--001636c5abdf9992780466f58195-- From owner-ietf-pkix@mail.imc.org Tue Apr 7 13:40:57 2009 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 714373A6E0A for ; Tue, 7 Apr 2009 13:40:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.869 X-Spam-Level: X-Spam-Status: No, score=-1.869 tagged_above=-999 required=5 tests=[AWL=0.730, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VJGr57Oz7Kbu for ; Tue, 7 Apr 2009 13:40:56 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id A0EDF3A6E0C for ; Tue, 7 Apr 2009 13:40:55 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n37KDVSF023906 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Apr 2009 13:13:31 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n37KDUvp023905; Tue, 7 Apr 2009 13:13:30 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from pne-smtpout1-sn1.fre.skanova.net (pne-smtpout1-sn1.fre.skanova.net [81.228.11.98]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n37KDJow023890 for ; Tue, 7 Apr 2009 13:13:30 -0700 (MST) (envelope-from anders.rundgren@telia.com) Received: from AndersPC (81.232.45.215) by pne-smtpout1-sn1.fre.skanova.net (7.3.129) id 49CCDA070016EFF6 for ietf-pkix@imc.org; Tue, 7 Apr 2009 22:13:18 +0200 Message-ID: <51FB0BC2B15540E3BAC7C0464B479375@AndersPC> From: "Anders Rundgren" To: Subject: - An HTML5 standard facility? Date: Tue, 7 Apr 2009 22:13:42 +0200 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 Windows Mail 6.0.6000.20661 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16669 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: http://www.whatwg.org/specs/web-apps/current-work/#the-keygen-element Since the PKI community at large seems to ignore the client-side of PKI in browsers, the HTML 5 designers apparently didn't find any other solution but adopting the 15 year old Netscape hack known as . It is indeed as said in this list very simple to use etc. However, does it really match the needs of today? My guess FWIW, is that the serious users of on-line provisioning of PKI which includes governments and banks in the EU, as well as the USPTO will continue to use entirely proprietary solutions (mostly using Java), since the browser-schemes are all-over-the-map and do not do signatures either. A few things to consider: How could a static tag in a page mark-up language match an API or a protocol? Algorithm agility, isn't that a requirement these days? PIN-codes anybody? TPM - A dead duck? Anders From owner-ietf-pkix@mail.imc.org Tue Apr 7 15:50:25 2009 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F6E83A684B for ; Tue, 7 Apr 2009 15:50:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.598 X-Spam-Level: X-Spam-Status: No, score=-1.598 tagged_above=-999 required=5 tests=[AWL=0.651, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XSJ0wzNBOiP0 for ; Tue, 7 Apr 2009 15:50:24 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 1143E3A67C1 for ; Tue, 7 Apr 2009 15:50:23 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n37MUGcJ031327 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Apr 2009 15:30:16 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n37MUG7Q031326; Tue, 7 Apr 2009 15:30:16 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from s87.loopia.se (s87.loopia.se [194.9.95.112]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n37MU20C031313 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 7 Apr 2009 15:30:14 -0700 (MST) (envelope-from stefan@aaa-sec.com) Received: (qmail 56805 invoked from network); 7 Apr 2009 22:30:10 -0000 Received: from s34.loopia.se (HELO s19.loopia.se) ([194.9.94.70]) (envelope-sender ) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 7 Apr 2009 22:30:10 -0000 Received: (qmail 81113 invoked from network); 7 Apr 2009 22:30:01 -0000 Received: from 90-229-233-249-no153.tbcn.telia.com (HELO [192.168.0.17]) (stefan@fiddler.nu@[90.229.233.249]) (envelope-sender ) by s19.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 7 Apr 2009 22:30:01 -0000 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Wed, 08 Apr 2009 00:30:00 +0200 Subject: Re: - An HTML5 standard facility? From: Stefan Santesson To: Anders Rundgren , Message-ID: Thread-Topic: - An HTML5 standard facility? Thread-Index: Acm30GMSHwX2ItKBnkiyz/+2DbXauw== In-Reply-To: <51FB0BC2B15540E3BAC7C0464B479375@AndersPC> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I find it a bit remarkable that they reference RFC 2459 for algorithm identifier OIDs Quote: "3. Let algorithm be an ASN.1 AlgorithmIdentifier structure as defined by RFC2459, with the algorithm field giving the ASN.1 OID used to identify signature algorithm, using the OIDs defined in section 7.2 ("Signature Algorithms") of RFC2459, and the parameters field set up as required by RFC2459 for AlgorithmIdentifier structures for that algorithm. [X690] [RFC2459]" It's a tiny bit more than slightly outdated... /Stefan On 4/7/09 10:13 PM, "Anders Rundgren" wrote: > > http://www.whatwg.org/specs/web-apps/current-work/#the-keygen-element > > Since the PKI community at large seems to ignore the client-side of > PKI in browsers, the HTML 5 designers apparently didn't find any other > solution but adopting the 15 year old Netscape hack known as . > > It is indeed as said in this list very simple to use etc. However, > does it really match the needs of today? > > My guess FWIW, is that the serious users of on-line provisioning of PKI > which includes governments and banks in the EU, as well as the USPTO > will continue to use entirely proprietary solutions (mostly using Java), since > the browser-schemes are all-over-the-map and do not do signatures either. > > A few things to consider: > > How could a static tag in a page mark-up language match an API > or a protocol? > > Algorithm agility, isn't that a requirement these days? > > PIN-codes anybody? > > TPM - A dead duck? > > Anders > From owner-ietf-pkix@mail.imc.org Tue Apr 7 16:22:42 2009 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1A3E3A6E05 for ; Tue, 7 Apr 2009 16:22:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.814 X-Spam-Level: X-Spam-Status: No, score=-0.814 tagged_above=-999 required=5 tests=[AWL=-0.262, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 233YwEnnAb57 for ; Tue, 7 Apr 2009 16:22:41 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 8BA473A68ED for ; Tue, 7 Apr 2009 16:20:42 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n37N0bSH032608 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Apr 2009 16:00:37 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n37N0bBX032607; Tue, 7 Apr 2009 16:00:37 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from s87.loopia.se (s87.loopia.se [194.9.95.112]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n37N0XGZ032599 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 7 Apr 2009 16:00:35 -0700 (MST) (envelope-from stefan@aaa-sec.com) Received: (qmail 79598 invoked from network); 7 Apr 2009 23:00:42 -0000 Received: from s34.loopia.se (HELO s24.loopia.se) ([194.9.94.70]) (envelope-sender ) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 7 Apr 2009 23:00:42 -0000 Received: (qmail 89598 invoked from network); 7 Apr 2009 23:00:32 -0000 Received: from 90-229-233-249-no153.tbcn.telia.com (HELO [192.168.0.17]) (stefan@fiddler.nu@[90.229.233.249]) (envelope-sender ) by s24.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 7 Apr 2009 23:00:32 -0000 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Wed, 08 Apr 2009 01:00:29 +0200 Subject: Re: Revocation scheme definition From: Stefan Santesson To: Jorge =?ISO-8859-1?B?TPNwZXo=?= , Message-ID: Thread-Topic: Revocation scheme definition Thread-Index: Acm31KU9P6Updu1cdk2ECIQhTrzzMA== In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3321997232_36557475" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3321997232_36557475 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Jorge, Despite that I would love to put CSI expert on my business card, it might b= e a bit problematic to hijack this acronym :) Other than that I feel sympathetic to your distinction between revocation and validation. It is however my belief that we have used that distinction in our standards efforts. /Stefan On 4/7/09 1:42 PM, "Jorge L=F3pez" wrote: > Hi all, >=20 > Next I merely offer personal considerations about the (in my opinion) > confusing scenario of PKI terminology classification. I would appreciate = any > comment on this. >=20 > As can be seen in the literature, most people define CRL, Partitioned CRL= , > Over-issued CRL, Delta CRL, OCSP, NOVOMODO, Certificate Revocation Status= , > Certificate Revocation Tree, etc. as revocation schemes. I think this > "classification" is confusing. >=20 > I personally consider a revocation scheme as a scheme/protocol where the = owner > (or an authorised party) is able to revocate the status of her certificat= e. > For example, the one defined in RFC 4210 CMP. However, the terms mentione= d > above relate to data structures (CRL, Partitioned CRL, Delta CRL), mechan= isms > to make that data structure available to others (Over-Issued CRL, Over-Is= sued > Segmented CRL, etc.) and both the managed data structure and the associat= ed > publication mechanism (NOVOMODO, Certificate Revocation Tree, etc.). But = none > of them to the procedure to be followed in order to revocate the certific= ate! > If fact OCSP is sometimes referenced as a revocation scheme, when it is > actually focused on "just" checking the revocation status of a certificat= e... >=20 > From my viewpoint, I would differentiate among the scheme, the certificat= e > status information itself - CSI (data structure) - and the method that > distributes/publishes the CSI. A revocation scheme updates the CSI. Howev= er, > the publication/distribution method is oriented to support the validation= of > certificates. IMHO it has nothing to do with a revocation scheme. Perhaps= you > may consider appropiate to include in the term "revocation scheme" everyt= hing > that has something to do with the revocation information... >=20 > Therefore, I distinguish a revocation scheme from another type of scheme > (validation scheme) which aim is to check the status of a certificate tak= ing > into account the CSI. This CSI could be distributed/published by using on= e of > the methods defined above, or accessed in an online manner (an OCSP servi= ce > that retrieves the CSI from a fresh database). >=20 > I guess that the revocation scheme term has been extended to things not s= o > related to the revocation itself, like the validation procedure. I just w= ant > to know what the PKI community think about this. >=20 > Thanks in advance, >=20 > -------- > Jorge Lopez Hernandez-Ardieta >=20 >=20 >=20 --B_3321997232_36557475 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: Revocation scheme definition Jorge,

Despite that I would love to put CSI expert on my business card, it might b= e a bit problematic to hijack this acronym :)

Other than that I feel sympathetic to your distinction between revocation a= nd validation. It is however my belief that we have used that distinction in= our standards efforts.

/Stefan

On 4/7/09 1:42 PM, "Jorge López" <jlopez.ha@gmail.com> wrote:

<= SPAN STYLE=3D'font-size:11pt'>Hi all,

Next I merely offer personal considerations about the (in my opinion) confu= sing scenario of PKI terminology classification. I would appreciate any comm= ent on this.

As can be seen in the literature, most people define CRL, Partitioned CRL, = Over-issued CRL, Delta CRL, OCSP, NOVOMODO, Certificate Revocation Status, C= ertificate Revocation Tree, etc. as revocation schemes. I think this "c= lassification" is confusing.

I personally consider a revocation scheme as a scheme/protocol where the ow= ner (or an authorised party) is able to revocate the status of her certifica= te. For example, the one defined in RFC 4210 CMP. However, the terms mention= ed above relate to data structures (CRL, Partitioned CRL, Delta CRL), mechan= isms to make that data structure available to others (Over-Issued CRL, Over-= Issued Segmented CRL, etc.) and both the managed data structure and the asso= ciated publication mechanism (NOVOMODO, Certificate Revocation Tree, etc.). = But none of them to the procedure to be followed in order to revocate the ce= rtificate! If fact OCSP is sometimes referenced as a revocation scheme, when= it is actually focused on "just" checking the revocation status o= f a certificate...

>From my viewpoint, I would differentiate among the scheme, the certificate = status information itself - CSI (data structure) - and the method that distr= ibutes/publishes the CSI. A revocation scheme updates the CSI. However, the = publication/distribution method is oriented to support the validation of cer= tificates. IMHO it has nothing to do with a revocation scheme. Perhaps you m= ay consider appropiate to include in the term "revocation scheme" = everything that has something to do with the revocation information...

Therefore, I distinguish a revocation scheme from another type of scheme (v= alidation scheme) which aim is to check the status of a certificate taking i= nto account the CSI. This CSI could be distributed/published by using one of= the methods defined above, or accessed in an online manner (an OCSP service= that retrieves the CSI from a fresh database).

I guess that the revocation scheme term has been extended to things not so = related to the revocation itself, like the validation procedure. I just want= to know what the PKI community think about this.

Thanks in advance,

--------
Jorge Lopez Hernandez-Ardieta

--B_3321997232_36557475-- From owner-ietf-pkix@mail.imc.org Wed Apr 8 07:48:15 2009 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 343883A69B7 for ; Wed, 8 Apr 2009 07:48:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.132 X-Spam-Level: X-Spam-Status: No, score=-7.132 tagged_above=-999 required=5 tests=[AWL=1.167, BAYES_00=-2.599, GB_I_LETTER=-2, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id buZwk-ia-LBM for ; Wed, 8 Apr 2009 07:48:14 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 7DCE53A6953 for ; Wed, 8 Apr 2009 07:48:13 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n38EJgLS002029 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Apr 2009 07:19:42 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n38EJgBf002028; Wed, 8 Apr 2009 07:19:42 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n38EJec5002019 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 8 Apr 2009 07:19:41 -0700 (MST) (envelope-from david.cooper@nist.gov) Received: from postmark.nist.gov (emailha2.nist.gov [129.6.16.198]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id n38EJhod001433; Wed, 8 Apr 2009 10:19:43 -0400 Received: from st26.ncsl.nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.13.1/8.13.1) with ESMTP id n38EJPD7029326; Wed, 8 Apr 2009 10:19:26 -0400 Message-ID: <49DCB26D.5050202@nist.gov> Date: Wed, 08 Apr 2009 10:19:25 -0400 From: "David A. Cooper" User-Agent: Thunderbird 2.0.0.21 (X11/20090330) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Jorge_L=F3pez?= , Stefan Santesson CC: pkix Subject: Re: Revocation scheme definition References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: david.cooper@nist.gov Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Stefan Santesson wrote: > Despite that I would love to put CSI expert on my business card, it > might be a bit problematic to hijack this acronym :) Yes, RFC 5513 points out the problem of the overuse of three letter acronyms (granted it is an April 1 RFC). If we used the acronym CSI, most people would tend to immediately think of the College of Southern Idaho ... I mean the College of Staten Island ... Computer Security Institute ... Construction Specifications Institute ... Commodity Systems Inc. ... Computers & Structures, Inc. ... Chi Sigma Iota ... Christian Schools International ... Computational Systems, Inc. ... Christian Solidarity International ... California Solar Initiative ... Canadian Solar Inc. ... Chandler Systems Inc. ... Communications Specialties, Inc. ... Cetacean Society International ... Coalition of Service Industries ... Church of South India ... Computer Society of India ... Cellular Specialties, Inc. ... College Student Insurance ... Custom Systems Integration ... Center for Social Innovation ... Center for Sustainable Innovation ... Creative Specialties International ... Control Sciences Inc. ... Conditional Symmetric Instability ... Community Services Infrastructure ... Coastal Studies Institute ... Curriculum Support Information ... Control Solutions International ... Conversion Services International ... Civil Society International ... Collaborative Software Initiative ... Consolidated Systems Incorporated ... Center for the Study of Intelligence ... Combat Studies Institute ... Coatings Societies International ... Chemical Sampling Information ... California Steel Industries ... Cardiovascular Systems Inc. ... Conservation Study Institute ... Cognitive Strategy Instruction ... Compliance Services International ... Cement Sustainability Initiative ... Cyber Safety Initiative ... Center for Student Involvement ... Center for the Study of Inequality ... Chiropractic Sports Institute ... Closure Systems International ... Custom Scientific Instruments ... Crisis Simulations International ... Cooperative Sagebrush Initiative ... Child Study Institute ... Climate Status Investigations ... Centrifugal Services, Inc. ... Conflict Solutions International ... Caregiver Services, Inc. ... Charter School Institute ... Component Sources International ... So I can understand that you would be concerned that if you referred to yourself as a CSI expert, people might think you meant that you were an expert in Computational Sciences and Informatics. > Other than that I feel sympathetic to your distinction between > revocation and validation. It is however my belief that we have used > that distinction in our standards efforts. I think it would be helpful if specific examples were provided of places in PKIX documents in which the distinction between mechanisms for distributing certificate status information (e.g., CRLs and OCSP) and mechanisms for submitting revocation requests (e.g., a CMP revocation request message) is not clear. Perhaps this confusion does appear in the literature, and those of us on this list simply don't notice it since we already clearly understand the concepts. But without being provided specific examples of text that a non-PKI expert might find confusing, it is difficult for us to judge whether this is a problem in PKIX documents that the WG needs to be more careful about in future documents. Dave > On 4/7/09 1:42 PM, "Jorge López" wrote: > > Hi all, > > Next I merely offer personal considerations about the (in my > opinion) confusing scenario of PKI terminology classification. I > would appreciate any comment on this. > > As can be seen in the literature, most people define CRL, > Partitioned CRL, Over-issued CRL, Delta CRL, OCSP, NOVOMODO, > Certificate Revocation Status, Certificate Revocation Tree, etc. > as revocation schemes. I think this "classification" is confusing. > > I personally consider a revocation scheme as a scheme/protocol > where the owner (or an authorised party) is able to revocate the > status of her certificate. For example, the one defined in RFC > 4210 CMP. However, the terms mentioned above relate to data > structures (CRL, Partitioned CRL, Delta CRL), mechanisms to make > that data structure available to others (Over-Issued CRL, > Over-Issued Segmented CRL, etc.) and both the managed data > structure and the associated publication mechanism (NOVOMODO, > Certificate Revocation Tree, etc.). But none of them to the > procedure to be followed in order to revocate the certificate! If > fact OCSP is sometimes referenced as a revocation scheme, when it > is actually focused on "just" checking the revocation status of a > certificate... > > From my viewpoint, I would differentiate among the scheme, the > certificate status information itself - CSI (data structure) - and > the method that distributes/publishes the CSI. A revocation scheme > updates the CSI. However, the publication/distribution method is > oriented to support the validation of certificates. IMHO it has > nothing to do with a revocation scheme. Perhaps you may consider > appropiate to include in the term "revocation scheme" everything > that has something to do with the revocation information... > > Therefore, I distinguish a revocation scheme from another type of > scheme (validation scheme) which aim is to check the status of a > certificate taking into account the CSI. This CSI could be > distributed/published by using one of the methods defined above, > or accessed in an online manner (an OCSP service that retrieves > the CSI from a fresh database). > > I guess that the revocation scheme term has been extended to > things not so related to the revocation itself, like the > validation procedure. I just want to know what the PKI community > think about this. > > Thanks in advance, > > -------- > Jorge Lopez Hernandez-Ardieta > From owner-ietf-pkix@mail.imc.org Wed Apr 8 08:29:35 2009 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6AFD3A6A3B for ; Wed, 8 Apr 2009 08:29:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0eM5sh8MgKvr for ; Wed, 8 Apr 2009 08:29:34 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id BD0113A68C3 for ; Wed, 8 Apr 2009 08:29:33 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n38Ew71t005866 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Apr 2009 07:58:08 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n38Ew7FS005865; Wed, 8 Apr 2009 07:58:07 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail-fx0-f177.google.com (mail-fx0-f177.google.com [209.85.220.177]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n38EvtQJ005840 for ; Wed, 8 Apr 2009 07:58:06 -0700 (MST) (envelope-from jlopez.ha@gmail.com) Received: by fxm25 with SMTP id 25so174748fxm.10 for ; Wed, 08 Apr 2009 07:57:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=9Z/kLQvAVeOVthHV9xhPtxDJ1CkrYeiiue5s39nsTtA=; b=r4fQH0SmXvyZSFJctoEctkEIVa5UMW2HKi2Le4nWBMxfp86drF2pcpQeG7GcIQM09o c+2GACOeR7Hjw/d3RkhmHAv1WtB4pJmvhv90K45cTUZJ+O54Enc4b1xzD0WcCGrnxoaI HhZgps7UrahjFeCn0+TSyZcdlAnf/W16d/56I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=BN3mmPhoNEC5vvDTb12Thzc7syouzFroLftkfxm3kRMTNy8+5wEDMT83k0UkVBs6ez 3KwUcqWbnRhbvtAu9hxHP6oaaMqOTDfGOqwDwAXYG074vaQhgz9NHqZzUK8rOeeBmIoS i0G4s8Wor0OY0EBSgui9fVOIxGaGM8DtZ9VCw= MIME-Version: 1.0 Received: by 10.204.77.81 with SMTP id f17mr1202998bkk.78.1239202674915; Wed, 08 Apr 2009 07:57:54 -0700 (PDT) In-Reply-To: <49DCB26D.5050202@nist.gov> References: <49DCB26D.5050202@nist.gov> Date: Wed, 8 Apr 2009 16:57:54 +0200 Message-ID: Subject: Re: Revocation scheme definition From: =?ISO-8859-1?Q?Jorge_L=F3pez?= To: "David A. Cooper" Cc: Stefan Santesson , pkix Content-Type: multipart/alternative; boundary=001485f870603e3a0d04670c5b4e Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --001485f870603e3a0d04670c5b4e Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks Stefan and Dave for your responses. Well, maybe CSI was not the best acronym as a proposal :-) I wasn't talking about PKIX documents, but some research papers, master/doctoral thesis where a classification of "revocation mechanisms" is made. I understand that these domains are out of the scope of the PKIX community, but maybe we should think of "standardizing" some concepts if th= e "rest of the world" tends to confuse them. I think that's one of the tasks of a standardization organization/work group/etc. Possibly it is not worthy to work on it focusing merely on revocation schem= e related terms, but I have been following a thread about digital certificate/end user certificate/etc. terms that seemed to be confusing as well to some folks. Is it crazy to propose an RFC Informational which collects a kind of glossary and definitions of PKIX related technology? Best, -------- Jorge Lopez Hernandez-Ardieta 2009/4/8 David A. Cooper > Stefan Santesson wrote: > >> Despite that I would love to put CSI expert on my business card, it migh= t >> be a bit problematic to hijack this acronym :) >> > > Yes, RFC 5513 points out the problem of the overuse of three letter > acronyms (granted it is an April 1 RFC). If we used the acronym CSI, mos= t > people would tend to immediately think of the College of Southern Idaho .= .. > I mean the College of Staten Island ... Computer Security Institute ... > Construction Specifications Institute ... Commodity Systems Inc. ... > Computers & Structures, Inc. ... Chi Sigma Iota ... Christian Schools > International ... Computational Systems, Inc. ... Christian Solidarity > International ... California Solar Initiative ... Canadian Solar Inc. ... > Chandler Systems Inc. ... Communications Specialties, Inc. ... Cetacean > Society International ... Coalition of Service Industries ... Church of > South India ... Computer Society of India ... Cellular Specialties, Inc. = ... > College Student Insurance ... Custom Systems Integration ... Center for > Social Innovation ... Center for Sustainable Innovation ... Creative > Specialties International ... Control Sciences Inc. ... Conditional > Symmetric Instability ... Community Services Infrastructure ... Coastal > Studies Institute ... Curriculum Support Information ... Control Solution= s > International ... Conversion Services International ... Civil Society > International ... Collaborative Software Initiative ... Consolidated Syst= ems > Incorporated ... Center for the Study of Intelligence ... Combat Studies > Institute ... Coatings Societies International ... Chemical Sampling > Information ... California Steel Industries ... Cardiovascular Systems In= c. > ... Conservation Study Institute ... Cognitive Strategy Instruction ... > Compliance Services International ... Cement Sustainability Initiative ..= . > Cyber Safety Initiative ... Center for Student Involvement ... Center for > the Study of Inequality ... Chiropractic Sports Institute ... Closure > Systems International ... Custom Scientific Instruments ... Crisis > Simulations International ... Cooperative Sagebrush Initiative ... Child > Study Institute ... Climate Status Investigations ... Centrifugal Service= s, > Inc. ... Conflict Solutions International ... Caregiver Services, Inc. ..= . > Charter School Institute ... Component Sources International ... > > So I can understand that you would be concerned that if you referred to > yourself as a CSI expert, people might think you meant that you were an > expert in Computational Sciences and Informatics. > > Other than that I feel sympathetic to your distinction between revocatio= n >> and validation. It is however my belief that we have used that distincti= on >> in our standards efforts. >> > > I think it would be helpful if specific examples were provided of places = in > PKIX documents in which the distinction between mechanisms for distributi= ng > certificate status information (e.g., CRLs and OCSP) and mechanisms for > submitting revocation requests (e.g., a CMP revocation request message) i= s > not clear. Perhaps this confusion does appear in the literature, and tho= se > of us on this list simply don't notice it since we already clearly > understand the concepts. But without being provided specific examples of > text that a non-PKI expert might find confusing, it is difficult for us t= o > judge whether this is a problem in PKIX documents that the WG needs to be > more careful about in future documents. > > Dave > > > On 4/7/09 1:42 PM, "Jorge L=F3pez" wrote: >> >> Hi all, >> >> Next I merely offer personal considerations about the (in my >> opinion) confusing scenario of PKI terminology classification. I >> would appreciate any comment on this. >> >> As can be seen in the literature, most people define CRL, >> Partitioned CRL, Over-issued CRL, Delta CRL, OCSP, NOVOMODO, >> Certificate Revocation Status, Certificate Revocation Tree, etc. >> as revocation schemes. I think this "classification" is confusing. >> >> I personally consider a revocation scheme as a scheme/protocol >> where the owner (or an authorised party) is able to revocate the >> status of her certificate. For example, the one defined in RFC >> 4210 CMP. However, the terms mentioned above relate to data >> structures (CRL, Partitioned CRL, Delta CRL), mechanisms to make >> that data structure available to others (Over-Issued CRL, >> Over-Issued Segmented CRL, etc.) and both the managed data >> structure and the associated publication mechanism (NOVOMODO, >> Certificate Revocation Tree, etc.). But none of them to the >> procedure to be followed in order to revocate the certificate! If >> fact OCSP is sometimes referenced as a revocation scheme, when it >> is actually focused on "just" checking the revocation status of a >> certificate... >> >> From my viewpoint, I would differentiate among the scheme, the >> certificate status information itself - CSI (data structure) - and >> the method that distributes/publishes the CSI. A revocation scheme >> updates the CSI. However, the publication/distribution method is >> oriented to support the validation of certificates. IMHO it has >> nothing to do with a revocation scheme. Perhaps you may consider >> appropiate to include in the term "revocation scheme" everything >> that has something to do with the revocation information... >> >> Therefore, I distinguish a revocation scheme from another type of >> scheme (validation scheme) which aim is to check the status of a >> certificate taking into account the CSI. This CSI could be >> distributed/published by using one of the methods defined above, >> or accessed in an online manner (an OCSP service that retrieves >> the CSI from a fresh database). >> >> I guess that the revocation scheme term has been extended to >> things not so related to the revocation itself, like the >> validation procedure. I just want to know what the PKI community >> think about this. >> >> Thanks in advance, >> >> -------- >> Jorge Lopez Hernandez-Ardieta >> >> > --001485f870603e3a0d04670c5b4e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Thanks Stefan and Dave for your responses.

We= ll, maybe CSI was not the best acronym as a proposal :-)

I wasn't talking about PKIX documents, but some research papers,= master/doctoral thesis where a classification of "revocation mechanis= ms" is made. I understand that these domains are out of the scope of t= he PKIX community, but maybe we should think of "standardizing" s= ome concepts if the "rest of the world" tends to confuse them. I = think that's one of the tasks of a standardization organization/work gr= oup/etc.

Possibly it is not worthy to work on it focusing merely= on revocation scheme related terms, but I have been following a thread abo= ut digital certificate/end user certificate/etc. terms that seemed to be co= nfusing as well to some folks.

Is it crazy to propose an RFC Informational which colle= cts a kind of glossary and definitions of PKIX related technology?

Best,

--------

Jorge Lo= pez Hernandez-Ardieta

2009/4/8 David A. Cooper &= lt;david.cooper@nist.gov>

Stefan Santesson wrote:

Despite that I would love to put CSI expert on my business card, it might b= e a bit problematic to hijack this acronym :)

Yes, RFC 5513 points out the problem of the overuse of three letter acronym= s (granted it is an April 1 RFC). =A0If we used the acronym CSI, most peopl= e would tend to immediately think of the College of Southern Idaho ... I me= an the College of Staten Island ... Computer Security Institute ... Constru= ction Specifications Institute ... Commodity Systems Inc. ... Computers &am= p; Structures, Inc. ... Chi Sigma Iota ... Christian Schools International = ... Computational Systems, Inc. ... Christian Solidarity International ... = California Solar Initiative ... Canadian Solar Inc. ... Chandler Systems In= c. ... Communications Specialties, Inc. ... Cetacean Society International = ... Coalition of Service Industries ... Church of South India ... Computer = Society of India ... Cellular Specialties, Inc. ... College Student Insuran= ce ... Custom Systems Integration ... Center for Social Innovation ... Cent= er for Sustainable Innovation ... Creative Specialties International ... Co= ntrol Sciences Inc. ... Conditional Symmetric Instability ... Community Ser= vices Infrastructure ... Coastal Studies Institute ... Curriculum Support I= nformation ... Control Solutions International ... Conversion Services Inte= rnational ... Civil Society International ... Collaborative Software Initia= tive ... Consolidated Systems Incorporated ... Center for the Study of Inte= lligence ... Combat Studies Institute ... Coatings Societies International = ... Chemical Sampling Information ... California Steel Industries ... Cardi= ovascular Systems Inc. ... Conservation Study Institute ... =A0Cognitive St= rategy Instruction ... Compliance Services International ... Cement Sustain= ability Initiative ... Cyber Safety Initiative ... Center for Student Invol= vement ... Center for the Study of Inequality ... Chiropractic Sports Insti= tute ... Closure Systems International ... Custom Scientific Instruments ..= . Crisis Simulations International ... Cooperative Sagebrush Initiative ...= Child Study Institute ... Climate Status Investigations ... Centrifugal Se= rvices, Inc. ... Conflict Solutions International ... Caregiver Services, I= nc. ... Charter School Institute ... Component Sources International ...
So I can understand that you would be concerned that if you referred to you= rself as a CSI expert, people might think you meant that you were an expert= in Computational Sciences and Informatics.

Other than that I feel sympathetic to your distinction between revocation a= nd validation. It is however my belief that we have used that distinction i= n our standards efforts.

I think it would be helpful if specific examples were provided of places in= PKIX documents in which the distinction between mechanisms for distributin= g certificate status information (e.g., CRLs and OCSP) and mechanisms for s= ubmitting revocation requests (e.g., a CMP revocation request message) is n= ot clear. =A0Perhaps this confusion does appear in the literature, and thos= e of us on this list simply don't notice it since we already clearly un= derstand the concepts. =A0But without being provided specific examples of t= ext that a non-PKI expert might find confusing, it is difficult for us to j= udge whether this is a problem in PKIX documents that the WG needs to be mo= re careful about in future documents.

Dave

On 4/7/09 1:42 PM, "Jorge L=F3pez" <jlopez.ha@gmail.com> wrote:

=A0 =A0Hi all,

=A0 =A0Next I merely offer personal considerations about the (in my
=A0 =A0opinion) confusing scenario of PKI terminology classification. I =A0 =A0would appreciate any comment on this.

=A0 =A0As can be seen in the literature, most people define CRL,
=A0 =A0Partitioned CRL, Over-issued CRL, Delta CRL, OCSP, NOVOMODO,
=A0 =A0Certificate Revocation Status, Certificate Revocation Tree, etc. =A0 =A0as revocation schemes. I think this "classification" is c= onfusing.

=A0 =A0I personally consider a revocation scheme as a scheme/protocol
=A0 =A0where the owner (or an authorised party) is able to revocate the =A0 =A0status of her certificate. For example, the one defined in RFC
=A0 =A04210 CMP. However, the terms mentioned above relate to data
=A0 =A0structures (CRL, Partitioned CRL, Delta CRL), mechanisms to make =A0 =A0that data structure available to others (Over-Issued CRL,
=A0 =A0Over-Issued Segmented CRL, etc.) and both the managed data
=A0 =A0structure and the associated publication mechanism (NOVOMODO,
=A0 =A0Certificate Revocation Tree, etc.). But none of them to the
=A0 =A0procedure to be followed in order to revocate the certificate! If =A0 =A0fact OCSP is sometimes referenced as a revocation scheme, when it =A0 =A0is actually focused on "just" checking the revocation sta= tus of a
=A0 =A0certificate...

=A0 =A0From my viewpoint, I would differentiate among the scheme, the
=A0 =A0certificate status information itself - CSI (data structure) - and<= br> =A0 =A0the method that distributes/publishes the CSI. A revocation scheme<= br> =A0 =A0updates the CSI. However, the publication/distribution method is =A0 =A0oriented to support the validation of certificates. IMHO it has
=A0 =A0nothing to do with a revocation scheme. Perhaps you may consider =A0 =A0appropiate to include in the term "revocation scheme" eve= rything
=A0 =A0that has something to do with the revocation information...

=A0 =A0Therefore, I distinguish a revocation scheme from another type of =A0 =A0scheme (validation scheme) which aim is to check the status of a =A0 =A0certificate taking into account the CSI. This CSI could be
=A0 =A0distributed/published by using one of the methods defined above, =A0 =A0or accessed in an online manner (an OCSP service that retrieves
=A0 =A0the CSI from a fresh database).

=A0 =A0I guess that the revocation scheme term has been extended to
=A0 =A0things not so related to the revocation itself, like the
=A0 =A0validation procedure. I just want to know what the PKI community =A0 =A0think about this.

=A0 =A0Thanks in advance,

=A0 =A0--------
=A0 =A0Jorge Lopez Hernandez-Ardieta

--001485f870603e3a0d04670c5b4e-- From owner-ietf-pkix@mail.imc.org Thu Apr 9 08:58:48 2009 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E97CF3A6CB3 for ; Thu, 9 Apr 2009 08:58:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.138 X-Spam-Level: X-Spam-Status: No, score=-0.138 tagged_above=-999 required=5 tests=[AWL=-1.224, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.134, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KQhJBjAsmVcx for ; Thu, 9 Apr 2009 08:58:47 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 99A723A6BAF for ; Thu, 9 Apr 2009 08:58:44 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n39Fa78r026216 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Apr 2009 08:36:07 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n39Fa78j026215; Thu, 9 Apr 2009 08:36:07 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n39FZtsh026198 for ; Thu, 9 Apr 2009 08:36:06 -0700 (MST) (envelope-from SChokhani@cygnacom.com) Received: (qmail 20817 invoked from network); 9 Apr 2009 15:34:38 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 9 Apr 2009 15:34:38 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; boundary="----_=_NextPart_001_01C9B928.DDECEF6D"; type="multipart/alternative" X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [x500standard] Re: Certificate definitions Date: Thu, 9 Apr 2009 11:35:52 -0400 Message-ID: In-Reply-To: <7B01F815F4064ABEB6447E403CA12C56@ERA1> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [x500standard] Re: Certificate definitions Thread-Index: Acm0cXogl35R6fnrRR6btIokFjzPxQErLQOwAAKEOVA= References: <7B01F815F4064ABEB6447E403CA12C56@ERA1> From: "Santosh Chokhani" To: , "ietf-pkix" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------_=_NextPart_001_01C9B928.DDECEF6D Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C9B928.DDECEF6D" ------_=_NextPart_002_01C9B928.DDECEF6D Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Erik, =20 See responses inline. ________________________________ From: x500standard-bounce@freelists.org = [mailto:x500standard-bounce@freelists.org] On Behalf Of Erik Andersen Sent: Thursday, April 09, 2009 11:26 AM To: x500standard@freelists.org; 'ietf-pkix' Subject: [x500standard] Re: Certificate definitions =09 =09 Hi Denis, =20 It is a little dangerous not to respond to my comments. Due to the = apparent inactivity of people, I have the power to produce Defect = Reports, produce Draft Technical Corrigenda, run them through both the = ISO and ITU-T approval process and finally integrate them into the next = edition of X.500 (incl. X.509) without being stopped by anyone (except = for Jean-Paul Lemaire). =20 I believe you misunderstood my diagram. It may be a little confusing. = Let me express myself without the diagram. =20 The set of certificates is the union of the set of public-key = certificates and the set of attribute certificates. =20 The set of end-entity certificates is the union of public-key = certificates issued to end-entities and the set of attribute = certificates issued to end-entities. However, X.509 is a little = confusing here as the term end-entity certificate is sometimes meant to = be just public-key certificates issued to end-entities, so the term = end-entity certificate has two meanings. =20 The set of public-key certificates is the union of the set of = end-entity (public-key) certificates and the set of CA certificates. =20 The set of attribute certificates is the union of the set of end-entity = (attribute) certificates and the set of AA certificates. =20 The set of authority certificates is the union of the set CA = certificates and the set of AA certificates. =20 The set of CA certificates is the union of the set of self-issued = (public-key) certificates and the set cross certificates. The latter is = a little confusing, as a cross certificate can also be an attribute = certificate.=20 =20 [Santosh]: The above paragraph has two inaccuracies. Since not all CA = certificates are called cross certificates, set of CA certificates are = self-issued, cross certificate, and subordinate CA certificates. (I = wish we had not distinguished between cross certificates and subordinate = CA certificates in the first place). Also note that a cross certificate = can not be attribute certificate. I don't see an AA cross certificate = in RFC 3281 or in X.509 =20 I am avoiding here to use the term "user attribute", but believe it is = supposed to mean a public-key certificate issued to an end-entity. =20 Whenever an innocent reader sees the term "certificate", he/she is = entitled to believe it can either be a public-key certificate. It may = not always be clear from the context what is meant. =20 Whenever an innocent us reader see the term "end-entity certificate", = he/she is entitled to believe it is either a public key certificate or = an attribute certificate issued to an end-entity. =20 Whenever an innocent us reader see the term "cross-certificate", = he/she is entitled to believe it is either a public key certificate or = an attribute certificate.=20 [Santosh]: See prior comment.=20 =20 My proposal was only to clear-up the terminology and to use the = terminology consistent in the text of X.509. Trying to do the latter may = raise a number of detailed questions when the meaning is not absolutely = clear from the context. =20 =20 Erik Andersen Andersen's L-Service Elsevej 48, DK-3500 Vaerloese Denmark Mobile: +45 2097 1490 email: era@x500.eu www.x500.eu www.x500standard.com =20 -----Original Message----- From: x500standard-bounce@freelists.org = [mailto:x500standard-bounce@freelists.org] On Behalf Of Denis Pinkas Sent: 3. april 2009 17:33 To: x500 list; ietf-pkix Subject: [x500standard] Re: Certificate definitions =20 Eric, =20 Silence does not mean approval. =20 It may mean that the corrections are so numerous that it would take too = long to respond and that people do not have that time available at the moment. =20 e.g.: an End-entity attribute certificate is not linked to a = public-key certificate. a cross-certificate is not linked to an AA certificate. an Authority Certificate is not linked to an Attribute = Certificate. =20 This is only a start ... =20 Denis ----- Message re=E7u -----=20 De : owner-ietf-pkix=20 =C0 : x500standard,'PKIX'=20 Date : 2009-04-03, 17:00:01 Sujet : RE: [x500standard] Certificate definitions =20 I take silence as approval. =20 Erik Andersen Andersen's L-Service Elsevej 48, DK-3500 Vaerloese Denmark Mobile: +45 2097 1490 email: era@x500.eu www.x500.eu www.x500standard.com =20 -----Original Message----- From: x500standard-bounce@freelists.org = [mailto:x500standard-bounce@freelists.org] On Behalf Of Erik Andersen Sent: 1. april 2009 14:40 To: Directory list; PKIX Subject: [x500standard] Certificate definitions =20 Hi =20 I got a number of responses on user certificates, but quite little = that actually answered my question. =20 I have tried to dig a little bit more in X.509 to get hold of the = terminology and then produced below figure. I will not comment all the = boxes. =20 =20 =20 I will like you to comments as to the correctness of above figure. =20 The end-entity certificate is not defined in the definition clause. = However it is used widely in the main text. It is mentioned the first = time in clause 7 as a public-key certificate. There are several other = places where it is a public-key certificate. In 15.5.2.4 is used in the = context of attribute certificates. The conclusion must be that an = end-entity certificate can either be a end-entity public-key certificate = or an end-entity attribute certificate. However, in most places, it is = implied that we only talks about public-key certificates. For veterans, = this is not a major problem, but new-comers may get confused. Anyway, I = thing our specifications should be clear and not subject to = interpretation. RFC 5280 does not use the term at all. It seems just to = use the term "certificate" as a synonym for "end-entrity public key = certificate". =20 The "User Certificate" is not defined in X.509, but is wide used. It = seems to be a synonym for "end-entrity public key certificate". It is = also used in X.511. RFC 5280 uses the term once without differenting it = from just "certificate". =20 The term "cross-certificate" should probably also be qualified. =20 I suggest to add in X.509 definitions for: =20 "end-entity public-key certificate" "user certificate" as a synonym for "end-entity public-key = certificate" "end-entity attribute certificate" =20 The X.509 text should be updated to make use of these definitions. =20 X.509 has four attribute types for holding certificates. =20 UserCertificate: For end-entity public-key certificates cAcertificate: For CA certificates attributeCertificateAttribute: For end-entity attribute certificates aACertificate: For AA Certificates =20 Any comments? =20 Erik Andersen Andersen's L-Service Elsevej 48, DK-3500 Vaerloese Denmark Mobile: +45 2097 1490 email: era@x500.eu www.x500.eu www.x500standard.com =20 ------_=_NextPart_002_01C9B928.DDECEF6D Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Erik,

See responses inline.

From: = x500standard-bounce@freelists.org=20 [mailto:x500standard-bounce@freelists.org] On Behalf Of Erik=20 Andersen
Sent: Thursday, April 09, 2009 11:26 = AM
To:=20 x500standard@freelists.org; 'ietf-pkix'
Subject: = [x500standard] Re:=20 Certificate definitions

Hi=20 Denis,

It is a=20 little dangerous not to respond to my comments. Due to the apparent = inactivity=20 of people, I have the power to produce Defect Reports, produce Draft = Technical=20 Corrigenda, run them through both the ISO and ITU-T approval process = and=20 finally integrate them into the next edition of X.500 (incl. X.509) = without=20 being stopped by anyone (except for Jean-Paul Lemaire).

I believe=20 you misunderstood my diagram. It may be a little confusing. Let me = express=20 myself without the diagram.

The set of=20 certificates is the union of the set of public-key certificates and = the set of=20 attribute certificates.

The set of=20 end-entity certificates is the union of public-key certificates issued = to=20 end-entities and the set of attribute certificates issued to = end-entities.=20 However, X.509 is a little confusing here as the term end-entity = certificate=20 is sometimes meant to be just public-key certificates issued to = end-entities,=20 so the term end-entity certificate has two meanings.

The set of=20 public-key certificates is the union of the set of end-entity = (public-key)=20 certificates and the set of CA certificates.

The set of=20 attribute certificates is the union of the set of end-entity = (attribute)=20 certificates and the set of AA certificates.

The set of=20 authority certificates is the union of the set CA certificates and the = set of=20 AA certificates.

The set of=20 CA certificates is the union of the set of self-issued (public-key)=20 certificates and the set cross certificates. The latter is a little = confusing,=20 as a cross certificate can also be an attribute certificate.

[Santosh]: The above = paragraph=20 has two inaccuracies. Since not all CA certificates = are called=20 cross certificates, set of CA certificates are self-issued, cross = certificate,=20 and subordinate CA certificates. (I wish we had not = distinguished=20 between cross certificates and subordinate CA certificates in the = first=20 place). Also note that a cross certificate can not be attribute=20 certificate. I don't see an AA cross certificate in RFC 3281 or = in=20 X.509

I am=20 avoiding here to use the term =93user attribute=94, but believe it is = supposed to=20 mean a public-key certificate issued to an = end-entity.

Whenever=20 an innocent reader sees the term =93certificate=94, he/she is entitled = to believe=20 it can either be a public-key certificate. It may not always be clear = from the=20 context what is meant.

Whenever=20 an innocent us reader see the term =93end-entity certificate=94, = he/she is=20 entitled to believe it is either a public key certificate or an = attribute=20 certificate issued to an end-entity.

Whenever=20 an innocent us reader see the term =93cross-certificate=94, = he/she is=20 entitled to believe it is either a public key certificate or an = attribute=20 certificate.

[Santosh]: See = prior=20 comment.

My=20 proposal was only to clear-up the terminology and to use the = terminology=20 consistent in the text of X.509. Trying to do the latter may raise a = number of=20 detailed questions when the meaning is not absolutely clear from the = context.=20

Erik=20 Andersen

Andersen's=20 L-Service

Elsevej=20 48, DK-3500=20 Vaerloese

Denmark

Mobile: +45 = 2097=20 1490

email:=20 era@x500.eu

www.x500.eu

www.x500standard.com

-----Original=20 Message-----
From:=20 x500standard-bounce@freelists.org = [mailto:x500standard-bounce@freelists.org]=20 On Behalf Of Denis=20 Pinkas
Sent: 3. = april 2009=20 17:33
To: x500 list; = ietf-pkix
Subject: [x500standard] Re: = Certificate=20 definitions

Eric,

Silence = does not mean=20 approval.

It may = mean that=20 the corrections are so numerous that it would take too long to=20 respond

and that = people do not=20 have that time available at the moment.

e.g.: an=20 End-entity attribute certificate is not linked to a public-key=20 certificate.

a=20 cross-certificate is not linked to an AA = certificate.

an = Authority=20 Certificate is not linked to an Attribute = Certificate.

This is = only a=20 start ...

Denis

----- = Message re=E7u=20 -----

De=20 : = owner-ietf-pkix=20

=C0=20 : = x500standard,'PKIX'=20

Date : = 2009-04-03,=20 17:00:01

Sujet : RE: = [x500standard]=20 Certificate definitions

I take silence as approval.

Erik=20 Andersen

Andersen's=20 L-Service

Elsevej = 48, DK-3500=20 Vaerloese

Denmark

Mobile: +45 2097 1490

email: era@x500.eu

www.x500.eu

www.x500standard.com

-----Original=20 Message-----
From:=20 x500standard-bounce@freelists.org = [mailto:x500standard-bounce@freelists.org]=20 On Behalf Of Erik=20 Andersen
Sent: 1. = april=20 2009 14:40
To: = Directory=20 list; PKIX
Subject:=20 [x500standard] Certificate definitions

I got a = number of=20 responses on user certificates, but quite little that actually = answered my=20 question.

I have = tried to dig a=20 little bit more in X.509 to get hold of the terminology and then = produced=20 below figure. I will not comment all the boxes.

I will = like you to=20 comments as to the correctness of above figure.

The = end-entity=20 certificate is not defined in the definition clause. However it is = used=20 widely in the main text. It is mentioned the first time in clause 7 = as a=20 public-key certificate. There are several other places where it is a = public-key certificate. In 15.5.2.4 is used in the context of = attribute=20 certificates. The conclusion must be that an end-entity certificate = can=20 either be a end-entity public-key certificate or an end-entity = attribute=20 certificate. However, in most places, it is implied that we only = talks about=20 public-key certificates. For veterans, this is not a major problem, = but=20 new-comers may get confused. Anyway, I thing our specifications = should be=20 clear and not subject to interpretation. RFC 5280 does not use the = term at=20 all. It seems just to use the term =93certificate=94 as a synonym = for=20 =93end-entrity public key certificate=94.

The = =93User=20 Certificate=94 is not defined in X.509, but is wide used. It = seems to be=20 a synonym for =93end-entrity public key certificate=94. It is also = used in=20 X.511. RFC 5280 uses the term once without differenting it from just = =93certificate=94.

The term=20 =93cross-certificate=94 should probably also be = qualified.

I suggest = to add in=20 X.509 definitions for:

=93end-entity=20 public-key certificate=94

=93user = certificate=94 as=20 a synonym for =93end-entity public-key = certificate=94

=93end-entity attribute=20 certificate=94

The X.509 = text should=20 be updated to make use of these definitions.

X.509 has = four=20 attribute types for holding certificates.

UserCertificate: For=20 end-entity public-key certificates

cAcertificate: For CA=20 certificates

attributeCertificateAttribute: For end-entity attribute = certificates

aACertificate: For AA=20 Certificates

Any=20 comments?

Erik = Andersen

Andersen's=20 L-Service

Elsevej 48, DK-3500=20 Vaerloese

Denmark

Mobile: = +45 2097=20 1490

email:=20 era@x500.eu

www.x500.eu

www.x500standard.com

------_=_NextPart_002_01C9B928.DDECEF6D-- ------_=_NextPart_001_01C9B928.DDECEF6D Content-Type: image/gif; name="image001.gif" Content-Transfer-Encoding: base64 Content-ID: <462263115@09042009-1BCF> Content-Description: image001.gif Content-Location: image001.gif R0lGODlh3wEPAXcAACH/C01TT0ZGSUNFOS4wGAAAAAxtc09QTVNPRkZJQ0U5LjAC8Zm0lgAsAAAA AN8BDwGAAAAA////Av+Mj6nL7Q+jnLRaBrLevPsPhuJIluKFpurKtu4Lx/JMK0CN59Ct9/4PDAqH RAOviEwdk8ym8wmNOpbSaoBqzWq33O4C60WCw+Sy+Twbo33qtfsNh7fjabr9ju/O8609/w8YGOMn aEFYiJio+LXoctgIGZn3KGlTeYkJSJl5xen5ubaZKQpaahpEepl6ytoqszqlIcFDKzvL5pqrKwSL UbtDlUEh3NO7e4zcYGz5JevRyWFku3E1bTuYnK3NsoxAnHBEXW0k3WkuTFtuvg7Tvf3e6q7u/aH+ e/N9YF0djQ3/DxBDHXDBfp3DN05funH5BgZ8GFCePYP4KJZbSI2YxoX//iB6fCdRWr59/A4e3OgM JY2QH1sKYhkIpsuZeGT+sUkz5xuck3T6NMWz5s+hnoLeMUo0aRWkdJgqfdrEqRyoVBNJ3Vk1a0xt V7V6xdE11NexTbmSPesmLBq1aNteYGsGrtu5EeSSsUs3bzMTfPv6/QsYhN7BdsSV6UA4MSLDaREr fty04VHHkCvruVbomeXNUDBH0sw59A/GnOqJPt3OMyvQqFsPk4yMtevZCmGDpEz7tOqWsnMTJv2z t++zwKkKHw5199jjyHMWp8u8eUTbik1LjweMOufo1yXZfp6bOd7uYDEr795bO/k4gtdnz3jefWPw 8pW1r88eN/7X/faH/7Lu3wTc+RdYgQYeiOB4TCTIYIMO6peVglxIKIYU6iVBISQZZrHhEB0uRdaH FpYiYhQlZmYWKCc+seJW2bSoA4wLhpjiJzJiSOOLJNbo1Y0VqsijVj4WMaRDseWYTJGvBBkhk5go yQuSRwKp43JOqnJlcrV9Fww5D1zoC5jQiCQmO+DsaJ83+jBzoTsYxXfmLVZO1EycdYmyETD0VEAd lO3YF45BdcbyQkNlJlQXknmiJM6bkqFTS6NLgAHfM45JCilofhYKaEWI9QNqpIzS802ln2IqKj+p MjJnQpCSeZGXgsbqap7zKAQrrRrJihBDFdmDJiO2DkvnqLWu6Wuuu/8yxKtJw1KqqKTK9vprmJ4C aKh16AD7aEqabeqILxdR9Oa4sH47qWnLbtvtq8KBmxaue6qqK6L0wkdQtvPKy6yr9i66G7zcWPvq sSYley+l6RIELLMj3VPtFNEyHOo5ze5Z8KwTTYPotv6e5CnC4QS7b8YWHZspschmbPA9vGbaskCt Ztueo1gAbGu+gRZM78eoXmuYwCsoTCrM6/6MatFb1rrPqtFY852UC34otApVgyU1kYcSSfIxVx+W pXdhK/X1Sl3vUnYYaS9JZZJZ67L2MGMnFfefbU/5Vd2c3u3127nonWiVec/dCOB9+O2K4V8SPpTi Q58NN+LY8Y225Iv/wakm5ZEv92DnnhdI4ueij05CgHrycsJ0AHZk+l1wlf536jk4HtrWbIzwJO5R tn5YibDfpDuOvLu+VvBxGd/Z8MRHFgKHyHOovNpX/46K7HFF74Xt/1lf6PNiYT8h7aquPov3ZYG/ hfaaPG/+TeinL/57JmD5vvOJ+0V//UvFrzP54/vvPv3trxLUE1D7piJAC9WtgN3j3vcS2JmqMXA0 B9QC/6ozIPg5MILN0wMEWQQhDd6neBuUWXn680EihDBGBixhYdqnvhbSJ4XFmOEr+lTBy3WwZyux IQ1nh7lBXCOHpZmgI3z4wxNS0IgvAmAfYoge0klxikhUBBWvKEXL/6mwejO8YOZkCMXAmUiLVoST F5FlwNGAqFVFmcMZveQ2NvZNc38jI+Tyh7ceMc6Ke/TJG+Vkoz7q5I9iLIognXPIlyRyJoTcwR0T Z0c6EnCRLmnk4iQ5ucEJzpCbFNKW/GC7XplpL4QQZRXb8McxqCdiYtwDEql1SkfOjE+UeNiXNDYo ft1JYpqLD89ec8tbiUuXu7ykJkcZKtKYCmj/u5UqvZVMY5kqV6N8Eik3pi2opSxn1VymN6eVMmrC UY/UBFhJ5CUtj5mMmNikVb9cJrKTBdISz4onysqVs26VE5ay0lW1uGnJ3SFzVR1T16/IZcv+pRNX rDwX0JY1z3mt0/9kpfpnO4l5H3Wmo10HxU1AUYFGdA5RP+ZEaEEYJlFTIiSh7oIW5U5lLmOJ7KK6 1Jc/ycHSjipDUTaA2Dkv6q556DNmi2Loy0KmsmrisaC+0qk9j8ZORm00UAezWUmSOk5PkolczVQa ziIlTHHii4caleo5g9a1h52KJNI6SVjJmpKl+UybIeNhVpvkhDDiApMUVFsklehBvsZIr0D4aGEp GcA4HjOPpUHsRwzLqogyFq+K5WRltXrZUTjWI5BlhmTnuFjQWnayVemsnUYrWsySdqmVk2NrP/ta cmbWmp2k7GonWdvSYnG3ngsdb3/LoCh2o4rkIS6hkpivNATxOsb/jcVywfdcFKBwPdM9YnRNd92h NXc72+UPYZuTXet+FzrhVUJ1W1deIY6XOOnlRnfDs94ntjdE703NfGsXX/XmlyjnFUN9LXPf2wWY bgPu4X9/s9/BFpiRB15ignukpP4KqcGoW/CEwSXhp1DYvxbW8IMxlOFBbjivI25c3ELMmxJz8MOc NRyKVXdiFUOkw66jcRFZbAUZp/anuVNmal8cEx3HY2Gn6A+O5bCzI2cPOKal5S9X48QbA1lDQVNy GYXMhwx6Z4W+vVaLp2wjMC9CzKPgchPNDGUyZwbNRVYziIELZwMpNM50nl/R6oznAuZ5zyUIUpND qlRIftHBbvbQ/5+zemgzJbpLTfSzozu56EWf9sePTpKkB01pSHPl0oCObaAzeVe4cTrUdcS0pyMt V1nyiR1uXK7NDqEGRusMkHIb2elWxiZa79TUm+u0qH3NS2Dua1BtOqmwIxvqWhqCyM7FWKyLaUxS CxrY9/P105gMTWaOz5nW+t9KndGzpKGV1zf7WU+3ue1LFUSq6N72OrxcHFkzFtViBau93s2xfoV7 2GhsK0Lr5U5bW3uk/bx3kpvlU2QyVWVFRbi1J33qTT9cJCHVVsC/zW9vM9zepPpkoyCucJwKXOMr 4yc0jE1Vhhv1qNWVd6YtPfGfarvfF7frQFEKVR5DNN4gv9maSv/lbpq/k6BbTfi6Vg6yaH96NSCP XcxJIlJbe8xgKeXWyVSSMIZyxOV3lbowse4soRr7ng2Dqjm72XQZonTWtxAVrO1G7TSuXWmBc7uA UvNJmrd85/tsaL3/bRFzX3UkPf84y88NR6dx818PnStdKa4crgu7ouV+a08zHsy9xf1O6778vXNp +TR1D4SB3bwKMyT5u1+T1wmzFLjDDU2br5r1ak81qb357bKmaprmjYqVH0f7028o9dA+U0LtVOWq Ojzs0i7k0h1J+ON/0d9lB/jUV/H785keKGm/tUQznlGT+52u7yV+ManK6nKj62LjZ3d6s8+e7jM9 +Kq+86Q8zy//jYr8+7KXrvxviTSmZlM5x0pH813wh0Dbl1ZWk3CMRycnt3JHl3UzpQT/J3oI44BE dXUY4VDm8nzHBXwf6FylBDJvJzf0Z15i8mqqNzsWOILOlC5qJXYbZ1beEoLNl3n1RncUxzTKB3s2 OF+ENXLLFno1VUvKhoJvgUv4V4SgVwPmN38KqCKuJFPv1ndeNnDbNE2KF079B2gh8UxamHuwNCq8 xzoiyDf0JnpMVnL6pkw+t08+CE/yhEoueGzTx1bV904BZyRo+FlqmEts+DJF5xk0Qxn6B4HJ1VTg AYVKeG7qxn6fR34d1ojcl4ShA4KCmH6FCIcYlXJWx39PtmtS/3iC/LZx+4dO4tSHo+aHbZR52KaB qFh1u1JRctiBMTOKOChdXJWIBHhUZNeKusaKgBgmbzVSUGOMxziDG1iDYGdCuriLMtiDzGh3NriK lRYbw4iNL5eN2xhxmtZo4HhZ2hiO4+iNvQaNmCiO83aOTreO3AiPaEOO5viO8shn97g6+KiP07WP /bhu/niPyAVEFNZeNvZCiRYgbLZsQoiA4dOQAmloWFZiBnk8DwmRNYRlO3hD8ZORF1lhFNltCvYZ IOmRCtaRL1hYenOSJalfJFk+D2mRAoaQAKaQXBSTn8c8N8mSBKOTKEliNeGSO/mSQSle+wMlKymU PElCHUKUG/85k3lTaCDUk8W3ZFMJQVpWlTJilT6ZlC25lQ30lXeoQE2ZQlh5F3cWGXYId0HXlZdo lsWzVZPAcbcTl22piI9IllNTk0uJFFG2k9GUlysWmB8ZFG+JXDskZWGpXCe5lxA5QompmF6JE4YZ HACJj51imXmGmZlZZ7k1GWd4iZLEiui4Y6SIWqEJW6U2W+komptVOFkymqbZWKs5bZ51W7FZm6XJ mqm5m6epmrcJm645Zj00ioTHNuHyjKNnQtphDPLwbCkZmfXnacipSk2InNdpm9QpM0fmnLk4WLKZ V555gzyIhYlHeYlXG7Y3MMl5OIpYnuQpV3V1jN3JnljziDr/d55bRJsMKHAmh2s49XP/OSa9qXSo +ZJ693UBaoX+MjJDuJ7IxkKe53UASqDYOZ3KuX6Zo4zo6W3g6Z0GKncZmp4FZzGECHRrqZYPOn1a tzM/clvtyWhVqIwTKnQWCqKqF6P29no0Woge+qE++haRhX4yBzNqtJ8VqHwas3VWKHUbBaTZeaOX FHgJSqE8yqBPCqVYemxLSqKmpJ8vmoItejD9lp9wdXCal6XalZ+4lG97OIiqqKIp6l4nyoN1OpjB SFu02SJs8ZxHaol6ehk62adg+qfAKZ64CWq6iad5mqa5SZoXWqGMKqea5adhKidi6nxmU5/yRYL4 hoY8Maj2/0WCn6hrTyie2mV6NlU+xfCj7pWqY7eqEQqhR/SqmAeCLVipQboXhHhyGzp4zoimkyqd I2op9zKiv1pXx9moVrOrGgdvxxp7PIaij2qjTLqBJcqBH7OowbasSIp8uCiB2Xp9fRilBdqgpBqu Bcd3ygqpcRqX6DeHiMc0+RWq1fo0qegz8tpuoKmlUHqvEZitHTevYHiqzJqd8Apw/wlR5NqvPYd8 5VKiCitKmjqr7YlpC3N1cSJPFKuoqBqJCOum4rqx1RqpOTilZSeu6mpR7FqumXilAKuuKtsw/Oqo YCmwGHtxBAWsJLutABiD44SIYpp8NlavRQmfN7t1MrWzPD4bhYYKqAVbqIqKqIjatFIbnFD7SIna smKzqTXrtV87tcLJR4d6tbnKm2BbtoTaZZzZmTzJtnC2mW8LXFtQAAA7 ------_=_NextPart_001_01C9B928.DDECEF6D-- From owner-ietf-pkix@mail.imc.org Thu Apr 9 08:59:05 2009 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AF4F3A6BAF for ; Thu, 9 Apr 2009 08:59:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.405 X-Spam-Level: ** X-Spam-Status: No, score=2.405 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_40=-0.185, HELO_EQ_DK=1.009, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.134, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bkpYEHi1B3CL for ; Thu, 9 Apr 2009 08:58:56 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 31DC83A6CB3 for ; Thu, 9 Apr 2009 08:58:54 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n39FQ0xa025396 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Apr 2009 08:26:00 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n39FQ03j025395; Thu, 9 Apr 2009 08:26:00 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail02.dandomain.dk (mail02.dandomain.dk [194.150.112.202]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n39FPkJK025382 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 9 Apr 2009 08:25:58 -0700 (MST) (envelope-from era@x500.eu) Received: from ERA1 ([95.209.182.175]) by mail02.dandomain.dk (DanDomain Mailserver) with ASMTP id QTI80738; Thu, 09 Apr 2009 17:25:38 +0200 From: "Erik Andersen" To: , "'ietf-pkix'" Subject: RE: [x500standard] Re: Certificate definitions Date: Thu, 9 Apr 2009 17:25:37 +0200 Message-ID: <7B01F815F4064ABEB6447E403CA12C56@ERA1> MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0000_01C9B938.35920940" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6838 Importance: Normal Thread-Index: Acm0cXogl35R6fnrRR6btIokFjzPxQErLQOw In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C9B938.35920940 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_01C9B938.35920940" ------=_NextPart_001_0001_01C9B938.35920940 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Denis, =20 It is a little dangerous not to respond to my comments. Due to the = apparent inactivity of people, I have the power to produce Defect Reports, = produce Draft Technical Corrigenda, run them through both the ISO and ITU-T = approval process and finally integrate them into the next edition of X.500 (incl. X.509) without being stopped by anyone (except for Jean-Paul Lemaire). =20 I believe you misunderstood my diagram. It may be a little confusing. = Let me express myself without the diagram. =20 The set of certificates is the union of the set of public-key = certificates and the set of attribute certificates. =20 The set of end-entity certificates is the union of public-key = certificates issued to end-entities and the set of attribute certificates issued to end-entities. However, X.509 is a little confusing here as the term end-entity certificate is sometimes meant to be just public-key = certificates issued to end-entities, so the term end-entity certificate has two = meanings. =20 The set of public-key certificates is the union of the set of end-entity (public-key) certificates and the set of CA certificates. =20 The set of attribute certificates is the union of the set of end-entity (attribute) certificates and the set of AA certificates. =20 The set of authority certificates is the union of the set CA = certificates and the set of AA certificates. =20 The set of CA certificates is the union of the set of self-issued (public-key) certificates and the set cross certificates. The latter is = a little confusing, as a cross certificate can also be an attribute certificate. =20 I am avoiding here to use the term =93user attribute=94, but believe it = is supposed to mean a public-key certificate issued to an end-entity. =20 Whenever an innocent reader sees the term =93certificate=94, he/she is = entitled to believe it can either be a public-key certificate. It may not always = be clear from the context what is meant. =20 Whenever an innocent us reader see the term =93end-entity = certificate=94, he/she is entitled to believe it is either a public key certificate or = an attribute certificate issued to an end-entity. =20 Whenever an innocent us reader see the term =93cross-certificate=94, = he/she is entitled to believe it is either a public key certificate or an = attribute certificate. =20 My proposal was only to clear-up the terminology and to use the = terminology consistent in the text of X.509. Trying to do the latter may raise a = number of detailed questions when the meaning is not absolutely clear from the context. =20 =20 Erik Andersen Andersen's L-Service Elsevej 48, DK-3500 Vaerloese Denmark Mobile: +45 2097 1490 email: era@x500.eu www.x500.eu www.x500standard.com =20 -----Original Message----- From: x500standard-bounce@freelists.org [mailto:x500standard-bounce@freelists.org] On Behalf Of Denis Pinkas Sent: 3. april 2009 17:33 To: x500 list; ietf-pkix Subject: [x500standard] Re: Certificate definitions =20 Eric, =20 Silence does not mean approval. =20 It may mean that the corrections are so numerous that it would take too = long to respond and that people do not have that time available at the moment. =20 e.g.: an End-entity attribute certificate is not linked to a public-key certificate. a cross-certificate is not linked to an AA certificate. an Authority Certificate is not linked to an Attribute = Certificate. =20 This is only a start ... =20 Denis ----- Message re=E7u -----=20 De : owner-ietf-pkix=20 =C0 : x500standard,'PKIX'=20 Date : 2009-04-03, 17:00:01 Sujet : RE: [x500standard] Certificate definitions =20 I take silence as approval. =20 Erik Andersen Andersen's L-Service Elsevej 48, DK-3500 Vaerloese Denmark Mobile: +45 2097 1490 email: era@x500.eu www.x500.eu www.x500standard.com =20 -----Original Message----- From: x500standard-bounce@freelists.org [mailto:x500standard-bounce@freelists.org] On Behalf Of Erik Andersen Sent: 1. april 2009 14:40 To: Directory list; PKIX Subject: [x500standard] Certificate definitions =20 Hi =20 I got a number of responses on user certificates, but quite little that actually answered my question. =20 I have tried to dig a little bit more in X.509 to get hold of the terminology and then produced below figure. I will not comment all the boxes. =20 =20 I will like you to comments as to the correctness of above figure. =20 The end-entity certificate is not defined in the definition clause. = However it is used widely in the main text. It is mentioned the first time in = clause 7 as a public-key certificate. There are several other places where it = is a public-key certificate. In 15.5.2.4 is used in the context of attribute certificates. The conclusion must be that an end-entity certificate can either be a end-entity public-key certificate or an end-entity attribute certificate. However, in most places, it is implied that we only talks = about public-key certificates. For veterans, this is not a major problem, but new-comers may get confused. Anyway, I thing our specifications should = be clear and not subject to interpretation. RFC 5280 does not use the term = at all. It seems just to use the term =93certificate=94 as a synonym for =93end-entrity public key certificate=94. =20 The =93User Certificate=94 is not defined in X.509, but is wide used. = It seems to be a synonym for =93end-entrity public key certificate=94. It is also = used in X.511. RFC 5280 uses the term once without differenting it from just =93certificate=94. =20 The term =93cross-certificate=94 should probably also be qualified. =20 I suggest to add in X.509 definitions for: =20 =93end-entity public-key certificate=94 =93user certificate=94 as a synonym for =93end-entity public-key = certificate=94 =93end-entity attribute certificate=94 =20 The X.509 text should be updated to make use of these definitions. =20 X.509 has four attribute types for holding certificates. =20 UserCertificate: For end-entity public-key certificates cAcertificate: For CA certificates attributeCertificateAttribute: For end-entity attribute certificates aACertificate: For AA Certificates =20 Any comments? =20 Erik Andersen Andersen's L-Service Elsevej 48, DK-3500 Vaerloese Denmark Mobile: +45 2097 1490 email: era@x500.eu www.x500.eu www.x500standard.com =20 ------=_NextPart_001_0001_01C9B938.35920940 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi = Denis,

It is a little = dangerous not to respond to my comments. Due to the apparent inactivity of people, = I have the power to produce Defect Reports, produce Draft Technical Corrigenda, = run them through both the ISO and ITU-T approval process and finally = integrate them into the next edition of X.500 (incl. X.509) without being stopped by = anyone (except for Jean-Paul = Lemaire).

I believe you = misunderstood my diagram. It may be a little confusing. Let me express myself without = the diagram.

The set of = certificates is the union of the set of public-key certificates and the set of = attribute certificates.

The set of = end-entity certificates is the union of public-key certificates issued to end-entities and the = set of attribute certificates issued to end-entities. However, X.509 is a = little confusing here as the term end-entity certificate is sometimes meant to = be just public-key certificates issued to end-entities, so the term end-entity certificate has two meanings.

The set of = public-key certificates is the union of the set of end-entity (public-key) = certificates and the set of CA certificates.

The set of = attribute certificates is the union of the set of end-entity (attribute) = certificates and the set of AA certificates.

The set of = authority certificates is the union of the set CA certificates and the set of AA certificates.

The set of CA certificates is the union of the set of self-issued (public-key) = certificates and the set cross certificates. The latter is a little confusing, as a = cross certificate can also be an attribute certificate.

I am avoiding = here to use the term “user attribute”, but believe it is supposed to = mean a public-key certificate issued to an end-entity.

Whenever an = innocent reader sees the term “certificate”, he/she is entitled to believe = it can either be a public-key certificate. It may not always be clear from the = context what is meant.

Whenever an = innocent us =A0reader see the term “end-entity certificate”, he/she is entitled to believe it is either a public key certificate or an attribute = certificate issued to an end-entity.

Whenever an = innocent us =A0reader see the term “cross-certificate”, he/she is entitled to = believe it is either a public key certificate or an attribute = certificate.

My proposal was = only to clear-up the terminology and to use the terminology consistent in the text of = X.509. Trying to do the latter may raise a number of detailed questions when the = meaning is not absolutely clear from the context. =A0

Erik = Andersen

Andersen's = L-Service

Elsevej 48, = DK-3500 Vaerloese

Denmark

Mobile: +45 2097 = 1490

email: era@x500.eu

www.x500.eu

www.x500standard.= com

-----Original Message-----
From: x500standard-bounce@freelists.org = [mailto:x500standard-bounce@freelists.org] On Behalf Of Denis Pinkas
Sent: 3. april 2009 = 17:33
To: x500 list; = ietf-pkix
Subject: [x500standard] = Re: Certificate definitions

Eric,

Silence does = not mean approval.

It may = mean that the corrections are so numerous that it would take too long to = respond

and that = people do not have that time available at the moment.

e.g.: = an End-entity attribute certificate is not linked to a public-key = certificate.

&nb= sp; a cross-certificate is not linked to an AA = certificate.

&nb= sp; an Authority Certificate is not linked to an Attribute = Certificate.

This is = only a start ...

Denis

----- Message = re=E7u -----

De : = owner-ietf-pkix

=C0 = : x500standard,'PKIX' =

Date = : 2009-04-03, 17:00:01

Sujet = : RE: [x500standard] Certificate definitions

I take silence as approval.

Erik Andersen

Andersen's L-Service

Elsevej 48, DK-3500 Vaerloese

Denmark

Mobile: +45 2097 1490

email: era@x500.eu

www.x500.eu

www.x500standard.com

-----Original Message-----
From: x500standard-bounce@freelists.org = [mailto:x500standard-bounce@freelists.org] On Behalf Of Erik Andersen
Sent: 1. april 2009 = 14:40
To: Directory list; = PKIX
Subject: [x500standard] Certificate definitions

Hi

I got a number = of responses on user certificates, but quite little that actually answered = my question.

I have tried = to dig a little bit more in X.509 to get hold of the terminology and then = produced below figure. I will not comment all the boxes.

I will like = you to comments as to the correctness of above figure.

The end-entity certificate is not defined in the definition clause. However it is used = widely in the main text. It is mentioned the first time in clause 7 as a = public-key certificate. There are several other places where it is a public-key certificate. In 15.5.2.4 is used in the context of attribute = certificates. The conclusion must be that an end-entity certificate can either be a = end-entity public-key certificate or an end-entity attribute certificate. However, = in most places, it is implied that we only talks about public-key certificates. = For veterans, this is not a major problem, but new-comers may get confused. = Anyway, I thing our specifications should be clear and not subject to = interpretation. RFC 5280 does not use the term at all. It seems just to use the term “certificate” as a synonym for “end-entrity public key certificate”.

The = “User Certificate” is not defined in X.509, but is wide used. It = seems to be a synonym for “end-entrity public key certificate”. It is = also used in X.511. RFC 5280 uses the term once without differenting it from = just “certificate”.

The term = “cross-certificate” should probably also be qualified.

I suggest to = add in X.509 definitions for:

“end-entity public-key certificate”

“user = certificate” as a synonym for “end-entity public-key = certificate”

“end-entity attribute certificate”

The X.509 text = should be updated to make use of these definitions.

X.509 has four = attribute types for holding certificates.

UserCertificate: For end-entity public-key certificates

cAcertificate: = For CA certificates

attributeCertificateAttribut= e: For end-entity attribute certificates

aACertificate: = For AA Certificates

Any = comments?

Erik = Andersen

Andersen's = L-Service

Elsevej 48, DK-3500 = Vaerloese

Denmark

Mobile: +45 = 2097 1490

email: = era@x500.eu
www.x500.eu
www.x500standard.com<= /font>

[Santosh]: The above paragraph has two inaccuracies. Since not all CA certificates are called cross certificates, set of CA certificates are self-issued, cross certificate, and subordinate CA certificates. (I wish we had not distinguished between cross certificates and subordinate CA certificates in the first place). Also note that a cross certificate can not be attribute certificate. I don't see an AA cross certificate in RFC 3281 or in X.509

Santosh,

RFC 5280 says that "Cross-certificates are CA certificates in which the issuer and subject are different entities."

X.509 defines a cross-certificate as "A public-key or attribute certificate where the issuer and the subject/holder are different CAs or AAs respectively. CAs and AAs issue cross-certificates to other CAs or AAs respectively as a mechanism to authorize the subject CA's existence (e.g., in a strict hierarchy) or to recognize the existence of the subject CA or holder AA (e.g., in a distributed trust model). The cross-certificate structure is used for both of these."

So, every CA certificate is either self-issued or a cross-certificate.

I know that a lot of people seem to think that a certificate issued in a hierarchy by a hierarchically superior CA to a subordinate CA is not a "cross-certificate", that belief is not consistent with either X.509 or RFC 5280. (Perhaps people are simply guessing the meaning of "cross-certificate", and the inclusion of "cross" in the name leads them to guess that the term does not incorporate certificates issued to subordinate CAs.) If documents are being created that use the term "cross-certificate" to mean only CA certificates that are neither self-issued nor issued to a subordinate CA, then they are creating confusion by misusing the term.

Dave

From owner-ietf-pkix@mail.imc.org Thu Apr 9 09:43:40 2009 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D01A3A69B1 for ; Thu, 9 Apr 2009 09:43:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.38 X-Spam-Level: X-Spam-Status: No, score=-1.38 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sAGeZVeGO603 for ; Thu, 9 Apr 2009 09:43:39 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 39E013A6856 for ; Thu, 9 Apr 2009 09:43:38 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n39GGOKn028935 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Apr 2009 09:16:24 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n39GGOLr028934; Thu, 9 Apr 2009 09:16:24 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n39GGNkE028928 for ; Thu, 9 Apr 2009 09:16:23 -0700 (MST) (envelope-from SChokhani@cygnacom.com) Received: (qmail 21115 invoked from network); 9 Apr 2009 16:15:08 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 9 Apr 2009 16:15:07 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9B92E.85ED62AC" X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [x500standard] Re: Certificate definitions Date: Thu, 9 Apr 2009 12:16:21 -0400 Message-ID: In-Reply-To: <49DE1DAF.2000307@nist.gov> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [x500standard] Re: Certificate definitions Thread-Index: Acm5LZm+5dIHybYeQIyTtW4kxKHJXQAAMztA References: <7B01F815F4064ABEB6447E403CA12C56@ERA1> <49DE1DAF.2000307@nist.gov> From: "Santosh Chokhani" To: Cc: "ietf-pkix" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------_=_NextPart_001_01C9B92E.85ED62AC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable David, =20 We agree. That is why my parenthetical remark. ________________________________ From: x500standard-bounce@freelists.org [mailto:x500standard-bounce@freelists.org] On Behalf Of David A. Cooper Sent: Thursday, April 09, 2009 12:09 PM To: x500standard@freelists.org Cc: ietf-pkix Subject: [x500standard] Re: Certificate definitions =09 =09 Santosh Chokhani wrote:=20 [Santosh]: The above paragraph has two inaccuracies. Since not all CA certificates are called cross certificates, set of CA certificates are self-issued, cross certificate, and subordinate CA certificates. (I wish we had not distinguished between cross certificates and subordinate CA certificates in the first place). Also note that a cross certificate can not be attribute certificate. I don't see an AA cross certificate in RFC 3281 or in X.509 =09 Santosh, =09 RFC 5280 says that "Cross-certificates are CA certificates in which the issuer and subject are different entities." =09 X.509 defines a cross-certificate as "A public-key or attribute certificate where the issuer and the subject/holder are different CAs or AAs respectively. CAs and AAs issue cross-certificates to other CAs or AAs respectively as a mechanism to authorize the subject CA's existence (e.g., in a strict hierarchy) or to recognize the existence of the subject CA or holder AA (e.g., in a distributed trust model). The cross-certificate structure is used for both of these." =09 So, every CA certificate is either self-issued or a cross-certificate. =09 I know that a lot of people seem to think that a certificate issued in a hierarchy by a hierarchically superior CA to a subordinate CA is not a "cross-certificate", that belief is not consistent with either X.509 or RFC 5280. (Perhaps people are simply guessing the meaning of "cross-certificate", and the inclusion of "cross" in the name leads them to guess that the term does not incorporate certificates issued to subordinate CAs.) If documents are being created that use the term "cross-certificate" to mean only CA certificates that are neither self-issued nor issued to a subordinate CA, then they are creating confusion by misusing the term. =09 Dave =09 ----- www.x500standard.com: The central source for information on the X.500 Directory Standard.=20 ------_=_NextPart_001_01C9B92E.85ED62AC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

David,

We agree. That is why my parenthetical=20 remark.

From: = x500standard-bounce@freelists.org=20 [mailto:x500standard-bounce@freelists.org] On Behalf Of David = A.=20 Cooper
Sent: Thursday, April 09, 2009 12:09 PM
To: = x500standard@freelists.org
Cc: ietf-pkix
Subject:=20 [x500standard] Re: Certificate definitions

Santosh Chokhani wrote:=20

[Santosh]: The = above=20 paragraph has two inaccuracies. Since not all CA = certificates=20 are called cross certificates, set of CA certificates are=20 self-issued, cross certificate, and subordinate CA=20 certificates. (I wish we had not distinguished between cross = certificates and subordinate CA certificates in the first=20 place). Also note that a cross certificate can not be = attribute=20 certificate. I don't see an AA cross certificate in RFC 3281 = or in=20 = X.509

It is indeed true that=20 the write-up refers to out-dated RFCs but = since <keygen>=20 was designed ages ago that is sort of aligned with the = rest of=20 the scheme as well :-)

IMO it doesn't really matter if = <keygen> gets=20 standardized or not, it will anyway be obviated by other solutions since = <keygen> doesn't support even the most basic security features = needed,=20 like giving the issuer an indication whether keys are stored in the file system, or are generated and stored in a = secure=20 container like a smart card. The technique for doing that = (container attestations) has been known for a decade or more, = and since=20 trusted HW is already a part of high-end mobile devices, it seems pretty = short-sighted not to make use of it.

BTW, <keygen> and its = numerous=20 cousins are actually much more important for mobile devices = than for=20 PCs, since for the latter we already have physical token distribution=20 (PIV/CAC/eID etc), which I believe is the main reason why the state of = on-line=20 key-generation doesn't exactly top the agendas of W3C, OASIS, or the IETF. One may argue that = SIM-cards=20 already have what it takes, but then = you probably=20 haven't tried it in practice :-)

Anders

----- Original = Message=20 -----
From: "Stefan Santesson" <stefan@aaa-sec.com>
To: "Anders=20 Rundgren" <anders.rundgren@telia.com>;=20 <ietf-pkix@imc.org>
Sent:=20 Wednesday, April 08, 2009 00:30
Subject: Re: <keygen> - An = HTML5=20 standard facility?

I find it a bit remarkable that they = reference RFC=20 2459 for algorithm
identifier OIDs

Quote:
"3. Let algorithm = be an=20 ASN.1 AlgorithmIdentifier structure as defined by
RFC2459, with the = algorithm=20 field giving the ASN.1 OID used to identify
signature algorithm, = using the=20 OIDs defined in section 7.2 ("Signature
Algorithms") of RFC2459, and = the=20 parameters field set up as required by
RFC2459 for = AlgorithmIdentifier=20 structures for that algorithm. [X690]
[RFC2459]"

It's a tiny = bit more=20 than slightly outdated...

/Stefan

On 4/7/09 10:13 PM, = "Anders=20 Rundgren" <anders.rundgren@telia.com>=20 wrote:

>
> http://www.whatwg.org/specs/web-apps/current-work/#the-keygen-el= ement
>
> Since the PKI community at large = seems to ignore=20 the client-side of
> PKI in browsers, the HTML 5 designers = apparently=20 didn't find any other
> solution but adopting the 15 year old = Netscape=20 hack known as <keygen>.
>
> It is indeed as said in = this list=20 very simple to use etc. However,
> does it really match the = needs of=20 today?
>
> My guess FWIW, is that the serious users of = on-line=20 provisioning of PKI
> which includes governments and banks in the = EU, as=20 well as the USPTO
> will continue to use entirely proprietary = solutions=20 (mostly using Java), since
> the browser-schemes are = all-over-the-map and=20 do not do signatures either.
>
> A few things to = consider:
>=20
> How could a static tag in a page mark-up language match an = API
>=20 or a protocol?
>
> Algorithm agility, isn't that a = requirement=20 these days?
>
> PIN-codes anybody?
>
> TPM - A = dead=20 duck?
>
> Anders
> =

------=_NextPart_000_0222_01C9B96C.0392F920-- From owner-ietf-pkix@mail.imc.org Thu Apr 9 16:18:51 2009 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EF373A6AE2 for ; Thu, 9 Apr 2009 16:18:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1XAC8TJmSEFc for ; Thu, 9 Apr 2009 16:18:50 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 15EA03A6358 for ; Thu, 9 Apr 2009 16:18:49 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n39MxOJt051675 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Apr 2009 15:59:24 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n39MxOSM051674; Thu, 9 Apr 2009 15:59:24 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp109.biz.mail.re2.yahoo.com (smtp109.biz.mail.re2.yahoo.com [206.190.53.8]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n39MxDQ3051658 for ; Thu, 9 Apr 2009 15:59:23 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 85969 invoked from network); 9 Apr 2009 22:59:12 -0000 Received: from unknown (HELO thunderfish.local) (turners@71.191.14.4 with plain) by smtp109.biz.mail.re2.yahoo.com with SMTP; 9 Apr 2009 22:59:12 -0000 X-Yahoo-SMTP: qPTWNAeswBAtDTSn9GKlmmL3C90ke7grn_5n9To- X-YMail-OSG: WwefH1kVM1msCUJ3k0N5Isro3B4ZvBaNxNxVzPpw2rX.tbem7tasco2XJqq_1uRXeG2EL4CV5z35Cd6Ll9Uzz0IxK3fiXq1eRv6Aem6c9OhCVcW2tQWL4GEASj32Ko4nV5KsFWEMJYZ3YaLn5cey1Ca5YzarhWngN4Wx.X0CE61Uf9d_aTX_LrnJ6FKWX3VfojBwYVjzRkzsNE3k9lUqjMYYfFSYBAntBh86JHnKAl4WpDx9XHisTCXArolnUmdCJ9OtHNQm7RK3dCQieDDEuKQP1QdYvFu1yDkAJnk16.clO_t1X0b. X-Yahoo-Newman-Property: ymail-3 Message-ID: <49DE7DC0.8050501@ieca.com> Date: Thu, 09 Apr 2009 18:59:12 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: pkix Subject: PRQP: CMS Gateway Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Max, Should the CMS Gateway be renamed CMC Gateway? CMM over CMS is CMC. Also should the reference be updated to RFC 5272? spt From owner-ietf-pkix@mail.imc.org Fri Apr 10 12:40:29 2009 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1744F3A6973 for ; Fri, 10 Apr 2009 12:40:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.472 X-Spam-Level: X-Spam-Status: No, score=-2.472 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iQa57Hzo9bUM for ; Fri, 10 Apr 2009 12:40:28 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id B0DDD3A6853 for ; Fri, 10 Apr 2009 12:40:27 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3AJBE1U029595 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Apr 2009 12:11:14 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3AJBEqO029594; Fri, 10 Apr 2009 12:11:14 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp102.biz.mail.re2.yahoo.com (smtp102.biz.mail.re2.yahoo.com [68.142.229.216]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n3AJB1cn029571 for ; Fri, 10 Apr 2009 12:11:11 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 53985 invoked from network); 10 Apr 2009 19:11:00 -0000 Received: from unknown (HELO thunderfish.local) (turners@96.231.117.245 with plain) by smtp102.biz.mail.re2.yahoo.com with SMTP; 10 Apr 2009 19:11:00 -0000 X-Yahoo-SMTP: qPTWNAeswBAtDTSn9GKlmmL3C90ke7grn_5n9To- X-YMail-OSG: dXsNavoVM1kbwapkdXuu_ux9kCzni.YUjnczK8muSQqwn0vUEjLvcxnSMj3q0OPDTj2FC2Bb0jNzJFIjMfSfXXxyhzcHIynwqNflz9rT16GA1AEGvhdKmVSLEWEkwpCXAakOJXF9AFYPe4NQ6zkF_s6u96pecau4sMWNpXVHJBeC6DgoDpmMfyShlPXX3pxhuLnVF3CG3R4y1YUZf4oEReS2lt9z2YJ.GJKu5272NVp1mGGsuaV0tycEXueS_qcoFxLbJYKSHX651FLIku_4DFJaiNFreOI6nm6GeGyzCLbYKArcrOULUW3jUzCjHczTyPBNbcXAzGooVFC36yloltnL2g-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49DF99C4.5000205@ieca.com> Date: Fri, 10 Apr 2009 15:11:00 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: McCann Peter-A001034 CC: gen-art@ietf.org, draft-ietf-pkix-3281update@tools.ietf.org, pkix-chairs@tools.ietf.org, pkix-ads@tools.ietf.org, ietf-pkix@imc.org Subject: Re: Gen-ART Review of draft-ietf-pkix-3281update-04 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Pete, I'll expand the acronym and fix the spelling during AUTH48. spt McCann Peter-A001034 wrote: > I have been selected as the General Area Review Team (Gen-ART) reviewer > for this draft (for background on Gen-ART, please see > http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). > > Please resolve these comments along with any other Last Call comments > you may receive. > > Document: draft-ietf-pkix-3281update-04 > Reviewer: Pete McCann > Review Date: 10 April 2009 > IETF LC End Date: 10 April 2009 > IESG Telechat date: unknown > > Summary: Ready for publication as a Proposed Standard > > Major issues: > > > Minor issues: > > Section 4.2.8: > this field SHOULD NOT be used by conforming CAs > I assume CA is Certificate Authority that issued the AC issuer's PKC, > but this acronym isn't expanded in the terminology section. > > > Nits/editorial comments: > > Section 7.1: > content type carried withing the ciphertext. > SHOULD BE: > content type carried within the ciphertext. > > From owner-ietf-pkix@mail.imc.org Fri Apr 10 13:12:36 2009 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E05683A680C for ; Fri, 10 Apr 2009 13:12:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kp+nXyP1fkRb for ; Fri, 10 Apr 2009 13:12:36 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 857263A63EB for ; Fri, 10 Apr 2009 13:12:35 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3AJlOTG031818 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Apr 2009 12:47:24 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3AJlO4v031817; Fri, 10 Apr 2009 12:47:24 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail.cs.dartmouth.edu (mail.cs.dartmouth.edu [129.170.212.100]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3AJlCXS031793 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 10 Apr 2009 12:47:23 -0700 (MST) (envelope-from Massimiliano.Pala@Dartmouth.edu) Received: from titan.cs.dartmouth.edu (mm.cs.dartmouth.edu [129.170.214.89]) (authenticated bits=0) by mail.cs.dartmouth.edu (8.14.2/8.14.2) with ESMTP id n3AJl6IH021306 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 10 Apr 2009 15:47:08 -0400 Message-ID: <49DFA346.309@Dartmouth.edu> Date: Fri, 10 Apr 2009 15:51:34 -0400 From: Massimiliano Pala Organization: Dartmouth College - Computer Science Department User-Agent: Thunderbird 2.0.0.16 (X11/20080707) MIME-Version: 1.0 To: Sean Turner CC: pkix Subject: Re: PRQP: CMS Gateway References: <49DE7DC0.8050501@ieca.com> In-Reply-To: <49DE7DC0.8050501@ieca.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060001020207000203080301" X-Virus-Scanned: ClamAV 0.93.3/9223/Fri Apr 10 10:54:59 2009 on mail.cs.dartmouth.edu X-Virus-Status: Clean Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms060001020207000203080301 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Sean, thanks for the comments - I just modified the current draft version with the suggested changes. There are still some changes to be done for providing TAMP support via PRQP - but I think we will finalize them next week (I shall meet with Wallace at IDTrust) and we will be ready for updating the draft. Ciao, Max Sean Turner wrote: > > Max, > > Should the CMS Gateway be renamed CMC Gateway? CMM over CMS is CMC. > Also should the reference be updated to RFC 5272? --------------ms060001020207000203080301 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJIjCC BI0wggN1oAMCAQICAhpTMA0GCSqGSIb3DQEBBQUAMHcxEzARBgoJkiaJk/IsZAEZFgNlZHUx GTAXBgoJkiaJk/IsZAEZFglkYXJ0bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0 bW91dGggQ29sbGVnZTEcMBoGA1UEAxMTRGFydG1vdXRoIENlcnRBdXRoMTAeFw0wNTExMDgy MDMzMDZaFw0wOTExMDkyMDMzMDZaMIHBMRMwEQYKCZImiZPyLGQBGRYDZWR1MRkwFwYKCZIm iZPyLGQBGRYJZGFydG1vdXRoMQswCQYDVQQGEwJVUzEaMBgGA1UEChMRRGFydG1vdXRoIENv bGxlZ2UxGjAYBgoJkiaJk/IsZAEBEwoxMjI1NjAyOTQ3MRowGAYDVQQDExFNYXNzaW1pbGlh bm8gUGFsYTEuMCwGCSqGSIb3DQEJARYfTWFzc2ltaWxpYW5vLlBhbGFARGFydG1vdXRoLmVk dTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAsv8obBpbhPixgdyIJj7UN0GYRNhsgWHB muCE5j8v8IvCSJWRF9spKoR0NBYgOfJu8DwQuKTIgrvbp0EC3ikrneotL4KTGD1IqWz/bSXL UR/bZAsc0r9PrvCUsZOi7wbijy784gOuqQUCJ2fJwKwk5SJ3RBaPnUROQXTp+LPSK8MCAwEA AaOCAVowggFWMA4GA1UdDwEB/wQEAwIF4DARBglghkgBhvhCAQEEBAMCBaAwgaIGA1UdIASB mjCBlzCBlAYKKwYBBAFBAgEBATCBhTA9BggrBgEFBQcCAjAxMBgWEURhcnRtb3V0aCBDb2xs ZWdlMAMCAQEaFURhcnRtb3V0aCBDb2xsZWdlIENQUzBEBggrBgEFBQcCARY4aHR0cDovL3d3 dy5kYXJ0bW91dGguZWR1L35wa2lsYWIvRGFydG1vdXRoQ1BTXzRTZXAwMy5wZGYwKgYDVR0R BCMwIYEfTWFzc2ltaWxpYW5vLlBhbGFARGFydG1vdXRoLmVkdTAfBgNVHSMEGDAWgBQ/wNbH p08Afu8GmWdsvJYeTaN3EjA/BggrBgEFBQcBAQQzMDEwLwYIKwYBBQUHMAGGI2h0dHA6Ly9j b2xsZWdlY2EuZGFydG1vdXRoLmVkdS9vY3NwMA0GCSqGSIb3DQEBBQUAA4IBAQDEYIWmG3Ht wcgFiBbrYKp7YpI62hgAw9I3Dj9Ai+etQcMDZL8cWg3Kd7DwYHDkLxO7jl518HIJCk8Elk+Z 3Y2c0rR+c9WLuxE+EHEUmQg2AbgxzRGZAeMXj7jrv5w75IWiXBrW3SdDkjVH6MQFZVP1CBk7 PF3/+dzmiO6E5g4cVtphPSdK2qtnX7Sh0zdePzeE+e0BTnsWdN0yHgKabKx3dCiEnQXt96sA Jf5ckg7fFLcplohwWlWJCpk8WwnJM0QGw3xbrZvLk+kIQgyh0sn2va4FgA1ae29cJ1d2NurA Z+LMdei9/ZbzBeMoD9XPSYyj7zLuVXGLF/JQQoPywk5oMIIEjTCCA3WgAwIBAgICGlMwDQYJ KoZIhvcNAQEFBQAwdzETMBEGCgmSJomT8ixkARkWA2VkdTEZMBcGCgmSJomT8ixkARkWCWRh cnRtb3V0aDELMAkGA1UEBhMCVVMxGjAYBgNVBAoTEURhcnRtb3V0aCBDb2xsZWdlMRwwGgYD VQQDExNEYXJ0bW91dGggQ2VydEF1dGgxMB4XDTA1MTEwODIwMzMwNloXDTA5MTEwOTIwMzMw NlowgcExEzARBgoJkiaJk/IsZAEZFgNlZHUxGTAXBgoJkiaJk/IsZAEZFglkYXJ0bW91dGgx CzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91dGggQ29sbGVnZTEaMBgGCgmSJomT8ixk AQETCjEyMjU2MDI5NDcxGjAYBgNVBAMTEU1hc3NpbWlsaWFubyBQYWxhMS4wLAYJKoZIhvcN AQkBFh9NYXNzaW1pbGlhbm8uUGFsYUBEYXJ0bW91dGguZWR1MIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQCy/yhsGluE+LGB3IgmPtQ3QZhE2GyBYcGa4ITmPy/wi8JIlZEX2ykqhHQ0 FiA58m7wPBC4pMiCu9unQQLeKSud6i0vgpMYPUipbP9tJctRH9tkCxzSv0+u8JSxk6LvBuKP LvziA66pBQInZ8nArCTlIndEFo+dRE5BdOn4s9IrwwIDAQABo4IBWjCCAVYwDgYDVR0PAQH/ BAQDAgXgMBEGCWCGSAGG+EIBAQQEAwIFoDCBogYDVR0gBIGaMIGXMIGUBgorBgEEAUECAQEB MIGFMD0GCCsGAQUFBwICMDEwGBYRRGFydG1vdXRoIENvbGxlZ2UwAwIBARoVRGFydG1vdXRo IENvbGxlZ2UgQ1BTMEQGCCsGAQUFBwIBFjhodHRwOi8vd3d3LmRhcnRtb3V0aC5lZHUvfnBr aWxhYi9EYXJ0bW91dGhDUFNfNFNlcDAzLnBkZjAqBgNVHREEIzAhgR9NYXNzaW1pbGlhbm8u UGFsYUBEYXJ0bW91dGguZWR1MB8GA1UdIwQYMBaAFD/A1senTwB+7waZZ2y8lh5No3cSMD8G CCsGAQUFBwEBBDMwMTAvBggrBgEFBQcwAYYjaHR0cDovL2NvbGxlZ2VjYS5kYXJ0bW91dGgu ZWR1L29jc3AwDQYJKoZIhvcNAQEFBQADggEBAMRghaYbce3ByAWIFutgqntikjraGADD0jcO P0CL561BwwNkvxxaDcp3sPBgcOQvE7uOXnXwcgkKTwSWT5ndjZzStH5z1Yu7ET4QcRSZCDYB uDHNEZkB4xePuOu/nDvkhaJcGtbdJ0OSNUfoxAVlU/UIGTs8Xf/53OaI7oTmDhxW2mE9J0ra q2dftKHTN14/N4T57QFOexZ03TIeAppsrHd0KISdBe33qwAl/lySDt8UtymWiHBaVYkKmTxb CckzRAbDfFutm8uT6QhCDKHSyfa9rgWADVp7b1wnV3Y26sBn4sx16L39lvMF4ygP1c9JjKPv Mu5VcYsX8lBCg/LCTmgxggL4MIIC9AIBATB9MHcxEzARBgoJkiaJk/IsZAEZFgNlZHUxGTAX BgoJkiaJk/IsZAEZFglkYXJ0bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91 dGggQ29sbGVnZTEcMBoGA1UEAxMTRGFydG1vdXRoIENlcnRBdXRoMQICGlMwCQYFKw4DAhoF AKCCAdEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwNDEw MTk1MTM0WjAjBgkqhkiG9w0BCQQxFgQU6sIaueZuctLcZSuyQaXRyrLksUEwUgYJKoZIhvcN AQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYF Kw4DAgcwDQYIKoZIhvcNAwICASgwgYwGCSsGAQQBgjcQBDF/MH0wdzETMBEGCgmSJomT8ixk ARkWA2VkdTEZMBcGCgmSJomT8ixkARkWCWRhcnRtb3V0aDELMAkGA1UEBhMCVVMxGjAYBgNV BAoTEURhcnRtb3V0aCBDb2xsZWdlMRwwGgYDVQQDExNEYXJ0bW91dGggQ2VydEF1dGgxAgIa UzCBjgYLKoZIhvcNAQkQAgsxf6B9MHcxEzARBgoJkiaJk/IsZAEZFgNlZHUxGTAXBgoJkiaJ k/IsZAEZFglkYXJ0bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91dGggQ29s bGVnZTEcMBoGA1UEAxMTRGFydG1vdXRoIENlcnRBdXRoMQICGlMwDQYJKoZIhvcNAQEBBQAE gYASnb0jdWaklDHSPE/utWIC1HbZRm2QqHrI8PqXJ2ng/NZVn/zs4czzzXwFsKs+R/t8Ng/t 36hW7ujSRB8Tt7m3qqhSfsw64t5DQ+Ttan9uDofi+510lDjWWYL8keOybWw7t6pYXffR2f9N gRMTidCgYP/t7WQHi/pCw7BcZxmZ5QAAAAAAAA== --------------ms060001020207000203080301-- From owner-ietf-pkix@mail.imc.org Fri Apr 10 16:14:55 2009 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F29313A685B for ; Fri, 10 Apr 2009 16:14:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.909 X-Spam-Level: X-Spam-Status: No, score=-0.909 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_96_XX=1.69] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ydEFvAykfAY4 for ; Fri, 10 Apr 2009 16:14:54 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id AE8413A693C for ; Fri, 10 Apr 2009 16:14:53 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3AMn2AL042002 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Apr 2009 15:49:02 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3AMn2dF042001; Fri, 10 Apr 2009 15:49:02 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from eurymedon.net.ttu.edu (eurymedon.net.ttu.edu [129.118.1.225]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3AMmpaE041988 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Fri, 10 Apr 2009 15:49:01 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: from hyperbius.net.ttu.edu (129.118.1.214) by tmrc.ttu.edu (129.118.1.179) with Microsoft SMTP Server id 8.1.340.0; Fri, 10 Apr 2009 17:48:50 -0500 Received: from Pickup by hyperbius.net.ttu.edu with Microsoft SMTP Server id 8.1.340.0; Fri, 10 Apr 2009 22:48:50 +0000 X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f X-IronPort-AV: E=Sophos;i="4.39,315,1235952000"; d="scan'208";a="149671683" CC: Message-ID: <52B7B6AB-2B7D-4272-8621-578571AB0A80@cisco.com> From: max pritikin To: Russ Housley In-Reply-To: <20090402162231.3E53E9A476F@odin.smetech.net> Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit MIME-Version: 1.0 (Apple Message framework v930.3) Subject: Re: Normative reference for 'CA rollover'? Date: Thu, 2 Apr 2009 12:24:33 -0500 References: <3DE5002F-3921-4170-9C22-F6D389071DC5@cisco.com> <20090402162231.3E53E9A476F@odin.smetech.net> X-Mailer: Apple Mail (2.930.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2418; t=1238693074; x=1239557074; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pritikin@cisco.com; z=From:=20max=20pritikin=20 |Subject:=20Re=3A=20Normative=20reference=20for=20'CA=20rol lover'? |Sender:=20; bh=iVnriq0ZJB212pieNLLFFvdly3fxfQrH5CDY+DZa7dw=; b=QAV9Eyx+SmJMNlsO3k1ch1OPPjRw9gHZJlFo/F32zIBHj2j7oWJl51No7H QPMME2T5Ws2jcTHe11Zt+3P2MzDVhpXsdtPAxwwkA96Tj5KkxL/n/PDWXTry svjvXbkCRw; Authentication-Results: sj-dkim-4; header.From=pritikin@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); List-Archive: List-ID: List-Unsubscribe: Received-SPF: None (emphytus.net.ttu.edu: owner-ietf-pkix@mail.imc.org does not designate permitted sender hosts) X-TechMail-Edge-Route: TTU Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Thank you Russ. This is what I was looking for. I'll review and ask questions as necessary. I would support the idea of publishing this information independently from a specific enrollment protocol. - max On Apr 2, 2009, at 11:22 AM, Russ Housley wrote: > Believe it or not, the new-in-old and old-in-new procedure is > documented in CMP. Many people fail to find it there. Perhaps it > should be extracted from there and published as a BCP. > > Russ > > At 10:47 AM 4/2/2009, max pritikin wrote: > > >> Hi folks, >> >> I'm looking for a normative reference describing how a CA would >> 'rollover' to a new keypair or 'modified' certificate. >> >> RFC5280 includes the following statements about 'rollover', here >> quoted with minimal context: >> >> 4.2.1.10 Name Contraints: >> "Name constraints are not applied to self-issued certificates >> (unless >> the certificate is the final certificate in the path). (This could >> prevent CAs that use name constraints from employing self-issued >> certificates to implement key rollover.)" >> >> 6.1. Basic Path Validation: >> "A certificate is self-issued if the same DN appears in the subject >> and issuer fields (the two DNs are the same if they match according >> to the rules specified in Section 7.1). In general, the issuer and >> subject of the certificates that make up a path are different for >> each certificate. However, a CA may issue a certificate to itself >> to >> support key rollover or changes in certificate policies. These >> self-issued certificates are not counted when evaluating path >> length >> or name constraints." >> >> 8. Security Considerations: >> "Loss of a CA's private signing key may also be problematic. The >> CA >> would not be able to produce CRLs or perform normal key rollover." >> >> But it does not include a recommended description of this rollover >> process itself. >> >> RFC3647 does not mention rollover at all, although it does define >> 'renewal' and 'rekey'. >> >> I can find informative discussions of rollover for various CA's >> (thanks Google). >> >> Can somebody point me in the right direction? Is there a normative >> reference or should I be able to infer the "correct" behavior from >> end >> entity rekey discussions as per the above notes? >> >> Thank you, >> >> - max >> > From owner-ietf-pkix@mail.imc.org Fri Apr 10 16:54:18 2009 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B036428C105 for ; Fri, 10 Apr 2009 16:54:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.909 X-Spam-Level: X-Spam-Status: No, score=-0.909 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_96_XX=1.69] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8r5CBolI1VKF for ; Fri, 10 Apr 2009 16:54:17 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 777123A6889 for ; Fri, 10 Apr 2009 16:54:15 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3AMpg4x042136 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Apr 2009 15:51:42 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3AMpgB7042135; Fri, 10 Apr 2009 15:51:42 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from euphorbus.net.ttu.edu (euphorbus.net.ttu.edu [129.118.1.216]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3AMpUbN042125 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Fri, 10 Apr 2009 15:51:40 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: from Pickup by euphorbus.net.ttu.edu with Microsoft SMTP Server id 8.1.340.0; Fri, 10 Apr 2009 22:51:30 +0000 X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: OCSP RFC (RFC 2560) Dependence on SHA-1 Date: Wed, 1 Apr 2009 16:31:58 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: OCSP RFC (RFC 2560) Dependence on SHA-1 Thread-Index: AcmyIGh4vURVLwB0QOmggx7xJi+ihAAAFOIwACx2HrAACXbF2QAB5FEQ References:

From: Santosh Chokhani To: Stefan Santesson , IETF-pkix List-Archive: List-ID: List-Unsubscribe: Received-SPF: None (emphytus.net.ttu.edu: owner-ietf-pkix@mail.imc.org does not designate permitted sender hosts) X-TechMail-Edge-Route: TTU Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Stefan, See responses in-line. > -----Original Message----- > From: Stefan Santesson [mailto:stefan@aaa-sec.com]=20 > Sent: Wednesday, April 01, 2009 2:34 PM > To: Santosh Chokhani; Massimiliano Pala; IETF-pkix > Subject: Re: OCSP RFC (RFC 2560) Dependence on SHA-1 >=20 > Santosh, >=20 > If you are talking about adding other options to calculate=20 > the KeyHash value in ResponderID then I strongly disagree. >=20 > If you add unspecified options you change the properties of=20 > the field from deterministic to a completely unknown value.=20 > It does not matter if RFC2560 isn't explicit in its=20 > description of the use of the field. The fact is that OCSP=20 > explicitly defines this value and as such will allow a client=20 > to deterministically compare this value with the certificate=20 > selected to validate the response signature. I hope no one is doing the matching of Responder ID with hash of a key in place of responder signature verification. That would be real bad. > If you allow=20 > other ways to calculate the value but do not provide any=20 > means to signal what method that was used, then this feature is lost. The most common use will be to use this field to prioritize the certificates of the responder to use for sigature verification on the response. >=20 > In worst case we will cause current implementation to fail. That is why I am asking what problems if any will the vendors have. >=20 > I really don't think its worth the effort to change this=20 > field. We have a very large base of implementations that we=20 > really don't want to mess up unless its absolutely necessary. So, we agree that leaving this field hard wired to SHA-1 is ok and 2560 can easily accommodate new hash functions. Right? My only reason to align with 5280 is that if some one were ever want to strip off SHA-1 altogether from their Responder or client, permitting other methods does it. >=20 > As the only property of this field is to provide a convenient=20 > identifier, it is far from absolutely necessary to change it.=20 > Remember that there is a second choice to to identify=20 > responder by name. For names we have accepted the possibility=20 > of collisions. In that comparison, upgrading from SHA-1 is=20 > really redundant. >=20 > /Stefan >=20 >=20 >=20 >=20 > On 4/1/09 4:05 PM, "Santosh Chokhani" wrote: >=20 > >=20 > > My resident ASN.1 expert apprised me of the fact that=20 > adding a choice=20 > > will break backward compatibility. Thus, extension is a=20 > fifth option=20 > > (probably third in the priority). > >=20 > > Based on what I know of OCSP implementations, not changing=20 > anything in=20 > > terms of bits on the wire and aligning the Key ID with SKID=20 > in 5280 is=20 > > the best approach. I do not think it will hurt backward=20 > compatibility. > >=20 > > OCSP Responder and OCSP client vendors should speak up if I=20 > am wrong. > >=20 > >> -----Original Message----- > >> From: Santosh Chokhani > >> Sent: Tuesday, March 31, 2009 12:51 PM > >> To: 'Massimiliano Pala'; IETF-pkix > >> Subject: RE: OCSP RFC (RFC 2560) Dependence on SHA-1 > >>=20 > >> Max, > >>=20 > >> I do not see where and what extension we need to add for=20 > other digest=20 > >> algorithm. > >>=20 > >> For key id, we need to enhance or broaden the options. > >>=20 > >>> -----Original Message----- > >>> From: owner-ietf-pkix@mail.imc.org > >>> [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of=20 > Massimiliano Pala > >>> Sent: Tuesday, March 31, 2009 1:37 PM > >>> To: IETF-pkix > >>> Subject: Re: OCSP RFC (RFC 2560) Dependence on SHA-1 > >>>=20 > >>> Hi all, > >>>=20 > >>> as I said during last meeting - as the use of SHA-1 does > >> not have any > >>> security implication in the OCSP, another viable way would be to=20 > >>> define an extension where other digest algorithms can be > >> added to the > >>> request/responses. > >>>=20 > >>> It is a simple addition and does not require any change in > >> the RFC, it > >>> can be done as a separate document for those who what to=20 > use other=20 > >>> digest algorithms. > >>>=20 > >>> After all, isn't this an example of why we allow=20 > extensions to the=20 > >>> messages ? > >>>=20 > >>> Later, > >>> Max > >>>=20 > >>>=20 > >>> Santosh Chokhani wrote: > >>>> Tom, > >>>>=20 > >>>> Adding a new choice and aligning it with 5280 SKID is fine. > >>>>=20 > >>>> I would not add anything about matching this field with > >>> anything since > >>>> RFC 2560 does not say anything about it. > >>>>=20 > >>>> If one were to add something, one should describe how this > >>> field can > >>>> be used to select from multiple Responder certificates. > >>>>=20 > >>>>> -----Original Message----- > >>>>> From: Tom Gindin [mailto:tgindin@us.ibm.com] > >>>>> Sent: Monday, March 30, 2009 7:46 PM > >>>>> To: Santosh Chokhani > >>>>> Cc: IETF-pkix > >>>>> Subject: Re: OCSP RFC (RFC 2560) Dependence on SHA-1 > >>>>>=20 > >>>>> Santosh: > >>>>>=20 > >>>>> The RFC 5280 method just describes "two common > >> methods for > >>>>> generating key identifiers from the public key" > >>>>> and says that other methods are acceptable. The comment > >>> to KeyHash > >>>>> in RFC 2560 4.2.1 is not as permissive. Of course, it's > >> the same > >>>>> field as SKID, and I would support either stating "if the > >>> KeyHash is > >>>>> not precisely 20 octets long, it should be matched against the=20 > >>>>> Subject Key Identifier extension of the signing certificate" or=20 > >>>>> adding another choice like byID [3] OCTET STRING -- > >>> matches the value > >>>>> of SKID. > >>>>>=20 > >>>>> Tom Gindin > >>>>>=20 > >>>>> P.S. - The above opinions are mine, and not necessarily > >>> those of my > >>>>> employer > >>>>>=20 > >>>>>=20 > >>>>>=20 > >>>>>=20 > >>>>> "Santosh Chokhani" Sent by: > >>>>> owner-ietf-pkix@mail.imc.org > >>>>> 03/26/2009 10:39 PM > >>>>>=20 > >>>>> To > >>>>> "IETF-pkix" > >>>>> cc > >>>>>=20 > >>>>> Subject > >>>>> OCSP RFC (RFC 2560) Dependence on SHA-1 > >>>>>=20 > >>>>>=20 > >>>>>=20 > >>>>>=20 > >>>>>=20 > >>>>>=20 > >>>>>=20 > >>>>> RFC 2560 dependence on SHA-1 does not appear to be > >>> difficult to deal > >>>>> with. > >>>>>=20 > >>>>> Section 4.3 lists SHA-1 as mandatory and RSA as > >> optional. We can > >>>>> update this to add SHA-2 series as optional. > >>>>>=20 > >>>>> The Responder ID has SHA-1 hardwired. But, that is no > >>> different than > >>>>> key ID extensions in RFC 5280. Here are some options=20 > in order of > >>>>> preference: > >>>>>=20 > >>>>> 1. Align the language with subject key ID language in RFC 5280. > >>>>>=20 > >>>>> 2. Keep on using SHA-1. This field is not security > >>> relevant. RFC > >>>>> 2560 does not even describe how to use this field. So, > >>> having SHA-1 > >>>>> and accidental or intentional collisions will not hurt the > >>> security > >>>>> of the protocol. > >>>>>=20 > >>>>> 3. If you do not believe in KISS principle, you can > >>> define another > >>>>> response type and enhance the key ID ASN.1 syntax so that hash=20 > >>>>> algorithm is identified. > >>>>>=20 > >>>>> 4. Another option is for the Responder to use the same hashing=20 > >>>>> algorithm as the one in the first certID entry. > >>>>>=20 > >>>>>=20 > >>>>> Santosh Chokhani > >>>>> CygnaCom Solutions > >>>>>=20 > >>>>>=20 > >>>>>=20 > >>>>>=20 > >>>>=20 > >>>>=20 > >>>=20 > >>>=20 > >>> -- > >>>=20 > >>> Best Regards, > >>>=20 > >>> Massimiliano Pala > >>>=20 > >>> --o----------------------------------------------------------- > >>> ------------- > >>> Massimiliano Pala [OpenCA Project Manager]=20 > >>> Massimiliano.Pala@dartmouth.edu > >>> =20 > >>> project.manager@openca.org > >>>=20 > >>> Dartmouth Computer Science Dept Home Phone: +1 > >>> (603) 369-9332 > >>> PKI/Trust Laboratory Work Phone: +1 > >>> (603) 646-9179 > >>> --o----------------------------------------------------------- > >>> ------------- > >>>=20 > >>> People who think they know everything are a great annoyance > >> to those > >>> of us who do. > >>> -- > >>> Isaac Asimov > >>>=20 > >>=20 > >=20 >=20 >=20 >=20 From owner-ietf-pkix@mail.imc.org Fri Apr 10 17:52:00 2009 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71F103A684B for ; Fri, 10 Apr 2009 17:52:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.908 X-Spam-Level: X-Spam-Status: No, score=-0.908 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, DATE_IN_PAST_96_XX=1.69, HTML_MESSAGE=0.001, WHOIS_NETSOLPR=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6iTjNX3loOxF for ; Fri, 10 Apr 2009 17:51:49 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 2C4793A6889 for ; Fri, 10 Apr 2009 17:51:47 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3B0KawP045883 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Apr 2009 17:20:36 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3B0KaDb045882; Fri, 10 Apr 2009 17:20:36 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from emphytus.net.ttu.edu (emphytus.net.ttu.edu [129.118.1.215]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3B0KO08045826 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Fri, 10 Apr 2009 17:20:34 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: from Pickup by emphytus.net.ttu.edu with Microsoft SMTP Server id 8.1.340.0; Sat, 11 Apr 2009 00:20:22 +0000 X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9B390.59C32388" X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: OCSP RFC (RFC 2560) Dependence on SHA-1 Date: Thu, 2 Apr 2009 08:41:31 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: OCSP RFC (RFC 2560) Dependence on SHA-1 Thread-Index: AcmyIGh4vURVLwB0QOmggx7xJi+ihAAAFOIwACx2HrAACXbF2QAB5FEQAAZrbKkABFxqQAAIVKC2AA7xVoAAATo3RwAAzaKg References:

From: Santosh Chokhani To: Stefan Santesson , "Hallam-Baker, Phillip" , IETF-pkix List-Archive: List-ID: List-Unsubscribe: Received-SPF: None (emphytus.net.ttu.edu: owner-ietf-pkix@mail.imc.org does not designate permitted sender hosts) X-TechMail-Edge-Route: TTU Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ------_=_NextPart_001_01C9B390.59C32388 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Agree ________________________________ From: Stefan Santesson [mailto:stefan@aaa-sec.com]=20 Sent: Thursday, April 02, 2009 8:18 AM To: Santosh Chokhani; Hallam-Baker, Phillip; IETF-pkix Subject: Re: OCSP RFC (RFC 2560) Dependence on SHA-1 =09 =09 I do agree to most things here. =09 I don't believe that implementations can strip off SHA-1 in any foreseeable future. It needs to be around, if nothing else, so for backwards compatibility. SHA-1 will continue to work in situations like this where no security properties are needed. =09 IMO, The added extension, even though I will not fight hard against it, would just be redundant complexity. =09 /Stefan =09 On 4/2/09 1:54 PM, "Santosh Chokhani" wrote: =09 =09 I have no objection to having an extension, but if in the long term SHA-1 will not be there, it seems defining a new response type (say basic 2) would be the way to go so that SHA-1 based key ID can be stripped off. =09 If SHA-1 is not getting ripped off in the long term, I do not see value in extension except that it may make every one happy: those who do not care will not include it on the Server side and/or will ignore it on the client side. =09 It would appear that the extension should be NC. =09 Phil, =09 I would not respond to the arguments on KISS and security since in this case both are straightforward. Also, in this thread, the comments were not meant for or directed at you. =09 As you know, I have provided extensive comments to you when you first posted the OCSP Agility I-D and my position and reasons are matter of PKIX archives for anyone to scrutinize. When you ignore every single cogent point, there is no sense in me commenting on next iteration. I do think that the OCSP Agility I-D is a solution looking for a problem that I do not see. =09 =09 =20 =09 ________________________________ From: Hallam-Baker, Phillip [mailto:pbaker@verisign.com]=20 Sent: Thursday, April 02, 2009 12:53 AM To: Santosh Chokhani; Stefan Santesson; IETF-pkix Subject: RE: OCSP RFC (RFC 2560) Dependence on SHA-1 =09 =20 =20 =20 I think we have no choice but to leave the Key ID CHOICE to be SHA-1 based. =09 =20 =20 But that does not preclude adding an extension that allows the KeyID to be specified using a stronger algorithm. There are two reasons for this: =09 =20 =20 1) Optics, even if there is no security implication, a protocol that uses weak crypto necessitates an (expensive) security review to prove that there is no problem. And these must be performed repeatedly by many different parties as relying on the analysis of others is a good way to cause issues. Been there, done that. =09 =20 =20 2) We are designing for long time spans, ten years or more. While simple compressor collisions may not be a concern, there is no guarantee that the attacks will stop at that point. MD4 has been broken repeatedly and they are now at the stage of jumping up and down on the little pieces. It will probably happen to MD5 and we should be cautious in case it happens to SHA-1. =09 =20 =20 =20 =20 On the claim of 'Keep it simple STUPID', I find it rather offensive to have my position characterized as stupid. My designs are not exactly known for being verbose or overly elaborate. If I propose something it is because there is a reason. It is very easy to defend the status quo by derriding proposals as unnecessary, but the fact is that making OCSP too simple will simply cause the complexity to blow out somewhere else. =09 =20 =20 There is an architectural princple of modular design that demands that the core of PKIX as it now stands (the certificate profile and OCSP) be capable of stand alone use. We cannot fix issues in OCSP with LTANS or other layered-on protocols as some have proposed. It does not simplify my OCSP deployment to have to graft on an entire different protocol in addition or to re-engineer my document archival protocol to cover defects in OCSP. =09 =20 =20 =20 =20 Simply adding new algorithms to a protocol does nothing to improve security. You only improve security if you withdraw insecure algorithms from use. =09 =20 =20 To make the system work you have to have a means of negotiating between the client and the server. Otherwise there is no way for an OCSP responder to ensure that it receives a secure, supported response to querries for certificates that do not exist yet or are not known to the responder. =09 =20 =20 In the case of an OCSP responder being driven by CRLs collected from various sources, there is no way for the CA to know if a certificate even exists, all it knows is if the status is definitively revoked. =09 =20 =20 In the case of many transactional architectures the OCSP validation is performed independently of certificate chain validation.=20 =09 =20 =20 =20 =20 Experience of small scale PKI deployment in which any box can be upgraded at will is simply not representative of large scale real world deployment. =09 =20 =20 =20 =09 =20 =20 =09 ________________________________ =20 From: owner-ietf-pkix@mail.imc.org on behalf of Santosh Chokhani Sent: Wed 4/1/2009 8:39 PM To: Stefan Santesson; IETF-pkix Subject: RE: OCSP RFC (RFC 2560) Dependence on SHA-1 =09 =20 =09 =20 =09 I am saying that "Do you agree that 2560 can be left alone for Responder ID's key ID CHOICE being SHA-1 based?" =09 > -----Original Message----- > From: Stefan Santesson [mailto:stefan@aaa-sec.com] > Sent: Wednesday, April 01, 2009 6:32 PM > To: Santosh Chokhani; IETF-pkix > Subject: Re: OCSP RFC (RFC 2560) Dependence on SHA-1 > > Santosh, > > In-line > > > On 4/1/09 10:31 PM, "Santosh Chokhani" wrote: > > > > > Stefan, > > > > See responses in-line. > > > >> -----Original Message----- > >> From: Stefan Santesson [mailto:stefan@aaa-sec.com] > >> Sent: Wednesday, April 01, 2009 2:34 PM > >> To: Santosh Chokhani; Massimiliano Pala; IETF-pkix > >> Subject: Re: OCSP RFC (RFC 2560) Dependence on SHA-1 > >> > >> Santosh, > >> > >> If you are talking about adding other options to calculate the > >> KeyHash value in ResponderID then I strongly disagree. > >> > >> If you add unspecified options you change the properties > of the field > >> from deterministic to a completely unknown value. > >> It does not matter if RFC2560 isn't explicit in its description of > >> the use of the field. The fact is that OCSP explicitly > defines this > >> value and as such will allow a client to deterministically compare > >> this value with the certificate selected to validate the response > >> signature. > > > > I hope no one is doing the matching of Responder ID with > hash of a key > > in place of responder signature verification. That would > be real bad. > > > > Yes it would. That is not at all what I talk about. But a > client could use this value to locate a responder certificate. > > >> If you allow > >> other ways to calculate the value but do not provide any means to > >> signal what method that was used, then this feature is lost. > > > > The most common use will be to use this field to prioritize the > > certificates of the responder to use for sigature > verification on the > > response. > > > > Do you know this for a fact, or are you guessing? > If a single implementation verifies that the certificate used > to validate the response matches the ResponderID value, and > choose to go into an error state because of mismatch, then we > have created great problems. So we can't guess. We have to > know that no single implementation will fail because of this. > And that may be very hard. > > > >> > >> In worst case we will cause current implementation to fail. > > > > That is why I am asking what problems if any will the vendors have. > > > > Even if no vendor speaks up here, it will not guarantee that > this will not create any problems. > > >> > >> I really don't think its worth the effort to change this field. We > >> have a very large base of implementations that we really > don't want > >> to mess up unless its absolutely necessary. > > > > So, we agree that leaving this field hard wired to SHA-1 is ok and > > 2560 can easily accommodate new hash functions. Right? > > > > I fail to understand this sentence. Despite reading it many > times over. > > > My only reason to align with 5280 is that if some one were > ever want > > to strip off SHA-1 altogether from their Responder or client, > > permitting other methods does it. > > > > I don't believe this argument is valid as I don't think it is > possible to strip off SHA-1 in any reasonable future. In any > case. If we compare the positive side with allowing this > change and the negative consequences to make OCSP > incompatible with itself, my choice is easy. > > /Stefan >=20 > > >> > >> As the only property of this field is to provide a convenient > >> identifier, it is far from absolutely necessary to change it. > >> Remember that there is a second choice to to identify responder by > >> name. For names we have accepted the possibility of collisions. In > >> that comparison, upgrading from SHA-1 is really redundant. > >> > >> /Stefan > >> > >> > >> > >> > >> On 4/1/09 4:05 PM, "Santosh Chokhani" > wrote: > >> > >>> > >>> My resident ASN.1 expert apprised me of the fact that > >> adding a choice > >>> will break backward compatibility. Thus, extension is a > >> fifth option > >>> (probably third in the priority). > >>> > >>> Based on what I know of OCSP implementations, not changing > >> anything in > >>> terms of bits on the wire and aligning the Key ID with SKID > >> in 5280 is > >>> the best approach. I do not think it will hurt backward > >> compatibility. > >>> > >>> OCSP Responder and OCSP client vendors should speak up if I > >> am wrong. > >>> > >>>> -----Original Message----- > >>>> From: Santosh Chokhani > >>>> Sent: Tuesday, March 31, 2009 12:51 PM > >>>> To: 'Massimiliano Pala'; IETF-pkix > >>>> Subject: RE: OCSP RFC (RFC 2560) Dependence on SHA-1 > >>>> > >>>> Max, > >>>> > >>>> I do not see where and what extension we need to add for > >> other digest > >>>> algorithm. > >>>> > >>>> For key id, we need to enhance or broaden the options. > >>>> > >>>>> -----Original Message----- > >>>>> From: owner-ietf-pkix@mail.imc.org > >>>>> [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of > >> Massimiliano Pala > >>>>> Sent: Tuesday, March 31, 2009 1:37 PM > >>>>> To: IETF-pkix > >>>>> Subject: Re: OCSP RFC (RFC 2560) Dependence on SHA-1 > >>>>> > >>>>> Hi all, > >>>>> > >>>>> as I said during last meeting - as the use of SHA-1 does > >>>> not have any > >>>>> security implication in the OCSP, another viable way > would be to > >>>>> define an extension where other digest algorithms can be > >>>> added to the > >>>>> request/responses. > >>>>> > >>>>> It is a simple addition and does not require any change in > >>>> the RFC, it > >>>>> can be done as a separate document for those who what to > >> use other > >>>>> digest algorithms. > >>>>> > >>>>> After all, isn't this an example of why we allow > >> extensions to the > >>>>> messages ? > >>>>> > >>>>> Later, > >>>>> Max > >>>>> > >>>>> > >>>>> Santosh Chokhani wrote: > >>>>>> Tom, > >>>>>> > >>>>>> Adding a new choice and aligning it with 5280 SKID is fine. > >>>>>> > >>>>>> I would not add anything about matching this field with > >>>>> anything since > >>>>>> RFC 2560 does not say anything about it. > >>>>>> > >>>>>> If one were to add something, one should describe how this > >>>>> field can > >>>>>> be used to select from multiple Responder certificates. > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: Tom Gindin [mailto:tgindin@us.ibm.com] > >>>>>>> Sent: Monday, March 30, 2009 7:46 PM > >>>>>>> To: Santosh Chokhani > >>>>>>> Cc: IETF-pkix > >>>>>>> Subject: Re: OCSP RFC (RFC 2560) Dependence on SHA-1 > >>>>>>> > >>>>>>> Santosh: > >>>>>>> > >>>>>>> The RFC 5280 method just describes "two common > >>>> methods for > >>>>>>> generating key identifiers from the public key" > >>>>>>> and says that other methods are acceptable. The comment > >>>>> to KeyHash > >>>>>>> in RFC 2560 4.2.1 is not as permissive. Of course, it's > >>>> the same > >>>>>>> field as SKID, and I would support either stating "if the > >>>>> KeyHash is > >>>>>>> not precisely 20 octets long, it should be matched > against the > >>>>>>> Subject Key Identifier extension of the signing > certificate" or > >>>>>>> adding another choice like byID [3] OCTET STRING -- > >>>>> matches the value > >>>>>>> of SKID. > >>>>>>> > >>>>>>> Tom Gindin > >>>>>>> > >>>>>>> P.S. - The above opinions are mine, and not necessarily > >>>>> those of my > >>>>>>> employer > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> "Santosh Chokhani" Sent by: > >>>>>>> owner-ietf-pkix@mail.imc.org > >>>>>>> 03/26/2009 10:39 PM > >>>>>>> > >>>>>>> To > >>>>>>> "IETF-pkix" > >>>>>>> cc > >>>>>>> > >>>>>>> Subject > >>>>>>> OCSP RFC (RFC 2560) Dependence on SHA-1 > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> RFC 2560 dependence on SHA-1 does not appear to be > >>>>> difficult to deal > >>>>>>> with. > >>>>>>> > >>>>>>> Section 4.3 lists SHA-1 as mandatory and RSA as > >>>> optional. We can > >>>>>>> update this to add SHA-2 series as optional. > >>>>>>> > >>>>>>> The Responder ID has SHA-1 hardwired. But, that is no > >>>>> different than > >>>>>>> key ID extensions in RFC 5280. Here are some options > >> in order of > >>>>>>> preference: > >>>>>>> > >>>>>>> 1. Align the language with subject key ID language > in RFC 5280. > >>>>>>> > >>>>>>> 2. Keep on using SHA-1. This field is not security > >>>>> relevant. RFC > >>>>>>> 2560 does not even describe how to use this field. So, > >>>>> having SHA-1 > >>>>>>> and accidental or intentional collisions will not hurt the > >>>>> security > >>>>>>> of the protocol. > >>>>>>> > >>>>>>> 3. If you do not believe in KISS principle, you can > >>>>> define another > >>>>>>> response type and enhance the key ID ASN.1 syntax so > that hash > >>>>>>> algorithm is identified. > >>>>>>> > >>>>>>> 4. Another option is for the Responder to use the > same hashing > >>>>>>> algorithm as the one in the first certID entry. > >>>>>>> > >>>>>>> > >>>>>>> Santosh Chokhani > >>>>>>> CygnaCom Solutions > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> > >>>>> Best Regards, > >>>>> > >>>>> Massimiliano Pala > >>>>> > >>>>> --o----------------------------------------------------------- > >>>>> ------------- > >>>>> Massimiliano Pala [OpenCA Project Manager] > >>>>> Massimiliano.Pala@dartmouth.edu > >>>>> =20 > >>>>> project.manager@openca.org > >>>>> > >>>>> Dartmouth Computer Science Dept Home Phone: +1 > >>>>> (603) 369-9332 > >>>>> PKI/Trust Laboratory Work Phone: +1 > >>>>> (603) 646-9179 > >>>>> --o----------------------------------------------------------- > >>>>> ------------- > >>>>> > >>>>> People who think they know everything are a great annoyance > >>>> to those > >>>>> of us who do. > >>>>> -- > >>>>> Isaac Asimov > >>>>> > >>>> > >>> > >> > >> > >> > > > > > =09 =09 =09 =09 ------_=_NextPart_001_01C9B390.59C32388 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: OCSP RFC (RFC 2560) Dependence on SHA-1

Agree

From: Stefan Santesson=20 [mailto:stefan@aaa-sec.com]
Sent: Thursday, April 02, 2009 = 8:18=20 AM
To: Santosh Chokhani; Hallam-Baker, Phillip;=20 IETF-pkix
Subject: Re: OCSP RFC (RFC 2560) Dependence on=20 SHA-1

I do agree to most things here.

I = don’t believe=20 that implementations can strip off SHA-1 in any foreseeable future. It = needs=20 to be around, if nothing else, so for backwards compatibility. SHA-1 = will=20 continue to work in situations like this where no security properties = are=20 needed.

IMO, The added extension, even though I will not fight = hard=20 against it, would just be redundant = complexity.

/Stefan

On=20 4/2/09 1:54 PM, "Santosh Chokhani" <SChokhani@cygnacom.com>=20 wrote:

I have no objection to having an extension, but if in = the long=20 term SHA-1 will not be there, it seems defining a new response type = (say=20 basic 2) would be the way to go so that SHA-1 based key ID can be = stripped=20 off.

If SHA-1 is not getting ripped = off in the=20 long term, I do not see value in extension except that it may make = every one=20 happy: those who do not care will not include it on the Server side = and/or=20 will ignore it on the client side.

It would appear that the = extension should be=20 NC.

Phil,

I would not respond to the = arguments on KISS=20 and security since in this case both are straightforward. = Also, in=20 this thread, the comments were not meant for or directed at=20 you.

As you know, I have provided = extensive=20 comments to you when you first posted the OCSP Agility I-D and my = position=20 and reasons are matter of PKIX archives for anyone to scrutinize. = When=20 you ignore every single cogent point, there is no sense in me = commenting on=20 next iteration. I do think that the OCSP Agility I-D is a = solution=20 looking for a problem that I do not see.

From:=20 Hallam-Baker, Phillip [mailto:pbaker@verisign.com]=20
Sent: Thursday, April 02, 2009 12:53 = AM
To:=20 Santosh Chokhani; Stefan Santesson; = IETF-pkix
Subject: RE:=20 OCSP RFC (RFC 2560) Dependence on SHA-1

I think we have no choice but to leave the Key = ID CHOICE=20 to be SHA-1 based.

But that does not preclude adding an extension = that=20 allows the KeyID to be specified using a stronger algorithm. = There=20 are two reasons for this:

1) Optics, even if there is no security = implication, a=20 protocol that uses weak crypto necessitates an (expensive) = security=20 review to prove that there is no problem. And these must be = performed=20 repeatedly by many different parties as relying on the = analysis of=20 others is a good way to cause issues. Been there, done=20 that.

2) We are designing for long time spans, ten = years or=20 more. While simple compressor collisions may not be a concern, = there=20 is no guarantee that the attacks will stop at that point. MD4 has = been=20 broken repeatedly and they are now at the stage of jumping = up and=20 down on the little pieces. It will probably happen to MD5 = and we=20 should be cautious in case it happens to = SHA-1.

On the claim of 'Keep it simple STUPID', I find = it rather=20 offensive to have my position characterized as stupid. My = designs=20 are not exactly known for being verbose or overly elaborate. If I=20 propose something it is because there is a reason. It is = very easy=20 to defend the status quo by derriding proposals as = unnecessary, but=20 the fact is that making OCSP too simple will simply cause = the=20 complexity to blow out somewhere else.

There is an architectural princple of modular = design that=20 demands that the core of PKIX as it now stands (the = certificate=20 profile and OCSP) be capable of stand alone use. We cannot fix=20 issues in OCSP with LTANS or other layered-on protocols as = some have=20 proposed. It does not simplify my OCSP deployment to have to = graft=20 on an entire different protocol in addition or to = re-engineer my=20 document archival protocol to cover defects in = OCSP.

Simply adding new algorithms to a protocol does = nothing=20 to improve security. You only improve security if you = withdraw=20 insecure algorithms from use.

To make the system work you have to have a = means of=20 negotiating between the client and the server. Otherwise there is = no=20 way for an OCSP responder to ensure that it receives a secure,=20 supported response to querries for certificates that do not = exist=20 yet or are not known to the responder.

In the case of an OCSP responder being driven = by CRLs=20 collected from various sources, there is no way for the CA to = know=20 if a certificate even exists, all it knows is if the status is=20 definitively revoked.

In the case of many transactional architectures = the OCSP=20 validation is performed independently of certificate chain=20 validation.

Experience of small scale PKI deployment in = which any box=20 can be upgraded at will is simply not representative of large = scale=20 real world deployment.

From: owner-ietf-pkix@mail.imc.org = on=20 behalf of Santosh Chokhani
Sent: Wed 4/1/2009 8:39 = PM
To: Stefan Santesson; IETF-pkix
Subject: = RE:=20 OCSP RFC (RFC 2560) Dependence on SHA-1

I=20 am saying that "Do you agree that 2560 can be left alone for=20 Responder
ID's key ID CHOICE being SHA-1 = based?"

>=20 -----Original Message-----
> From: Stefan Santesson = [mailto:stefan@aaa-sec.com]
>= =20 Sent: Wednesday, April 01, 2009 6:32 PM
> To: Santosh=20 Chokhani; IETF-pkix
> Subject: Re: OCSP RFC (RFC 2560) = Dependence on SHA-1
>
> Santosh,
>
> = In-line
>
>
> On 4/1/09 10:31 PM, "Santosh = Chokhani" <SChokhani@cygnacom.com>=20 wrote:
>
> >
> > Stefan,
>=20 >
> > See responses in-line.
> = >
>=20 >> -----Original Message-----
> >> From: = Stefan=20 Santesson [mailto:stefan@aaa-sec.com]
>= =20 >> Sent: Wednesday, April 01, 2009 2:34 PM
> = >>=20 To: Santosh Chokhani; Massimiliano Pala; IETF-pkix
> = >>=20 Subject: Re: OCSP RFC (RFC 2560) Dependence on SHA-1
> = >>
> >> Santosh,
> >>
> = >>=20 If you are talking about adding other options to calculate=20 the
> >> KeyHash value in ResponderID then I = strongly=20 disagree.
> >>
> >> If you add = unspecified=20 options you change the properties
> of the field
>=20 >> from deterministic to a completely unknown = value.
>=20 >> It does not matter if RFC2560 isn't explicit in its = description of
> >> the use of the field. The = fact is=20 that OCSP explicitly
> defines this
> >> = value and=20 as such will allow a client to deterministically = compare
>=20 >> this value with the certificate selected to = validate the=20 response
> >> signature.
> >
> = > I=20 hope no one is doing the matching of Responder ID = with
> hash=20 of a key
> > in place of responder signature = verification.=20 That would
> be real bad.
> = >
>
>=20 Yes it would. That is not at all what I talk about. But = a
>=20 client could use this value to locate a responder=20 certificate.
>
> >> If you allow
> = >>=20 other ways to calculate the value but do not provide any = means=20 to
> >> signal what method that was used, then = this=20 feature is lost.
> >
> > The most common = use will=20 be to use this field to prioritize the
> > = certificates of=20 the responder to use for sigature
> verification on=20 the
> > response.
> >
>
> Do = you know=20 this for a fact, or are you guessing?
> If a single=20 implementation verifies that the certificate used
> to = validate the response matches the ResponderID value, = and
>=20 choose to go into an error state because of mismatch, then=20 we
> have created great problems. So we can't guess. = We have=20 to
> know that no single implementation will fail = because of=20 this.
> And that may be very = hard.
>
>
>=20 >>
> >> In worst case we will cause = current=20 implementation to fail.
> >
> > That is = why I am=20 asking what problems if any will the vendors have.
>=20 >
>
> Even if no vendor speaks up here, it = will not=20 guarantee that
> this will not create any=20 problems.
>
> >>
> >> I really = don't=20 think its worth the effort to change this field. We
> = >>=20 have a very large base of implementations that we = really
>=20 don't want
> >> to mess up unless its absolutely=20 necessary.
> >
> > So, we agree that = leaving this=20 field hard wired to SHA-1 is ok and
> > 2560 can = easily=20 accommodate new hash functions. Right?
>=20 >
>
> I fail to understand this sentence. = Despite=20 reading it many
> times over.
>
> > My = only=20 reason to align with 5280 is that if some one were
> ever=20 want
> > to strip off SHA-1 altogether from their = Responder=20 or client,
> > permitting other methods does = it.
>=20 >
>
> I don't believe this argument is valid = as I=20 don't think it is
> possible to strip off SHA-1 in any = reasonable future. In any
> case. If we compare the = positive=20 side with allowing this
> change and the negative = consequences=20 to make OCSP
> incompatible with itself, my choice is=20 easy.
>
> /Stefan
>
>
>=20 >>
> >> As the only property of this field = is to=20 provide a convenient
> >> identifier, it is far = from=20 absolutely necessary to change it.
> >> Remember = that=20 there is a second choice to to identify responder by
> = >>=20 name. For names we have accepted the possibility of = collisions.=20 In
> >> that comparison, upgrading from SHA-1 is = really=20 redundant.
> >>
> >> /Stefan
> = >>
> >>
> >>
> = >>
>=20 >> On 4/1/09 4:05 PM, "Santosh Chokhani"
> = <SChokhani@cygnacom.com>=20 wrote:
> >>
> >>>
> = >>> My=20 resident ASN.1 expert apprised me of the fact that
> = >>=20 adding a choice
> >>> will break backward=20 compatibility. Thus, extension is a
> >> = fifth=20 option
> >>> (probably third in the=20 priority).
> >>>
> >>> Based = on what I=20 know of OCSP implementations, not changing
> >> = anything=20 in
> >>> terms of bits on the wire and = aligning the=20 Key ID with SKID
> >> in 5280 is
> = >>>=20 the best approach.   I do not think it will hurt=20 backward
> >> compatibility.
>=20 >>>
> >>> OCSP Responder and OCSP = client=20 vendors should speak up if I
> >> am = wrong.
>=20 >>>
> >>>> -----Original=20 Message-----
> >>>> From: Santosh = Chokhani
>=20 >>>> Sent: Tuesday, March 31, 2009 12:51 = PM
>=20 >>>> To: 'Massimiliano Pala'; IETF-pkix
>=20 >>>> Subject: RE: OCSP RFC (RFC 2560) Dependence = on=20 SHA-1
> >>>>
> >>>> = Max,
>=20 >>>>
> >>>> I do not see where = and=20 what extension we need to add for
> >> other=20 digest
> >>>> algorithm.
>=20 >>>>
> >>>> For key id, we = need to=20 enhance or broaden the options.
> = >>>>
>=20 >>>>> -----Original Message-----
>=20 >>>>> From: owner-ietf-pkix@mail.imc.org>=20 >>>>> [mailto:owner-ietf-pkix@mail.= imc.org]=20 On Behalf Of
> >> Massimiliano Pala
>=20 >>>>> Sent: Tuesday, March 31, 2009 1:37 = PM
>=20 >>>>> To: IETF-pkix
> = >>>>>=20 Subject: Re: OCSP RFC (RFC 2560) Dependence on SHA-1
> = >>>>>
> >>>>> Hi = all,
>=20 >>>>>
> >>>>> as I said = during=20 last meeting - as the use of SHA-1 does
> >>>> = not=20 have any
> >>>>> security implication = in the=20 OCSP, another viable way
> would be to
>=20 >>>>> define an extension where other digest=20 algorithms can be
> >>>> added to = the
>=20 >>>>> request/responses.
>=20 >>>>>
> >>>>> It is a = simple=20 addition and does not require any change in
> = >>>>=20 the RFC, it
> >>>>> can be done as a = separate=20 document for those who what to
> >> use = other
>=20 >>>>> digest algorithms.
>=20 >>>>>
> >>>>> After all, = isn't=20 this an example of why we allow
> >> extensions to=20 the
> >>>>> messages ?
>=20 >>>>>
> >>>>> = Later,
>=20 >>>>> Max
> = >>>>>
>=20 >>>>>
> >>>>> Santosh = Chokhani=20 wrote:
> >>>>>> Tom,
>=20 >>>>>>
> >>>>>> = Adding a=20 new choice and aligning it with 5280 SKID is fine.
>=20 >>>>>>
> >>>>>> I = would=20 not add anything about matching this field with
>=20 >>>>> anything since
> = >>>>>>=20 RFC 2560 does not say anything about it.
>=20 >>>>>>
> >>>>>> If one=20 were to add something, one should describe how this
>=20 >>>>> field can
> = >>>>>> be=20 used to select from multiple Responder certificates.
> = >>>>>>
> = >>>>>>>=20 -----Original Message-----
> = >>>>>>>=20 From: Tom Gindin [mailto:tgindin@us.ibm.com]
>= =20 >>>>>>> Sent: Monday, March 30, 2009 = 7:46=20 PM
> >>>>>>> To: Santosh = Chokhani
>=20 >>>>>>> Cc: IETF-pkix
>=20 >>>>>>> Subject: Re: OCSP RFC (RFC = 2560)=20 Dependence on SHA-1
> = >>>>>>>
>=20 >>>>>>>=20 =          Santosh:
>=20 >>>>>>>
> = >>>>>>>=20          The RFC 5280 = method=20 just describes "two common
> >>>> methods=20 for
> >>>>>>> generating key = identifiers=20 from the public key"
> >>>>>>> = and says=20 that other methods are acceptable. The comment
> = >>>>> to KeyHash
> = >>>>>>>=20 in RFC 2560 4.2.1 is not as permissive. Of course,=20 it's
> >>>> the same
>=20 >>>>>>> field as SKID, and I would = support=20 either stating "if the
> >>>>> KeyHash=20 is
> >>>>>>> not precisely 20 = octets=20 long, it should be matched
> against the
>=20 >>>>>>> Subject Key Identifier = extension of the=20 signing
> certificate" or
> = >>>>>>>=20 adding another choice like byID [3] OCTET STRING --
>=20 >>>>> matches the value
>=20 >>>>>>> of SKID.
>=20 >>>>>>>
>=20 >>>>>>>=20 =             &= nbsp;    Tom=20 Gindin
> >>>>>>>
>=20 >>>>>>> P.S. - The above opinions are = mine, and=20 not necessarily
> >>>>> those of = my
>=20 >>>>>>> employer
>=20 >>>>>>>
>=20 >>>>>>>
>=20 >>>>>>>
>=20 >>>>>>>
> = >>>>>>>=20 "Santosh Chokhani" <SChokhani@cygnacom.com> = Sent=20 by:
> >>>>>>> owner-ietf-pkix@mail.imc.org>=20 >>>>>>> 03/26/2009 10:39 PM
>=20 >>>>>>>
> = >>>>>>>=20 To
> >>>>>>> "IETF-pkix" <ietf-pkix@imc.org>
>=20 >>>>>>> cc
>=20 >>>>>>>
> >>>>>>>=20 Subject
> >>>>>>> OCSP RFC (RFC = 2560)=20 Dependence on SHA-1
> = >>>>>>>
>=20 >>>>>>>
>=20 >>>>>>>
>=20 >>>>>>>
>=20 >>>>>>>
>=20 >>>>>>>
>=20 >>>>>>>
> = >>>>>>>=20 RFC 2560 dependence on SHA-1 does not appear to be
>=20 >>>>> difficult to deal
>=20 >>>>>>> with.
>=20 >>>>>>>
> = >>>>>>>=20 Section 4.3 lists SHA-1 as mandatory and RSA as
>=20 >>>> optional.   We can
>=20 >>>>>>> update this to add SHA-2 series as=20 optional.
> >>>>>>>
>=20 >>>>>>> The Responder ID has SHA-1 = hardwired.=20 But, that is no
> >>>>> different = than
> >>>>>>> key ID extensions = in RFC=20 5280. Here are some options
> >> in order=20 of
> >>>>>>> preference:
>=20 >>>>>>>
> = >>>>>>> 1.=20 Align the language with subject key ID = language
> in RFC=20 5280.
> >>>>>>>
>=20 >>>>>>> 2. Keep on using SHA-1.=20 This field is not security
> = >>>>>=20 relevant. RFC
> >>>>>>> = 2560 does=20 not even describe how to use this field. So,
>=20 >>>>> having SHA-1
>=20 >>>>>>> and accidental or intentional=20 collisions will not hurt the
> >>>>>=20 security
> >>>>>>> of the=20 protocol.
> >>>>>>>
>=20 >>>>>>> 3. If you do not believe = in KISS=20 principle, you can
> >>>>> define=20 another
> >>>>>>> response type and = enhance=20 the key ID ASN.1 syntax so
> that hash
>=20 >>>>>>> algorithm is = identified.
>=20 >>>>>>>
> = >>>>>>> 4.=20   Another option is for the Responder to use the
> = same=20 hashing
> >>>>>>> algorithm as = the one in=20 the first certID entry.
> = >>>>>>>
>=20 >>>>>>>
> = >>>>>>>=20 Santosh Chokhani
> >>>>>>> = CygnaCom=20 Solutions
> >>>>>>>
>=20 >>>>>>>
>=20 >>>>>>>
>=20 >>>>>>>
>=20 >>>>>>
> = >>>>>>
>=20 >>>>>
> >>>>>
>=20 >>>>> --
> >>>>>
> = >>>>> Best Regards,
>=20 >>>>>
> >>>>> = Massimiliano=20 Pala
> >>>>>
> >>>>>=20 = --o-----------------------------------------------------------
&= gt;=20 >>>>> -------------
> = >>>>>=20 Massimiliano Pala [OpenCA Project Manager]
>=20 >>>>> Massimiliano.Pala@dartmouth.edu<= /A>
>=20 >>>>>=20 =             <= BR>>=20 >>>>> project.manager@openca.org
>= ;=20 >>>>>
> >>>>> Dartmouth = Computer=20 Science Dept=20 =             &= nbsp;  Home=20 Phone: +1
> >>>>> (603) 369-9332
>=20 >>>>> PKI/Trust Laboratory=20 =             &= nbsp;           &n= bsp; Work=20 Phone: +1
> >>>>> (603) 646-9179
>=20 >>>>>=20 = --o-----------------------------------------------------------
&= gt;=20 >>>>> -------------
>=20 >>>>>
> >>>>> People who = think=20 they know everything are a great annoyance
> = >>>>=20 to those
> >>>>> of us who do.
>=20 >>>>>   --
> = >>>>>=20 Isaac Asimov
> >>>>>
>=20 >>>>
> >>>
> = >>
>=20 >>
> >>
>=20 = >
>
>
>

------_=_NextPart_001_01C9B390.59C32388-- From owner-ietf-pkix@mail.imc.org Fri Apr 10 17:53:13 2009 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B610A3A689A for ; Fri, 10 Apr 2009 17:53:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.909 X-Spam-Level: X-Spam-Status: No, score=-0.909 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_96_XX=1.69] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ikot2N-5FgJw for ; Fri, 10 Apr 2009 17:53:13 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id A2FEB3A6889 for ; Fri, 10 Apr 2009 17:53:12 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3B0a2OJ047258 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Apr 2009 17:36:02 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3B0a2ng047257; Fri, 10 Apr 2009 17:36:02 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from eurymedon.net.ttu.edu (eurymedon.net.ttu.edu [129.118.1.225]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3B0a146047251 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Fri, 10 Apr 2009 17:36:01 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: from hyperbius.net.ttu.edu (129.118.1.214) by tmrc.ttu.edu (129.118.1.179) with Microsoft SMTP Server id 8.1.340.0; Fri, 10 Apr 2009 19:36:00 -0500 Received: from Pickup by hyperbius.net.ttu.edu with Microsoft SMTP Server id 8.1.340.0; Sat, 11 Apr 2009 00:36:00 +0000 X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Renew/Rekey/Modification Date: Thu, 2 Apr 2009 17:05:34 -0400 Message-ID: <200904022105.n32L5ZXD014427@stingray.missi.ncsc.mil> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Renew/Rekey/Modification Thread-Index: AcmydZMWT6hOmshVRjOIL4r3iaOQaAAlenSwACiN0dAACdj+0A== References: <49D2D476.3030000@lockstep.com.au>

From: "Kemp, David P." To: X-OriginalArrivalTime: 02 Apr 2009 21:00:25.0140 (UTC) FILETIME=[0B571740:01C9B3D6] List-Archive: List-ID: List-Unsubscribe: Received-SPF: None (emphytus.net.ttu.edu: owner-ietf-pkix@mail.imc.org does not designate permitted sender hosts) X-TechMail-Edge-Route: TTU Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: As Santosh said, if the old key is compromised and used first by an adversary to rekey, then the subscriber will detect the compromise when he tries to rekey and is rejected. If the subscriber rekeys first, then the adversary is out of luck. The subscriber could be allowed to spawn multiple new rekeyed certificates (such as generating an email encryption certificate based on a signature certificate) as long as the validity is not extended from old to new, but should be allowed only one rekey with a new validity period. -----Original Message----- From: EXT-Glatting, Dennis P >>=20 >> It should be. The goal here is to use the current certificate to >> authenticate to create new certificates. >>=20 > > I'm a little confused here. If we're getting rid of the key because it's > getting old, then how is it young enough to validate a new key? A > problem is there is an implicit "continuance of legacy" in the new key > of the old key that doesn't end with the immediate generation but > follows all generations of the original key. >=20 > I'm not suggesting something is "wrong" but there seems like there is a > logic error somewhere.=20 From owner-ietf-pkix@mail.imc.org Fri Apr 10 17:53:26 2009 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD6BF3A6A03 for ; Fri, 10 Apr 2009 17:53:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.091 X-Spam-Level: X-Spam-Status: No, score=0.091 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_96_XX=1.69, J_BACKHAIR_42=1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Go6KHS79yGNP for ; Fri, 10 Apr 2009 17:53:26 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id BB06C3A689A for ; Fri, 10 Apr 2009 17:53:25 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3B0bbki047376 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Apr 2009 17:37:37 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3B0bbuF047375; Fri, 10 Apr 2009 17:37:37 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from emphytus.net.ttu.edu (emphytus.net.ttu.edu [129.118.1.215]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3B0baIE047368 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Fri, 10 Apr 2009 17:37:37 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: from Pickup by emphytus.net.ttu.edu with Microsoft SMTP Server id 8.1.340.0; Sat, 11 Apr 2009 00:37:36 +0000 X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f X-BigFish: VPS-25(zz1432R98dR1805Mzz1202hzz1033ILz2dh6bh87il61h) X-Spam-TCS-SCL: 0:0 X-FB-DOMAIN-IP-MATCH: fail Message-ID: <49D4C40D.5040501@cs.tcd.ie> Date: Thu, 2 Apr 2009 14:56:29 +0100 From: Stephen Farrell User-Agent: Thunderbird 2.0.0.21 (X11/20090302) MIME-Version: 1.0 To: IETF-pkix Subject: Re: WG Last Call on draft-ietf-pkix-tac-03 References: In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-AntiVirus-Status: MessageID = A1743EE5B0A X-AntiVirus-Status: Host: imx2.tcd.ie X-AntiVirus-Status: Action Taken: X-AntiVirus-Status: NONE X-AntiVirus-Status: Checked by TCD Vexira. (version=1.60.2 VDF=10.102.30) List-Archive: List-ID: List-Unsubscribe: Received-SPF: None (emphytus.net.ttu.edu: owner-ietf-pkix@mail.imc.org does not designate permitted sender hosts) X-TechMail-Edge-Route: TTU Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Stefan Santesson wrote: > The authors of Traceable Anonymous Certificate > draft-ietf-pkix-tac-03.txt has requested WGLC. > > http://tools.ietf.org/html/draft-ietf-pkix-tac-03 > A couple of comments: #1: Top of p7: "To effect issuance of the TAC, the AI interacts with the BI, over a secure channel, to jointly create the signature on the TAC, and sends the signed TAC to the user. The AI does this without learning the user's real identity (either from the user or from the BI)." If the AI sends the TAC to the user, then it will know some form of identity for that user, even if that's only an IP address. (And with the likes of SAVI, that could well be enough to establish a real identity.) I'd have thought it'd be much better to return the TAC via the BI and not require any user<->AI direct connections? #2: Section 5.2 claims that the AI can't unilaterally fool the BI into revealing the real identity. But the only thing that stops that seems to be the RP client identity verified by the BI when the RP establishes a mutual-auth TLS connection to the BI. So how can the BI really know that its not the AI making that connection? Stephen. From owner-ietf-pkix@mail.imc.org Fri Apr 10 18:00:43 2009 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4BBE3A6928 for ; Fri, 10 Apr 2009 18:00:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.909 X-Spam-Level: X-Spam-Status: No, score=-0.909 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, DATE_IN_PAST_96_XX=1.69] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MiWlyEmmxIu3 for ; Fri, 10 Apr 2009 18:00:42 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 608FD3A684B for ; Fri, 10 Apr 2009 18:00:41 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3B0fZ2q047605 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Apr 2009 17:41:35 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3B0fZIj047604; Fri, 10 Apr 2009 17:41:35 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from euphorbus.net.ttu.edu (euphorbus.net.ttu.edu [129.118.1.216]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3B0fYl6047598 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Fri, 10 Apr 2009 17:41:34 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: from Pickup by euphorbus.net.ttu.edu with Microsoft SMTP Server id 8.1.340.0; Sat, 11 Apr 2009 00:41:33 +0000 X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: Renew/Rekey/Modification Date: Wed, 1 Apr 2009 17:00:50 -0400 Message-ID: In-Reply-To: <49D2D476.3030000@lockstep.com.au> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Renew/Rekey/Modification Thread-Index: AcmydZMWT6hOmshVRjOIL4r3iaOQaAAlenSw References: <49D2D476.3030000@lockstep.com.au> From: Santosh Chokhani To: , List-Archive: List-ID: List-Unsubscribe: Received-SPF: None (emphytus.net.ttu.edu: owner-ietf-pkix@mail.imc.org does not designate permitted sender hosts) X-TechMail-Edge-Route: TTU Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Stephen, See responses in-line.=20 > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org=20 > [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stephen Wilson > Sent: Tuesday, March 31, 2009 10:42 PM > To: ietf-pkix@imc.org > Subject: Renew/Rekey/Modification >=20 >=20 >=20 > Colleagues, >=20 > There are a few things about certificate "renewal" and=20 > "re-key" that have long confounded me. Things only seem to=20 > have got more convoluted in RFC 3647 and -- no offence! -- in=20 > newer Certificate Policies like the=20 > US FPKI Policy Authority document. Can anyone help me=20 > understand the=20 > rationale for the some of the following scenarios? Thanks in advance! >=20 >=20 >=20 > Re-key is said (in the FPKI CP) to be a good idea because the=20 > older a key gets, the more susceptible it is to loss and=20 > compromise. Fair enough, but why wouldn't that consideration=20 > be factored into the chosen certificate validity period? It should be. The goal here is to use the current certificate to authenticate to create new certificates. >=20 >=20 > Is there ever a real world scenario when a Subject would of=20 > their own accord request re-key because they feel the key is=20 > getting old? PKI obligations and policy may require that subject perform the re-key and take some concrete action in order to be bound to the subscriber obligations and agreements. > If so, why wouldn't they revoke as well? Two reasons come to mind for not revoking. You do not want to invalidate existing, unexpired signatures. You do not want to have built in mechanism for large CRL. BTW, you can compensate for it by destroying the current key after re-key. > The=20 > FPKI CA says that after re-key "The old certificate may or=20 > may not be revoked". Why would you not revoke, given the=20 > possibility that the key has got too old? See previous response. > I don't think it=20 > would ever be sensible to keep using an old original key and=20 > a fresh key. And if I were a Relying Party, I might like to=20 > know about this possible quality difference, yet there would=20 > be nothing in a CRL or anywhere else to mark the fact that=20 > the Subscriber has re-keyed. >=20 You do not need to use the old authentication/signature key. You do not need to revoke it either. You can simply destroy it. You do need to keep old decryption keys. >=20 > The FPKI CA goes on to say that after re-key "The old certificate ...=20 > must not be further re-keyed, renewed, or modified". This=20 > seems almost oxymoronic. Consider that I have certificate A=20 > and then I re-key A to create certificate B. And then I=20 > re-key B to create certificate C. I would say that C is=20 > indistinguishable from a re-keyed A since A, B and C will=20 > only differ by key value. So how is it meaningful to forbid=20 > re-keying A more than once?=20 >=20 Certificates are not the only objects. CA and RA can keep other information that can be used to enforce that A is used to rekey only once. >=20 > Finally, why does RFC 3647 bother to describe "Certificate=20 > Modification"=20 > at all? The term is inherently confusing since one of the=20 > most obvious characteristics of a digital certificate is that=20 > it cannot be tampered with. I question the need for a=20 > special bit of counter intuitive jargon (and a whole slab of=20 > the RFC) to cover what is really a mundane scenario; viz a=20 > certificate Subject needs a certificate with different=20 > details in it. That is, it's just a new certificate. Why is=20 > it treated any differently from an original certificate application? Certificate Modification (like renewal and rekey) refer to the fact that a new certificate with different information is created. If you feel that the term is confusing, let us know of a better term. As to why deal with differently that original certificate is that the modification may be carried out using fully or partly automated process based on the current certificate to be modified. That is why framework identifies this. Of course, many certificate policies require initial process for certificate modification. For that matter, policies do not permit renewal and some require initial process for rekey as well. The framework tries to accommodate many plausible scenarios. >=20 >=20 > Cheers, >=20 > Stephen Wilson > Lockstep Technologies > www.lockstep.com.au/technologies. >=20 >=20 >=20 From owner-ietf-pkix@mail.imc.org Fri Apr 10 18:40:21 2009 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBC613A6A98 for ; Fri, 10 Apr 2009 18:40:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.555 X-Spam-Level: X-Spam-Status: No, score=-10.555 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ld8gpTqamkaD for ; Fri, 10 Apr 2009 18:40:21 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 8C9893A6AEA for ; Fri, 10 Apr 2009 18:40:20 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3B1JKTd049515 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Apr 2009 18:19:20 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3B1JKhJ049514; Fri, 10 Apr 2009 18:19:20 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp.microsoft.com (maila.microsoft.com [131.107.115.212]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3B1J9KM049504 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 10 Apr 2009 18:19:20 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: from tk5-exhub-c103.redmond.corp.microsoft.com (157.54.88.96) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.99.4; Fri, 10 Apr 2009 18:19:09 -0700 Received: from tk5-exmlt-w601.wingroup.windeploy.ntdev.microsoft.com (157.54.18.32) by tk5-exhub-c103.redmond.corp.microsoft.com (157.54.88.96) with Microsoft SMTP Server id 8.2.99.4; Fri, 10 Apr 2009 18:19:08 -0700 Received: from Pickup by mail.windows.microsoft.com with Microsoft SMTP Server id 8.1.291.1; Sat, 11 Apr 2009 01:21:02 +0000 X-BigFish: ps-67(zz1432R98dR1447R1805Mzz2cfT1202hzzz2dheIL6bh34h) X-FB-SS: 5,13, X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Message-ID: <49DFA346.309@Dartmouth.edu> Date: Fri, 10 Apr 2009 15:51:34 -0400 From: Massimiliano Pala Organization: Dartmouth College - Computer Science Department User-Agent: Thunderbird 2.0.0.16 (X11/20080707) MIME-Version: 1.0 To: Sean Turner CC: pkix Subject: Re: PRQP: CMS Gateway References: <49DE7DC0.8050501@ieca.com> In-Reply-To: <49DE7DC0.8050501@ieca.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060001020207000203080301" X-Virus-Scanned: ClamAV 0.93.3/9223/Fri Apr 10 10:54:59 2009 on mail.cs.dartmouth.edu X-Virus-Status: Clean List-Archive: List-ID: List-Unsubscribe: Received-SPF: None (tk5-exgwy-e803.partners.extranet.microsoft.com: owner-ietf-pkix@mail.imc.org does not designate permitted sender hosts) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --------------ms060001020207000203080301 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Sean, thanks for the comments - I just modified the current draft version with the suggested changes. There are still some changes to be done for providing TAMP support via PRQP - but I think we will finalize them next week (I shall meet with Wallace at IDTrust) and we will be ready for updating the draft. Ciao, Max Sean Turner wrote: > > Max, > > Should the CMS Gateway be renamed CMC Gateway? CMM over CMS is CMC. > Also should the reference be updated to RFC 5272? --------------ms060001020207000203080301 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJIjCC BI0wggN1oAMCAQICAhpTMA0GCSqGSIb3DQEBBQUAMHcxEzARBgoJkiaJk/IsZAEZFgNlZHUx GTAXBgoJkiaJk/IsZAEZFglkYXJ0bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0 bW91dGggQ29sbGVnZTEcMBoGA1UEAxMTRGFydG1vdXRoIENlcnRBdXRoMTAeFw0wNTExMDgy MDMzMDZaFw0wOTExMDkyMDMzMDZaMIHBMRMwEQYKCZImiZPyLGQBGRYDZWR1MRkwFwYKCZIm iZPyLGQBGRYJZGFydG1vdXRoMQswCQYDVQQGEwJVUzEaMBgGA1UEChMRRGFydG1vdXRoIENv bGxlZ2UxGjAYBgoJkiaJk/IsZAEBEwoxMjI1NjAyOTQ3MRowGAYDVQQDExFNYXNzaW1pbGlh bm8gUGFsYTEuMCwGCSqGSIb3DQEJARYfTWFzc2ltaWxpYW5vLlBhbGFARGFydG1vdXRoLmVk dTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAsv8obBpbhPixgdyIJj7UN0GYRNhsgWHB muCE5j8v8IvCSJWRF9spKoR0NBYgOfJu8DwQuKTIgrvbp0EC3ikrneotL4KTGD1IqWz/bSXL UR/bZAsc0r9PrvCUsZOi7wbijy784gOuqQUCJ2fJwKwk5SJ3RBaPnUROQXTp+LPSK8MCAwEA AaOCAVowggFWMA4GA1UdDwEB/wQEAwIF4DARBglghkgBhvhCAQEEBAMCBaAwgaIGA1UdIASB mjCBlzCBlAYKKwYBBAFBAgEBATCBhTA9BggrBgEFBQcCAjAxMBgWEURhcnRtb3V0aCBDb2xs ZWdlMAMCAQEaFURhcnRtb3V0aCBDb2xsZWdlIENQUzBEBggrBgEFBQcCARY4aHR0cDovL3d3 dy5kYXJ0bW91dGguZWR1L35wa2lsYWIvRGFydG1vdXRoQ1BTXzRTZXAwMy5wZGYwKgYDVR0R BCMwIYEfTWFzc2ltaWxpYW5vLlBhbGFARGFydG1vdXRoLmVkdTAfBgNVHSMEGDAWgBQ/wNbH p08Afu8GmWdsvJYeTaN3EjA/BggrBgEFBQcBAQQzMDEwLwYIKwYBBQUHMAGGI2h0dHA6Ly9j b2xsZWdlY2EuZGFydG1vdXRoLmVkdS9vY3NwMA0GCSqGSIb3DQEBBQUAA4IBAQDEYIWmG3Ht wcgFiBbrYKp7YpI62hgAw9I3Dj9Ai+etQcMDZL8cWg3Kd7DwYHDkLxO7jl518HIJCk8Elk+Z 3Y2c0rR+c9WLuxE+EHEUmQg2AbgxzRGZAeMXj7jrv5w75IWiXBrW3SdDkjVH6MQFZVP1CBk7 PF3/+dzmiO6E5g4cVtphPSdK2qtnX7Sh0zdePzeE+e0BTnsWdN0yHgKabKx3dCiEnQXt96sA Jf5ckg7fFLcplohwWlWJCpk8WwnJM0QGw3xbrZvLk+kIQgyh0sn2va4FgA1ae29cJ1d2NurA Z+LMdei9/ZbzBeMoD9XPSYyj7zLuVXGLF/JQQoPywk5oMIIEjTCCA3WgAwIBAgICGlMwDQYJ KoZIhvcNAQEFBQAwdzETMBEGCgmSJomT8ixkARkWA2VkdTEZMBcGCgmSJomT8ixkARkWCWRh cnRtb3V0aDELMAkGA1UEBhMCVVMxGjAYBgNVBAoTEURhcnRtb3V0aCBDb2xsZWdlMRwwGgYD VQQDExNEYXJ0bW91dGggQ2VydEF1dGgxMB4XDTA1MTEwODIwMzMwNloXDTA5MTEwOTIwMzMw NlowgcExEzARBgoJkiaJk/IsZAEZFgNlZHUxGTAXBgoJkiaJk/IsZAEZFglkYXJ0bW91dGgx CzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91dGggQ29sbGVnZTEaMBgGCgmSJomT8ixk AQETCjEyMjU2MDI5NDcxGjAYBgNVBAMTEU1hc3NpbWlsaWFubyBQYWxhMS4wLAYJKoZIhvcN AQkBFh9NYXNzaW1pbGlhbm8uUGFsYUBEYXJ0bW91dGguZWR1MIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQCy/yhsGluE+LGB3IgmPtQ3QZhE2GyBYcGa4ITmPy/wi8JIlZEX2ykqhHQ0 FiA58m7wPBC4pMiCu9unQQLeKSud6i0vgpMYPUipbP9tJctRH9tkCxzSv0+u8JSxk6LvBuKP LvziA66pBQInZ8nArCTlIndEFo+dRE5BdOn4s9IrwwIDAQABo4IBWjCCAVYwDgYDVR0PAQH/ BAQDAgXgMBEGCWCGSAGG+EIBAQQEAwIFoDCBogYDVR0gBIGaMIGXMIGUBgorBgEEAUECAQEB MIGFMD0GCCsGAQUFBwICMDEwGBYRRGFydG1vdXRoIENvbGxlZ2UwAwIBARoVRGFydG1vdXRo IENvbGxlZ2UgQ1BTMEQGCCsGAQUFBwIBFjhodHRwOi8vd3d3LmRhcnRtb3V0aC5lZHUvfnBr aWxhYi9EYXJ0bW91dGhDUFNfNFNlcDAzLnBkZjAqBgNVHREEIzAhgR9NYXNzaW1pbGlhbm8u UGFsYUBEYXJ0bW91dGguZWR1MB8GA1UdIwQYMBaAFD/A1senTwB+7waZZ2y8lh5No3cSMD8G CCsGAQUFBwEBBDMwMTAvBggrBgEFBQcwAYYjaHR0cDovL2NvbGxlZ2VjYS5kYXJ0bW91dGgu ZWR1L29jc3AwDQYJKoZIhvcNAQEFBQADggEBAMRghaYbce3ByAWIFutgqntikjraGADD0jcO P0CL561BwwNkvxxaDcp3sPBgcOQvE7uOXnXwcgkKTwSWT5ndjZzStH5z1Yu7ET4QcRSZCDYB uDHNEZkB4xePuOu/nDvkhaJcGtbdJ0OSNUfoxAVlU/UIGTs8Xf/53OaI7oTmDhxW2mE9J0ra q2dftKHTN14/N4T57QFOexZ03TIeAppsrHd0KISdBe33qwAl/lySDt8UtymWiHBaVYkKmTxb CckzRAbDfFutm8uT6QhCDKHSyfa9rgWADVp7b1wnV3Y26sBn4sx16L39lvMF4ygP1c9JjKPv Mu5VcYsX8lBCg/LCTmgxggL4MIIC9AIBATB9MHcxEzARBgoJkiaJk/IsZAEZFgNlZHUxGTAX BgoJkiaJk/IsZAEZFglkYXJ0bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91 dGggQ29sbGVnZTEcMBoGA1UEAxMTRGFydG1vdXRoIENlcnRBdXRoMQICGlMwCQYFKw4DAhoF AKCCAdEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwNDEw MTk1MTM0WjAjBgkqhkiG9w0BCQQxFgQU6sIaueZuctLcZSuyQaXRyrLksUEwUgYJKoZIhvcN AQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYF Kw4DAgcwDQYIKoZIhvcNAwICASgwgYwGCSsGAQQBgjcQBDF/MH0wdzETMBEGCgmSJomT8ixk ARkWA2VkdTEZMBcGCgmSJomT8ixkARkWCWRhcnRtb3V0aDELMAkGA1UEBhMCVVMxGjAYBgNV BAoTEURhcnRtb3V0aCBDb2xsZWdlMRwwGgYDVQQDExNEYXJ0bW91dGggQ2VydEF1dGgxAgIa UzCBjgYLKoZIhvcNAQkQAgsxf6B9MHcxEzARBgoJkiaJk/IsZAEZFgNlZHUxGTAXBgoJkiaJ k/IsZAEZFglkYXJ0bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91dGggQ29s bGVnZTEcMBoGA1UEAxMTRGFydG1vdXRoIENlcnRBdXRoMQICGlMwDQYJKoZIhvcNAQEBBQAE gYASnb0jdWaklDHSPE/utWIC1HbZRm2QqHrI8PqXJ2ng/NZVn/zs4czzzXwFsKs+R/t8Ng/t 36hW7ujSRB8Tt7m3qqhSfsw64t5DQ+Ttan9uDofi+510lDjWWYL8keOybWw7t6pYXffR2f9N gRMTidCgYP/t7WQHi/pCw7BcZxmZ5QAAAAAAAA== --------------ms060001020207000203080301-- From owner-ietf-pkix@mail.imc.org Fri Apr 10 19:11:51 2009 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD7DA3A6D98 for ; Fri, 10 Apr 2009 19:11:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.908 X-Spam-Level: X-Spam-Status: No, score=-0.908 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, DATE_IN_PAST_96_XX=1.69, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bPHLtLhRJo4U for ; Fri, 10 Apr 2009 19:11:49 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 7AA6F3A6D85 for ; Fri, 10 Apr 2009 19:11:48 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3B1mKQe051149 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Apr 2009 18:48:20 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3B1mKCE051148; Fri, 10 Apr 2009 18:48:20 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from eurymedon.net.ttu.edu (eurymedon.net.ttu.edu [129.118.1.225]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3B1mIN8051138 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Fri, 10 Apr 2009 18:48:19 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: from hoplodamus.net.ttu.edu (129.118.1.213) by tmrc.ttu.edu (129.118.1.179) with Microsoft SMTP Server id 8.1.340.0; Fri, 10 Apr 2009 20:48:18 -0500 Received: from Pickup by hoplodamus.net.ttu.edu with Microsoft SMTP Server id 8.1.340.0; Sat, 11 Apr 2009 01:48:17 +0000 X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9B389.B83C96F2" X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: OCSP RFC (RFC 2560) Dependence on SHA-1 Date: Thu, 2 Apr 2009 07:54:02 -0400 Message-ID: In-Reply-To: <2788466ED3E31C418E9ACC5C3166155768B35D@mou1wnexmb09.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: OCSP RFC (RFC 2560) Dependence on SHA-1 Thread-Index: AcmyIGh4vURVLwB0QOmggx7xJi+ihAAAFOIwACx2HrAACXbF2QAB5FEQAAZrbKkABFxqQAAIVKC2AA7xVoA= References:

<2788466ED3E31C418E9ACC5C3166155768B35D@mou1wnexmb09.vcorp.ad.vrsn.com> From: Santosh Chokhani To: "Hallam-Baker, Phillip" , Stefan Santesson , IETF-pkix List-Archive: List-ID: List-Unsubscribe: Received-SPF: None (emphytus.net.ttu.edu: owner-ietf-pkix@mail.imc.org does not designate permitted sender hosts) X-TechMail-Edge-Route: TTU Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ------_=_NextPart_001_01C9B389.B83C96F2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have no objection to having an extension, but if in the long term SHA-1 will not be there, it seems defining a new response type (say basic 2) would be the way to go so that SHA-1 based key ID can be stripped off. =20 If SHA-1 is not getting ripped off in the long term, I do not see value in extension except that it may make every one happy: those who do not care will not include it on the Server side and/or will ignore it on the client side. =20 It would appear that the extension should be NC. =20 Phil, =20 I would not respond to the arguments on KISS and security since in this case both are straightforward. Also, in this thread, the comments were not meant for or directed at you. =20 As you know, I have provided extensive comments to you when you first posted the OCSP Agility I-D and my position and reasons are matter of PKIX archives for anyone to scrutinize. When you ignore every single cogent point, there is no sense in me commenting on next iteration. I do think that the OCSP Agility I-D is a solution looking for a problem that I do not see. ________________________________ From: Hallam-Baker, Phillip [mailto:pbaker@verisign.com]=20 Sent: Thursday, April 02, 2009 12:53 AM To: Santosh Chokhani; Stefan Santesson; IETF-pkix Subject: RE: OCSP RFC (RFC 2560) Dependence on SHA-1 =09 =09 I think we have no choice but to leave the Key ID CHOICE to be SHA-1 based. =20 But that does not preclude adding an extension that allows the KeyID to be specified using a stronger algorithm. There are two reasons for this: =20 1) Optics, even if there is no security implication, a protocol that uses weak crypto necessitates an (expensive) security review to prove that there is no problem. And these must be performed repeatedly by many different parties as relying on the analysis of others is a good way to cause issues. Been there, done that. =20 2) We are designing for long time spans, ten years or more. While simple compressor collisions may not be a concern, there is no guarantee that the attacks will stop at that point. MD4 has been broken repeatedly and they are now at the stage of jumping up and down on the little pieces. It will probably happen to MD5 and we should be cautious in case it happens to SHA-1. =20 =20 On the claim of 'Keep it simple STUPID', I find it rather offensive to have my position characterized as stupid. My designs are not exactly known for being verbose or overly elaborate. If I propose something it is because there is a reason. It is very easy to defend the status quo by derriding proposals as unnecessary, but the fact is that making OCSP too simple will simply cause the complexity to blow out somewhere else. =20 There is an architectural princple of modular design that demands that the core of PKIX as it now stands (the certificate profile and OCSP) be capable of stand alone use. We cannot fix issues in OCSP with LTANS or other layered-on protocols as some have proposed. It does not simplify my OCSP deployment to have to graft on an entire different protocol in addition or to re-engineer my document archival protocol to cover defects in OCSP. =20 =20 Simply adding new algorithms to a protocol does nothing to improve security. You only improve security if you withdraw insecure algorithms from use. =20 To make the system work you have to have a means of negotiating between the client and the server. Otherwise there is no way for an OCSP responder to ensure that it receives a secure, supported response to querries for certificates that do not exist yet or are not known to the responder. =20 In the case of an OCSP responder being driven by CRLs collected from various sources, there is no way for the CA to know if a certificate even exists, all it knows is if the status is definitively revoked. =20 In the case of many transactional architectures the OCSP validation is performed independently of certificate chain validation.=20 =20 =20 Experience of small scale PKI deployment in which any box can be upgraded at will is simply not representative of large scale real world deployment. =20 ________________________________ From: owner-ietf-pkix@mail.imc.org on behalf of Santosh Chokhani Sent: Wed 4/1/2009 8:39 PM To: Stefan Santesson; IETF-pkix Subject: RE: OCSP RFC (RFC 2560) Dependence on SHA-1 =09 =09 I am saying that "Do you agree that 2560 can be left alone for Responder ID's key ID CHOICE being SHA-1 based?" =09 > -----Original Message----- > From: Stefan Santesson [mailto:stefan@aaa-sec.com] > Sent: Wednesday, April 01, 2009 6:32 PM > To: Santosh Chokhani; IETF-pkix > Subject: Re: OCSP RFC (RFC 2560) Dependence on SHA-1 > > Santosh, > > In-line > > > On 4/1/09 10:31 PM, "Santosh Chokhani" wrote: > > > > > Stefan, > > > > See responses in-line. > > > >> -----Original Message----- > >> From: Stefan Santesson [mailto:stefan@aaa-sec.com] > >> Sent: Wednesday, April 01, 2009 2:34 PM > >> To: Santosh Chokhani; Massimiliano Pala; IETF-pkix > >> Subject: Re: OCSP RFC (RFC 2560) Dependence on SHA-1 > >> > >> Santosh, > >> > >> If you are talking about adding other options to calculate the > >> KeyHash value in ResponderID then I strongly disagree. > >> > >> If you add unspecified options you change the properties > of the field > >> from deterministic to a completely unknown value. > >> It does not matter if RFC2560 isn't explicit in its description of > >> the use of the field. The fact is that OCSP explicitly > defines this > >> value and as such will allow a client to deterministically compare > >> this value with the certificate selected to validate the response > >> signature. > > > > I hope no one is doing the matching of Responder ID with > hash of a key > > in place of responder signature verification. That would > be real bad. > > > > Yes it would. That is not at all what I talk about. But a > client could use this value to locate a responder certificate. > > >> If you allow > >> other ways to calculate the value but do not provide any means to > >> signal what method that was used, then this feature is lost. > > > > The most common use will be to use this field to prioritize the > > certificates of the responder to use for sigature > verification on the > > response. > > > > Do you know this for a fact, or are you guessing? > If a single implementation verifies that the certificate used > to validate the response matches the ResponderID value, and > choose to go into an error state because of mismatch, then we > have created great problems. So we can't guess. We have to > know that no single implementation will fail because of this. > And that may be very hard. > > > >> > >> In worst case we will cause current implementation to fail. > > > > That is why I am asking what problems if any will the vendors have. > > > > Even if no vendor speaks up here, it will not guarantee that > this will not create any problems. > > >> > >> I really don't think its worth the effort to change this field. We > >> have a very large base of implementations that we really > don't want > >> to mess up unless its absolutely necessary. > > > > So, we agree that leaving this field hard wired to SHA-1 is ok and > > 2560 can easily accommodate new hash functions. Right? > > > > I fail to understand this sentence. Despite reading it many > times over. > > > My only reason to align with 5280 is that if some one were > ever want > > to strip off SHA-1 altogether from their Responder or client, > > permitting other methods does it. > > > > I don't believe this argument is valid as I don't think it is > possible to strip off SHA-1 in any reasonable future. In any > case. If we compare the positive side with allowing this > change and the negative consequences to make OCSP > incompatible with itself, my choice is easy. > > /Stefan >=20 > > >> > >> As the only property of this field is to provide a convenient > >> identifier, it is far from absolutely necessary to change it. > >> Remember that there is a second choice to to identify responder by > >> name. For names we have accepted the possibility of collisions. In > >> that comparison, upgrading from SHA-1 is really redundant. > >> > >> /Stefan > >> > >> > >> > >> > >> On 4/1/09 4:05 PM, "Santosh Chokhani" > wrote: > >> > >>> > >>> My resident ASN.1 expert apprised me of the fact that > >> adding a choice > >>> will break backward compatibility. Thus, extension is a > >> fifth option > >>> (probably third in the priority). > >>> > >>> Based on what I know of OCSP implementations, not changing > >> anything in > >>> terms of bits on the wire and aligning the Key ID with SKID > >> in 5280 is > >>> the best approach. I do not think it will hurt backward > >> compatibility. > >>> > >>> OCSP Responder and OCSP client vendors should speak up if I > >> am wrong. > >>> > >>>> -----Original Message----- > >>>> From: Santosh Chokhani > >>>> Sent: Tuesday, March 31, 2009 12:51 PM > >>>> To: 'Massimiliano Pala'; IETF-pkix > >>>> Subject: RE: OCSP RFC (RFC 2560) Dependence on SHA-1 > >>>> > >>>> Max, > >>>> > >>>> I do not see where and what extension we need to add for > >> other digest > >>>> algorithm. > >>>> > >>>> For key id, we need to enhance or broaden the options. > >>>> > >>>>> -----Original Message----- > >>>>> From: owner-ietf-pkix@mail.imc.org > >>>>> [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of > >> Massimiliano Pala > >>>>> Sent: Tuesday, March 31, 2009 1:37 PM > >>>>> To: IETF-pkix > >>>>> Subject: Re: OCSP RFC (RFC 2560) Dependence on SHA-1 > >>>>> > >>>>> Hi all, > >>>>> > >>>>> as I said during last meeting - as the use of SHA-1 does > >>>> not have any > >>>>> security implication in the OCSP, another viable way > would be to > >>>>> define an extension where other digest algorithms can be > >>>> added to the > >>>>> request/responses. > >>>>> > >>>>> It is a simple addition and does not require any change in > >>>> the RFC, it > >>>>> can be done as a separate document for those who what to > >> use other > >>>>> digest algorithms. > >>>>> > >>>>> After all, isn't this an example of why we allow > >> extensions to the > >>>>> messages ? > >>>>> > >>>>> Later, > >>>>> Max > >>>>> > >>>>> > >>>>> Santosh Chokhani wrote: > >>>>>> Tom, > >>>>>> > >>>>>> Adding a new choice and aligning it with 5280 SKID is fine. > >>>>>> > >>>>>> I would not add anything about matching this field with > >>>>> anything since > >>>>>> RFC 2560 does not say anything about it. > >>>>>> > >>>>>> If one were to add something, one should describe how this > >>>>> field can > >>>>>> be used to select from multiple Responder certificates. > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: Tom Gindin [mailto:tgindin@us.ibm.com] > >>>>>>> Sent: Monday, March 30, 2009 7:46 PM > >>>>>>> To: Santosh Chokhani > >>>>>>> Cc: IETF-pkix > >>>>>>> Subject: Re: OCSP RFC (RFC 2560) Dependence on SHA-1 > >>>>>>> > >>>>>>> Santosh: > >>>>>>> > >>>>>>> The RFC 5280 method just describes "two common > >>>> methods for > >>>>>>> generating key identifiers from the public key" > >>>>>>> and says that other methods are acceptable. The comment > >>>>> to KeyHash > >>>>>>> in RFC 2560 4.2.1 is not as permissive. Of course, it's > >>>> the same > >>>>>>> field as SKID, and I would support either stating "if the > >>>>> KeyHash is > >>>>>>> not precisely 20 octets long, it should be matched > against the > >>>>>>> Subject Key Identifier extension of the signing > certificate" or > >>>>>>> adding another choice like byID [3] OCTET STRING -- > >>>>> matches the value > >>>>>>> of SKID. > >>>>>>> > >>>>>>> Tom Gindin > >>>>>>> > >>>>>>> P.S. - The above opinions are mine, and not necessarily > >>>>> those of my > >>>>>>> employer > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> "Santosh Chokhani" Sent by: > >>>>>>> owner-ietf-pkix@mail.imc.org > >>>>>>> 03/26/2009 10:39 PM > >>>>>>> > >>>>>>> To > >>>>>>> "IETF-pkix" > >>>>>>> cc > >>>>>>> > >>>>>>> Subject > >>>>>>> OCSP RFC (RFC 2560) Dependence on SHA-1 > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> RFC 2560 dependence on SHA-1 does not appear to be > >>>>> difficult to deal > >>>>>>> with. > >>>>>>> > >>>>>>> Section 4.3 lists SHA-1 as mandatory and RSA as > >>>> optional. We can > >>>>>>> update this to add SHA-2 series as optional. > >>>>>>> > >>>>>>> The Responder ID has SHA-1 hardwired. But, that is no > >>>>> different than > >>>>>>> key ID extensions in RFC 5280. Here are some options > >> in order of > >>>>>>> preference: > >>>>>>> > >>>>>>> 1. Align the language with subject key ID language > in RFC 5280. > >>>>>>> > >>>>>>> 2. Keep on using SHA-1. This field is not security > >>>>> relevant. RFC > >>>>>>> 2560 does not even describe how to use this field. So, > >>>>> having SHA-1 > >>>>>>> and accidental or intentional collisions will not hurt the > >>>>> security > >>>>>>> of the protocol. > >>>>>>> > >>>>>>> 3. If you do not believe in KISS principle, you can > >>>>> define another > >>>>>>> response type and enhance the key ID ASN.1 syntax so > that hash > >>>>>>> algorithm is identified. > >>>>>>> > >>>>>>> 4. Another option is for the Responder to use the > same hashing > >>>>>>> algorithm as the one in the first certID entry. > >>>>>>> > >>>>>>> > >>>>>>> Santosh Chokhani > >>>>>>> CygnaCom Solutions > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> > >>>>> Best Regards, > >>>>> > >>>>> Massimiliano Pala > >>>>> > >>>>> --o----------------------------------------------------------- > >>>>> ------------- > >>>>> Massimiliano Pala [OpenCA Project Manager] > >>>>> Massimiliano.Pala@dartmouth.edu > >>>>> =20 > >>>>> project.manager@openca.org > >>>>> > >>>>> Dartmouth Computer Science Dept Home Phone: +1 > >>>>> (603) 369-9332 > >>>>> PKI/Trust Laboratory Work Phone: +1 > >>>>> (603) 646-9179 > >>>>> --o----------------------------------------------------------- > >>>>> ------------- > >>>>> > >>>>> People who think they know everything are a great annoyance > >>>> to those > >>>>> of us who do. > >>>>> -- > >>>>> Isaac Asimov > >>>>> > >>>> > >>> > >> > >> > >> > > > > > =09 =09 ------_=_NextPart_001_01C9B389.B83C96F2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: OCSP RFC (RFC 2560) Dependence on = SHA-1

I have no objection to having an extension, but if = in the long=20 term SHA-1 will not be there, it seems defining a new response type (say = basic=20 2) would be the way to go so that SHA-1 based key ID can be stripped=20 off.

If SHA-1 is not getting ripped off in the long = term, I do=20 not see value in extension except that it may make every one happy: = those who do=20 not care will not include it on the Server side and/or will ignore = it on=20 the client side.

It would appear that the extension should be=20 NC.

Phil,

I would not respond to the arguments on KISS and = security=20 since in this case both are straightforward. Also, in this thread, = the=20 comments were not meant for or directed at you.

As you know, I have provided extensive comments to = you when=20 you first posted the OCSP Agility I-D and my position and reasons are = matter of=20 PKIX archives for anyone to scrutinize. When you ignore every = single=20 cogent point, there is no sense in me commenting on next = iteration. I do=20 think that the OCSP Agility I-D is a solution looking for a problem that = I do=20 not see.

From: Hallam-Baker, Phillip=20 [mailto:pbaker@verisign.com]
Sent: Thursday, April 02, 2009 = 12:53=20 AM
To: Santosh Chokhani; Stefan Santesson;=20 IETF-pkix
Subject: RE: OCSP RFC (RFC 2560) Dependence on=20 SHA-1

I think we = have no choice=20 but to leave the Key ID CHOICE to be SHA-1 based.

But that does not preclude = adding an=20 extension that allows the KeyID to be specified using a stronger = algorithm.=20 There are two reasons for this:

1) Optics, even if there is = no security=20 implication, a protocol that uses weak crypto necessitates an = (expensive)=20 security review to prove that there is no problem. And these must be = performed=20 repeatedly by many different parties as relying on the analysis of = others is a=20 good way to cause issues. Been there, done that.

2) We are designing for = long time spans,=20 ten years or more. While simple compressor collisions may not be a = concern,=20 there is no guarantee that the attacks will stop at that point. MD4 = has been=20 broken repeatedly and they are now at the stage of jumping up and down = on the=20 little pieces. It will probably happen to MD5 and we should be = cautious in=20 case it happens to SHA-1.

On the claim of 'Keep it = simple STUPID',=20 I find it rather offensive to have my position characterized as = stupid. My=20 designs are not exactly known for being verbose or overly elaborate. = If I=20 propose something it is because there is a reason. It is very easy to = defend=20 the status quo by derriding proposals as unnecessary, but the fact is = that=20 making OCSP too simple will simply cause the complexity to blow out = somewhere=20 else.

There is an architectural = princple of=20 modular design that demands that the core of PKIX as it now stands = (the=20 certificate profile and OCSP) be capable of stand alone use. We cannot = fix=20 issues in OCSP with LTANS or other layered-on protocols as some have = proposed.=20 It does not simplify my OCSP deployment to have to graft on an entire=20 different protocol in addition or to re-engineer my document archival = protocol=20 to cover defects in OCSP.

Simply adding new = algorithms to a=20 protocol does nothing to improve security. You only improve security = if you=20 withdraw insecure algorithms from use.

To make the system work you = have to have=20 a means of negotiating between the client and the server. Otherwise = there is=20 no way for an OCSP responder to ensure that it receives a secure,=20 supported response to querries for certificates that do not exist = yet or=20 are not known to the responder.

In the case of an OCSP = responder being=20 driven by CRLs collected from various sources, there is no way for the = CA to=20 know if a certificate even exists, all it knows is if the status is=20 definitively revoked.

In the case of many = transactional=20 architectures the OCSP validation is performed independently of = certificate=20 chain validation.

Experience of small scale = PKI deployment=20 in which any box can be upgraded at will is simply not representative = of large=20 scale real world deployment.

From:=20 owner-ietf-pkix@mail.imc.org on behalf of Santosh = Chokhani
Sent: Wed=20 4/1/2009 8:39 PM
To: Stefan Santesson; = IETF-pkix
Subject:=20 RE: OCSP RFC (RFC 2560) Dependence on SHA-1

I am saying that "Do you agree that 2560 can be left = alone for=20 Responder
ID's key ID CHOICE being SHA-1 based?"

> = -----Original=20 Message-----
> From: Stefan Santesson [mailto:stefan@aaa-sec.com]
>= Sent:=20 Wednesday, April 01, 2009 6:32 PM
> To: Santosh Chokhani;=20 IETF-pkix
> Subject: Re: OCSP RFC (RFC 2560) Dependence on=20 SHA-1
>
> Santosh,
>
> = In-line
>
>
>=20 On 4/1/09 10:31 PM, "Santosh Chokhani" <SChokhani@cygnacom.com>=20 wrote:
>
> >
> > Stefan,
> >
> = > See=20 responses in-line.
> >
> >> -----Original=20 Message-----
> >> From: Stefan Santesson [mailto:stefan@aaa-sec.com]
>= =20 >> Sent: Wednesday, April 01, 2009 2:34 PM
> >> To: = Santosh=20 Chokhani; Massimiliano Pala; IETF-pkix
> >> Subject: Re: = OCSP RFC=20 (RFC 2560) Dependence on SHA-1
> >>
> >>=20 Santosh,
> >>
> >> If you are talking about = adding=20 other options to calculate the
> >> KeyHash value in = ResponderID=20 then I strongly disagree.
> >>
> >> If you add = unspecified options you change the properties
> of the = field
>=20 >> from deterministic to a completely unknown value.
> = >> It=20 does not matter if RFC2560 isn't explicit in its description = of
>=20 >> the use of the field. The fact is that OCSP = explicitly
>=20 defines this
> >> value and as such will allow a client to = deterministically compare
> >> this value with the = certificate=20 selected to validate the response
> >> signature.
>=20 >
> > I hope no one is doing the matching of Responder ID=20 with
> hash of a key
> > in place of responder = signature=20 verification. That would
> be real bad.
>=20 >
>
> Yes it would. That is not at all what I talk = about. But=20 a
> client could use this value to locate a responder=20 certificate.
>
> >> If you allow
> >> = other ways=20 to calculate the value but do not provide any means to
> = >> signal=20 what method that was used, then this feature is lost.
> = >
>=20 > The most common use will be to use this field to prioritize = the
>=20 > certificates of the responder to use for sigature
> = verification on=20 the
> > response.
> >
>
> Do you know = this for a=20 fact, or are you guessing?
> If a single implementation verifies = that=20 the certificate used
> to validate the response matches the = ResponderID=20 value, and
> choose to go into an error state because of = mismatch, then=20 we
> have created great problems. So we can't guess. We have = to
>=20 know that no single implementation will fail because of this.
> = And that=20 may be very hard.
>
>
> >>
> >> In = worst=20 case we will cause current implementation to fail.
> = >
> >=20 That is why I am asking what problems if any will the vendors = have.
>=20 >
>
> Even if no vendor speaks up here, it will not = guarantee=20 that
> this will not create any problems.
>
>=20 >>
> >> I really don't think its worth the effort to = change=20 this field. We
> >> have a very large base of = implementations that=20 we really
> don't want
> >> to mess up unless its = absolutely=20 necessary.
> >
> > So, we agree that leaving this = field hard=20 wired to SHA-1 is ok and
> > 2560 can easily accommodate new = hash=20 functions. Right?
> >
>
> I fail to = understand this=20 sentence. Despite reading it many
> times over.
>
> = > My=20 only reason to align with 5280 is that if some one were
> ever=20 want
> > to strip off SHA-1 altogether from their Responder = or=20 client,
> > permitting other methods does it.
>=20 >
>
> I don't believe this argument is valid as I don't = think=20 it is
> possible to strip off SHA-1 in any reasonable future. In = any
> case. If we compare the positive side with allowing = this
>=20 change and the negative consequences to make OCSP
> incompatible = with=20 itself, my choice is easy.
>
>=20 /Stefan
>
>
> >>
> >> As the = only=20 property of this field is to provide a convenient
> >> = identifier,=20 it is far from absolutely necessary to change it.
> >> = Remember=20 that there is a second choice to to identify responder by
> = >>=20 name. For names we have accepted the possibility of collisions. = In
>=20 >> that comparison, upgrading from SHA-1 is really = redundant.
>=20 >>
> >> /Stefan
> >>
> = >>
>=20 >>
> >>
> >> On 4/1/09 4:05 PM, "Santosh = Chokhani"
> <SChokhani@cygnacom.com> wrote:
>=20 >>
> >>>
> >>> My resident ASN.1 = expert=20 apprised me of the fact that
> >> adding a choice
>=20 >>> will break backward compatibility. Thus, extension = is=20 a
> >> fifth option
> >>> (probably third = in the=20 priority).
> >>>
> >>> Based on what I = know of=20 OCSP implementations, not changing
> >> anything = in
>=20 >>> terms of bits on the wire and aligning the Key ID with=20 SKID
> >> in 5280 is
> >>> the best = approach. =20 I do not think it will hurt backward
> >> = compatibility.
>=20 >>>
> >>> OCSP Responder and OCSP client = vendors=20 should speak up if I
> >> am wrong.
> = >>>
>=20 >>>> -----Original Message-----
> >>>> = From:=20 Santosh Chokhani
> >>>> Sent: Tuesday, March 31, = 2009 12:51=20 PM
> >>>> To: 'Massimiliano Pala'; IETF-pkix
> = >>>> Subject: RE: OCSP RFC (RFC 2560) Dependence on = SHA-1
>=20 >>>>
> >>>> Max,
>=20 >>>>
> >>>> I do not see where and what=20 extension we need to add for
> >> other digest
>=20 >>>> algorithm.
> >>>>
> = >>>>=20 For key id, we need to enhance or broaden the options.
>=20 >>>>
> >>>>> -----Original=20 Message-----
> >>>>> From:=20 owner-ietf-pkix@mail.imc.org
> >>>>> [mailto:owner-ietf-pkix@mail.= imc.org]=20 On Behalf Of
> >> Massimiliano Pala
> = >>>>>=20 Sent: Tuesday, March 31, 2009 1:37 PM
> >>>>> To: = IETF-pkix
> >>>>> Subject: Re: OCSP RFC (RFC = 2560)=20 Dependence on SHA-1
> >>>>>
> = >>>>>=20 Hi all,
> >>>>>
> >>>>> as I = said=20 during last meeting - as the use of SHA-1 does
> = >>>> not=20 have any
> >>>>> security implication in the = OCSP,=20 another viable way
> would be to
> >>>>> = define an=20 extension where other digest algorithms can be
> = >>>> added=20 to the
> >>>>> request/responses.
>=20 >>>>>
> >>>>> It is a simple = addition and=20 does not require any change in
> >>>> the RFC, = it
>=20 >>>>> can be done as a separate document for those who = what=20 to
> >> use other
> >>>>> digest=20 algorithms.
> >>>>>
> >>>>> = After=20 all, isn't this an example of why we allow
> >> extensions = to=20 the
> >>>>> messages ?
>=20 >>>>>
> >>>>> Later,
>=20 >>>>> Max
> >>>>>
>=20 >>>>>
> >>>>> Santosh Chokhani=20 wrote:
> >>>>>> Tom,
>=20 >>>>>>
> >>>>>> Adding a new = choice=20 and aligning it with 5280 SKID is fine.
>=20 >>>>>>
> >>>>>> I would not = add=20 anything about matching this field with
> >>>>> = anything=20 since
> >>>>>> RFC 2560 does not say anything = about=20 it.
> >>>>>>
> >>>>>> = If one=20 were to add something, one should describe how this
>=20 >>>>> field can
> >>>>>> be = used to=20 select from multiple Responder certificates.
>=20 >>>>>>
> >>>>>>> = -----Original=20 Message-----
> >>>>>>> From: Tom Gindin [mailto:tgindin@us.ibm.com]
>= =20 >>>>>>> Sent: Monday, March 30, 2009 7:46 = PM
>=20 >>>>>>> To: Santosh Chokhani
>=20 >>>>>>> Cc: IETF-pkix
>=20 >>>>>>> Subject: Re: OCSP RFC (RFC 2560) = Dependence on=20 SHA-1
> >>>>>>>
>=20 = >>>>>>>       &nb= sp;=20 Santosh:
> >>>>>>>
>=20 = >>>>>>>       &nb= sp;=20 The RFC 5280 method just describes "two common
> = >>>>=20 methods for
> >>>>>>> generating key = identifiers=20 from the public key"
> >>>>>>> and says = that other=20 methods are acceptable. The comment
> >>>>> = to=20 KeyHash
> >>>>>>> in RFC 2560 4.2.1 is not = as=20 permissive. Of course, it's
> >>>> the = same
>=20 >>>>>>> field as SKID, and I would support either = stating=20 "if the
> >>>>> KeyHash is
>=20 >>>>>>> not precisely 20 octets long, it should = be=20 matched
> against the
> >>>>>>> = Subject Key=20 Identifier extension of the signing
> certificate" or
>=20 >>>>>>> adding another choice like byID [3] OCTET = STRING=20 --
> >>>>> matches the value
>=20 >>>>>>> of SKID.
>=20 >>>>>>>
>=20 = >>>>>>>       &nb= sp;        =20 Tom Gindin
> >>>>>>>
>=20 >>>>>>> P.S. - The above opinions are mine, and = not=20 necessarily
> >>>>> those of my
>=20 >>>>>>> employer
>=20 >>>>>>>
> = >>>>>>>
>=20 >>>>>>>
> = >>>>>>>
>=20 >>>>>>> "Santosh Chokhani" = <SChokhani@cygnacom.com>=20 Sent by:
> >>>>>>>=20 owner-ietf-pkix@mail.imc.org
> >>>>>>> = 03/26/2009=20 10:39 PM
> >>>>>>>
>=20 >>>>>>> To
> >>>>>>>=20 "IETF-pkix" <ietf-pkix@imc.org>
> = >>>>>>>=20 cc
> >>>>>>>
> = >>>>>>>=20 Subject
> >>>>>>> OCSP RFC (RFC 2560) = Dependence on=20 SHA-1
> >>>>>>>
>=20 >>>>>>>
> = >>>>>>>
>=20 >>>>>>>
> = >>>>>>>
>=20 >>>>>>>
> = >>>>>>>
>=20 >>>>>>> RFC 2560 dependence on SHA-1 does not = appear to=20 be
> >>>>> difficult to deal
>=20 >>>>>>> with.
>=20 >>>>>>>
> >>>>>>> = Section 4.3=20 lists SHA-1 as mandatory and RSA as
> >>>> = optional. =20 We can
> >>>>>>> update this to add SHA-2 = series as=20 optional.
> >>>>>>>
>=20 >>>>>>> The Responder ID has SHA-1 = hardwired. But,=20 that is no
> >>>>> different than
>=20 >>>>>>> key ID extensions in RFC 5280. Here = are=20 some options
> >> in order of
> = >>>>>>>=20 preference:
> >>>>>>>
>=20 >>>>>>> 1. Align the language with subject = key ID=20 language
> in RFC 5280.
> = >>>>>>>
>=20 >>>>>>> 2. Keep on using SHA-1. This = field is=20 not security
> >>>>> relevant. RFC
>=20 >>>>>>> 2560 does not even describe how to use = this=20 field. So,
> >>>>> having SHA-1
>=20 >>>>>>> and accidental or intentional collisions = will not=20 hurt the
> >>>>> security
>=20 >>>>>>> of the protocol.
>=20 >>>>>>>
> >>>>>>> = 3. If=20 you do not believe in KISS principle, you can
> = >>>>>=20 define another
> >>>>>>> response type and = enhance=20 the key ID ASN.1 syntax so
> that hash
>=20 >>>>>>> algorithm is identified.
>=20 >>>>>>>
> >>>>>>> = 4. =20 Another option is for the Responder to use the
> same = hashing
>=20 >>>>>>> algorithm as the one in the first certID=20 entry.
> >>>>>>>
>=20 >>>>>>>
> >>>>>>> = Santosh=20 Chokhani
> >>>>>>> CygnaCom = Solutions
>=20 >>>>>>>
> = >>>>>>>
>=20 >>>>>>>
> = >>>>>>>
>=20 >>>>>>
> >>>>>>
>=20 >>>>>
> >>>>>
> = >>>>>=20 --
> >>>>>
> >>>>> Best=20 Regards,
> >>>>>
> >>>>>=20 Massimiliano Pala
> >>>>>
> = >>>>>=20 --o-----------------------------------------------------------
> = >>>>> -------------
> >>>>> = Massimiliano=20 Pala [OpenCA Project Manager]
> >>>>>=20 Massimiliano.Pala@dartmouth.edu
>=20 = >>>>>         = ;
>=20 >>>>> project.manager@openca.org
>=20 >>>>>
> >>>>> Dartmouth Computer = Science=20 = Dept           &nb= sp;  =20 Home Phone: +1
> >>>>> (603) 369-9332
>=20 >>>>> PKI/Trust=20 = Laboratory          &nb= sp;           &nbs= p;  =20 Work Phone: +1
> >>>>> (603) 646-9179
>=20 >>>>>=20 --o-----------------------------------------------------------
> = >>>>> -------------
> = >>>>>
>=20 >>>>> People who think they know everything are a great = annoyance
> >>>> to those
> = >>>>> of us=20 who do.
> >>>>>   --
>=20 >>>>> Isaac Asimov
> >>>>>
> = >>>>
> >>>
> >>
>=20 >>
> >>
>=20 = >
>
>
>

= ------_=_NextPart_001_01C9B389.B83C96F2-- From owner-ietf-pkix@mail.imc.org Fri Apr 10 20:27:45 2009 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54FAE3A6DBF for ; Fri, 10 Apr 2009 20:27:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.488 X-Spam-Level: X-Spam-Status: No, score=0.488 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_96_XX=1.69, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dheoRJa--So6 for ; Fri, 10 Apr 2009 20:27:42 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 107163A6D9A for ; Fri, 10 Apr 2009 20:27:41 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3B2xWGP054274 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Apr 2009 19:59:32 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3B2xWhS054273; Fri, 10 Apr 2009 19:59:32 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from eurymedon.net.ttu.edu (eurymedon.net.ttu.edu [129.118.1.225]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3B2xLcR054260 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Fri, 10 Apr 2009 19:59:31 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: from hoplodamus.net.ttu.edu (129.118.1.213) by tmrc.ttu.edu (129.118.1.179) with Microsoft SMTP Server id 8.1.340.0; Fri, 10 Apr 2009 21:59:20 -0500 Received: from Pickup by hoplodamus.net.ttu.edu with Microsoft SMTP Server id 8.1.340.0; Sat, 11 Apr 2009 02:59:19 +0000 X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9B39A.1397BF01" Subject: RE: OCSP RFC (RFC 2560) Dependence on SHA-1 Date: Thu, 2 Apr 2009 06:47:45 -0700 Message-ID: <2788466ED3E31C418E9ACC5C3166155768B35F@mou1wnexmb09.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: OCSP RFC (RFC 2560) Dependence on SHA-1 thread-index: AcmyIGh4vURVLwB0QOmggx7xJi+ihAAAFOIwACx2HrAACXbF2QAB5FEQAAZrbKkABFxqQAAIVKC2AA7xVoAABFiEVA== References:

<2788466ED3E31C418E9ACC5C3166155768B35D@mou1wnexmb09.vcorp.ad.vrsn.com> From: "Hallam-Baker, Phillip" To: Santosh Chokhani , Stefan Santesson , IETF-pkix X-OriginalArrivalTime: 02 Apr 2009 13:51:09.0810 (UTC) FILETIME=[13F79D20:01C9B39A] List-Archive: List-ID: List-Unsubscribe: Received-SPF: None (emphytus.net.ttu.edu: owner-ietf-pkix@mail.imc.org does not designate permitted sender hosts) X-TechMail-Edge-Route: TTU Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ------_=_NextPart_001_01C9B39A.1397BF01 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On the contrary, each time I asked for a substantive argument you used = exactly the same non argument you are using here. =20 I have put a substantive argument on the table here. "I am not = convinced" or "I answered the question some other time" with no links to = the specific points are not a substantive response. You may think that = you gave a substantive explanation of how a client that only supports = ECC can obtain a comprehensible response from a generic OCSP server that = also supports RSA. However I do not beleive that it is possible in the = current protocol. =20 If you think you have demonstrated this in the past then please point to = the email. =20 ________________________________ From: Santosh Chokhani [mailto:SChokhani@cygnacom.com] Sent: Thu 4/2/2009 7:54 AM To: Hallam-Baker, Phillip; Stefan Santesson; IETF-pkix Subject: RE: OCSP RFC (RFC 2560) Dependence on SHA-1 I have no objection to having an extension, but if in the long term = SHA-1 will not be there, it seems defining a new response type (say = basic 2) would be the way to go so that SHA-1 based key ID can be = stripped off. =20 If SHA-1 is not getting ripped off in the long term, I do not see value = in extension except that it may make every one happy: those who do not = care will not include it on the Server side and/or will ignore it on the = client side. =20 It would appear that the extension should be NC. =20 Phil, =20 I would not respond to the arguments on KISS and security since in this = case both are straightforward. Also, in this thread, the comments were = not meant for or directed at you. =20 As you know, I have provided extensive comments to you when you first = posted the OCSP Agility I-D and my position and reasons are matter of = PKIX archives for anyone to scrutinize. When you ignore every single = cogent point, there is no sense in me commenting on next iteration. I = do think that the OCSP Agility I-D is a solution looking for a problem = that I do not see. ________________________________ From: Hallam-Baker, Phillip [mailto:pbaker@verisign.com]=20 Sent: Thursday, April 02, 2009 12:53 AM To: Santosh Chokhani; Stefan Santesson; IETF-pkix Subject: RE: OCSP RFC (RFC 2560) Dependence on SHA-1 =09 =09 I think we have no choice but to leave the Key ID CHOICE to be SHA-1 = based. =20 But that does not preclude adding an extension that allows the KeyID to = be specified using a stronger algorithm. There are two reasons for this: =20 1) Optics, even if there is no security implication, a protocol that = uses weak crypto necessitates an (expensive) security review to prove = that there is no problem. And these must be performed repeatedly by many = different parties as relying on the analysis of others is a good way to = cause issues. Been there, done that. =20 2) We are designing for long time spans, ten years or more. While = simple compressor collisions may not be a concern, there is no guarantee = that the attacks will stop at that point. MD4 has been broken repeatedly = and they are now at the stage of jumping up and down on the little = pieces. It will probably happen to MD5 and we should be cautious in case = it happens to SHA-1. =20 =20 On the claim of 'Keep it simple STUPID', I find it rather offensive to = have my position characterized as stupid. My designs are not exactly = known for being verbose or overly elaborate. If I propose something it = is because there is a reason. It is very easy to defend the status quo = by derriding proposals as unnecessary, but the fact is that making OCSP = too simple will simply cause the complexity to blow out somewhere else. =20 There is an architectural princple of modular design that demands that = the core of PKIX as it now stands (the certificate profile and OCSP) be = capable of stand alone use. We cannot fix issues in OCSP with LTANS or = other layered-on protocols as some have proposed. It does not simplify = my OCSP deployment to have to graft on an entire different protocol in = addition or to re-engineer my document archival protocol to cover = defects in OCSP. =20 =20 Simply adding new algorithms to a protocol does nothing to improve = security. You only improve security if you withdraw insecure algorithms = from use. =20 To make the system work you have to have a means of negotiating between = the client and the server. Otherwise there is no way for an OCSP = responder to ensure that it receives a secure, supported response to = querries for certificates that do not exist yet or are not known to the = responder. =20 In the case of an OCSP responder being driven by CRLs collected from = various sources, there is no way for the CA to know if a certificate = even exists, all it knows is if the status is definitively revoked. =20 In the case of many transactional architectures the OCSP validation is = performed independently of certificate chain validation.=20 =20 =20 Experience of small scale PKI deployment in which any box can be = upgraded at will is simply not representative of large scale real world = deployment. =20 ________________________________ From: owner-ietf-pkix@mail.imc.org on behalf of Santosh Chokhani Sent: Wed 4/1/2009 8:39 PM To: Stefan Santesson; IETF-pkix Subject: RE: OCSP RFC (RFC 2560) Dependence on SHA-1 =09 =09 I am saying that "Do you agree that 2560 can be left alone for = Responder ID's key ID CHOICE being SHA-1 based?" =09 > -----Original Message----- > From: Stefan Santesson [mailto:stefan@aaa-sec.com] > Sent: Wednesday, April 01, 2009 6:32 PM > To: Santosh Chokhani; IETF-pkix > Subject: Re: OCSP RFC (RFC 2560) Dependence on SHA-1 > > Santosh, > > In-line > > > On 4/1/09 10:31 PM, "Santosh Chokhani" = wrote: > > > > > Stefan, > > > > See responses in-line. > > > >> -----Original Message----- > >> From: Stefan Santesson [mailto:stefan@aaa-sec.com] > >> Sent: Wednesday, April 01, 2009 2:34 PM > >> To: Santosh Chokhani; Massimiliano Pala; IETF-pkix > >> Subject: Re: OCSP RFC (RFC 2560) Dependence on SHA-1 > >> > >> Santosh, > >> > >> If you are talking about adding other options to calculate the > >> KeyHash value in ResponderID then I strongly disagree. > >> > >> If you add unspecified options you change the properties > of the field > >> from deterministic to a completely unknown value. > >> It does not matter if RFC2560 isn't explicit in its description of > >> the use of the field. The fact is that OCSP explicitly > defines this > >> value and as such will allow a client to deterministically compare > >> this value with the certificate selected to validate the response > >> signature. > > > > I hope no one is doing the matching of Responder ID with > hash of a key > > in place of responder signature verification. That would > be real bad. > > > > Yes it would. That is not at all what I talk about. But a > client could use this value to locate a responder certificate. > > >> If you allow > >> other ways to calculate the value but do not provide any means to > >> signal what method that was used, then this feature is lost. > > > > The most common use will be to use this field to prioritize the > > certificates of the responder to use for sigature > verification on the > > response. > > > > Do you know this for a fact, or are you guessing? > If a single implementation verifies that the certificate used > to validate the response matches the ResponderID value, and > choose to go into an error state because of mismatch, then we > have created great problems. So we can't guess. We have to > know that no single implementation will fail because of this. > And that may be very hard. > > > >> > >> In worst case we will cause current implementation to fail. > > > > That is why I am asking what problems if any will the vendors have. > > > > Even if no vendor speaks up here, it will not guarantee that > this will not create any problems. > > >> > >> I really don't think its worth the effort to change this field. We > >> have a very large base of implementations that we really > don't want > >> to mess up unless its absolutely necessary. > > > > So, we agree that leaving this field hard wired to SHA-1 is ok and > > 2560 can easily accommodate new hash functions. Right? > > > > I fail to understand this sentence. Despite reading it many > times over. > > > My only reason to align with 5280 is that if some one were > ever want > > to strip off SHA-1 altogether from their Responder or client, > > permitting other methods does it. > > > > I don't believe this argument is valid as I don't think it is > possible to strip off SHA-1 in any reasonable future. In any > case. If we compare the positive side with allowing this > change and the negative consequences to make OCSP > incompatible with itself, my choice is easy. > > /Stefan >=20 > > >> > >> As the only property of this field is to provide a convenient > >> identifier, it is far from absolutely necessary to change it. > >> Remember that there is a second choice to to identify responder by > >> name. For names we have accepted the possibility of collisions. In > >> that comparison, upgrading from SHA-1 is really redundant. > >> > >> /Stefan > >> > >> > >> > >> > >> On 4/1/09 4:05 PM, "Santosh Chokhani" > wrote: > >> > >>> > >>> My resident ASN.1 expert apprised me of the fact that > >> adding a choice > >>> will break backward compatibility. Thus, extension is a > >> fifth option > >>> (probably third in the priority). > >>> > >>> Based on what I know of OCSP implementations, not changing > >> anything in > >>> terms of bits on the wire and aligning the Key ID with SKID > >> in 5280 is > >>> the best approach. I do not think it will hurt backward > >> compatibility. > >>> > >>> OCSP Responder and OCSP client vendors should speak up if I > >> am wrong. > >>> > >>>> -----Original Message----- > >>>> From: Santosh Chokhani > >>>> Sent: Tuesday, March 31, 2009 12:51 PM > >>>> To: 'Massimiliano Pala'; IETF-pkix > >>>> Subject: RE: OCSP RFC (RFC 2560) Dependence on SHA-1 > >>>> > >>>> Max, > >>>> > >>>> I do not see where and what extension we need to add for > >> other digest > >>>> algorithm. > >>>> > >>>> For key id, we need to enhance or broaden the options. > >>>> > >>>>> -----Original Message----- > >>>>> From: owner-ietf-pkix@mail.imc.org > >>>>> [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of > >> Massimiliano Pala > >>>>> Sent: Tuesday, March 31, 2009 1:37 PM > >>>>> To: IETF-pkix > >>>>> Subject: Re: OCSP RFC (RFC 2560) Dependence on SHA-1 > >>>>> > >>>>> Hi all, > >>>>> > >>>>> as I said during last meeting - as the use of SHA-1 does > >>>> not have any > >>>>> security implication in the OCSP, another viable way > would be to > >>>>> define an extension where other digest algorithms can be > >>>> added to the > >>>>> request/responses. > >>>>> > >>>>> It is a simple addition and does not require any change in > >>>> the RFC, it > >>>>> can be done as a separate document for those who what to > >> use other > >>>>> digest algorithms. > >>>>> > >>>>> After all, isn't this an example of why we allow > >> extensions to the > >>>>> messages ? > >>>>> > >>>>> Later, > >>>>> Max > >>>>> > >>>>> > >>>>> Santosh Chokhani wrote: > >>>>>> Tom, > >>>>>> > >>>>>> Adding a new choice and aligning it with 5280 SKID is fine. > >>>>>> > >>>>>> I would not add anything about matching this field with > >>>>> anything since > >>>>>> RFC 2560 does not say anything about it. > >>>>>> > >>>>>> If one were to add something, one should describe how this > >>>>> field can > >>>>>> be used to select from multiple Responder certificates. > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: Tom Gindin [mailto:tgindin@us.ibm.com] > >>>>>>> Sent: Monday, March 30, 2009 7:46 PM > >>>>>>> To: Santosh Chokhani > >>>>>>> Cc: IETF-pkix > >>>>>>> Subject: Re: OCSP RFC (RFC 2560) Dependence on SHA-1 > >>>>>>> > >>>>>>> Santosh: > >>>>>>> > >>>>>>> The RFC 5280 method just describes "two common > >>>> methods for > >>>>>>> generating key identifiers from the public key" > >>>>>>> and says that other methods are acceptable. The comment > >>>>> to KeyHash > >>>>>>> in RFC 2560 4.2.1 is not as permissive. Of course, it's > >>>> the same > >>>>>>> field as SKID, and I would support either stating "if the > >>>>> KeyHash is > >>>>>>> not precisely 20 octets long, it should be matched > against the > >>>>>>> Subject Key Identifier extension of the signing > certificate" or > >>>>>>> adding another choice like byID [3] OCTET STRING -- > >>>>> matches the value > >>>>>>> of SKID. > >>>>>>> > >>>>>>> Tom Gindin > >>>>>>> > >>>>>>> P.S. - The above opinions are mine, and not necessarily > >>>>> those of my > >>>>>>> employer > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> "Santosh Chokhani" Sent by: > >>>>>>> owner-ietf-pkix@mail.imc.org > >>>>>>> 03/26/2009 10:39 PM > >>>>>>> > >>>>>>> To > >>>>>>> "IETF-pkix" > >>>>>>> cc > >>>>>>> > >>>>>>> Subject > >>>>>>> OCSP RFC (RFC 2560) Dependence on SHA-1 > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> RFC 2560 dependence on SHA-1 does not appear to be > >>>>> difficult to deal > >>>>>>> with. > >>>>>>> > >>>>>>> Section 4.3 lists SHA-1 as mandatory and RSA as > >>>> optional. We can > >>>>>>> update this to add SHA-2 series as optional. > >>>>>>> > >>>>>>> The Responder ID has SHA-1 hardwired. But, that is no > >>>>> different than > >>>>>>> key ID extensions in RFC 5280. Here are some options > >> in order of > >>>>>>> preference: > >>>>>>> > >>>>>>> 1. Align the language with subject key ID language > in RFC 5280. > >>>>>>> > >>>>>>> 2. Keep on using SHA-1. This field is not security > >>>>> relevant. RFC > >>>>>>> 2560 does not even describe how to use this field. So, > >>>>> having SHA-1 > >>>>>>> and accidental or intentional collisions will not hurt the > >>>>> security > >>>>>>> of the protocol. > >>>>>>> > >>>>>>> 3. If you do not believe in KISS principle, you can > >>>>> define another > >>>>>>> response type and enhance the key ID ASN.1 syntax so > that hash > >>>>>>> algorithm is identified. > >>>>>>> > >>>>>>> 4. Another option is for the Responder to use the > same hashing > >>>>>>> algorithm as the one in the first certID entry. > >>>>>>> > >>>>>>> > >>>>>>> Santosh Chokhani > >>>>>>> CygnaCom Solutions > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> > >>>>> Best Regards, > >>>>> > >>>>> Massimiliano Pala > >>>>> > >>>>> --o----------------------------------------------------------- > >>>>> ------------- > >>>>> Massimiliano Pala [OpenCA Project Manager] > >>>>> Massimiliano.Pala@dartmouth.edu > >>>>> =20 > >>>>> project.manager@openca.org > >>>>> > >>>>> Dartmouth Computer Science Dept Home Phone: +1 > >>>>> (603) 369-9332 > >>>>> PKI/Trust Laboratory Work Phone: +1 > >>>>> (603) 646-9179 > >>>>> --o----------------------------------------------------------- > >>>>> ------------- > >>>>> > >>>>> People who think they know everything are a great annoyance > >>>> to those > >>>>> of us who do. > >>>>> -- > >>>>> Isaac Asimov > >>>>> > >>>> > >>> > >> > >> > >> > > > > > =09 =09 ------_=_NextPart_001_01C9B39A.1397BF01 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: OCSP RFC (RFC 2560) Dependence on = SHA-1=0A= =0A= =0A= =0A=

=0A=

On the = contrary, each time I asked for a substantive argument you used exactly = the same non argument you are using here.

=0A=

I have put a substantive = argument on the table here. "I am not convinced" or "I answered the = question some other time" with no links to the specific points are not a = substantive response. You may think that you gave a substantive = explanation of how a client that only supports ECC can obtain a = comprehensible response from a generic OCSP server that also supports = RSA. However I do not beleive that it is possible in the current = protocol.

=0A=

If you think you have = demonstrated this in the past then please point to the = email.

=0A=

=0A= From: Santosh Chokhani = [mailto:SChokhani@cygnacom.com]
Sent: Thu 4/2/2009 7:54 = AM
To: Hallam-Baker, Phillip; Stefan Santesson; = IETF-pkix
Subject: RE: OCSP RFC (RFC 2560) Dependence on = SHA-1

=0A=

I have no objection to having an = extension, but if in the long term SHA-1 will not be there, it seems = defining a new response type (say basic 2) would be the way to go so = that SHA-1 based key ID can be stripped off.

=0A=

If SHA-1 is not getting ripped off = in the long term, I do not see value in extension except that it = may make every one happy: those who do not care will not include it = on the Server side and/or will ignore it on the client = side.

=0A=

It would appear that the extension = should be NC.

=0A=

Phil,

=0A=

I would not respond to the = arguments on KISS and security since in this case both are = straightforward. Also, in this thread, the comments were not meant = for or directed at you.

=0A=

As you know, I have provided = extensive comments to you when you first posted the OCSP Agility I-D and = my position and reasons are matter of PKIX archives for anyone to = scrutinize. When you ignore every single cogent point, there is no = sense in me commenting on next iteration. I do think that the OCSP = Agility I-D is a solution looking for a problem that I do not = see.

=0A=

=0A=
=0A=
=0A= From: Hallam-Baker, Phillip = [mailto:pbaker@verisign.com]
Sent: Thursday, April 02, 2009 = 12:53 AM
To: Santosh Chokhani; Stefan Santesson; = IETF-pkix
Subject: RE: OCSP RFC (RFC 2560) Dependence on = SHA-1

=0A=
=0A=
=0A=
I think we = have no choice but to leave the Key ID CHOICE to be SHA-1 = based.
=0A=

=0A=
But that does not preclude = adding an extension that allows the KeyID to be specified using a = stronger algorithm. There are two reasons for this:
=0A=

=0A=
1) Optics, even if there is = no security implication, a protocol that uses weak crypto necessitates = an (expensive) security review to prove that there is no problem. And = these must be performed repeatedly by many different parties as relying = on the analysis of others is a good way to cause issues. Been there, = done that.
=0A=

=0A=
2) We are designing for long = time spans, ten years or more. While simple compressor collisions may = not be a concern, there is no guarantee that the attacks will stop at = that point. MD4 has been broken repeatedly and they are now at the stage = of jumping up and down on the little pieces. It will probably happen to = MD5 and we should be cautious in case it happens to SHA-1.
=0A=

=0A=

=0A=
On the claim of 'Keep it = simple STUPID', I find it rather offensive to have my position = characterized as stupid. My designs are not exactly known for being = verbose or overly elaborate. If I propose something it is because there = is a reason. It is very easy to defend the status quo by derriding = proposals as unnecessary, but the fact is that making OCSP too simple = will simply cause the complexity to blow out somewhere else.
=0A=

=0A=
There is an architectural = princple of modular design that demands that the core of PKIX as it now = stands (the certificate profile and OCSP) be capable of stand alone use. = We cannot fix issues in OCSP with LTANS or other layered-on protocols as = some have proposed. It does not simplify my OCSP deployment to have to = graft on an entire different protocol in addition or to re-engineer my = document archival protocol to cover defects in OCSP.
=0A=

=0A=

=0A=
Simply adding new algorithms = to a protocol does nothing to improve security. You only improve = security if you withdraw insecure algorithms from use.
=0A=

=0A=
To make the system work you = have to have a means of negotiating between the client and the server. = Otherwise there is no way for an OCSP responder to ensure that it = receives a secure, supported response to querries for certificates = that do not exist yet or are not known to the responder.
=0A=

=0A=
In the case of an OCSP = responder being driven by CRLs collected from various sources, there is = no way for the CA to know if a certificate even exists, all it knows is = if the status is definitively revoked.
=0A=

=0A=
In the case of many = transactional architectures the OCSP validation is performed = independently of certificate chain validation.
=0A=

=0A=

=0A=
Experience of small scale PKI = deployment in which any box can be upgraded at will is simply not = representative of large scale real world deployment.
=0A=

=0A=
=0A=

=0A=
=0A=
=0A=
=0A=
From: = owner-ietf-pkix@mail.imc.org on behalf of Santosh = Chokhani
Sent: Wed 4/1/2009 8:39 PM
To: Stefan = Santesson; IETF-pkix
Subject: RE: OCSP RFC (RFC 2560) = Dependence on SHA-1

=0A=

=0A=
I am saying that "Do you agree that 2560 can be left = alone for Responder
ID's key ID CHOICE being SHA-1 = based?"

> -----Original Message-----
> From: Stefan = Santesson [mailto:stefan@aaa-sec.com]
>= Sent: Wednesday, April 01, 2009 6:32 PM
> To: Santosh Chokhani; = IETF-pkix
> Subject: Re: OCSP RFC (RFC 2560) Dependence on = SHA-1
>
> Santosh,
>
> = In-line
>
>
> On 4/1/09 10:31 PM, "Santosh Chokhani" = <SChokhani@cygnacom.com> wrote:
>
> >
> > = Stefan,
> >
> > See responses in-line.
> = >
> >> -----Original Message-----
> >> From: = Stefan Santesson [mailto:stefan@aaa-sec.com]
>= >> Sent: Wednesday, April 01, 2009 2:34 PM
> >> To: = Santosh Chokhani; Massimiliano Pala; IETF-pkix
> >> Subject: = Re: OCSP RFC (RFC 2560) Dependence on SHA-1
> >>
> = >> Santosh,
> >>
> >> If you are talking = about adding other options to calculate the
> >> KeyHash = value in ResponderID then I strongly disagree.
> >>
> = >> If you add unspecified options you change the = properties
> of the field
> >> from deterministic to a = completely unknown value.
> >> It does not matter if RFC2560 = isn't explicit in its description of
> >> the use of the = field. The fact is that OCSP explicitly
> defines this
> = >> value and as such will allow a client to deterministically = compare
> >> this value with the certificate selected to = validate the response
> >> signature.
> >
> = > I hope no one is doing the matching of Responder ID with
> = hash of a key
> > in place of responder signature = verification. That would
> be real bad.
> = >
>
> Yes it would. That is not at all what I talk about. = But a
> client could use this value to locate a responder = certificate.
>
> >> If you allow
> >> = other ways to calculate the value but do not provide any means = to
> >> signal what method that was used, then this feature = is lost.
> >
> > The most common use will be to use = this field to prioritize the
> > certificates of the responder = to use for sigature
> verification on the
> > = response.
> >
>
> Do you know this for a fact, or = are you guessing?
> If a single implementation verifies that the = certificate used
> to validate the response matches the = ResponderID value, and
> choose to go into an error state because = of mismatch, then we
> have created great problems. So we can't = guess. We have to
> know that no single implementation will fail = because of this.
> And that may be very = hard.
>
>
> >>
> >> In worst case we = will cause current implementation to fail.
> >
> > = That is why I am asking what problems if any will the vendors = have.
> >
>
> Even if no vendor speaks up here, it = will not guarantee that
> this will not create any = problems.
>
> >>
> >> I really don't think = its worth the effort to change this field. We
> >> have a = very large base of implementations that we really
> don't = want
> >> to mess up unless its absolutely = necessary.
> >
> > So, we agree that leaving this = field hard wired to SHA-1 is ok and
> > 2560 can easily = accommodate new hash functions. Right?
> = >
>
> I fail to understand this sentence. Despite reading = it many
> times over.
>
> > My only reason to align = with 5280 is that if some one were
> ever want
> > to = strip off SHA-1 altogether from their Responder or client,
> > = permitting other methods does it.
> >
>
> I don't = believe this argument is valid as I don't think it is
> possible = to strip off SHA-1 in any reasonable future. In any
> case. If we = compare the positive side with allowing this
> change and the = negative consequences to make OCSP
> incompatible with itself, my = choice is easy.
>
> /Stefan
>
>
> = >>
> >> As the only property of this field is to = provide a convenient
> >> identifier, it is far from = absolutely necessary to change it.
> >> Remember that there = is a second choice to to identify responder by
> >> name. = For names we have accepted the possibility of collisions. In
> = >> that comparison, upgrading from SHA-1 is really = redundant.
> >>
> >> /Stefan
> = >>
> >>
> >>
> >>
> = >> On 4/1/09 4:05 PM, "Santosh Chokhani"
> = <SChokhani@cygnacom.com> wrote:
> >>
> = >>>
> >>> My resident ASN.1 expert apprised me = of the fact that
> >> adding a choice
> >>> = will break backward compatibility. Thus, extension is a
> = >> fifth option
> >>> (probably third in the = priority).
> >>>
> >>> Based on what I = know of OCSP implementations, not changing
> >> anything = in
> >>> terms of bits on the wire and aligning the Key = ID with SKID
> >> in 5280 is
> >>> the best = approach. I do not think it will hurt backward
> >> = compatibility.
> >>>
> >>> OCSP Responder = and OCSP client vendors should speak up if I
> >> am = wrong.
> >>>
> >>>> -----Original = Message-----
> >>>> From: Santosh Chokhani
> = >>>> Sent: Tuesday, March 31, 2009 12:51 PM
> = >>>> To: 'Massimiliano Pala'; IETF-pkix
> = >>>> Subject: RE: OCSP RFC (RFC 2560) Dependence on = SHA-1
> >>>>
> >>>> Max,
> = >>>>
> >>>> I do not see where and what = extension we need to add for
> >> other digest
> = >>>> algorithm.
> >>>>
> = >>>> For key id, we need to enhance or broaden the = options.
> >>>>
> >>>>> = -----Original Message-----
> >>>>> From: = owner-ietf-pkix@mail.imc.org
> >>>>> [mailto:owner-ietf-pkix@mail.= imc.org] On Behalf Of
> >> Massimiliano Pala
> = >>>>> Sent: Tuesday, March 31, 2009 1:37 PM
> = >>>>> To: IETF-pkix
> >>>>> Subject: = Re: OCSP RFC (RFC 2560) Dependence on SHA-1
> = >>>>>
> >>>>> Hi all,
> = >>>>>
> >>>>> as I said during last = meeting - as the use of SHA-1 does
> >>>> not have = any
> >>>>> security implication in the OCSP, = another viable way
> would be to
> >>>>> = define an extension where other digest algorithms can be
> = >>>> added to the
> >>>>> = request/responses.
> >>>>>
> = >>>>> It is a simple addition and does not require any = change in
> >>>> the RFC, it
> = >>>>> can be done as a separate document for those who = what to
> >> use other
> >>>>> digest = algorithms.
> >>>>>
> >>>>> = After all, isn't this an example of why we allow
> >> = extensions to the
> >>>>> messages ?
> = >>>>>
> >>>>> Later,
> = >>>>> Max
> >>>>>
> = >>>>>
> >>>>> Santosh Chokhani = wrote:
> >>>>>> Tom,
> = >>>>>>
> >>>>>> Adding a new = choice and aligning it with 5280 SKID is fine.
> = >>>>>>
> >>>>>> I would not = add anything about matching this field with
> >>>>> = anything since
> >>>>>> RFC 2560 does not say = anything about it.
> >>>>>>
> = >>>>>> If one were to add something, one should = describe how this
> >>>>> field can
> = >>>>>> be used to select from multiple Responder = certificates.
> >>>>>>
> = >>>>>>> -----Original Message-----
> = >>>>>>> From: Tom Gindin [mailto:tgindin@us.ibm.com]
>= >>>>>>> Sent: Monday, March 30, 2009 7:46 = PM
> >>>>>>> To: Santosh Chokhani
> = >>>>>>> Cc: IETF-pkix
> = >>>>>>> Subject: Re: OCSP RFC (RFC 2560) Dependence = on SHA-1
> >>>>>>>
> = >>>>>>>       &nb= sp; Santosh:
> >>>>>>>
> = >>>>>>>       &nb= sp; The RFC 5280 method just describes "two common
> = >>>> methods for
> >>>>>>> = generating key identifiers from the public key"
> = >>>>>>> and says that other methods are = acceptable. The comment
> >>>>> to = KeyHash
> >>>>>>> in RFC 2560 4.2.1 is not as = permissive. Of course, it's
> >>>> the = same
> >>>>>>> field as SKID, and I would = support either stating "if the
> >>>>> KeyHash = is
> >>>>>>> not precisely 20 octets long, it = should be matched
> against the
> = >>>>>>> Subject Key Identifier extension of the = signing
> certificate" or
> >>>>>>> = adding another choice like byID [3] OCTET STRING --
> = >>>>> matches the value
> = >>>>>>> of SKID.
> = >>>>>>>
> = >>>>>>>       &nb= sp;         Tom Gindin
> = >>>>>>>
> >>>>>>> P.S. - = The above opinions are mine, and not necessarily
> = >>>>> those of my
> >>>>>>> = employer
> >>>>>>>
> = >>>>>>>
> = >>>>>>>
> = >>>>>>>
> >>>>>>> = "Santosh Chokhani" <SChokhani@cygnacom.com> Sent by:
> = >>>>>>> owner-ietf-pkix@mail.imc.org
> = >>>>>>> 03/26/2009 10:39 PM
> = >>>>>>>
> >>>>>>> = To
> >>>>>>> "IETF-pkix" = <ietf-pkix@imc.org>
> >>>>>>> = cc
> >>>>>>>
> = >>>>>>> Subject
> = >>>>>>> OCSP RFC (RFC 2560) Dependence on = SHA-1
> >>>>>>>
> = >>>>>>>
> = >>>>>>>
> = >>>>>>>
> = >>>>>>>
> = >>>>>>>
> = >>>>>>>
> >>>>>>> RFC = 2560 dependence on SHA-1 does not appear to be
> = >>>>> difficult to deal
> = >>>>>>> with.
> = >>>>>>>
> >>>>>>> = Section 4.3 lists SHA-1 as mandatory and RSA as
> >>>> = optional. We can
> >>>>>>> update this = to add SHA-2 series as optional.
> = >>>>>>>
> >>>>>>> The = Responder ID has SHA-1 hardwired. But, that is no
> = >>>>> different than
> >>>>>>> = key ID extensions in RFC 5280. Here are some options
> = >> in order of
> >>>>>>> = preference:
> >>>>>>>
> = >>>>>>> 1. Align the language with subject = key ID language
> in RFC 5280.
> = >>>>>>>
> >>>>>>> = 2. Keep on using SHA-1. This field is not security
> = >>>>> relevant. RFC
> = >>>>>>> 2560 does not even describe how to use this = field. So,
> >>>>> having SHA-1
> = >>>>>>> and accidental or intentional collisions = will not hurt the
> >>>>> security
> = >>>>>>> of the protocol.
> = >>>>>>>
> >>>>>>> = 3. If you do not believe in KISS principle, you can
> = >>>>> define another
> >>>>>>> = response type and enhance the key ID ASN.1 syntax so
> that = hash
> >>>>>>> algorithm is = identified.
> >>>>>>>
> = >>>>>>> 4. Another option is for the = Responder to use the
> same hashing
> = >>>>>>> algorithm as the one in the first certID = entry.
> >>>>>>>
> = >>>>>>>
> >>>>>>> = Santosh Chokhani
> >>>>>>> CygnaCom = Solutions
> >>>>>>>
> = >>>>>>>
> = >>>>>>>
> = >>>>>>>
> >>>>>>
> = >>>>>>
> >>>>>
> = >>>>>
> >>>>> --
> = >>>>>
> >>>>> Best Regards,
> = >>>>>
> >>>>> Massimiliano = Pala
> >>>>>
> >>>>> = --o-----------------------------------------------------------
> = >>>>> -------------
> >>>>> = Massimiliano Pala [OpenCA Project Manager]
> >>>>> = Massimiliano.Pala@dartmouth.edu
> = >>>>>         = ;
> >>>>> = project.manager@openca.org
> >>>>>
> = >>>>> Dartmouth Computer Science = Dept           &nb= sp;   Home Phone: +1
> >>>>> (603) = 369-9332
> >>>>> PKI/Trust = Laboratory          &nb= sp;           &nbs= p;   Work Phone: +1
> >>>>> (603) = 646-9179
> >>>>> = --o-----------------------------------------------------------
> = >>>>> -------------
> >>>>>
> = >>>>> People who think they know everything are a great = annoyance
> >>>> to those
> >>>>> = of us who do.
> >>>>>   --
> = >>>>> Isaac Asimov
> >>>>>
> = >>>>
> >>>
> >>
> = >>
> >>
> = >
>
>
>

<= /BODY> ------_=_NextPart_001_01C9B39A.1397BF01-- From owner-ietf-pkix@mail.imc.org Fri Apr 10 21:29:27 2009 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB7293A69BB for ; Fri, 10 Apr 2009 21:29:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.908 X-Spam-Level: X-Spam-Status: No, score=-0.908 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_96_XX=1.69, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s6Gbd440J171 for ; Fri, 10 Apr 2009 21:29:27 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 897033A6886 for ; Fri, 10 Apr 2009 21:29:26 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3B3xAQo056744 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Apr 2009 20:59:11 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3B3xAAF056743; Fri, 10 Apr 2009 20:59:10 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from eurymedon.net.ttu.edu (eurymedon.net.ttu.edu [129.118.1.225]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3B3x9oS056737 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Fri, 10 Apr 2009 20:59:10 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: from hoplodamus.net.ttu.edu (129.118.1.213) by tmrc.ttu.edu (129.118.1.179) with Microsoft SMTP Server id 8.1.340.0; Fri, 10 Apr 2009 22:59:09 -0500 Received: from Pickup by hoplodamus.net.ttu.edu with Microsoft SMTP Server id 8.1.340.0; Sat, 11 Apr 2009 03:59:09 +0000 X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9B3A4.843C68C1" X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: OCSP RFC (RFC 2560) Dependence on SHA-1 Date: Thu, 2 Apr 2009 11:05:52 -0400 Message-ID: In-Reply-To: <2788466ED3E31C418E9ACC5C3166155768B360@mou1wnexmb09.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: OCSP RFC (RFC 2560) Dependence on SHA-1 Thread-Index: AcmyIGh4vURVLwB0QOmggx7xJi+ihAAAFOIwACx2HrAACXbF2QAB5FEQAAZrbKkABFxqQAAIVKC2AA7xVoAABIERYQACTItw References:

<2788466ED3E31C418E9ACC5C3166155768B35D@mou1wnexmb09.vcorp.ad.vrsn.com> <2788466ED3E31C418E9ACC5C3166155768B360@mou1wnexmb09.vcorp.ad.vrsn.com> From: Carl Wallace To: "Hallam-Baker, Phillip" , IETF-pkix List-Archive: List-ID: List-Unsubscribe: Received-SPF: None (emphytus.net.ttu.edu: owner-ietf-pkix@mail.imc.org does not designate permitted sender hosts) X-TechMail-Edge-Route: TTU Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ------_=_NextPart_001_01C9B3A4.843C68C1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The second half of the equation is where we can end up in (some) difficulty. Particularly if we are working in an archival situation. Imagine the case that we have an RSA1024-SHA1 signature on a document signed using a key that was subsequently compromised and the question the infrastructure needs to answer is whether the certificate was valid at the point it was signed. This was one of the original core use cases in the design of OCSP. =20 Ignoring hash algorithms for the moment, how does a client indicate its time of interest to the OCSP responder? ------_=_NextPart_001_01C9B3A4.843C68C1 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: OCSP RFC (RFC 2560) Dependence on SHA-1

The second half of the equation is where we can end up in (some) difficulty. Particularly if we are working in an archival situation. Imagine the = case that we have an RSA1024-SHA1 signature on a document signed using a key that = was subsequently compromised and the question the infrastructure needs to = answer is whether the certificate was valid at the point it was signed. This was = one of the original core use cases in the design of OCSP.

Ignoring hash algorithms for the moment, how does a = client indicate its time of interest to the OCSP = responder?

------_=_NextPart_001_01C9B3A4.843C68C1-- From owner-ietf-pkix@mail.imc.org Sat Apr 11 03:14:19 2009 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F5B43A6B0B for ; Sat, 11 Apr 2009 03:14:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.699 X-Spam-Level: X-Spam-Status: No, score=-9.699 tagged_above=-999 required=5 tests=[BAYES_50=0.001, GB_I_LETTER=-2, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vVNX6NbO6KzM for ; Sat, 11 Apr 2009 03:14:18 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id A4C893A6836 for ; Sat, 11 Apr 2009 03:14:17 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3B9lMoe070383 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 11 Apr 2009 02:47:22 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3B9lMr1070382; Sat, 11 Apr 2009 02:47:22 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.212]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3B9lAtL070374 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Sat, 11 Apr 2009 02:47:20 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: from tk5-exhub-c104.redmond.corp.microsoft.com (157.54.88.97) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.99.4; Sat, 11 Apr 2009 02:47:10 -0700 Received: from tk5-exmlt-w601.wingroup.windeploy.ntdev.microsoft.com (157.54.18.32) by tk5-exhub-c104.redmond.corp.microsoft.com (157.54.88.97) with Microsoft SMTP Server id 8.2.99.4; Sat, 11 Apr 2009 02:47:09 -0700 Received: from Pickup by mail.windows.microsoft.com with Microsoft SMTP Server id 8.1.291.1; Sat, 11 Apr 2009 09:49:03 +0000 X-BigFish: ps-93(zz1432R98dR14ffO936eQ1443R1805M936fK9371Pzz2cfT1202hzz5a6ciz2dheIL6bh62h) X-Spam-TCS-SCL: 1:0 X-FB-SS: 5, X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Message-ID: <49DCB26D.5050202@nist.gov> Date: Wed, 8 Apr 2009 10:19:25 -0400 From: "David A. Cooper" User-Agent: Thunderbird 2.0.0.21 (X11/20090330) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Jorge_L=F3pez?= , Stefan Santesson CC: pkix Subject: Re: Revocation scheme definition References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: david.cooper@nist.gov List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: quoted-printable Received-SPF: None (SVC-EXGWY-E802.partners.extranet.microsoft.com: owner-ietf-pkix@mail.imc.org does not designate permitted sender hosts) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Stefan Santesson wrote: > Despite that I would love to put CSI expert on my business card, it=20 > might be a bit problematic to hijack this acronym :) Yes, RFC 5513 points out the problem of the overuse of three letter=20 acronyms (granted it is an April 1 RFC). If we used the acronym CSI,=20 most people would tend to immediately think of the College of Southern=20 Idaho ... I mean the College of Staten Island ... Computer Security=20 Institute ... Construction Specifications Institute ... Commodity=20 Systems Inc. ... Computers & Structures, Inc. ... Chi Sigma Iota ...=20 Christian Schools International ... Computational Systems, Inc. ...=20 Christian Solidarity International ... California Solar Initiative ...=20 Canadian Solar Inc. ... Chandler Systems Inc. ... Communications=20 Specialties, Inc. ... Cetacean Society International ... Coalition of=20 Service Industries ... Church of South India ... Computer Society of=20 India ... Cellular Specialties, Inc. ... College Student Insurance ...=20 Custom Systems Integration ... Center for Social Innovation ... Center=20 for Sustainable Innovation ... Creative Specialties International ...=20 Control Sciences Inc. ... Conditional Symmetric Instability ...=20 Community Services Infrastructure ... Coastal Studies Institute ...=20 Curriculum Support Information ... Control Solutions International ...=20 Conversion Services International ... Civil Society International ...=20 Collaborative Software Initiative ... Consolidated Systems Incorporated=20 ... Center for the Study of Intelligence ... Combat Studies Institute=20 ... Coatings Societies International ... Chemical Sampling Information=20 ... California Steel Industries ... Cardiovascular Systems Inc. ...=20 Conservation Study Institute ... Cognitive Strategy Instruction ...=20 Compliance Services International ... Cement Sustainability Initiative=20 ... Cyber Safety Initiative ... Center for Student Involvement ...=20 Center for the Study of Inequality ... Chiropractic Sports Institute ...=20 Closure Systems International ... Custom Scientific Instruments ...=20 Crisis Simulations International ... Cooperative Sagebrush Initiative=20 ... Child Study Institute ... Climate Status Investigations ...=20 Centrifugal Services, Inc. ... Conflict Solutions International ...=20 Caregiver Services, Inc. ... Charter School Institute ... Component=20 Sources International ... So I can understand that you would be concerned that if you referred to=20 yourself as a CSI expert, people might think you meant that you were an=20 expert in Computational Sciences and Informatics. > Other than that I feel sympathetic to your distinction between=20 > revocation and validation. It is however my belief that we have used=20 > that distinction in our standards efforts. I think it would be helpful if specific examples were provided of places=20 in PKIX documents in which the distinction between mechanisms for=20 distributing certificate status information (e.g., CRLs and OCSP) and=20 mechanisms for submitting revocation requests (e.g., a CMP revocation=20 request message) is not clear. Perhaps this confusion does appear in=20 the literature, and those of us on this list simply don't notice it=20 since we already clearly understand the concepts. But without being=20 provided specific examples of text that a non-PKI expert might find=20 confusing, it is difficult for us to judge whether this is a problem in=20 PKIX documents that the WG needs to be more careful about in future=20 documents. Dave > On 4/7/09 1:42 PM, "Jorge L=F3pez" wrote: > > Hi all, > > Next I merely offer personal considerations about the (in my > opinion) confusing scenario of PKI terminology classification. I > would appreciate any comment on this. > > As can be seen in the literature, most people define CRL, > Partitioned CRL, Over-issued CRL, Delta CRL, OCSP, NOVOMODO, > Certificate Revocation Status, Certificate Revocation Tree, etc. > as revocation schemes. I think this "classification" is confusing. > > I personally consider a revocation scheme as a scheme/protocol > where the owner (or an authorised party) is able to revocate the > status of her certificate. For example, the one defined in RFC > 4210 CMP. However, the terms mentioned above relate to data > structures (CRL, Partitioned CRL, Delta CRL), mechanisms to make > that data structure available to others (Over-Issued CRL, > Over-Issued Segmented CRL, etc.) and both the managed data > structure and the associated publication mechanism (NOVOMODO, > Certificate Revocation Tree, etc.). But none of them to the > procedure to be followed in order to revocate the certificate! If > fact OCSP is sometimes referenced as a revocation scheme, when it > is actually focused on "just" checking the revocation status of a > certificate... > > From my viewpoint, I would differentiate among the scheme, the > certificate status information itself - CSI (data structure) - and > the method that distributes/publishes the CSI. A revocation scheme > updates the CSI. However, the publication/distribution method is > oriented to support the validation of certificates. IMHO it has > nothing to do with a revocation scheme. Perhaps you may consider > appropiate to include in the term "revocation scheme" everything > that has something to do with the revocation information... > > Therefore, I distinguish a revocation scheme from another type of > scheme (validation scheme) which aim is to check the status of a > certificate taking into account the CSI. This CSI could be > distributed/published by using one of the methods defined above, > or accessed in an online manner (an OCSP service that retrieves > the CSI from a fresh database). > > I guess that the revocation scheme term has been extended to > things not so related to the revocation itself, like the > validation procedure. I just want to know what the PKI community > think about this. > > Thanks in advance, > > -------- > Jorge Lopez Hernandez-Ardieta > From owner-ietf-pkix@mail.imc.org Sat Apr 11 03:22:50 2009 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAAEC3A6836 for ; Sat, 11 Apr 2009 03:22:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.298 X-Spam-Level: X-Spam-Status: No, score=-12.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lA5fOb5trFt1 for ; Sat, 11 Apr 2009 03:22:49 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 92EF93A6AE6 for ; Sat, 11 Apr 2009 03:22:48 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3BA4APb071332 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 11 Apr 2009 03:04:11 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3BA4AQM071331; Sat, 11 Apr 2009 03:04:10 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3BA3xOE071320 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Sat, 11 Apr 2009 03:04:09 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: from TK5-EXHUB-C101.redmond.corp.microsoft.com (157.54.18.48) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.99.4; Sat, 11 Apr 2009 03:03:58 -0700 Received: from tk5-exmlt-w601.wingroup.windeploy.ntdev.microsoft.com (157.54.18.32) by TK5-EXHUB-C101.redmond.corp.microsoft.com (157.54.18.48) with Microsoft SMTP Server id 8.2.99.4; Sat, 11 Apr 2009 03:03:58 -0700 Received: from Pickup by mail.windows.microsoft.com with Microsoft SMTP Server id 8.1.291.1; Sat, 11 Apr 2009 10:05:51 +0000 X-BigFish: ps-96(zz1418M1432R98dR14ffO936eQ1443R1805M936fK9371Pzz2cfT1202h10adjzz5a6ciz2dheIL5eh6bh5fh) X-FB-SS: 5,5,13, X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=9Z/kLQvAVeOVthHV9xhPtxDJ1CkrYeiiue5s39nsTtA=; b=r4fQH0SmXvyZSFJctoEctkEIVa5UMW2HKi2Le4nWBMxfp86drF2pcpQeG7GcIQM09o c+2GACOeR7Hjw/d3RkhmHAv1WtB4pJmvhv90K45cTUZJ+O54Enc4b1xzD0WcCGrnxoaI HhZgps7UrahjFeCn0+TSyZcdlAnf/W16d/56I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=BN3mmPhoNEC5vvDTb12Thzc7syouzFroLftkfxm3kRMTNy8+5wEDMT83k0UkVBs6ez 3KwUcqWbnRhbvtAu9hxHP6oaaMqOTDfGOqwDwAXYG074vaQhgz9NHqZzUK8rOeeBmIoS i0G4s8Wor0OY0EBSgui9fVOIxGaGM8DtZ9VCw= MIME-Version: 1.0 In-Reply-To: <49DCB26D.5050202@nist.gov> References: <49DCB26D.5050202@nist.gov> Date: Wed, 8 Apr 2009 16:57:54 +0200 Message-ID: Subject: Re: Revocation scheme definition From: =?ISO-8859-1?Q?Jorge_L=F3pez?= To: "David A. Cooper" CC: Stefan Santesson , pkix Content-Type: multipart/alternative; boundary="001485f870603e3a0d04670c5b4e" List-Archive: List-ID: List-Unsubscribe: Received-SPF: None (SVC-EXGWY-E802.partners.extranet.microsoft.com: owner-ietf-pkix@mail.imc.org does not designate permitted sender hosts) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --001485f870603e3a0d04670c5b4e Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Thanks Stefan and Dave for your responses. Well, maybe CSI was not the best acronym as a proposal :-) I wasn't talking about PKIX documents, but some research papers, master/doctoral thesis where a classification of "revocation mechanisms" is made. I understand that these domains are out of the scope of the PKIX community, but maybe we should think of "standardizing" some concepts if th= e "rest of the world" tends to confuse them. I think that's one of the tasks of a standardization organization/work group/etc. Possibly it is not worthy to work on it focusing merely on revocation schem= e related terms, but I have been following a thread about digital certificate/end user certificate/etc. terms that seemed to be confusing as well to some folks. Is it crazy to propose an RFC Informational which collects a kind of glossary and definitions of PKIX related technology? Best, -------- Jorge Lopez Hernandez-Ardieta 2009/4/8 David A. Cooper > Stefan Santesson wrote: > >> Despite that I would love to put CSI expert on my business card, it migh= t >> be a bit problematic to hijack this acronym :) >> > > Yes, RFC 5513 points out the problem of the overuse of three letter > acronyms (granted it is an April 1 RFC). If we used the acronym CSI, mos= t > people would tend to immediately think of the College of Southern Idaho .= .. > I mean the College of Staten Island ... Computer Security Institute ... > Construction Specifications Institute ... Commodity Systems Inc. ... > Computers & Structures, Inc. ... Chi Sigma Iota ... Christian Schools > International ... Computational Systems, Inc. ... Christian Solidarity > International ... California Solar Initiative ... Canadian Solar Inc. ... > Chandler Systems Inc. ... Communications Specialties, Inc. ... Cetacean > Society International ... Coalition of Service Industries ... Church of > South India ... Computer Society of India ... Cellular Specialties, Inc. = ... > College Student Insurance ... Custom Systems Integration ... Center for > Social Innovation ... Center for Sustainable Innovation ... Creative > Specialties International ... Control Sciences Inc. ... Conditional > Symmetric Instability ... Community Services Infrastructure ... Coastal > Studies Institute ... Curriculum Support Information ... Control Solution= s > International ... Conversion Services International ... Civil Society > International ... Collaborative Software Initiative ... Consolidated Syst= ems > Incorporated ... Center for the Study of Intelligence ... Combat Studies > Institute ... Coatings Societies International ... Chemical Sampling > Information ... California Steel Industries ... Cardiovascular Systems In= c. > ... Conservation Study Institute ... Cognitive Strategy Instruction ... > Compliance Services International ... Cement Sustainability Initiative ..= . > Cyber Safety Initiative ... Center for Student Involvement ... Center for > the Study of Inequality ... Chiropractic Sports Institute ... Closure > Systems International ... Custom Scientific Instruments ... Crisis > Simulations International ... Cooperative Sagebrush Initiative ... Child > Study Institute ... Climate Status Investigations ... Centrifugal Service= s, > Inc. ... Conflict Solutions International ... Caregiver Services, Inc. ..= . > Charter School Institute ... Component Sources International ... > > So I can understand that you would be concerned that if you referred to > yourself as a CSI expert, people might think you meant that you were an > expert in Computational Sciences and Informatics. > > Other than that I feel sympathetic to your distinction between revocatio= n >> and validation. It is however my belief that we have used that distincti= on >> in our standards efforts. >> > > I think it would be helpful if specific examples were provided of places = in > PKIX documents in which the distinction between mechanisms for distributi= ng > certificate status information (e.g., CRLs and OCSP) and mechanisms for > submitting revocation requests (e.g., a CMP revocation request message) i= s > not clear. Perhaps this confusion does appear in the literature, and tho= se > of us on this list simply don't notice it since we already clearly > understand the concepts. But without being provided specific examples of > text that a non-PKI expert might find confusing, it is difficult for us t= o > judge whether this is a problem in PKIX documents that the WG needs to be > more careful about in future documents. > > Dave > > > On 4/7/09 1:42 PM, "Jorge L=F3pez" wrote: >> >> Hi all, >> >> Next I merely offer personal considerations about the (in my >> opinion) confusing scenario of PKI terminology classification. I >> would appreciate any comment on this. >> >> As can be seen in the literature, most people define CRL, >> Partitioned CRL, Over-issued CRL, Delta CRL, OCSP, NOVOMODO, >> Certificate Revocation Status, Certificate Revocation Tree, etc. >> as revocation schemes. I think this "classification" is confusing. >> >> I personally consider a revocation scheme as a scheme/protocol >> where the owner (or an authorised party) is able to revocate the >> status of her certificate. For example, the one defined in RFC >> 4210 CMP. However, the terms mentioned above relate to data >> structures (CRL, Partitioned CRL, Delta CRL), mechanisms to make >> that data structure available to others (Over-Issued CRL, >> Over-Issued Segmented CRL, etc.) and both the managed data >> structure and the associated publication mechanism (NOVOMODO, >> Certificate Revocation Tree, etc.). But none of them to the >> procedure to be followed in order to revocate the certificate! If >> fact OCSP is sometimes referenced as a revocation scheme, when it >> is actually focused on "just" checking the revocation status of a >> certificate... >> >> From my viewpoint, I would differentiate among the scheme, the >> certificate status information itself - CSI (data structure) - and >> the method that distributes/publishes the CSI. A revocation scheme >> updates the CSI. However, the publication/distribution method is >> oriented to support the validation of certificates. IMHO it has >> nothing to do with a revocation scheme. Perhaps you may consider >> appropiate to include in the term "revocation scheme" everything >> that has something to do with the revocation information... >> >> Therefore, I distinguish a revocation scheme from another type of >> scheme (validation scheme) which aim is to check the status of a >> certificate taking into account the CSI. This CSI could be >> distributed/published by using one of the methods defined above, >> or accessed in an online manner (an OCSP service that retrieves >> the CSI from a fresh database). >> >> I guess that the revocation scheme term has been extended to >> things not so related to the revocation itself, like the >> validation procedure. I just want to know what the PKI community >> think about this. >> >> Thanks in advance, >> >> -------- >> Jorge Lopez Hernandez-Ardieta >> >> > --001485f870603e3a0d04670c5b4e Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable

Thanks Stefan and Dave for your responses.

We= ll, maybe CSI was not the best acronym as a proposal :-)

Is it crazy to propose an RFC Informational which colle= cts a kind of glossary and definitions of PKIX related technology?

Best,

--------

Jorge Lo= pez Hernandez-Ardieta

2009/4/8 David A. Cooper &= lt;david.cooper@nist.gov>

Stefan Santesson wrote:

Despite that I would love to put CSI expert on my business card, it might b= e a bit problematic to hijack this acronym :)

Yes, RFC 5513 points out the problem of the overuse of three letter acronym= s (granted it is an April 1 RFC). =A0If we used the acronym CSI, most peopl= e would tend to immediately think of the College of Southern Idaho ... I me= an the College of Staten Island ... Computer Security Institute ... Constru= ction Specifications Institute ... Commodity Systems Inc. ... Computers &am= p; Structures, Inc. ... Chi Sigma Iota ... Christian Schools International = ... Computational Systems, Inc. ... Christian Solidarity International ... = California Solar Initiative ... Canadian Solar Inc. ... Chandler Systems In= c. ... Communications Specialties, Inc. ... Cetacean Society International = ... Coalition of Service Industries ... Church of South India ... Computer = Society of India ... Cellular Specialties, Inc. ... College Student Insuran= ce ... Custom Systems Integration ... Center for Social Innovation ... Cent= er for Sustainable Innovation ... Creative Specialties International ... Co= ntrol Sciences Inc. ... Conditional Symmetric Instability ... Community Ser= vices Infrastructure ... Coastal Studies Institute ... Curriculum Support I= nformation ... Control Solutions International ... Conversion Services Inte= rnational ... Civil Society International ... Collaborative Software Initia= tive ... Consolidated Systems Incorporated ... Center for the Study of Inte= lligence ... Combat Studies Institute ... Coatings Societies International = ... Chemical Sampling Information ... California Steel Industries ... Cardi= ovascular Systems Inc. ... Conservation Study Institute ... =A0Cognitive St= rategy Instruction ... Compliance Services International ... Cement Sustain= ability Initiative ... Cyber Safety Initiative ... Center for Student Invol= vement ... Center for the Study of Inequality ... Chiropractic Sports Insti= tute ... Closure Systems International ... Custom Scientific Instruments ..= . Crisis Simulations International ... Cooperative Sagebrush Initiative ...= Child Study Institute ... Climate Status Investigations ... Centrifugal Se= rvices, Inc. ... Conflict Solutions International ... Caregiver Services, I= nc. ... Charter School Institute ... Component Sources International ...
So I can understand that you would be concerned that if you referred to you= rself as a CSI expert, people might think you meant that you were an expert= in Computational Sciences and Informatics.

Other than that I feel sympathetic to your distinction between revocation a= nd validation. It is however my belief that we have used that distinction i= n our standards efforts.

I think it would be helpful if specific examples were provided of places in= PKIX documents in which the distinction between mechanisms for distributin= g certificate status information (e.g., CRLs and OCSP) and mechanisms for s= ubmitting revocation requests (e.g., a CMP revocation request message) is n= ot clear. =A0Perhaps this confusion does appear in the literature, and thos= e of us on this list simply don't notice it since we already clearly un= derstand the concepts. =A0But without being provided specific examples of t= ext that a non-PKI expert might find confusing, it is difficult for us to j= udge whether this is a problem in PKIX documents that the WG needs to be mo= re careful about in future documents.

Dave

On 4/7/09 1:42 PM, "Jorge L=F3pez" <jlopez.ha@gmail.com> wrote:

=A0 =A0Hi all,

=A0 =A0Next I merely offer personal considerations about the (in my
=A0 =A0opinion) confusing scenario of PKI terminology classification. I =A0 =A0would appreciate any comment on this.

=A0 =A0As can be seen in the literature, most people define CRL,
=A0 =A0Partitioned CRL, Over-issued CRL, Delta CRL, OCSP, NOVOMODO,
=A0 =A0Certificate Revocation Status, Certificate Revocation Tree, etc. =A0 =A0as revocation schemes. I think this "classification" is c= onfusing.

=A0 =A0I personally consider a revocation scheme as a scheme/protocol
=A0 =A0where the owner (or an authorised party) is able to revocate the =A0 =A0status of her certificate. For example, the one defined in RFC
=A0 =A04210 CMP. However, the terms mentioned above relate to data
=A0 =A0structures (CRL, Partitioned CRL, Delta CRL), mechanisms to make =A0 =A0that data structure available to others (Over-Issued CRL,
=A0 =A0Over-Issued Segmented CRL, etc.) and both the managed data
=A0 =A0structure and the associated publication mechanism (NOVOMODO,
=A0 =A0Certificate Revocation Tree, etc.). But none of them to the
=A0 =A0procedure to be followed in order to revocate the certificate! If =A0 =A0fact OCSP is sometimes referenced as a revocation scheme, when it =A0 =A0is actually focused on "just" checking the revocation sta= tus of a
=A0 =A0certificate...

=A0 =A0From my viewpoint, I would differentiate among the scheme, the
=A0 =A0certificate status information itself - CSI (data structure) - and<= br> =A0 =A0the method that distributes/publishes the CSI. A revocation scheme<= br> =A0 =A0updates the CSI. However, the publication/distribution method is =A0 =A0oriented to support the validation of certificates. IMHO it has
=A0 =A0nothing to do with a revocation scheme. Perhaps you may consider =A0 =A0appropiate to include in the term "revocation scheme" eve= rything
=A0 =A0that has something to do with the revocation information...

=A0 =A0Therefore, I distinguish a revocation scheme from another type of =A0 =A0scheme (validation scheme) which aim is to check the status of a =A0 =A0certificate taking into account the CSI. This CSI could be
=A0 =A0distributed/published by using one of the methods defined above, =A0 =A0or accessed in an online manner (an OCSP service that retrieves
=A0 =A0the CSI from a fresh database).

=A0 =A0I guess that the revocation scheme term has been extended to
=A0 =A0things not so related to the revocation itself, like the
=A0 =A0validation procedure. I just want to know what the PKI community =A0 =A0think about this.

=A0 =A0Thanks in advance,

=A0 =A0--------
=A0 =A0Jorge Lopez Hernandez-Ardieta

--001485f870603e3a0d04670c5b4e-- From owner-ietf-pkix@mail.imc.org Sat Apr 11 06:01:16 2009 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC1CC3A67A8 for ; Sat, 11 Apr 2009 06:01:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.825 X-Spam-Level: X-Spam-Status: No, score=-7.825 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_24_48=1.219, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.134, RCVD_IN_DNSWL_HI=-8, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v27-Z6nuk56a for ; Sat, 11 Apr 2009 06:01:08 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 28F463A6E3E for ; Sat, 11 Apr 2009 06:00:59 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3BCV47G079326 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 11 Apr 2009 05:31:04 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3BCV4wU079325; Sat, 11 Apr 2009 05:31:04 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.212]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3BCV2Yd079319 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Sat, 11 Apr 2009 05:31:03 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: from tk5-exhub-c103.redmond.corp.microsoft.com (157.54.88.96) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.99.4; Sat, 11 Apr 2009 05:31:02 -0700 Received: from tk5-exmlt-w601.wingroup.windeploy.ntdev.microsoft.com (157.54.18.32) by tk5-exhub-c103.redmond.corp.microsoft.com (157.54.88.96) with Microsoft SMTP Server id 8.2.99.4; Sat, 11 Apr 2009 05:31:02 -0700 Received: from Pickup by mail.windows.microsoft.com with Microsoft SMTP Server id 8.1.291.1; Sat, 11 Apr 2009 12:32:55 +0000 X-BigFish: ps-60(zz146fK542Ndf9M62a3Laf6W936eQ936fKzz2cfT1202h1082kzz4461rz2dh54h53keIL6bh6di34h61h) X-Spam-TCS-SCL: 0:0 X-FB-SS: 5,5,5, X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f From: Erik Andersen To: , "'ietf-pkix'" Subject: RE: [x500standard] Re: Certificate definitions Date: Thu, 9 Apr 2009 17:25:37 +0200 Message-ID: <7B01F815F4064ABEB6447E403CA12C56@ERA1> MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0000_01C9B938.35920940" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6838 Importance: Normal Thread-Index: Acm0cXogl35R6fnrRR6btIokFjzPxQErLQOw In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 List-Archive: List-ID: List-Unsubscribe: Received-SPF: None (tk5-exgwy-e802.partners.extranet.microsoft.com: owner-ietf-pkix@mail.imc.org does not designate permitted sender hosts) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ------=_NextPart_000_0000_01C9B938.35920940 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_01C9B938.35920940" ------=_NextPart_001_0001_01C9B938.35920940 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Denis, =20 It is a little dangerous not to respond to my comments. Due to the = apparent inactivity of people, I have the power to produce Defect Reports, = produce Draft Technical Corrigenda, run them through both the ISO and ITU-T = approval process and finally integrate them into the next edition of X.500 (incl. X.509) without being stopped by anyone (except for Jean-Paul Lemaire). =20 I believe you misunderstood my diagram. It may be a little confusing. = Let me express myself without the diagram. =20 The set of certificates is the union of the set of public-key = certificates and the set of attribute certificates. =20 The set of end-entity certificates is the union of public-key = certificates issued to end-entities and the set of attribute certificates issued to end-entities. However, X.509 is a little confusing here as the term end-entity certificate is sometimes meant to be just public-key = certificates issued to end-entities, so the term end-entity certificate has two = meanings. =20 The set of public-key certificates is the union of the set of end-entity (public-key) certificates and the set of CA certificates. =20 The set of attribute certificates is the union of the set of end-entity (attribute) certificates and the set of AA certificates. =20 The set of authority certificates is the union of the set CA = certificates and the set of AA certificates. =20 The set of CA certificates is the union of the set of self-issued (public-key) certificates and the set cross certificates. The latter is = a little confusing, as a cross certificate can also be an attribute certificate. =20 I am avoiding here to use the term =93user attribute=94, but believe it = is supposed to mean a public-key certificate issued to an end-entity. =20 Whenever an innocent reader sees the term =93certificate=94, he/she is = entitled to believe it can either be a public-key certificate. It may not always = be clear from the context what is meant. =20 Whenever an innocent us reader see the term =93end-entity = certificate=94, he/she is entitled to believe it is either a public key certificate or = an attribute certificate issued to an end-entity. =20 Whenever an innocent us reader see the term =93cross-certificate=94, = he/she is entitled to believe it is either a public key certificate or an = attribute certificate. =20 My proposal was only to clear-up the terminology and to use the = terminology consistent in the text of X.509. Trying to do the latter may raise a = number of detailed questions when the meaning is not absolutely clear from the context. =20 =20 Erik Andersen Andersen's L-Service Elsevej 48, DK-3500 Vaerloese Denmark Mobile: +45 2097 1490 email: era@x500.eu www.x500.eu www.x500standard.com =20 -----Original Message----- From: x500standard-bounce@freelists.org [mailto:x500standard-bounce@freelists.org] On Behalf Of Denis Pinkas Sent: 3. april 2009 17:33 To: x500 list; ietf-pkix Subject: [x500standard] Re: Certificate definitions =20 Eric, =20 Silence does not mean approval. =20 It may mean that the corrections are so numerous that it would take too = long to respond and that people do not have that time available at the moment. =20 e.g.: an End-entity attribute certificate is not linked to a public-key certificate. a cross-certificate is not linked to an AA certificate. an Authority Certificate is not linked to an Attribute = Certificate. =20 This is only a start ... =20 Denis ----- Message re=E7u -----=20 De : owner-ietf-pkix=20 =C0 : x500standard,'PKIX'=20 Date : 2009-04-03, 17:00:01 Sujet : RE: [x500standard] Certificate definitions =20 I take silence as approval. =20 Erik Andersen Andersen's L-Service Elsevej 48, DK-3500 Vaerloese Denmark Mobile: +45 2097 1490 email: era@x500.eu www.x500.eu www.x500standard.com =20 -----Original Message----- From: x500standard-bounce@freelists.org [mailto:x500standard-bounce@freelists.org] On Behalf Of Erik Andersen Sent: 1. april 2009 14:40 To: Directory list; PKIX Subject: [x500standard] Certificate definitions =20 Hi =20 I got a number of responses on user certificates, but quite little that actually answered my question. =20 I have tried to dig a little bit more in X.509 to get hold of the terminology and then produced below figure. I will not comment all the boxes. =20 =20 I will like you to comments as to the correctness of above figure. =20 The end-entity certificate is not defined in the definition clause. = However it is used widely in the main text. It is mentioned the first time in = clause 7 as a public-key certificate. There are several other places where it = is a public-key certificate. In 15.5.2.4 is used in the context of attribute certificates. The conclusion must be that an end-entity certificate can either be a end-entity public-key certificate or an end-entity attribute certificate. However, in most places, it is implied that we only talks = about public-key certificates. For veterans, this is not a major problem, but new-comers may get confused. Anyway, I thing our specifications should = be clear and not subject to interpretation. RFC 5280 does not use the term = at all. It seems just to use the term =93certificate=94 as a synonym for =93end-entrity public key certificate=94. =20 The =93User Certificate=94 is not defined in X.509, but is wide used. = It seems to be a synonym for =93end-entrity public key certificate=94. It is also = used in X.511. RFC 5280 uses the term once without differenting it from just =93certificate=94. =20 The term =93cross-certificate=94 should probably also be qualified. =20 I suggest to add in X.509 definitions for: =20 =93end-entity public-key certificate=94 =93user certificate=94 as a synonym for =93end-entity public-key = certificate=94 =93end-entity attribute certificate=94 =20 The X.509 text should be updated to make use of these definitions. =20 X.509 has four attribute types for holding certificates. =20 UserCertificate: For end-entity public-key certificates cAcertificate: For CA certificates attributeCertificateAttribute: For end-entity attribute certificates aACertificate: For AA Certificates =20 Any comments? =20 Erik Andersen Andersen's L-Service Elsevej 48, DK-3500 Vaerloese Denmark Mobile: +45 2097 1490 email: era@x500.eu www.x500.eu www.x500standard.com =20 ------=_NextPart_001_0001_01C9B938.35920940 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable