RE: SMIME Capabilities in X.509 certificates.
"Stefan Santesson" <stefans@microsoft.com> Fri, 30 April 2004 17:22 UTC
Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16042 for <pkix-archive@lists.ietf.org>; Fri, 30 Apr 2004 13:22:38 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3UGWFCZ021618; Fri, 30 Apr 2004 09:32:15 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3UGWFVX021617; Fri, 30 Apr 2004 09:32:15 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from mail-dub.microsoft.com (mail-dub.microsoft.com [213.199.128.160]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3UGWEV2021593 for <ietf-pkix@imc.org>; Fri, 30 Apr 2004 09:32:14 -0700 (PDT) (envelope-from stefans@microsoft.com)
Received: from dub-imc-01.europe.corp.microsoft.com ([65.53.196.22]) by mail-dub.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 30 Apr 2004 17:32:07 +0100
Received: from 65.53.196.22 by dub-imc-01.europe.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 30 Apr 2004 17:32:07 +0100
Received: from EUR-MSG-03.europe.corp.microsoft.com ([65.53.192.44]) by dub-imc-01.europe.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 30 Apr 2004 17:32:07 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: SMIME Capabilities in X.509 certificates.
Date: Fri, 30 Apr 2004 17:31:51 +0100
Message-ID: <0C3042E92D8A714783E2C44AB9936E1DF1A410@EUR-MSG-03.europe.corp.microsoft.com>
Thread-Topic: SMIME Capabilities in X.509 certificates.
Thread-Index: AcQuz05W3naujQUcRV+Ke79ylscM5QAAC7kg
From: Stefan Santesson <stefans@microsoft.com>
To: "Hallam-Baker, Phillip" <pbaker@verisign.com>, "David A. Cooper" <david.cooper@nist.gov>
Cc: ietf-pkix@imc.org
X-OriginalArrivalTime: 30 Apr 2004 16:32:07.0649 (UTC) FILETIME=[ADC26510:01C42ED0]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i3UGWFV2021612
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 8bit
Phil, I agree to your conclusion. Now if we would move to a discussion of where it should be located I would suggest that the fact that we have a large installed base of clients that today understands and makes use of this information if present in an extension identified with the existing PKCS#9 OID, combined with the fact that there is no other solution out there in use today, we would get a better head start of deployment and interoperability if we found that we could live with the solution already in use. Stefan Santesson Program Manager, Windows Security > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] > On Behalf Of Hallam-Baker, Phillip > Sent: den 30 april 2004 08:15 > To: 'David A. Cooper'; Stefan Santesson > Cc: ietf-pkix@imc.org > Subject: RE: SMIME Capabilities in X.509 certificates. > > > > > Given that SMIMECapabilities is an Attribute, why not put it in the > > SubjectDirectoryAttributes extension rather than trying to > > treat it as a certificate extension? > > I don't care what the OID is provided it is signed and in the cert. > > This is information that the sender of an encrypted email needs to > send mail. Therefore it should be in the cert and be authenticated. > > > Phill Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3UGWFCZ021618; Fri, 30 Apr 2004 09:32:15 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3UGWFVX021617; Fri, 30 Apr 2004 09:32:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail-dub.microsoft.com (mail-dub.microsoft.com [213.199.128.160]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3UGWEV2021593 for <ietf-pkix@imc.org>; Fri, 30 Apr 2004 09:32:14 -0700 (PDT) (envelope-from stefans@microsoft.com) Received: from dub-imc-01.europe.corp.microsoft.com ([65.53.196.22]) by mail-dub.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 30 Apr 2004 17:32:07 +0100 Received: from 65.53.196.22 by dub-imc-01.europe.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 30 Apr 2004 17:32:07 +0100 Received: from EUR-MSG-03.europe.corp.microsoft.com ([65.53.192.44]) by dub-imc-01.europe.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 30 Apr 2004 17:32:07 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: SMIME Capabilities in X.509 certificates. Date: Fri, 30 Apr 2004 17:31:51 +0100 Message-ID: <0C3042E92D8A714783E2C44AB9936E1DF1A410@EUR-MSG-03.europe.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SMIME Capabilities in X.509 certificates. Thread-Index: AcQuz05W3naujQUcRV+Ke79ylscM5QAAC7kg From: "Stefan Santesson" <stefans@microsoft.com> To: "Hallam-Baker, Phillip" <pbaker@verisign.com>, "David A. Cooper" <david.cooper@nist.gov> Cc: <ietf-pkix@imc.org> X-OriginalArrivalTime: 30 Apr 2004 16:32:07.0649 (UTC) FILETIME=[ADC26510:01C42ED0] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i3UGWFV2021612 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Phil, I agree to your conclusion. Now if we would move to a discussion of where it should be located I would suggest that the fact that we have a large installed base of clients that today understands and makes use of this information if present in an extension identified with the existing PKCS#9 OID, combined with the fact that there is no other solution out there in use today, we would get a better head start of deployment and interoperability if we found that we could live with the solution already in use. Stefan Santesson Program Manager, Windows Security > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] > On Behalf Of Hallam-Baker, Phillip > Sent: den 30 april 2004 08:15 > To: 'David A. Cooper'; Stefan Santesson > Cc: ietf-pkix@imc.org > Subject: RE: SMIME Capabilities in X.509 certificates. > > > > > Given that SMIMECapabilities is an Attribute, why not put it in the > > SubjectDirectoryAttributes extension rather than trying to > > treat it as a certificate extension? > > I don't care what the OID is provided it is signed and in the cert. > > This is information that the sender of an encrypted email needs to > send mail. Therefore it should be in the cert and be authenticated. > > > Phill Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3UFFCxP009628; Fri, 30 Apr 2004 08:15:12 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3UFFCpA009627; Fri, 30 Apr 2004 08:15:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3UFFC4F009620 for <ietf-pkix@imc.org>; Fri, 30 Apr 2004 08:15:12 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (verisign.com [65.205.251.55]) by peacock.verisign.com (8.12.11/) with ESMTP id i3UFFEfU024843; Fri, 30 Apr 2004 08:15:14 -0700 (PDT) Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id <JPKPQ3T9>; Fri, 30 Apr 2004 08:15:14 -0700 Message-ID: <C6DDA43B91BFDA49AA2F1E473732113E5DBBF9@mou1wnexm05.vcorp.ad.vrsn.com> From: "Hallam-Baker, Phillip" <pbaker@verisign.com> To: "'David A. Cooper'" <david.cooper@nist.gov>, Stefan Santesson <stefans@microsoft.com> Cc: ietf-pkix@imc.org Subject: RE: SMIME Capabilities in X.509 certificates. Date: Fri, 30 Apr 2004 08:15:05 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> > Given that SMIMECapabilities is an Attribute, why not put it in the > SubjectDirectoryAttributes extension rather than trying to > treat it as a certificate extension? I don't care what the OID is provided it is signed and in the cert. This is information that the sender of an encrypted email needs to send mail. Therefore it should be in the cert and be authenticated. Phill Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3U3CFGs017101; Thu, 29 Apr 2004 20:12:15 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3U3CFxL017100; Thu, 29 Apr 2004 20:12:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3U3CEK3017092 for <ietf-pkix@imc.org>; Thu, 29 Apr 2004 20:12:15 -0700 (PDT) (envelope-from chokhani@orionsec.com) Received: from wchokhani3 (pcp09271907pcs.arlngt01.va.comcast.net [69.143.130.247]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i3U3CLJA018750 for <ietf-pkix@imc.org>; Thu, 29 Apr 2004 23:12:21 -0400 From: "Santosh Chokhani" <chokhani@orionsec.com> To: <ietf-pkix@imc.org> Subject: RE: Cross certificate format Date: Thu, 29 Apr 2004 23:12:15 -0400 Message-ID: <001801c42e60$f3609df0$aa02a8c0@hq.orionsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: <OF320CA641.ECD5BB2D-ON85256E85.003F3195-85256E86.0003E94D@us.ibm.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i3U3CFK3017095 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Tom: The basic point (at the risk of repeating myself) is that a CA certificate or a self-signed certificate can be used as a means to provide trust anchor information. In that case, there is no need to check signature or anything. But, when the CA certificate is a certificate in the certificate path, X.509 logic kicks in. This is consistent with X.509, 3280 and general security principles since the trust in a trust anchor can be derived through any number of means. If you do not agree, feel free to argue against the definitions and Galileo -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Tom Gindin Sent: Thursday, April 29, 2004 8:43 PM To: Santosh Chokhani Cc: ietf-pkix@imc.org Subject: RE: Cross certificate format Santosh: I don't think that a CA certificate and a trust anchor are as much different things as different uses for the same thing. They are both identifiers of issuers which bind a public key to an issuer name, and it is perfectly appropriate for any CA certificate to represent a trust anchor. I also do not see why such things as name constraints on a trust anchor are inappropriate. It is perfectly true that verifying a trust anchor's certificate, when issued by another CA (who may not be trusted) is a pointless operation. Tom Gindin "Santosh Chokhani" <chokhani@orionsec.com> Sent by: owner-ietf-pkix@mail.imc.org 04/27/2004 09:14 AM To: <ietf-pkix@imc.org> cc: Subject: RE: Cross certificate format Tom: My point is that even if the trust anchor is a self-signed certificate, all you need to do is extract the required information. There is no need to examine anything. Cross certificate and trust anchor are very different things. An element of the cross certificate pair is nothing but an intermediate CA certificate in a certification path. -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Tom Gindin Sent: Tuesday, April 27, 2004 7:33 AM To: Santosh Chokhani Cc: ietf-pkix@imc.org; owner-ietf-pkix@mail.imc.org Subject: RE: Cross certificate format Santosh: Of course, you are right that RFC 3280 6.1.1 d permits trust anchor information to be provided outside a certificate. If it is so, no checks of the sort I indicated can be performed. It also says that it can be provided as "a self-signed certificate", with no further qualification. I do think it is somewhat odd that a self-signed certificate with KeyUsage set to typical EE values would be considered a valid issuer as a trust anchor while a cross certificate would not. You can always extract the needed anchor information from a cross-certificate, of course. Tom Gindin "Santosh Chokhani" <chokhani@orionsec.com> Sent by: owner-ietf-pkix@mail.imc.org 04/26/2004 08:51 AM To: <ietf-pkix@imc.org> cc: Subject: RE: Cross certificate format Tom: My reading of 3280 and X.509 is that a trust anchor need not even be a certificate. Thus, no checks need to be performed on a trust anchor at all. You get the DN, public key, algorithm OID, and parameters (if applicable) from a trust anchor. Any checks are gratuitous and not required by either standard. -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Tom Gindin Sent: Sunday, April 25, 2004 7:06 PM To: Jean-Marc Desperrier Cc: ietf-pkix@imc.org Subject: Re: Cross certificate format Jean-Marc: RFC 3280 doesn't say that anywhere. It does say that you don't need to validate the trust anchor as part of the path, but it isn't clear from the text that a v1 certificate is acceptable as a trust anchor - and it certainly isn't clear that a v1 certificate is acceptable as an issuer if it is a trust anchor while a v3 certificate with KeyUsage= { DigitalSignature, keyEncipherment } is not acceptable as an issuer even if it is a trust anchor. I believe that the correct rules for versions are something like the following: a certificate issued by a trust anchor which is represented by a certificate is verifiable if the anchor certificate is either a v1 certificate or a v3 certificate with the CA flag present in the basicConstraints extension. If the anchor certificate is a v3 certificate with the KeyUsage extension present, it is only a valid issuer certificate if keyCertSign is set. Tom Gindin Jean-Marc Desperrier <jmdesp@free.fr> Sent by: owner-ietf-pkix@mail.imc.org 04/21/2004 03:42 PM To: ietf-pkix@imc.org cc: Subject: Re: Cross certificate format Tom Gindin wrote: > RFC 3280 does not support the use of v1 self-signed > certificates, >which contain no extensions at all (see the text of RFC 3280's >basicConstraints section). However, a number of public CA's still have >them. > > Applications implementing the path validation algorithm of RFC3280 MUST accept them when they are used as trust anchors. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3U1fXjp008692; Thu, 29 Apr 2004 18:41:33 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3U1fXui008691; Thu, 29 Apr 2004 18:41:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from ncsusraimge03.jnj.com (ncsusraimge03.jnj.com [148.177.2.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3U1fW4H008670 for <ietf-pkix@imc.org>; Thu, 29 Apr 2004 18:41:32 -0700 (PDT) (envelope-from RGuida@CORUS.JNJ.com) Received: from NCSUSRAWSC4.na.jnj.com (NCSUSRAWSC4.na.jnj.com [10.4.20.24]) by ncsusraimge03.jnj.com (Switch-3.1.2/Switch-3.1.0) with SMTP id i3U1fRkN026984 for <ietf-pkix@imc.org>; Thu, 29 Apr 2004 21:41:33 -0400 (EDT) Received: From NCSUSRAEXIMS1.na.jnj.com ([10.4.20.168]) by NCSUSRAWSC4.na.jnj.com (WebShield SMTP v4.5 MR1a); id 1083289287221; Thu, 29 Apr 2004 21:41:27 -0400 Received: by NCSUSRAEXIMS1.na.jnj.com with Internet Mail Service (5.5.2657.72) id <JWZKPD3Q>; Thu, 29 Apr 2004 21:41:27 -0400 Message-ID: <EE091DE219B2D61190F50002A5436BE30AF6C568@jjcusnbexs8.jjcus.na.jnj.com> From: "Guida, Richard [JJCUS]" <RGuida@CORUS.JNJ.com> To: Trevor Freeman <trevorf@exchange.microsoft.com>, Stefan Santesson <stefans@microsoft.com>, "David A. Cooper" <david.cooper@nist.gov> Cc: ietf-pkix@imc.org Subject: RE: SMIME Capabilities in X.509 certificates. Date: Thu, 29 Apr 2004 21:41:21 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C42E54.3BC8F414" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C42E54.3BC8F414 Content-Type: text/plain; charset="iso-8859-1" I can't agree more, Trevor, and as you imply, sometimes adult or corporate supervision can be a good thing. Even for us baby boomers weened on "doing our own thing!" (And yes, 3DES or AES are acceptable under our policies, although one give 112 and the other 128+ bits of key strength; as you know, both as unbreakable.) Richard A. Guida Director, Information Security Johnson & Johnson Room GS8217 410 George Street New Brunswick, New Jersey 08901 Phone: 732 524 3785 -----Original Message----- From: Trevor Freeman [mailto:trevorf@exchange.microsoft.com] Sent: Thursday, April 29, 2004 9:25 PM To: Guida, Richard [JJCUS]; Stefan Santesson; David A. Cooper Cc: ietf-pkix@imc.org Subject: RE: SMIME Capabilities in X.509 certificates. Hi Rich, As one lurker to another, you also need to consider that it is accepted practice with SMIME today for the client to self certify this data so the potential for having this in the certificate could lead to some adult or corporate supervision. Also if you say you have a preference for AES and 3DES, you are saying both are acceptable otherwise you should not offer the alternatives. So having more ways to express your preference is better. Trevor _____ From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Guida, Richard [JJCUS] Sent: Thursday, April 29, 2004 5:31 PM To: Stefan Santesson; David A. Cooper Cc: ietf-pkix@imc.org Subject: RE: SMIME Capabilities in X.509 certificates. Forgive me for coming out of lurker status on this one, but I do think that Stefan's arguments for this attribute are good ones; we have a requirement to use only strong crypto (3DES, AES, etc.) but of course enforcing that with S/MIME is tricky, requiring more user knowledge than one would expect of most users (clicking on the encryption icon, seeing the crypto strength, confirming it is o.k...). An extension like this (or semantic info in an existing extension) could be very helpful. David's points are correct that a CA may not know the S/MIME capabilities (or requirements) of its subjects - but I agree with Stefan's response that in some cases (like our enterprise environment), it does, so this info can have real utility. Two cents worth... Richard A. Guida Director, Information Security Johnson & Johnson Room GS8217 410 George Street New Brunswick, New Jersey 08901 Phone: 732 524 3785 -----Original Message----- From: Stefan Santesson [ mailto:stefans@microsoft.com <mailto:stefans@microsoft.com> ] Sent: Thursday, April 29, 2004 2:24 PM To: David A. Cooper Cc: ietf-pkix@imc.org Subject: RE: SMIME Capabilities in X.509 certificates. David, Comment in line; > -----Original Message----- > From: David A. Cooper [ mailto:david.cooper@nist.gov <mailto:david.cooper@nist.gov> ] > Sent: den 29 april 2004 10:59 > To: Stefan Santesson > Cc: ietf-pkix@imc.org > Subject: Re: SMIME Capabilities in X.509 certificates. > > Stefan, > > Given that SMIMECapabilities is an Attribute, why not put it in the > SubjectDirectoryAttributes extension rather than trying to treat it as a > certificate extension? Well, today we put this as an extension. In general this is not a suitable directory attribute since it has to be signed. Manipulating this attribute for a subject could have security implications. Having said that, I would wait with the HOW discussions until we have decided IF we want to standardize this practice at all. > > It's not clear to me how this extension would be populated. How does > the CA know the S/MIME capabilities of the certificate subject? Does > the CA assume that the capabilities are the same for all of its > subscribers or does the subscriber specify this information in the > certificate request? The CA can't populate the attribute on its own > unless it really knows what e-mail client software every subscriber is > using. Otherwise the contents of the attribute wouldn't be very > useful. In theory, the contents of the attribute could reflect the > capabilities of the subscriber if the subscriber specified the > contents. But, I don't see how this would work in practice unless the > subscriber's e-mail client generated the certificate request, which > doesn't seem realistic. I would turn it around. Some CAs actually has access to this information about users, especially if the CA is a local enterprise CA with access to local policies for users. In this case, the inclusion is straight forward and sufficiently accurate. Since there without doubts are ways where the CA can know this information, the interesting question is whether the world would benefit from a standard way to read this information from a certificate, if the CA has chosen to put it there, which many CAs already do. Again I would repeat that the use of this information is just a last resource in the situations where no other knowledge is available. > Besides, if the information in the SMIMECapabilities attribute is only > of use to S/MIME clients, shouldn't this be an S/MIME working group > consideration rather than PKIX? That is not for me to decide. I have been asked to post this to PKIX since it is a certificate format issue, but if this is to be done, it will absolutely also has an intersection with SMIME. /Stefan > > Dave > > Stefan Santesson wrote: > > >OK Steve. > > > >Let me try to recap this issue and see if we at least can get to a > >debate whether this is worth doing or not. > > > >The issue on the table is whether it should be a standardized option to > >include the SMIME capability attribute in a certificate. > > > >Microsoft is currently supporting inclusion of this attribute in > >certificates using the standard PKCS#9 OID as extension OID and thus > >using the standard PKCS#9 attribute syntax as extension syntax. > > > >This extension, when present in certificates is used as the last > >resource to figure out the appropriate configuration/capabilities of an > >S/MIME opponent before falling back to default configuration for unknown > >users. > > > >This is useful in particular when an encrypted e-mail is sent to a > >recipient whose certificate is known but where the recipient's > >capabilities otherwise are unknown. > > > >But if there is a known previous S/MIME message from the recipient from > >which the recipient's capabilities can be extracted, the certificate > >extension would typically be ignored. > > > >The underlying rationale for this is that in a store and forward type of > >communication such as e-mail, we may run into situation where one party > >need to guess the capabilities of the opponent and the guiding principle > >is that the more information we can use to make the best guess, the > >better it is. > > > >Using such SMIMECapabilities extension in certificates as the last > >resource of information is supporting that rationale. > > > >So, again, please state your opinion so we can either do this or put it > >away. If it is to be done, the task should be very simple since there > >should be no reason to deviate from the current syntax of the > >SMIMECapabilities attribute used in S/MIME. > > ------_=_NextPart_001_01C42E54.3BC8F414 Content-Type: text/html; charset="iso-8859-1" <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1"> <TITLE>RE: SMIME Capabilities in X.509 certificates.</TITLE> <META content="MSHTML 6.00.2600.0" name=GENERATOR> <STYLE>@font-face { font-family: Tahoma; } @page Section1 {size: 612.0pt 792.0pt; margin: 0pt 180.0pt 0pt 0pt; } P.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0pt; FONT-FAMILY: "Times New Roman" } LI.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0pt; FONT-FAMILY: "Times New Roman" } DIV.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0pt; FONT-FAMILY: "Times New Roman" } A:link { COLOR: blue; TEXT-DECORATION: underline } SPAN.MsoHyperlink { COLOR: blue; TEXT-DECORATION: underline } A:visited { COLOR: blue; TEXT-DECORATION: underline } SPAN.MsoHyperlinkFollowed { COLOR: blue; TEXT-DECORATION: underline } P { FONT-SIZE: 12pt; MARGIN-LEFT: 0pt; MARGIN-RIGHT: 0pt; FONT-FAMILY: "Times New Roman" } SPAN.EmailStyle18 { COLOR: navy; FONT-FAMILY: Arial } DIV.Section1 { page: Section1 } </STYLE> </HEAD> <BODY lang=EN-US vLink=blue link=blue> <DIV><SPAN class=412453801-30042004><FONT face=Arial color=#0000ff size=2>I can't agree more, Trevor, and as you imply, sometimes adult or corporate supervision can be a good thing. Even for us baby boomers weened on "doing our own thing!" (And yes, 3DES or AES are acceptable under our policies, although one give 112 and the other 128+ bits of key strength; as you know, both as unbreakable.)</FONT></SPAN></DIV> <DIV> </DIV><BR> <P><B><FONT face=Arial size=2>Richard A. Guida</FONT></B> <BR><B><FONT face=Arial size=2>Director, Information Security</FONT></B> </P> <P><B><I><FONT face="Times New Roman" color=#ff0000 size=5>Johnson & Johnson</FONT></I></B><I></I> <BR><FONT face=Arial size=2>Room GS8217</FONT> <BR><FONT face=Arial size=2>410 George Street</FONT> <BR><FONT face=Arial size=2>New Brunswick, New Jersey 08901</FONT> <BR><FONT face=Arial size=2>Phone: 732 524 3785</FONT> </P> <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px"> <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma size=2>-----Original Message-----<BR><B>From:</B> Trevor Freeman [mailto:trevorf@exchange.microsoft.com]<BR><B>Sent:</B> Thursday, April 29, 2004 9:25 PM<BR><B>To:</B> Guida, Richard [JJCUS]; Stefan Santesson; David A. Cooper<BR><B>Cc:</B> ietf-pkix@imc.org<BR><B>Subject:</B> RE: SMIME Capabilities in X.509 certificates.<BR><BR></FONT></DIV> <DIV class=Section1> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Hi Rich,</SPAN></FONT></P> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">As one lurker to another, you also need to consider that it is accepted practice with SMIME today for the client to self certify this data so the potential for having this in the certificate could lead to some adult or corporate supervision. Also if you say you have a preference for AES and 3DES, you are saying both are acceptable otherwise you should not offer the alternatives. So having more ways to express your preference is better.</SPAN></FONT></P> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"></SPAN></FONT> </P> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Trevor</SPAN></FONT></P> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"></SPAN></FONT> </P> <DIV> <DIV class=MsoNormal style="TEXT-ALIGN: center" align=center><FONT face="Times New Roman" size=3><SPAN style="FONT-SIZE: 12pt"> <HR tabIndex=-1 align=center width="100%" SIZE=2> </SPAN></FONT></DIV> <P class=MsoNormal><B><FONT face=Tahoma size=2><SPAN style="FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: Tahoma">From:</SPAN></FONT></B><FONT face=Tahoma size=2><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Tahoma"> owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] <B><SPAN style="FONT-WEIGHT: bold">On Behalf Of </SPAN></B>Guida, Richard [JJCUS]<BR><B><SPAN style="FONT-WEIGHT: bold">Sent:</SPAN></B> Thursday, April 29, 2004 5:31 PM<BR><B><SPAN style="FONT-WEIGHT: bold">To:</SPAN></B> Stefan Santesson; David A. Cooper<BR><B><SPAN style="FONT-WEIGHT: bold">Cc:</SPAN></B> ietf-pkix@imc.org<BR><B><SPAN style="FONT-WEIGHT: bold">Subject:</SPAN></B> RE: SMIME Capabilities in X.509 certificates.</SPAN></FONT></P></DIV> <P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN style="FONT-SIZE: 12pt"></SPAN></FONT> </P> <P><FONT face="Times New Roman" size=2><SPAN style="FONT-SIZE: 10pt">Forgive me for coming out of lurker status on this one, but I do think that Stefan's arguments for this attribute are good ones; we have a requirement to use only strong crypto (3DES, AES, etc.) but of course enforcing that with S/MIME is tricky, requiring more user knowledge than one would expect of most users (clicking on the encryption icon, seeing the crypto strength, confirming it is o.k...). An extension like this (or semantic info in an existing extension) could be very helpful. David's points are correct that a CA may not know the S/MIME capabilities (or requirements) of its subjects - but I agree with Stefan's response that in some cases (like our enterprise environment), it does, so this info can have real utility. Two cents worth...</SPAN></FONT></P> <P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN style="FONT-SIZE: 12pt"></SPAN></FONT> </P> <P><FONT face="Times New Roman" size=2><SPAN style="FONT-SIZE: 10pt">Richard A. Guida</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">Director, Information Security</SPAN></FONT> </P> <P><FONT face="Times New Roman" size=2><SPAN style="FONT-SIZE: 10pt">Johnson & Johnson</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">Room GS8217</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">410 George Street<FONT size=3><SPAN style="FONT-SIZE: 12pt"> <BR></SPAN></FONT>New Brunswick, New Jersey 08901</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">Phone: 732 524 3785</SPAN></FONT> </P> <P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN style="FONT-SIZE: 12pt"></SPAN></FONT> </P> <P><FONT face="Times New Roman" size=2><SPAN style="FONT-SIZE: 10pt">-----Original Message-----</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">From: Stefan Santesson [<A href="mailto:stefans@microsoft.com">mailto:stefans@microsoft.com</A>]</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">Sent: Thursday, April 29, 2004 2:24 PM</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">To: David A. Cooper</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">Cc: ietf-pkix@imc.org</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">Subject: RE: SMIME Capabilities in X.509 certificates.</SPAN></FONT> </P> <P class=MsoNormal style="MARGIN-BOTTOM: 12pt"><FONT face="Times New Roman" size=3><SPAN style="FONT-SIZE: 12pt"></SPAN></FONT> </P> <P><FONT face="Times New Roman" size=2><SPAN style="FONT-SIZE: 10pt">David,</SPAN></FONT> </P> <P><FONT face="Times New Roman" size=2><SPAN style="FONT-SIZE: 10pt">Comment in line;</SPAN></FONT> </P> <P><FONT face="Times New Roman" size=2><SPAN style="FONT-SIZE: 10pt">> -----Original Message-----</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> From: David A. Cooper [<A href="mailto:david.cooper@nist.gov">mailto:david.cooper@nist.gov</A>]</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> Sent: den 29 april 2004 10:59</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> To: Stefan Santesson</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> Cc: ietf-pkix@imc.org</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> Subject: Re: SMIME Capabilities in X.509 certificates.</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> </SPAN></FONT><BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> Stefan,</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> </SPAN></FONT><BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> Given that SMIMECapabilities is an Attribute, why not put it in the</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> SubjectDirectoryAttributes extension rather than trying to treat it as</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">a</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> certificate extension?</SPAN></FONT> </P> <P><FONT face="Times New Roman" size=2><SPAN style="FONT-SIZE: 10pt">Well, today we put this as an extension. In general this is not a</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">suitable directory attribute since it has to be signed. Manipulating</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">this attribute for a subject could have security implications.</SPAN></FONT> </P> <P><FONT face="Times New Roman" size=2><SPAN style="FONT-SIZE: 10pt">Having said that, I would wait with the HOW discussions until we have</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">decided IF we want to standardize this practice at all.</SPAN></FONT> </P> <P><FONT face="Times New Roman" size=2><SPAN style="FONT-SIZE: 10pt">> </SPAN></FONT><BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> It's not clear to me how this extension would be populated. How does</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> the CA know the S/MIME capabilities of the certificate subject? Does</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> the CA assume that the capabilities are the same for all of its</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> subscribers or does the subscriber specify this information in the</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> certificate request? The CA can't populate the attribute on its own</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> unless it really knows what e-mail client software every subscriber is</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> using. Otherwise the contents of the attribute wouldn't be very</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> useful. In theory, the contents of the attribute could reflect the</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> capabilities of the subscriber if the subscriber specified the</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> contents. But, I don't see how this would work in practice unless the</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> subscriber's e-mail client generated the certificate request, which</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> doesn't seem realistic.</SPAN></FONT> </P> <P><FONT face="Times New Roman" size=2><SPAN style="FONT-SIZE: 10pt">I would turn it around. Some CAs actually has access to this information</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">about users, especially if the CA is a local enterprise CA with access</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">to local policies for users. In this case, the inclusion is straight</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">forward and sufficiently accurate.</SPAN></FONT> </P> <P><FONT face="Times New Roman" size=2><SPAN style="FONT-SIZE: 10pt">Since there without doubts are ways where the CA can know this</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">information, the interesting question is whether the world would benefit</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">from a standard way to read this information from a certificate, if the</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">CA has chosen to put it there, which many CAs already do.</SPAN></FONT> </P> <P><FONT face="Times New Roman" size=2><SPAN style="FONT-SIZE: 10pt">Again I would repeat that the use of this information is just a last</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">resource in the situations where no other knowledge is available.</SPAN></FONT> </P> <P><FONT face="Times New Roman" size=2><SPAN style="FONT-SIZE: 10pt">> Besides, if the information in the SMIMECapabilities attribute is only</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> of use to S/MIME clients, shouldn't this be an S/MIME working group</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> consideration rather than PKIX?</SPAN></FONT> </P> <P><FONT face="Times New Roman" size=2><SPAN style="FONT-SIZE: 10pt">That is not for me to decide. I have been asked to post this to PKIX</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">since it is a certificate format issue, but if this is to be done, it</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">will absolutely also has an intersection with SMIME.</SPAN></FONT> </P> <P><FONT face="Times New Roman" size=2><SPAN style="FONT-SIZE: 10pt">/Stefan</SPAN></FONT> </P> <P><FONT face="Times New Roman" size=2><SPAN style="FONT-SIZE: 10pt">> </SPAN></FONT><BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> Dave</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> </SPAN></FONT><BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> Stefan Santesson wrote:</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> </SPAN></FONT><BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> >OK Steve.</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> ></SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> >Let me try to recap this issue and see if we at least can get to a</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> >debate whether this is worth doing or not.</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> ></SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> >The issue on the table is whether it should be a standardized option</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">to</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> >include the SMIME capability attribute in a certificate.</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> ></SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> >Microsoft is currently supporting inclusion of this attribute in</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> >certificates using the standard PKCS#9 OID as extension OID and thus</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> >using the standard PKCS#9 attribute syntax as extension syntax.</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> ></SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> >This extension, when present in certificates is used as the last</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> >resource to figure out the appropriate configuration/capabilities of</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">an</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> >S/MIME opponent before falling back to default configuration for</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">unknown</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> >users.</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> ></SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> >This is useful in particular when an encrypted e-mail is sent to a</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> >recipient whose certificate is known but where the recipient's</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> >capabilities otherwise are unknown.</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> ></SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> >But if there is a known previous S/MIME message from the recipient</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">from</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> >which the recipient's capabilities can be extracted, the certificate</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> >extension would typically be ignored.</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> ></SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> >The underlying rationale for this is that in a store and forward type</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">of</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> >communication such as e-mail, we may run into situation where one</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">party</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> >need to guess the capabilities of the opponent and the guiding</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">principle</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> >is that the more information we can use to make the best guess, the</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> >better it is.</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> ></SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> >Using such SMIMECapabilities extension in certificates as the last</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> >resource of information is supporting that rationale.</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> ></SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> >So, again, please state your opinion so we can either do this or put</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">it</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> >away. If it is to be done, the task should be very simple since there</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> >should be no reason to deviate from the current syntax of the</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> >SMIMECapabilities attribute used in S/MIME.</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> ></SPAN></FONT> </P></DIV></BLOCKQUOTE></BODY></HTML> ------_=_NextPart_001_01C42E54.3BC8F414-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3U1P2RT005131; Thu, 29 Apr 2004 18:25:02 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3U1P2hb005130; Thu, 29 Apr 2004 18:25:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from exchange.microsoft.com ([131.107.8.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3U1P1UW005121 for <ietf-pkix@imc.org>; Thu, 29 Apr 2004 18:25:01 -0700 (PDT) (envelope-from trevorf@exchange.microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 29 Apr 2004 18:25:07 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 29 Apr 2004 18:25:12 -0700 Received: from DF-GROMMIT-01.mercury.corp.microsoft.com ([10.197.0.61]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 29 Apr 2004 18:25:07 -0700 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-701fd0bd-50a1-4598-877d-e46299425b15" Subject: RE: SMIME Capabilities in X.509 certificates. Date: Thu, 29 Apr 2004 18:25:00 -0700 Message-ID: <33E7A1613A3480448996047B69308A2F027130F5@df-grommit-01.dogfood> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SMIME Capabilities in X.509 certificates. thread-index: AcQuTuYCV+SAF0/XSqSNPRiVIDiViQAAhrKQ From: "Trevor Freeman" <trevorf@exchange.microsoft.com> To: "Guida, Richard [JJCUS]" <RGuida@CORUS.JNJ.com>, "Stefan Santesson" <stefans@microsoft.com>, "David A. Cooper" <david.cooper@nist.gov> Cc: <ietf-pkix@imc.org> X-OriginalArrivalTime: 30 Apr 2004 01:25:07.0313 (UTC) FILETIME=[F8B61E10:01C42E51] Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> This is a multi-part message in MIME format. ------=_NextPartTM-000-701fd0bd-50a1-4598-877d-e46299425b15 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C42E51.F85BC7B3" ------_=_NextPart_001_01C42E51.F85BC7B3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Rich, As one lurker to another, you also need to consider that it is accepted practice with SMIME today for the client to self certify this data so the potential for having this in the certificate could lead to some adult or corporate supervision. Also if you say you have a preference for AES and 3DES, you are saying both are acceptable otherwise you should not offer the alternatives. So having more ways to express your preference is better. =20 Trevor =20 ________________________________ From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Guida, Richard [JJCUS] Sent: Thursday, April 29, 2004 5:31 PM To: Stefan Santesson; David A. Cooper Cc: ietf-pkix@imc.org Subject: RE: SMIME Capabilities in X.509 certificates. =20 Forgive me for coming out of lurker status on this one, but I do think that Stefan's arguments for this attribute are good ones; we have a requirement to use only strong crypto (3DES, AES, etc.) but of course enforcing that with S/MIME is tricky, requiring more user knowledge than one would expect of most users (clicking on the encryption icon, seeing the crypto strength, confirming it is o.k...). An extension like this (or semantic info in an existing extension) could be very helpful. David's points are correct that a CA may not know the S/MIME capabilities (or requirements) of its subjects - but I agree with Stefan's response that in some cases (like our enterprise environment), it does, so this info can have real utility. Two cents worth... =20 Richard A. Guida=20 Director, Information Security=20 Johnson & Johnson=20 Room GS8217=20 410 George Street=20 New Brunswick, New Jersey 08901=20 Phone: 732 524 3785=20 =20 -----Original Message-----=20 From: Stefan Santesson [mailto:stefans@microsoft.com]=20 Sent: Thursday, April 29, 2004 2:24 PM=20 To: David A. Cooper=20 Cc: ietf-pkix@imc.org=20 Subject: RE: SMIME Capabilities in X.509 certificates.=20 =20 David,=20 Comment in line;=20 > -----Original Message-----=20 > From: David A. Cooper [mailto:david.cooper@nist.gov]=20 > Sent: den 29 april 2004 10:59=20 > To: Stefan Santesson=20 > Cc: ietf-pkix@imc.org=20 > Subject: Re: SMIME Capabilities in X.509 certificates.=20 >=20 > Stefan,=20 >=20 > Given that SMIMECapabilities is an Attribute, why not put it in the=20 > SubjectDirectoryAttributes extension rather than trying to treat it as a=20 > certificate extension?=20 Well, today we put this as an extension. In general this is not a=20 suitable directory attribute since it has to be signed. Manipulating=20 this attribute for a subject could have security implications.=20 Having said that, I would wait with the HOW discussions until we have=20 decided IF we want to standardize this practice at all.=20 >=20 > It's not clear to me how this extension would be populated. How does=20 > the CA know the S/MIME capabilities of the certificate subject? Does=20 > the CA assume that the capabilities are the same for all of its=20 > subscribers or does the subscriber specify this information in the=20 > certificate request? The CA can't populate the attribute on its own=20 > unless it really knows what e-mail client software every subscriber is > using. Otherwise the contents of the attribute wouldn't be very=20 > useful. In theory, the contents of the attribute could reflect the=20 > capabilities of the subscriber if the subscriber specified the=20 > contents. But, I don't see how this would work in practice unless the > subscriber's e-mail client generated the certificate request, which=20 > doesn't seem realistic.=20 I would turn it around. Some CAs actually has access to this information about users, especially if the CA is a local enterprise CA with access=20 to local policies for users. In this case, the inclusion is straight=20 forward and sufficiently accurate.=20 Since there without doubts are ways where the CA can know this=20 information, the interesting question is whether the world would benefit from a standard way to read this information from a certificate, if the=20 CA has chosen to put it there, which many CAs already do.=20 Again I would repeat that the use of this information is just a last=20 resource in the situations where no other knowledge is available.=20 > Besides, if the information in the SMIMECapabilities attribute is only > of use to S/MIME clients, shouldn't this be an S/MIME working group=20 > consideration rather than PKIX?=20 That is not for me to decide. I have been asked to post this to PKIX=20 since it is a certificate format issue, but if this is to be done, it=20 will absolutely also has an intersection with SMIME.=20 /Stefan=20 >=20 > Dave=20 >=20 > Stefan Santesson wrote:=20 >=20 > >OK Steve.=20 > >=20 > >Let me try to recap this issue and see if we at least can get to a=20 > >debate whether this is worth doing or not.=20 > >=20 > >The issue on the table is whether it should be a standardized option=20 to=20 > >include the SMIME capability attribute in a certificate.=20 > >=20 > >Microsoft is currently supporting inclusion of this attribute in=20 > >certificates using the standard PKCS#9 OID as extension OID and thus=20 > >using the standard PKCS#9 attribute syntax as extension syntax.=20 > >=20 > >This extension, when present in certificates is used as the last=20 > >resource to figure out the appropriate configuration/capabilities of=20 an=20 > >S/MIME opponent before falling back to default configuration for=20 unknown=20 > >users.=20 > >=20 > >This is useful in particular when an encrypted e-mail is sent to a=20 > >recipient whose certificate is known but where the recipient's=20 > >capabilities otherwise are unknown.=20 > >=20 > >But if there is a known previous S/MIME message from the recipient=20 from=20 > >which the recipient's capabilities can be extracted, the certificate=20 > >extension would typically be ignored.=20 > >=20 > >The underlying rationale for this is that in a store and forward type of=20 > >communication such as e-mail, we may run into situation where one=20 party=20 > >need to guess the capabilities of the opponent and the guiding=20 principle=20 > >is that the more information we can use to make the best guess, the=20 > >better it is.=20 > >=20 > >Using such SMIMECapabilities extension in certificates as the last=20 > >resource of information is supporting that rationale.=20 > >=20 > >So, again, please state your opinion so we can either do this or put=20 it=20 > >away. If it is to be done, the task should be very simple since there > >should be no reason to deviate from the current syntax of the=20 > >SMIMECapabilities attribute used in S/MIME.=20 > >=20 ------_=_NextPart_001_01C42E51.F85BC7B3 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3DContent-Type content=3D"text/html; = charset=3Dus-ascii"> <meta name=3DGenerator content=3D"Microsoft Word 11 (filtered)"> <title>RE: SMIME Capabilities in X.509 certificates.</title> <style> <!-- /* Font Definitions */ @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0pt; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman";} a:link, span.MsoHyperlink {color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {color:blue; text-decoration:underline;} p {margin-right:0pt; margin-left:0pt; font-size:12.0pt; font-family:"Times New Roman";} span.EmailStyle18 {font-family:Arial; color:navy;} @page Section1 {size:612.0pt 792.0pt; margin:0pt 180.0pt 0pt 0pt;} div.Section1 {page:Section1;} --> </style> </head> <body lang=3DEN-US link=3Dblue vlink=3Dblue> <div class=3DSection1> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span = style=3D'font-size: 10.0pt;font-family:Arial;color:navy'>Hi Rich,</span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span = style=3D'font-size: 10.0pt;font-family:Arial;color:navy'>As one lurker to another, you also = need to consider that it is accepted practice with SMIME today for the client to = self certify this data so the potential for having this in the certificate could lead = to some adult or corporate supervision. Also if you say you have a = preference for AES and 3DES, you are saying both are acceptable otherwise you should = not offer the alternatives. So having more ways to express your preference is = better.</span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span = style=3D'font-size: 10.0pt;font-family:Arial;color:navy'> </span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span = style=3D'font-size: 10.0pt;font-family:Arial;color:navy'>Trevor</span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span = style=3D'font-size: 10.0pt;font-family:Arial;color:navy'> </span></font></p> <div> <div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font = size=3D3 face=3D"Times New Roman"><span style=3D'font-size:12.0pt'> <hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1> </span></font></div> <p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span = style=3D'font-size:10.0pt; font-family:Tahoma;font-weight:bold'>From:</span></font></b><font = size=3D2 face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'> owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] = <b><span style=3D'font-weight:bold'>On Behalf Of </span></b>Guida, Richard = [JJCUS]<br> <b><span style=3D'font-weight:bold'>Sent:</span></b> Thursday, April 29, = 2004 5:31 PM<br> <b><span style=3D'font-weight:bold'>To:</span></b> Stefan Santesson; = David A. Cooper<br> <b><span style=3D'font-weight:bold'>Cc:</span></b> ietf-pkix@imc.org<br> <b><span style=3D'font-weight:bold'>Subject:</span></b> RE: SMIME = Capabilities in X.509 certificates.</span></font></p> </div> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span = style=3D'font-size: 12.0pt'> </span></font></p> <p><font size=3D2 face=3D"Times New Roman"><span = style=3D'font-size:10.0pt'>Forgive me for coming out of lurker status on this one, but I do think that = Stefan's arguments for this attribute are good ones; we have a requirement to use = only strong crypto (3DES, AES, etc.) but of course enforcing that with S/MIME = is tricky, requiring more user knowledge than one would expect of most = users (clicking on the encryption icon, seeing the crypto strength, confirming = it is o.k...). An extension like this (or semantic info in an existing extension) could be very helpful. David's points are correct that = a CA may not know the S/MIME capabilities (or requirements) of its subjects - = but I agree with Stefan's response that in some cases (like our enterprise environment), it does, so this info can have real utility. Two = cents worth...</span></font></p> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span = style=3D'font-size: 12.0pt'> </span></font></p> <p><font size=3D2 face=3D"Times New Roman"><span = style=3D'font-size:10.0pt'>Richard A. Guida</span></font> <br> <font size=3D2><span style=3D'font-size:10.0pt'>Director, Information = Security</span></font> </p> <p><font size=3D2 face=3D"Times New Roman"><span = style=3D'font-size:10.0pt'>Johnson & Johnson</span></font> <br> <font size=3D2><span style=3D'font-size:10.0pt'>Room = GS8217</span></font> <br> <font size=3D2><span style=3D'font-size:10.0pt'>410 George Street<font = size=3D3><span style=3D'font-size:12.0pt'> <br> </span></font>New Brunswick, New Jersey 08901</span></font> <br> <font size=3D2><span style=3D'font-size:10.0pt'>Phone: 732 524 = 3785</span></font> </p> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span = style=3D'font-size: 12.0pt'> </span></font></p> <p><font size=3D2 face=3D"Times New Roman"><span = style=3D'font-size:10.0pt'>-----Original Message-----</span></font> <br> <font size=3D2><span style=3D'font-size:10.0pt'>From: Stefan Santesson = [<a href=3D"mailto:stefans@microsoft.com">mailto:stefans@microsoft.com</a>]</= span></font> <br> <font size=3D2><span style=3D'font-size:10.0pt'>Sent: Thursday, April = 29, 2004 2:24 PM</span></font> <br> <font size=3D2><span style=3D'font-size:10.0pt'>To: David A. = Cooper</span></font> <br> <font size=3D2><span style=3D'font-size:10.0pt'>Cc: = ietf-pkix@imc.org</span></font> <br> <font size=3D2><span style=3D'font-size:10.0pt'>Subject: RE: SMIME = Capabilities in X.509 certificates.</span></font> </p> <p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><font size=3D3 face=3D"Times New Roman"><span = style=3D'font-size:12.0pt'> </span></font></p> <p><font size=3D2 face=3D"Times New Roman"><span = style=3D'font-size:10.0pt'>David,</span></font> </p> <p><font size=3D2 face=3D"Times New Roman"><span = style=3D'font-size:10.0pt'>Comment in line;</span></font> </p> <p><font size=3D2 face=3D"Times New Roman"><span = style=3D'font-size:10.0pt'>> -----Original Message-----</span></font> <br> <font size=3D2><span style=3D'font-size:10.0pt'>> From: David A. = Cooper [<a href=3D"mailto:david.cooper@nist.gov">mailto:david.cooper@nist.gov</a>]</= span></font> <br> <font size=3D2><span style=3D'font-size:10.0pt'>> Sent: den 29 april = 2004 10:59</span></font> <br> <font size=3D2><span style=3D'font-size:10.0pt'>> To: Stefan = Santesson</span></font> <br> <font size=3D2><span style=3D'font-size:10.0pt'>> Cc: = ietf-pkix@imc.org</span></font> <br> <font size=3D2><span style=3D'font-size:10.0pt'>> Subject: Re: SMIME Capabilities in X.509 certificates.</span></font> <br> <font size=3D2><span style=3D'font-size:10.0pt'>> </span></font><br> <font size=3D2><span style=3D'font-size:10.0pt'>> = Stefan,</span></font> <br> <font size=3D2><span style=3D'font-size:10.0pt'>> </span></font><br> <font size=3D2><span style=3D'font-size:10.0pt'>> Given that = SMIMECapabilities is an Attribute, why not put it in the</span></font> <br> <font size=3D2><span style=3D'font-size:10.0pt'>> = SubjectDirectoryAttributes extension rather than trying to treat it as</span></font> <br> <font size=3D2><span style=3D'font-size:10.0pt'>a</span></font> <br> <font size=3D2><span style=3D'font-size:10.0pt'>> certificate = extension?</span></font> </p> <p><font size=3D2 face=3D"Times New Roman"><span = style=3D'font-size:10.0pt'>Well, today we put this as an extension. In general this is not = a</span></font> <br> <font size=3D2><span style=3D'font-size:10.0pt'>suitable directory = attribute since it has to be signed. Manipulating</span></font> <br> <font size=3D2><span style=3D'font-size:10.0pt'>this attribute for a = subject could have security implications.</span></font> </p> <p><font size=3D2 face=3D"Times New Roman"><span = style=3D'font-size:10.0pt'>Having said that, I would wait with the HOW discussions until we = have</span></font> <br> <font size=3D2><span style=3D'font-size:10.0pt'>decided IF we want to = standardize this practice at all.</span></font> </p> <p><font size=3D2 face=3D"Times New Roman"><span = style=3D'font-size:10.0pt'>> </span></font><br> <font size=3D2><span style=3D'font-size:10.0pt'>> It's not clear to = me how this extension would be populated. How does</span></font> <br> <font size=3D2><span style=3D'font-size:10.0pt'>> the CA know the = S/MIME capabilities of the certificate subject? Does</span></font> <br> <font size=3D2><span style=3D'font-size:10.0pt'>> the CA assume that = the capabilities are the same for all of its</span></font> <br> <font size=3D2><span style=3D'font-size:10.0pt'>> subscribers or does = the subscriber specify this information in the</span></font> <br> <font size=3D2><span style=3D'font-size:10.0pt'>> certificate = request? The CA can't populate the attribute on its own</span></font> <br> <font size=3D2><span style=3D'font-size:10.0pt'>> unless it really = knows what e-mail client software every subscriber is</span></font> <br> <font size=3D2><span style=3D'font-size:10.0pt'>> using. = Otherwise the contents of the attribute wouldn't be very</span></font> <br> <font size=3D2><span style=3D'font-size:10.0pt'>> useful. In = theory, the contents of the attribute could reflect the</span></font> <br> <font size=3D2><span style=3D'font-size:10.0pt'>> capabilities of the = subscriber if the subscriber specified the</span></font> <br> <font size=3D2><span style=3D'font-size:10.0pt'>> contents. = But, I don't see how this would work in practice unless the</span></font> <br> <font size=3D2><span style=3D'font-size:10.0pt'>> subscriber's e-mail = client generated the certificate request, which</span></font> <br> <font size=3D2><span style=3D'font-size:10.0pt'>> doesn't seem = realistic.</span></font> </p> <p><font size=3D2 face=3D"Times New Roman"><span = style=3D'font-size:10.0pt'>I would turn it around. Some CAs actually has access to this = information</span></font> <br> <font size=3D2><span style=3D'font-size:10.0pt'>about users, especially = if the CA is a local enterprise CA with access</span></font> <br> <font size=3D2><span style=3D'font-size:10.0pt'>to local policies for = users. In this case, the inclusion is straight</span></font> <br> <font size=3D2><span style=3D'font-size:10.0pt'>forward and sufficiently = accurate.</span></font> </p> <p><font size=3D2 face=3D"Times New Roman"><span = style=3D'font-size:10.0pt'>Since there without doubts are ways where the CA can know this</span></font> = <br> <font size=3D2><span style=3D'font-size:10.0pt'>information, the = interesting question is whether the world would benefit</span></font> <br> <font size=3D2><span style=3D'font-size:10.0pt'>from a standard way to = read this information from a certificate, if the</span></font> <br> <font size=3D2><span style=3D'font-size:10.0pt'>CA has chosen to put it = there, which many CAs already do.</span></font> </p> <p><font size=3D2 face=3D"Times New Roman"><span = style=3D'font-size:10.0pt'>Again I would repeat that the use of this information is just a = last</span></font> <br> <font size=3D2><span style=3D'font-size:10.0pt'>resource in the = situations where no other knowledge is available.</span></font> </p> <p><font size=3D2 face=3D"Times New Roman"><span = style=3D'font-size:10.0pt'>> Besides, if the information in the SMIMECapabilities attribute is = only</span></font> <br> <font size=3D2><span style=3D'font-size:10.0pt'>> of use to S/MIME = clients, shouldn't this be an S/MIME working group</span></font> <br> <font size=3D2><span style=3D'font-size:10.0pt'>> consideration = rather than PKIX?</span></font> </p> <p><font size=3D2 face=3D"Times New Roman"><span = style=3D'font-size:10.0pt'>That is not for me to decide. I have been asked to post this to = PKIX</span></font> <br> <font size=3D2><span style=3D'font-size:10.0pt'>since it is a = certificate format issue, but if this is to be done, it</span></font> <br> <font size=3D2><span style=3D'font-size:10.0pt'>will absolutely also has = an intersection with SMIME.</span></font> </p> <p><font size=3D2 face=3D"Times New Roman"><span = style=3D'font-size:10.0pt'>/Stefan</span></font> </p> <p><font size=3D2 face=3D"Times New Roman"><span = style=3D'font-size:10.0pt'>> </span></font><br> <font size=3D2><span style=3D'font-size:10.0pt'>> Dave</span></font> = <br> <font size=3D2><span style=3D'font-size:10.0pt'>> </span></font><br> <font size=3D2><span style=3D'font-size:10.0pt'>> Stefan Santesson = wrote:</span></font> <br> <font size=3D2><span style=3D'font-size:10.0pt'>> </span></font><br> <font size=3D2><span style=3D'font-size:10.0pt'>> >OK = Steve.</span></font> <br> <font size=3D2><span style=3D'font-size:10.0pt'>> ></span></font> = <br> <font size=3D2><span style=3D'font-size:10.0pt'>> >Let me try to = recap this issue and see if we at least can get to a</span></font> <br> <font size=3D2><span style=3D'font-size:10.0pt'>> >debate whether = this is worth doing or not.</span></font> <br> <font size=3D2><span style=3D'font-size:10.0pt'>> ></span></font> = <br> <font size=3D2><span style=3D'font-size:10.0pt'>> >The issue on = the table is whether it should be a standardized option</span></font> <br> <font size=3D2><span style=3D'font-size:10.0pt'>to</span></font> <br> <font size=3D2><span style=3D'font-size:10.0pt'>> >include the = SMIME capability attribute in a certificate.</span></font> <br> <font size=3D2><span style=3D'font-size:10.0pt'>> ></span></font> = <br> <font size=3D2><span style=3D'font-size:10.0pt'>> >Microsoft is = currently supporting inclusion of this attribute in</span></font> <br> <font size=3D2><span style=3D'font-size:10.0pt'>> >certificates = using the standard PKCS#9 OID as extension OID and thus</span></font> <br> <font size=3D2><span style=3D'font-size:10.0pt'>> >using the = standard PKCS#9 attribute syntax as extension syntax.</span></font> <br> <font size=3D2><span style=3D'font-size:10.0pt'>> ></span></font> = <br> <font size=3D2><span style=3D'font-size:10.0pt'>> >This extension, = when present in certificates is used as the last</span></font> <br> <font size=3D2><span style=3D'font-size:10.0pt'>> >resource to = figure out the appropriate configuration/capabilities of</span></font> <br> <font size=3D2><span style=3D'font-size:10.0pt'>an</span></font> <br> <font size=3D2><span style=3D'font-size:10.0pt'>> >S/MIME opponent = before falling back to default configuration for</span></font> <br> <font size=3D2><span style=3D'font-size:10.0pt'>unknown</span></font> = <br> <font size=3D2><span style=3D'font-size:10.0pt'>> = >users.</span></font> <br> <font size=3D2><span style=3D'font-size:10.0pt'>> ></span></font> = <br> <font size=3D2><span style=3D'font-size:10.0pt'>> >This is useful = in particular when an encrypted e-mail is sent to a</span></font> <br> <font size=3D2><span style=3D'font-size:10.0pt'>> >recipient whose certificate is known but where the recipient's</span></font> <br> <font size=3D2><span style=3D'font-size:10.0pt'>> >capabilities = otherwise are unknown.</span></font> <br> <font size=3D2><span style=3D'font-size:10.0pt'>> ></span></font> = <br> <font size=3D2><span style=3D'font-size:10.0pt'>> >But if there is = a known previous S/MIME message from the recipient</span></font> <br> <font size=3D2><span style=3D'font-size:10.0pt'>from</span></font> <br> <font size=3D2><span style=3D'font-size:10.0pt'>> >which the = recipient's capabilities can be extracted, the certificate</span></font> <br> <font size=3D2><span style=3D'font-size:10.0pt'>> >extension would = typically be ignored.</span></font> <br> <font size=3D2><span style=3D'font-size:10.0pt'>> ></span></font> = <br> <font size=3D2><span style=3D'font-size:10.0pt'>> >The underlying = rationale for this is that in a store and forward type</span></font> <br> <font size=3D2><span style=3D'font-size:10.0pt'>of</span></font> <br> <font size=3D2><span style=3D'font-size:10.0pt'>> >communication = such as e-mail, we may run into situation where one</span></font> <br> <font size=3D2><span style=3D'font-size:10.0pt'>party</span></font> <br> <font size=3D2><span style=3D'font-size:10.0pt'>> >need to guess = the capabilities of the opponent and the guiding</span></font> <br> <font size=3D2><span style=3D'font-size:10.0pt'>principle</span></font> = <br> <font size=3D2><span style=3D'font-size:10.0pt'>> >is that the = more information we can use to make the best guess, the</span></font> <br> <font size=3D2><span style=3D'font-size:10.0pt'>> >better it = is.</span></font> <br> <font size=3D2><span style=3D'font-size:10.0pt'>> ></span></font> = <br> <font size=3D2><span style=3D'font-size:10.0pt'>> >Using such SMIMECapabilities extension in certificates as the last</span></font> = <br> <font size=3D2><span style=3D'font-size:10.0pt'>> >resource of = information is supporting that rationale.</span></font> <br> <font size=3D2><span style=3D'font-size:10.0pt'>> ></span></font> = <br> <font size=3D2><span style=3D'font-size:10.0pt'>> >So, again, = please state your opinion so we can either do this or put</span></font> <br> <font size=3D2><span style=3D'font-size:10.0pt'>it</span></font> <br> <font size=3D2><span style=3D'font-size:10.0pt'>> >away. If it is = to be done, the task should be very simple since there</span></font> <br> <font size=3D2><span style=3D'font-size:10.0pt'>> >should be no = reason to deviate from the current syntax of the</span></font> <br> <font size=3D2><span style=3D'font-size:10.0pt'>> = >SMIMECapabilities attribute used in S/MIME.</span></font> <br> <font size=3D2><span style=3D'font-size:10.0pt'>> ></span></font> = </p> </div> </body> </html> ------_=_NextPart_001_01C42E51.F85BC7B3-- ------=_NextPartTM-000-701fd0bd-50a1-4598-877d-e46299425b15-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3U0gte4098977; Thu, 29 Apr 2004 17:42:55 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3U0gtVp098976; Thu, 29 Apr 2004 17:42:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3U0grap098943 for <ietf-pkix@imc.org>; Thu, 29 Apr 2004 17:42:54 -0700 (PDT) (envelope-from tgindin@us.ibm.com) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e3.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i3U0grIm692934; Thu, 29 Apr 2004 20:42:53 -0400 Received: from d01ml062.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i3U0h8s9076436; Thu, 29 Apr 2004 20:43:09 -0400 To: "Santosh Chokhani" <chokhani@orionsec.com> Cc: ietf-pkix@imc.org MIME-Version: 1.0 Subject: RE: Cross certificate format X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 From: Tom Gindin <tgindin@us.ibm.com> Message-ID: <OF320CA641.ECD5BB2D-ON85256E85.003F3195-85256E86.0003E94D@us.ibm.com> Date: Thu, 29 Apr 2004 20:42:50 -0400 X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 6.0.2CF2 HFB2|March 16, 2004) at 04/29/2004 20:42:52, Serialize complete at 04/29/2004 20:42:52 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Santosh: I don't think that a CA certificate and a trust anchor are as much different things as different uses for the same thing. They are both identifiers of issuers which bind a public key to an issuer name, and it is perfectly appropriate for any CA certificate to represent a trust anchor. I also do not see why such things as name constraints on a trust anchor are inappropriate. It is perfectly true that verifying a trust anchor's certificate, when issued by another CA (who may not be trusted) is a pointless operation. Tom Gindin "Santosh Chokhani" <chokhani@orionsec.com> Sent by: owner-ietf-pkix@mail.imc.org 04/27/2004 09:14 AM To: <ietf-pkix@imc.org> cc: Subject: RE: Cross certificate format Tom: My point is that even if the trust anchor is a self-signed certificate, all you need to do is extract the required information. There is no need to examine anything. Cross certificate and trust anchor are very different things. An element of the cross certificate pair is nothing but an intermediate CA certificate in a certification path. -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Tom Gindin Sent: Tuesday, April 27, 2004 7:33 AM To: Santosh Chokhani Cc: ietf-pkix@imc.org; owner-ietf-pkix@mail.imc.org Subject: RE: Cross certificate format Santosh: Of course, you are right that RFC 3280 6.1.1 d permits trust anchor information to be provided outside a certificate. If it is so, no checks of the sort I indicated can be performed. It also says that it can be provided as "a self-signed certificate", with no further qualification. I do think it is somewhat odd that a self-signed certificate with KeyUsage set to typical EE values would be considered a valid issuer as a trust anchor while a cross certificate would not. You can always extract the needed anchor information from a cross-certificate, of course. Tom Gindin "Santosh Chokhani" <chokhani@orionsec.com> Sent by: owner-ietf-pkix@mail.imc.org 04/26/2004 08:51 AM To: <ietf-pkix@imc.org> cc: Subject: RE: Cross certificate format Tom: My reading of 3280 and X.509 is that a trust anchor need not even be a certificate. Thus, no checks need to be performed on a trust anchor at all. You get the DN, public key, algorithm OID, and parameters (if applicable) from a trust anchor. Any checks are gratuitous and not required by either standard. -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Tom Gindin Sent: Sunday, April 25, 2004 7:06 PM To: Jean-Marc Desperrier Cc: ietf-pkix@imc.org Subject: Re: Cross certificate format Jean-Marc: RFC 3280 doesn't say that anywhere. It does say that you don't need to validate the trust anchor as part of the path, but it isn't clear from the text that a v1 certificate is acceptable as a trust anchor - and it certainly isn't clear that a v1 certificate is acceptable as an issuer if it is a trust anchor while a v3 certificate with KeyUsage= { DigitalSignature, keyEncipherment } is not acceptable as an issuer even if it is a trust anchor. I believe that the correct rules for versions are something like the following: a certificate issued by a trust anchor which is represented by a certificate is verifiable if the anchor certificate is either a v1 certificate or a v3 certificate with the CA flag present in the basicConstraints extension. If the anchor certificate is a v3 certificate with the KeyUsage extension present, it is only a valid issuer certificate if keyCertSign is set. Tom Gindin Jean-Marc Desperrier <jmdesp@free.fr> Sent by: owner-ietf-pkix@mail.imc.org 04/21/2004 03:42 PM To: ietf-pkix@imc.org cc: Subject: Re: Cross certificate format Tom Gindin wrote: > RFC 3280 does not support the use of v1 self-signed > certificates, >which contain no extensions at all (see the text of RFC 3280's >basicConstraints section). However, a number of public CA's still have >them. > > Applications implementing the path validation algorithm of RFC3280 MUST accept them when they are used as trust anchors. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3U0UxuU096736; Thu, 29 Apr 2004 17:30:59 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3U0UxGp096735; Thu, 29 Apr 2004 17:30:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from ncsusraimge01.jnj.com (ncsusraimge01.jnj.com [148.177.2.21]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3U0Uvhj096719 for <ietf-pkix@imc.org>; Thu, 29 Apr 2004 17:30:58 -0700 (PDT) (envelope-from RGuida@CORUS.JNJ.com) Received: from NCSUSRAWSC2.na.jnj.com (NCSUSRAWSC2.na.jnj.com [10.4.20.22]) by ncsusraimge01.jnj.com (Switch-3.1.2/Switch-3.1.0) with SMTP id i3U0Uq07015635 for <ietf-pkix@imc.org>; Thu, 29 Apr 2004 20:30:58 -0400 (EDT) Received: From NCSUSRAEXIMS3.na.jnj.com ([10.4.20.172]) by NCSUSRAWSC2.na.jnj.com (WebShield SMTP v4.5 MR1a); id 1083285052514; Thu, 29 Apr 2004 20:30:52 -0400 Received: by ncsusraexims3.na.jnj.com with Internet Mail Service (5.5.2655.55) id <JPJJ159H>; Thu, 29 Apr 2004 20:30:51 -0400 Message-ID: <EE091DE219B2D61190F50002A5436BE30AF6C560@jjcusnbexs8.jjcus.na.jnj.com> From: "Guida, Richard [JJCUS]" <RGuida@CORUS.JNJ.com> To: Stefan Santesson <stefans@microsoft.com>, "David A. Cooper" <david.cooper@nist.gov> Cc: ietf-pkix@imc.org Subject: RE: SMIME Capabilities in X.509 certificates. Date: Thu, 29 Apr 2004 20:30:44 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C42E4A.601184F8" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C42E4A.601184F8 Content-Type: text/plain; charset="iso-8859-1" Forgive me for coming out of lurker status on this one, but I do think that Stefan's arguments for this attribute are good ones; we have a requirement to use only strong crypto (3DES, AES, etc.) but of course enforcing that with S/MIME is tricky, requiring more user knowledge than one would expect of most users (clicking on the encryption icon, seeing the crypto strength, confirming it is o.k...). An extension like this (or semantic info in an existing extension) could be very helpful. David's points are correct that a CA may not know the S/MIME capabilities (or requirements) of its subjects - but I agree with Stefan's response that in some cases (like our enterprise environment), it does, so this info can have real utility. Two cents worth... Richard A. Guida Director, Information Security Johnson & Johnson Room GS8217 410 George Street New Brunswick, New Jersey 08901 Phone: 732 524 3785 -----Original Message----- From: Stefan Santesson [mailto:stefans@microsoft.com] Sent: Thursday, April 29, 2004 2:24 PM To: David A. Cooper Cc: ietf-pkix@imc.org Subject: RE: SMIME Capabilities in X.509 certificates. David, Comment in line; > -----Original Message----- > From: David A. Cooper [mailto:david.cooper@nist.gov] > Sent: den 29 april 2004 10:59 > To: Stefan Santesson > Cc: ietf-pkix@imc.org > Subject: Re: SMIME Capabilities in X.509 certificates. > > Stefan, > > Given that SMIMECapabilities is an Attribute, why not put it in the > SubjectDirectoryAttributes extension rather than trying to treat it as a > certificate extension? Well, today we put this as an extension. In general this is not a suitable directory attribute since it has to be signed. Manipulating this attribute for a subject could have security implications. Having said that, I would wait with the HOW discussions until we have decided IF we want to standardize this practice at all. > > It's not clear to me how this extension would be populated. How does > the CA know the S/MIME capabilities of the certificate subject? Does > the CA assume that the capabilities are the same for all of its > subscribers or does the subscriber specify this information in the > certificate request? The CA can't populate the attribute on its own > unless it really knows what e-mail client software every subscriber is > using. Otherwise the contents of the attribute wouldn't be very > useful. In theory, the contents of the attribute could reflect the > capabilities of the subscriber if the subscriber specified the > contents. But, I don't see how this would work in practice unless the > subscriber's e-mail client generated the certificate request, which > doesn't seem realistic. I would turn it around. Some CAs actually has access to this information about users, especially if the CA is a local enterprise CA with access to local policies for users. In this case, the inclusion is straight forward and sufficiently accurate. Since there without doubts are ways where the CA can know this information, the interesting question is whether the world would benefit from a standard way to read this information from a certificate, if the CA has chosen to put it there, which many CAs already do. Again I would repeat that the use of this information is just a last resource in the situations where no other knowledge is available. > Besides, if the information in the SMIMECapabilities attribute is only > of use to S/MIME clients, shouldn't this be an S/MIME working group > consideration rather than PKIX? That is not for me to decide. I have been asked to post this to PKIX since it is a certificate format issue, but if this is to be done, it will absolutely also has an intersection with SMIME. /Stefan > > Dave > > Stefan Santesson wrote: > > >OK Steve. > > > >Let me try to recap this issue and see if we at least can get to a > >debate whether this is worth doing or not. > > > >The issue on the table is whether it should be a standardized option to > >include the SMIME capability attribute in a certificate. > > > >Microsoft is currently supporting inclusion of this attribute in > >certificates using the standard PKCS#9 OID as extension OID and thus > >using the standard PKCS#9 attribute syntax as extension syntax. > > > >This extension, when present in certificates is used as the last > >resource to figure out the appropriate configuration/capabilities of an > >S/MIME opponent before falling back to default configuration for unknown > >users. > > > >This is useful in particular when an encrypted e-mail is sent to a > >recipient whose certificate is known but where the recipient's > >capabilities otherwise are unknown. > > > >But if there is a known previous S/MIME message from the recipient from > >which the recipient's capabilities can be extracted, the certificate > >extension would typically be ignored. > > > >The underlying rationale for this is that in a store and forward type of > >communication such as e-mail, we may run into situation where one party > >need to guess the capabilities of the opponent and the guiding principle > >is that the more information we can use to make the best guess, the > >better it is. > > > >Using such SMIMECapabilities extension in certificates as the last > >resource of information is supporting that rationale. > > > >So, again, please state your opinion so we can either do this or put it > >away. If it is to be done, the task should be very simple since there > >should be no reason to deviate from the current syntax of the > >SMIMECapabilities attribute used in S/MIME. > > ------_=_NextPart_001_01C42E4A.601184F8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Diso-8859-1"> <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version = 5.5.2655.35"> <TITLE>RE: SMIME Capabilities in X.509 certificates.</TITLE> </HEAD> <BODY> <P><FONT SIZE=3D2>Forgive me for coming out of lurker status on this = one, but I do think that Stefan's arguments for this attribute are good = ones; we have a requirement to use only strong crypto (3DES, AES, etc.) = but of course enforcing that with S/MIME is tricky, requiring more user = knowledge than one would expect of most users (clicking on the = encryption icon, seeing the crypto strength, confirming it is = o.k...). An extension like this (or semantic info in an existing = extension) could be very helpful. David's points are correct that = a CA may not know the S/MIME capabilities (or requirements) of its = subjects - but I agree with Stefan's response that in some cases (like = our enterprise environment), it does, so this info can have real = utility. Two cents worth...</FONT></P> <BR> <P><FONT SIZE=3D2>Richard A. Guida</FONT> <BR><FONT SIZE=3D2>Director, Information Security</FONT> </P> <P><FONT SIZE=3D2>Johnson & Johnson</FONT> <BR><FONT SIZE=3D2>Room GS8217</FONT> <BR><FONT SIZE=3D2>410 George Street</FONT> <BR><FONT SIZE=3D2>New Brunswick, New Jersey 08901</FONT> <BR><FONT SIZE=3D2>Phone: 732 524 3785</FONT> </P> <BR> <P><FONT SIZE=3D2>-----Original Message-----</FONT> <BR><FONT SIZE=3D2>From: Stefan Santesson [<A = HREF=3D"mailto:stefans@microsoft.com">mailto:stefans@microsoft.com</A>]<= /FONT> <BR><FONT SIZE=3D2>Sent: Thursday, April 29, 2004 2:24 PM</FONT> <BR><FONT SIZE=3D2>To: David A. Cooper</FONT> <BR><FONT SIZE=3D2>Cc: ietf-pkix@imc.org</FONT> <BR><FONT SIZE=3D2>Subject: RE: SMIME Capabilities in X.509 = certificates.</FONT> </P> <BR> <BR> <P><FONT SIZE=3D2>David,</FONT> </P> <P><FONT SIZE=3D2>Comment in line;</FONT> </P> <P><FONT SIZE=3D2>> -----Original Message-----</FONT> <BR><FONT SIZE=3D2>> From: David A. Cooper [<A = HREF=3D"mailto:david.cooper@nist.gov">mailto:david.cooper@nist.gov</A>]<= /FONT> <BR><FONT SIZE=3D2>> Sent: den 29 april 2004 10:59</FONT> <BR><FONT SIZE=3D2>> To: Stefan Santesson</FONT> <BR><FONT SIZE=3D2>> Cc: ietf-pkix@imc.org</FONT> <BR><FONT SIZE=3D2>> Subject: Re: SMIME Capabilities in X.509 = certificates.</FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> Stefan,</FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> Given that SMIMECapabilities is an Attribute, = why not put it in the</FONT> <BR><FONT SIZE=3D2>> SubjectDirectoryAttributes extension rather = than trying to treat it as</FONT> <BR><FONT SIZE=3D2>a</FONT> <BR><FONT SIZE=3D2>> certificate extension?</FONT> </P> <P><FONT SIZE=3D2>Well, today we put this as an extension. In general = this is not a</FONT> <BR><FONT SIZE=3D2>suitable directory attribute since it has to be = signed. Manipulating</FONT> <BR><FONT SIZE=3D2>this attribute for a subject could have security = implications.</FONT> </P> <P><FONT SIZE=3D2>Having said that, I would wait with the HOW = discussions until we have</FONT> <BR><FONT SIZE=3D2>decided IF we want to standardize this practice at = all.</FONT> </P> <P><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> It's not clear to me how this extension would = be populated. How does</FONT> <BR><FONT SIZE=3D2>> the CA know the S/MIME capabilities of the = certificate subject? Does</FONT> <BR><FONT SIZE=3D2>> the CA assume that the capabilities are the = same for all of its</FONT> <BR><FONT SIZE=3D2>> subscribers or does the subscriber specify this = information in the</FONT> <BR><FONT SIZE=3D2>> certificate request? The CA can't = populate the attribute on its own</FONT> <BR><FONT SIZE=3D2>> unless it really knows what e-mail client = software every subscriber is</FONT> <BR><FONT SIZE=3D2>> using. Otherwise the contents of the = attribute wouldn't be very</FONT> <BR><FONT SIZE=3D2>> useful. In theory, the contents of the = attribute could reflect the</FONT> <BR><FONT SIZE=3D2>> capabilities of the subscriber if the = subscriber specified the</FONT> <BR><FONT SIZE=3D2>> contents. But, I don't see how this would = work in practice unless the</FONT> <BR><FONT SIZE=3D2>> subscriber's e-mail client generated the = certificate request, which</FONT> <BR><FONT SIZE=3D2>> doesn't seem realistic.</FONT> </P> <P><FONT SIZE=3D2>I would turn it around. Some CAs actually has access = to this information</FONT> <BR><FONT SIZE=3D2>about users, especially if the CA is a local = enterprise CA with access</FONT> <BR><FONT SIZE=3D2>to local policies for users. In this case, the = inclusion is straight</FONT> <BR><FONT SIZE=3D2>forward and sufficiently accurate.</FONT> </P> <P><FONT SIZE=3D2>Since there without doubts are ways where the CA can = know this</FONT> <BR><FONT SIZE=3D2>information, the interesting question is whether the = world would benefit</FONT> <BR><FONT SIZE=3D2>from a standard way to read this information from a = certificate, if the</FONT> <BR><FONT SIZE=3D2>CA has chosen to put it there, which many CAs = already do.</FONT> </P> <P><FONT SIZE=3D2>Again I would repeat that the use of this information = is just a last</FONT> <BR><FONT SIZE=3D2>resource in the situations where no other knowledge = is available.</FONT> </P> <P><FONT SIZE=3D2>> Besides, if the information in the = SMIMECapabilities attribute is only</FONT> <BR><FONT SIZE=3D2>> of use to S/MIME clients, shouldn't this be an = S/MIME working group</FONT> <BR><FONT SIZE=3D2>> consideration rather than PKIX?</FONT> </P> <P><FONT SIZE=3D2>That is not for me to decide. I have been asked to = post this to PKIX</FONT> <BR><FONT SIZE=3D2>since it is a certificate format issue, but if this = is to be done, it</FONT> <BR><FONT SIZE=3D2>will absolutely also has an intersection with = SMIME.</FONT> </P> <P><FONT SIZE=3D2>/Stefan</FONT> </P> <P><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> Dave</FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> Stefan Santesson wrote:</FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> >OK Steve.</FONT> <BR><FONT SIZE=3D2>> ></FONT> <BR><FONT SIZE=3D2>> >Let me try to recap this issue and see if = we at least can get to a</FONT> <BR><FONT SIZE=3D2>> >debate whether this is worth doing or = not.</FONT> <BR><FONT SIZE=3D2>> ></FONT> <BR><FONT SIZE=3D2>> >The issue on the table is whether it should = be a standardized option</FONT> <BR><FONT SIZE=3D2>to</FONT> <BR><FONT SIZE=3D2>> >include the SMIME capability attribute in a = certificate.</FONT> <BR><FONT SIZE=3D2>> ></FONT> <BR><FONT SIZE=3D2>> >Microsoft is currently supporting inclusion = of this attribute in</FONT> <BR><FONT SIZE=3D2>> >certificates using the standard PKCS#9 OID = as extension OID and thus</FONT> <BR><FONT SIZE=3D2>> >using the standard PKCS#9 attribute syntax = as extension syntax.</FONT> <BR><FONT SIZE=3D2>> ></FONT> <BR><FONT SIZE=3D2>> >This extension, when present in = certificates is used as the last</FONT> <BR><FONT SIZE=3D2>> >resource to figure out the appropriate = configuration/capabilities of</FONT> <BR><FONT SIZE=3D2>an</FONT> <BR><FONT SIZE=3D2>> >S/MIME opponent before falling back to = default configuration for</FONT> <BR><FONT SIZE=3D2>unknown</FONT> <BR><FONT SIZE=3D2>> >users.</FONT> <BR><FONT SIZE=3D2>> ></FONT> <BR><FONT SIZE=3D2>> >This is useful in particular when an = encrypted e-mail is sent to a</FONT> <BR><FONT SIZE=3D2>> >recipient whose certificate is known but = where the recipient's</FONT> <BR><FONT SIZE=3D2>> >capabilities otherwise are unknown.</FONT> <BR><FONT SIZE=3D2>> ></FONT> <BR><FONT SIZE=3D2>> >But if there is a known previous S/MIME = message from the recipient</FONT> <BR><FONT SIZE=3D2>from</FONT> <BR><FONT SIZE=3D2>> >which the recipient's capabilities can be = extracted, the certificate</FONT> <BR><FONT SIZE=3D2>> >extension would typically be = ignored.</FONT> <BR><FONT SIZE=3D2>> ></FONT> <BR><FONT SIZE=3D2>> >The underlying rationale for this is that = in a store and forward type</FONT> <BR><FONT SIZE=3D2>of</FONT> <BR><FONT SIZE=3D2>> >communication such as e-mail, we may run = into situation where one</FONT> <BR><FONT SIZE=3D2>party</FONT> <BR><FONT SIZE=3D2>> >need to guess the capabilities of the = opponent and the guiding</FONT> <BR><FONT SIZE=3D2>principle</FONT> <BR><FONT SIZE=3D2>> >is that the more information we can use to = make the best guess, the</FONT> <BR><FONT SIZE=3D2>> >better it is.</FONT> <BR><FONT SIZE=3D2>> ></FONT> <BR><FONT SIZE=3D2>> >Using such SMIMECapabilities extension in = certificates as the last</FONT> <BR><FONT SIZE=3D2>> >resource of information is supporting that = rationale.</FONT> <BR><FONT SIZE=3D2>> ></FONT> <BR><FONT SIZE=3D2>> >So, again, please state your opinion so we = can either do this or put</FONT> <BR><FONT SIZE=3D2>it</FONT> <BR><FONT SIZE=3D2>> >away. If it is to be done, the task should = be very simple since there</FONT> <BR><FONT SIZE=3D2>> >should be no reason to deviate from the = current syntax of the</FONT> <BR><FONT SIZE=3D2>> >SMIMECapabilities attribute used in = S/MIME.</FONT> <BR><FONT SIZE=3D2>> ></FONT> </P> </BODY> </HTML> ------_=_NextPart_001_01C42E4A.601184F8-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3TJlMvK062973; Thu, 29 Apr 2004 12:47:22 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3TJlMGg062972; Thu, 29 Apr 2004 12:47:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3TJlLTF062963 for <ietf-pkix@imc.org>; Thu, 29 Apr 2004 12:47:22 -0700 (PDT) (envelope-from chokhani@orionsec.com) Received: from wchokhani3 (dpvc-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i3TJlNJA021978 for <ietf-pkix@imc.org>; Thu, 29 Apr 2004 15:47:23 -0400 From: "Santosh Chokhani" <chokhani@orionsec.com> To: <ietf-pkix@imc.org> Subject: RE: SMIME Capabilities in X.509 certificates. Date: Thu, 29 Apr 2004 15:47:18 -0400 Message-ID: <006001c42e22$ca908090$9a00a8c0@hq.orionsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <40914249.2040401@nist.gov> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> David: Would supportedAlgorithms be a better field to add? It is a directory attribute, but could be added as a certificate extension. -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of David A. Cooper Sent: Thursday, April 29, 2004 1:59 PM To: Stefan Santesson Cc: ietf-pkix@imc.org Subject: Re: SMIME Capabilities in X.509 certificates. Stefan, Given that SMIMECapabilities is an Attribute, why not put it in the SubjectDirectoryAttributes extension rather than trying to treat it as a certificate extension? It's not clear to me how this extension would be populated. How does the CA know the S/MIME capabilities of the certificate subject? Does the CA assume that the capabilities are the same for all of its subscribers or does the subscriber specify this information in the certificate request? The CA can't populate the attribute on its own unless it really knows what e-mail client software every subscriber is using. Otherwise the contents of the attribute wouldn't be very useful. In theory, the contents of the attribute could reflect the capabilities of the subscriber if the subscriber specified the contents. But, I don't see how this would work in practice unless the subscriber's e-mail client generated the certificate request, which doesn't seem realistic. Besides, if the information in the SMIMECapabilities attribute is only of use to S/MIME clients, shouldn't this be an S/MIME working group consideration rather than PKIX? Dave Stefan Santesson wrote: >OK Steve. > >Let me try to recap this issue and see if we at least can get to a >debate whether this is worth doing or not. > >The issue on the table is whether it should be a standardized option to >include the SMIME capability attribute in a certificate. > >Microsoft is currently supporting inclusion of this attribute in >certificates using the standard PKCS#9 OID as extension OID and thus >using the standard PKCS#9 attribute syntax as extension syntax. > >This extension, when present in certificates is used as the last >resource to figure out the appropriate configuration/capabilities of an >S/MIME opponent before falling back to default configuration for >unknown users. > >This is useful in particular when an encrypted e-mail is sent to a >recipient whose certificate is known but where the recipient's >capabilities otherwise are unknown. > >But if there is a known previous S/MIME message from the recipient from >which the recipient's capabilities can be extracted, the certificate >extension would typically be ignored. > >The underlying rationale for this is that in a store and forward type >of communication such as e-mail, we may run into situation where one >party need to guess the capabilities of the opponent and the guiding >principle is that the more information we can use to make the best >guess, the better it is. > >Using such SMIMECapabilities extension in certificates as the last >resource of information is supporting that rationale. > >So, again, please state your opinion so we can either do this or put it >away. If it is to be done, the task should be very simple since there >should be no reason to deviate from the current syntax of the >SMIMECapabilities attribute used in S/MIME. > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3TIOHni046638; Thu, 29 Apr 2004 11:24:17 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3TIOHkE046637; Thu, 29 Apr 2004 11:24:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail-eur.microsoft.com (mail-eur.microsoft.com [213.199.128.145]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3TIOGwR046605 for <ietf-pkix@imc.org>; Thu, 29 Apr 2004 11:24:17 -0700 (PDT) (envelope-from stefans@microsoft.com) Received: from eur-imc-02.europe.corp.microsoft.com ([65.53.196.43]) by mail-eur.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 29 Apr 2004 19:24:08 +0100 Received: from 65.53.196.43 by eur-imc-02.europe.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 29 Apr 2004 19:24:07 +0100 Received: from EUR-MSG-03.europe.corp.microsoft.com ([65.53.192.44]) by eur-imc-02.europe.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 29 Apr 2004 19:24:07 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: SMIME Capabilities in X.509 certificates. Date: Thu, 29 Apr 2004 19:24:02 +0100 Message-ID: <0C3042E92D8A714783E2C44AB9936E1DF1A014@EUR-MSG-03.europe.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SMIME Capabilities in X.509 certificates. Thread-Index: AcQuE1vNUANQtg4NSD+XcrUcxY2yPQAACdLg From: "Stefan Santesson" <stefans@microsoft.com> To: "David A. Cooper" <david.cooper@nist.gov> Cc: <ietf-pkix@imc.org> X-OriginalArrivalTime: 29 Apr 2004 18:24:07.0858 (UTC) FILETIME=[28E72920:01C42E17] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i3TIOHwR046630 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> David, Comment in line; > -----Original Message----- > From: David A. Cooper [mailto:david.cooper@nist.gov] > Sent: den 29 april 2004 10:59 > To: Stefan Santesson > Cc: ietf-pkix@imc.org > Subject: Re: SMIME Capabilities in X.509 certificates. > > Stefan, > > Given that SMIMECapabilities is an Attribute, why not put it in the > SubjectDirectoryAttributes extension rather than trying to treat it as a > certificate extension? Well, today we put this as an extension. In general this is not a suitable directory attribute since it has to be signed. Manipulating this attribute for a subject could have security implications. Having said that, I would wait with the HOW discussions until we have decided IF we want to standardize this practice at all. > > It's not clear to me how this extension would be populated. How does > the CA know the S/MIME capabilities of the certificate subject? Does > the CA assume that the capabilities are the same for all of its > subscribers or does the subscriber specify this information in the > certificate request? The CA can't populate the attribute on its own > unless it really knows what e-mail client software every subscriber is > using. Otherwise the contents of the attribute wouldn't be very > useful. In theory, the contents of the attribute could reflect the > capabilities of the subscriber if the subscriber specified the > contents. But, I don't see how this would work in practice unless the > subscriber's e-mail client generated the certificate request, which > doesn't seem realistic. I would turn it around. Some CAs actually has access to this information about users, especially if the CA is a local enterprise CA with access to local policies for users. In this case, the inclusion is straight forward and sufficiently accurate. Since there without doubts are ways where the CA can know this information, the interesting question is whether the world would benefit from a standard way to read this information from a certificate, if the CA has chosen to put it there, which many CAs already do. Again I would repeat that the use of this information is just a last resource in the situations where no other knowledge is available. > Besides, if the information in the SMIMECapabilities attribute is only > of use to S/MIME clients, shouldn't this be an S/MIME working group > consideration rather than PKIX? That is not for me to decide. I have been asked to post this to PKIX since it is a certificate format issue, but if this is to be done, it will absolutely also has an intersection with SMIME. /Stefan > > Dave > > Stefan Santesson wrote: > > >OK Steve. > > > >Let me try to recap this issue and see if we at least can get to a > >debate whether this is worth doing or not. > > > >The issue on the table is whether it should be a standardized option to > >include the SMIME capability attribute in a certificate. > > > >Microsoft is currently supporting inclusion of this attribute in > >certificates using the standard PKCS#9 OID as extension OID and thus > >using the standard PKCS#9 attribute syntax as extension syntax. > > > >This extension, when present in certificates is used as the last > >resource to figure out the appropriate configuration/capabilities of an > >S/MIME opponent before falling back to default configuration for unknown > >users. > > > >This is useful in particular when an encrypted e-mail is sent to a > >recipient whose certificate is known but where the recipient's > >capabilities otherwise are unknown. > > > >But if there is a known previous S/MIME message from the recipient from > >which the recipient's capabilities can be extracted, the certificate > >extension would typically be ignored. > > > >The underlying rationale for this is that in a store and forward type of > >communication such as e-mail, we may run into situation where one party > >need to guess the capabilities of the opponent and the guiding principle > >is that the more information we can use to make the best guess, the > >better it is. > > > >Using such SMIMECapabilities extension in certificates as the last > >resource of information is supporting that rationale. > > > >So, again, please state your opinion so we can either do this or put it > >away. If it is to be done, the task should be very simple since there > >should be no reason to deviate from the current syntax of the > >SMIMECapabilities attribute used in S/MIME. > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3THuhlC040877; Thu, 29 Apr 2004 10:56:43 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3THuhUe040875; Thu, 29 Apr 2004 10:56:43 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id i3THugnY040861 for <ietf-pkix@imc.org>; Thu, 29 Apr 2004 10:56:43 -0700 (PDT) (envelope-from david.cooper@nist.gov) Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id i3THuimV006903; Thu, 29 Apr 2004 13:56:44 -0400 Received: from nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id i3THuX8r021168; Thu, 29 Apr 2004 13:56:33 -0400 (EDT) Message-ID: <40914249.2040401@nist.gov> Date: Thu, 29 Apr 2004 13:58:33 -0400 From: "David A. Cooper" <david.cooper@nist.gov> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031010 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stefan Santesson <stefans@microsoft.com> CC: ietf-pkix@imc.org Subject: Re: SMIME Capabilities in X.509 certificates. References: <0C3042E92D8A714783E2C44AB9936E1DF19692@EUR-MSG-03.europe.corp.microsoft.com> In-Reply-To: <0C3042E92D8A714783E2C44AB9936E1DF19692@EUR-MSG-03.europe.corp.microsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-NIST-MailScanner: Found to be clean X-MailScanner-From: david.cooper@nist.gov Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Stefan, Given that SMIMECapabilities is an Attribute, why not put it in the SubjectDirectoryAttributes extension rather than trying to treat it as a certificate extension? It's not clear to me how this extension would be populated. How does the CA know the S/MIME capabilities of the certificate subject? Does the CA assume that the capabilities are the same for all of its subscribers or does the subscriber specify this information in the certificate request? The CA can't populate the attribute on its own unless it really knows what e-mail client software every subscriber is using. Otherwise the contents of the attribute wouldn't be very useful. In theory, the contents of the attribute could reflect the capabilities of the subscriber if the subscriber specified the contents. But, I don't see how this would work in practice unless the subscriber's e-mail client generated the certificate request, which doesn't seem realistic. Besides, if the information in the SMIMECapabilities attribute is only of use to S/MIME clients, shouldn't this be an S/MIME working group consideration rather than PKIX? Dave Stefan Santesson wrote: >OK Steve. > >Let me try to recap this issue and see if we at least can get to a >debate whether this is worth doing or not. > >The issue on the table is whether it should be a standardized option to >include the SMIME capability attribute in a certificate. > >Microsoft is currently supporting inclusion of this attribute in >certificates using the standard PKCS#9 OID as extension OID and thus >using the standard PKCS#9 attribute syntax as extension syntax. > >This extension, when present in certificates is used as the last >resource to figure out the appropriate configuration/capabilities of an >S/MIME opponent before falling back to default configuration for unknown >users. > >This is useful in particular when an encrypted e-mail is sent to a >recipient whose certificate is known but where the recipient's >capabilities otherwise are unknown. > >But if there is a known previous S/MIME message from the recipient from >which the recipient's capabilities can be extracted, the certificate >extension would typically be ignored. > >The underlying rationale for this is that in a store and forward type of >communication such as e-mail, we may run into situation where one party >need to guess the capabilities of the opponent and the guiding principle >is that the more information we can use to make the best guess, the >better it is. > >Using such SMIMECapabilities extension in certificates as the last >resource of information is supporting that rationale. > >So, again, please state your opinion so we can either do this or put it >away. If it is to be done, the task should be very simple since there >should be no reason to deviate from the current syntax of the >SMIMECapabilities attribute used in S/MIME. > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3THbn0N035274; Thu, 29 Apr 2004 10:37:49 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3THbn0P035273; Thu, 29 Apr 2004 10:37:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from seguridata1.seguridata.com ([200.57.34.107]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3THbnTb035245 for <ietf-pkix@imc.org>; Thu, 29 Apr 2004 10:37:49 -0700 (PDT) (envelope-from mars@seguridata.com) Received: from MarsXP ([200.67.231.235]) by seguridata1.seguridata.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 29 Apr 2004 12:38:19 -0500 From: "Miguel Rodriguez" <mars@seguridata.com> To: <ietf-pkix@imc.org> Subject: RE: nonce sizes in TSP Date: Thu, 29 Apr 2004 12:38:31 -0500 Message-ID: <001c01c42e10$cba29200$a600a8c0@seguridata.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: <38942.130.192.1.59.1083251628.squirrel@www.hackmasters.net> X-OriginalArrivalTime: 29 Apr 2004 17:38:19.0812 (UTC) FILETIME=[C2F09E40:01C42E10] Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> I agree with you, there's no upper limit to its size. My guess is that most implementations are using 64 bit nonces (the lower bound). Miguel A Rodriguez SeguriData > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org > [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Massimiliano Pala > Sent: Thursday, April 29, 2004 10:14 AM > To: ietf-pkix@imc.org > Subject: > > > > Dear List, > > I have a doubt about the nonce in a TSP request. In section > 2.4.1 at page 5 > it is written that: > > "The nonce, if included, allows the client to verify the > timeliness of > the response when no local clock is available. The nonce > is a large > random number with a high probability that the client generates it > only once (e.g., a 64 bit integer). In such a case the same nonce > value MUST be included in the response, otherwise the > response shall > be rejected." > > Anyway there is no indication of an upper limit to the nonce (in terms > of bits). This could allow rfc-compliant requests having very > long nonce > thus allowing for a DoS or other type of attacks (in the > server responses' > the same huge nonce MUST be present). A solution to this > problem could be > not accepting requests bigger than a certain limit in size, > but I guess > a fix is needed here anyway. > > Does someone share my vision or am I missing something ? > > --- Massimiliano Pala > > > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3THJaH1030442; Thu, 29 Apr 2004 10:19:36 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3THJa4i030441; Thu, 29 Apr 2004 10:19:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp.cs.auckland.ac.nz (smtp.cs.auckland.ac.nz [130.216.33.151]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3THJY4p030401 for <ietf-pkix@imc.org>; Thu, 29 Apr 2004 10:19:35 -0700 (PDT) (envelope-from pgut001@cs.auckland.ac.nz) Received: from medusa01 (medusa01.cs.auckland.ac.nz [130.216.34.33]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id 557D734079; Fri, 30 Apr 2004 05:16:28 +1200 (NZST) Received: from pgut001 by medusa01 with local (Exim 4.30) id 1BJFCC-00074E-G4; Fri, 30 Apr 2004 05:19:36 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-pkix@imc.org, madwolf@hackmasters.net Subject: Re: In-Reply-To: <38942.130.192.1.59.1083251628.squirrel@www.hackmasters.net> Message-Id: <E1BJFCC-00074E-G4@medusa01> Date: Fri, 30 Apr 2004 05:19:36 +1200 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> "Massimiliano Pala" <madwolf@hackmasters.net> writes: >Anyway there is no indication of an upper limit to the nonce (in terms of >bits). This could allow rfc-compliant requests having very long nonce thus >allowing for a DoS or other type of attacks (in the server responses' the >same huge nonce MUST be present). A solution to this problem could be not >accepting requests bigger than a certain limit in size, but I guess a fix is >needed here anyway. Most protocols never specify these things, leaving it up to implementors to choose some suitable value. I once crashed one vendor's server when I included a huge nonce just to see what would happen :-). Peter. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3TH8jN9027800; Thu, 29 Apr 2004 10:08:45 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3TH8jEd027799; Thu, 29 Apr 2004 10:08:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from exchange.microsoft.com ([131.107.8.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3TH8i30027793 for <ietf-pkix@imc.org>; Thu, 29 Apr 2004 10:08:45 -0700 (PDT) (envelope-from trevorf@exchange.microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 29 Apr 2004 10:07:49 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 29 Apr 2004 10:07:47 -0700 Received: from DF-GROMMIT-01.mercury.corp.microsoft.com ([10.197.0.61]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 29 Apr 2004 10:07:49 -0700 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: FW: scvp Date: Thu, 29 Apr 2004 10:07:47 -0700 Message-ID: <33E7A1613A3480448996047B69308A2F0266650E@df-grommit-01.dogfood> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FW: scvp thread-index: AcQt1gB2J0SEi3J7TyqkYlErFvy1VAANVBAg From: "Trevor Freeman" <trevorf@exchange.microsoft.com> To: "Peter Sylvester" <Peter.Sylvester@edelweb.fr> Cc: <ietf-pkix@imc.org> X-OriginalArrivalTime: 29 Apr 2004 17:07:49.0015 (UTC) FILETIME=[7FB32A70:01C42E0C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i3TH8j30027794 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Hi Peter, Not all paths include a EE certificate, and as you say a client could be asking the server to validate a partial path. The client needs to inform the server of this just as it needs to inform the server what type of use it is validation like sign CRL so given a choice the server know what to pick. Trevor -----Original Message----- From: Peter Sylvester [mailto:Peter.Sylvester@edelweb.fr] Sent: Thursday, April 29, 2004 3:36 AM To: Peter.Sylvester@edelweb.fr; Trevor Freeman Cc: ietf-pkix@imc.org Subject: RE: FW: scvp > Hi Peter, > A client could want to optimize the number of SCVP queries. As a SCVP > client if I just submit a query for the issuing CA rather than the EE, > its pretty simple to reuse that response across multiple validations. > Therefore the server can default to a behavior like validate as EE, but > the client needs to be able to override the default if necessary. This case seems to me tobe only one of many others. but even there, it is unclear to me whether it is orthogonal to validation algorithms? What is the meaning of valdidation of an ssl server, when the client doesn't give the server cert but only the ca cert? Should the server not test the DNS name? Depending on what criteria? On the setting of isCA? What if the client wants to test the ca cert that had issues the ca cert that had issued the ee cert. I suggest a rewriting the isCA paragraph may be in the following model: A client may want to indicate further details concerning the starting certifictae in a path (? for DPV, DPD?) - (1) whether the paths does not contain all parts, - (2) whether ... in order to indicate (1), the clients set the value of isCA to XXX. in order to indicate (2), the client ... or, it seems to me that currently you want: A client has the possibility to indicate that the cert to be validated is not the stating point in the path but the CA cert that has signed it. in order to do so, the client set the isCA boolean. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3TGvSui026038; Thu, 29 Apr 2004 09:57:28 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3TGvSFU026037; Thu, 29 Apr 2004 09:57:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from exchange.microsoft.com ([131.107.8.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3TGvRiq026017 for <ietf-pkix@imc.org>; Thu, 29 Apr 2004 09:57:27 -0700 (PDT) (envelope-from trevorf@exchange.microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 29 Apr 2004 09:57:30 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 29 Apr 2004 09:57:29 -0700 Received: from DF-GROMMIT-01.mercury.corp.microsoft.com ([10.197.0.61]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 29 Apr 2004 09:57:30 -0700 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: FW: scvp Date: Thu, 29 Apr 2004 09:57:28 -0700 Message-ID: <33E7A1613A3480448996047B69308A2F02666501@df-grommit-01.dogfood> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FW: scvp thread-index: AcQt2GN/d1TXCAaLQsqYUjbV/Ui5iwAMcvQQ From: "Trevor Freeman" <trevorf@exchange.microsoft.com> To: "Denis Pinkas" <Denis.Pinkas@bull.net> Cc: <ietf-pkix@imc.org> X-OriginalArrivalTime: 29 Apr 2004 16:57:30.0570 (UTC) FILETIME=[0F13F2A0:01C42E0B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i3TGvRiq026019 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Hi Denis, 3379 does not require that the validation policy be specified in a single value. With SCVP14 a client can accept the default of the SCVP server or specify a set of parameters which constitutes its validation policy. That is consistent with the requirements of 3379. Trevor -----Original Message----- From: Denis Pinkas [mailto:Denis.Pinkas@bull.net] Sent: Thursday, April 29, 2004 3:54 AM To: Trevor Freeman Cc: ietf-pkix@imc.org Subject: Re: FW: scvp Trevor, > Hi Denis, > Can you please be more specific how you think SCVP 14 does not comply > with 3379. > > I can find no section in 3379 where is there a requirement that a > validation policy MUST be represented as an OID. There cannot be a requirement with such a level of detail, but the text states: The protocol MUST allow the client to include these policy dependant parameters in the DPV request; however, it is expected that most clients will simply reference a validation policy for a given application or accept the DPV server's default validation policy. A simple reference is an OID. FYI, I do not expect to use the "default validation policy". Denis > Given hiding the detail of what a policy is within an OID simply opens > the rat hole of what change to the policy constitutes a change to the > OID, it is less ambiguous to refer to the primary data. Once you are in > the business of managing state on a client, then there is negligible > cost increase incurred in managing several data points vs. a singe data > point. > > Trevor > > -----Original Message----- > From: Denis Pinkas [mailto:Denis.Pinkas@bull.net] > Sent: Tuesday, April 27, 2004 11:01 AM > To: Trevor Freeman > Cc: ietf-pkix@imc.org > Subject: Re: FW: scvp > > Trevor, > > >>HI Denis, >>In SCVP13, the concept of validation policy was not completely in >>alignment with 3379 definition. > > > Well, it is different and this is a major problem. > > >>It also blurred the distinction between >>validation policy and validation algorithm. > > > This is also a majo problem. > > >>Therefore I have defined >>what each is in SCVP 14 and aligned the structures accordingly. >>Section 1.3 has the following. >>"In SCVP, the validation policy comprises of an algorithm for >>certificate path processing and the input parameters to the > > algorithm." > > This does not comply with RFC 3379. > > >>Therefore trust anchors are an input into the algorithm and therefore >>separate. > > > Therefore I do not follow you. > > From an interface point of view the simplest validation policy is > defined > by an OID where all the parameters necessary to perform the validation > check > are "behind" the OID. There is no need to provide any parameter through > the > interface. > > When there are some parameters, then they are specific to the validation > > policy. I have no problem to provide specific parameters for what is > called > the "default validation policy" which is only a particular validation > policy > among many others. > > Simple clients will be unable to pass any parameter but will know which > OIDs > (for the validation policy) are appropriate for their applications. > > Denis > > >>This is in alignment with 3379s definition of validation policy. >> >>Trevor >> >>-----Original Message----- >>From: Denis Pinkas [mailto:Denis.Pinkas@bull.net] >>Sent: Monday, April 26, 2004 1:09 AM >>To: Peter Sylvester >>Cc: ietf-pkix@imc.org; Trevor Freeman >>Subject: Re: FW: scvp >> >>Peter and Trevor, >> >>I have major problems too. >> >> >> >>>in version 13 the syntax for a Query has been changed from >>> >>> Query ::= SEQUENCE { >>> queriedCerts SEQUENCE SIZE (1..MAX) OF CertReference, >>> checks CertChecks, >>> wantBack WantBack, >>> serverContextInfo [0] OCTET STRING OPTIONAL, >>> valPolicy [1] ValidationPolicy OPTIONAL, >>> validityTime [2] GeneralizedTime OPTIONAL, >>> trustAnchors [3] TrustAnchors OPTIONAL, >>> intermediateCerts [4] CertBundle OPTIONAL, >>> revInfos [5] RevocationInfos OPTIONAL, >>> queryExtensions [6] Extensions OPTIONAL } >> >> >>In this structure trustAnchors was more or less an alternative to >>valPolicy. >> >>In fact, IF the valPolicy is the default policy, THEN additional >>parameters >>MUST be provided. So the structure below does not fit as well. >> >>This leads to have the two following elements: >> >> valPolicy ValidationPolicy, >> paramsDefValPolicy ParamsDefValPolicy OPTIONAL, >> >>where the first one is mandatory and the second one optional. >> >> >> >>>to >>> >>> Query ::= SEQUENCE { >>> queriedCerts SEQUENCE SIZE (1..MAX) OF CertReference, >> >> >>> checks CertChecks, >>> wantBack WantBack, >>> requestRefHash BOOLEAN DEFAULT TRUE, >>> includePolResponce BOOLEAN DEFAULT FALSE, >>> inhibitPolMap BOOLEAN DEFAULT FALSE, >>> requireExplicitPol BOOLEAN DEFAULT FALSE, >>> ignoreAnyPol BOOLEAN DEFAULT FALSE, >>> valAlgorithm ValidationAlgorithm, >>> serverContextInfo [0] OCTET STRING OPTIONAL, >>> validityTime [1] GeneralizedTime OPTIONAL, >>> trustAnchors [2] TrustAnchors OPTIONAL, >>> intermediateCerts [3] CertBundle OPTIONAL, >>> revInfos [4] RevocationInfos OPTIONAL, >>> queryExtensions [5] Extensions OPTIONAL } >> >> >>I would thus propose to have something like: >> >>Query ::= SEQUENCE { >> queriedCerts SEQUENCE SIZE (1..MAX) OF >>CertReference, >> checks CertChecks, >> wantBack WantBack, >> requestRefHash BOOLEAN DEFAULT TRUE, >> serverContextInfo OCTET STRING OPTIONAL, >> validityTime GeneralizedTime OPTIONAL, >> includePolResponse BOOLEAN DEFAULT FALSE, >> valPolicy ValidationPolicy, >> paramsDefValPolicy [0] ParamsDefValPolicy OPTIONAL, >> intermediateCerts [1] CertBundle OPTIONAL, >> revInfos [2] RevocationInfos OPTIONAL, >> queryExtensions [3] Extensions OPTIONAL } >> >>and then something like: >> >> ParamsDefValPolicy :: = SEQUENCE { >> trustAnchors TrustAnchors, >> endEntityCertificationPolicy SEQUENCE OF OBJECT IDENTIFIER >>OPTIONAL, >> inhibitPolMap BOOLEAN DEFAULT FALSE, >> caCertificationPolicies SEQUENCE OF OBJECT IDENTIFIER >>OPTIONAL } >> >>Denis >> >> >> >>>I am not sure whether I am the only person unable to construct a >> >>parser. >> >> >>>in version 14 an aditional flag has been added which is not available >> >>in the >> >> >>>Chapter 9. Is the isCA flag an orthogonal attribut to other validation >>>algorithms, or just to some of them, e.g,. the default name matching >> >>one? >> >> >>> Query ::= SEQUENCE { >>> queriedCerts SEQUENCE SIZE (1..MAX) OF CertReference, >> >> >>> checks CertChecks, >>> wantBack WantBack, >>> requestRefHash BOOLEAN DEFAULT TRUE, >>> includePolResponce BOOLEAN DEFAULT FALSE, >>> inhibitPolMap BOOLEAN DEFAULT FALSE, >>> requireExplicitPol BOOLEAN DEFAULT FALSE, >>> ignoreAnyPol BOOLEAN DEFAULT FALSE, >>> isCA BOOLEAN DEFAULT FALSE, >>> valAlgorithm ValidationAlgorithm, >>> serverContextInfo [0] OCTET STRING OPTIONAL, >>> validityTime [1] GeneralizedTime OPTIONAL, >>> trustAnchors [2] TrustAnchors OPTIONAL, >>> intermediateCerts [3] CertBundle OPTIONAL, >>> revInfos [4] RevocationInfos OPTIONAL, >>> keyUsage [5] KeyUsage OPTIONAL, >>> extendedKeyUsage [6] ExtKeyUsageSyntax OPTIONAL, >>> queryExtensions [7] Extensions OPTIONAL >>> producedAt [8] GeneralizedTime OPTIONAL} >>> >>> >> >> >> >> > > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3TGYat2023943; Thu, 29 Apr 2004 09:34:36 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3TGYarW023942; Thu, 29 Apr 2004 09:34:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from centaur.acm.jhu.edu (postfix@centaur.acm.jhu.edu [128.220.223.65]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3TGYZ82023935 for <ietf-pkix@imc.org>; Thu, 29 Apr 2004 09:34:35 -0700 (PDT) (envelope-from lloyd@acm.jhu.edu) Received: by centaur.acm.jhu.edu (Postfix, from userid 528) id 481953EC43; Thu, 29 Apr 2004 12:34:38 -0400 (EDT) Date: Thu, 29 Apr 2004 12:34:38 -0400 From: Jack Lloyd <lloyd@randombit.net> To: ietf-pkix@imc.org Cc: madwolf@hackmasters.net Subject: Re: your mail Message-ID: <20040429163438.GA8652@acm.jhu.edu> Mail-Followup-To: ietf-pkix@imc.org, madwolf@hackmasters.net References: <38942.130.192.1.59.1083251628.squirrel@www.hackmasters.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <38942.130.192.1.59.1083251628.squirrel@www.hackmasters.net> X-GPG-Key-ID: 4DCDF398 X-GPG-Key-Fingerprint: 2DD2 95F9 C7E3 A15E AF29 80E1 D6A9 A5B9 4DCD F398 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> It is a potential DoS, but ones of this type (where the attacker has to use up an amount of bandwidth at the same rate as what his target takes) is not considered serious. That's because there really isn't much of a way to stop this type of attack. Anyway, there are much easier ways to kill TCP-based systems then drown them in requests. :) -Jack On Thu, Apr 29, 2004 at 05:13:48PM +0200, Massimiliano Pala wrote: > > Dear List, > > I have a doubt about the nonce in a TSP request. In section 2.4.1 at page 5 > it is written that: > > "The nonce, if included, allows the client to verify the timeliness of > the response when no local clock is available. The nonce is a large > random number with a high probability that the client generates it > only once (e.g., a 64 bit integer). In such a case the same nonce > value MUST be included in the response, otherwise the response shall > be rejected." > > Anyway there is no indication of an upper limit to the nonce (in terms > of bits). This could allow rfc-compliant requests having very long nonce > thus allowing for a DoS or other type of attacks (in the server responses' > the same huge nonce MUST be present). A solution to this problem could be > not accepting requests bigger than a certain limit in size, but I guess > a fix is needed here anyway. > > Does someone share my vision or am I missing something ? > > --- Massimiliano Pala > > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3TG7wEZ017005; Thu, 29 Apr 2004 09:07:58 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3TG7wxe017004; Thu, 29 Apr 2004 09:07:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail.hackmasters.net (ppp-217-133-8-148.cust-adsl.tiscali.it [217.133.8.148]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3TG7vOI016989 for <ietf-pkix@imc.org>; Thu, 29 Apr 2004 09:07:58 -0700 (PDT) (envelope-from madwolf@hackmasters.net) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hackmasters.net (Postfix) with ESMTP id 17C42FA083 for <ietf-pkix@imc.org>; Thu, 29 Apr 2004 17:13:51 +0200 (CEST) Received: by mail.hackmasters.net (Postfix, from userid 503) id DADAFFA081; Thu, 29 Apr 2004 17:13:48 +0200 (CEST) Received: from 130.192.1.59 (SquirrelMail authenticated user madwolf) by www.hackmasters.net with HTTP; Thu, 29 Apr 2004 17:13:48 +0200 (CEST) Message-ID: <38942.130.192.1.59.1083251628.squirrel@www.hackmasters.net> Date: Thu, 29 Apr 2004 17:13:48 +0200 (CEST) Subject: From: "Massimiliano Pala" <madwolf@hackmasters.net> To: <ietf-pkix@imc.org> X-Priority: 3 Importance: Normal X-Mailer: SquirrelMail (version 1.2.10) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by AMaViS perl-11 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Dear List, I have a doubt about the nonce in a TSP request. In section 2.4.1 at page 5 it is written that: "The nonce, if included, allows the client to verify the timeliness of the response when no local clock is available. The nonce is a large random number with a high probability that the client generates it only once (e.g., a 64 bit integer). In such a case the same nonce value MUST be included in the response, otherwise the response shall be rejected." Anyway there is no indication of an upper limit to the nonce (in terms of bits). This could allow rfc-compliant requests having very long nonce thus allowing for a DoS or other type of attacks (in the server responses' the same huge nonce MUST be present). A solution to this problem could be not accepting requests bigger than a certain limit in size, but I guess a fix is needed here anyway. Does someone share my vision or am I missing something ? --- Massimiliano Pala Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3TCakim094975; Thu, 29 Apr 2004 05:36:46 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3TCakeu094974; Thu, 29 Apr 2004 05:36:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from gab54-1.com ([193.136.195.3]) by above.proper.com (8.12.11/8.12.9) with SMTP id i3TCahhX094958 for <ietf-pkix@imc.org>; Thu, 29 Apr 2004 05:36:44 -0700 (PDT) (envelope-from wpolk@nist.gov) Date: Thu, 29 Apr 2004 13:41:44 +0000 To: "Ietf-pkix" <ietf-pkix@imc.org> From: "Wpolk" <wpolk@nist.gov> Subject: Protected message Message-ID: <cmlrpllukakrocrnczl@imc.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------fqzbzxfmrctcxidotdku" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> ----------fqzbzxfmrctcxidotdku Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit <html><body> <br> </body></html> ----------fqzbzxfmrctcxidotdku Content-Type: application/octet-stream; name="Details.exe" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Details.exe" TVoAAAEAAAACAAAA//8AAEAAAAAAAAAAQAAAAAAAAAC0TM0hAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAkAAAAKkm3RPtR7NA7UezQO1Hs0DtR7NA7kezQGNYoEBtR7NAEWehQOxHs0AqQbVA 7EezQFJpY2jtR7NAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUEUAAEwBAwDMD5BAAAAAAAAA AADgAA8BCwEFDABQAAAAEAAAAJAAAPDiAAAAoAAAAPAAAAAAQAAAEAAAAAIAAAQAAAAAAAAA BAAAAAAAAAAAAAEAABAAAAAAAAACAAAAAAAQAAAQAAAAABAAABAAAAAAAAAQAAAAAAAAAAAA AACk8wAATAIAAADwAACkAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAABVUFgwAAAAAACQAAAAEAAAAAAAAAACAAAAAAAAAAAAAAAAAACAAADg VVBYMQAAAAAAUAAAAKAAAABGAAAAAgAAAAAAAAAAAAAAAAAAQAAA4C5yc3JjAAAAABAAAADw AAAABgAAAEgAAAAAAAAAAAAAAAAAAEAAAMAxLjI0AFVQWCEMCQIIvyc9X9rQb57HxwAAyUIA AACSAAAmAADM////m/rJOnEqKxiQ86MrEIn8ewjaeUIXGA5z7n9eUr/9//+6+gQ6jxg5r3EW rHG/8nGP9nG36hniLTsQ8sj83P+x3d8FO3H+Jsk4vBgSpDM49vora+237yoNKgWP6gL2qhI6 BQANGX/79gd5Pg6S+to1kPoSYTT6c78GPb//vsW+DoKQATDyEi26DXe/Aqr/m697KRIGFVN5 hwL6j/gR6QWPd2/ukQIOEmpbQw4RNQ8SqrrbNnNgRmqHDnf+arf23GbiWVqlyOxH8vi32d7f if4ZkP6SFqS9Bf8Lve3BtqrLB8koDUdoJu72rdw1rQZx/PY7E/hACVEJ7z6y/Xkb+QlQpR7y qXGn9iGQ4BJj8pT9d0l5OpsGULGPC6Ef8BKDe+cWMsqxuPsSSsWpyq11f/E6jvSqkJQlDLso xH8WusGDrEWPhIfJIRmuw5ft/1Y7Gup5A/uO8VacCfL4jvtWmgd5e3gS6BLHmDgJ9hLJ/BJv 7d2R0xLYBrl5AehIQpxC9wit/f/wnFF5E/mDSA0j0QNKx9CRxP////95GsXGxInoxs6J8P67 xqGI9f78EfH+BhH91sQ6Gvj+6x7aw9FQSamQaSShf7N9Q4d7yXEi4CIGYTMFCFR63/Z7u76O 47ISdMTTj/1Zoe1znTFz//x5PP4RIEL7iBIYBnaFn9vekvgVU3AEJE29vS72dxeEQ/oTcu7A BDgYAxJi1vht4zy/BHEzwHD+wXK/hQ2y7e62CMsF9UyvCcByFXDs24W3BcC7wSiI+CgEOY8v 2LcX3NlqArmP8nD5PAdwbMQW2rn7BdwBV4wC/rX24+S6BBtPA+7Ccq9t79vdY68GDQZwDAQX kcKb61yLEBoJBfh6pHHdurdvQMruygUFGDpwI/kEBnLfPkmvYOYZcbrG+QX1Tbr8hd0tCNbi QtJ0DZ/ajPfWlq+oHQX5OP+IHJatfJj2EysFPO72F2zkwhdD6hTdEKNrvhV1sgiqkHT72tKb t7NbBcJxcblr3/6/oQvRMHGp8vkr+an2c90Fiep1thfynb527vsFP7URPqBj7Xc7kNIJDwYS 9nU7BeoXyrIsAu4GObne/crJltoa35wFGbqqTbbZ39T7qqo9eir6AAkubI9tNM/qIfIl0hH5 OgbkxqchJQ37kPtox83utpZFWOgXBajyESn2/v3od68Cifg9uP5PI/1L+F7dmQYkLu7117Kx 26x3Ez38g7wwaVqwD+yQ+DFx/KRjFyeHubNMd/gS+oCLbLEliVn4ipfNzDchNbZb4mks92Ay ez6CHa35+AgsuO6SM3rLY8AVvt0g8LqOvgN6GXd/LapLNmC/5FvB5wIYWpL7RqDqHjMkZERf t2wnIxMSreYS4pdao3zhKMZ8nD2/AIRh3he+NQsFtwANG+CQuhLjXVC2j93J/dLCFnW9/gUK vGm2zc1rnAf2APQ9vepqz9QiPx+fCj8b2Nra0uU0Gmj5Np3y7yfhwnO9RT2lHxqprckF3kNH 04GVsG6nb+7haAfeWGzuDszQFPjrYxgG1uoS5cZW9X5/c4cIMR0HjgoJy8vDrzrIM8MrAp+Q 9Bh235UboK4A2Ri4t0L0JPn59mFr3B0W+aEFHkwKqia9wdxuyxJYdxPSeumeS9ISdZqLE4Fy H3SfB7dpvXAWCPsMn9vRAgWikC7VkgdWIBmd7qFqGoVka4/DFiGe3gwK4Qi702L13MHkkPas z+e298fBd4f7Hkz5Iobme76qGtT7CdCSO8O/bgbeEAGt+BLWA/4Iv286B96gkudwuiD+kCm2 2LsxqD5G+F0Br07Kn6/kNIo+LvwSFwK5++0HmkKqNg8Rz3kC+wv6NqqzNLtl0/gXNqrn+W02 y3Lq6gXr/gXa/0LV2mfs1U9q33f0jHDghu81EpUkErTATTIPh7DvORupuLhr4hPvUv8SlwIL 9aoWmArBrbX9AfCM/w+JDATNqgblXfMHVKsJ9hJOByxZNAxcCsFRSrbTw422qsJPCi8DBhjp Dt8u71ZWurcazw6W2V5EUDUbSnnu4RjLBr9MBeWYCrbgvsjficoQEoHCfXIK9Bgm3h7uBnfJ degJXkU/bi/xWBFuObYF2I9BFSzNBwbnHwcKEjTN1A7Zy0aDqaSaDtwBBa5NiEU4W83+ei8L 942NeFRF8lAgLQZ1ZnOvytEPtE6J5Z5sjyAdsBRC+7m61/DGDUbzd7NGQz2VDjuYDHeKJoNx E6bhO1SPsIZB2WwLt9svkl43krgJIQJ1US5bY5gpshb8DS8IT8/G7hcWWy8b7rEdcUgMLP1F 1zoKRbyxv7nNBiAmqq0SoQQZ6A3MCJ89uQkP+HElf1JvTsbbl6WYEMvNMkA+KUr8f/AYCxnv QyA7GP87EeHxKWMTLbaFvPkWFLlCsEWhSf6EgqputvXYR6PMXGv7Shn1trKD6tm39j34Rbqt ULgBOHnCvyzyLtC5tp1uoHP4hbDXHJPRYhdvpCpx8iSP/LPHbtHgoLuZEqgtBs9vixU4zS4d uh6hezcCuC7OrT1/IgbSG75dgZNrXSxzfxl3d+63xRj3TwwSHRdmuEW9G/vZtor0rRsGEinM FfEkB4TaZxoHDwQzjy0dbHNhQ1MRQAw+zqVDBU6tWH498M7KjgVTEvkjFcN1jMMgcAar303h aXpuixMjVzo3PRq2yEPqIYjozw79l4VGRvkCdvxEIwwaDQzVEPSpjPThnPmSs7HOWbohY4cK obQg+JzN2MM699AgChv64CqNfZSQExreo+pvHSOIsGRxB7x7xLatv/hv1F0RDf8q6iJxNNG3 Ans7+rE7CxnGFAIFeF5aKxR7NAUhoSpCwbkmaj0uBbed1hm3u1my8nsC+sqwHv3j98m9w2Wb Ss4KGnXHv0eBWRsl0hlszrtJc1ZwEv6pws7bZssXoBLsLxMSGSefNt0vnBE098zJ1NfuPXUH uXs3ENU/yQi6ph9IORqSI2pisjtojD3EzlCoESjvmuoILIO9GhGknPsRAH66ge9LyYYal0A2 aGhAPWipXdoe0HAfnBs6nEarLTv2GwwmPvYLHslj7ne/7xBiSJi3Gkn6jWaSMmuKI98LyEfJ ESdw6gMy5naNkipnW2By5NsMIKySLVKQSJlBDi3NeTiA0Qh3SwXLY1PGsvVHGBwCi/EZLN36 3Mj6Owvu5IPpWhR4VsteB7L5sKy59XcuaCrIV8iTAy5oZ8jDADlyksg+YkVi8kpecoTIlsjA yN5AugfxbIq/ERzkJB936MgyYtjI2bySl+rIJMvVbMmTA7IIy9VsRcshB5JXfcqQyuTJK3lU ys7K1sp4ARwloRz2yDjBbsEsHS7JOBvXdW8LQfJFzzpWtyhEWQl35P6CSfn/PgpQ/37y6TZ6 l/K6WQ5Q4i0y7zB4514JCPcM9AUa2nsbFScz8Dt5C/sHeK11fBsyYGQCfwcJ2qLICT49/2uC rM7uK2+26Ak+c52/2URqFGKzvQRaVhH9NaNW8MDUsFpWDwQ9Pwi5MehCGcp3hwwR7WvtAUOQ exUGcjjVF9qmk1AFH+wK8IgZs33Jt2sMM34R21YkvmGSj0ZyQ24W6v/hwWFlyjoj4fG5XiBb K+Ic1VyYCeTyIuIPBDnv1gIG71cJj/4Pa+YLVr4klDIQMvI13w2aqkcCBWDGXjPJoiENxyMb 2UpYdYUFLU5N9se31cT2j1B4Ck7+jbGFUdSwnBUKnHsQRv2c7W+3JZ7zDLcIBxv/nPG3DAPS dM32K5xz6iHyAhzxAKIwSW8Yy2qGHgZuEt9KVMGq1MDUQnteQTHKboDL9maaBWqQ5HwsuhQL mGVbZ9QKUs/S7mPf7i/wnHm3JvsESvu3ST5idq2ruz0usfn+QCRwBVTw26vtVh5UnEsgNgMa uqYzC5LcFBpOBxi2ffVrTI3bF9ceAkJ8q+17NiijhtdYEgJGiHUmLpugOmKcEQM+swnb1gr7 qXkC5EWt1TZzT3b9jRMNYhEac4MTCUi50cJtM0t1ZO4wB1z2A7FvUptGDvbyLW92euoOA+Z0 EvAXYu5631bGHgYfXpmgULaMS5gEm376BTq5HsLIoFrZkjaMWFcC8xeIoLlsG7Kb7zb4BWyq Gq2cDa8XtnPbm8Vil/+fAxL/0w2T7h0GglLlBRPus02CqAsZai/Wks93DgkVC9YiWkjCQbYl pDc31iXcuW8M6EcSeRD2E+9mEgKCu4QWtx2NJeoJR5rLUvv4SFbu8J9LLb4FNs3kNNqPUs+7 81L25kPUsl4SFNHiBKGRDuJe4mw3SDUmW2Vfv2GE/9EPV6HWn+77+3n71H/JRua76iLYUerQ CwTcjv6fHdCPhE7zYwb5hPYS3Uo2zzzQAhj6g1+y8TRjIA477MUoxVLk69YRyBI2qh9wZuP6 VObZ1XQGeMvcR8iMlhv1qcAjHumIBFsRrofeWRruQQwLFGC+YGcS4jsVIe2z6bJtKP/8UiD4 IJw9NmtryyZx0UOaJLuZVnyGbzH9ZGgjsDB48qvPK9Mz02K4esDo4uOS+GO+XQd3Nxx6Elw4 kstXKRj0qj9TP2IK2ZLUfElt0RslqWdRjdEJ9dozZOawij+WUqljHeSwPqjC0XST8TuivdNF kO859U2y/LMUHz1IyBtxKbEpbH8GnMU5Ca2SQvH6NwchnwvB6joG0ibB6aPfyQ/Li9RY/XMe 0jLU09LHblCp5bkgjNMV6XHdUv/HIhJDcYLu+YLqqenTZmB6J7+T0q26edOVe9l1000JDZeS Jv8kHxIHnlXq/+kzLBLffR/2kg0Nqi+1jyYKxnNCGMBdwt8CDXIAC1/d0oecDSGecZHSsd74 MaydnP+1yPa4QM9athPPqlMrGsRWuAbvkxFNc1yp5Ljq7t4hTB+o7S5j7xEFyBIVG+oSVQm9 qS+EeLb/3fJo3ZsyqZe4lfuQnhIOHfB1jNv/jmMtXvAt+/WhCTenkctCfDRf0hHQHCQwYxB4 wBrdx2eL0TJhGZLKYyRzIAf2MhK1DLjP/AmOOQdMkQqB7VmSY8802LeeBJomVjAHOewluHhj YFqpe562Rw4bGg6vJpD8VI+LjBzm06HEFk3ZCJ95FhI+B7aAHpSSkUG6F1rOEpbk22RyxBoS c90MmeIcyIqZly3ZlrwMEhLgGfc0316zS/qQIwweEvXcnjrWhxpX0F8cShImCLc94FLpRMNo EjdjY9wXrxyPqhNnEjTnLN07azcOF0EtWp636ZKc3ROVks+hfy68MQ06LO7/HMj1eCGUwM+x +g8PH6qIhzE1thi3u4nfowomQ/t6RsA9uAomlZMS9k66nwfB38f/5nIJDs1GOWEHUYq+0/wm vPcTs4pN7vIAhLOduxNlbpGI4C6zd5NHmt8eLgh67ojt5OzykqnBChGeFrQ2SNe87A632uD2 IueQbXPPEeEQ0sXeIZyz8KTApqPRfD/Uw06S3tPokqYiouc+w2AV6qgHHB0l3gnb2AoHHgje 9jQHMkYfGzc83rs5Aio25Ag3ghFWQlUefDY3UXIaL/0Y+xzjLGTGNiYiqikebioeLpOdLQwi NNkT+xAN8Y3HyToR+ZE5gXdLh4+s7wQdcQpBwKyBvBCiuZ1D2TkI8Tmz3sKpmMDf2UOI8+nD oKYeOe4G2xzvET4Myl6SVvfD4Oa6QdgWmKGkXO1+FWrZYVlmGCaMGd5hsNkr7eH++6iDOgcP e/ayDujeHcxUuxSoZDYftzLbv/vOIqUkSxP+BHuC+9ePitO1bv2ejvO6eoImjwqrb/uNffbc HpYsRxI72daU7oelD/CP7W7Zi5IBYh++y97XNGLBKoZhtSD6AzZywECg2Nwj0XavZCOQJxOw ut6yuXMkG7fYHXwCWNx1f/s5kir9mgUZERw593PhwMn6kn6C+gX9eNnuaxi6BfoQpNmJj+FL FCKHD7KbdvZ4LxZ2Bv5x9OIUUfZtMT5xzyQJ3wzme5nbOSiuABHoMg3UQ6hvOfqNDgSU2Xhj 2n8IPgJ1ycY4zRj7jlR1BSMSzwokiTh9uBbb5jXYd5BhoPgBmKxaWrd6/Nzgnm3qku50RA6+ ewGxfXs/S4z9QwYtcTEZy0Wr1b9fsOd6fYHY5ITk0SIOdbJ1EugZqvbm6LfbLf+O+DIRRmZ/ IfVuOmxbBGkR7q8hZ+I7gAvy3KWfVb5d4uTfylDuwhKP+En7IvWSzV0iXkhWKAA78MG/OiVh 5XfY4Y5GX2IOH/IfDWW+Q1kriMH/qx8ubEIBnSgaJO6Q8LhXLM03iZh/vQDsHWa+Mbp4/jV4 HvWbb/Yac3qHBNqP8b4D7RqnIdUQ146gqVn0ug16BQIy24RLrvyG4KTb9K+aI5cuF0FmCrIa CoJbGYD4zbe3CJ7gBmwDjv+HEeUO8O9L0AIGFBHfEfWmK/bOykYHQ+7ORFXQzHZ2LtpZ8go5 cbDWEOoL5XZsfwlIciEloPxxjP58PgsWsAArCNym2P2aO01Bn2xf5VYBBS3Sw+4pIRGca6ba KYBEh2yFrkwNiLzs2amyg+olKNfa7rfhpj/Qa3Hvgnl7AA4viekj3nGkjkaseUbkWfyrEvAz sLChq0DxyPEleLSEXq9Bkqa+RGgDGvEp5awoQp9i4wu6/v6Y7rR1RQbL3lSdkS2WAWlv8nqk nsQ05DTP/izykvRW3xMNOCen6T6H1lWz6goB7uyGsjdSTbZuH8+6Geq6wqHTcRZprPyueycX wk3lVQdLlWSgRB+haROtRSOEUAInJFpTBToXpXkiN/ZYQLKMPogWD2Xr9O8S1NDseZEG/Sd9 ED1AlktFmeQ2KsgGi16H/+fZt4PdFurkMVosJ1VByP7Wzf1y/ZJp3hEOJmXJObGDFKFb44NJ rqqtNAXPg2y5h5YC8D5sbjzLluncf4SaBoVc8lR4CGYzWoRnnOdoxLM+ymatEnr7dQ5SaVL/ a3cBksxXbkIB+SC24zUHpNhYbbsbR3Xuz45tjPMI8Yj/E0Q8U/oZZLBYC1hnWG6xJAcJGiZb TASNYG5CHyAUHN1sHXcFwf/yGY5dmnrHYEXosM3+DcEhy91udw2fDJLBVRoT9EI2zglD/scu B+swqxXEJDz/PBHZ/////56VlN2O2p+Mn5TajoiD2sDX04fxFPNznTHuXHIfqk9M/////x9W e2aHmbrKF0oxvK+C9MblQN4BVvCgQVrbr7RQ31qG/////5xP3hVFSiO1YsO3W6fX/uRJhS4P JVDErX81Ds1pldNf/w3+/8GlQIPtMyG2+jE1pHsUSkxvicoWyUkflv////8Xf1fPw/LQ0svW 52ef6DyewK9f68SQ6xMhZCruwEMJ9vj//6XmFulU6bn1sumW+OSi9D7x0QsNfVAjNf///6Wc dekuvDl7/HArHyl6Q+mDGCvKkSYaYbxvEv///7+Uw0Ovopq2TuNbdJ5wf1K1QRY5JGRs3fy/ 0d/o6wcq43PJk0NvKy05LnmR//9/oZKckC1Ug1ciOnglrk9z67TDBt697AQ4Gv//Lf6MFmY1 RcGuzyFgXEwD8m5AnsKfxd68o7X/////XLGufG4aa98CIhgepmiy9xsfJ1BLaXZo9M0V4ZEw 0OD/////AyRnZTymlaTUduy8HEPCMsTwbFLOautB8rPoch1VX6C/wf//adQVLqicaDUnTrkd OHBFPnjYDRQo2iDF/////zk9Y6+KcAaC5PNdEwC3rvCULG+GU0moQoFlqj2FdJi0/////+lh 0UZpeux1+LFN4DYJanQ/Otdb4pDWhsWssz2RCTxb/////5cX0eR16uC9WNnOLcUZgdTEd3vg XqY+NJC4f0+Gnb6V//+N/971pynqxlf3i366Qppun/kHDJarx9WlT8M4//8b/TWlAzvsMyzI nFxU84CuKj6Yu2s5qWFkpP/b//+wwAjEfhO9cNX2VjJIQ/JXouyGMIUhOkVJnZ4t/////5rF HmqCQ/39J9YHxcBBRIMrvHwZXDrmYjRkZFH5Mq9o///W/zJP3Wcy+R6bGlZ9aJzu/YOKkbky NU9668zI/5f+/7alrkz3/XP/gT0b6WbX88wf2M3GP2oDGrai/////zsx8kG63Fvg/CE/WR+4 3+Udt8GXM27n75obKhY25gDBwdv//1IfjR0FwHHT7rFRvS5WUapyQ0p5y5P///+/EfEtZy+G KmZOvaKljIa3WGC4d0W1Yw4VRxko0RSv6v///1FVpCQd/Fiy77sG0BX32ZqzqUxltIoGpjkz O///L9CDpStVAi2bF9rNgeA1zD5Rn4k6CVJqByP4cgMv9fl97uAHRW59NqBmzeNmeUcHy3wf 024T2YWu4yUJOAYOpaRd9QMPdqQF/1gAEpAmWJgA02b711wBfCPRDf0XGPK92fn63yMiEAYR Knf9S2wKd/J6xLmP4HqEou6ceRrBFoCEfvdFMnvfF4aGyPINnpBTGczepuoF93uToyziCDyS svgCmeI34oMV7wIQU+8iXLq6yA9uFJWP7zG/4i3PmoCETSbScTa3DOwTeur7WfaKWeIDhxwj G/HiFqoVR+LY9t0BLd8O+M3db9QyDK+cO7cM8goC+/oCCmaTgvKRLRzAA0WNTeLW/AZvIrAt StQGonEl0SB6y2H/C2bUj/uxc6cKq6g2+wptSMEgo9wfsD+LZhE9o38zj0Iwm+TZBYUU9RT4 HZBCBmQU+3efpZbzjIZDz2l8N6vACZhBR+KL9rC49B36t04gEdmwizNDT0cGjCbtgjc5Vu0b IBaROHuztVNq9nybbhaL7kwXOlsRMYQ+wnw8Tez4aiR+Y3Q8DjKWGnMgrr5gA5bBBlZ5gLFH tHYRlzdAsUG2k3/RnvdWw24bqwvJPewS8BnbCbLNqFOotRAYIgwzKsL8NhRvx8pWUkfm3sVh VqxH0dGG3fkK2qyo7ovcu8WkEdrwH/6WP20L/wvr6vkCoxn5Bgle8VA9UG1DqEulcTyJbNQe Uu8GP+o8kh5rBa/5yg/zlMFDRKItcaIhSYfBCP+wCP2idH6c72cO+Xeg5q084OPsIwUFwnm+ nRfF7xQGszjbZph0qXg2xwbQtPyrL9388gT4Dbz49VKJ9U2kxdOuUJyWAqwLsHq0FXdTClfH a/uW25PDGpWqG9SqV+OcQmGs0VegfyP8gx5/ZLLtEdMQnCf8nKCcwa8IQK6Val8TBRlPPnTX zsiisY9K323ude7iQDoVsvUGX4nS2Sph1vYI+3Kxi9N5x8FIEhySjBUcxp4xiHO+iF+kFqDP DN8HxbK6kzNHIKJIDsiPCeS01iKQ+ejqZLwlrvmILALeIWBUsg+PH7KCCJsb1feIg7QZi3A2 6YeRw0PjeEIXlkrXsAk/z/gRLOAr+fVpd585u3VcCBnvrKLMx8jIQxfehcpQf/gsKns8/PkC 8bExrBK17rj5Es4pXQNhOGYUlPsLUOITdT//QkIGrEoa6e01873ECjWKFXI5yIC900OC2Wj7 dMHzPC8Ez4WMPLnFZh8ldEAMQhzpMsjJCxoLtWjkc49dxhL2kjc4lLEZsgG5wG5RdOclJwcH +roQ+pKTHOTykiQD6BLok2eH5LjGC+ZR+smnOckUB2L6F13oWS/kyBcF6AMKmD82fr4+VcnP zpunvBsvmhU4H0oCmjFrgRiHMEzBjPv2ExwbCphT6IfcETVbhnwnB2fqmqlWqEENKcqGsO6k X3kPLuSd6y8fD7UxWcVxPdipHnOxegJd7bq+nOj3DMTpxuW6kEoGhZSB+/i9uRy/+03nSczW dRikqd7qE1+dHjuWC+rSA+qsH/pLsAHtwCtz4BH9q3HdUvCXYqPyo3PjosSqJSmxQjg2c/nk q5jXKlrw7nW5/oUUWkYAE41rRTvf7bkX7ilZl0pYPf/HBQAJEm53kLtB8ARFvw1Fqm1tulWH BlEgCN4UoNIQP4m0/X8/AzxDEjedsf7xM46bBct1lmXZduyL/gUC9g7ywgzm7oSrEscjLpQT TkTZyRe/m4l/NgxU/AaP+bWFEf/X8E4Y6lvvB2v3B6n4G2wR8UPQFPH1dXQrLIuajP++luyv ZSbMpN/wiPDo9zUbtRv+3xD/5nIRr4ZZ4RpWol+7r+JKCKCogHe5ZoCF1oW/UJzoQyoGGDh5 wQOOrHsG3F1Zuo0j9JD5eQWPFx129TEK+//tv5lxJLS0S/sHwU2IzlbGyoj+xsOM3sa7B2/c aL6gjObGm4CTxtRvxqWOtnAL+PbG147y8vHwTP04Q8BQ/LlwMhE9s4cRyK59TQZMS4nJBKwr zfD8SjJJ4kbxQn7Rv/JbhvMAPTCsoGDyWyQ48lrUV/Ww/+PJmqJzCSyNUf8wEyLyBEv6YYDh QROYc9z8/Hb41goCqQL1eVnnHnuHDurdMyxEHUH0XnsvMXEM3gYGyLqPhKM2BOI/eDg39eqt MtExewPhvfAfT6R5A/+MowkJd0duw97CbWJW7P1QODUtGAgBrfgm3vEojsOoGybbWvfFkV2g rjLcEvOxK32CPK2oaQjZIpD7gzVB8BoFr+qkE64VNKdKWJhE+8mRk4cY9qDc9wF5Tsi4OvbW 6iEez6736GBeOvnclnv8dhVWgi83ipsNPJYDknLpBotKbizHqm4TXP+PCjzArUXGxqqBAhGt WfRT/QaEOJgB1X8lO4FiEaMWjzvhdd8zkBISD/BYqpmrzIBov9hsEw3x6nrCoU/X3e+A+14R CjTaDPAi6JfkWpWueK2SEgff7BM+crYlRTNhptk00AToYOFA9kf7Tdhju3Hx+rUqI+j2uLAF ty3sy0X3LSR7gchvqPbn97GivrrK2a9hGLBKlUAvpZAIx+IyAsT7EDfxpuwC4L4pqFtb12E4 yAZg7NGWAvXK8Yt46TFkxRo8/v3xtZcKvHeo1pxyUZOcewUVf+a7BpioLAkb6A34zAgWyBDc pmerC+4n+fa6kj5iPIj21wiuG+zRbkY2oh5KzPxixDw6v7YFFIDbikeln5koc5+ggxVk8Hx/ kBkPFHVP5nggBAelxH6PkrKH6zXwxmgziiO5o/HdNoHwpIMpHEjwtqBhh9CsNm85247cEQ4S rw+desTe5uuA3AaLzw18/AreyG1ucUYF8lxivBEl0TOq+VKlpAXeBYWx6vINKvTwHhsA1970 yhJnEwrzEh7zFxXmkMu+70wjBvL7Xh2QDHzwwVaqO/+BHxtxCw0iY0PGxwN/KIf4DSsantsg qEH8ZBt18Oodtm38eocbyu88EdFKwdyC3oH6SnirUjNx+Y41c+kKRjO7SsgFmjjpJb1S8M1o SqjDakLwJqE4+v5ccDDi62TaEg3zetbAQQ1ZFuZvjALl+DPo6DXGE+CjQSmsDk0dooVazgEy jXjxUc0fJBzwTqgBrnTeejGxofjZDeIRHxKS2Vi65zS/u2VaYqc5ks4P3VhyOdLsjgRfHxle giVePN2Rp6GSKVo/V6K5z/eMrcIfshJhBZ7n+UoOBEtGPSg4xmPwHoaS2rQ1pfKB53u9mUYN qwp+WXdjQFUjDUI2VkzCjcP40xKPBfCqPjXyormntiouXVKfjDODNbMKZu8MdSeyMwZv/1G1 9nfZ2LNzHf1OkmswhlJY1zKKcwOpmoYgxHpM/QRyaH9rolxUF/IE2o75vREJCLun7XDlPCKo WttIcuWGUIFn0POWEcnDBHqBof0DscdghzockvX1rBOMejEajKc5aQvO3A8YvXr60liUe2eA byN/uuu6a3mq9Uw6SRWgcvjxow2LccPB9fIgHk2MjM27utJLlO93R2OH9s31+PCv625uBMqI w43/0hHcHiaDXha4ZW1mxgXM+w7Np/5j/Lq2ZHYa8Z2RAYTGRIv7hDD1BoEUyhItMyulR2Tk 2qhDWkO6I0uxmLA8De6QZ2SQobTU8As26+bFBU+y5zDhtnoP70+XOE+FfgbY5OHDJhJ+/FwC Oc7SzDACXzyUS+RsVs8qpfyZOLEL2NMhkpUU1x0RuiN4Fhxx7yN5OPyswRE0VKlsqLpsWBcx ARHkFbbZgpspqQ6+XSSQkgH5bZKEYDb/hHY2GFIrgltuo5ENG08HbDnJw14g6+plif/YAjvs 0vn/6xOys5ktRZ4FmhhikP3FzJKWWhOYoX7RmgzPimMGPC85LIxWHP7mRoaSgyj+pqKZ5GFJ Ub1abhZCBhn2eh7szFDPvj8mKUAKYJ6RZ7pVxl7lRplaXRbLJlwwyn1R8PkWz0G8BRkTJFdd unUg3JCdT4Tez2Xme1oHZCP4aws7yCFugP5iu0tnrVECYyLskluJkun5OrZwBO0+NiIOQ6N8 nuf0T4YFOY9ykaVcD1eOaxvZXisaEBZb3giWkWVkX+FT6FerxFlG80slGOJSOKg5LphiOPB+ bfaDDEk6Et9VmES0U38SDO4BvtaWGzugCtINa3Bme1LzDgjL72zA+QuFuQ53hxJD8j4cgLNM Hp4fGqp7kHuC6upTEq+Ri7HeiJ+Krp5qikwTVZgrhlEd9fkEIdIk0og2cC33o/tR2k+hDiOw 2W3jCwSpIPInrf/g2cEWey3NijYZn+2WpdBwAAANCgFJbiB/sP//YSBkaWZmaWN1bHQgd29y bGQVbmFtZWxlv91c+3NzIHRpCBMcYW4hdG8gc3X+b3/3cnZpdhJTbywgeW91GGlsbCBiZSBt aW639tvvFS0tIEJhZzkgQXV0aE8iMjlht2/uLjA0AglHZXJtRHkufW//t+9qAAHojkCQo2yZ QABoDzgE/zUE3+0a33BAFCGKBTZsBBaxkGpk2v7/dwdBbuvxycNVi+xX/3UIX+sIR/YIgO1u /5ezBTt9DHXzX8nCCEJrT0cAEPsg349BQChok6gOcIEFcVAebu3/ZQAA6ZX+7//M/yXsYA8F KGEZGRl5JCAcGBkZGRkUEAwI8hwZGQQA/GD4MjIyMvTw6OQyMjIy4JxUWDIyMjJcYGRoMjIy MmxwdHg5NjIyfICEv4hgns/n84xgkGCUYJhgLPl8PkegYKRgqGCsYMjIyPOwYLS4vMjIyMjA xMjMycjIyNDU2Nx8Pp/fYYlwYWxhaGFkYcjY5PmoYaQFnMjIyMi0lJCMyMjIyJiwuKzIyMjI vDg0QOHIyMhEUEhMYdlkZGTkeIR8gDIyMsKXFBAI5DthMgzZYAUgZGRkZCQoLDBkZGRkNDg8 QGFmZGRESEwAAiRUQSKaqaL6HcP+9t8+EASMT8vDz9QBy8/M1Mj6AG3///+ptbyurbuov6au k5ef+p6IjJ6elpbUn4ILptn//4EMta+uqrWprtS/or/6tLe7s7QJ/v/f/rWorrW0pQ2uv6i0 v66lqb+5r6XJ1MqlzsrN375tzyCqvAqlYKXDwqUkpbe/pWu3bdjIsRgMqS+0vTkQ+c9uB6i1 RbmuDKm5sr++ych2a2c/rqy+twmsqBjLzAy19v82sTiztdetqKrXzsjL10gKvbnug5Sxs7a2 TLleX66vqreZO7Yvyxe2vhUJHLu2J+QPc68Msb61rbTIyn0sNmsAEEIKuba/uyP8P7aluQu7 rIqIlY6fmY7Dgh652MJZ+7e9qL6zHii3E8ql5GTtNrnnw6JNDLSuD/s2m6wGbLjLwssLrr7P bu3Zrbeks7m+eaq0pb6/C4O1hbylrvwMqo6jLxvWZgpSB6m+qEJhVnAr2I0ZU585tnK/n7IB v6KrrxxYwApMGCWsv53dkmeqvheiFq6zrLOoLdiH8K+p17k6vLupCBewMCu0v3J2DEStOJw1 gsweEaqcWQu20AawuyKgB5KwzdqpYmnPtYTkwN7+Fc/Jylu4o7gQrWDbgyWjvbi34a8KZd1g jaKDvdy+CdbKEbZavd6yu4UEhn0JjTossq62HSs0Tti2v3q74XkKdnhbADWor5w0w+Rk77u+ ggy0rv1CskOwCb8jzHYyCgOzy2Czqp+MLUy2MaggqWqwMxRmrdUTyIIEYcZsWA0M5wPDTKV2 trMLX0QQG5OWuarZECIZ1y5pSUsgySE6tu3Z7Ui4iL3ICanLotsOxhmUvv68vSagCgtWKgQL kjMMW5aE9q++iMeiG2mhHcYrtJxIrdLbDlsOu6IJqeG4Cy0Jkw0guSAKi5Bsa0Mizl6/GUbD yTq+Ir+1dbNvm1uCG3NUDEC8HsPcsLULJwrq6evfsBIOqqOyr8nXjUKwlmzIFEm/mq9sl4T9 C6+3/Lavmw7htbmGJKy9e6msrN2eZgw+17u1sAgP2LBIKV4NCFrhLTuqs9kO8rUNYcnN9QzF vrruMoZ1HLUJ/bth2ZI17M/PvxhCLqzYN9iWIrYMvbbDDAPPcD2po7TOBr6lStdBak28sy68 uLOMrW7ZMAnuDargLYHCZQm/7zyWNQ3WEqkItoO+CuGDwdjOv3q1h7TzQCsvOa20rafDaA6C ToKOUmzWCwaTKnsSyzgwl7MVqq3AbpBvCrSzorGsJ6Kj0Wa1hzK/uKuWvfufrP1+yKnDAw+x pc3MpcvOycwRZYM9DrNyDL7oYIcHtgy8CbOND9k3WFgcyx3LzaXKD6zWNLA7l6kohZoN9hTL vJC8iGVukmjxrnyqWNdbmD22B73PDFiuFyxzyw614wsiNQ4UTLnGo3UxweSCbkK6Wgu4Bzf6 iYOJ2hd2uUSwpmAhq7Wqtiy19mCiaEYvrMoUSW/YG1cLXeXQOBi0d6atvUsuRuEgEa2yqI+5 huRMs7eC/4HTjLCt0QqE4L8smRhCcyJ7VTirtSWcB6gSC37ijof1WQqpuL2TraOwTBjcGlSn sam2ormDVDBk7yqgu7+FBhGGCaB+tMs6tWAQDY7fadksZrAfCRUiZXHZC8lCJBIYyDK+cCsI BUqTpLIwNmkQWr9Oq88Yw4WAdKuWEazCK21tGDSkFfM+vgSG9Ya0DL+4NrAuBqgHrwouQo1l HahbnaPYthCEO/OsJLSJVoFGK8N+R2dmKpQIqPBZCxFms3e4lgpCWTaBCYulMKUBGmevQmtC 7EcRvIOZGrO5B+gXkKmSDLxgZorA9a0gZ98TtDe3x3C4GbOzCIwHThIO1s2gOqIJqckQZmzB WktkibxKe7RkB+RfFe3SFYj0ZM+jt2rwdUvWgm4JSJOpsSQF7JstC68KkDLYYI3bBrsHty8r dWseyNc8C7SuttDsIdfJCYWxgZstUGD3RLgJdyYdWFfntAuit1vy7Cz9rn6osAt1M0iWh5Yq qh0oVJhizUCf3BJqjQysDQcMGNaCOXYKzCGrLWvkb/ULSsbIlqwwGWMLvA9ePwj3t77wZWZq T0iWrLS2inwMaMGcaTwLDAsaOYK1vgkPL3LMcsELt++TrFUqORpU1VMyGqyJFnOiqAuyMGCD RRYMs46pFsO6JGMKtQkKxLKRb9+pvwzH7AXMrQ3HDqUrCLNbvkHCwwwSxw+mYRSRG4OiRrNW Fk1bSbAmNVbNp4De2RojsEezOhxdWSySRreQgFx4s/kKNL3JKTdrradBCEgrGAYmDreTORyN WVtQvGTBGQ/NDg3WkyOpeJziw1rBDAhzDK/KycJDqFUC0vbCyrQ46YLAo12uqaAzMQT+DLfI zHj4D9v/yFZ9t/qSjo6KwNXVjQDUA3vh/4mKk5+dn5bUnp/VI4qSihsT2L/9lp+TioCTHYjX l5+JiZ8jl2D/BfaVmJOWGpSfnJWIl5tbyE9gX5uMkk+dlZ+OkoG13xYTnYiPg46OrPuHsDKS opuPjpWJmZUFrbUEdsjOH1TcOxPY3beZQNeYlY4Hm5yOJ5iEbwvsl5icGJKWk5SbBitcaCFP A5SUQlsra4VCDW0DXGsnsP+pipuZn5mWj5g/nIgdDrb2IWzXvJaVjJ8+Ip5Fu4UQM5WUldb2 DSG8j5KTkVSP85ai8O4Fwp48mdcelJOOgLbRPoB3m5ibkThDjn+wwgnklJufl1l3ob3ALo1v k5wVjW07hHCdlGiZkYaJkf4LrG3PjllYioiT142V1/JTwht1mI+InRSMk4iOj9othPGAlZTP 6YmPBIwJLxCJj9fq7i2BtQubcBiq0naBbbSWUY0Yjga7bY0QKhvXU46Tqe1tCGmJXoAekZWX BtRwDGF1mcp4pcIuhNsO14hpFUZbYI2IeprmPIEVFtiZnKByNmULbUztlxqQpYE13MaT/YzT rMo2YTtheIjM1+EqLawE95eCktm90ILCEIIrRtQ01/VSO2WmbBzJjuolVtYW2pXRbJlWOLAt lBoIjkMxnj+WhQMIralAEsiPDQuEbWuXHJ3MjP8AmJ4KsKjXJwKjUGqabbn3N8cE8pydkVY0 n5QyNEYIi3tdCOuRwmDq+wghjEIPHtxWKrRCD3cCvcoK7hGVmR5GUy5LpduEiJ5buZWIj9OH FkAU2deVuFwgtTarlbF8kVzHBgkmR4+UH1fWChcInZNmCvOegLW1jpP31KPGiVsaOFMpSVOJ 0gghlQWPkhqnVitQvohbRT0LIQwatm7pjyhcYBsKk6OWdWOEtJkzY517aynZDK6UIdXnlw3X SuCXkozsuJqVYOhMSP6IBB202rbFiRXC9Yyz2oEB1gofI7fjYaKJkogmidhsw8SVaI7JLIM3 KFFqARWaI0YIy1By+WzvCOnC9oDXkSWWmY+Sm2ZaIHGemfCUcrDAlrZhjvKYINX00Y6o14p7 XNdln5bbGoUXdo03X6YFEo0b//eMbYG1nmTYm5QLQggLxzM9TVyDJNqO+1xVsFm3DbOcZpee I6XSVuAtZiEZlMwTBtoEnKA8ijU1HIW7AmRviYVSaZB0AEu0bBvCTM0k12adh6PQSimlQ5Gm QiOEhNTiEVtgJr6Hlg9F60JioWmAy4kYj2a25KKxb5YnjMcFToUF7qeNXyDgCj0ot5mTmcQE kqGMH2GVaLYwhMSQXZvjpba8QG6fgo5yKf5LtlrqpoP634nFisffaLy1haXc9waJ+rtOttFm Wtb6MaTVGYoJbgdbCiScCZCKvvqdnG1d20aKMd+WKr0LqcZWsh9pj4oOR4582m9j7I2UD71J szy/lHsJbKkZ5BxWnxjdWKFjFLaV9RW87Kn5WAMH4gcXqZuMnwaetR6ulbw0QL6TU7kCbrOJ Fsq3oJwFJgqzA/hgwv6yCIcHTrY32/oA2NvlFyOqv7b7PRc7ajL3m/1/+hr69Nvx+//2+vxY AOrrBLPvzboD2g4LG/4ebrbsZAf6yjMGKBlLNrDqBwYM7ux8I6zGoALaAIlF9iqK6jc1fcG+ lmbr/5Cs+LYt15R6GlJzmRDSOyWcTSP+R7j6AJoahyimmXrimNlg4CuklVoLqurukicvJuqS 6gAPZjllk3IDaupkQJ5tmlY+KuofEOrDQccv4/q5lp2yoK9/FBytyA3Lary7+p7GkoOO+/yt 9ySJxdK3LrYYmR+DFvpD+K2BtUbusyT6KfjOyDMqQQPQF7FOtixt21J7c/rZYJ8Iv+eZNnuE K2dN7By+wP8KWJqH9vuPvGrpeONTZJIat+oSYbOSAc/e2Q5ixwrf+t8koE/y4mrlFJJhUb25 9ykLEo36X4KepKpRySFquVEQkk28zvqINkQ92kTgV2hmE9ExVKis2tn69wPE8wYS8/qkUAXf imVGRkY2BY6ChnocgGFGcuf6////g9rL0MvVy8DLtcuuy0DLOss8yzbLKMsiy/o7ChVlAAba nHlsCUw4R9YIjoKOpW2DbZ0GlEKfCIpI2Nt7tZIF6xsJk/fwDO3rJX7ax9rYr4mlyDrYF5/k hrWpM0kat7WYkFVq6U2l0tipmaCKTGcneDKlpKmzG9gN5tyy0zl6OUPU6rLPnUGubTPSg64K WDBntjWjMZ973ecdKrQV0rgk3pvAEiVuBpvHo+uDbDdTroQSaMbHytSVNNaZa/cNd9RB0stc 9y8riNKb0pPT0yeUcB9dsLNYlU+ABge527atBJGzvFGoq57e5Oy9nYzL1g9OD8jZBjNwu4pa Ick3mYKrqxY04p+QSrScK0eJXhXnyAgtIjjdTZXv8DosFYnPQCresjtqL3+U2tJIGYsW7sMq i4+TzLhitb9sb9YEA5bGsq63tsQVgTfovAe/u77jtr/EYH+z3Qfar4qec8bVFSauu8C/VQ/A u6o6rsfas77H2FiLBuyr2NoStGgTbAWWgAG+fAqUXvuwQlsNqa6jRxLe25orCBQxqjIQBtC9 1gw/CRS1Of1nLuCirosYt7uis7ezoAw07FZUrq4sQBq0wMgTzLUyRr23iyC4u3cS5Gj2F7Vw yrS5vxMVc5e1TVusk4EVAtdKeA0+OlsJOgedK5eBA4Al2v5tu9X4qbmos6zaQTtjt1C2vR6s uNDYHZD+Qbq3g7wMi5yW1IyYiQr3Bkh6vKm1Bq41O8mYjYz+ZvwKqT12J9SNsnbBwm7tNurc 2qaJlpxGxtYGUtbKFJFCg6QQNtgt7EJZG2Tm51AKYYOwA0qsEbbKGDkt2LJCWBtCIBE2sEJX IgphIaxsLlmsUPaBSZbNCBtkA4AbHCFsQdbVTKwyAljqXoQEQgkAAZYQSGFUF3WBQApbLy1t lzSwIpm0xZIaLuTM7xK8vlOths1i1JFlIA1OoJWSImfBqVnuYUMp1KirSaCAaSFkytIte80q 8HmIhpCmH4UIPMSNqRsD0iHwgrXTIBYr0r4QiMDV4/f6+7nWaKelXd1uPu7kbdWg/ZOfjZ+I CDank7VGa82jE1fRxo4RC40jP/q/9unbg2/tZOG3k2ZwlZyOpinaVrQHprmPIgmsRWpWriGX psJJbSboxlPUlfqzBIBambe3nfrXE5KOm3mY5CmMXMBjurPWGoaOFpROPjGK/0YFuqvPsJj4 +f7//P3y0oKpUmDHh9/lMJesuSLxDXENOQdhHpWIna8Gt/3CVpe2vKi1t8DGGsQXGtbAwLne Sw7DPril0LsGK7qX7a7eHqX6/PuWnNeJQRi5RGvTbiT6j/oWojlYT4PpG0iJKxTK0QXyBucr 9Aa5ln4d7Z7XmYrW4BoMG+SKBextqGbuBY6egwc8B6VCYZGCH3B7ZqA2Wfp0iWAAItsWLLR7 p/qrgmOJiuZu0J76IY+CBV3QxqBm33BomS4b5Fq7d5KVtFwEvJtU26VogCLXmyG6B8eXwLbw lpuY+jaJa80ZbpWVnd4Nq80c3VozcJeKLH/CUvqKa61trTvXVpu/C5QamrttWxCdMLpHitSs UtaCRtspg3wt9KYY2tbcleaiiJe9plzdwje1pvrQ1NDdjWnUopt1nBfxl4mdAIkFBM2YefuC l5YenpiCBJ6fXN42fxOUmZKXnDyVnomZnFw7xMEYeQQhsV/BFXYhJ16YmFS79sF1TpYrMNSP zzWdk21u7HNEGJ5ykEDIkhqGJ8Pnvdq1nDHjtGDaCqLJna6RLEbDtmqt25Hj27gptfchtBGi qtYLBrniJ4cvjdqxn4MTNsyl7DVfLSY1rdAObC2qGU8RFMqttYkLBAqblnhopVcuVdqZCpZI FV2XXbfb2yraN59onQy0/pvTWGWLeIeOe4loJbxtMrSTHQcyjpGDrFUxCp462Be20NpZRYqY DgySGMNirYlKggA65Rkd8aipCFza3Tk4ZqLqIbuSDytgW2vvV0HNMrBLhdx2tpXdklnpgptc rGJrDSWR7YKi7azbDsIxjcOiANrsKcrmHVyIG4lHwZbdOLt+2swpEdGECe7P2qpsMD7ots2C lo98mEeqkqCtrRkPBC3DsI8aLLQTaLcjGIKUZaqFDniMS4862G5NrT6kMZLgj5gPjgoNYubs RHZSqH071jsM+p4A3dbd2gXGrebWZQDag9pDssCP2Da20sA+Cd8qkwPIDlzd1lsKvoTAWT/M atC2lQfYCC89AZcwU4EQbvQtddLZLLeG1zvA2KhR7B4gy5PXVo5aEDwVjFfWum8tXgLXroOK ZZfVsO3W6qIp1RuknsEfVqhWsNoAPwQYmgu20YOS1wB3Hkb2hrm8DxFPhsamh0bVF5bBaY7R ajQTbD8fJgABa7RQkx0seMUGLcqJ9ddqUlnh5sA5zZg4XgbaodYRV4BUeOztIHuPUZh1n8zO IiK0WLGdZQt0VGsUY06hZcEmLLAYi1VLUWAq+xTEm5tO1hpfqwO4XtXVGBeELTvQiS2xsGBv EBKV+gSe4M99bQMR1BkDxpiI78GH934JncTGHhHZa7ESxgkGFuRopa3Sxj5QiahdxGAnXLSe wBLEQKrs2KHLy3Oeigza1wkNY7M3Fg0AqBK3Lr4JtIlI0g2yhGrs0rGVCaObU5XbCq4Bayw1 /3mDbA5Bh9luVMDTDb9N2jGrxoJeHr4ZA3uZMLiE+B1bcshkFLe/jINDw94QHFzY7iDEWpkG t/q5fj1cDV45iy7BVqhC6Q2lBjBqarVkT7ybgkR2zy0WVOjqngFtCaOVuWWRaxXaHp01msER e6kaHKUIw2Ui/w6MDfuWdIoynuwA2nN1NjubBRDUfgTuZwNXseKTjIKeBEMbVpiTdiq2tFos unLaV21y4IJsdJGJToll2CFsD5iTEIrCirOGW9Zw1I2fFyMZ1AawQWuKBguwQ10OifBwIQB2 GUfXbLoFtmyDM6+JpDQ6eGSANzWXmSmbsA+Y1EW7mJMto2GPrV+chPACCEu2I/dKrh2ziCv5 lkIcnAJCnh4IxuSeodeiGy0acwA77NE3jcKGwGUhETYbu+szfiILhC0sWNIDmNRmgmIPDDVx vseTUimKHJCMpeIOqeuW1N3fMfr8pTcxE4cNNrffHKGwcEjjozGlHCFcWWhgpU6NVKUzlNxb lLK5nKW2/9IFGHAdx44XjFNta7H5+k8TiSEVmupOWINfu5YspV6eXCXcrk6wlSl8HINobqYC X4mllJw1TN2cf2aPnIABbQStnXqbB8WPk2uO3NcdnhGIRO+sxWzfs5gOa6mXU7OGn0wwNHyE pQ+l6x7WMtVaJN3eLII2WHCOgowLjE2Tu20xi0CKkIGOrj5zYJislCGJIBfkcnNvREi7mZbV Ho+K3KG2TawYjxckMoxdzBVSuT5ojqm8X7WKEEMX/ZanWsBgaKjvaETBHLmp9F45tdoihaQ3 knCobbHKp3datAIfbIP4jqonlza3j6KCrQPxbwGuv7Sjsam+cVYbtRjNu4m802jJqf8dtEZI FOv63b7diN2V3Yrv/oV2AZ/dKqndkd2D3bQLjt36pU2z/fbXlbWbSYbX0anRA5GDtP3b0jSf joZlsbWV16X6oTHiUs5PiKaApx0/a3C0iYNqRZdpsJGWqc3SNVOXUgDXxK8/Y6+ZxgoRaaep 15Hc+Rb614PXtNdQjl2h0KqR4Y71rPqg0ouAo7DUhe25ga5Sg8BvPvrDorKO7voYakNbSHGK D6bavNWE1jZTjQcIXD3WGMz6B64nUrO5q2CjW9a2+kMNvjawh21srWopyJX6QaklF6GrjGmJ vuAO3VIDVzMzioNDqjVHzQBaB4xUZI4KsFm03JqLYSxJvWW7JfoRzxE4OonIRoMKMAq+2oT6 cwFZjIpcIgAJRQILJYkD/5fLqTQBVFABR2V0TW9kdWxl2BYAy0ZpToNBE1gLgP9Qcm9jQWRk cpAP/+y3/1N5c3RlbURpEGN0b3J5JFRpY2tDb+zbFux1bnQNPEYbbWF0QQ9jbeyfWm9uZUlu ZhVpCxdXbf+E/WluZG93c0tsb2JhbEFsBmP3v22HDEYdZQtMb2FkTGlicmEmz2LJug1jJQsk TWG7Nff+cFZpZXdPZsIOzGtCea7vW/t2VG9qZGVDaDwUT3BlbtNr28FizwgzMjBy1g/N2u4B TmV4DlJldEohgN3NrWdnaWlEcoJrW/d2U3QFbmdziVMYRcVxtd3PDQ0IQXQfYnV4da39giET UG8xEIBT2iGCuwtlcAZHGp1t27b3HwkVVCFtJ2EZ4Rf2ZKJVbm3VV2FpdF3mDG+uU4AOT2Jq OxTf7S9ZC0v0FG5FeB7hdrZ0MnJlPWx1cmOYyx722QltcGkKcHkJLvZasG4KMQn8+jDbZmei R89/egzhCx+PEFR5cC9DkXNlSGEQDwz3XmobyQlDddjBCoVyqAbcSWQU17rPAhJvbW1FTMBV BHsHx0YnkHYOm3sDO68PeHLuafgP22VHQ1Vh+29saGVscG6yX1jTU1dwc2hvdBloBhu24bBk DU2ueEENWpcwQ8dNcGQTDNpCssJvHwo/YRuabO0SvlJoS3PmbqdZWkEIFmdEGRTM4d7CVkR1 OBAWDWz2ZG9FdCBLZXkOcmZzb9kO3w1UTpijnZ0gIULwHw3Jbk1vkF9iSkRDttmbHUptfV8W CeFjO4w5Rllv5GywjW2CO0lQgyZ27xizWWtRXA4vz7h2w9xsCD7GQms329YMZ/xUpYNRcqdY 30xJNjRRMQZtT25I21qHSdQ7DmppCuFpNkdH1WIAU6s0W8OjbLVCQUVuQPbYG+4/33JJQQlE dXAI2cZgbgISVIVtCfWn6dxSJzl6WFVSTESmm+S6ZW5sQGkchWg2bZ1gfXDJdGZNHTss7DRh Z1BvkP9za20ZZm2VcKQ1eneVGk/u3hxoVRuqHE9P00mQeEndbrrsa9mSAhR0QQ6MgJUuVVwR 8zZD23BublJlZMMvWZy5tu5pjGkfX7xkO0FAo7GedMD4VZidzCEMYnkOSHnpa8BQWGOAcwNr ZXS/yltuYr1yYWNjJVNBgdccd1xydHUwIxl5NvtmrnYyehRsBz75L8dgzVBFTAEEAMwPkECe NP8P4AAPAQsBBQwARFZIUPsMBwLfWA1AC24WbDkCBDMHDMDO3JLQHjQQB7O8JN4GT9Bh3F0g kMvAoAOnxPuarrABHi7DdOtCkHcX9gXrBCMgHi5yZHSD7Qqvo0YL+wwnSNli3YVAAi4mR3Vt SprucCc6VMBPBhtsgXOCAOvAc47Av9/KJxtwZA0hxgAAAAAAAAAAIAH/AABgviWgQACNvttv //9Xg83/6xCQkJCQkJCKBkaIB0cB23UHix6D7vwR23LtuAEAAAAB23UHix6D7vwR2xHAAdtz 73UJix6D7vwR23PkMcmD6ANyDcHgCIoGRoPw/3R0icUB23UHix6D7vwR2xHJAdt1B4seg+78 EdsRyXUgQQHbdQeLHoPu/BHbEckB23PvdQmLHoPu/BHbc+SDwQKB/QDz//+D0QGNFC+D/fx2 D4oCQogHR0l19+lj////kIsCg8IEiQeDxwSD6QR38QHP6Uz///9eife5BwAAAIoHRyzoPAF3 94A/AHXyiweKXwRmwegIwcAQhsQp+IDr6AHwiQeDxwWJ2OLZjb4AwAAAiwcJwHQ8i18EjYQw pOMAAAHzUIPHCP+WgOQAAJWKB0cIwHTciflXSPKuVf+WhOQAAAnAdAeJA4PDBOvh/5aI5AAA YekEbP//AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAMAAAAgAACADgAAAGAAAIAAAAAA AAAAAAAAAAAAAAEAAQAAADgAAIAAAAAAAAAAAAAAAAAAAAEAAAAAAFAAAACk8AAA6AIAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAABAAEAAAB4AACAAAAAAAAAAAAAAAAAAAABAAAAAACQAAAA kPMAABQAAAAAAAAAAAAAAKDAAAAoAAAAIAAAAEAAAAABAAQAAAAAAIACAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAgAAAgAAAAICAAIAAAACAAIAAgIAAAICAgADAwMAAAAD/AAD/AAAA//8A /wAAAP8A/wD//wAA////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHd3d3 d3d3AAAAAAAAAAAAB4iIiIiIhwAAAAAAAAAAAAc4iDM4iDcAAAAAAAAAAAAHs4MAA4OHAAAA AAAAAAAAB/8w/7A4hwAAAAAAAAAAAAe4D7//A4cAAAAAAAAAAAAHgL//v/A3AAAAAAAAAAAA Bw//v/+/AwAAAAAAAAAAAAf/v/+//7AAAAAAAAAAAAAHd3d3d3d3AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA//////////////// //////////////////////////////////////////////////////////////////////// ////////gAH//4AB//+AAf//gAH//4AB//+AAf//gAH//4AB//+AAf//gAH//4AB//////// //////////+IwwAAAAABAAEAICAQAAEABADoAgAAAQAAAAAAAAAAAAAAAADY9AAAgPQAAAAA AAAAAAAAAAAAAOX0AACQ9AAAAAAAAAAAAAAAAAAA8vQAAJj0AAAAAAAAAAAAAAAAAAD89AAA oPQAAAAAAAAAAAAAAAAAAAb1AACo9AAAAAAAAAAAAAAAAAAAEvUAALD0AAAAAAAAAAAAAAAA AAAe9QAAuPQAAAAAAAAAAAAAAAAAACn1AADA9AAAAAAAAAAAAAAAAAAANPUAAMj0AAAAAAAA AAAAAAAAAABA9QAA0PQAAAAAAAAAAAAAAAAAAAAAAAAAAAAATPUAAFr1AABq9QAAAAAAAHj1 AAAAAAAAhvUAAAAAAACQ9QAAAAAAAJ71AAAAAAAArvUAAAAAAAC49QAAAAAAAMz1AAAAAAAA 2PUAAAAAAADo9QAAAAAAAEtFUk5FTDMyLkRMTABhZHZhcGkzMi5kbGwAZ2RpMzIuZGxsAG9s ZTMyLmRsbABTSEVMTDMyLmRsbABzaGx3YXBpLmRsbAB1cmxtb24uZGxsAHVzZXIzMi5kbGwA d2luaW5ldC5kbGwAd3NvY2szMi5kbGwAAABMb2FkTGlicmFyeUEAAEdldFByb2NBZGRyZXNz AABFeGl0UHJvY2VzcwAAAFJlZ0Nsb3NlS2V5AAAARGVsZXRlREMAAENvSW5pdGlhbGl6ZQAA U2hlbGxFeGVjdXRlQQAAAFN0ckR1cEEAAABVUkxEb3dubG9hZFRvRmlsZUEAAHdzcHJpbnRm QQAAAEludGVybmV0T3BlbkEAAABiaW5kAAAAAAAAAAAAAAAAAAAAAAAAwwS8kil1VROPQr5o K46bcS+enmKoLQV9lHFGeg0iQXoHp4FVPDmqTEAomVSdUHolUp+gupKtSakHPiC4s6RuSqkz VAhrlELCccUiI3ZzH1uoHJwSrZObxRc9mqASjwS2NJ4cjbYUIIWeRXJIMgmstzhJipBFXEh1 nDojrYQcnMKUczN3DIvAnmICYwqfAmwSNxeYarYouwvEDMCOWQKHACvCnm+fWaicrg6upXN9 Wj6MGw92dR7CYDQgvBiLlwQ3uoOctWGCDT1egCwZAzMbC8ULr225CkuXIhCcbTE5I7tknQGJ H3OfTT+UAUBXloxlUSSloIcIimSAX8Avq30AIcQiKbvDhLHCZx8EF5lsc2WjBkpvgbhQDHkH v1QmvsdYOQa5wyFIEiJdxVGPCXYIZ7uiFzABtMAjpReKXKvCwhCFjV+gf7ObB39rYmGprp2o vJBpGbkrorwwOiNgXBxKFkFMpsCcV7A5jjBfxyCfG2cSJDYRHW/BpANRIDK8JFp+l0yHWkaN Xg8Mp51lRH5BFhcxc1FzCrMGqZ4JDTW/XmynhwxjkQhyb4Qsq5dDIhBOdgG3woEiZlo8TkEa kQilvqeYOq85Jq4ys0+vEQCEwsGMRTAFMl1uHzCJC5tcwh1rMms1w0BHOYu3J6gmoAyPulah PwuxVIhsP1+WBZYrw2hIm3ZnM6fEALo5NzBchneKsBFah2Y5uqwHbQOQS1CBFxmHQ267th2/ KlarUWVgWJVqmBIegkVWHwgvnUE8SBCVObogiMZ4gWlYTFKwhq4EolknBrt5tGKwUYsqkVh7 IpVpC1wEcAIRioOOhCwAd5ZKCpa/wpaDXHPHjqeHKGybuaa5DHgFqGfHGIaYBC3AUEevE4mR UHhFUDZlhjCVWYOFczcXUqNGwYEMkWyJlVCWQxuYAFYqboCjqBqbsi0XwsImClsvciSOlg0X sSuwk6YzpbFjNFhKvqepwAUyjy2tIopAD6WlJj9vQR5MnIcVXEMKeZBBwmGCnaCrCz0/SYt9 NGc6iFZ2HgqUwTt9GCl8F0A9EEMjBCN3FyxdfBZQHlQVrDZQZUQvThRmuaEBQwySR5WygcOZ HwefilCfvhxNU33HeyQOxFCPV0UFvyI2lzBWQKkFImjGvG9zVMB+mGh4KlKjBiUmdWhBXzII SlE+f3xUQzArmUJ/PSyiSryZlhs5Ib0pt6KDoouxal89wFMLbSm2SC+Oipw3IJ5grSF7Kmsf EY9ASlxWB6IbbrNwakeadGMFYU1CgABEnodGklCqTII/lEZ5oxueZQGsTayAlcevol67vQtd faHHNLKoAhVCjkIuoViOesNxYhuKkX2ALpuxsAsPITF/eoK+BZFQKGAVlY63ErGTZJC3hH9t vHS1QxV4e1cLYVaWfoGMXQJzbY0/r0AgmqkMMJYTRS1HJZu8OgYhbyMIaTGxFblWM5BZB1dF bSQLn4JpLbxgkRxgj5UOn5degIKkZzeDa0h9bYMvecI4Ex/BHkOxbAhAkEo1ia+bNW1aUKKE soBauZdMNr08tkcuc6F6MLJjFGQyhYaSccRIwIBvDoMYn6lmZBZ6pK1UIyoHRUcVprMJkSm6 tbmWazMMimcexJIpCBEXWAcbKQYsnUKbPMetvnkhibY4VFoqJEGtQhaTIwGyI7dcfau9Cbd1 XCYaJGWPn6IQS70UP3NPxECwLVO5ER42wZsik4BfFZusBRmYNUlFA6x3V5o+rMIEiIEdKwsI gWwgszVisEelXVZ+LYKYriQ/Pn2nGjcnhiAfsU52l2MZtII2JYU4b4C3pXhZjSw4syVxiRDE o0OprksqKG8CLaDCUGBofsdGxGcqdFIIHrmbRlUvQgC+lVOSk4mmnE6xrRxjk3Yeqll0mKuv fmZuq0ocCHiSTYUaSaQKoyFAuQBmYcSYLCctZ2J2TMWVK7ekh0NZcVOyiI9wZ0Y7N2AukyM/ BygzHbxQAqVfx74MvkO9o6erYEapWIMKTDRxsg== ----------fqzbzxfmrctcxidotdku-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3TAshMA086167; Thu, 29 Apr 2004 03:54:43 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3TAshKH086166; Thu, 29 Apr 2004 03:54:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3TAsfwe086155 for <ietf-pkix@imc.org>; Thu, 29 Apr 2004 03:54:42 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net) Received: from clbull.frcl.bull.fr (IDENT:root@clbull.frcl.bull.fr [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id NAA56876; Thu, 29 Apr 2004 13:03:46 +0200 Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id MAA12661; Thu, 29 Apr 2004 12:50:30 +0200 Message-ID: <4090DEE5.1030209@bull.net> Date: Thu, 29 Apr 2004 12:54:29 +0200 From: Denis Pinkas <Denis.Pinkas@bull.net> Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: Trevor Freeman <trevorf@exchange.microsoft.com> CC: ietf-pkix@imc.org Subject: Re: FW: scvp References: <33E7A1613A3480448996047B69308A2F02665D2A@df-grommit-01.dogfood> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Trevor, > Hi Denis, > Can you please be more specific how you think SCVP 14 does not comply > with 3379. > > I can find no section in 3379 where is there a requirement that a > validation policy MUST be represented as an OID. There cannot be a requirement with such a level of detail, but the text states: The protocol MUST allow the client to include these policy dependant parameters in the DPV request; however, it is expected that most clients will simply reference a validation policy for a given application or accept the DPV server's default validation policy. A simple reference is an OID. FYI, I do not expect to use the "default validation policy". Denis > Given hiding the detail of what a policy is within an OID simply opens > the rat hole of what change to the policy constitutes a change to the > OID, it is less ambiguous to refer to the primary data. Once you are in > the business of managing state on a client, then there is negligible > cost increase incurred in managing several data points vs. a singe data > point. > > Trevor > > -----Original Message----- > From: Denis Pinkas [mailto:Denis.Pinkas@bull.net] > Sent: Tuesday, April 27, 2004 11:01 AM > To: Trevor Freeman > Cc: ietf-pkix@imc.org > Subject: Re: FW: scvp > > Trevor, > > >>HI Denis, >>In SCVP13, the concept of validation policy was not completely in >>alignment with 3379 definition. > > > Well, it is different and this is a major problem. > > >>It also blurred the distinction between >>validation policy and validation algorithm. > > > This is also a majo problem. > > >>Therefore I have defined >>what each is in SCVP 14 and aligned the structures accordingly. >>Section 1.3 has the following. >>"In SCVP, the validation policy comprises of an algorithm for >>certificate path processing and the input parameters to the > > algorithm." > > This does not comply with RFC 3379. > > >>Therefore trust anchors are an input into the algorithm and therefore >>separate. > > > Therefore I do not follow you. > > From an interface point of view the simplest validation policy is > defined > by an OID where all the parameters necessary to perform the validation > check > are "behind" the OID. There is no need to provide any parameter through > the > interface. > > When there are some parameters, then they are specific to the validation > > policy. I have no problem to provide specific parameters for what is > called > the "default validation policy" which is only a particular validation > policy > among many others. > > Simple clients will be unable to pass any parameter but will know which > OIDs > (for the validation policy) are appropriate for their applications. > > Denis > > >>This is in alignment with 3379s definition of validation policy. >> >>Trevor >> >>-----Original Message----- >>From: Denis Pinkas [mailto:Denis.Pinkas@bull.net] >>Sent: Monday, April 26, 2004 1:09 AM >>To: Peter Sylvester >>Cc: ietf-pkix@imc.org; Trevor Freeman >>Subject: Re: FW: scvp >> >>Peter and Trevor, >> >>I have major problems too. >> >> >> >>>in version 13 the syntax for a Query has been changed from >>> >>> Query ::= SEQUENCE { >>> queriedCerts SEQUENCE SIZE (1..MAX) OF CertReference, >>> checks CertChecks, >>> wantBack WantBack, >>> serverContextInfo [0] OCTET STRING OPTIONAL, >>> valPolicy [1] ValidationPolicy OPTIONAL, >>> validityTime [2] GeneralizedTime OPTIONAL, >>> trustAnchors [3] TrustAnchors OPTIONAL, >>> intermediateCerts [4] CertBundle OPTIONAL, >>> revInfos [5] RevocationInfos OPTIONAL, >>> queryExtensions [6] Extensions OPTIONAL } >> >> >>In this structure trustAnchors was more or less an alternative to >>valPolicy. >> >>In fact, IF the valPolicy is the default policy, THEN additional >>parameters >>MUST be provided. So the structure below does not fit as well. >> >>This leads to have the two following elements: >> >> valPolicy ValidationPolicy, >> paramsDefValPolicy ParamsDefValPolicy OPTIONAL, >> >>where the first one is mandatory and the second one optional. >> >> >> >>>to >>> >>> Query ::= SEQUENCE { >>> queriedCerts SEQUENCE SIZE (1..MAX) OF CertReference, >> >> >>> checks CertChecks, >>> wantBack WantBack, >>> requestRefHash BOOLEAN DEFAULT TRUE, >>> includePolResponce BOOLEAN DEFAULT FALSE, >>> inhibitPolMap BOOLEAN DEFAULT FALSE, >>> requireExplicitPol BOOLEAN DEFAULT FALSE, >>> ignoreAnyPol BOOLEAN DEFAULT FALSE, >>> valAlgorithm ValidationAlgorithm, >>> serverContextInfo [0] OCTET STRING OPTIONAL, >>> validityTime [1] GeneralizedTime OPTIONAL, >>> trustAnchors [2] TrustAnchors OPTIONAL, >>> intermediateCerts [3] CertBundle OPTIONAL, >>> revInfos [4] RevocationInfos OPTIONAL, >>> queryExtensions [5] Extensions OPTIONAL } >> >> >>I would thus propose to have something like: >> >>Query ::= SEQUENCE { >> queriedCerts SEQUENCE SIZE (1..MAX) OF >>CertReference, >> checks CertChecks, >> wantBack WantBack, >> requestRefHash BOOLEAN DEFAULT TRUE, >> serverContextInfo OCTET STRING OPTIONAL, >> validityTime GeneralizedTime OPTIONAL, >> includePolResponse BOOLEAN DEFAULT FALSE, >> valPolicy ValidationPolicy, >> paramsDefValPolicy [0] ParamsDefValPolicy OPTIONAL, >> intermediateCerts [1] CertBundle OPTIONAL, >> revInfos [2] RevocationInfos OPTIONAL, >> queryExtensions [3] Extensions OPTIONAL } >> >>and then something like: >> >> ParamsDefValPolicy :: = SEQUENCE { >> trustAnchors TrustAnchors, >> endEntityCertificationPolicy SEQUENCE OF OBJECT IDENTIFIER >>OPTIONAL, >> inhibitPolMap BOOLEAN DEFAULT FALSE, >> caCertificationPolicies SEQUENCE OF OBJECT IDENTIFIER >>OPTIONAL } >> >>Denis >> >> >> >>>I am not sure whether I am the only person unable to construct a >> >>parser. >> >> >>>in version 14 an aditional flag has been added which is not available >> >>in the >> >> >>>Chapter 9. Is the isCA flag an orthogonal attribut to other validation >>>algorithms, or just to some of them, e.g,. the default name matching >> >>one? >> >> >>> Query ::= SEQUENCE { >>> queriedCerts SEQUENCE SIZE (1..MAX) OF CertReference, >> >> >>> checks CertChecks, >>> wantBack WantBack, >>> requestRefHash BOOLEAN DEFAULT TRUE, >>> includePolResponce BOOLEAN DEFAULT FALSE, >>> inhibitPolMap BOOLEAN DEFAULT FALSE, >>> requireExplicitPol BOOLEAN DEFAULT FALSE, >>> ignoreAnyPol BOOLEAN DEFAULT FALSE, >>> isCA BOOLEAN DEFAULT FALSE, >>> valAlgorithm ValidationAlgorithm, >>> serverContextInfo [0] OCTET STRING OPTIONAL, >>> validityTime [1] GeneralizedTime OPTIONAL, >>> trustAnchors [2] TrustAnchors OPTIONAL, >>> intermediateCerts [3] CertBundle OPTIONAL, >>> revInfos [4] RevocationInfos OPTIONAL, >>> keyUsage [5] KeyUsage OPTIONAL, >>> extendedKeyUsage [6] ExtKeyUsageSyntax OPTIONAL, >>> queryExtensions [7] Extensions OPTIONAL >>> producedAt [8] GeneralizedTime OPTIONAL} >>> >>> >> >> >> >> > > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3TAbc6m085280; Thu, 29 Apr 2004 03:37:38 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3TAbcdH085279; Thu, 29 Apr 2004 03:37:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3TAbabM085273 for <ietf-pkix@imc.org>; Thu, 29 Apr 2004 03:37:37 -0700 (PDT) (envelope-from Peter.Sylvester@edelweb.fr) Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id i3TAZmN14901; Thu, 29 Apr 2004 12:35:48 +0200 (MEST) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Thu, 29 Apr 2004 12:35:48 +0200 (MET DST) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i3TAZho04669; Thu, 29 Apr 2004 12:35:43 +0200 (MEST) Date: Thu, 29 Apr 2004 12:35:43 +0200 (MEST) From: Peter Sylvester <Peter.Sylvester@edelweb.fr> Message-Id: <200404291035.i3TAZho04669@chandon.edelweb.fr> To: Peter.Sylvester@edelweb.fr, trevorf@exchange.microsoft.com Subject: RE: FW: scvp Cc: ietf-pkix@imc.org X-Sun-Charset: US-ASCII Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> > Hi Peter, > A client could want to optimize the number of SCVP queries. As a SCVP > client if I just submit a query for the issuing CA rather than the EE, > its pretty simple to reuse that response across multiple validations. > Therefore the server can default to a behavior like validate as EE, but > the client needs to be able to override the default if necessary. This case seems to me tobe only one of many others. but even there, it is unclear to me whether it is orthogonal to validation algorithms? What is the meaning of valdidation of an ssl server, when the client doesn't give the server cert but only the ca cert? Should the server not test the DNS name? Depending on what criteria? On the setting of isCA? What if the client wants to test the ca cert that had issues the ca cert that had issued the ee cert. I suggest a rewriting the isCA paragraph may be in the following model: A client may want to indicate further details concerning the starting certifictae in a path (? for DPV, DPD?) - (1) whether the paths does not contain all parts, - (2) whether ... in order to indicate (1), the clients set the value of isCA to XXX. in order to indicate (2), the client ... or, it seems to me that currently you want: A client has the possibility to indicate that the cert to be validated is not the stating point in the path but the CA cert that has signed it. in order to do so, the client set the isCA boolean. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3SJJJMx037309; Wed, 28 Apr 2004 12:19:19 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3SJJJ4w037308; Wed, 28 Apr 2004 12:19:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from exchange.microsoft.com ([131.107.8.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3SJJICq037298 for <ietf-pkix@imc.org>; Wed, 28 Apr 2004 12:19:18 -0700 (PDT) (envelope-from trevorf@exchange.microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 28 Apr 2004 12:19:19 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 28 Apr 2004 12:19:19 -0700 Received: from DF-GROMMIT-01.mercury.corp.microsoft.com ([10.197.0.61]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 28 Apr 2004 12:19:18 -0700 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: FW: scvp Date: Wed, 28 Apr 2004 12:19:14 -0700 Message-ID: <33E7A1613A3480448996047B69308A2F02666168@df-grommit-01.dogfood> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FW: scvp thread-index: AcQtR8EnplUxC4UyTlWpVpzUV+r27AAC16hw From: "Trevor Freeman" <trevorf@exchange.microsoft.com> To: "Peter Sylvester" <Peter.Sylvester@edelweb.fr> Cc: <ietf-pkix@imc.org> X-OriginalArrivalTime: 28 Apr 2004 19:19:18.0876 (UTC) FILETIME=[B402A9C0:01C42D55] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i3SJJICq037302 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Hi Peter, A client could want to optimize the number of SCVP queries. As a SCVP client if I just submit a query for the issuing CA rather than the EE, its pretty simple to reuse that response across multiple validations. Therefore the server can default to a behavior like validate as EE, but the client needs to be able to override the default if necessary. OK, the tag thing is a bit of a surprise sine this was in SCVP13 as well. I will add tags to the query. I think the bit sting vs. enumerated list is a stylistic call. I personally prefer enumerated lists. Trevor -----Original Message----- From: Peter Sylvester [mailto:Peter.Sylvester@edelweb.fr] Sent: Wednesday, April 28, 2004 10:39 AM To: Peter.Sylvester@edelweb.fr; Trevor Freeman Cc: ietf-pkix@imc.org Subject: RE: FW: scvp link the two ... and (1) and (2) together. (1) ... but the syntax is ambiguous. You cannot parse: a BOOLEAN OPTIONAL, b BOOLEAN OPTIONAL, you need to add tags a BOOLEAN OPTIONAL, b [0] BOOLEAN OPTIONAL, > > 2. How about changing the isCA boolean to entityType where entityType is > an enumerated list. Absence means don't care. You can play with OPTIONAL instead of DEFAULT, which actually gives a three value possibility but it is somewhat ugly. Absense of 'Any' you cannot really name it 'Any' because in the 88 version this is a reserved word. But my question is not how to encode "this" but what is the actual intended meaning and maybe why this is an independant parameter and not as part of a validation algorithm for CAs. For any validation algorithm specified, I don't see why one would care whether the first element is a CA or not? I could understand a need to try to recursively go up a path for a particular validation algorithm, and then one needs to say that the cert is not the starting point of the path but an intermediate cert. For example, if the the ssl server validation algo is used, the first cert must contain, common name or subjectaltname and extendedkeyusage etc. but if one goes up in the path, nothing of that is in the cert, on the other hand, it may be part of the trust information to indicate whether the ac in question can be use to sign such types of end entity certs. Thus I am puzzled about the actual intention of having this field. Or, there is no defined combination of the meaning isCA + sslserver validation algorithm, at least not the interesting one as defined above. > > entityType ::= ENUMERATED { > Any (0), > endEntity (1), > certificateAuthority (2)} Another option was suggested by peter gutmann, use a name bitlist for all these things. The pb is that I don't see a useful case for the actual semantics (even with three options), but rather a potential need to indicate a partial path. You need to indicate a path length. one solution is an integer that indicates how many certificates in the path are not present, default 0 means that you have the complete beginning according to the validation algorithm, 1 means that you must test whether pathlen in basic contraints is at least 0 or missing. This is useful import for DPD: Give a CA cert with at least a pathlen of 1 that can be used to validate the given cert (the one of the intermediate CA). Sorry if I an unclear here. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3SHdChj030085; Wed, 28 Apr 2004 10:39:12 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3SHdCrb030084; Wed, 28 Apr 2004 10:39:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3SHdAH1030059 for <ietf-pkix@imc.org>; Wed, 28 Apr 2004 10:39:11 -0700 (PDT) (envelope-from Peter.Sylvester@edelweb.fr) Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id i3SHd8N04467; Wed, 28 Apr 2004 19:39:08 +0200 (MEST) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Wed, 28 Apr 2004 19:39:08 +0200 (MET DST) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i3SHd8C02674; Wed, 28 Apr 2004 19:39:08 +0200 (MEST) Date: Wed, 28 Apr 2004 19:39:08 +0200 (MEST) From: Peter Sylvester <Peter.Sylvester@edelweb.fr> Message-Id: <200404281739.i3SHd8C02674@chandon.edelweb.fr> To: Peter.Sylvester@edelweb.fr, trevorf@exchange.microsoft.com Subject: RE: FW: scvp Cc: ietf-pkix@imc.org X-Sun-Charset: US-ASCII Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> link the two ... and (1) and (2) together. (1) ... but the syntax is ambiguous. You cannot parse: a BOOLEAN OPTIONAL, b BOOLEAN OPTIONAL, you need to add tags a BOOLEAN OPTIONAL, b [0] BOOLEAN OPTIONAL, > > 2. How about changing the isCA boolean to entityType where entityType is > an enumerated list. Absence means don't care. You can play with OPTIONAL instead of DEFAULT, which actually gives a three value possibility but it is somewhat ugly. Absense of 'Any' you cannot really name it 'Any' because in the 88 version this is a reserved word. But my question is not how to encode "this" but what is the actual intended meaning and maybe why this is an independant parameter and not as part of a validation algorithm for CAs. For any validation algorithm specified, I don't see why one would care whether the first element is a CA or not? I could understand a need to try to recursively go up a path for a particular validation algorithm, and then one needs to say that the cert is not the starting point of the path but an intermediate cert. For example, if the the ssl server validation algo is used, the first cert must contain, common name or subjectaltname and extendedkeyusage etc. but if one goes up in the path, nothing of that is in the cert, on the other hand, it may be part of the trust information to indicate whether the ac in question can be use to sign such types of end entity certs. Thus I am puzzled about the actual intention of having this field. Or, there is no defined combination of the meaning isCA + sslserver validation algorithm, at least not the interesting one as defined above. > > entityType ::= ENUMERATED { > Any (0), > endEntity (1), > certificateAuthority (2)} Another option was suggested by peter gutmann, use a name bitlist for all these things. The pb is that I don't see a useful case for the actual semantics (even with three options), but rather a potential need to indicate a partial path. You need to indicate a path length. one solution is an integer that indicates how many certificates in the path are not present, default 0 means that you have the complete beginning according to the validation algorithm, 1 means that you must test whether pathlen in basic contraints is at least 0 or missing. This is useful import for DPD: Give a CA cert with at least a pathlen of 1 that can be used to validate the given cert (the one of the intermediate CA). Sorry if I an unclear here. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3SH0D7K025180; Wed, 28 Apr 2004 10:00:13 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3SH0DJD025179; Wed, 28 Apr 2004 10:00:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from exchange.microsoft.com ([131.107.8.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3SH0COg025168 for <ietf-pkix@imc.org>; Wed, 28 Apr 2004 10:00:12 -0700 (PDT) (envelope-from trevorf@exchange.microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 28 Apr 2004 10:00:10 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 28 Apr 2004 10:00:10 -0700 Received: from DF-GROMMIT-01.mercury.corp.microsoft.com ([10.197.0.61]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 28 Apr 2004 10:00:10 -0700 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: FW: scvp Date: Wed, 28 Apr 2004 10:00:09 -0700 Message-ID: <33E7A1613A3480448996047B69308A2F02666081@df-grommit-01.dogfood> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FW: scvp thread-index: AcQs+OvTsP9qUwY0S4C7PgahxCNVsAAR/NUg From: "Trevor Freeman" <trevorf@exchange.microsoft.com> To: "Peter Sylvester" <Peter.Sylvester@edelweb.fr> Cc: <ietf-pkix@imc.org> X-OriginalArrivalTime: 28 Apr 2004 17:00:10.0496 (UTC) FILETIME=[43FCF800:01C42D42] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i3SH0COg025174 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Hi Peter, What part of 1 are you referring to, the core 3280 parameters or the parameters which are used over and above 3280? 2. How about changing the isCA boolean to entityType where entityType is an enumerated list. Absence means don't care. entityType ::= ENUMERATED { Any (0), endEntity (1), certificateAuthority (2)} Trevor -----Original Message----- From: Peter Sylvester [mailto:Peter.Sylvester@edelweb.fr] Sent: Wednesday, April 28, 2004 1:15 AM To: Peter.Sylvester@edelweb.fr; Trevor Freeman Cc: ietf-pkix@imc.org Subject: RE: FW: scvp > Hi Peter, > The additions optional allow the client to specify in the request the > full range validation parameters defined in 3280 section 6. If you read > section 1, you will see a validation policy is the validation algorithm > plus the input parameter to the algorithm. SCVP14 defines all the base > inputs as defined in 3280. New validation algorithm cab define > additional input variable. I saw the need for these parameters, but ... (1) > The only other parameter you mention refers to Basic constraints, so if > a SCVP client want to validate what it believes is a CA certificate, > then it passes in CA=true. That's not what the spec says ... (2) > > I am not sure whether I am the only person unable to construct a parser. (1) ... the syntax in umbiguous. > in version 14 an aditional flag has been added which is not available in > the > Chapter 9. Is the isCA flag an orthogonal attribut to other validation > algorithms, or just to some of them, e.g,. the default name matching > one? (2) ... there is no option saying client doesn't care whether the cert is a CA or EE. I am not sure whether one needs three options, or, for example: "If set to TRUE, the caller requires a CA, otherwise, the caller doesn't care." Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3SDusri011448; Wed, 28 Apr 2004 06:56:54 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3SDusa0011447; Wed, 28 Apr 2004 06:56:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3SDurOx011435 for <ietf-pkix@imc.org>; Wed, 28 Apr 2004 06:56:53 -0700 (PDT) (envelope-from Steve.Hanna@Sun.COM) Received: from phys-bur1-1 ([129.148.13.15]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i3SDuoms028162 for <ietf-pkix@imc.org>; Wed, 28 Apr 2004 06:56:50 -0700 (PDT) Received: from conversion-daemon.bur-mail2.east.sun.com by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) id <0HWV00A01VUSUG@bur-mail2.east.sun.com> for ietf-pkix@imc.org; Wed, 28 Apr 2004 09:56:50 -0400 (EDT) Received: from sun.com (dhcp-ubur02-75-154.East.Sun.COM [129.148.75.154]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPA id <0HWV00FZUW2QMI@bur-mail2.east.sun.com> for ietf-pkix@imc.org; Wed, 28 Apr 2004 09:56:50 -0400 (EDT) Date: Wed, 28 Apr 2004 09:53:31 -0400 From: Steve Hanna <Steve.Hanna@Sun.COM> Subject: Comments on Path Building I-D To: PKIX List <ietf-pkix@imc.org> Message-id: <408FB75B.50108@sun.com> MIME-version: 1.0 Content-type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary=------------ms020703040003000503010505 X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20031111 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> --------------ms020703040003000503010505 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Here are my comments on draft-ietf-pkix-certpathbuild-03.txt. I suspect that these will come off sounding negative. I'm sorry about that. I'm glad we have this document and I hope it will progress in a modified form, but I have some serious problems with the document as it now stands. I also apologize for the length of these comments. I wanted to do a careful review of the document and there are a lot of problem areas (although some are minor). The fact that nobody else has commented on these leads me to suspect that nobody except the authors and myself has carefully reviewed the document. Can anyone refute that suspicion? Thanks, Steve -------- Overall Comments: * My main overall comment is the one I made last July. There is not consensus on path building techniques in the PKIX working group or the IETF. Why? Because we don't understand the problem thoroughly yet. In this document, you advocate depth first search and suggest that building forward is usually best. I don't think you have carefully considered a wide variety of other algorithms like breadth first search, meet in the middle, etc. Can you show me any solid evidence that shows your algorithms are better than the alternatives? I doubt that you have any such proof. In fact, it seems clear to me that depth first search is a poor algorithm for building cert paths. I say this as a person who has implemented that algorithm myself and regretted it. The problem is that if you make a wrong choice, you must completely explore that part of the PKI before you consider backing out and trying other options. I have heard stories of path building taking 35 minutes or more when there was a valid short path because the builder used DFS and headed down the wrong path. We need to do our homework before making any solid recommendations to implementers. I suppose it's better to have some advice than none, but this document should have a prominent warning that these techniques are experimental. In fact, we might want to give the RFC Experimental status. As I've suggested before, I want to see a careful analysis of different path building strategies. Theoretical analysis will probably be useful, but I expect it will also be useful to compare real-world performance with a variety of topologies (some from real-world deployments, some looking at possible futures like many cross-certified bridges). We need to try out a lot of ideas without getting committed to any too early. The cert path building panel at the PKI R&D Workshop this year was a good start, but we need to do more in-depth work. I've started talking to some other researchers about this. I hope that this documents' authors will join this effort. Their experience and aid will be valuable. * At several places in the document, you refer to the "authors' opinions". If this was truly a working group document, it would reflect the consensus of the working group, not the opinions of the authors. As I said before, I don't see working group consensus on this topic. Has anyone other than me (and maybe the authors) carefully reviewed the current draft? I haven't seen any comments on it during Last Call. Since this document does not reflect working group consensus, I do not think it should go forward as a working group draft. It should be an individual submission. But I suppose once it becomes an RFC nobody will ever know whether it was a working group submission or not. And I really do think it's useful to have some guidance on cert path building (even if we don't understand the problem very well). So I'd be OK with having it be a working group submission if it goes to Experimental status and a caveat is added at the beginning warning that this is only the authors' opinion (albeit an educated opinion) and that further study is under way to determine which techniques are actually preferred. * You should include in this document a section with guidance to PKI designers about what they can do to make path building easier. Here are some ideas: Use a simple topology (hierarchical with one root), when possible. Include AIA, SIA, and CRLDP extensions in certificates. Make certificates (especially CA certificates) and CRLs easily available by LDAP and HTTP, populating both sides of the crossCertificatePair attribute. Use name constraints and policy constraints whenever possible, especially at high fanout points like bridges. Avoid having more than two high fanout CAs (at most) between any two points, if possible. * I have a *serious* objection to the idea that someone is going to specially configure path building software for a particular PKI environment (as I think you imply at the end of section 2.3, early in section 3.4, and in a few other places). This is not practical. Most organizations do not have a PKI wizard on staff (especially a path building wizard). The path building software must just work, automatically. If we can't do that, PKI will never be widely used (at least, not in a non-hierarchical topology). Fortunately, I see no reason why we need special configuration. With AIA and SIA and CRLDP and some good algorithms, we should be able to build paths just fine in almost any PKI without any configuration. Substantive Comments: * Section 1.2 (Purpose) says "... this document suggests using ... depth first tree traversal. ... Other approaches (e.g., building complete spanning trees of the PKI.) exist and may be shown to be more effective under certain conditions." Building a complete spanning tree of the PKI is not a decent solution. Please change this to something more reasonable, like breadth first search. Otherwise, you're just setting up a straw man, an impractical alternative. * In section 1.4.1, you mention one disadvantage of the trust list approach. You might want to mention the problem that compromise of any trusted certificate compromises the entire system. * In section 1.4.2, you say that a partial mesh is a mixture of unidirectional and bidirectional cross-certifications. It's probably also important to note that in a partial mesh there may be CAs that are not directly cross-certified at all. * What is a Root CA doing in Figure 3? As you say, each EE in a mesh usually trusts the CA that issued its certificate. Because of this Root CA, Figure 3 does not depict a full mesh, as stated in 1.4.2. I suggest that you remove the Root CA. * At the end of section 1.4.3, you raise the concern that the assurance of a high-assurance PKI may be diluted by cross-certifying with a less restrictive PKI. If you're going to raise this concern, you should mention that it can be addressed through the use of certificate policies. * At the end of section 1.4.4, you say that connecting PKIs with a bridge results in a non-hierarchical PKI. Certainly, this is true. But mesh and hybrid PKIs are not hierarchical either. Why raise this here? And the following sentence which states that any PKI can be considered hierarchical from the right perspective only applies if you remove and duplicate links in the PKI. Since you don't have space to get into this here, I suggest you remove those last two sentences. * At the end of the first paragraph of section 2.1, you explain that S/MIME messages commonly include certificates. I think you would be wise to also mention SSL/TLS since this is the most widespread use of PKI and it also supplies certificates in the protocol. * Before Figure 6, you explain how certificates are depicted with arrows in your figures. You should also explain the "B(A)" notation you use. * At the end of the paragraph after Figure 6, you say that building paths is as important as validating them. I don't agree. Many products have been shipping for years and work just fine without building. In a complex PKI, building is important. But in a simple hierarchical PKI, it's not. * At the end of section 2.1, you have a large discussion of why you believe building forward is usually better. This duplicates later discussions on this topic. I suggest you save this for later. * In section 2.2, you could simplify and clarify Criterion 1 by changing it from this: Criterion 1: The implementation is able to find all possible paths. By this, it is meant that all possible certification paths between the trust anchor and the target certificate which may be valid paths can be built by the algorithm. to this: Criterion 1: The implementation is able to find all possible paths. By this, it is meant that all valid certification paths between the trust anchor and the target certificate can be built by the algorithm. * In section 2.2, Criterion 2 seems rather odd. Who cares which invalid paths you build first? The important thing is how quickly and efficiently you can build a valid path or determine that no valid path exists. * In section 2.3, you say that because certificates are not permitted to repeat, every potentially valid path has a terminus. But every potentially valid path *always* has a terminus, even if certificates are allowed to repeat. As defined in RFC 3280, a certification path is a collection of n certificates. Every path has a finite number of certificates. I suggest you remove the sentence "As a result, every potential valid path has a terminus, a leaf on the tree." * In the following paragraph, you say that removing and duplicating nodes and links in a PKI to turn it into a hierarchy greatly simplifies software design. This may be so, but it also removes many opportunities for insight and optimization. For example, it increases the number of nodes in the data structure and makes it harder to mark a certain area of the PKI as unproductive (since that area may appear several places in the tree). * Later in that paragraph, you use the phrase "decision tree" without defining it. I suggest that you define it in section 1.3. * One paragraph on page 16 (starting with "A more complicated example") talks about problems with building in the reverse direction when there are many trust anchors. The real issue here is fanout. Whether you're building forward or building reverse, it's bad news when you get to a point where you have several choices. It's especially bad if your heuristics (ranking) don't give you much help in deciding which way to go. And it's even worse if you're using depth-first search, since one wrong move can send you off in the wrong direction for hours. That's why I suggest breadth first search or (even better) ranking all candidates at all points in the tree at each decision time. Four trust anchors is a four-way fanout. A similar situation would arise if you were building forward and arrived at a CA that has four certificates with it as the subject. In either case, you hope that your ranking will help choose the right path. And if you're using depth first search, you really hope that you don't take a wrong turn. One technique for dealing with extreme fanout with fairly equal rankings is to start building from the other end. Another is to rank the certs at the fanout point low and try another branch. A third is to use DPD to get help. And a fourth is to tell PKI designers to use name constraints and other techniques at high fanout points (like bridges) to help path building succeed. I hope that you find this analysis useful. * In Figure 10, are W, X, Y, and Z all trust anchors? I think so. That's pretty odd. Why would a relying party have all four of those trust anchors? Who needs the bridge CA in that case? I suspect that this topology was created to support your arguments that repeating a (name, key) pair is bad and that building in reverse is bad. If so, I think you can do better. Let's do a careful theoretical analysis and try out different algorithms on different topologies. I suspect you're right that repeating a (name, key) pair is bad but we need to think about this carefully since it is a significant change to RFC 3280. I think you will see below that building in reverse is a useful tool that should be used in conjunction with building forward. But we need to show the merits of our approaches through analysis, not by consructing topologies that serve our own purposes. * In the paragraph after Figure 10, you have several sentences explaining the diagram's notation. This was explained much earlier. The rest of the paragraph (explaining where certificates would be stored in an LDAP directory) also duplicates material found elsewhere. I suggest that you remove these, since the document is already too long. * In section 2.4.2, you seem to be proposing that software should build a decision tree. I believe you don't intend for the software to actually build a tree for the entire PKI but only to move incrementally through the PKI adding nodes and links to the tree as needed. I hope that's the case, anyway. Otherwise, you'd need to download all certs in the PKI! If I'm right, you need to be much clearer about this. I could easily imagine a developer writing code that actually builds the tree. That code would work fine in a small test PKI but flood the directory with requests and then die in a large PKI. * After Figure 11, you point out that building in reverse is not good in this case. Sure. The EE is in a simple hierarchy. Of course, building forward is best there. If you don't know the topology (especially if you have several trust anchors), starting with forward is fine. Then you can switch or meet in the middle if things get hairy. * In section 2.6, you say "[...] the path builder only needs to store the current location in the tree [...] All completed branches can be discarded from memory [...]". Maybe. There's a lot to be said for retaining records of paths you have already tried and rejected. Then you can avoid retrying them at a different point in the graph (unless conditions are sufficiently different to merit a retry). * Later in section 2.6, you say "Consider HTTPS support" for CRLDP and AIA. Why would this be valuable? You're retrieving signed data. Using HTTPS may trigger another path build, maybe even a loop where one build triggers another which triggers another and so on. I suppose some repositories may require HTTPS to authenticate the client or protect the certs from prying eyes. But you should probably warn that doing so may be expensive and that implementers should protect against loops. * Toward the end of section 2.6, you talk about the path cache. You call for "a configurable expiration date for each entry". Who would configure the date and why? I'm a path building geek and I can't imagine configuring such a thing! * A few sentences later, you suggest storing issuer-subject cert relationships. If you want to do this, I suggest that you use a cert hash instead of an (issuer, serial) tuple. Issuer, serial is *not* always unique, especially across multiple PKIs or when one CA is malicious (and remember that some CAs are only partly trusted in a modern PKI). * In section 2.7.1, you talk about the required inputs. Instead of supplying the actual Target Certificate, it is sometimes useful to provide criteria that describe what sorts of target certificates you're willing to accept. For instance, when doing S/MIME encryption to a new correspondent you may not have the correspondent's encryption certificate. The path building software can help find it if you tell it what you need. * In section 3.2, you recommend that path building software output a detailed log. I think you should recommend that this log be carefully structured so that the paths tried can be easily reconstructed by a diagnostic program. My team built a tool that shows the cert graph and then replays the paths our builder tried, lighting up each one in sequence. We found this a great help in understanding the behavior of our software (finding bugs, improving algorithms, etc.). It's also a very cool way to demo path building, which otherwise is a pretty boring demo ("see, there's the web page!"). * Later in that paragraph, you say "Ideally, there would be a mechanism for turning this logging on and off [...]". I'd change this to "There should be [...]". Logging is expensive (in storage and CPU time), especially for path building where you commonly try hundreds of certificates or more to create a valid path. You really need a way to turn logging off and on. * A few paragraphs later, you say "it may be useful to not rule out any paths" and just return each path as its built, even if it's invalid. The problem with this is that (especially with a depth first search) is that there are many topologies that may cause you to wander among many invalid paths. Why is this technique good? You say it will "provid[e] a more rapid response to the caller than one which builds all possible paths." Maybe. I suspect you'll instead waste time by spending a lot of time returning invalid paths to the caller. I don't see much reason to return invalid paths except in a diagnostic log or for your interesting idea of providing one path that's *mostly* valid for debugging and in case the caller finds that invalid path educational or compelling. * A few paragraphs later, you lay out your approach. Here are some comments on it: You say "Do not check revocation status if it requires a directory lookup or network access." Why not start the revocation check and let it run in parallel while you do other things (like checking certs deeper in the graph)? That way, you'll have the revocation check done when you need it. And if the check fails you can abort all work that was based on the validity of that certificate. Of course, you'll want to cache the revocation status of certificates for some time. You say "Do not check digital signatures". Again, why not run this in parallel? Most of path building time (about 90%, based on our data) is spent waiting for the network (while downloading certificates and such). That's an ideal time to be checking signatures. And, of course, you'll want to cache the results of signature checks. You say "Do not check anything that can not be checked as part of the iterative process of traversing the tree." Why not? I expect you would want to run these final checks (like full policy processing when building forward) before returning the path to the caller. Otherwise, the caller will need to run a complete validation of the path, which will take much more time than just running these last few checks. * In the last paragraph of 3.2, you say "Second, it is fairly uncommon in typical application environments to encounter a revoked key; therefore, most certificates validated will not be revoked." In a PKI, we don't revoke a key. We revoke a certificate. Therefore, this sentence should read "Second, it is fairly uncommon in typical application environments to encounter a revoked certificate." * Why include section 3.3 at all? It's very odd to have an IETF spec talking about internal data structures. Maybe you should just give everyone a copy of your code (since it is apparently ideal) and save them the trouble of implementing it! I'm going to skip my more detailed comments on this section since I think it should be entirely removed. * In section 3.4, you refer say "developers should evaluate each method with respect to the environment that the application will operate, and assign weights to each accordingly in the path building software.". First, the word "that" in this sentence should be "in which". Second, this is a prime example of the awful idea that developers must examine each PKI and configure their software to run optimally there. * In section 3.5.1, you say "According to [RFC 3280], basicConstraints is required to be present with cA=TRUE in all CA certificates." Actually, section 6.1.4 (k) of RFC 3280 says "Verify that the certificate is a CA certificate (as specified in a basicConstraints extension or as verified out-of-band)." Maybe your software doesn't make any provision for out-of-band indication of CA certificates, but you should probably at least note the possibility that other software may do so. * In section 3.5.5, you say "Certificates in the path cache have been validated previously. There is some probability that the path from that certificate to a trust anchor is still valid." The path may still be valid but it may contain constraints that are inconsistent with the path from the Target Certificate to this certificate. You should probably note that possibility. * In section 3.5.6, you say that the Previously Verified Signatures sorting method doesn't apply when building in reverse. Actually, it does. Your analysis is incorrect. This method never tells you which way the Target or Trust Anchor is (which certificate is most likely). It only lets you rule out certificates because the signature check would certainly fail. * In section 3.5.7, you say the Path Length Constraints sorting method "may be applied in reverse, but the benefit is likely less than that of the forward direction". Why? You can argue that the method is more effective when building in reverse because path length constraints often appear close to trust anchors. * In section 3.5.8, you say "Certificates that contain nameConstraints that would be violated by certificates already in the path to this point are given lower priority (or perhaps eliminated)." They should definitely be eliminated. You know they can't be used to build a valid path, so what's the point (unless you're working on building an invalid path)? * In section 3.5.9, you say "While this is viable, the signature verifications required make it less attractive as an elimination method." Usually, a CRL check only requires one signature verification so "verification" should be singular. You also say "It is suggested that this method only be used for sorting and that CRLs are validated post path building." As I noted above, fetching CRLs and performing signature checks can be done in parallel with other work. It's a good idea to do this so that you can discover revoked certs before you have invested too much time in them (and also so that you have the results of the revocation check ASAP). You should also probably change this section to include discussion of OCSP. Right now, it's very focussed on CRLs. * Here's a sorting method similar to the "Issuer Found in the Path Cache" method, but better suited to building in reverse. Check whether the subject of the candidate certificate matches the issuer of a certificate sent by the target (in SSL/TLS, S/MIME, etc.). If so, then the candidate certificate should be ranked more highly because it is more likely to lead to a path to the Target Certificate. You may also want to do RDN Matching (as in 3.5.15) with the certificates sent by the target. * In section 3.5.15 (on RDN matching), you say "Additionally, it should be noted that this method can require a lot of processing if many trust anchors are present." Actually, this should only require a few hash table lookups (of the RDNs). * Section 3.5.18 could be clearer. I think you're saying that the subject and issuer of the candidate certificate should have lots of RDNs in common. But this could be understood to be saying that the subject of the candidate certificate should have lots of RDNs in common with the issuer of the next certificate. Of course, they must match exactly so that can't be what you're saying. But it would help if this section was more explicit. * Section 3.5.19 also should be clarified. The description of the reverse method is much clearer than that of the forward method. I suggest that you replace the forward method language with language based on the reverse method language. One change to the reverse method language, though. Instead of saying "If an entity named by a reverse certificate", say "If the subject of a certificate". There's no such thing as a "reverse certificate". Note also that just because you find a name in the certificate cache, that doesn't mean you have the right certificates. There may be several different CAs with the same name. Also, you may now have more clues (like AIA and SIA) for finding certificates than you had before. You should be sure to pursue any such new clues. * In the Justification for 3.5.19, you say "The presence of required directory values populated in the cache increases the likelihood that all the required certificates and CRLs needed to complete the path from this certificate to the trust anchor (or target if building in reverse) are present in the cache from a prior path being developed [...]". That's fine, but you might also want to keep the actual path previously developed and look at that as a prime candidate for the path this time. * In section 3.5.20, you use the presence of a CRL in the CRL cache to indicate whether a complete path through a CA has previously been found. This is rather indirect. It would be better to actually track which certs have been previously included in valid paths. Keeping a copy of the path would also be quite useful. * The discussion of Forward Policy Chaining in section 4 overstates the benefits of policy checks when building in the forward direction. We should discuss this more. * In section 5.2, you suggest that each name/key pair only be allowed to appear once in a path. Since there is no such requirement in X.509 or RFC 3280, this would violate Criterion 1 as stated in section 2.2. You would miss some valid paths. * In section 6 (Retrieval Methods), you should mention getting certificates and CRLs from the target (with S/MIME or SSL/TLS, for instance). That's a *great* way to get certificates and CRLs. The ones you get are usually highly valuable. * Sections 6.2 and 6.3 should include text that encourages implementers to support AIA and SIA, especially HTTP. This text from the end of section 6.4 could easily be adapted: However, implementers of path building and validation modules are strongly encouraged to support CRLDPs. At a minimum, developers are encouraged to consider supporting the LDAP and HTTP transports; this will provide for interoperability across a wide range of existing PKIs. * In section 7, you should talk about prefetching and parallel fetching. Both are good ways to improve the performance of a cert path building implementation. * In section 7.1, you say "Certificate processing systems can cache data retrieved from external sources for some period of time, but not to exceed the useful period of the data (i.e., an expired certificate need not be cached)." CRLs are often issued well before the nextUpdate of the previous CRL. Could you mention this and suggest that implementers check periodically for updated CRLs? Similarly, crossCertificatePairs may be updated on an unpredictable basis. If you don't check back every so often, you'll never know that a new cross certificate is available! * The last bullet in section 7.1 offers a few suggestions for other things to cache. I'd add to that list previously built paths and partial paths. If the cache is safe from unauthorized modifications (as with an in-memory cache), you may also want to cache validation and signature check status for certificates and CRLs. * In section 7.2 (Retrieval Order), you may want to consider checking repositories in parallel instead of serially. Also, you might want to run ahead with your path building and validation while a network query is ongoing. Maybe you can build and validate the path with just the certificates and CRLs you have already (thus eliminating the need to wait for the network query to complete). Anything to get the answer to the user more quickly! * In section 8.1, you should probably add a statement that path building can be used as a denial of service attack. Make a series of simple requests to a server and cause it to do a bunch of long path builds. To avoid this, the server can limit the amount of resources it's willing to devote to a path build. This amount can be reduced when the load is heavy. And standard DOS protections like identifying attackers can be employed. * Section 8.2 goes way beyond RFC 3280 and X.509. I know that Santosh is working on getting this into X.509 and the successor to RFC 3280. I'll debate the specifics of his proposal in that context. But for this document, I think you should be careful to explain that this goes beyond the standards. If you implement it, you will violate Criterion 1 from section 2.2. Maybe the best thing to do is to just briefly point out that there's an issue here and it's under discussion in the standards groups. Once it's settled there, this document can be revised to reflect whatever's agreed on. Minor Comments: * The first paragraph of section 2 says "... guidance is provided on the capabilities path building implementations required in order to ...". I think you want "require" or (maybe better due to RFC 2119) "need" instead of "required". * Just below Figure 6, "the certificates cannot be validated" should be "certificates cannot be validated". You're not referring to any particular certificates, just certificates in general. * In the paragraph after that, you should say "the crossCertificatePair attribute" instead of "the cross certificates". Otherwise, it's not clear what you mean. * In the second paragraph of section 3.2, you say a certificate "may appear again on another point in the tree". That should be "at another point in the tree". * At the end of section 3.4, "The list" should be "the list". * In section 3.5.17, there are two typos. "it priority" should be "it has priority". "will not successfully" (in the last paragraph) should be "will not verify successfully". * In section 5.4, you say certificates "will be" required to use UTF-8 after January 1, 2004. This should now be changed to "are". * In section 6, the first sentence should mention CRLs also. I suggest that the second sentence say "obtaining these certificates and CRLs" instead of "performing this retrieval", since retrieval has not yet been mentioned and sometimes the certificates can be obtained without having to be retrieved (as when the EE sends them in SSL). * In section 6.1, the description of userCertificate should probably say that it "contains certificates issued by one or more certification authorities with a subject DN that matches that of the directory entry". Also, there's an extra period at the end of the parenthetical comment later in the paragraph. * Later in section 6.1, the description of issuedByThisCA should say it contains certificates issued to *other* CAs. And there's an extra comma after "If both elements are present" (later in that paragraph). Why include that sentence anyway. The relying party doesn't need to enforce this requirement. People may think they need to do so. * In section 6.2, you say "AIA may be used to retrieve one or more certificates for entities that issued the certificate containing the AIA extension." I think it would be clearer to say "the CA" instead of "entities". * At the end of the first paragraph of section 6.3, "AIA" appears twice where it should be "SIA". * In section 6.4, you say "the CRL(s) to which the CRLDP(s) refer is the CRL that would contain revocation information for the certificate." I'd say instead "the CRL(s) to which the CRLDP refers are generally the CRLs that would contain revocation information for the certificate." Why? Because a CRLDP may refer an LDAP directory entry that contains many CRLs. Some of them may not pertain to this certificate. And of course there's usually only one CRLDP in a certificate. * In section 8.2, "q CRL Signer" should be "a CRL Signer". * In the Informative References, you include "[MINHPKIS]" but it's never actually referred to anywhere in the document. Similarly for [X.501] and [X.520]. You should probably remove those references. If you're going to retain them for some reason, please provide a decent reference for [MINHPKIS]: publisher, publication date. --------------ms020703040003000503010505 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJNzCC AvYwggJfoAMCAQICAwwtVDANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwNDIyMTY1MzA4WhcNMDUwNDIyMTY1MzA4 WjBoMQ4wDAYDVQQEEwVIYW5uYTEVMBMGA1UEKhMMU3RlcGhlbiBSb3NzMRswGQYDVQQDExJT dGVwaGVuIFJvc3MgSGFubmExIjAgBgkqhkiG9w0BCQEWE3N0ZXZlLmhhbm5hQHN1bi5jb20w ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDmIw2r4VrFAZJwvd0PPdpDfEVxnecb FpJWCNqdFG/wqFDBnpRHxFj114xtSLjPvSGAGKUAMtVVYZajgCGMyEOo3Q9GuYLQuldyzd9o nrnirn+qk2pz8kXMgNMGqs0YCsKJT7ULsObtCFY+YpSCENf/lzvr/p3No618ARy30X16Q0vl vbYS0aViehtkBe5/z+t6cTEVm4nN+JKZroRsRfrlDdM2k0/f2hj8jsBN4B5fdB0WluuJVyzu ePEHRH78KKlsX6H4S5sLND35xw+0rqLACsEvZDUxtIELrwoARlVBzvimi8Lb6BfcmVQiMdpa WKb63wzFfW9nvn7ZmPxxR0gvAgMBAAGjMDAuMB4GA1UdEQQXMBWBE3N0ZXZlLmhhbm5hQHN1 bi5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQABOxvvuAEld+aDU7egH3J5 r9NHc3jN3bkp6ozifPRZI+nGVKfcnKEa/Hai1x/QepKaD8FD7SZ3dXDEBhiS+OoZzcekDvpA fh3f37JeWS7uoZt07b46UeC6s5KsX2Vecb7yrPyBm+33+uic6zE4vfWwpyarEvk8G7BgzGhm MICTnzCCAvYwggJfoAMCAQICAwwtVDANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTEl MCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwNDIyMTY1MzA4WhcNMDUwNDIy MTY1MzA4WjBoMQ4wDAYDVQQEEwVIYW5uYTEVMBMGA1UEKhMMU3RlcGhlbiBSb3NzMRswGQYD VQQDExJTdGVwaGVuIFJvc3MgSGFubmExIjAgBgkqhkiG9w0BCQEWE3N0ZXZlLmhhbm5hQHN1 bi5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDmIw2r4VrFAZJwvd0PPdpD fEVxnecbFpJWCNqdFG/wqFDBnpRHxFj114xtSLjPvSGAGKUAMtVVYZajgCGMyEOo3Q9GuYLQ uldyzd9onrnirn+qk2pz8kXMgNMGqs0YCsKJT7ULsObtCFY+YpSCENf/lzvr/p3No618ARy3 0X16Q0vlvbYS0aViehtkBe5/z+t6cTEVm4nN+JKZroRsRfrlDdM2k0/f2hj8jsBN4B5fdB0W luuJVyzuePEHRH78KKlsX6H4S5sLND35xw+0rqLACsEvZDUxtIELrwoARlVBzvimi8Lb6Bfc mVQiMdpaWKb63wzFfW9nvn7ZmPxxR0gvAgMBAAGjMDAuMB4GA1UdEQQXMBWBE3N0ZXZlLmhh bm5hQHN1bi5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQABOxvvuAEld+aD U7egH3J5r9NHc3jN3bkp6ozifPRZI+nGVKfcnKEa/Hai1x/QepKaD8FD7SZ3dXDEBhiS+OoZ zcekDvpAfh3f37JeWS7uoZt07b46UeC6s5KsX2Vecb7yrPyBm+33+uic6zE4vfWwpyarEvk8 G7BgzGhmMICTnzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYT AlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UE ChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqG SIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBa Fw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRw nd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn 8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJg t/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0 dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1Ud DwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJ KoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A 9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH 1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggM7MIIDNwIBATBpMGIxCzAJ BgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYD VQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDDC1UMAkGBSsOAwIa BQCgggGnMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDQy ODEzNTMzMVowIwYJKoZIhvcNAQkEMRYEFNTe30Bo2AlEPISxuoti1VuWiXH6MFIGCSqGSIb3 DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcG BSsOAwIHMA0GCCqGSIb3DQMCAgEoMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMMLVQwegYLKoZIhvcNAQkQAgsxa6Bp MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQu MSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDDC1UMA0G CSqGSIb3DQEBAQUABIIBABCuV9Yq2J5tOMp2/HM/H6MhaLPY9J2xoXLOSHo8BiUW0JspvhLl iE5oFmT6857tV09m05x324JcpYBYwpkG5yMpcCGkxJoE45gnDZvMvnNLQy6zv1yT96Xbfqmw kyc9jmPIYrvrF2O8zCEornyWjOj33mai4mpOTah/oeykHa6NftHXlzc+r+ZzMAzDwYnv73Uz KGpwSV6EV5RgdsRk4sNLSN3N8z/HcTfDOXsRIA4A4Vl2jtv61yKflX1KEJnams1uMx+e137S mIjNd/NDXYfMcWpGPST+Cz/TaFv9hkeuq8bvcWaL/24Jeg9Rk56ruS4B+zhYbzCNyuEDlvgg 95UAAAAAAAA= --------------ms020703040003000503010505-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3SA34cC093341; Wed, 28 Apr 2004 03:03:04 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3SA334Q093338; Wed, 28 Apr 2004 03:03:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3SA31Ov093320 for <ietf-pkix@imc.org>; Wed, 28 Apr 2004 03:03:02 -0700 (PDT) (envelope-from Peter.Sylvester@edelweb.fr) Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id i3SA31N28180; Wed, 28 Apr 2004 12:03:01 +0200 (MEST) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Wed, 28 Apr 2004 12:03:01 +0200 (MET DST) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i3SA31101483; Wed, 28 Apr 2004 12:03:01 +0200 (MEST) Date: Wed, 28 Apr 2004 12:03:01 +0200 (MEST) From: Peter Sylvester <Peter.Sylvester@edelweb.fr> Message-Id: <200404281003.i3SA31101483@chandon.edelweb.fr> To: Peter.Sylvester@edelweb.fr, Denis.Pinkas@bull.net Subject: Re: FW: scvp Cc: ietf-pkix@imc.org X-Sun-Charset: US-ASCII Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> > > The issuer of the OID will have to provide the full definition. If there are > some parameters (which is not mandatory at all), then it will define the > ASN.1 syntax, and then you will be able to compile it. > What about semantics? It is not just a question of ASN1 structure compilation. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3S9U7g7084505; Wed, 28 Apr 2004 02:30:07 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3S9U715084504; Wed, 28 Apr 2004 02:30:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3S9U54S084483 for <ietf-pkix@imc.org>; Wed, 28 Apr 2004 02:30:06 -0700 (PDT) (envelope-from Peter.Sylvester@edelweb.fr) Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id i3S9U2N27679; Wed, 28 Apr 2004 11:30:02 +0200 (MEST) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Wed, 28 Apr 2004 11:30:02 +0200 (MET DST) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i3S9U0r01376; Wed, 28 Apr 2004 11:30:00 +0200 (MEST) Date: Wed, 28 Apr 2004 11:30:00 +0200 (MEST) From: Peter Sylvester <Peter.Sylvester@edelweb.fr> Message-Id: <200404280930.i3S9U0r01376@chandon.edelweb.fr> To: Peter.Sylvester@edelweb.fr, Denis.Pinkas@bull.net Subject: Re: Meaning of CP in a CA certificate Cc: housley@vigilsec.com, wpolk@nist.gov, ietf-pkix@imc.org, trevorf@exchange.microsoft.com X-Sun-Charset: US-ASCII Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> > > >>I believe that this is a mis-interpretation from the editors of RFC 3280. > >> > > 3280 and X509 have the same textual definition concerning the value > > of the policy extension. what do you think is available in X509 > > which is not available in 3280? What can be misinterpreted if > > both texts are identical? > > > > In both text, there is no provision to indicate in a CA cert some > > policy that governs a CA cert. > > If you had not suppressed the text from my previous e-mail, then you would > have seen that the texts are different. I refered to the text that defines the meaning of the policy extension, they are both identical in X509 and 3280. The text about any policy in 3280 was added as a result to a defect report in X.509. You have statements about semantics in both texts which are not necessarily identical but are supposed to be semantically equivalent as far as I remember. > >>>Are you saying that for example you are looking for > >>>"some path that creates Qualified certificates" but only if the > >>>CA certs are created under a policy indicating "some particular > >>>more or less global UN policy concering CAs"' ? > >> > > > > You have not answered the previous question. > > This question is not understandable for me. A combination of a policy indication in the end entity cert, and some information that the CA certificate is a certifiction authority belonging to a country administration issuing passports or id cards, indicated by a "gobal policy". This seems to me what you are asking for: adding "qualified certificate" as policy for the ee-certs and "country authority ca" as a policy for the ca. Remembering the discussion about policies some days ago, this seems again wanting another type of hierarchy since name chains to trust anchors are not sufficient, because we don't like names, etc. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3S8F5w0060409; Wed, 28 Apr 2004 01:15:05 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3S8F5Ik060408; Wed, 28 Apr 2004 01:15:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3S8F43o060392 for <ietf-pkix@imc.org>; Wed, 28 Apr 2004 01:15:05 -0700 (PDT) (envelope-from Peter.Sylvester@edelweb.fr) Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id i3S8F3N26545; Wed, 28 Apr 2004 10:15:03 +0200 (MEST) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Wed, 28 Apr 2004 10:15:03 +0200 (MET DST) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i3S8F3E01185; Wed, 28 Apr 2004 10:15:03 +0200 (MEST) Date: Wed, 28 Apr 2004 10:15:03 +0200 (MEST) From: Peter Sylvester <Peter.Sylvester@edelweb.fr> Message-Id: <200404280815.i3S8F3E01185@chandon.edelweb.fr> To: Peter.Sylvester@edelweb.fr, trevorf@exchange.microsoft.com Subject: RE: FW: scvp Cc: ietf-pkix@imc.org X-Sun-Charset: US-ASCII Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> > Hi Peter, > The additions optional allow the client to specify in the request the > full range validation parameters defined in 3280 section 6. If you read > section 1, you will see a validation policy is the validation algorithm > plus the input parameter to the algorithm. SCVP14 defines all the base > inputs as defined in 3280. New validation algorithm cab define > additional input variable. I saw the need for these parameters, but ... (1) > The only other parameter you mention refers to Basic constraints, so if > a SCVP client want to validate what it believes is a CA certificate, > then it passes in CA=true. That's not what the spec says ... (2) > > I am not sure whether I am the only person unable to construct a parser. (1) ... the syntax in umbiguous. > in version 14 an aditional flag has been added which is not available in > the > Chapter 9. Is the isCA flag an orthogonal attribut to other validation > algorithms, or just to some of them, e.g,. the default name matching > one? (2) ... there is no option saying client doesn't care whether the cert is a CA or EE. I am not sure whether one needs three options, or, for example: "If set to TRUE, the caller requires a CA, otherwise, the caller doesn't care." Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3RKZgOg054615; Tue, 27 Apr 2004 13:35:42 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3RKZgil054614; Tue, 27 Apr 2004 13:35:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail-eur.microsoft.com (mail-eur.microsoft.com [213.199.128.145]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3RKZedU054605 for <ietf-pkix@imc.org>; Tue, 27 Apr 2004 13:35:41 -0700 (PDT) (envelope-from stefans@microsoft.com) Received: from eur-imc-02.europe.corp.microsoft.com ([65.53.196.43]) by mail-eur.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 27 Apr 2004 21:35:35 +0100 Received: from 65.53.196.43 by eur-imc-02.europe.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 27 Apr 2004 21:35:35 +0100 Received: from EUR-MSG-03.europe.corp.microsoft.com ([65.53.192.44]) by eur-imc-02.europe.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 27 Apr 2004 21:35:35 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: SMIME Capabilities in X.509 certificates. Date: Tue, 27 Apr 2004 21:35:27 +0100 Message-ID: <0C3042E92D8A714783E2C44AB9936E1DF19692@EUR-MSG-03.europe.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SMIME Capabilities in X.509 certificates. Thread-Index: AcQeYtsInf/pINMQRHGoBcgBsbCoqwOMT20A From: "Stefan Santesson" <stefans@microsoft.com> To: <ietf-pkix@imc.org> Cc: "Stephen Kent" <kent@bbn.com> X-OriginalArrivalTime: 27 Apr 2004 20:35:35.0593 (UTC) FILETIME=[31888190:01C42C97] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i3RKZfdU054609 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> OK Steve. Let me try to recap this issue and see if we at least can get to a debate whether this is worth doing or not. The issue on the table is whether it should be a standardized option to include the SMIME capability attribute in a certificate. Microsoft is currently supporting inclusion of this attribute in certificates using the standard PKCS#9 OID as extension OID and thus using the standard PKCS#9 attribute syntax as extension syntax. This extension, when present in certificates is used as the last resource to figure out the appropriate configuration/capabilities of an S/MIME opponent before falling back to default configuration for unknown users. This is useful in particular when an encrypted e-mail is sent to a recipient whose certificate is known but where the recipient's capabilities otherwise are unknown. But if there is a known previous S/MIME message from the recipient from which the recipient's capabilities can be extracted, the certificate extension would typically be ignored. The underlying rationale for this is that in a store and forward type of communication such as e-mail, we may run into situation where one party need to guess the capabilities of the opponent and the guiding principle is that the more information we can use to make the best guess, the better it is. Using such SMIMECapabilities extension in certificates as the last resource of information is supporting that rationale. So, again, please state your opinion so we can either do this or put it away. If it is to be done, the task should be very simple since there should be no reason to deviate from the current syntax of the SMIMECapabilities attribute used in S/MIME. Stefan Santesson Program Manager, Windows Security > -----Original Message----- > From: Stephen Kent [mailto:kent@bbn.com] > Sent: den 9 april 2004 10:34 > To: Stefan Santesson > Cc: ietf-pkix@imc.org > Subject: Re: SMIME Capabilities in X.509 certificates. > > Stefan, > > There have been no responses on the list to your proposal. I think it > would help to give examples of what sorts of info you envision in the > extension, starting with what MS has put in certs under using this > extension. Also note that this might be the topic of a separate RFC, > or part of a 3280 update, but not a new work item unless the > cognizant AD agrees. > > Steve Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3RIvNHU046546; Tue, 27 Apr 2004 11:57:23 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3RIvNNC046545; Tue, 27 Apr 2004 11:57:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from exchange.microsoft.com ([131.107.8.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3RIvMs1046537 for <ietf-pkix@imc.org>; Tue, 27 Apr 2004 11:57:22 -0700 (PDT) (envelope-from trevorf@exchange.microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 27 Apr 2004 11:57:26 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 27 Apr 2004 11:57:26 -0700 Received: from DF-GROMMIT-01.mercury.corp.microsoft.com ([10.197.0.61]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 27 Apr 2004 11:57:25 -0700 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: FW: scvp Date: Tue, 27 Apr 2004 11:57:24 -0700 Message-ID: <33E7A1613A3480448996047B69308A2F02665D2A@df-grommit-01.dogfood> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FW: scvp thread-index: AcQsgagsHGO2NKg2TJe8QizvTePG4AABZSeg From: "Trevor Freeman" <trevorf@exchange.microsoft.com> To: "Denis Pinkas" <Denis.Pinkas@bull.net> Cc: <ietf-pkix@imc.org> X-OriginalArrivalTime: 27 Apr 2004 18:57:25.0931 (UTC) FILETIME=[7B0567B0:01C42C89] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i3RIvMs1046539 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Hi Denis, Can you please be more specific how you think SCVP 14 does not comply with 3379. I can find no section in 3379 where is there a requirement that a validation policy MUST be represented as an OID. Given hiding the detail of what a policy is within an OID simply opens the rat hole of what change to the policy constitutes a change to the OID, it is less ambiguous to refer to the primary data. Once you are in the business of managing state on a client, then there is negligible cost increase incurred in managing several data points vs. a singe data point. Trevor -----Original Message----- From: Denis Pinkas [mailto:Denis.Pinkas@bull.net] Sent: Tuesday, April 27, 2004 11:01 AM To: Trevor Freeman Cc: ietf-pkix@imc.org Subject: Re: FW: scvp Trevor, > HI Denis, > In SCVP13, the concept of validation policy was not completely in > alignment with 3379 definition. Well, it is different and this is a major problem. > It also blurred the distinction between > validation policy and validation algorithm. This is also a majo problem. > Therefore I have defined > what each is in SCVP 14 and aligned the structures accordingly. > Section 1.3 has the following. > "In SCVP, the validation policy comprises of an algorithm for > certificate path processing and the input parameters to the algorithm." This does not comply with RFC 3379. > Therefore trust anchors are an input into the algorithm and therefore > separate. Therefore I do not follow you. From an interface point of view the simplest validation policy is defined by an OID where all the parameters necessary to perform the validation check are "behind" the OID. There is no need to provide any parameter through the interface. When there are some parameters, then they are specific to the validation policy. I have no problem to provide specific parameters for what is called the "default validation policy" which is only a particular validation policy among many others. Simple clients will be unable to pass any parameter but will know which OIDs (for the validation policy) are appropriate for their applications. Denis > This is in alignment with 3379s definition of validation policy. > > Trevor > > -----Original Message----- > From: Denis Pinkas [mailto:Denis.Pinkas@bull.net] > Sent: Monday, April 26, 2004 1:09 AM > To: Peter Sylvester > Cc: ietf-pkix@imc.org; Trevor Freeman > Subject: Re: FW: scvp > > Peter and Trevor, > > I have major problems too. > > >>in version 13 the syntax for a Query has been changed from >> >> Query ::= SEQUENCE { >> queriedCerts SEQUENCE SIZE (1..MAX) OF CertReference, >> checks CertChecks, >> wantBack WantBack, >> serverContextInfo [0] OCTET STRING OPTIONAL, >> valPolicy [1] ValidationPolicy OPTIONAL, >> validityTime [2] GeneralizedTime OPTIONAL, >> trustAnchors [3] TrustAnchors OPTIONAL, >> intermediateCerts [4] CertBundle OPTIONAL, >> revInfos [5] RevocationInfos OPTIONAL, >> queryExtensions [6] Extensions OPTIONAL } > > > In this structure trustAnchors was more or less an alternative to > valPolicy. > > In fact, IF the valPolicy is the default policy, THEN additional > parameters > MUST be provided. So the structure below does not fit as well. > > This leads to have the two following elements: > > valPolicy ValidationPolicy, > paramsDefValPolicy ParamsDefValPolicy OPTIONAL, > > where the first one is mandatory and the second one optional. > > >>to >> >> Query ::= SEQUENCE { >> queriedCerts SEQUENCE SIZE (1..MAX) OF CertReference, > > >> checks CertChecks, >> wantBack WantBack, >> requestRefHash BOOLEAN DEFAULT TRUE, >> includePolResponce BOOLEAN DEFAULT FALSE, >> inhibitPolMap BOOLEAN DEFAULT FALSE, >> requireExplicitPol BOOLEAN DEFAULT FALSE, >> ignoreAnyPol BOOLEAN DEFAULT FALSE, >> valAlgorithm ValidationAlgorithm, >> serverContextInfo [0] OCTET STRING OPTIONAL, >> validityTime [1] GeneralizedTime OPTIONAL, >> trustAnchors [2] TrustAnchors OPTIONAL, >> intermediateCerts [3] CertBundle OPTIONAL, >> revInfos [4] RevocationInfos OPTIONAL, >> queryExtensions [5] Extensions OPTIONAL } > > > I would thus propose to have something like: > > Query ::= SEQUENCE { > queriedCerts SEQUENCE SIZE (1..MAX) OF > CertReference, > checks CertChecks, > wantBack WantBack, > requestRefHash BOOLEAN DEFAULT TRUE, > serverContextInfo OCTET STRING OPTIONAL, > validityTime GeneralizedTime OPTIONAL, > includePolResponse BOOLEAN DEFAULT FALSE, > valPolicy ValidationPolicy, > paramsDefValPolicy [0] ParamsDefValPolicy OPTIONAL, > intermediateCerts [1] CertBundle OPTIONAL, > revInfos [2] RevocationInfos OPTIONAL, > queryExtensions [3] Extensions OPTIONAL } > > and then something like: > > ParamsDefValPolicy :: = SEQUENCE { > trustAnchors TrustAnchors, > endEntityCertificationPolicy SEQUENCE OF OBJECT IDENTIFIER > OPTIONAL, > inhibitPolMap BOOLEAN DEFAULT FALSE, > caCertificationPolicies SEQUENCE OF OBJECT IDENTIFIER > OPTIONAL } > > Denis > > >>I am not sure whether I am the only person unable to construct a > > parser. > >>in version 14 an aditional flag has been added which is not available > > in the > >>Chapter 9. Is the isCA flag an orthogonal attribut to other validation >>algorithms, or just to some of them, e.g,. the default name matching > > one? > >> >> Query ::= SEQUENCE { >> queriedCerts SEQUENCE SIZE (1..MAX) OF CertReference, > > >> checks CertChecks, >> wantBack WantBack, >> requestRefHash BOOLEAN DEFAULT TRUE, >> includePolResponce BOOLEAN DEFAULT FALSE, >> inhibitPolMap BOOLEAN DEFAULT FALSE, >> requireExplicitPol BOOLEAN DEFAULT FALSE, >> ignoreAnyPol BOOLEAN DEFAULT FALSE, >> isCA BOOLEAN DEFAULT FALSE, >> valAlgorithm ValidationAlgorithm, >> serverContextInfo [0] OCTET STRING OPTIONAL, >> validityTime [1] GeneralizedTime OPTIONAL, >> trustAnchors [2] TrustAnchors OPTIONAL, >> intermediateCerts [3] CertBundle OPTIONAL, >> revInfos [4] RevocationInfos OPTIONAL, >> keyUsage [5] KeyUsage OPTIONAL, >> extendedKeyUsage [6] ExtKeyUsageSyntax OPTIONAL, >> queryExtensions [7] Extensions OPTIONAL >> producedAt [8] GeneralizedTime OPTIONAL} >> >> > > > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3RI1JkN042970; Tue, 27 Apr 2004 11:01:19 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3RI1Jbu042969; Tue, 27 Apr 2004 11:01:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3RI1Hq8042937 for <ietf-pkix@imc.org>; Tue, 27 Apr 2004 11:01:18 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net) Received: from clbull.frcl.bull.fr (IDENT:root@clbull.frcl.bull.fr [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id UAA57062; Tue, 27 Apr 2004 20:10:25 +0200 Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id TAA08834; Tue, 27 Apr 2004 19:57:14 +0200 Message-ID: <408E9FEA.5020709@bull.net> Date: Tue, 27 Apr 2004 20:01:14 +0200 From: Denis Pinkas <Denis.Pinkas@bull.net> Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: Trevor Freeman <trevorf@exchange.microsoft.com> CC: ietf-pkix@imc.org Subject: Re: FW: scvp References: <33E7A1613A3480448996047B69308A2F026658A8@df-grommit-01.dogfood> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Trevor, > HI Denis, > In SCVP13, the concept of validation policy was not completely in > alignment with 3379 definition. Well, it is different and this is a major problem. > It also blurred the distinction between > validation policy and validation algorithm. This is also a majo problem. > Therefore I have defined > what each is in SCVP 14 and aligned the structures accordingly. > Section 1.3 has the following. > "In SCVP, the validation policy comprises of an algorithm for > certificate path processing and the input parameters to the algorithm." This does not comply with RFC 3379. > Therefore trust anchors are an input into the algorithm and therefore > separate. Therefore I do not follow you. From an interface point of view the simplest validation policy is defined by an OID where all the parameters necessary to perform the validation check are "behind" the OID. There is no need to provide any parameter through the interface. When there are some parameters, then they are specific to the validation policy. I have no problem to provide specific parameters for what is called the "default validation policy" which is only a particular validation policy among many others. Simple clients will be unable to pass any parameter but will know which OIDs (for the validation policy) are appropriate for their applications. Denis > This is in alignment with 3379s definition of validation policy. > > Trevor > > -----Original Message----- > From: Denis Pinkas [mailto:Denis.Pinkas@bull.net] > Sent: Monday, April 26, 2004 1:09 AM > To: Peter Sylvester > Cc: ietf-pkix@imc.org; Trevor Freeman > Subject: Re: FW: scvp > > Peter and Trevor, > > I have major problems too. > > >>in version 13 the syntax for a Query has been changed from >> >> Query ::= SEQUENCE { >> queriedCerts SEQUENCE SIZE (1..MAX) OF CertReference, >> checks CertChecks, >> wantBack WantBack, >> serverContextInfo [0] OCTET STRING OPTIONAL, >> valPolicy [1] ValidationPolicy OPTIONAL, >> validityTime [2] GeneralizedTime OPTIONAL, >> trustAnchors [3] TrustAnchors OPTIONAL, >> intermediateCerts [4] CertBundle OPTIONAL, >> revInfos [5] RevocationInfos OPTIONAL, >> queryExtensions [6] Extensions OPTIONAL } > > > In this structure trustAnchors was more or less an alternative to > valPolicy. > > In fact, IF the valPolicy is the default policy, THEN additional > parameters > MUST be provided. So the structure below does not fit as well. > > This leads to have the two following elements: > > valPolicy ValidationPolicy, > paramsDefValPolicy ParamsDefValPolicy OPTIONAL, > > where the first one is mandatory and the second one optional. > > >>to >> >> Query ::= SEQUENCE { >> queriedCerts SEQUENCE SIZE (1..MAX) OF CertReference, > > >> checks CertChecks, >> wantBack WantBack, >> requestRefHash BOOLEAN DEFAULT TRUE, >> includePolResponce BOOLEAN DEFAULT FALSE, >> inhibitPolMap BOOLEAN DEFAULT FALSE, >> requireExplicitPol BOOLEAN DEFAULT FALSE, >> ignoreAnyPol BOOLEAN DEFAULT FALSE, >> valAlgorithm ValidationAlgorithm, >> serverContextInfo [0] OCTET STRING OPTIONAL, >> validityTime [1] GeneralizedTime OPTIONAL, >> trustAnchors [2] TrustAnchors OPTIONAL, >> intermediateCerts [3] CertBundle OPTIONAL, >> revInfos [4] RevocationInfos OPTIONAL, >> queryExtensions [5] Extensions OPTIONAL } > > > I would thus propose to have something like: > > Query ::= SEQUENCE { > queriedCerts SEQUENCE SIZE (1..MAX) OF > CertReference, > checks CertChecks, > wantBack WantBack, > requestRefHash BOOLEAN DEFAULT TRUE, > serverContextInfo OCTET STRING OPTIONAL, > validityTime GeneralizedTime OPTIONAL, > includePolResponse BOOLEAN DEFAULT FALSE, > valPolicy ValidationPolicy, > paramsDefValPolicy [0] ParamsDefValPolicy OPTIONAL, > intermediateCerts [1] CertBundle OPTIONAL, > revInfos [2] RevocationInfos OPTIONAL, > queryExtensions [3] Extensions OPTIONAL } > > and then something like: > > ParamsDefValPolicy :: = SEQUENCE { > trustAnchors TrustAnchors, > endEntityCertificationPolicy SEQUENCE OF OBJECT IDENTIFIER > OPTIONAL, > inhibitPolMap BOOLEAN DEFAULT FALSE, > caCertificationPolicies SEQUENCE OF OBJECT IDENTIFIER > OPTIONAL } > > Denis > > >>I am not sure whether I am the only person unable to construct a > > parser. > >>in version 14 an aditional flag has been added which is not available > > in the > >>Chapter 9. Is the isCA flag an orthogonal attribut to other validation >>algorithms, or just to some of them, e.g,. the default name matching > > one? > >> >> Query ::= SEQUENCE { >> queriedCerts SEQUENCE SIZE (1..MAX) OF CertReference, > > >> checks CertChecks, >> wantBack WantBack, >> requestRefHash BOOLEAN DEFAULT TRUE, >> includePolResponce BOOLEAN DEFAULT FALSE, >> inhibitPolMap BOOLEAN DEFAULT FALSE, >> requireExplicitPol BOOLEAN DEFAULT FALSE, >> ignoreAnyPol BOOLEAN DEFAULT FALSE, >> isCA BOOLEAN DEFAULT FALSE, >> valAlgorithm ValidationAlgorithm, >> serverContextInfo [0] OCTET STRING OPTIONAL, >> validityTime [1] GeneralizedTime OPTIONAL, >> trustAnchors [2] TrustAnchors OPTIONAL, >> intermediateCerts [3] CertBundle OPTIONAL, >> revInfos [4] RevocationInfos OPTIONAL, >> keyUsage [5] KeyUsage OPTIONAL, >> extendedKeyUsage [6] ExtKeyUsageSyntax OPTIONAL, >> queryExtensions [7] Extensions OPTIONAL >> producedAt [8] GeneralizedTime OPTIONAL} >> >> > > > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3RI0eJm042901; Tue, 27 Apr 2004 11:00:40 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3RI0eDT042900; Tue, 27 Apr 2004 11:00:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3RI0d3r042893 for <ietf-pkix@imc.org>; Tue, 27 Apr 2004 11:00:40 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net) Received: from clbull.frcl.bull.fr (IDENT:root@clbull.frcl.bull.fr [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id UAA50190; Tue, 27 Apr 2004 20:09:45 +0200 Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id TAA08822; Tue, 27 Apr 2004 19:56:23 +0200 Message-ID: <408E9FB7.6040104@bull.net> Date: Tue, 27 Apr 2004 20:00:23 +0200 From: Denis Pinkas <Denis.Pinkas@bull.net> Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: Peter Sylvester <Peter.Sylvester@edelweb.fr> CC: housley@vigilsec.com, wpolk@nist.gov, ietf-pkix@imc.org, trevorf@exchange.microsoft.com Subject: Re: Meaning of CP in a CA certificate References: <200404261740.i3QHeqx25500@chandon.edelweb.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Peter, >>I believe that this is a mis-interpretation from the editors of RFC 3280. >> > 3280 and X509 have the same textual definition concerning the value > of the policy extension. what do you think is available in X509 > which is not available in 3280? What can be misinterpreted if > both texts are identical? > > In both text, there is no provision to indicate in a CA cert some > policy that governs a CA cert. If you had not suppressed the text from my previous e-mail, then you would have seen that the texts are different. > >>Denis >> >> >>>Are you saying that for example you are looking for >>>"some path that creates Qualified certificates" but only if the >>>CA certs are created under a policy indicating "some particular >>>more or less global UN policy concering CAs"' ? >> > > You have not answered the previous question. This question is not understandable for me. Denis > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3RHwJuW042599; Tue, 27 Apr 2004 10:58:19 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3RHwJ0f042598; Tue, 27 Apr 2004 10:58:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3RHwH3Q042586 for <ietf-pkix@imc.org>; Tue, 27 Apr 2004 10:58:18 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net) Received: from clbull.frcl.bull.fr (IDENT:root@clbull.frcl.bull.fr [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id UAA50430; Tue, 27 Apr 2004 20:07:22 +0200 Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id TAA08803; Tue, 27 Apr 2004 19:54:08 +0200 Message-ID: <408E9F31.30106@bull.net> Date: Tue, 27 Apr 2004 19:58:09 +0200 From: Denis Pinkas <Denis.Pinkas@bull.net> Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: Peter Sylvester <Peter.Sylvester@edelweb.fr> CC: ietf-pkix@imc.org Subject: Re: FW: scvp References: <200404261718.i3QHIeQ25413@chandon.edelweb.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Peter, >>Do you want something like >>> >>> validationPolicyParameters ANY DEFINED BY theValidationPolicy >> >>Yes. > > unless I'm wrong, validation policies identifiers are something like > the policy identifier in RFC 3161? if so, the number is unlimited, > and you cannot use really these ids in an any define by construct. The issuer of the OID will have to provide the full definition. If there are some parameters (which is not mandatory at all), then it will define the ASN.1 syntax, and then you will be able to compile it. Denis > And how would you construct an ASN1 parser for this, how would > a parser learn dynamically what syntax (and semantics) you need. > > Isn't exactly the technical nonsense that we had in version 12, > the validation algorithm syntaxes had been split off in v13, > in a validation policy you indicate now as a parameter. > > "use validation algorithm OIDofsslserver + dns=this.domain", > > you could try to define things like that for each step for the > validation path, saying, "the ca that signs at level 1 must > be validates using cavalidation algorithm 'standard 3280 default > path' (or one of a few of others), and the parameters for algorithm are > 'the OCSP server to validate', frequence of validation time?? or others. > > I think one should first try and define a language for ... ooups, SPKI > > > > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3RDEqg9023229; Tue, 27 Apr 2004 06:14:52 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3RDEqwG023228; Tue, 27 Apr 2004 06:14:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mclean-vscan5.bah.com (mclean-vscan5.bah.com [156.80.3.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3RDEnax023210 for <ietf-pkix@imc.org>; Tue, 27 Apr 2004 06:14:52 -0700 (PDT) (envelope-from chokhani@orionsec.com) Received: from mclean-vscan5.bah.com (mclean-vscan5.bah.com [156.80.3.66]) by mclean-vscan5.bah.com (8.11.0/8.11.0) with SMTP id i3RDEit19004 for <ietf-pkix@imc.org>; Tue, 27 Apr 2004 09:14:44 -0400 (EDT) Received: from mclean-mail.usae.bah.com ([156.80.5.109]) by mclean-vscan5.bah.com (NAVGW 2.5.2.12) with SMTP id M2004042709144304648 for <ietf-pkix@imc.org>; Tue, 27 Apr 2004 09:14:43 -0400 Received: from wchokhani3 ([156.80.234.186]) by mclean-mail.usae.bah.com (Netscape Messaging Server 4.15) with ESMTP id HWTZGJ00.VP5 for <ietf-pkix@imc.org>; Tue, 27 Apr 2004 09:14:43 -0400 From: "Santosh Chokhani" <chokhani@orionsec.com> To: <ietf-pkix@imc.org> Subject: RE: Cross certificate format Date: Tue, 27 Apr 2004 09:14:42 -0400 Message-ID: <001101c42c59$9afd2790$baea509c@hq.orionsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal In-Reply-To: <OFE32FF033.CF4D7805-ON85256E82.0061733E-85256E83.003F794D@us.ibm.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i3RDEqax023223 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Tom: My point is that even if the trust anchor is a self-signed certificate, all you need to do is extract the required information. There is no need to examine anything. Cross certificate and trust anchor are very different things. An element of the cross certificate pair is nothing but an intermediate CA certificate in a certification path. -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Tom Gindin Sent: Tuesday, April 27, 2004 7:33 AM To: Santosh Chokhani Cc: ietf-pkix@imc.org; owner-ietf-pkix@mail.imc.org Subject: RE: Cross certificate format Santosh: Of course, you are right that RFC 3280 6.1.1 d permits trust anchor information to be provided outside a certificate. If it is so, no checks of the sort I indicated can be performed. It also says that it can be provided as "a self-signed certificate", with no further qualification. I do think it is somewhat odd that a self-signed certificate with KeyUsage set to typical EE values would be considered a valid issuer as a trust anchor while a cross certificate would not. You can always extract the needed anchor information from a cross-certificate, of course. Tom Gindin "Santosh Chokhani" <chokhani@orionsec.com> Sent by: owner-ietf-pkix@mail.imc.org 04/26/2004 08:51 AM To: <ietf-pkix@imc.org> cc: Subject: RE: Cross certificate format Tom: My reading of 3280 and X.509 is that a trust anchor need not even be a certificate. Thus, no checks need to be performed on a trust anchor at all. You get the DN, public key, algorithm OID, and parameters (if applicable) from a trust anchor. Any checks are gratuitous and not required by either standard. -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Tom Gindin Sent: Sunday, April 25, 2004 7:06 PM To: Jean-Marc Desperrier Cc: ietf-pkix@imc.org Subject: Re: Cross certificate format Jean-Marc: RFC 3280 doesn't say that anywhere. It does say that you don't need to validate the trust anchor as part of the path, but it isn't clear from the text that a v1 certificate is acceptable as a trust anchor - and it certainly isn't clear that a v1 certificate is acceptable as an issuer if it is a trust anchor while a v3 certificate with KeyUsage= { DigitalSignature, keyEncipherment } is not acceptable as an issuer even if it is a trust anchor. I believe that the correct rules for versions are something like the following: a certificate issued by a trust anchor which is represented by a certificate is verifiable if the anchor certificate is either a v1 certificate or a v3 certificate with the CA flag present in the basicConstraints extension. If the anchor certificate is a v3 certificate with the KeyUsage extension present, it is only a valid issuer certificate if keyCertSign is set. Tom Gindin Jean-Marc Desperrier <jmdesp@free.fr> Sent by: owner-ietf-pkix@mail.imc.org 04/21/2004 03:42 PM To: ietf-pkix@imc.org cc: Subject: Re: Cross certificate format Tom Gindin wrote: > RFC 3280 does not support the use of v1 self-signed > certificates, >which contain no extensions at all (see the text of RFC 3280's >basicConstraints section). However, a number of public CA's still have >them. > > Applications implementing the path validation algorithm of RFC3280 MUST accept them when they are used as trust anchors. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3RBXYZh014974; Tue, 27 Apr 2004 04:33:34 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3RBXYdA014973; Tue, 27 Apr 2004 04:33:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3RBXXdw014957; Tue, 27 Apr 2004 04:33:33 -0700 (PDT) (envelope-from tgindin@us.ibm.com) Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e1.ny.us.ibm.com (8.12.10/NS PXFA) with ESMTP id i3RBXTX4413044; Tue, 27 Apr 2004 07:33:29 -0400 Received: from d01ml062.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i3RBXvOU096100; Tue, 27 Apr 2004 07:33:57 -0400 To: "Santosh Chokhani" <chokhani@orionsec.com> Cc: ietf-pkix@imc.org, owner-ietf-pkix@mail.imc.org MIME-Version: 1.0 Subject: RE: Cross certificate format X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 From: Tom Gindin <tgindin@us.ibm.com> Message-ID: <OFE32FF033.CF4D7805-ON85256E82.0061733E-85256E83.003F794D@us.ibm.com> Date: Tue, 27 Apr 2004 07:33:24 -0400 X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 6.0.2CF2 HFB2|March 16, 2004) at 04/27/2004 07:33:28, Serialize complete at 04/27/2004 07:33:28 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Santosh: Of course, you are right that RFC 3280 6.1.1 d permits trust anchor information to be provided outside a certificate. If it is so, no checks of the sort I indicated can be performed. It also says that it can be provided as "a self-signed certificate", with no further qualification. I do think it is somewhat odd that a self-signed certificate with KeyUsage set to typical EE values would be considered a valid issuer as a trust anchor while a cross certificate would not. You can always extract the needed anchor information from a cross-certificate, of course. Tom Gindin "Santosh Chokhani" <chokhani@orionsec.com> Sent by: owner-ietf-pkix@mail.imc.org 04/26/2004 08:51 AM To: <ietf-pkix@imc.org> cc: Subject: RE: Cross certificate format Tom: My reading of 3280 and X.509 is that a trust anchor need not even be a certificate. Thus, no checks need to be performed on a trust anchor at all. You get the DN, public key, algorithm OID, and parameters (if applicable) from a trust anchor. Any checks are gratuitous and not required by either standard. -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Tom Gindin Sent: Sunday, April 25, 2004 7:06 PM To: Jean-Marc Desperrier Cc: ietf-pkix@imc.org Subject: Re: Cross certificate format Jean-Marc: RFC 3280 doesn't say that anywhere. It does say that you don't need to validate the trust anchor as part of the path, but it isn't clear from the text that a v1 certificate is acceptable as a trust anchor - and it certainly isn't clear that a v1 certificate is acceptable as an issuer if it is a trust anchor while a v3 certificate with KeyUsage= { DigitalSignature, keyEncipherment } is not acceptable as an issuer even if it is a trust anchor. I believe that the correct rules for versions are something like the following: a certificate issued by a trust anchor which is represented by a certificate is verifiable if the anchor certificate is either a v1 certificate or a v3 certificate with the CA flag present in the basicConstraints extension. If the anchor certificate is a v3 certificate with the KeyUsage extension present, it is only a valid issuer certificate if keyCertSign is set. Tom Gindin Jean-Marc Desperrier <jmdesp@free.fr> Sent by: owner-ietf-pkix@mail.imc.org 04/21/2004 03:42 PM To: ietf-pkix@imc.org cc: Subject: Re: Cross certificate format Tom Gindin wrote: > RFC 3280 does not support the use of v1 self-signed > certificates, >which contain no extensions at all (see the text of RFC 3280's >basicConstraints section). However, a number of public CA's still have >them. > > Applications implementing the path validation algorithm of RFC3280 MUST accept them when they are used as trust anchors. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3R6TC91042473; Mon, 26 Apr 2004 23:29:12 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3R6TCgs042472; Mon, 26 Apr 2004 23:29:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from exchange.microsoft.com ([131.107.8.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3R6TBTv042460 for <ietf-pkix@imc.org>; Mon, 26 Apr 2004 23:29:11 -0700 (PDT) (envelope-from trevorf@exchange.microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Mon, 26 Apr 2004 23:29:10 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 26 Apr 2004 23:29:10 -0700 Received: from DF-GROMMIT-01.mercury.corp.microsoft.com ([10.197.0.61]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 26 Apr 2004 23:29:10 -0700 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: FW: scvp Date: Mon, 26 Apr 2004 23:29:20 -0700 Message-ID: <33E7A1613A3480448996047B69308A2F02665B9E@df-grommit-01.dogfood> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FW: scvp thread-index: AcQpX2lRm8fC7VN6RSCxjuCQySDQ1QACJWeg From: "Trevor Freeman" <trevorf@exchange.microsoft.com> To: "Peter Sylvester" <Peter.Sylvester@edelweb.fr>, <ietf-pkix@imc.org> X-OriginalArrivalTime: 27 Apr 2004 06:29:10.0238 (UTC) FILETIME=[F31A4FE0:01C42C20] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i3R6TBTv042462 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Hi Peter, The additions optional allow the client to specify in the request the full range validation parameters defined in 3280 section 6. If you read section 1, you will see a validation policy is the validation algorithm plus the input parameter to the algorithm. SCVP14 defines all the base inputs as defined in 3280. New validation algorithm cab define additional input variable. The only other parameter you mention refers to Basic constraints, so if a SCVP client want to validate what it believes is a CA certificate, then it passes in CA=true. Trevor -----Original Message----- From: Peter Sylvester [mailto:Peter.Sylvester@edelweb.fr] Sent: Friday, April 23, 2004 11:19 AM To: ietf-pkix@imc.org; Trevor Freeman Cc: Peter.Sylvester@edelweb.fr Subject: Re: FW: scvp in version 13 the syntax for a Query has been changed from Query ::= SEQUENCE { queriedCerts SEQUENCE SIZE (1..MAX) OF CertReference, checks CertChecks, wantBack WantBack, serverContextInfo [0] OCTET STRING OPTIONAL, valPolicy [1] ValidationPolicy OPTIONAL, validityTime [2] GeneralizedTime OPTIONAL, trustAnchors [3] TrustAnchors OPTIONAL, intermediateCerts [4] CertBundle OPTIONAL, revInfos [5] RevocationInfos OPTIONAL, queryExtensions [6] Extensions OPTIONAL } to Query ::= SEQUENCE { queriedCerts SEQUENCE SIZE (1..MAX) OF CertReference, checks CertChecks, wantBack WantBack, requestRefHash BOOLEAN DEFAULT TRUE, includePolResponce BOOLEAN DEFAULT FALSE, inhibitPolMap BOOLEAN DEFAULT FALSE, requireExplicitPol BOOLEAN DEFAULT FALSE, ignoreAnyPol BOOLEAN DEFAULT FALSE, valAlgorithm ValidationAlgorithm, serverContextInfo [0] OCTET STRING OPTIONAL, validityTime [1] GeneralizedTime OPTIONAL, trustAnchors [2] TrustAnchors OPTIONAL, intermediateCerts [3] CertBundle OPTIONAL, revInfos [4] RevocationInfos OPTIONAL, queryExtensions [5] Extensions OPTIONAL } I am not sure whether I am the only person unable to construct a parser. in version 14 an aditional flag has been added which is not available in the Chapter 9. Is the isCA flag an orthogonal attribut to other validation algorithms, or just to some of them, e.g,. the default name matching one? Query ::= SEQUENCE { queriedCerts SEQUENCE SIZE (1..MAX) OF CertReference, checks CertChecks, wantBack WantBack, requestRefHash BOOLEAN DEFAULT TRUE, includePolResponce BOOLEAN DEFAULT FALSE, inhibitPolMap BOOLEAN DEFAULT FALSE, requireExplicitPol BOOLEAN DEFAULT FALSE, ignoreAnyPol BOOLEAN DEFAULT FALSE, isCA BOOLEAN DEFAULT FALSE, valAlgorithm ValidationAlgorithm, serverContextInfo [0] OCTET STRING OPTIONAL, validityTime [1] GeneralizedTime OPTIONAL, trustAnchors [2] TrustAnchors OPTIONAL, intermediateCerts [3] CertBundle OPTIONAL, revInfos [4] RevocationInfos OPTIONAL, keyUsage [5] KeyUsage OPTIONAL, extendedKeyUsage [6] ExtKeyUsageSyntax OPTIONAL, queryExtensions [7] Extensions OPTIONAL producedAt [8] GeneralizedTime OPTIONAL} Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3QIfrYq055293; Mon, 26 Apr 2004 11:41:53 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3QIfrgx055292; Mon, 26 Apr 2004 11:41:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from exchange.microsoft.com ([131.107.8.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3QIfquJ055285 for <ietf-pkix@imc.org>; Mon, 26 Apr 2004 11:41:52 -0700 (PDT) (envelope-from trevorf@exchange.microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Mon, 26 Apr 2004 11:41:53 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 26 Apr 2004 11:41:53 -0700 Received: from DF-GROMMIT-01.mercury.corp.microsoft.com ([10.197.0.61]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 26 Apr 2004 11:41:53 -0700 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: FW: scvp Date: Mon, 26 Apr 2004 11:41:54 -0700 Message-ID: <33E7A1613A3480448996047B69308A2F026658BA@df-grommit-01.dogfood> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FW: scvp thread-index: AcQrson5pHrEmUqeS4KoqHa03S7p4AACr3vA From: "Trevor Freeman" <trevorf@exchange.microsoft.com> To: "Peter Sylvester" <Peter.Sylvester@edelweb.fr>, <Denis.Pinkas@bull.net> Cc: <ietf-pkix@imc.org> X-OriginalArrivalTime: 26 Apr 2004 18:41:53.0233 (UTC) FILETIME=[24AD3C10:01C42BBE] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i3QIfquJ055286 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> SCVP assumes that the minimum processing for certificate validation is defined in 3280 and supports that set of data independently of the algorithm definition. This set of data is universal to all SCVP validation. If as part of a new algorithm you define additional data, then that data can be added to the inputs to the new algorithm. An illustration of how this works is given in SCVP 3.2.11.2 where some name checking is also performed which is over and above the 3280 checking. Trevor -----Original Message----- From: Peter Sylvester [mailto:Peter.Sylvester@edelweb.fr] Sent: Monday, April 26, 2004 10:19 AM To: Peter.Sylvester@edelweb.fr; Denis.Pinkas@bull.net Cc: ietf-pkix@imc.org; Trevor Freeman Subject: Re: FW: scvp > > Do you want something like > > > > validationPolicyParameters ANY DEFINED BY theValidationPolicy > > Yes. unless I'm wrong, validation policies identifiers are something like the policy identifier in RFC 3161? if so, the number is unlimited, and you cannot use really these ids in an any define by construct. And how would you construct an ASN1 parser for this, how would a parser learn dynamically what syntax (and semantics) you need. Isn't exactly the technical nonsense that we had in version 12, the validation algorithm syntaxes had been split off in v13, in a validation policy you indicate now as a parameter. "use validation algorithm OIDofsslserver + dns=this.domain", you could try to define things like that for each step for the validation path, saying, "the ca that signs at level 1 must be validates using cavalidation algorithm 'standard 3280 default path' (or one of a few of others), and the parameters for algorithm are 'the OCSP server to validate', frequence of validation time?? or others. I think one should first try and define a language for ... ooups, SPKI Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3QIUBf1054494; Mon, 26 Apr 2004 11:30:11 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3QIUBLo054493; Mon, 26 Apr 2004 11:30:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from exchange.microsoft.com ([131.107.8.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3QIUAqx054486 for <ietf-pkix@imc.org>; Mon, 26 Apr 2004 11:30:10 -0700 (PDT) (envelope-from trevorf@exchange.microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Mon, 26 Apr 2004 11:30:14 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 26 Apr 2004 11:30:14 -0700 Received: from DF-GROMMIT-01.mercury.corp.microsoft.com ([10.197.0.61]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 26 Apr 2004 11:30:14 -0700 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: FW: scvp Date: Mon, 26 Apr 2004 11:30:14 -0700 Message-ID: <33E7A1613A3480448996047B69308A2F026658A8@df-grommit-01.dogfood> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FW: scvp thread-index: AcQrZcX9jvHAeAbORcKM2ThMQhUjNAAVbJsg From: "Trevor Freeman" <trevorf@exchange.microsoft.com> To: "Denis Pinkas" <Denis.Pinkas@bull.net>, "Peter Sylvester" <Peter.Sylvester@edelweb.fr> Cc: <ietf-pkix@imc.org> X-OriginalArrivalTime: 26 Apr 2004 18:30:14.0137 (UTC) FILETIME=[83FBA690:01C42BBC] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i3QIUAqx054487 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> HI Denis, In SCVP13, the concept of validation policy was not completely in alignment with 3379 definition. It also blurred the distinction between validation policy and validation algorithm. Therefore I have defined what each is in SCVP 14 and aligned the structures accordingly. Section 1.3 has the following. "In SCVP, the validation policy comprises of an algorithm for certificate path processing and the input parameters to the algorithm." Therefore trust anchors are an input into the algorithm and therefore separate. This is in alignment with 3379s definition of validation policy. Trevor -----Original Message----- From: Denis Pinkas [mailto:Denis.Pinkas@bull.net] Sent: Monday, April 26, 2004 1:09 AM To: Peter Sylvester Cc: ietf-pkix@imc.org; Trevor Freeman Subject: Re: FW: scvp Peter and Trevor, I have major problems too. > in version 13 the syntax for a Query has been changed from > > Query ::= SEQUENCE { > queriedCerts SEQUENCE SIZE (1..MAX) OF CertReference, > checks CertChecks, > wantBack WantBack, > serverContextInfo [0] OCTET STRING OPTIONAL, > valPolicy [1] ValidationPolicy OPTIONAL, > validityTime [2] GeneralizedTime OPTIONAL, > trustAnchors [3] TrustAnchors OPTIONAL, > intermediateCerts [4] CertBundle OPTIONAL, > revInfos [5] RevocationInfos OPTIONAL, > queryExtensions [6] Extensions OPTIONAL } In this structure trustAnchors was more or less an alternative to valPolicy. In fact, IF the valPolicy is the default policy, THEN additional parameters MUST be provided. So the structure below does not fit as well. This leads to have the two following elements: valPolicy ValidationPolicy, paramsDefValPolicy ParamsDefValPolicy OPTIONAL, where the first one is mandatory and the second one optional. > to > > Query ::= SEQUENCE { > queriedCerts SEQUENCE SIZE (1..MAX) OF CertReference, > checks CertChecks, > wantBack WantBack, > requestRefHash BOOLEAN DEFAULT TRUE, > includePolResponce BOOLEAN DEFAULT FALSE, > inhibitPolMap BOOLEAN DEFAULT FALSE, > requireExplicitPol BOOLEAN DEFAULT FALSE, > ignoreAnyPol BOOLEAN DEFAULT FALSE, > valAlgorithm ValidationAlgorithm, > serverContextInfo [0] OCTET STRING OPTIONAL, > validityTime [1] GeneralizedTime OPTIONAL, > trustAnchors [2] TrustAnchors OPTIONAL, > intermediateCerts [3] CertBundle OPTIONAL, > revInfos [4] RevocationInfos OPTIONAL, > queryExtensions [5] Extensions OPTIONAL } I would thus propose to have something like: Query ::= SEQUENCE { queriedCerts SEQUENCE SIZE (1..MAX) OF CertReference, checks CertChecks, wantBack WantBack, requestRefHash BOOLEAN DEFAULT TRUE, serverContextInfo OCTET STRING OPTIONAL, validityTime GeneralizedTime OPTIONAL, includePolResponse BOOLEAN DEFAULT FALSE, valPolicy ValidationPolicy, paramsDefValPolicy [0] ParamsDefValPolicy OPTIONAL, intermediateCerts [1] CertBundle OPTIONAL, revInfos [2] RevocationInfos OPTIONAL, queryExtensions [3] Extensions OPTIONAL } and then something like: ParamsDefValPolicy :: = SEQUENCE { trustAnchors TrustAnchors, endEntityCertificationPolicy SEQUENCE OF OBJECT IDENTIFIER OPTIONAL, inhibitPolMap BOOLEAN DEFAULT FALSE, caCertificationPolicies SEQUENCE OF OBJECT IDENTIFIER OPTIONAL } Denis > I am not sure whether I am the only person unable to construct a parser. > > in version 14 an aditional flag has been added which is not available in the > Chapter 9. Is the isCA flag an orthogonal attribut to other validation > algorithms, or just to some of them, e.g,. the default name matching one? > > > Query ::= SEQUENCE { > queriedCerts SEQUENCE SIZE (1..MAX) OF CertReference, > checks CertChecks, > wantBack WantBack, > requestRefHash BOOLEAN DEFAULT TRUE, > includePolResponce BOOLEAN DEFAULT FALSE, > inhibitPolMap BOOLEAN DEFAULT FALSE, > requireExplicitPol BOOLEAN DEFAULT FALSE, > ignoreAnyPol BOOLEAN DEFAULT FALSE, > isCA BOOLEAN DEFAULT FALSE, > valAlgorithm ValidationAlgorithm, > serverContextInfo [0] OCTET STRING OPTIONAL, > validityTime [1] GeneralizedTime OPTIONAL, > trustAnchors [2] TrustAnchors OPTIONAL, > intermediateCerts [3] CertBundle OPTIONAL, > revInfos [4] RevocationInfos OPTIONAL, > keyUsage [5] KeyUsage OPTIONAL, > extendedKeyUsage [6] ExtKeyUsageSyntax OPTIONAL, > queryExtensions [7] Extensions OPTIONAL > producedAt [8] GeneralizedTime OPTIONAL} > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3QHetX1050012; Mon, 26 Apr 2004 10:40:55 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3QHetKw050011; Mon, 26 Apr 2004 10:40:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3QHerPK050004 for <ietf-pkix@imc.org>; Mon, 26 Apr 2004 10:40:54 -0700 (PDT) (envelope-from Peter.Sylvester@edelweb.fr) Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id i3QHerN00287; Mon, 26 Apr 2004 19:40:53 +0200 (MEST) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Mon, 26 Apr 2004 19:40:54 +0200 (MET DST) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i3QHeqx25500; Mon, 26 Apr 2004 19:40:52 +0200 (MEST) Date: Mon, 26 Apr 2004 19:40:52 +0200 (MEST) From: Peter Sylvester <Peter.Sylvester@edelweb.fr> Message-Id: <200404261740.i3QHeqx25500@chandon.edelweb.fr> To: Peter.Sylvester@edelweb.fr, housley@vigilsec.com, wpolk@nist.gov, Denis.Pinkas@bull.net Subject: Re: Meaning of CP in a CA certificate Cc: ietf-pkix@imc.org, trevorf@exchange.microsoft.com X-Sun-Charset: US-ASCII Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> > > I believe that this is a mis-interpretation from the editors of RFC 3280. > 3280 and X509 have the same textual definition concerning the value of the policy extension. what do you think is available in X509 which is not available in 3280? What can be misinterpreted if both texts are identical? In both text, there is no provision to indicate in a CA cert some policy that governs a CA cert. > Denis > > > Are you saying that for example you are looking for > > "some path that creates Qualified certificates" but only if the > > CA certs are created under a policy indicating "some particular > > more or less global UN policy concering CAs"' ? You have not answered the previous question. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3QHIrma047119; Mon, 26 Apr 2004 10:18:53 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3QHIrTo047118; Mon, 26 Apr 2004 10:18:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3QHIm9C047101 for <ietf-pkix@imc.org>; Mon, 26 Apr 2004 10:18:51 -0700 (PDT) (envelope-from Peter.Sylvester@edelweb.fr) Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id i3QHIeN29970; Mon, 26 Apr 2004 19:18:40 +0200 (MEST) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Mon, 26 Apr 2004 19:18:40 +0200 (MET DST) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i3QHIeQ25413; Mon, 26 Apr 2004 19:18:40 +0200 (MEST) Date: Mon, 26 Apr 2004 19:18:40 +0200 (MEST) From: Peter Sylvester <Peter.Sylvester@edelweb.fr> Message-Id: <200404261718.i3QHIeQ25413@chandon.edelweb.fr> To: Peter.Sylvester@edelweb.fr, Denis.Pinkas@bull.net Subject: Re: FW: scvp Cc: ietf-pkix@imc.org, trevorf@exchange.microsoft.com X-Sun-Charset: US-ASCII Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> > > Do you want something like > > > > validationPolicyParameters ANY DEFINED BY theValidationPolicy > > Yes. unless I'm wrong, validation policies identifiers are something like the policy identifier in RFC 3161? if so, the number is unlimited, and you cannot use really these ids in an any define by construct. And how would you construct an ASN1 parser for this, how would a parser learn dynamically what syntax (and semantics) you need. Isn't exactly the technical nonsense that we had in version 12, the validation algorithm syntaxes had been split off in v13, in a validation policy you indicate now as a parameter. "use validation algorithm OIDofsslserver + dns=this.domain", you could try to define things like that for each step for the validation path, saying, "the ca that signs at level 1 must be validates using cavalidation algorithm 'standard 3280 default path' (or one of a few of others), and the parameters for algorithm are 'the OCSP server to validate', frequence of validation time?? or others. I think one should first try and define a language for ... ooups, SPKI Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3QGi0B7043443; Mon, 26 Apr 2004 09:44:00 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3QGi0hC043442; Mon, 26 Apr 2004 09:44:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3QGhvxH043431 for <ietf-pkix@imc.org>; Mon, 26 Apr 2004 09:43:58 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net) Received: from clbull.frcl.bull.fr (IDENT:root@clbull.frcl.bull.fr [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id SAA32408; Mon, 26 Apr 2004 18:53:01 +0200 Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id SAA20768; Mon, 26 Apr 2004 18:39:45 +0200 Message-ID: <408D3C42.6000805@bull.net> Date: Mon, 26 Apr 2004 18:43:46 +0200 From: Denis Pinkas <Denis.Pinkas@bull.net> Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: Peter Sylvester <Peter.Sylvester@edelweb.fr> CC: ietf-pkix@imc.org, trevorf@exchange.microsoft.com Subject: Re: FW: scvp References: <200404261639.i3QGduR25262@chandon.edelweb.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Peter, >>I am saying that the parameters of validation policies may vary depending >>upon the validation policy. Some policies may be simple while some others >>quite complex. Some parameters may be fixed and some others may be specified >>by the interface (i.e. using the parameters of the validation policy). > > > 'may vary' is not sufficiently clear. > > Do you want something like > > validationPolicyParameters ANY DEFINED BY theValidationPolicy Yes. Denis Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3QGdxwE043133; Mon, 26 Apr 2004 09:39:59 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3QGdxV0043132; Mon, 26 Apr 2004 09:39:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3QGdvPK043126 for <ietf-pkix@imc.org>; Mon, 26 Apr 2004 09:39:58 -0700 (PDT) (envelope-from Peter.Sylvester@edelweb.fr) Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id i3QGdvN29215; Mon, 26 Apr 2004 18:39:57 +0200 (MEST) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Mon, 26 Apr 2004 18:39:57 +0200 (MET DST) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i3QGduR25262; Mon, 26 Apr 2004 18:39:56 +0200 (MEST) Date: Mon, 26 Apr 2004 18:39:56 +0200 (MEST) From: Peter Sylvester <Peter.Sylvester@edelweb.fr> Message-Id: <200404261639.i3QGduR25262@chandon.edelweb.fr> To: Peter.Sylvester@edelweb.fr, Denis.Pinkas@bull.net Subject: Re: FW: scvp Cc: ietf-pkix@imc.org, trevorf@exchange.microsoft.com X-Sun-Charset: US-ASCII Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> > I am saying that the parameters of validation policies may vary depending > upon the validation policy. Some policies may be simple while some others > quite complex. Some parameters may be fixed and some others may be specified > by the interface (i.e. using the parameters of the validation policy). 'may vary' is not sufficiently clear. Do you want something like validationPolicyParameters ANY DEFINED BY theValidationPolicy Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3QEp0FM033799; Mon, 26 Apr 2004 07:51:00 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3QEp0Ef033798; Mon, 26 Apr 2004 07:51:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3QEowOn033763 for <ietf-pkix@imc.org>; Mon, 26 Apr 2004 07:50:59 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net) Received: from clbull.frcl.bull.fr (IDENT:root@clbull.frcl.bull.fr [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA36076; Mon, 26 Apr 2004 16:59:59 +0200 Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id QAA20105; Mon, 26 Apr 2004 16:46:48 +0200 Message-ID: <408D21C9.2040602@bull.net> Date: Mon, 26 Apr 2004 16:50:49 +0200 From: Denis Pinkas <Denis.Pinkas@bull.net> Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: Peter Sylvester <Peter.Sylvester@edelweb.fr> CC: ietf-pkix@imc.org, trevorf@exchange.microsoft.com Subject: Re: FW: scvp References: <200404261341.i3QDf6E24479@chandon.edelweb.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Peter, Since the first part has been answered in a separate e-mail, I have deleted the part that is answered separately. (text deleted) >>Ooops ! This is a typo. I meant: The parameters for a given *validation >>policy* should be depended upon the OID of the validation policy. > that's less clear to me. besides "dependant", are you talking about a limited > number of syntaxes defined by some OID, or OIDs indicating some > parameter set similar as with a CP, or? I am saying that the parameters of validation policies may vary depending upon the validation policy. Some policies may be simple while some others quite complex. Some parameters may be fixed and some others may be specified by the interface (i.e. using the parameters of the validation policy). Denis Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3QEoXlX033749; Mon, 26 Apr 2004 07:50:33 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3QEoXw8033748; Mon, 26 Apr 2004 07:50:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3QEoTs1033727 for <ietf-pkix@imc.org>; Mon, 26 Apr 2004 07:50:30 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net) Received: from clbull.frcl.bull.fr (IDENT:root@clbull.frcl.bull.fr [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA27090; Mon, 26 Apr 2004 16:59:27 +0200 Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id QAA20100; Mon, 26 Apr 2004 16:46:05 +0200 Message-ID: <408D219F.3080501@bull.net> Date: Mon, 26 Apr 2004 16:50:07 +0200 From: Denis Pinkas <Denis.Pinkas@bull.net> Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: Peter Sylvester <Peter.Sylvester@edelweb.fr>, Russ Housley <housley@vigilsec.com>, Tim Polk <wpolk@nist.gov> CC: ietf-pkix@imc.org, trevorf@exchange.microsoft.com Subject: Meaning of CP in a CA certificate References: <200404261341.i3QDf6E24479@chandon.edelweb.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Peter, Since one of your observations triggers a different topic , I change the subject of this e-mail and reply to the remaining in a different one. >>A signatory certificate in Europe may use a specific OID for the CP meaning >>"Qualified Certificate". >> >>Such CP does not apply to CA certificates. > > But you can put them into a CA. No. They are not applicable for such a purpose. > In an end entity certificate, these policy information terms indicate > the policy under which the certificate has been issued and the > purposes for which the certificate may be used. In a CA certificate, > these policy information terms limit the set of policies for > certification paths which include this certificate. > So far, no known texts says that CA certificates can be profiled > by some policy. It seems that you introducing something new? X.509 defines certificate policy as: "3.3.10 certificate policy: A named set of rules that indicates the applicability of a certificate to a particular community and/or class of application with common security requirements." This definition is not restricted to end-entity certificates. In section 8.1.1. from X.509 the text states: "All certificates are issued in accordance with a policy, even if the policy is neither recorded anywhere nor referenced in the certificate." This means that a CA certificate may be issued with a certificate policy. In section 8.1.1. from X.509 the text states later: "A certification authority may place limitations on the use of its certificates, in order to control the risk that it assumes as a result of issuing certificates. For instance, it may restrict the community of certificate users, the purposes for which they may use its certificates and/or the type and extent of damages that it is prepared to make good in the event of a failure on its part, or that of its end-entities. These matters should be defined in the certificate policy. Additional information, to help affected entities understand the provisions of the policy, may be included in the certificate policies extension in the form of policy qualifiers." This does NOT mean that limitations are defined by specifying the set of CP OIDs which are allowed or nor allowed. However RFC 3280 states: In a CA certificate, these policy information terms limit the set of policies for certification paths which include this certificate. When a CA does not wish to limit the set of policies for certification paths which include this certificate, it MAY assert the special policy anyPolicy, with a value of { 2 5 29 32 0 }. This is quite different from X.509 ! I believe that this is a mis-interpretation from the editors of RFC 3280. Denis > Are you saying that for example you are looking for > "some path that creates Qualified certificates" but only if the > CA certs are created under a policy indicating "some particular > more or less global UN policy concering CAs"' ? > > > >>>I am not sure that I follow you here. Can't you always cover different >>>certification policies using policy mappings? >> >>No. Policy mappings make mapping in any category. > > I was wrong here, since there is currently no provision to indicate in > a CA cert something about a policy/ > > >>Ooops ! This is a typo. I meant: The parameters for a given *validation >>policy* should be depended upon the OID of the validation policy. > > > that's less clear to me. besides "dependant", are you talking about a limited > number of syntaxes defined by some OID, or OIDs indicating some > parameter set similar as with a CP, or? > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3QDfDDR025830; Mon, 26 Apr 2004 06:41:13 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3QDfDQA025829; Mon, 26 Apr 2004 06:41:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3QDfBuj025822 for <ietf-pkix@imc.org>; Mon, 26 Apr 2004 06:41:12 -0700 (PDT) (envelope-from Peter.Sylvester@edelweb.fr) Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id i3QDfBN26501; Mon, 26 Apr 2004 15:41:11 +0200 (MEST) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Mon, 26 Apr 2004 15:41:11 +0200 (MET DST) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i3QDf6E24479; Mon, 26 Apr 2004 15:41:06 +0200 (MEST) Date: Mon, 26 Apr 2004 15:41:06 +0200 (MEST) From: Peter Sylvester <Peter.Sylvester@edelweb.fr> Message-Id: <200404261341.i3QDf6E24479@chandon.edelweb.fr> To: Peter.Sylvester@edelweb.fr, Denis.Pinkas@bull.net Subject: Re: FW: scvp Cc: ietf-pkix@imc.org, trevorf@exchange.microsoft.com X-Sun-Charset: US-ASCII Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> > > A signatory certificate in Europe may use a specific OID for the CP meaning > "Qualified Certificate". > > Such CP does not apply to CA certificates. But you can put them into a CA. In an end entity certificate, these policy information terms indicate the policy under which the certificate has been issued and the purposes for which the certificate may be used. In a CA certificate, these policy information terms limit the set of policies for certification paths which include this certificate. So far, no known texts says that CA certificates can be profiled by some policy. It seems that you introducing something new? Are you saying that for example you are looking for "some path that creates Qualified certificates" but only if the CA certs are created under a policy indicating "some particular more or less global UN policy concering CAs"' ? > > I am not sure that I follow you here. Can't you always cover different > > certification policies using policy mappings? > > No. Policy mappings make mapping in any category. I was wrong here, since there is currently no provision to indicate in a CA cert something about a policy/ > > Ooops ! This is a typo. I meant: The parameters for a given *validation > policy* should be depended upon the OID of the validation policy. that's less clear to me. besides "dependant", are you talking about a limited number of syntaxes defined by some OID, or OIDs indicating some parameter set similar as with a CP, or? Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3QCpP7u021743; Mon, 26 Apr 2004 05:51:25 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3QCpPLU021742; Mon, 26 Apr 2004 05:51:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3QCpP6l021733 for <ietf-pkix@imc.org>; Mon, 26 Apr 2004 05:51:25 -0700 (PDT) (envelope-from chokhani@orionsec.com) Received: from wchokhani3 (dpvc-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i3QCpOJA007359 for <ietf-pkix@imc.org>; Mon, 26 Apr 2004 08:51:24 -0400 From: "Santosh Chokhani" <chokhani@orionsec.com> To: <ietf-pkix@imc.org> Subject: RE: Cross certificate format Date: Mon, 26 Apr 2004 08:51:18 -0400 Message-ID: <000601c42b8d$2e76feb0$9a00a8c0@hq.orionsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal In-Reply-To: <OF5D57C7C3.BC80601F-ON85256E7F.0039EB19-85256E81.007ED839@us.ibm.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i3QCpP6l021737 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Tom: My reading of 3280 and X.509 is that a trust anchor need not even be a certificate. Thus, no checks need to be performed on a trust anchor at all. You get the DN, public key, algorithm OID, and parameters (if applicable) from a trust anchor. Any checks are gratuitous and not required by either standard. -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Tom Gindin Sent: Sunday, April 25, 2004 7:06 PM To: Jean-Marc Desperrier Cc: ietf-pkix@imc.org Subject: Re: Cross certificate format Jean-Marc: RFC 3280 doesn't say that anywhere. It does say that you don't need to validate the trust anchor as part of the path, but it isn't clear from the text that a v1 certificate is acceptable as a trust anchor - and it certainly isn't clear that a v1 certificate is acceptable as an issuer if it is a trust anchor while a v3 certificate with KeyUsage= { DigitalSignature, keyEncipherment } is not acceptable as an issuer even if it is a trust anchor. I believe that the correct rules for versions are something like the following: a certificate issued by a trust anchor which is represented by a certificate is verifiable if the anchor certificate is either a v1 certificate or a v3 certificate with the CA flag present in the basicConstraints extension. If the anchor certificate is a v3 certificate with the KeyUsage extension present, it is only a valid issuer certificate if keyCertSign is set. Tom Gindin Jean-Marc Desperrier <jmdesp@free.fr> Sent by: owner-ietf-pkix@mail.imc.org 04/21/2004 03:42 PM To: ietf-pkix@imc.org cc: Subject: Re: Cross certificate format Tom Gindin wrote: > RFC 3280 does not support the use of v1 self-signed > certificates, >which contain no extensions at all (see the text of RFC 3280's >basicConstraints section). However, a number of public CA's still have >them. > > Applications implementing the path validation algorithm of RFC3280 MUST accept them when they are used as trust anchors. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3QCcOTL020531; Mon, 26 Apr 2004 05:38:24 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3QCcOZI020530; Mon, 26 Apr 2004 05:38:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3QCcLRr020515 for <ietf-pkix@imc.org>; Mon, 26 Apr 2004 05:38:22 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net) Received: from clbull.frcl.bull.fr (IDENT:root@clbull.frcl.bull.fr [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id OAA73876; Mon, 26 Apr 2004 14:47:22 +0200 Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id OAA19015; Mon, 26 Apr 2004 14:34:11 +0200 Message-ID: <408D02B5.4050908@bull.net> Date: Mon, 26 Apr 2004 14:38:13 +0200 From: Denis Pinkas <Denis.Pinkas@bull.net> Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: Peter Sylvester <Peter.Sylvester@edelweb.fr> CC: ietf-pkix@imc.org, trevorf@exchange.microsoft.com Subject: Re: FW: scvp References: <200404261219.i3QCJ2K24284@chandon.edelweb.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Peter, >>Your question makes sense. The default validation algorithm is too simple >>and does not make any difference bewteen the CP appropriate for the >>end-entity certificate (i.e. endEntityCertificationPolicy) and the CP >>appropriate for the CA certificates (i.e. caCertificationPolicies). > > Where do you need such a difference? A signatory certificate in Europe may use a specific OID for the CP meaning "Qualified Certificate". Such CP does not apply to CA certificates. >>So these two parameters make one only for the default validation policy. It >>however obvious that more elaborate validation policies would be able to >>make the difference. > > > I am not sure that I follow you here. Can't you always cover different > certification policies using policy mappings? No. Policy mappings make mapping in any category. >>This raises me an observation. The parameters for a given CP should be >>depended upon the OID of the validation policy. > What parameters of a given CP? Addresses of a validation service, url for > cert lookup? Ooops ! This is a typo. I meant: The parameters for a given *validation policy* should be depended upon the OID of the validation policy. >>This means that a better (and much simpler) structure would be: >> >>Query ::= SEQUENCE { >> queriedCerts SEQUENCE SIZE (1..MAX) OF CertReference, >> checks CertChecks, >> wantBack WantBack, >> requestRefHash BOOLEAN DEFAULT TRUE, >> serverContextInfo OCTET STRING OPTIONAL, >> validityTime GeneralizedTime OPTIONAL, >> includePolResponse BOOLEAN DEFAULT FALSE, >> valPolicy ValidationPolicy, >> intermediateCerts [0] CertBundle OPTIONAL, >> revInfos [1] RevocationInfos OPTIONAL, >> queryExtensions [2] Extensions OPTIONAL } >> >>with: >> >> ValidationPolicy ::= SEQUENCE { >> algorithm OBJECT IDENTIFIER, >> parameters ANY DEFINED BY algorithm OPTIONAL } >> >>Then the parameters of the default validation policy should be defined. > > > Why is the following an independant booloan and not a WantBack? > includePolResponse BOOLEAN DEFAULT FALSE. > > Why are intermediate certs and revocationInformation independant > of the validation policy but trustanchors are not? intermediate certs and revocationInformation is just "useful" information that may be used or discarded. Denis Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3QCJ51w019098; Mon, 26 Apr 2004 05:19:05 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3QCJ50L019097; Mon, 26 Apr 2004 05:19:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3QCJ47U019091 for <ietf-pkix@imc.org>; Mon, 26 Apr 2004 05:19:04 -0700 (PDT) (envelope-from Peter.Sylvester@edelweb.fr) Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id i3QCJ2N25403; Mon, 26 Apr 2004 14:19:02 +0200 (MEST) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Mon, 26 Apr 2004 14:19:02 +0200 (MET DST) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i3QCJ2K24284; Mon, 26 Apr 2004 14:19:02 +0200 (MEST) Date: Mon, 26 Apr 2004 14:19:02 +0200 (MEST) From: Peter Sylvester <Peter.Sylvester@edelweb.fr> Message-Id: <200404261219.i3QCJ2K24284@chandon.edelweb.fr> To: Peter.Sylvester@edelweb.fr, Denis.Pinkas@bull.net Subject: Re: FW: scvp Cc: ietf-pkix@imc.org, trevorf@exchange.microsoft.com X-Sun-Charset: US-ASCII Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> > > Your question makes sense. The default validation algorithm is too simple > and does not make any difference bewteen the CP appropriate for the > end-entity certificate (i.e. endEntityCertificationPolicy) and the CP > appropriate for the CA certificates (i.e. caCertificationPolicies). Where do you need such a difference? > > So these two parameters make one only for the default validation policy. It > however obvious that more elaborate validation policies would be able to > make the difference. I am not sure that I follow you here. Can't you always cover different certification policies using policy mappings? > This raises me an observation. The parameters for a given CP should be > depended upon the OID of the validation policy. What parameters of a given CP? Addresses of a validation service, url for cert lookup? > > This means that a better (and much simpler) structure would be: > > Query ::= SEQUENCE { > queriedCerts SEQUENCE SIZE (1..MAX) OF CertReference, > checks CertChecks, > wantBack WantBack, > requestRefHash BOOLEAN DEFAULT TRUE, > serverContextInfo OCTET STRING OPTIONAL, > validityTime GeneralizedTime OPTIONAL, > includePolResponse BOOLEAN DEFAULT FALSE, > valPolicy ValidationPolicy, > intermediateCerts [0] CertBundle OPTIONAL, > revInfos [1] RevocationInfos OPTIONAL, > queryExtensions [2] Extensions OPTIONAL } > > with: > > ValidationPolicy ::= SEQUENCE { > algorithm OBJECT IDENTIFIER, > parameters ANY DEFINED BY algorithm OPTIONAL } > > Then the parameters of the default validation policy should be defined. Why is the following an independant booloan and not a WantBack? includePolResponse BOOLEAN DEFAULT FALSE. Why are intermediate certs and revocationInformation independant of the validation policy but trustanchors are not? Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3QBmCX6016704; Mon, 26 Apr 2004 04:48:12 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3QBmCF3016701; Mon, 26 Apr 2004 04:48:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3QBmABx016687 for <ietf-pkix@imc.org>; Mon, 26 Apr 2004 04:48:11 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net) Received: from clbull.frcl.bull.fr (IDENT:root@clbull.frcl.bull.fr [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id NAA68664; Mon, 26 Apr 2004 13:57:12 +0200 Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id NAA18558; Mon, 26 Apr 2004 13:44:00 +0200 Message-ID: <408CF6F2.8070600@bull.net> Date: Mon, 26 Apr 2004 13:48:02 +0200 From: Denis Pinkas <Denis.Pinkas@bull.net> Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: Peter Sylvester <Peter.Sylvester@edelweb.fr> CC: ietf-pkix@imc.org, trevorf@exchange.microsoft.com Subject: Re: FW: scvp References: <200404261127.i3QBRV724165@chandon.edelweb.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Peter, > what is the meaninng of > > endEntityCertificationPolicy vs caCertificationPolicies Your question makes sense. The default validation algorithm is too simple and does not make any difference bewteen the CP appropriate for the end-entity certificate (i.e. endEntityCertificationPolicy) and the CP appropriate for the CA certificates (i.e. caCertificationPolicies). So these two parameters make one only for the default validation policy. It however obvious that more elaborate validation policies would be able to make the difference. This raises me an observation. The parameters for a given CP should be depended upon the OID of the validation policy. This means that a better (and much simpler) structure would be: Query ::= SEQUENCE { queriedCerts SEQUENCE SIZE (1..MAX) OF CertReference, checks CertChecks, wantBack WantBack, requestRefHash BOOLEAN DEFAULT TRUE, serverContextInfo OCTET STRING OPTIONAL, validityTime GeneralizedTime OPTIONAL, includePolResponse BOOLEAN DEFAULT FALSE, valPolicy ValidationPolicy, intermediateCerts [0] CertBundle OPTIONAL, revInfos [1] RevocationInfos OPTIONAL, queryExtensions [2] Extensions OPTIONAL } with: ValidationPolicy ::= SEQUENCE { algorithm OBJECT IDENTIFIER, parameters ANY DEFINED BY algorithm OPTIONAL } Then the parameters of the default validation policy should be defined. Thanks for the observation. Denis > (without nitpicking that both are SEQUENCE). > > >> ParamsDefValPolicy :: = SEQUENCE { >> trustAnchors TrustAnchors, >> endEntityCertificationPolicy SEQUENCE OF OBJECT IDENTIFIER OPTIONAL, >> inhibitPolMap BOOLEAN DEFAULT FALSE, >> caCertificationPolicies SEQUENCE OF OBJECT IDENTIFIER OPTIONAL } >> > > > I may be able to understand that in order to to 3280 path validation, one > has to provide the seven input parameters in some way. Aren't some flags indicating > > require Explicit Policy > ignore Any Policy > > missing? > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3QBRfKe015555; Mon, 26 Apr 2004 04:27:41 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3QBRfAs015554; Mon, 26 Apr 2004 04:27:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3QBRd8m015539 for <ietf-pkix@imc.org>; Mon, 26 Apr 2004 04:27:40 -0700 (PDT) (envelope-from Peter.Sylvester@edelweb.fr) Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id i3QBRVN24767; Mon, 26 Apr 2004 13:27:31 +0200 (MEST) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Mon, 26 Apr 2004 13:27:31 +0200 (MET DST) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i3QBRV724165; Mon, 26 Apr 2004 13:27:31 +0200 (MEST) Date: Mon, 26 Apr 2004 13:27:31 +0200 (MEST) From: Peter Sylvester <Peter.Sylvester@edelweb.fr> Message-Id: <200404261127.i3QBRV724165@chandon.edelweb.fr> To: Peter.Sylvester@edelweb.fr, Denis.Pinkas@bull.net Subject: Re: FW: scvp Cc: ietf-pkix@imc.org, trevorf@exchange.microsoft.com X-Sun-Charset: US-ASCII Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> what is the meaninng of endEntityCertificationPolicy vs caCertificationPolicies (without nitpicking that both are SEQUENCE). > ParamsDefValPolicy :: = SEQUENCE { > trustAnchors TrustAnchors, > endEntityCertificationPolicy SEQUENCE OF OBJECT IDENTIFIER OPTIONAL, > inhibitPolMap BOOLEAN DEFAULT FALSE, > caCertificationPolicies SEQUENCE OF OBJECT IDENTIFIER OPTIONAL } > I may be able to understand that in order to to 3280 path validation, one has to provide the seven input parameters in some way. Aren't some flags indicating require Explicit Policy ignore Any Policy missing? Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3Q89TLr077307; Mon, 26 Apr 2004 01:09:29 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3Q89SLA077306; Mon, 26 Apr 2004 01:09:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3Q89R7b077241 for <ietf-pkix@imc.org>; Mon, 26 Apr 2004 01:09:27 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net) Received: from clbull.frcl.bull.fr (IDENT:root@clbull.frcl.bull.fr [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id KAA39638; Mon, 26 Apr 2004 10:18:21 +0200 Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id KAA16903; Mon, 26 Apr 2004 10:05:08 +0200 Message-ID: <408CC3A5.7070408@bull.net> Date: Mon, 26 Apr 2004 10:09:09 +0200 From: Denis Pinkas <Denis.Pinkas@bull.net> Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: Peter Sylvester <Peter.Sylvester@edelweb.fr> CC: ietf-pkix@imc.org, trevorf@exchange.microsoft.com Subject: Re: FW: scvp References: <200404231818.i3NIIZq18038@chandon.edelweb.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Peter and Trevor, I have major problems too. > in version 13 the syntax for a Query has been changed from > > Query ::= SEQUENCE { > queriedCerts SEQUENCE SIZE (1..MAX) OF CertReference, > checks CertChecks, > wantBack WantBack, > serverContextInfo [0] OCTET STRING OPTIONAL, > valPolicy [1] ValidationPolicy OPTIONAL, > validityTime [2] GeneralizedTime OPTIONAL, > trustAnchors [3] TrustAnchors OPTIONAL, > intermediateCerts [4] CertBundle OPTIONAL, > revInfos [5] RevocationInfos OPTIONAL, > queryExtensions [6] Extensions OPTIONAL } In this structure trustAnchors was more or less an alternative to valPolicy. In fact, IF the valPolicy is the default policy, THEN additional parameters MUST be provided. So the structure below does not fit as well. This leads to have the two following elements: valPolicy ValidationPolicy, paramsDefValPolicy ParamsDefValPolicy OPTIONAL, where the first one is mandatory and the second one optional. > to > > Query ::= SEQUENCE { > queriedCerts SEQUENCE SIZE (1..MAX) OF CertReference, > checks CertChecks, > wantBack WantBack, > requestRefHash BOOLEAN DEFAULT TRUE, > includePolResponce BOOLEAN DEFAULT FALSE, > inhibitPolMap BOOLEAN DEFAULT FALSE, > requireExplicitPol BOOLEAN DEFAULT FALSE, > ignoreAnyPol BOOLEAN DEFAULT FALSE, > valAlgorithm ValidationAlgorithm, > serverContextInfo [0] OCTET STRING OPTIONAL, > validityTime [1] GeneralizedTime OPTIONAL, > trustAnchors [2] TrustAnchors OPTIONAL, > intermediateCerts [3] CertBundle OPTIONAL, > revInfos [4] RevocationInfos OPTIONAL, > queryExtensions [5] Extensions OPTIONAL } I would thus propose to have something like: Query ::= SEQUENCE { queriedCerts SEQUENCE SIZE (1..MAX) OF CertReference, checks CertChecks, wantBack WantBack, requestRefHash BOOLEAN DEFAULT TRUE, serverContextInfo OCTET STRING OPTIONAL, validityTime GeneralizedTime OPTIONAL, includePolResponse BOOLEAN DEFAULT FALSE, valPolicy ValidationPolicy, paramsDefValPolicy [0] ParamsDefValPolicy OPTIONAL, intermediateCerts [1] CertBundle OPTIONAL, revInfos [2] RevocationInfos OPTIONAL, queryExtensions [3] Extensions OPTIONAL } and then something like: ParamsDefValPolicy :: = SEQUENCE { trustAnchors TrustAnchors, endEntityCertificationPolicy SEQUENCE OF OBJECT IDENTIFIER OPTIONAL, inhibitPolMap BOOLEAN DEFAULT FALSE, caCertificationPolicies SEQUENCE OF OBJECT IDENTIFIER OPTIONAL } Denis > I am not sure whether I am the only person unable to construct a parser. > > in version 14 an aditional flag has been added which is not available in the > Chapter 9. Is the isCA flag an orthogonal attribut to other validation > algorithms, or just to some of them, e.g,. the default name matching one? > > > Query ::= SEQUENCE { > queriedCerts SEQUENCE SIZE (1..MAX) OF CertReference, > checks CertChecks, > wantBack WantBack, > requestRefHash BOOLEAN DEFAULT TRUE, > includePolResponce BOOLEAN DEFAULT FALSE, > inhibitPolMap BOOLEAN DEFAULT FALSE, > requireExplicitPol BOOLEAN DEFAULT FALSE, > ignoreAnyPol BOOLEAN DEFAULT FALSE, > isCA BOOLEAN DEFAULT FALSE, > valAlgorithm ValidationAlgorithm, > serverContextInfo [0] OCTET STRING OPTIONAL, > validityTime [1] GeneralizedTime OPTIONAL, > trustAnchors [2] TrustAnchors OPTIONAL, > intermediateCerts [3] CertBundle OPTIONAL, > revInfos [4] RevocationInfos OPTIONAL, > keyUsage [5] KeyUsage OPTIONAL, > extendedKeyUsage [6] ExtKeyUsageSyntax OPTIONAL, > queryExtensions [7] Extensions OPTIONAL > producedAt [8] GeneralizedTime OPTIONAL} > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3PN5fa6068243; Sun, 25 Apr 2004 16:05:41 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3PN5fhu068242; Sun, 25 Apr 2004 16:05:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.106]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3PN5e1J068226 for <ietf-pkix@imc.org>; Sun, 25 Apr 2004 16:05:40 -0700 (PDT) (envelope-from tgindin@us.ibm.com) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e6.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i3PN5dfQ736786; Sun, 25 Apr 2004 19:05:39 -0400 Received: from d01ml062.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i3PN5nII063332; Sun, 25 Apr 2004 19:05:50 -0400 To: Jean-Marc Desperrier <jmdesp@free.fr> Cc: ietf-pkix@imc.org MIME-Version: 1.0 Subject: Re: Cross certificate format X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 From: Tom Gindin <tgindin@us.ibm.com> Message-ID: <OF5D57C7C3.BC80601F-ON85256E7F.0039EB19-85256E81.007ED839@us.ibm.com> Date: Sun, 25 Apr 2004 19:05:35 -0400 X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 6.0.2CF2 HFB2|March 16, 2004) at 04/25/2004 19:05:38, Serialize complete at 04/25/2004 19:05:38 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Jean-Marc: RFC 3280 doesn't say that anywhere. It does say that you don't need to validate the trust anchor as part of the path, but it isn't clear from the text that a v1 certificate is acceptable as a trust anchor - and it certainly isn't clear that a v1 certificate is acceptable as an issuer if it is a trust anchor while a v3 certificate with KeyUsage= { DigitalSignature, keyEncipherment } is not acceptable as an issuer even if it is a trust anchor. I believe that the correct rules for versions are something like the following: a certificate issued by a trust anchor which is represented by a certificate is verifiable if the anchor certificate is either a v1 certificate or a v3 certificate with the CA flag present in the basicConstraints extension. If the anchor certificate is a v3 certificate with the KeyUsage extension present, it is only a valid issuer certificate if keyCertSign is set. Tom Gindin Jean-Marc Desperrier <jmdesp@free.fr> Sent by: owner-ietf-pkix@mail.imc.org 04/21/2004 03:42 PM To: ietf-pkix@imc.org cc: Subject: Re: Cross certificate format Tom Gindin wrote: > RFC 3280 does not support the use of v1 self-signed certificates, >which contain no extensions at all (see the text of RFC 3280's >basicConstraints section). However, a number of public CA's still have >them. > > Applications implementing the path validation algorithm of RFC3280 MUST accept them when they are used as trust anchors. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3NKIltJ096025; Fri, 23 Apr 2004 13:18:47 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3NKIls7096024; Fri, 23 Apr 2004 13:18:47 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id i3NKIk8h096018 for <ietf-pkix@imc.org>; Fri, 23 Apr 2004 13:18:46 -0700 (PDT) (envelope-from wpolk@nist.gov) Received: from real1.localdomain ([192.168.2.10]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id i3NKIPrt002069; Fri, 23 Apr 2004 16:18:25 -0400 Received: from real1.localdomain (real1.localdomain [127.0.0.1]) by real1.localdomain (8.12.8/8.12.8) with ESMTP id i3NKIPfG020667; Fri, 23 Apr 2004 16:18:25 -0400 Received: (from apache@localhost) by real1.localdomain (8.12.8/8.12.8/Submit) id i3NKIOO7020665; Fri, 23 Apr 2004 16:18:24 -0400 Received: from pool-138-88-209-136.res.east.verizon.net (pool-138-88-209-136.res.east.verizon.net [138.88.209.136]) by webmail.nist.gov (IMP) with HTTP for <wpolk@localhost>; Fri, 23 Apr 2004 16:18:24 -0400 Message-ID: <1082751504.40897a10d920f@webmail.nist.gov> Date: Fri, 23 Apr 2004 16:18:24 -0400 From: wpolk@nist.gov To: Steven Bellovin <smb@research.att.com>, Russell Housley <housley@vigilsec.com> Cc: ietf-pkix@imc.org, Stephen Kent <kent@bbn.com> Subject: Forwarding SHA-224 to ADs References: <5.1.0.14.2.20040326160906.02f9d000@email.nist.gov> In-Reply-To: <5.1.0.14.2.20040326160906.02f9d000@email.nist.gov> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.1 X-Originating-IP: 138.88.209.136 X-NIST-MailScanner: Found to be clean X-MailScanner-From: wpolk@nist.gov Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> This message closes working group last call for "A 224-bit One-way Hash Function: SHA-224". I have reviewed the comments on the list since 26 March (when Last Call was initiated.) No technical issues are unresolved, so I am forwarding the document to the ADs for progression to RFC status. As suggested by the authors, we are requesting Informational Track for this specification. This document is currently available at http://www.ietf.org/internet-drafts/draft-ietf-pkix-sha224-01.txt. This specification will provide a stable reference for the SHA-224 algorithm, which is needed by several IETF specifications. At least two independent implementations exist and agree on the test vectors in this document. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3NJaiBY092728; Fri, 23 Apr 2004 12:36:44 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3NJaicI092727; Fri, 23 Apr 2004 12:36:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3NJahEk092719 for <ietf-pkix@imc.org>; Fri, 23 Apr 2004 12:36:43 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03487; Fri, 23 Apr 2004 15:36:44 -0400 (EDT) Message-Id: <200404231936.PAA03487@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-pkix@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pkix-certstore-http-06.txt Date: Fri, 23 Apr 2004 15:36:44 -0400 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. Title : Internet X.509 Public Key Infrastructure Operational Protocols: Certificate Store Access via HTTP Author(s) : P. Gutmann Filename : draft-ietf-pkix-certstore-http-06.txt Pages : 0 Date : 2004-4-23 The protocol conventions described in this document satisfy some of the operational requirements of the Internet Public Key Infrastructure (PKI). This document specifies the conventions for using the Hypertext Transfer Protocol (HTTP/HTTPS) as an interface mechanism to obtain certificates and certificate revocation lists (CRLs) from PKI repositories. Additional mechanisms addressing PKIX operational requirements are specified in separate documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-certstore-http-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pkix-certstore-http-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pkix-certstore-http-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-4-23150642.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pkix-certstore-http-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pkix-certstore-http-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-23150642.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3NIInNm084288; Fri, 23 Apr 2004 11:18:49 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3NIInZK084287; Fri, 23 Apr 2004 11:18:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3NIIm0n084273 for <ietf-pkix@imc.org>; Fri, 23 Apr 2004 11:18:48 -0700 (PDT) (envelope-from Peter.Sylvester@edelweb.fr) Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id i3NIIdN20485; Fri, 23 Apr 2004 20:18:39 +0200 (MEST) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Fri, 23 Apr 2004 20:18:39 +0200 (MET DST) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i3NIIZq18038; Fri, 23 Apr 2004 20:18:35 +0200 (MEST) Date: Fri, 23 Apr 2004 20:18:35 +0200 (MEST) From: Peter Sylvester <Peter.Sylvester@edelweb.fr> Message-Id: <200404231818.i3NIIZq18038@chandon.edelweb.fr> To: ietf-pkix@imc.org, trevorf@exchange.microsoft.com Subject: Re: FW: scvp Cc: Peter.Sylvester@edelweb.fr X-Sun-Charset: US-ASCII Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> in version 13 the syntax for a Query has been changed from Query ::= SEQUENCE { queriedCerts SEQUENCE SIZE (1..MAX) OF CertReference, checks CertChecks, wantBack WantBack, serverContextInfo [0] OCTET STRING OPTIONAL, valPolicy [1] ValidationPolicy OPTIONAL, validityTime [2] GeneralizedTime OPTIONAL, trustAnchors [3] TrustAnchors OPTIONAL, intermediateCerts [4] CertBundle OPTIONAL, revInfos [5] RevocationInfos OPTIONAL, queryExtensions [6] Extensions OPTIONAL } to Query ::= SEQUENCE { queriedCerts SEQUENCE SIZE (1..MAX) OF CertReference, checks CertChecks, wantBack WantBack, requestRefHash BOOLEAN DEFAULT TRUE, includePolResponce BOOLEAN DEFAULT FALSE, inhibitPolMap BOOLEAN DEFAULT FALSE, requireExplicitPol BOOLEAN DEFAULT FALSE, ignoreAnyPol BOOLEAN DEFAULT FALSE, valAlgorithm ValidationAlgorithm, serverContextInfo [0] OCTET STRING OPTIONAL, validityTime [1] GeneralizedTime OPTIONAL, trustAnchors [2] TrustAnchors OPTIONAL, intermediateCerts [3] CertBundle OPTIONAL, revInfos [4] RevocationInfos OPTIONAL, queryExtensions [5] Extensions OPTIONAL } I am not sure whether I am the only person unable to construct a parser. in version 14 an aditional flag has been added which is not available in the Chapter 9. Is the isCA flag an orthogonal attribut to other validation algorithms, or just to some of them, e.g,. the default name matching one? Query ::= SEQUENCE { queriedCerts SEQUENCE SIZE (1..MAX) OF CertReference, checks CertChecks, wantBack WantBack, requestRefHash BOOLEAN DEFAULT TRUE, includePolResponce BOOLEAN DEFAULT FALSE, inhibitPolMap BOOLEAN DEFAULT FALSE, requireExplicitPol BOOLEAN DEFAULT FALSE, ignoreAnyPol BOOLEAN DEFAULT FALSE, isCA BOOLEAN DEFAULT FALSE, valAlgorithm ValidationAlgorithm, serverContextInfo [0] OCTET STRING OPTIONAL, validityTime [1] GeneralizedTime OPTIONAL, trustAnchors [2] TrustAnchors OPTIONAL, intermediateCerts [3] CertBundle OPTIONAL, revInfos [4] RevocationInfos OPTIONAL, keyUsage [5] KeyUsage OPTIONAL, extendedKeyUsage [6] ExtKeyUsageSyntax OPTIONAL, queryExtensions [7] Extensions OPTIONAL producedAt [8] GeneralizedTime OPTIONAL} Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3NFNDCW069034; Fri, 23 Apr 2004 08:23:13 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3NFND3t069033; Fri, 23 Apr 2004 08:23:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from hotmail.com (bay10-dav37.bay10.hotmail.com [64.4.37.211]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3NFND8Q069016 for <ietf-pkix@imc.org>; Fri, 23 Apr 2004 08:23:13 -0700 (PDT) (envelope-from jaleelpa@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 23 Apr 2004 08:23:08 -0700 Received: from 203.123.181.226 by bay10-dav37.bay10.hotmail.com with DAV; Fri, 23 Apr 2004 15:23:08 +0000 X-Originating-IP: [203.123.181.226] X-Originating-Email: [jaleelpa@hotmail.com] X-Sender: jaleelpa@hotmail.com From: "Jaleel P.A" <jaleelpa@hotmail.com> To: <ietf-pkix@imc.org> Subject: RE: Cross certificate format Date: Fri, 23 Apr 2004 20:53:07 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcQnw/jU0rLVV64rRZ24IYUJCq38pwBgsBfA In-Reply-To: <OFB6C8C5FA.85168521-ON85256E7D.0057CD3B-85256E7D.005A2AAC@us.ibm.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Message-ID: <BAY10-DAV37Rf6Ci6nx00048bd6@hotmail.com> X-OriginalArrivalTime: 23 Apr 2004 15:23:08.0866 (UTC) FILETIME=[E1F5FA20:01C42946] Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Hi Can anybody attach a sample cross certificate. Thanks Jaleel -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Tom Gindin Sent: Wednesday, April 21, 2004 9:55 PM To: Jaleel P.A Cc: ietf-pkix@imc.org Subject: Re: Cross certificate format Jaleel: As several of the earlier responses have pointed out, cross certificates are just those CA certificates whose issuer and subject are different. CA certificates (except v1 self-signed certificates) are slightly different from non-CA certificates in the following ways: a) The basic constraints extension is present and has the "CA" flag set. b) The key usage extension is present and has the keyCertSign bit set, and often the cRLSign bit as well. There are other, less common, extensions which are typically found in CA certificates and not in others. These include Name Constraints, Policy Constraints, Policy Mappings, and Inhibit Any-Policy. RFC 3280 does not support the use of v1 self-signed certificates, which contain no extensions at all (see the text of RFC 3280's basicConstraints section). However, a number of public CA's still have them. Tom Gindin P.S. The opinions above are my own, and not necessarily those of my employer. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3N7sQur011259; Fri, 23 Apr 2004 00:54:26 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3N7sQRF011255; Fri, 23 Apr 2004 00:54:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from ntexch03.office.sia.it (clients.sia.it [193.203.230.22] (may be forged)) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3N7sI2O011199 for <ietf-pkix@imc.org>; Fri, 23 Apr 2004 00:54:25 -0700 (PDT) (envelope-from adriano.santoni@actalis.it) Received: by ntexch03.office.sia.it with Internet Mail Service (5.5.2657.72) id <HJMHA8KQ>; Fri, 23 Apr 2004 09:54:24 +0200 Message-ID: <BE82E060F5EA2D44A4CFCFFA8363958803B4BB4B@ntexch00.office.sia.it> From: Santoni Adriano <adriano.santoni@actalis.it> To: "'pgut001@cs.auckland.ac.nz'" <pgut001@cs.auckland.ac.nz> Cc: ietf-pkix@imc.org Subject: R: I: R: RFC3280: doubt on the use of UTF8String in encoding RDNs Date: Fri, 23 Apr 2004 09:54:19 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i3N7sQ2O011243 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> A rule that is "at odds with reality" should not be expressed in terms of MUST, but rather in terms of SHOULD. I wonder how it came that RFC 3280 reached the status of an official IETF standard, if it contains one or more areas that are "at odds with reality". I suppose the answer is one of these: - RFC 3280 does not really contain areas that are "at odds with reality" - it's just that we do not understand them; - containing areas that are "at odds with reality" is not an obstacle to becoming a standard; - expressions like "MUST" in IETF standard are really to be taken as mere suggestions; - nobody really cares. Adriano -----Messaggio originale----- Da: pgut001 [mailto:pgut001@medusa01.cs.auckland.ac.nz] Per conto di pgut001@cs.auckland.ac.nz Inviato: venerdì 23 aprile 2004 4.33 A: adriano.santoni@actalis.it; dsolo@alum.mit.edu; rhousley@rsasecurity.com; wford@verisign.com; wpolk@nist.gov Cc: ietf-pkix@imc.org Oggetto: Re: I: R: RFC3280: doubt on the use of UTF8String in encoding RDNs Santoni Adriano <adriano.santoni@actalis.it> writes: >If the answer is YES, I would like your personal opinion about the >great majority (sai 99,9%) of all CAs all over the planet not being >conformant to RFC 3280 and neither to RFC 2459, as far as this >particular PKIX prescription is concerned. Here we go again... this really should be an FAQ, given the number of times it's come up, and will no doubt continue to come up. So the standard answer is: Most people are ignoring the UTF-8 requirement because of backwards- compatibility concerns, both for existing certs and for existing applications. Don't worry about it, it's quite normal, this is just another area where the RFC is at odds with reality. Peter. *******************Internet Email Confidentiality Footer******************* Qualsiasi utilizzo non autorizzato del presente messaggio nonche' dei suoi allegati e' vietato e potrebbe costituire reato. Se lei ha ricevuto erroneamente il presente messaggio, Le saremmo grati se, via e-mail, ce ne comunicasse la ricezione e provvedesse alla distruzione del messaggio stesso e dei suoi eventuali allegati. Le dichiarazioni contenute nel presente messaggio nonche' nei suoi eventuali allegati devono essere attribuite esclusivamente al mittente e non possono essere considerate come trasmesse o autorizzate da SIA S.p.A.; le medesime dichiarazioni non impegnano SIA S.p.A. nei confronti del destinatario o di terzi. SIA S.p.A. non si assume alcuna responsabilita' per eventuali intercettazioni, modifiche o danneggiamenti del presente messaggio e-mail. Any unauthorized use of this e-mail or any of its attachments is prohibited and could constitute an offence. If you are not the intended addressee please advise immediately the sender by using the reply facility in your e-mail software and destroy the message and its attachments. The statements and opinions expressed in this e-mail message are those of the author of the message and do not necessarily represent those of SIA. Besides, The contents of this message shall be understood as neither given nor endorsed by SIA S.p.A.. SIA S.p.A. does not accept liability for corruption, interception or amendment, if any, or the consequences thereof. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3N3e7Ih041348; Thu, 22 Apr 2004 20:40:07 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3N3e7cV041347; Thu, 22 Apr 2004 20:40:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp.cs.auckland.ac.nz (smtp.cs.auckland.ac.nz [130.216.33.151]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3N3e6Ef041341 for <ietf-pkix@imc.org>; Thu, 22 Apr 2004 20:40:06 -0700 (PDT) (envelope-from pgut001@cs.auckland.ac.nz) Received: from medusa01 (medusa01.cs.auckland.ac.nz [130.216.34.33]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id 6511934181; Fri, 23 Apr 2004 15:37:30 +1200 (NZST) Received: from pgut001 by medusa01 with local (Exim 4.30) id 1BGrXw-0006Rf-Pa; Fri, 23 Apr 2004 15:40:12 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-pkix@imc.org, lloyd@randombit.net Subject: Re: Status of draft-ietf-pkix-certstore-http? In-Reply-To: <20040421142210.GA15955@acm.jhu.edu> Message-Id: <E1BGrXw-0006Rf-Pa@medusa01> Date: Fri, 23 Apr 2004 15:40:12 +1200 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Jack Lloyd <lloyd@randombit.net> writes: >Is there a public server anywhere I can hit with requests? Or, better, a >server implementation I can run locally with various strange test certs? Not that I know of. There are several implementations, but I don't know if any of their users would want them being hit with arbitrary requests from the net, or if they're even visible on the net. OTOH doing an implementation using (say) a web-enabled database takes almost no time, there's a MySQL- based one that was supposedly done in about 30 minutes, it's just a case of mapping the portions of an incoming URI to a "SELECT FROM certificates WHERE $URI_key_portion = $URI_value_portion", for various values of $URI_key_portion. I did a (fairly minimal) C one in about 2 pages of code (this is based on a much older version of the spec which does multiple-cert responses as a PKCS #7 cert chain rather than a multipart response, among other things), and there's a JDBC one as well... I'll see if I can get the code for that publicised. Actually since the person who wrote it reads this list: Any chance of posting the code? It also depends on what you want to test, if all you want to check is the ability to grab certs via HTTP, you can just put some certs at a fixed location on a web server, since the client can't tell the difference between static and dynamic content. That's how I first tested the client-side code years ago. Send me private mail if you want the implementation I did. Generally it'd be publicly available, but I've been re-doing some unrelated portions of the code recently and it's not really fit to be released yet. Peter. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3N2XdMZ037689; Thu, 22 Apr 2004 19:33:39 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3N2Xdnn037688; Thu, 22 Apr 2004 19:33:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp.cs.auckland.ac.nz (smtp.cs.auckland.ac.nz [130.216.33.151]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3N2XVd4037672 for <ietf-pkix@imc.org>; Thu, 22 Apr 2004 19:33:31 -0700 (PDT) (envelope-from pgut001@cs.auckland.ac.nz) Received: from medusa01 (medusa01.cs.auckland.ac.nz [130.216.34.33]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id E9BF6341B5; Fri, 23 Apr 2004 14:30:47 +1200 (NZST) Received: from pgut001 by medusa01 with local (Exim 4.30) id 1BGqVN-0006NA-Lr; Fri, 23 Apr 2004 14:33:29 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: adriano.santoni@actalis.it, dsolo@alum.mit.edu, rhousley@rsasecurity.com, wford@verisign.com, wpolk@nist.gov Subject: Re: I: R: RFC3280: doubt on the use of UTF8String in encoding RDNs Cc: ietf-pkix@imc.org In-Reply-To: <BE82E060F5EA2D44A4CFCFFA8363958803B4BB0E@ntexch00.office.sia.it> Message-Id: <E1BGqVN-0006NA-Lr@medusa01> Date: Fri, 23 Apr 2004 14:33:29 +1200 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Santoni Adriano <adriano.santoni@actalis.it> writes: >If the answer is YES, I would like your personal opinion about the great >majority (sai 99,9%) of all CAs all over the planet not being conformant to >RFC 3280 and neither to RFC 2459, as far as this particular PKIX prescription >is concerned. Here we go again... this really should be an FAQ, given the number of times it's come up, and will no doubt continue to come up. So the standard answer is: Most people are ignoring the UTF-8 requirement because of backwards- compatibility concerns, both for existing certs and for existing applications. Don't worry about it, it's quite normal, this is just another area where the RFC is at odds with reality. Peter. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3MMc1jh024110; Thu, 22 Apr 2004 15:38:01 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3MMc18u024109; Thu, 22 Apr 2004 15:38:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail1.atl.registeredsite.com (nobody@mail1.atl.registeredsite.com [64.224.219.75]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3MMc0jw024102 for <ietf-pkix@imc.org>; Thu, 22 Apr 2004 15:38:00 -0700 (PDT) (envelope-from egerck@nma.com) Received: from taurus.hosting4u.net (taurus.hosting4u.net [209.35.191.122]) by mail1.atl.registeredsite.com (8.12.10/8.12.8) with ESMTP id i3MMc5m8026520 for <ietf-pkix@imc.org>; Thu, 22 Apr 2004 22:38:05 GMT Received: from nma.com ([63.204.17.85]) by taurus.hosting4u.net ; Thu, 22 Apr 2004 17:38:04 -0500 Message-ID: <40884936.826AB8A2@nma.com> Date: Thu, 22 Apr 2004 15:37:42 -0700 From: Ed Gerck <egerck@nma.com> X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: PKIX <ietf-pkix@imc.org> Subject: Re: new -- Clarification Note proposal on cert revocation - References: <004c01c427c5$209283d0$9a00a8c0@hq.orionsec.com> <40874ECC.A3006F03@nma.com> <200404221214.i3MCE7RK017678@stingray.missi.ncsc.mil> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Rcpt-To: <ietf-pkix@imc.org> Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Dave, Clearly, an RP can rely on (trust) any source for revocation information of a cert issued by a CA. Still, this does not mean that the revocation status of a cert is defined by that RP or by conditions authoritatively defined by that RP. That revocation status is defined by conditions set forth authoritatively by the issuer CA, whether that RP agrees with them or not, whether that RP reads them or not. Here, a tree falls even though no one may watch it fall. Moreover, when an RP decides to rely on any source for revocation information and something goes wrong (e.g., that cert turns out to have been listed as revoked by a CRL issuer identified in the certificate, or by the issuer CA), will the RP be able to claim to anyone that it relied on the cert based on anything else but the RP's own risk in such a case? No. The RP has 100% of the risk if the RP has not followed the conditions defined by the issuer CA to learn the revocation status of a cert issued by that CA. Further, what good or harm has X.509 done in such a case? Nothing, either way. There is no violation of X.509 -- if an RP decides to be on its own and blindly ignores the conditions for reliance defined in X.509 in terms of revocation conditions and where to find them, that RP was and is on its own -- proof by construction. The matter is different in terms of validation vs. revocation. An RP is always authoritative for validation of a certificate. And also has 100% of the risk. The RP cannot rely on the issuer CA to define the validation status of a cert, which is a matter of local policy. Finally, in the context of an organization, will the organization allow each employee to decide what source to rely on for revocation information of a cert issued by a CA? Probably not, for the reasons noted above. The organization will want to enforce the restrictions on cert reliance placed by the issuer CA (including when a cert is revoked or not) in addition to their own restrictions on validation of that cert (e.g., the path used to verify the revocation information). Cheers, Ed Gerck "David P. Kemp" wrote: > > A relying party is obviously authoritative for the sources of > information that that relying party trusts. This cannot be > disputed - proof by construction. > > If an RP says a CA is the only authoritative source of revocation > information for that CA's certs, then it is (for that RP). If > a different RP trusts some other source, then the CA is not > authoritative. > > PKIX can only seek to put in place standards capable of > faithfully and securely mechanizing RP trust policies without > introducing unrecognized or difficult to foresee violations > of those policies (i.e., vulnerabilities). > > PKIX does not attempt to tell you, or Santosh, what to believe. > > Ed Gerck wrote: > > > Santosh, > > > > You do not believe that CAs are authoritative for revocation > > conditions. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3MGiadO090560; Thu, 22 Apr 2004 09:44:36 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3MGiamK090559; Thu, 22 Apr 2004 09:44:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3MGiaFw090552 for <ietf-pkix@imc.org>; Thu, 22 Apr 2004 09:44:36 -0700 (PDT) (envelope-from chokhani@orionsec.com) Received: from wchokhani3 (dpvc-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i3MGiWK5020591 for <ietf-pkix@imc.org>; Thu, 22 Apr 2004 12:44:37 -0400 From: "Santosh Chokhani" <chokhani@orionsec.com> To: "'PKIX'" <ietf-pkix@imc.org> Subject: RE: new -- Clarification Note proposal on cert revocation - Date: Thu, 22 Apr 2004 12:44:27 -0400 Message-ID: <00c501c42889$19409530$9a00a8c0@hq.orionsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <200404221214.i3MCE7RK017678@stingray.missi.ncsc.mil> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Dave: I agree with you. -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of David P. Kemp Sent: Thursday, April 22, 2004 8:46 AM To: PKIX Subject: Re: new -- Clarification Note proposal on cert revocation - A relying party is obviously authoritative for the sources of information that that relying party trusts. This cannot be disputed - proof by construction. If an RP says a CA is the only authoritative source of revocation information for that CA's certs, then it is (for that RP). If a different RP trusts some other source, then the CA is not authoritative. PKIX can only seek to put in place standards capable of faithfully and securely mechanizing RP trust policies without introducing unrecognized or difficult to foresee violations of those policies (i.e., vulnerabilities). PKIX does not attempt to tell you, or Santosh, what to believe. Ed Gerck wrote: > Santosh, > > You do not believe that CAs are authoritative for revocation > conditions. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3MFK6v2082172; Thu, 22 Apr 2004 08:20:06 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3MFK691082171; Thu, 22 Apr 2004 08:20:06 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.8) with ESMTP id i3MFK5dS082165 for <ietf-pkix@imc.org>; Thu, 22 Apr 2004 08:20:05 -0700 (PDT) (envelope-from tim.polk@nist.gov) Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id i3MFJRrt023809; Thu, 22 Apr 2004 11:19:27 -0400 Received: from krdp8.nist.gov (krdp8.ncsl.nist.gov [129.6.54.113]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id i3MFId8s009470; Thu, 22 Apr 2004 11:18:40 -0400 (EDT) Message-Id: <5.1.0.14.2.20040422110410.03045e70@email.nist.gov> X-Sender: wpolk@email.nist.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 22 Apr 2004 11:21:06 -0400 To: Steve Hanna <Steve.Hanna@Sun.COM>, ietf-pkix@imc.org From: Tim Polk <tim.polk@nist.gov> Subject: Re: Successor to RFC 3280? Cc: Stephen Kent <kent@bbn.com>, david.cooper@nist.gov In-Reply-To: <40620A08.20BBD37E@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-NIST-MailScanner: Found to be clean X-MailScanner-From: tim.polk@nist.gov Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Steve, I believe we have WG consensus that a successor to 3280 is an appropriate work item. In light of the controlled shutdown of PKIX is, I believe the scope must be limited to the task of progressing to Draft Status. That means we will need to remove those features that do not have two implementations, and clarify any errors and inconsistencies. Any other work needs to be performed in separate documents (and probably needs to progress as a personal draft.) I am volunteering David Cooper from NIST to act as lead editor for the successor to 3280. He was a key contributor, particularly with respect to the path validation algorithm, in the development of 3280 itself and has been a key player in the interoperability testing. In addition, David participated in the revisions to the ISO specification which leaves us well positioned to maintain the consistency of the ISO and IETF documents. Thanks, Tim Polk Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3MCkHN3068155; Thu, 22 Apr 2004 05:46:17 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3MCkHZh068154; Thu, 22 Apr 2004 05:46:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3MCkGJ9068147 for <ietf-pkix@imc.org>; Thu, 22 Apr 2004 05:46:16 -0700 (PDT) (envelope-from dpkemp@missi.ncsc.mil) Message-ID: <200404221214.i3MCE7RK017678@stingray.missi.ncsc.mil> Date: Thu, 22 Apr 2004 08:46:08 -0400 From: "David P. Kemp" <dpkemp@missi.ncsc.mil> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: PKIX <ietf-pkix@imc.org> Subject: Re: new -- Clarification Note proposal on cert revocation - References: <004c01c427c5$209283d0$9a00a8c0@hq.orionsec.com> <40874ECC.A3006F03@nma.com> In-Reply-To: <40874ECC.A3006F03@nma.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> A relying party is obviously authoritative for the sources of information that that relying party trusts. This cannot be disputed - proof by construction. If an RP says a CA is the only authoritative source of revocation information for that CA's certs, then it is (for that RP). If a different RP trusts some other source, then the CA is not authoritative. PKIX can only seek to put in place standards capable of faithfully and securely mechanizing RP trust policies without introducing unrecognized or difficult to foresee violations of those policies (i.e., vulnerabilities). PKIX does not attempt to tell you, or Santosh, what to believe. Ed Gerck wrote: > Santosh, > > You do not believe that CAs are authoritative for revocation > conditions. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3M4nWkg048424; Wed, 21 Apr 2004 21:49:32 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3M4nWoh048423; Wed, 21 Apr 2004 21:49:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail10.atl.registeredsite.com (nobody@mail10.atl.registeredsite.com [64.224.219.84]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3M4nW5b048417 for <ietf-pkix@imc.org>; Wed, 21 Apr 2004 21:49:32 -0700 (PDT) (envelope-from egerck@nma.com) Received: from taurus.hosting4u.net (taurus.hosting4u.net [209.35.191.122]) by mail10.atl.registeredsite.com (8.12.8/8.12.8) with ESMTP id i3M4nbNd018157 for <ietf-pkix@imc.org>; Thu, 22 Apr 2004 04:49:37 GMT Received: from nma.com ([63.204.17.85]) by taurus.hosting4u.net ; Wed, 21 Apr 2004 23:49:35 -0500 Message-ID: <40874ECC.A3006F03@nma.com> Date: Wed, 21 Apr 2004 21:49:16 -0700 From: Ed Gerck <egerck@nma.com> X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: PKIX <ietf-pkix@imc.org> Subject: Re: new -- Clarification Note proposal on cert revocation - References: <004c01c427c5$209283d0$9a00a8c0@hq.orionsec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Rcpt-To: <ietf-pkix@imc.org> Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Santosh, You do not believe that CAs are authoritative for revocation conditions. You also think that there is no mechanism to limit the time of delegation; no way for revoking the delegation. Yet, an issuer CA can revoke the signing cert, hence revoking the revocation delegation for all certs signed by that cert. By ignoring the authoritative role of CAs in revocation conditions, you will not improve the authoritative role of CRL issuers, however. You will not make the role of OCSP responders clearer, either. You will just create more confusion on revocation delegation, making the position of an issuer CA even stronger (why should you get revocation from a delegate if you can get the real thing without pesky questions?). The bottom line of what I'm saying is that revocation in PKIX is not as bad as "flip a coin to know if this cert is revoked" (as it may seem) but can be understood and verified by a relying party, to the extent the RP desires. As I showed, the only limitation is how much time and work the RP is willing to spend, not the result. The result is ultimately unambiguous and verifiable. X.509 is not perfect. But we shall not demand perfection. Pointing out that PKIX cert revocation is ultimately unambiguous for an RP is, IMO a great clarification -- if this lit's archives and my private mailbox can be proof. Yes, it does renovate some notions. However, to renovate is not to destroy. It is to respect the foundations, and so restore works for the general good. Thanks again. Cheers, Ed Gerck Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3LJgbHS003849; Wed, 21 Apr 2004 12:42:37 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3LJgbUd003848; Wed, 21 Apr 2004 12:42:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp-ft6.fr.colt.net (smtp-ft6.fr.colt.net [213.41.78.209]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3LJg6tl003809 for <ietf-pkix@imc.org>; Wed, 21 Apr 2004 12:42:36 -0700 (PDT) (envelope-from jmdesp@free.fr) Received: from free.fr (host.104.92.68.195.rev.coltfrance.com [195.68.92.104]) by smtp-ft6.fr.colt.net with ESMTP id i3LJg4R17779 for <ietf-pkix@imc.org>; Wed, 21 Apr 2004 21:42:04 +0200 Message-ID: <4086CEB4.10402@free.fr> Date: Wed, 21 Apr 2004 21:42:44 +0200 From: Jean-Marc Desperrier <jmdesp@free.fr> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:) Gecko/20040226 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: Re: Cross certificate format References: <OFB6C8C5FA.85168521-ON85256E7D.0057CD3B-85256E7D.005A2AAC@us.ibm.com> In-Reply-To: <OFB6C8C5FA.85168521-ON85256E7D.0057CD3B-85256E7D.005A2AAC@us.ibm.com> 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: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Tom Gindin wrote: > RFC 3280 does not support the use of v1 self-signed certificates, >which contain no extensions at all (see the text of RFC 3280's >basicConstraints section). However, a number of public CA's still have >them. > > Applications implementing the path validation algorithm of RFC3280 MUST accept them when they are used as trust anchors. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3LHlEhC094245; Wed, 21 Apr 2004 10:47:14 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3LHlEGe094244; Wed, 21 Apr 2004 10:47:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3LHlDVi094238 for <ietf-pkix@imc.org>; Wed, 21 Apr 2004 10:47:13 -0700 (PDT) (envelope-from Peter.Sylvester@edelweb.fr) Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id i3LHlDN14639; Wed, 21 Apr 2004 19:47:13 +0200 (MEST) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Wed, 21 Apr 2004 19:47:13 +0200 (MET DST) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i3LHl9910356; Wed, 21 Apr 2004 19:47:09 +0200 (MEST) Date: Wed, 21 Apr 2004 19:47:09 +0200 (MEST) From: Peter Sylvester <Peter.Sylvester@edelweb.fr> Message-Id: <200404211747.i3LHl9910356@chandon.edelweb.fr> To: ietf-pkix@imc.org, trevorf@exchange.microsoft.com Subject: Re: FW: scvp Cc: Peter.Sylvester@edelweb.fr X-Sun-Charset: US-ASCII Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> > > Reposting at Peters request Thanks > > -----Original Message----- > From: Trevor Freeman > Sent: Tuesday, April 13, 2004 11:25 AM > To: 'Peter Sylvester'; ietf-pkix@imc.org > Subject: RE: scvp > > Hi Peter, > Respnces below. > > The change to 3.4 permits a SCVP server to return a cached response in > which case it cannot include any request specific values. A client could > require a non-cached repsoce in which case this value must be present. > > There is no requiremnt today that SCVP client must have a name in the > genral name space. They can simply use soemthing generated localy and > use that which seems a big plus. There are least one server and all its clients involved which must agree on the identifications. Furthermore, the identifications are also used by other relying parties. this means that all participating entities need to have a comon understanding of an identification. What is the big plus of having an untyped opaque identifier without any possibility for structuring, this seems to me that the requirement Mechanisms for matching this identifier with the > authenticated identity depends on local DPV server conditions and/or > the validation policy. seems unnecessarily difficult in this case. What is the real benefit over GeneralName. I wonder how one can implement a general solution in a product without specific code or an " identifier to authenticated identity mapping function" specifiable dynamically. On the other hand, using generalName allows to have a simple local definition (identifier must be one of the identifiers in the authenticated indentity); furthermore identifiers are not just for loop control, but supposed to be displayed or otherwise shown to some user. of course, one can always show a hexadecimal representation of the identifier but again, the same difficulty to map this identification of the 'requester' (not the request) to any of the authenticated entity remains. Well, on can always recomment to encode a generalname in the octet string ... oops, that doesn't work, either. If the request or repnoce is signed > then you get a name in the certifcate. You can have more than one identification in a certificate using subject alternatename extension. > > The octet string vs. oid with any was a arbitary chioce since boht > chiver the same end. Does this refer to 4.8.5? The question is why is it necessary to use all different known techniques in this text in a arbitrary choice, at some places it is any defined by at others it is an octet string encapsulating a structure, and to invent at least one new opaque. (ValidationAalg, replywantback, 'identifiers' in requestor, responder, etc) The argument of encapsulation of some structure in an octet string comes from the fact that some encoders/decoders cannot treat correctly 'any defined by' with unknown oids. If one wants to support them then there should be no any defined by at all. Or, if the number of types syntaxes is small and stable, then an additional encapsulation is not necessary. Another potential reason is that the encapsulated type cannot easly be encode with DER, well, saying 'The octet string contains a boolean type' is not ok, I may have overlooked if it is excluded to have a XER encoding of an ASN.1 type. There is a confusion between "ValidationAlg" and "ValidationAlgorithm" I have no asnwer to the last question. As far as I remember there is nowhere a place to have a contentinfo, i.e. an SCVP response as part of the response. > > Trevor > > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] > On Behalf Of Peter Sylvester > Sent: Tuesday, April 13, 2004 3:56 AM > To: ietf-pkix@imc.org > Subject: scvp > > > > > SCVP 14: > 3.4 Requestor > > The OPTIONAL requestor item is a reference local to the requestor. > The value is only of local significance to the requestor. If the > SCVP client includes a requestor value in the request, then the > SCVP server MUST return the same value in a unique SCVP response. > The SCVP server MAY omit the requestor value from cached SCVP > responses. > > SCVP 13: > > The OPTIONAL requestor item is a reference local to the requestor. > The value is only of local significance to the requestor. If the > SCVP client includes a requestor value in the request, then the > SCVP server MUST return the same value in the response. > > As far as I remember, there was no discussion about this. > > I think that the following sentence of 4.6 does not respect the > requirements. > > 4.6 Requestor > > The OPTIONAL requestor item is used to identify the requestor. The > value is only of local significance to the requestor. > > requirements say: > > When the DPV request is authenticated, the client SHOULD be able to > include a client identifier in the request for the DPV server to copy > into the response. Mechanisms for matching this identifier with the > authenticated identity depends on local DPV server conditions and/or > the validation policy. The DPV server MAY choose to blindly copy the > identifier, omit the identifier, or return an error response. > > IMO this clearly indicates that the identifier has a meaning for the > server. > > > Unless I have overlooked something, I have not seen any response > to the following. Maybe the content of my message considered > as pure nonsense. > > > Date: Tue Oct 28 18:43:58 2003 > To: kent@bbn.com, ietf-pkix@imc.org, trevorf@windows.microsoft.com > Subject: RE: SCVP additions > > hello, > > It would be nice to hear whether all or which comments > about SCVP have been addressed. Unless I have overlooked > something, my remarks about the definitions of requestor > and responder have not received any treatment. > > I simplify the content of my comments: > > requestor and responder should be GENERALNAMES which > indicate and identify in global the partipating parties. > > IMO Using arbitrary octets with only LOCAL significance > is not compatible with the procedure to detect loops. > > 4.6 indicates the there MUST NOt be null characters, > something which is explicitly allowed for a server > acting as a relay. > > What is the sense of 4.7? The responder field is > never used anywhere in the actual protocol, what > is the meaning of such an opaque value? > > > 4.8.5 What is the reason of having an additional octet string > encapsulation instead of an any defined by construct? Is it > that some tools may break decodeing when they find an OID > that is not known? If so, whay are there ANY DEFINED BYs at > other places? > > can someone indicate me how a relay would return the response > of the next server to a client as part of his response? > > regards > > > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3LHLjJm092338; Wed, 21 Apr 2004 10:21:45 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3LHLjYx092337; Wed, 21 Apr 2004 10:21:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3LHLiIw092330 for <ietf-pkix@imc.org>; Wed, 21 Apr 2004 10:21:44 -0700 (PDT) (envelope-from chokhani@orionsec.com) Received: from wchokhani3 (dpvc-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i3LHLmK5011798 for <ietf-pkix@imc.org>; Wed, 21 Apr 2004 13:21:48 -0400 From: "Santosh Chokhani" <chokhani@orionsec.com> To: <ietf-pkix@imc.org> Subject: RE: new -- Clarification Note proposal on cert revocation - Date: Wed, 21 Apr 2004 13:21:42 -0400 Message-ID: <004c01c427c5$209283d0$9a00a8c0@hq.orionsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: <40869A8F.92EFBE4@nma.com> Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i3LHLjIw092332 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Ed: There is no particular reason to debate this. We have gone down this path and at your request, I have had several private exchanges with you regarding this. If you still do not get it, I do not have time to help any further. -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Ed Gerck Sent: Wednesday, April 21, 2004 12:00 PM To: Santosh Chokhani Cc: 'PKIX' Subject: Re: new -- Clarification Note proposal on cert revocation - Santosh Chokhani wrote: > > Ed: > > I do not think 3280 needs any clarification in this area. With all due respect, I think this reply shows otherwise. > There are several errors in the statements. Thank you. If you could please name them as you see them, this will also help the clarification. > Also, some of the topics are CA and RP policy issues and not > certificate and CRL formats issue. CA and RP policy issues are not described but, again, if you could please name them as you see them, this will also help the clarification. > Since PKIX is not operating a CA or recommending any operations > policy, none of this is needed for any other document either. On Wed, Apr 07, you wrote: "There is no mechanism to limit the time of delegation." However, as you see in the Clarification Note, this is not true: The issuer CA can authoritatively revoke delegation to the CRL issuer. Delegation is not for the life of the cert. A issuer CA could revoke the signing cert and re- issue all certs with a different delegation specification or no delegation. This also provides an incentive for the CRL issuer to conform to the issuer CA's policy. On the same day, you also wrote: "...and if the Indirect CRL is checked by the relying party, there is no requirement to check any CRL issued by the issuing CA." Yes, but that check was not done absolutely, as explained in the Note. It depends on whether the issuer CA signing cert is revoked or not, OR whether any other conforming revocation condition defined by the issuer CA applies. Also, as explained in the Note, An RP software relying on the revocation status of a certificate specified by any mechanism, authorized or not by the issuer CA of the certificate, is also subject to conditions defined by the issuer CA. Those conditions may change from time to time. Some mechanisms may not include direct evidence of the issuer CA's assertion of a certificate's revocation status or conditions, at a particular time. Cheers, Ed Gerck Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3LGdkTE089320; Wed, 21 Apr 2004 09:39:46 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3LGdkY9089319; Wed, 21 Apr 2004 09:39:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from exchange.microsoft.com ([131.107.8.3]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3LGdkko089313 for <ietf-pkix@imc.org>; Wed, 21 Apr 2004 09:39:46 -0700 (PDT) (envelope-from trevorf@exchange.microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 21 Apr 2004 09:39:49 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 21 Apr 2004 09:39:44 -0700 Received: from DF-GROMMIT-01.mercury.corp.microsoft.com ([10.197.0.61]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 21 Apr 2004 09:39:49 -0700 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: FW: scvp Date: Wed, 21 Apr 2004 09:39:48 -0700 Message-ID: <33E7A1613A3480448996047B69308A2F025E9C32@df-grommit-01.dogfood> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: scvp thread-index: AcQhUEjgRB16ax2fTtiK8dPXjv4WBAALuz/AAY/53IA= From: "Trevor Freeman" <trevorf@exchange.microsoft.com> To: <ietf-pkix@imc.org> Cc: "Peter Sylvester" <Peter.Sylvester@edelweb.fr> X-OriginalArrivalTime: 21 Apr 2004 16:39:49.0457 (UTC) FILETIME=[434CF410:01C427BF] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i3LGdkko089314 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Reposting at Peters request -----Original Message----- From: Trevor Freeman Sent: Tuesday, April 13, 2004 11:25 AM To: 'Peter Sylvester'; ietf-pkix@imc.org Subject: RE: scvp Hi Peter, Respnces below. The change to 3.4 permits a SCVP server to return a cached response in which case it cannot include any request specific values. A client could require a non-cached repsoce in which case this value must be present. There is no requiremnt today that SCVP client must have a name in the genral name space. They can simply use soemthing generated localy and use that which seems a big plus. If the request or repnoce is signed then you get a name in the certifcate. The octet string vs. oid with any was a arbitary chioce since boht chiver the same end. Trevor -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Peter Sylvester Sent: Tuesday, April 13, 2004 3:56 AM To: ietf-pkix@imc.org Subject: scvp SCVP 14: 3.4 Requestor The OPTIONAL requestor item is a reference local to the requestor. The value is only of local significance to the requestor. If the SCVP client includes a requestor value in the request, then the SCVP server MUST return the same value in a unique SCVP response. The SCVP server MAY omit the requestor value from cached SCVP responses. SCVP 13: The OPTIONAL requestor item is a reference local to the requestor. The value is only of local significance to the requestor. If the SCVP client includes a requestor value in the request, then the SCVP server MUST return the same value in the response. As far as I remember, there was no discussion about this. I think that the following sentence of 4.6 does not respect the requirements. 4.6 Requestor The OPTIONAL requestor item is used to identify the requestor. The value is only of local significance to the requestor. requirements say: When the DPV request is authenticated, the client SHOULD be able to include a client identifier in the request for the DPV server to copy into the response. Mechanisms for matching this identifier with the authenticated identity depends on local DPV server conditions and/or the validation policy. The DPV server MAY choose to blindly copy the identifier, omit the identifier, or return an error response. IMO this clearly indicates that the identifier has a meaning for the server. Unless I have overlooked something, I have not seen any response to the following. Maybe the content of my message considered as pure nonsense. Date: Tue Oct 28 18:43:58 2003 To: kent@bbn.com, ietf-pkix@imc.org, trevorf@windows.microsoft.com Subject: RE: SCVP additions hello, It would be nice to hear whether all or which comments about SCVP have been addressed. Unless I have overlooked something, my remarks about the definitions of requestor and responder have not received any treatment. I simplify the content of my comments: requestor and responder should be GENERALNAMES which indicate and identify in global the partipating parties. IMO Using arbitrary octets with only LOCAL significance is not compatible with the procedure to detect loops. 4.6 indicates the there MUST NOt be null characters, something which is explicitly allowed for a server acting as a relay. What is the sense of 4.7? The responder field is never used anywhere in the actual protocol, what is the meaning of such an opaque value? 4.8.5 What is the reason of having an additional octet string encapsulation instead of an any defined by construct? Is it that some tools may break decodeing when they find an OID that is not known? If so, whay are there ANY DEFINED BYs at other places? can someone indicate me how a relay would return the response of the next server to a client as part of his response? regards Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3LGQak3088238; Wed, 21 Apr 2004 09:26:36 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3LGQaXw088237; Wed, 21 Apr 2004 09:26:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3LGQZwp088209 for <ietf-pkix@imc.org>; Wed, 21 Apr 2004 09:26:35 -0700 (PDT) (envelope-from tgindin@us.ibm.com) Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e3.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i3LGQ9Im494506; Wed, 21 Apr 2004 12:26:21 -0400 Received: from d01ml062.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by northrelay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i3LGQYBR102868; Wed, 21 Apr 2004 12:26:36 -0400 To: "Jaleel P.A" <jaleelpa@hotmail.com> Cc: ietf-pkix@imc.org MIME-Version: 1.0 Subject: Re: Cross certificate format X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 From: Tom Gindin <tgindin@us.ibm.com> Message-ID: <OFB6C8C5FA.85168521-ON85256E7D.0057CD3B-85256E7D.005A2AAC@us.ibm.com> Date: Wed, 21 Apr 2004 12:24:57 -0400 X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 6.0.2CF2 HFB2|March 16, 2004) at 04/21/2004 12:26:08, Serialize complete at 04/21/2004 12:26:08 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Jaleel: As several of the earlier responses have pointed out, cross certificates are just those CA certificates whose issuer and subject are different. CA certificates (except v1 self-signed certificates) are slightly different from non-CA certificates in the following ways: a) The basic constraints extension is present and has the "CA" flag set. b) The key usage extension is present and has the keyCertSign bit set, and often the cRLSign bit as well. There are other, less common, extensions which are typically found in CA certificates and not in others. These include Name Constraints, Policy Constraints, Policy Mappings, and Inhibit Any-Policy. RFC 3280 does not support the use of v1 self-signed certificates, which contain no extensions at all (see the text of RFC 3280's basicConstraints section). However, a number of public CA's still have them. Tom Gindin P.S. The opinions above are my own, and not necessarily those of my employer. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3LG0WhY086383; Wed, 21 Apr 2004 09:00:32 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3LG0WnE086382; Wed, 21 Apr 2004 09:00:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail14.atl.registeredsite.com (nobody@mail14.atl.registeredsite.com [64.224.219.88]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3LG0VVi086376 for <ietf-pkix@imc.org>; Wed, 21 Apr 2004 09:00:31 -0700 (PDT) (envelope-from egerck@nma.com) Received: from taurus.hosting4u.net (taurus.hosting4u.net [209.35.191.122]) by mail14.atl.registeredsite.com (8.12.8/8.12.8) with ESMTP id i3LG0YBL010820; Wed, 21 Apr 2004 16:00:34 GMT Received: from nma.com ([63.204.17.85]) by taurus.hosting4u.net ; Wed, 21 Apr 2004 11:00:32 -0500 Message-ID: <40869A8F.92EFBE4@nma.com> Date: Wed, 21 Apr 2004 09:00:15 -0700 From: Ed Gerck <egerck@nma.com> X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Santosh Chokhani <chokhani@orionsec.com> CC: "'PKIX'" <ietf-pkix@imc.org> Subject: Re: new -- Clarification Note proposal on cert revocation - References: <002501c4274a$cc436ad0$aa02a8c0@hq.orionsec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Santosh Chokhani wrote: > > Ed: > > I do not think 3280 needs any clarification in this area. With all due respect, I think this reply shows otherwise. > There are several errors in the statements. Thank you. If you could please name them as you see them, this will also help the clarification. > Also, some of the topics are CA and RP policy issues and not certificate and > CRL formats issue. CA and RP policy issues are not described but, again, if you could please name them as you see them, this will also help the clarification. > Since PKIX is not operating a CA or recommending any operations policy, none > of this is needed for any other document either. On Wed, Apr 07, you wrote: "There is no mechanism to limit the time of delegation." However, as you see in the Clarification Note, this is not true: The issuer CA can authoritatively revoke delegation to the CRL issuer. Delegation is not for the life of the cert. A issuer CA could revoke the signing cert and re- issue all certs with a different delegation specification or no delegation. This also provides an incentive for the CRL issuer to conform to the issuer CA's policy. On the same day, you also wrote: "...and if the Indirect CRL is checked by the relying party, there is no requirement to check any CRL issued by the issuing CA." Yes, but that check was not done absolutely, as explained in the Note. It depends on whether the issuer CA signing cert is revoked or not, OR whether any other conforming revocation condition defined by the issuer CA applies. Also, as explained in the Note, An RP software relying on the revocation status of a certificate specified by any mechanism, authorized or not by the issuer CA of the certificate, is also subject to conditions defined by the issuer CA. Those conditions may change from time to time. Some mechanisms may not include direct evidence of the issuer CA's assertion of a certificate's revocation status or conditions, at a particular time. Cheers, Ed Gerck Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3LEMDCG076825; Wed, 21 Apr 2004 07:22:13 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3LEMDLb076824; Wed, 21 Apr 2004 07:22:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from centaur.acm.jhu.edu (postfix@centaur.acm.jhu.edu [128.220.223.65]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3LEMBDA076810 for <ietf-pkix@imc.org>; Wed, 21 Apr 2004 07:22:12 -0700 (PDT) (envelope-from lloyd@acm.jhu.edu) Received: by centaur.acm.jhu.edu (Postfix, from userid 528) id 819403EBCF; Wed, 21 Apr 2004 10:22:10 -0400 (EDT) Date: Wed, 21 Apr 2004 10:22:10 -0400 From: Jack Lloyd <lloyd@randombit.net> To: ietf-pkix@imc.org Subject: Re: Status of draft-ietf-pkix-certstore-http? Message-ID: <20040421142210.GA15955@acm.jhu.edu> Mail-Followup-To: ietf-pkix@imc.org References: <20040420141147.GC29689@acm.jhu.edu> <E1BG62Z-0002Lz-R3@medusa01> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <E1BG62Z-0002Lz-R3@medusa01> X-GPG-Key-ID: 4DCDF398 X-GPG-Key-Fingerprint: 2DD2 95F9 C7E3 A15E AF29 80E1 D6A9 A5B9 4DCD F398 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> On Wed, Apr 21, 2004 at 12:56:39PM +1200, Peter Gutmann wrote: > Jack Lloyd <lloyd@randombit.net> writes: > > >The last version of this draft I can find is -05, expiring in September 2003. > >Has this draft been abandoned, or is going to start moving again at some > >point? > > A number of people have been asking that :-). The current draft was > mistakenly deleted from the IETF server, I'll get a new version up within the > next few days, although I'm not sure what number it'll have because of the > missing (deleted) copy. For all intents and purposes it's identical to -05, > there's just two minor wording changes. Good to hear. Is there a public server anywhere I can hit with requests? Or, better, a server implementation I can run locally with various strange test certs? -J Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3LDhZsT073191; Wed, 21 Apr 2004 06:43:35 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3LDhZ2c073190; Wed, 21 Apr 2004 06:43:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from nic.lp.se (nic.lp.se [213.212.3.208]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3LDhYLX073161 for <ietf-pkix@mail.imc.org>; Wed, 21 Apr 2004 06:43:34 -0700 (PDT) (envelope-from levitte@lp.se) Received: from localhost (127.0.0.1) by nic.lp.se (MX V5.3 VnHj) with ESMTP; Wed, 21 Apr 2004 15:43:09 +0200 Date: Wed, 21 Apr 2004 15:43:15 +0200 (CEST) Message-ID: <20040421.154315.59832379.levitte@lp.se> To: timofey@pochta.ru CC: ietf-pkix@mail.imc.org Subject: Re: Cross certificate format From: Richard Levitte - VMS Whacker <levitte@lp.se> In-Reply-To: <713506888.20040421160037@pochta.ru> References: <BAY10-DAV6Ih7jtrSBy0000e275@hotmail.com> <713506888.20040421160037@pochta.ru> X-URL: http://www.lp.se/ X-Waved: dead chicken, GNU emacs 21.3.1, Mew version 4.0.64 X-Mew: See http://www.mew.org/ X-Mailer: Mew version 4.0.64 on Emacs 21.3 / Mule 5.0 (SAKAKI) 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: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> In message <713506888.20040421160037@pochta.ru> on Wed, 21 Apr 2004 16:00:37 +0400, Timofey <timofey@pochta.ru> said: timofey> Hello Jaleel, timofey> timofey> JPA> Hi, timofey> timofey> JPA> Can anybody tell me the structure of a Cross Certificate timofey> JPA> and how it is different from a normal Public Key timofey> JPA> certificate. A Cross certificate sample can be of great timofey> JPA> help. timofey> timofey> Cross-certificate has absolutly the same structure as timofey> "normal" certificate. It looks like one CA signs another. timofey> timofey> The only difference is the place you store it. For example, timofey> you can place it in LDAP directory as crossCertificatePair timofey> attribute. I've always wondered about that, what's the reason to have that placed separately from other certificates? To me, that just means I have to look in yet another place... ----- Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte | http://richard.levitte.org/ | Tunnlandsv. 52 Levitte Programming | http://www.lp.se/ | S-168 36 Bromma T: +46-708-26 53 44 | | SWEDEN "Price, performance, quality... choose the two you like" Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3LDISC6070765; Wed, 21 Apr 2004 06:18:28 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3LDISFk070764; Wed, 21 Apr 2004 06:18:28 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.8) with ESMTP id i3LDIRTE070758 for <ietf-pkix@imc.org>; Wed, 21 Apr 2004 06:18:27 -0700 (PDT) (envelope-from david.cooper@nist.gov) Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id i3LDIJrt032188; Wed, 21 Apr 2004 09:18:19 -0400 Received: from nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id i3LDHf8r027360; Wed, 21 Apr 2004 09:17:41 -0400 (EDT) Message-ID: <408674DA.90408@nist.gov> Date: Wed, 21 Apr 2004 09:19:22 -0400 From: "David A. Cooper" <david.cooper@nist.gov> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031010 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Jaleel P.A" <jaleelpa@hotmail.com> CC: ietf-pkix@imc.org Subject: Re: Cross certificate format References: <BAY10-DAV23onPnnGva00043050@hotmail.com> In-Reply-To: <BAY10-DAV23onPnnGva00043050@hotmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-NIST-MailScanner: Found to be clean X-MailScanner-From: david.cooper@nist.gov Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Jaleel P.A wrote: >Can anybody tell me the structure of a Cross Certificate and how it is >different from a normal Public Key certificate. A Cross certificate sample >can be of great help. > > Technically, a cross certificate is certificate that has been issued by one CA to another CA. X.509 defines three types of CA certificates: 1) self-issued certificate: certificate in which the issuer and subject are the same CA. 2) self-signed certificate: self-issued certificate in which private key used to sign the certificate corresponds to the certificate's subject public key. 3) cross certificate: certificate in which the issuer and subject are different CAs (i.e., any CA certificate that is not a self-issued certificate). Certificates issued to other CAs may be divided into two types: (1) a certificate issued to a subordinate CA in a hierarchy; and (2) a certificate issued to a CA that is a peer (frequently a CA at a different organization). With the second type, it will commonly be the case the each CA will issue a certificate to the other one. Despite the "official" definition above, people will sometimes use the term "cross certificate" to refer to this second type of CA certificate (i.e., certificates issued to CAs in another organization in a peer-to-peer manner). In fact, some believe that cross-certification implies that the two peer CAs have each issued the other a certificate. Note that there is also a directory attribute crossCertificatePair, which holds a SEQUENCE of two cross certificates as specified in RFC 2587: crossCertificatePairATTRIBUTE::={ WITH SYNTAX CertificatePair EQUALITY MATCHING RULE certificatePairExactMatch ID joint-iso-ccitt(2) ds(5) attributeType(4) crossCertificatePair(40)} CertificatePair ::= SEQUENCE { forward [0] Certificate OPTIONAL, reverse [1] Certificate OPTIONAL, -- at least one of the pair shall be present -- } Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3LC24oE064676; Wed, 21 Apr 2004 05:02:04 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3LC24En064675; Wed, 21 Apr 2004 05:02:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from relay1.hotbox.ru (relay1.hotbox.ru [194.186.36.181]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3LC21jR064663 for <ietf-pkix@mail.imc.org>; Wed, 21 Apr 2004 05:02:02 -0700 (PDT) (envelope-from timofey@pochta.ru) Received: from smtp.hotbox.ru (smtp.hotbox.ru [80.68.244.50]) by relay1.hotbox.ru (8.11.6/8.11.6) with ESMTP id i3LC1sW01753 for <ietf-pkix@mail.imc.org>; Wed, 21 Apr 2004 16:01:54 +0400 Received: from VORTEX2 (vortex.demos.ru [194.87.1.170]) (authenticated bits=0) by smtp.hotbox.ru (8.12.9/8.12.9) with ESMTP id i3LC2tRV076919 for <ietf-pkix@mail.imc.org>; Wed, 21 Apr 2004 16:02:57 +0400 (MSD) (envelope-from timofey@pochta.ru) Date: Wed, 21 Apr 2004 16:00:37 +0400 From: Timofey <timofey@pochta.ru> X-Mailer: The Bat! (v2.04.7) Personal Reply-To: Timofey <timofey@pochta.ru> X-Priority: 3 (Normal) Message-ID: <713506888.20040421160037@pochta.ru> To: ietf-pkix@mail.imc.org Subject: Re: Cross certificate format In-Reply-To: <BAY10-DAV6Ih7jtrSBy0000e275@hotmail.com> References: <BAY10-DAV6Ih7jtrSBy0000e275@hotmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="----------7A15B2B26FB9D77" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> This is a cryptographically signed message in MIME format. ------------7A15B2B26FB9D77 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hello Jaleel, JPA> Hi, JPA> Can anybody tell me the structure of a Cross Certificate and how it is JPA> different from a normal Public Key certificate. A Cross certificate sa= mple JPA> can be of great help. Cross-certificate has absolutly the same structure as "normal" certificate. It looks like one CA signs another. The only difference is the place you store it. For example, you can place it in LDAP directory as crossCertificatePair attribute. --=20 Best regards, Timofey =20 ------------7A15B2B26FB9D77 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIHNQYJKoZIhvcNAQcCoIIHJjCCByICAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BbwwggJ8MIIB5aADAgECAgMKZo4wDQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhh d3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwg RnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA3MjMxMDU4NTRaFw0wNDA3MjIxMDU4NTRa MEMxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIxIDAeBgkqhkiG9w0BCQEWEXRp bW9mZXlAcG9jaHRhLnJ1MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDFuTPqxNka4gz3 nS0g5F6uCu8s28fvHQ/0vA7Jx2LdG11WiaF3oxT0Kgxz6k9Z0O1ltdeiL7LPlhnF7hannrLi s7em4GBm9V/CZIElA5Th5UDKRjJpTutGbbBrLC03mxn+oGp1mUfnrCmvJVDc8vmAcYNEe6CR Mkf1gkGLkO4phwIDAQABoy4wLDAcBgNVHREEFTATgRF0aW1vZmV5QHBvY2h0YS5ydTAMBgNV HRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAJ9/8DqRdaxp5SjYkccHO5hU3FHYPeY22Xwq LkUEFZTD2U4pt2424iwDuMwCPkZMtUjJtdvj1PZcp9yqva+coUqggrVJnj42at6xLMU/qzag gSxljZM1VhOnmn+9NJyY6rbGNkhtbPmTR+WbJd9mBcJAw+t4tOcAhqRdUgSwroK2MIIDODCC AqGgAwIBAgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMC WkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQK ExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBE aXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZI hvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoX DTA0MDgyNzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx EjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z MDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7j RCmKYzUqbXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagn rthy+boC9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEA AaNOMEwwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1Ud EwEB/wQIMAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx 5fVTbF151j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0 teuiR59sogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0ie zqWf54TYyWJirQXGMYIBQTCCAT0CAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYD VQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwg UlNBIDIwMDAuOC4zMAIDCmaOMAkGBSsOAwIaBQAwDQYJKoZIhvcNAQEBBQAEgYBrChEpKvwB SEislKUu1InerFQ/8pz6c/Ql64pzFZFCocfR0DpMF6w6HJIzKp+VQBUtIb7tueDumUn8cXY5 P97h/XM0vGeXvVIilPgM4kf840tda/r/sZeZ+2QeV/RmjFPyQJNTTUKy8tUwaHT1NDchP0xj 8fa04yKMCDk4JMzSmw== ------------7A15B2B26FB9D77-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3LALI1Z057015; Wed, 21 Apr 2004 03:21:18 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3LALICX057013; Wed, 21 Apr 2004 03:21:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from hotmail.com (bay10-dav6.bay10.hotmail.com [64.4.37.180]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3LALHPR056888 for <ietf-pkix@mail.imc.org>; Wed, 21 Apr 2004 03:21:17 -0700 (PDT) (envelope-from jaleelpa@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 21 Apr 2004 03:21:13 -0700 Received: from 203.123.181.226 by bay10-dav6.bay10.hotmail.com with DAV; Wed, 21 Apr 2004 10:21:13 +0000 X-Originating-IP: [203.123.181.226] X-Originating-Email: [jaleelpa@hotmail.com] X-Sender: jaleelpa@hotmail.com From: "Jaleel P.A" <jaleelpa@hotmail.com> To: <ietf-pkix@mail.imc.org> Subject: Cross certificate format Date: Wed, 21 Apr 2004 15:51:12 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcQniL6Ztf5XYbKcQaOeq493SdmU7gAAQLGwAAAkhnA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Message-ID: <BAY10-DAV6Ih7jtrSBy0000e275@hotmail.com> X-OriginalArrivalTime: 21 Apr 2004 10:21:13.0268 (UTC) FILETIME=[5F659740:01C4278A] Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Hi, Can anybody tell me the structure of a Cross Certificate and how it is different from a normal Public Key certificate. A Cross certificate sample can be of great help. Thanks Jaleel Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3LAKJRV056828; Wed, 21 Apr 2004 03:20:19 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3LAKJd5056827; Wed, 21 Apr 2004 03:20:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from hotmail.com (bay10-dav23.bay10.hotmail.com [64.4.37.197]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3LAKAdp056818 for <ietf-pkix@imc.org>; Wed, 21 Apr 2004 03:20:18 -0700 (PDT) (envelope-from jaleelpa@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 21 Apr 2004 03:20:06 -0700 Received: from 203.123.181.226 by bay10-dav23.bay10.hotmail.com with DAV; Wed, 21 Apr 2004 10:20:06 +0000 X-Originating-IP: [203.123.181.226] X-Originating-Email: [jaleelpa@hotmail.com] X-Sender: jaleelpa@hotmail.com From: "Jaleel P.A" <jaleelpa@hotmail.com> To: <ietf-pkix@imc.org> Subject: Cross certificate format Date: Wed, 21 Apr 2004 15:50:06 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcQniL6Ztf5XYbKcQaOeq493SdmU7gAAQLGw In-Reply-To: <200404211009.i3LA9UQR055882@above.proper.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Message-ID: <BAY10-DAV23onPnnGva00043050@hotmail.com> X-OriginalArrivalTime: 21 Apr 2004 10:20:06.0958 (UTC) FILETIME=[37DF7CE0:01C4278A] Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Hi, Can anybody tell me the structure of a Cross Certificate and how it is different from a normal Public Key certificate. A Cross certificate sample can be of great help. Thanks Jaleel Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3LACZJM056182; Wed, 21 Apr 2004 03:12:35 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3LACZHp056181; Wed, 21 Apr 2004 03:12:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from ntexch03.office.sia.it (clients.sia.it [193.203.230.22] (may be forged)) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3LACXtv056174 for <ietf-pkix@imc.org>; Wed, 21 Apr 2004 03:12:34 -0700 (PDT) (envelope-from adriano.santoni@actalis.it) Received: by ntexch03.office.sia.it with Internet Mail Service (5.5.2657.72) id <HJMHADGK>; Wed, 21 Apr 2004 12:12:38 +0200 Message-ID: <BE82E060F5EA2D44A4CFCFFA8363958803B4BB0E@ntexch00.office.sia.it> From: Santoni Adriano <adriano.santoni@actalis.it> To: "'rhousley@rsasecurity.com'" <rhousley@rsasecurity.com>, "'wford@verisign.com'" <wford@verisign.com>, "'wpolk@nist.gov'" <wpolk@nist.gov>, "'dsolo@alum.mit.edu'" <dsolo@alum.mit.edu> Cc: "'ietf-pkix@imc.org'" <ietf-pkix@imc.org> Subject: I: R: RFC3280: doubt on the use of UTF8String in encoding RDNs Date: Wed, 21 Apr 2004 12:12:37 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i3LACYtv056176 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Dear RFC3280 Authors, Sorry for bothering, and please forgive me if I am asking an old question. RFC 3280 reads (§4.1.2.4): "...all certificates issued after December 31, 2003 MUST use the UTF8String encoding of DirectoryString...". Is that sentence meant to be intepreted in the following way? : "All RDNs (having a DirectoryString syntax) of the issuer and subject certificate fields, in all certificates issued after December 31, 2003, MUST be encoded as UTF8Strings EVEN if they could be correctly encoded as a PrintableStrings." If the answer is YES, I would like your personal opinion about the great majority (sai 99,9%) of all CAs all over the planet not being conformant to RFC 3280 and neither to RFC 2459, as far as this particular PKIX prescription is concerned. Thank you for any feedback on this issue. Regards, Adriano -----Messaggio originale----- Da: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] Per conto di Jean-Marc Desperrier Inviato: martedì 13 aprile 2004 15.12 A: ietf-pkix@imc.org Oggetto: Re: R: RFC3280: doubt on the use of UTF8String in encoding RDNs Santoni Adriano wrote: > Well, it turns out that - despite the topic has been debated in the > past - there is not much consense on the "true" intepretation of RFC > 3280, §4.1.2.4. The sentence " all certificates issued after December > 31, 2003 MUST use the UTF8String encoding of DirectoryString (except > as noted below) " is a prescriptive one, if I am not mistaken. > > Nontheless, Glassey says "you have to do so, full-stop", while Gutman > and Desperrier says "you'd better not" because a) some application > would not handle UTF-8 properly and b) the CA should not "alter" the > name if a certificate already exists for the same subject. I feel I have to say my post was not at all an interpretation of the meaning of RFC3280, and I did not intend to say that part of RFC3280 is not prescriptive. It was just a remark about the state of current applications. They are other aspects of RFC3280 that are certainly no more well supported in practice. This said, AFAIR when the topic was debated in the past, it was concluded that renewal cert were one of the "except as noted below" case. > Regarding point a), I personally agree that some applications will not > behave properly when encountering UTF8Strings, but that should have > been taken into account when drafting RFC 3280, not today! That part of RFC3280 was copied without any change (and I strongly suspect without discussion, or rereading) from RFC2459. At the time RFC2459 was drafted, 2003 was far in the future, and the redactors surely hoped UTF8String would be widely in use before the deadline, so that this deadline would not be much a constraint. > I am sure many of you have noticed that most CAs (all over the planet) > claiming conformance to RFC3280 have not started issuing certificates > with subject names encoded as UTF8String, after 31 december 2003. I > dare to say one of the reasons might be a little ambiguity in RFC 3280 > and probably insufficient debate on this specific topic. I'm not sure the problem is due to any ambiguity in RFC3280. I think some of the problem might be related to few people really trying to implement RFC3280 fully and carefully, many just implementing support for what they see the most often in use. If there is no UTF-8 around, they don't do it, and therefore nobody starts doing it. I'm afraid all what one can hope is that some people will start to implement it because it's written in the RFC, will meet interoperability problems, will tell other implementors they are the one who don't respect the norm, and the other implementators will progressively correct any problem related to that in their code. I now think expecting implementors to prepare for the future, or beginning to implement something until they are forced to is a lost cause, so the prescriptive aspect of RFC3280, and the fact applying it will break a few things, is a good thing if we really want certificates to support internationalization one day. What I also think in relation to that is that there should be a normalized, pkix approved test suite for RFC3280 as complete as possible so that it would be very easy to ask anybody claiming RFC3280 conformance what the result of the test suite is. *******************Internet Email Confidentiality Footer******************* Qualsiasi utilizzo non autorizzato del presente messaggio nonche' dei suoi allegati e' vietato e potrebbe costituire reato. Se lei ha ricevuto erroneamente il presente messaggio, Le saremmo grati se, via e-mail, ce ne comunicasse la ricezione e provvedesse alla distruzione del messaggio stesso e dei suoi eventuali allegati. Le dichiarazioni contenute nel presente messaggio nonche' nei suoi eventuali allegati devono essere attribuite esclusivamente al mittente e non possono essere considerate come trasmesse o autorizzate da SIA S.p.A.; le medesime dichiarazioni non impegnano SIA S.p.A. nei confronti del destinatario o di terzi. SIA S.p.A. non si assume alcuna responsabilita' per eventuali intercettazioni, modifiche o danneggiamenti del presente messaggio e-mail. Any unauthorized use of this e-mail or any of its attachments is prohibited and could constitute an offence. If you are not the intended addressee please advise immediately the sender by using the reply facility in your e-mail software and destroy the message and its attachments. The statements and opinions expressed in this e-mail message are those of the author of the message and do not necessarily represent those of SIA. Besides, The contents of this message shall be understood as neither given nor endorsed by SIA S.p.A.. SIA S.p.A. does not accept liability for corruption, interception or amendment, if any, or the consequences thereof. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3L9jWTl053851; Wed, 21 Apr 2004 02:45:32 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3L9jWXV053850; Wed, 21 Apr 2004 02:45:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from ns01.secom.co.jp (ns01.secom.co.jp [61.114.178.247]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3L9jVK4053842 for <ietf-pkix@imc.org>; Wed, 21 Apr 2004 02:45:31 -0700 (PDT) (envelope-from yo-ishigak@secom.co.jp) Received: from mlit02.intra.secom.co.jp ([172.21.1.41]) by ns01.secom.co.jp (8.11.7-20030918/3.7W) with ESMTP id i3L9jP924764 for <ietf-pkix@imc.org>; Wed, 21 Apr 2004 18:45:26 +0900 (JST) Received: from sectrl.isl.secom.co.jp (localhost [127.0.0.1]) by mlit02.intra.secom.co.jp (8.11.3/3.7W) with ESMTP id i3L9jPH11612 for <ietf-pkix@imc.org>; Wed, 21 Apr 2004 18:45:25 +0900 Received: from isis.sp.isl.secom.co.jp (isis.isl.secom.co.jp [10.131.16.23]) by sectrl.isl.secom.co.jp (Postfix) with ESMTP id 014511E72F for <ietf-pkix@imc.org>; Wed, 21 Apr 2004 18:45:24 +0900 (JST) Received: from [127.0.0.1] (hogehoge [10.131.129.129] (may be forged)) by isis.sp.isl.secom.co.jp (8.9.1+3.1W/3.7W-Isis.1) with ESMTP id SAA29739 for <ietf-pkix@imc.org>; Wed, 21 Apr 2004 18:45:24 +0900 Date: Wed, 21 Apr 2004 18:45:13 +0900 From: =?ISO-2022-JP?B?GyRCQFAzQBsoQiAbJEJNWxsoQg==?= <yo-ishigak@secom.co.jp> To: ietf-pkix@imc.org Subject: Re: TSA for testing In-Reply-To: <1086.68.160.182.113.1080320994.squirrel@webmail.ncipherusa.com> References: <E1B6m0A-0002au-0P@medusa01> <1086.68.160.182.113.1080320994.squirrel@webmail.ncipherusa.com> Message-Id: <20040421183531.3C95.YO-ISHIGAK@secom.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.05.10 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> ChallengePKI project will open timestamp test center, based on Denis Pinkas's TSP Interoperability Testing Draft (Feb 2002). http://www.jnsa.org/mpki/2003/ Regards, Yo ISHIGAKI On Fri, 26 Mar 2004 12:09:54 -0500 (EST) "Scott Mustard" <scott@ncipher.com> wrote: > > Gerald Willet and I leave ours online as well at dse200.ncipher.com. > > Cheers, > > Scott Mustard > > > --- Yo Ishigaki SECOM Intelligent Systems Laboratory TEL. 0422-76-2105 / FAX. 0422-76-2120 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3L2k4qS042541; Tue, 20 Apr 2004 19:46:04 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3L2k4p0042540; Tue, 20 Apr 2004 19:46:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3L2k42H042520 for <ietf-pkix@imc.org>; Tue, 20 Apr 2004 19:46:04 -0700 (PDT) (envelope-from chokhani@orionsec.com) Received: from wchokhani3 (pcp09271907pcs.arlngt01.va.comcast.net [69.143.130.247]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i3L2k8K5024101 for <ietf-pkix@imc.org>; Tue, 20 Apr 2004 22:46:08 -0400 From: "Santosh Chokhani" <chokhani@orionsec.com> To: "'PKIX'" <ietf-pkix@imc.org> Subject: RE: new -- Clarification Note proposal on cert revocation - Date: Tue, 20 Apr 2004 22:46:02 -0400 Message-ID: <002501c4274a$cc436ad0$aa02a8c0@hq.orionsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal In-Reply-To: <4085870B.55A84F79@nma.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i3L2k42H042535 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Ed: I do not think 3280 needs any clarification in this area. There are several errors in the statements. Also, some of the topics are CA and RP policy issues and not certificate and CRL formats issue. Since PKIX is not operating a CA or recommending any operations policy, none of this is needed for any other document either. -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Ed Gerck Sent: Tuesday, April 20, 2004 4:25 PM To: PKIX Subject: new -- Clarification Note proposal on cert revocation - All, I'm sending this new version for additional list's comments, in its short and long forms. Please refer to the long form if you have questions reading the short form. PKIX list traffic also has ~30 messages recently, Re "cert revocation", showing some of the context and need for this clarification. MOTIVATION (not intended as part of the proposed text) The proposal is to add a Clarification Note to current PKIX documents that deal with revocation and validation of certs. This would help the weary reader, who must otherwise wade through the PKIX documents and list's archives in order to find limitations that are often not so clear to most folks. I also used the opportunity to point out the conditions on those limitations in the long form of the Note, with a view to reducing their effect. The purpose of the Clarification Note is not to reinvent or change X.509 or related PKIX RFCs. The purpose is to clarify and unify PKIX references (including WG context interpretation) in regard to certificate revocation. There should be many paragraphs in X.509 and related PKIX RFCs that are, with analysis, equivalent to the Clarification Note and vice versa. This is how it should be. The informative aspect of the Clarification Note is in terms of ambiguity resolution in the documentation and context interpretation. As reported by Steve Kent, since there is a suggestion before the WG to issue an update to 3280, the WG can decide whether the Clarification Note text should be part of the next update, if the WG proceeds on that work item. CLARIFICATION NOTE ON CERTIFICATE REVOCATION (short form) In X.509/PKIX there is only one issuer CA for a given certificate. Only the issuer CA of a certificate is authoritative for revocation conditions of the certificate. If a certificate is listed as revoked by means of one of those mechanisms identified by the issuer CA in a conforming certificate extension (e.g., a CRL signed by the CA, an indirect CRL signed by the CRL issuer, an OCSP status, an HTTP CRL list), OR if any other revocation condition defined by the issuer CA applies (e.g., expired or revoked issuer CA certificate), the certificate is revoked. Otherwise, the certificate is not revoked. However, from a particular RP's point of view, there are several limitations on verifying the current revocation status of a certificate. For example, if an RP does not support any of the mechanisms defined by the issuer CA to verify the revocation status, or times out during such verification, or cannot find a path to verify the status, then the revocation status is undefined for that RP. Also, since there may be more than one path used to verify the revocation status of the same certificate, the occurrence of race conditions, differently available paths, and revoked parent certificates can lead to ambiguous results for different RPs. Therefore, different RPs may arrive at a different view of the revocation status of a EE, CA or cross certificate at a particular time. An RP software relying on the revocation status of a certificate specified by any mechanism, authorized or not by the issuer CA of the certificate, is also subject to conditions defined by the issuer CA. Those conditions may change from time to time. Some mechanisms may not include direct evidence of the issuer CA's assertion of a certificate's revocation status or conditions, at a particular time. Further, from a particular RP's point of view, the revocation status of a certificate is not enough to define the validity of that certificate. Certificate validity is a function of a number of additional parameters, including the certificate path that the RP trusts to validate the certificate, the access to revocation status information available to the RP, the local policy used by the RP, and the application (the RP software) that the RP will employ. The validity of a certificate refers to conditions that are authoritatively defined locally. Note that the distinction between "revocation" and "validation" has been somewhat blurred in the documentation and informal discussions. That distinction is, however, necessary to preserve both the control needs for PKI, requiring centralized conditions of revocation that are authoritatively defined by the issuer CA, and those business and user needs, requiring local authoritative definition of validation. Now we ask the critical question: When is a certificate revoked? The answer is: when the corresponding revocation status is published by means of one of those mechanisms identified by the issuer CA in a conforming certificate extension, or when any other revocation condition defined by the issuer CA applies. It does not matter when a particular RP is able to verify that status, or what mechanisms an RP can use for such purpose. The revocation status of a certificate issued by a conforming CA does not depend on an RP and is always well-defined from an RP's point of view -- i.e., it is unambiguous (revoked or not revoked) and ultimately verifiable. Therefore, from a particular RP's point of view, the limitations on verifying the current revocation status of a certificate have nothing to do with the eventual result of that verification, which is always well-defined. The limitations have to do with the efforts for that verification, which may require an unspecified amount of time and work. Human intervention may also be necessary. The same considerations apply to certificateHold and removefromCRL status. CLARIFICATION NOTE ON CERTIFICATE REVOCATION (long form) In X.509/PKIX there is only one issuer CA for a given certificate. Only the issuer CA of a certificate is authoritative for revocation conditions of the certificate. One of those conditions is that the certificate must be signed by a CA certificate, issued by the issuer CA, that has not expired and is not revoked. Another condition is that the issuer CA may delegate the authority for a particular certificate's revocation notices and/or status to another entity called the CRL issuer, identified by the CA in the CRL Distribution Point (CDP) extension of the certificate. Another condition is that the issuer CA may send the revocation notice for a particular certificate as a status service to a server identified by the CA in the Authority Information Access (AIA) extension of the certificate with an OCSP access descriptor or an HTTP CRL access descriptor. If a certificate is listed as revoked by means of one of those mechanisms identified by the issuer CA in a conforming certificate extension (e.g., a CRL signed by the CA, an indirect CRL signed by the CRL issuer, an OCSP status, an HTTP CRL list), OR if any other revocation condition defined by the issuer CA applies (e.g., expired or revoked issuer CA certificate), the certificate is revoked. Otherwise, the certificate is not revoked. In short, because the revocation status of a certificate refers to conditions that a conforming issuer CA authoritatively and unambiguously defines, a certificate is either revoked or not from the issuer CA viewpoint. However, from a particular RP's point of view, there are several limitations on verifying the current revocation status of a certificate. For example, if an RP does not support any of the mechanisms defined by the issuer CA to verify the revocation status, or times out during such verification, or cannot find a path to verify the status, then the revocation status is undefined for that RP. According to RFC 3280, this can happen even for a conforming CA and a conforming application (RP software). Conforming CAs are not required to issue CRLs if other revocation or certificate status mechanisms are provided. Conforming applications are NOT REQUIRED to support processing of delta CRLs, indirect CRLs, or CRLs with a scope other than all certificates issued by one CA. Also, since there may be more than one path used to verify the revocation status of the same certificate, the occurrence of race conditions, differently available paths, and revoked parent certificates can lead to ambiguous results for different RPs. If a CA sends status data to an OCSP Responder including a revocation notice before creating a CRL, the certificate in question is revoked for an RP receiving the OCSP Responder's status but not for an RP accessing only the current CRL. Even along a single path, different RPs may have access to different revocation status for a CA or cross certificate. Further, as demanded by chain processing rules, a revoked parent certificate may or may not cause an RP to deduce that a child certificate status is revoked, independently of the current authoritative revocation status. Therefore, different RPs may arrive at a different view of the revocation status of a EE, CA or cross certificate at a particular time. Resolution of revocation status may be difficult for the RP's software. For example, the software may need to wait for a fresher CRL, the software may need more time than what is available for the desired action, the software may need additional communication channels that are not available to the software at the time of checking, the software might need human intervention, and so on. Using any single mechanism to specify revocation information can be seen as introducing a single point of failure from the RP's software point of view. An RP software relying on the revocation status of a certificate specified by any mechanism, authorized or not by the issuer CA of the certificate, is also subject to conditions defined by the issuer CA. Those conditions may change from time to time. Some mechanisms may not include direct evidence of the issuer CA's assertion of a certificate's revocation status or conditions, at a particular time. With a view to reducing the effect of those limitations, an RP can determine bounds on the extent of those limitations, or at least ways in which those limitations can be bounded. Some of those limitations can also be prevented or reduced by using a strategy of redundancy and diversity. For example: - There are various unspecified and unpublished delays between the time a CA, CRL issuer or OCSP Responder receives notice to revoke, suspend, or reinstate a certificate and the time the information status is made available through the CA's CRL, an indirect CRL, a delta CRL, an OCSP Responder, a DPV Server, or a client. Nonetheless, some of these bounds can be actually known or modeled by an RP. - To prevent single access faults and race conditions, a certificate can use multiple mechanisms to specify revocation information, some of which can be redundant mechanisms, where an RP should be able to interoperate with any of those mechanisms which it trusts. Multiple mechanisms available to an issuer CA include a CDP extension with a URI DistributionPointName, an AIA extension with an OCSP access descriptor, and an AIA extension with an HTTP CRL access descriptor. An RP receiving both an OCSP Responder's status and the CA's CRL for a certificate is less susceptible to race conditions caused by CA's delays when sending status data to the OCSP Responder with a revocation notice and publishing a CRL for the certificate in question. Further, from a particular RP's point of view, the revocation status of a certificate is not enough to define the validity of that certificate. Certificate validity is a function of a number of additional parameters, including the certificate path that the RP trusts to validate the certificate, the access to revocation status information available to the RP, the local policy used by the RP, and the application (the RP software) that the RP will employ. The validity of a certificate refers to conditions that are authoritatively defined locally. Note that the distinction between "revocation" and "validation" has been somewhat blurred in the documentation and informal discussions. It is further corroded by the usual practice of talking about the determination of the revocation status by an RP, whereas all that the RP can do is verify the revocation status, for which conditions the issuer CA is authoritative. That distinction is, however, necessary to preserve both the control needs for PKI, requiring centralized conditions of revocation that are authoritatively defined by the issuer CA, and those business and user needs, requiring local authoritative definition of validation. There are also those cases in which domains may choose to adopt one or other model based on an operational rationale. The flexibility of having both a centralized revocation mechanism and a localized validation mechanism is an important feature of X.509/PKIX. For example, a certificate can also be authoritatively revoked when the issuer CA or the CRL issuer makes the revocation status available to an RP in a reasonable way. For example, by signed XML messages in a wireless network, by SQL over HTTPS, or in a signed SOAP response for database lookup over web services. What matters to the RP is the revocation status, in a repository or as a status message, and whether it has been published by some means acceptable by the RP. As another example, a CRL Issuer or an OCSP responder may perform additional processing, beyond aggregating and republishing revocation notices as revocation status services. If the operator of the service knows an RP's validation criteria, they may apply those criteria when creating a validation service for that RP. In this case, the "validation service" is a policy- enhanced validation service tuned to the acceptance processes of the RP, rather than only to the revocation processes of CAs and their delegates. Can a validation service indicate a certificate to be valid, when the revocation status is revoked? Yes -- e.g., for the purpose of an RP reading a timely message, the security policy of a validation service may consider a certificate to be valid when no revocation status can be contacted. Generalizing this behavior is an implementation flaw, however. For example, the widely used TLS/SSL security application in Internet browsers does not currently verify the revocation status of EE and CA certificates and always considers the resulting undefined revocation status as valid. Now we ask the critical question: When is a certificate revoked? The answer is: when the corresponding revocation status is published by means of one of those mechanisms identified by the issuer CA in a conforming certificate extension, or when any other revocation condition defined by the issuer CA applies. It does not matter when a particular RP is able to verify that status, or what mechanisms an RP can use for such purpose. The revocation status of a certificate issued by a conforming CA does not depend on an RP and is always well-defined from an RP's point of view -- i.e., it is unambiguous (revoked or not revoked) and ultimately verifiable. Therefore, from a particular RP's point of view, the limitations on verifying the current revocation status of a certificate have nothing to do with the eventual result of that verification, which is always well-defined. The limitations have to do with the efforts for that verification, which may require an unspecified amount of time and work. Human intervention may also be necessary. The same considerations apply to certificateHold and removefromCRL status. ACKNOWLEDGMENTS The names cited do not mean endorsement of this work, which is the sole responsibility of the author. I would like to thank very useful comments by Santoshi Chokhani, Tom Gidin, Paul Hoffman, David Kemp, Steve Kent, Stefan Santesson, Peter Williams, Julien Stern and the PKIX list. Ed Gerck egerck@nma.com Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3L0us7N034052; Tue, 20 Apr 2004 17:56:54 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3L0usEG034051; Tue, 20 Apr 2004 17:56:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp.cs.auckland.ac.nz (smtp.cs.auckland.ac.nz [130.216.33.151]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3L0umgq034028 for <ietf-pkix@imc.org>; Tue, 20 Apr 2004 17:56:51 -0700 (PDT) (envelope-from pgut001@cs.auckland.ac.nz) Received: from medusa01 (medusa01.cs.auckland.ac.nz [130.216.34.33]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id 0451F34125; Wed, 21 Apr 2004 12:54:05 +1200 (NZST) Received: from pgut001 by medusa01 with local (Exim 4.30) id 1BG62Z-0002Lz-R3; Wed, 21 Apr 2004 12:56:39 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-pkix@imc.org, lloyd@randombit.net Subject: Re: Status of draft-ietf-pkix-certstore-http? In-Reply-To: <20040420141147.GC29689@acm.jhu.edu> Message-Id: <E1BG62Z-0002Lz-R3@medusa01> Date: Wed, 21 Apr 2004 12:56:39 +1200 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Jack Lloyd <lloyd@randombit.net> writes: >The last version of this draft I can find is -05, expiring in September 2003. >Has this draft been abandoned, or is going to start moving again at some >point? A number of people have been asking that :-). The current draft was mistakenly deleted from the IETF server, I'll get a new version up within the next few days, although I'm not sure what number it'll have because of the missing (deleted) copy. For all intents and purposes it's identical to -05, there's just two minor wording changes. Peter. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3KKOxpK014421; Tue, 20 Apr 2004 13:24:59 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3KKOxZY014420; Tue, 20 Apr 2004 13:24:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail4.atl.registeredsite.com (nobody@mail4.atl.registeredsite.com [64.224.219.78]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3KKOw8T014413 for <ietf-pkix@imc.org>; Tue, 20 Apr 2004 13:24:59 -0700 (PDT) (envelope-from egerck@nma.com) Received: from taurus.hosting4u.net (taurus.hosting4u.net [209.35.191.122]) by mail4.atl.registeredsite.com (8.12.8/8.12.8) with ESMTP id i3KKOvDa015672 for <ietf-pkix@imc.org>; Tue, 20 Apr 2004 20:24:57 GMT Received: from nma.com ([63.204.17.85]) by taurus.hosting4u.net ; Tue, 20 Apr 2004 15:24:55 -0500 Message-ID: <4085870B.55A84F79@nma.com> Date: Tue, 20 Apr 2004 13:24:43 -0700 From: Ed Gerck <egerck@nma.com> X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: PKIX <ietf-pkix@imc.org> Subject: new -- Clarification Note proposal on cert revocation - References: <40759FBB.F9C8C488@nma.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Rcpt-To: <ietf-pkix@imc.org> Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> All, I'm sending this new version for additional list's comments, in its short and long forms. Please refer to the long form if you have questions reading the short form. PKIX list traffic also has ~30 messages recently, Re "cert revocation", showing some of the context and need for this clarification. MOTIVATION (not intended as part of the proposed text) The proposal is to add a Clarification Note to current PKIX documents that deal with revocation and validation of certs. This would help the weary reader, who must otherwise wade through the PKIX documents and list's archives in order to find limitations that are often not so clear to most folks. I also used the opportunity to point out the conditions on those limitations in the long form of the Note, with a view to reducing their effect. The purpose of the Clarification Note is not to reinvent or change X.509 or related PKIX RFCs. The purpose is to clarify and unify PKIX references (including WG context interpretation) in regard to certificate revocation. There should be many paragraphs in X.509 and related PKIX RFCs that are, with analysis, equivalent to the Clarification Note and vice versa. This is how it should be. The informative aspect of the Clarification Note is in terms of ambiguity resolution in the documentation and context interpretation. As reported by Steve Kent, since there is a suggestion before the WG to issue an update to 3280, the WG can decide whether the Clarification Note text should be part of the next update, if the WG proceeds on that work item. CLARIFICATION NOTE ON CERTIFICATE REVOCATION (short form) In X.509/PKIX there is only one issuer CA for a given certificate. Only the issuer CA of a certificate is authoritative for revocation conditions of the certificate. If a certificate is listed as revoked by means of one of those mechanisms identified by the issuer CA in a conforming certificate extension (e.g., a CRL signed by the CA, an indirect CRL signed by the CRL issuer, an OCSP status, an HTTP CRL list), OR if any other revocation condition defined by the issuer CA applies (e.g., expired or revoked issuer CA certificate), the certificate is revoked. Otherwise, the certificate is not revoked. However, from a particular RP's point of view, there are several limitations on verifying the current revocation status of a certificate. For example, if an RP does not support any of the mechanisms defined by the issuer CA to verify the revocation status, or times out during such verification, or cannot find a path to verify the status, then the revocation status is undefined for that RP. Also, since there may be more than one path used to verify the revocation status of the same certificate, the occurrence of race conditions, differently available paths, and revoked parent certificates can lead to ambiguous results for different RPs. Therefore, different RPs may arrive at a different view of the revocation status of a EE, CA or cross certificate at a particular time. An RP software relying on the revocation status of a certificate specified by any mechanism, authorized or not by the issuer CA of the certificate, is also subject to conditions defined by the issuer CA. Those conditions may change from time to time. Some mechanisms may not include direct evidence of the issuer CA's assertion of a certificate's revocation status or conditions, at a particular time. Further, from a particular RP's point of view, the revocation status of a certificate is not enough to define the validity of that certificate. Certificate validity is a function of a number of additional parameters, including the certificate path that the RP trusts to validate the certificate, the access to revocation status information available to the RP, the local policy used by the RP, and the application (the RP software) that the RP will employ. The validity of a certificate refers to conditions that are authoritatively defined locally. Note that the distinction between "revocation" and "validation" has been somewhat blurred in the documentation and informal discussions. That distinction is, however, necessary to preserve both the control needs for PKI, requiring centralized conditions of revocation that are authoritatively defined by the issuer CA, and those business and user needs, requiring local authoritative definition of validation. Now we ask the critical question: When is a certificate revoked? The answer is: when the corresponding revocation status is published by means of one of those mechanisms identified by the issuer CA in a conforming certificate extension, or when any other revocation condition defined by the issuer CA applies. It does not matter when a particular RP is able to verify that status, or what mechanisms an RP can use for such purpose. The revocation status of a certificate issued by a conforming CA does not depend on an RP and is always well-defined from an RP's point of view -- i.e., it is unambiguous (revoked or not revoked) and ultimately verifiable. Therefore, from a particular RP's point of view, the limitations on verifying the current revocation status of a certificate have nothing to do with the eventual result of that verification, which is always well-defined. The limitations have to do with the efforts for that verification, which may require an unspecified amount of time and work. Human intervention may also be necessary. The same considerations apply to certificateHold and removefromCRL status. CLARIFICATION NOTE ON CERTIFICATE REVOCATION (long form) In X.509/PKIX there is only one issuer CA for a given certificate. Only the issuer CA of a certificate is authoritative for revocation conditions of the certificate. One of those conditions is that the certificate must be signed by a CA certificate, issued by the issuer CA, that has not expired and is not revoked. Another condition is that the issuer CA may delegate the authority for a particular certificate's revocation notices and/or status to another entity called the CRL issuer, identified by the CA in the CRL Distribution Point (CDP) extension of the certificate. Another condition is that the issuer CA may send the revocation notice for a particular certificate as a status service to a server identified by the CA in the Authority Information Access (AIA) extension of the certificate with an OCSP access descriptor or an HTTP CRL access descriptor. If a certificate is listed as revoked by means of one of those mechanisms identified by the issuer CA in a conforming certificate extension (e.g., a CRL signed by the CA, an indirect CRL signed by the CRL issuer, an OCSP status, an HTTP CRL list), OR if any other revocation condition defined by the issuer CA applies (e.g., expired or revoked issuer CA certificate), the certificate is revoked. Otherwise, the certificate is not revoked. In short, because the revocation status of a certificate refers to conditions that a conforming issuer CA authoritatively and unambiguously defines, a certificate is either revoked or not from the issuer CA viewpoint. However, from a particular RP's point of view, there are several limitations on verifying the current revocation status of a certificate. For example, if an RP does not support any of the mechanisms defined by the issuer CA to verify the revocation status, or times out during such verification, or cannot find a path to verify the status, then the revocation status is undefined for that RP. According to RFC 3280, this can happen even for a conforming CA and a conforming application (RP software). Conforming CAs are not required to issue CRLs if other revocation or certificate status mechanisms are provided. Conforming applications are NOT REQUIRED to support processing of delta CRLs, indirect CRLs, or CRLs with a scope other than all certificates issued by one CA. Also, since there may be more than one path used to verify the revocation status of the same certificate, the occurrence of race conditions, differently available paths, and revoked parent certificates can lead to ambiguous results for different RPs. If a CA sends status data to an OCSP Responder including a revocation notice before creating a CRL, the certificate in question is revoked for an RP receiving the OCSP Responder's status but not for an RP accessing only the current CRL. Even along a single path, different RPs may have access to different revocation status for a CA or cross certificate. Further, as demanded by chain processing rules, a revoked parent certificate may or may not cause an RP to deduce that a child certificate status is revoked, independently of the current authoritative revocation status. Therefore, different RPs may arrive at a different view of the revocation status of a EE, CA or cross certificate at a particular time. Resolution of revocation status may be difficult for the RP's software. For example, the software may need to wait for a fresher CRL, the software may need more time than what is available for the desired action, the software may need additional communication channels that are not available to the software at the time of checking, the software might need human intervention, and so on. Using any single mechanism to specify revocation information can be seen as introducing a single point of failure from the RP's software point of view. An RP software relying on the revocation status of a certificate specified by any mechanism, authorized or not by the issuer CA of the certificate, is also subject to conditions defined by the issuer CA. Those conditions may change from time to time. Some mechanisms may not include direct evidence of the issuer CA's assertion of a certificate's revocation status or conditions, at a particular time. With a view to reducing the effect of those limitations, an RP can determine bounds on the extent of those limitations, or at least ways in which those limitations can be bounded. Some of those limitations can also be prevented or reduced by using a strategy of redundancy and diversity. For example: - There are various unspecified and unpublished delays between the time a CA, CRL issuer or OCSP Responder receives notice to revoke, suspend, or reinstate a certificate and the time the information status is made available through the CA's CRL, an indirect CRL, a delta CRL, an OCSP Responder, a DPV Server, or a client. Nonetheless, some of these bounds can be actually known or modeled by an RP. - To prevent single access faults and race conditions, a certificate can use multiple mechanisms to specify revocation information, some of which can be redundant mechanisms, where an RP should be able to interoperate with any of those mechanisms which it trusts. Multiple mechanisms available to an issuer CA include a CDP extension with a URI DistributionPointName, an AIA extension with an OCSP access descriptor, and an AIA extension with an HTTP CRL access descriptor. An RP receiving both an OCSP Responder's status and the CA's CRL for a certificate is less susceptible to race conditions caused by CA's delays when sending status data to the OCSP Responder with a revocation notice and publishing a CRL for the certificate in question. Further, from a particular RP's point of view, the revocation status of a certificate is not enough to define the validity of that certificate. Certificate validity is a function of a number of additional parameters, including the certificate path that the RP trusts to validate the certificate, the access to revocation status information available to the RP, the local policy used by the RP, and the application (the RP software) that the RP will employ. The validity of a certificate refers to conditions that are authoritatively defined locally. Note that the distinction between "revocation" and "validation" has been somewhat blurred in the documentation and informal discussions. It is further corroded by the usual practice of talking about the determination of the revocation status by an RP, whereas all that the RP can do is verify the revocation status, for which conditions the issuer CA is authoritative. That distinction is, however, necessary to preserve both the control needs for PKI, requiring centralized conditions of revocation that are authoritatively defined by the issuer CA, and those business and user needs, requiring local authoritative definition of validation. There are also those cases in which domains may choose to adopt one or other model based on an operational rationale. The flexibility of having both a centralized revocation mechanism and a localized validation mechanism is an important feature of X.509/PKIX. For example, a certificate can also be authoritatively revoked when the issuer CA or the CRL issuer makes the revocation status available to an RP in a reasonable way. For example, by signed XML messages in a wireless network, by SQL over HTTPS, or in a signed SOAP response for database lookup over web services. What matters to the RP is the revocation status, in a repository or as a status message, and whether it has been published by some means acceptable by the RP. As another example, a CRL Issuer or an OCSP responder may perform additional processing, beyond aggregating and republishing revocation notices as revocation status services. If the operator of the service knows an RP's validation criteria, they may apply those criteria when creating a validation service for that RP. In this case, the "validation service" is a policy- enhanced validation service tuned to the acceptance processes of the RP, rather than only to the revocation processes of CAs and their delegates. Can a validation service indicate a certificate to be valid, when the revocation status is revoked? Yes -- e.g., for the purpose of an RP reading a timely message, the security policy of a validation service may consider a certificate to be valid when no revocation status can be contacted. Generalizing this behavior is an implementation flaw, however. For example, the widely used TLS/SSL security application in Internet browsers does not currently verify the revocation status of EE and CA certificates and always considers the resulting undefined revocation status as valid. Now we ask the critical question: When is a certificate revoked? The answer is: when the corresponding revocation status is published by means of one of those mechanisms identified by the issuer CA in a conforming certificate extension, or when any other revocation condition defined by the issuer CA applies. It does not matter when a particular RP is able to verify that status, or what mechanisms an RP can use for such purpose. The revocation status of a certificate issued by a conforming CA does not depend on an RP and is always well-defined from an RP's point of view -- i.e., it is unambiguous (revoked or not revoked) and ultimately verifiable. Therefore, from a particular RP's point of view, the limitations on verifying the current revocation status of a certificate have nothing to do with the eventual result of that verification, which is always well-defined. The limitations have to do with the efforts for that verification, which may require an unspecified amount of time and work. Human intervention may also be necessary. The same considerations apply to certificateHold and removefromCRL status. ACKNOWLEDGMENTS The names cited do not mean endorsement of this work, which is the sole responsibility of the author. I would like to thank very useful comments by Santoshi Chokhani, Tom Gidin, Paul Hoffman, David Kemp, Steve Kent, Stefan Santesson, Peter Williams, Julien Stern and the PKIX list. Ed Gerck egerck@nma.com Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3KECBK1077811; Tue, 20 Apr 2004 07:12:11 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3KECBi4077810; Tue, 20 Apr 2004 07:12:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from centaur.acm.jhu.edu (postfix@centaur.acm.jhu.edu [128.220.223.65]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3KEBwl9077772 for <ietf-pkix@imc.org>; Tue, 20 Apr 2004 07:12:08 -0700 (PDT) (envelope-from lloyd@acm.jhu.edu) Received: by centaur.acm.jhu.edu (Postfix, from userid 528) id 90C583EC68; Tue, 20 Apr 2004 10:11:47 -0400 (EDT) Date: Tue, 20 Apr 2004 10:11:47 -0400 From: Jack Lloyd <lloyd@randombit.net> To: ietf-pkix@imc.org Subject: Status of draft-ietf-pkix-certstore-http? Message-ID: <20040420141147.GC29689@acm.jhu.edu> Mail-Followup-To: ietf-pkix@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-GPG-Key-ID: 4DCDF398 X-GPG-Key-Fingerprint: 2DD2 95F9 C7E3 A15E AF29 80E1 D6A9 A5B9 4DCD F398 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> The last version of this draft I can find is -05, expiring in September 2003. Has this draft been abandoned, or is going to start moving again at some point? -Jack Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3J1fonW041142; Sun, 18 Apr 2004 18:41:50 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3J1foOh041141; Sun, 18 Apr 2004 18:41:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail9.atl.registeredsite.com (nobody@mail9.atl.registeredsite.com [64.224.219.83]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3J1fnAf041135 for <ietf-pkix@imc.org>; Sun, 18 Apr 2004 18:41:49 -0700 (PDT) (envelope-from egerck@nma.com) Received: from taurus.hosting4u.net (taurus.hosting4u.net [209.35.191.122]) by mail9.atl.registeredsite.com (8.12.8/8.12.8) with ESMTP id i3J1fsxJ016325; Mon, 19 Apr 2004 01:41:55 GMT Received: from nma.com ([63.204.17.85]) by taurus.hosting4u.net ; Sun, 18 Apr 2004 20:41:53 -0500 Message-ID: <40832E5B.B142B4C7@nma.com> Date: Sun, 18 Apr 2004 18:41:47 -0700 From: Ed Gerck <egerck@nma.com> X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: PKIX <ietf-pkix@imc.org> CC: Stefan Santesson <stefans@microsoft.com> Subject: Re: clarification proposal -- Re: Current status of CRL validation? References: <0C3042E92D8A714783E2C44AB9936E1DE352CC@EUR-MSG-03.europe.corp.microsoft.com> <40744CAD.A9FA6983@nma.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Stefan, On further thought, I'm even more indebted to your observation. It is indeed possible and desirable to eliminate the "valid path" qualifier. BTW, a new (hopefully improved) text shall be available tomorrow. Cheers, Ed Gerck Ed Gerck wrote: > > Stefan Santesson wrote: > > > > The basic assumption for the whole discussion seems to be very confused: > > > > Snip: > > > > > > "Since there may be more than one path used to validate the > > > same certificate, it is possible that some paths to that > > > certificate are valid while others are not." > > > > > > > There is only 1 kind of path that can be used to validate a certificate, > > and that is a valid path. > > Valid to a RP may not be valid to another RP. To clarify this, > the text could say: > > Since there may be more than one path used to validate the same > certificate, it is possible that some paths to that certificate > are valid for some RPs while not valid to other RPs. > > > Valid being defined as a path that pass the > > RPs validation policy (defined at the discretion of the relying party). > > Exactly. It depends on what each RP may choose to rely upon. Different > RPs may define "valid path" in a different way. > > The RP may also receive different answers from valid paths. > > > All other paths are invalid by definition. So among the valid paths > > there is no ambiguity, since they are all valid. > > > > Why complicate things? > > The RPs are complicated ;-) > > Cheers, > Ed Gerck Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3GM2qCJ032391; Fri, 16 Apr 2004 15:02:52 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3GM2qfT032390; Fri, 16 Apr 2004 15:02:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3GM2pVC032372 for <ietf-pkix@imc.org>; Fri, 16 Apr 2004 15:02:51 -0700 (PDT) (envelope-from kent@bbn.com) Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i3GM2l7Z005528; Fri, 16 Apr 2004 18:02:48 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: <p06100506bca5fdcd6024@[128.89.89.75]> In-Reply-To: <017a01c42192$cb215e40$0500a8c0@arport> References: <024001c4216e$3b1ef420$0500a8c0@arport> <p06020403bca1cd55043c@[128.89.89.75]> <017a01c42192$cb215e40$0500a8c0@arport> Date: Fri, 16 Apr 2004 17:21:14 -0400 To: "Anders Rundgren" <anders.rundgren@telia.com> From: Stephen Kent <kent@bbn.com> Subject: Re: Intel killed the smart ID-card Cc: <ietf-pkix@imc.org> Content-Type: multipart/alternative; boundary="============_-1129969580==_ma============" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> --============_-1129969580==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 10:06 PM +0200 4/13/04, Anders Rundgren wrote: >Steve, > >IMO you should rather be happy as this means that the technology you >have been preaching about since ages ago, may finally become >mainstream. Yes, it will also bring new life to "indirect" PKI >schemes like SAML and 3D Secure, but I believe this is just fine. you would :-) > The only major reason why smart cards may be more secure than >mobile phones (here not including physical attacks on the chips) is >that they are so powerless in comparison to the latter. or, stated differently, a simple device has a much better chance of performing a limited set of functions correctly (and securely) than a much more complex device. The original Palms are a good example, vs. Pocket PCs. > Talking about security: How secure is it really to use PIN-codes >in public or unknown PCs? Using the described concept, PIN-codes >never leave your trusted device. I don't use public PCs. In fact, as a Mac user, I try to never use PCs at all. > Assume you are on a the road and don't bring your laptop around, >where would you be able to use your smart ID card? Probably >nowhere. Using mobile phones as "carriers", you are much more >likely to have the ID (and be able to use it) when you actually need >it. I always bring my laptop with me. > Smart ID cards will indeed survive, but only in the DoD and >similar places where it is OK to burn any amount of tax-payer money >in the name of the nation. I am still amazed at the naivete re DoD criteria as expressed by those with no direct knowledge of such criteria. >The smart card vendors have had ample of time to launch a ubiquitous >PKI card and free software but they didn't. Now it is "harvest >time" :-) Please do hold your breath. Steve --============_-1129969580==_ma============ Content-Type: text/html; charset="us-ascii" <!doctype html public "-//W3C//DTD W3 HTML//EN"> <html><head><style type="text/css"><!-- blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 } --></style><title>Re: Intel killed the smart ID-card</title></head><body> <div>At 10:06 PM +0200 4/13/04, Anders Rundgren wrote:</div> <blockquote type="cite" cite><font face="Arial" size="-1">Steve,</font></blockquote> <blockquote type="cite" cite> </blockquote> <blockquote type="cite" cite><font face="Arial" size="-1">IMO you should rather be happy as this means that the technology you have been preaching about since ages ago, may finally become mainstream. Yes, it will also bring new life to "indirect" PKI schemes like SAML and 3D Secure, but I believe this is just fine.</font></blockquote> <div><br></div> <div>you would :-)</div> <div><br></div> <blockquote type="cite" cite> <font face="Arial" size="-1">The only major reason why smart cards<i> may</i> be more secure than mobile phones (here not including physical attacks on the chips) is that they are so powerless in comparison to the latter. </font></blockquote> <div><br></div> <div>or, stated differently, a simple device has a much better chance of performing a limited set of functions correctly (and securely) than a much more complex device. The original Palms are a good example, vs. Pocket PCs.</div> <div><br></div> <blockquote type="cite" cite> <font face="Arial" size="-1">Talking about security: How secure is it really to use PIN-codes in public or unknown PCs? Using the described concept, PIN-codes never leave<i> your</i> trusted device.</font></blockquote> <div><br></div> <div>I don't use public PCs. In fact, as a Mac user, I try to never use PCs at all.</div> <div><br></div> <blockquote type="cite" cite> <font face="Arial" size="-1">Assume you are on a the road and don't bring your laptop around, where would you be able to use your smart ID card? Probably nowhere. Using mobile phones as "carriers", you are much more likely to have the ID (and be able to use it) when you actually need it.</font></blockquote> <div><br></div> <div>I always bring my laptop with me.<br> </div> <blockquote type="cite" cite> <font face="Arial" size="-1">Smart ID cards will indeed survive, but only in the DoD and similar places where it is OK to burn any amount of tax-payer money in the name of the nation.</font></blockquote> <div><br></div> <div>I am still amazed at the naivete re DoD criteria as expressed by those with no direct knowledge of such criteria.</div> <div><br></div> <blockquote type="cite" cite><font face="Arial" size="-1">The smart card vendors have had ample of time to launch a ubiquitous PKI card and free software but they didn't. Now it is "harvest time" :-)</font></blockquote> <div><br></div> <div>Please do hold your breath.</div> <div><br></div> <div>Steve</div> </body> </html> --============_-1129969580==_ma============-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3G0OI6x041496; Thu, 15 Apr 2004 17:24:18 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3G0OIIL041495; Thu, 15 Apr 2004 17:24:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from exchange.microsoft.com ([131.107.8.3]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3G0OHo4041489 for <ietf-pkix@imc.org>; Thu, 15 Apr 2004 17:24:17 -0700 (PDT) (envelope-from trevorf@exchange.microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 15 Apr 2004 17:24:25 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 15 Apr 2004 17:24:23 -0700 Received: from DF-GROMMIT-01.mercury.corp.microsoft.com ([10.197.0.61]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 15 Apr 2004 17:24:22 -0700 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Signing Untrusted SCVP? Date: Thu, 15 Apr 2004 17:24:19 -0700 Message-ID: <33E7A1613A3480448996047B69308A2F02559605@df-grommit-01.dogfood> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Signing Untrusted SCVP? Thread-Index: AcQjSGt9dtTD/g3vTDCGE6kvd6IvigAAGAEw From: "Trevor Freeman" <trevorf@exchange.microsoft.com> To: "Michael Myers" <mmyers@fastq.com>, <ietf-pkix@imc.org> Cc: "Stephen Kent" <kent@bbn.com>, "Santosh Chokhani" <chokhani@orionsec.com>, "David Engberg" <dave@corestreet.com> X-OriginalArrivalTime: 16 Apr 2004 00:24:22.0731 (UTC) FILETIME=[2A9689B0:01C42349] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i3G0OHo4041490 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Hi Michael, Looks like we are still talk past each other. As far as I can see on the list the topic became redundant because the issue was addressed by another mechanism. So is there some new problem which needs to be addressed? Trevor -----Original Message----- From: Michael Myers [mailto:mmyers@fastq.com] Sent: Thursday, April 15, 2004 5:12 PM To: ietf-pkix@imc.org Cc: Stephen Kent; Santosh Chokhani; David Engberg; Trevor Freeman Subject: RE: Signing Untrusted SCVP? Trevor, As the list will show, a rough consensus has been established regarding DPD response signatures. It would be helpful if you were to detail your objections to this outcome. Mike -----Original Message----- From: Trevor Freeman [mailto:trevorf@exchange.microsoft.com] Sent: Thursday, April 15, 2004 3:03 PM To: Michael Myers; ietf-pkix@imc.org Subject: RE: Signing Untrusted SCVP? Hi Michael, I agree we are talking past each other. So David said he had a problem (server load) and could we could address it via method a(unsigned DPD responses), I said we could almost do the same by method b (caching responses) with less impact on the spec, he said he could live with that as a solution. Therefore Dave's issue is addressed and method a is no longer under consideration unless there is something new. Is there something new? Trevor Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3FM2pJ0021055; Thu, 15 Apr 2004 15:02:51 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3FM2pGo021054; Thu, 15 Apr 2004 15:02:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from exchange.microsoft.com ([131.107.8.4]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3FM2osT021045 for <ietf-pkix@imc.org>; Thu, 15 Apr 2004 15:02:50 -0700 (PDT) (envelope-from trevorf@exchange.microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 15 Apr 2004 15:02:50 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 15 Apr 2004 15:02:53 -0700 Received: from DF-GROMMIT-01.mercury.corp.microsoft.com ([10.197.0.61]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 15 Apr 2004 15:06:25 -0700 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Signing Untrusted SCVP? Date: Thu, 15 Apr 2004 15:02:51 -0700 Message-ID: <33E7A1613A3480448996047B69308A2F02559524@df-grommit-01.dogfood> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Signing Untrusted SCVP? Thread-Index: AcQjIVEJHtoQDplORuGp0L/ygE6ftwAEvcpw From: "Trevor Freeman" <trevorf@exchange.microsoft.com> To: "Michael Myers" <mmyers@fastq.com>, <ietf-pkix@imc.org> X-OriginalArrivalTime: 15 Apr 2004 22:06:25.0587 (UTC) FILETIME=[E5069830:01C42335] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i3FM2osT021049 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Hi Michael, I agree we are talking past each other. So David said he had a problem (server load) and could we could address it via method a(unsigned DPD responses), I said we could almost do the same by method b (caching responses) with less impact on the spec, he said he could live with that as a solution. Therefore Dave's issue is addressed and method a is no longer under consideration unless there is something new. Is there something new? Trevor -----Original Message----- From: Michael Myers [mailto:mmyers@fastq.com] Sent: Thursday, April 15, 2004 12:35 PM To: Trevor Freeman; ietf-pkix@imc.org Subject: RE: Signing Untrusted SCVP? Trevor, I fear we may be talking past each other. You're saying caching and I'm saying signing. Note the Subject: line of this thread. Dave had concerns regarding "MUST sign" DPD responses. After some back-and-forth, Steve and Santosh came back advocating for "MUST be capable of" signing, which I proposed and Santosh agreed to. I trust based on his prior comments on this thread that Steve would share Santosh's affinity for this resolution. That said, I worked with Dave to develop a common understanding on what precisely it meant to "be capable of" from the perspectives of implementor and deployer. See below for example, one of many such PKIX exchanges on this subject over the past couple of weeks. Now he too agrees with the change to "MUST be capable of" signing DPD responses. Mike -----Original Message----- From: David Engberg Sent: Tuesday, April 13, 2004 4:17 AM Yes. Is that allowable? . . . Michael Myers wrote: > Dave, > > Do you mean by "removed" that a local administrator may choose > not to install DPD signing? > > Mike Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3FJ10bB095268; Thu, 15 Apr 2004 12:01:00 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3FJ10Hm095267; Thu, 15 Apr 2004 12:01:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from exchange.microsoft.com ([131.107.8.4]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3FJ0xxM095261 for <ietf-pkix@imc.org>; Thu, 15 Apr 2004 12:00:59 -0700 (PDT) (envelope-from trevorf@exchange.microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 15 Apr 2004 12:00:55 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 15 Apr 2004 12:01:03 -0700 Received: from DF-GROMMIT-01.mercury.corp.microsoft.com ([10.197.0.61]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 15 Apr 2004 12:04:09 -0700 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Signing Untrusted SCVP? Date: Thu, 15 Apr 2004 12:01:01 -0700 Message-ID: <33E7A1613A3480448996047B69308A2F025593E3@df-grommit-01.dogfood> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Signing Untrusted SCVP? Thread-Index: AcQjFr1Itq7RHwBDSm6QGQFuu3qzfQABLFMQ From: "Trevor Freeman" <trevorf@exchange.microsoft.com> To: "Michael Myers" <mmyers@fastq.com>, <ietf-pkix@imc.org> X-OriginalArrivalTime: 15 Apr 2004 19:04:09.0374 (UTC) FILETIME=[6E88EBE0:01C4231C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i3FJ0xxM095262 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Hi Michael, The original issue was reducing load on the server, and caching responses is the proposed solution which has consensus so I consider the issue addressed. Is there some other issue that troubles you. Trevor -----Original Message----- From: Michael Myers [mailto:mmyers@fastq.com] Sent: Thursday, April 15, 2004 11:20 AM To: Trevor Freeman; ietf-pkix@imc.org Subject: RE: Signing Untrusted SCVP? Trevor, Caching is ancillary to the issue. The proposed use of "be capable of" enables unsigned DPD responses as long as the server is nonetheless capable of signing them. As to other issues, I only took notice of and action on this one. There may be others I'm not aware of. Mike -----Original Message----- From: Trevor Freeman [mailto:trevorf@exchange.microsoft.com] Sent: Thursday, April 15, 2004 10:27 AM To: Michael Myers; ietf-pkix@imc.org Subject: RE: Signing Untrusted SCVP? Hi Michael, Given Dave agrees that cached server responses meets his needs, what issues are left? Trevor -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Michael Myers Sent: Tuesday, April 13, 2004 4:04 PM To: ietf-pkix@imc.org Subject: RE: Signing Untrusted SCVP? Trevor, It seeks to establish a consensus within the WG on this draft work product. Mike -----Original Message----- From: Trevor Freeman [mailto:trevorf@exchange.microsoft.com] Sent: Tuesday, April 13, 2004 2:44 PM To: Michael Myers; Dave Engberg Cc: ietf-pkix@imc.org Subject: RE: Signing Untrusted SCVP? Mike, I have no idea what this proposed change seeks to accomplish other than defeating the objective on having a reasonable expectation of an onteropabe standard since it make it totally opaque as to what a valid response is. Trevor -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Michael Myers Sent: Tuesday, April 13, 2004 11:17 AM To: Dave Engberg Cc: ietf-pkix@imc.org Subject: RE: Signing Untrusted SCVP? Trevor? Mike -----Original Message----- From: Dave Engberg [mailto:dengberg@corestreet.com] Sent: Tuesday, April 13, 2004 11:03 AM To: Michael Myers Cc: ietf-pkix@imc.org Subject: RE: Signing Untrusted SCVP? Sounds good. -----Original Message----- From: Michael Myers [mailto:mmyers@fastq.com] Sent: Tuesday, April 13, 2004 2:01 PM To: Dave Engberg Cc: ietf-pkix@imc.org Subject: RE: Signing Untrusted SCVP? Dave, Installation from original distribution media is perfectly acceptable to my understanding of "be capable of". The understanding I wish to achieve is that selectable functionality (as defined by "be capable of") is produced, fully tested, and shipped at the same time as mandated functionality--versus rapidly writing the code, perhaps not testing it too much if at all, and hustling out a patch in the context of an emerging threat. Another way of saying it is that "be capable of" does NOT IMHO mean "we'll write, ship and be prepared to support the code when the marketplace asks for it". I see that Steve has provided us his opinion. Can close this thread with a consensus to change the relevant MUSTs to "MUST be capable of"?. Mike Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3FIt1fU094571; Thu, 15 Apr 2004 11:55:01 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3FIt10o094570; Thu, 15 Apr 2004 11:55:01 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.8) with ESMTP id i3FIt0lJ094563 for <ietf-pkix@imc.org>; Thu, 15 Apr 2004 11:55:01 -0700 (PDT) (envelope-from david.cooper@nist.gov) Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id i3FIsvrt015729; Thu, 15 Apr 2004 14:54:57 -0400 Received: from nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id i3FIscNm024416; Thu, 15 Apr 2004 14:54:38 -0400 (EDT) Message-ID: <407EDAC5.6020906@nist.gov> Date: Thu, 15 Apr 2004 14:56:05 -0400 From: "David A. Cooper" <david.cooper@nist.gov> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031010 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jean-Marc Desperrier <jmdesp@free.fr> CC: ietf-pkix@imc.org Subject: Re: R: RFC3280: doubt on the use of UTF8String in encoding RDNs References: <BE82E060F5EA2D44A4CFCFFA8363958803B4BA7D@ntexch00.office.sia.it> <407BE720.3010806@free.fr> In-Reply-To: <407BE720.3010806@free.fr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-NIST-MailScanner: Found to be clean X-MailScanner-From: david.cooper@nist.gov Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Jean-Marc Desperrier wrote: > What I also think in relation to that is that there should be a > normalized, pkix approved test suite for RFC3280 as complete as > possible so that it would be very easy to ask anybody claiming RFC3280 > conformance what the result of the test suite is. Last year NIST, in conjunction with DigitalNet and NSA, developed the Public Key Interoperability Test Suite (PKITS): a path validation test suite that is available at http://csrc.nist.gov/pki/testing/x509paths.html. This test suite includes over 200 tests and was designed to cover most of the features in RFC 3280. I would like to see PKITS adopted for use as you suggest above. If you are interested in using a path validation test suite to test path validation implementations, I would suggest that you look at this test suite. If you believe that new tests would need to be added in order for PKITS to meet your needs, please let me know what new tests you think would be needed and I will consider adding them. The test suite by itself will not be enough to ensure interoperability. RFC 3280 includes many rather obscure features and I don't expect vendors to implement all of them. For the U.S. Government, NIST is trying to address this by creating profiles. We are creating document that specifies the set of features from RFC 3280 that we believe are needed for use within the Federal PKI. In order to achieve interoperability, we will encourage agencies use path validation implementations that implement all of these features and we will encourage them not to use any other features in the certificates and CRLs that they issue. The document specifying which features need to be implemented will also then indicate how PKITS can be used to verify that a path validation implementation implements those features correctly (it will also indicate how to verify that any other feature that is implemented is implemented correctly). The more features that a path validation implementation implements, the more tests from PKITS will need to be run in order to demonstrate correct implementation. However, in no case will the document require that every one of the tests from PKITS be run. As I said above, it is my hope that others will adopt PKITS as well even those who have decided that they need a different set of features than what we believe will be needed within the U.S. Federal PKI. Vendors would just have to run a different subset of PKITS to demonstrate that they implement this different set of features. Dave Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3FHcZRm083092; Thu, 15 Apr 2004 10:38:35 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3FHcZRM083091; Thu, 15 Apr 2004 10:38:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from seguridata1.seguridata.com ([200.57.34.107]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3FHcYI9083054 for <ietf-pkix@imc.org>; Thu, 15 Apr 2004 10:38:34 -0700 (PDT) (envelope-from mars@seguridata.com) Received: from MarsXP ([200.67.231.235]) by seguridata1.seguridata.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 15 Apr 2004 12:39:10 -0500 From: "Miguel Rodriguez" <mars@seguridata.com> To: <ietf-pkix@imc.org> Subject: RE: key uniqueness in a PKI Date: Thu, 15 Apr 2004 12:38:21 -0500 Message-ID: <001201c42310$726950d0$a600a8c0@seguridata.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0013_01C422E6.899348D0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: <4074A00A.5070602@aol.com> X-OriginalArrivalTime: 15 Apr 2004 17:39:11.0000 (UTC) FILETIME=[8FAAC980:01C42310] Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> This is a multi-part message in MIME format. ------=_NextPart_000_0013_01C422E6.899348D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thanks to both Steve and Bill. Now for a more technical question: how bad is not to check for key uniqueness? does anyone know about problems arising from this situation? Thanks in advance, Miguel Rodriguez -----Original Message----- From: Bill Burns [mailto:shadow@aol.com] Sent: Wednesday, April 07, 2004 7:43 PM To: Stephen Kent Cc: Miguel Rodriguez; ietf-pkix@imc.org Subject: Re: key uniqueness in a PKI Stephen Kent wrote on 4/7/04, 1:39 PM: At 10:39 AM -0500 4/7/04, Miguel Rodriguez wrote: Where can I find information on key pair uniqueness in a PKI? Is this issue discussed in an RFC? I will also appreciate comments on this issue, particularly when considering a PKI with several CAs. Thanks. Miguel A Rodriguez SeguriData Mexico there is no standards-based requirement that a CA verify that each cert request contain a unique public key, neither globally nor relative to the certs that the CA has perviously issued. A CA might choose to try to make checks relative to the certs it has issued, and for which it still has this info, but there is no requirement to do so in X.509 nor PKIX standards. Steve FWIW, there's also a mention of this in the WebTrust for CA's documentation. It's not a "requirement" per se, but they seem to suggest that it's a good idea. Nevertheless, that's a pretty expensive operation to perform...especially as the Member base grows. bill ------=_NextPart_000_0013_01C422E6.899348D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Dus-ascii"> <TITLE>Message</TITLE> <META content=3D"MSHTML 6.00.2800.1400" name=3DGENERATOR></HEAD> <BODY> <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN = class=3D741553517-15042004>Thanks=20 to both Steve and Bill. Now for a more technical question: how bad is = not to=20 check for key uniqueness? does anyone know about problems arising from = this=20 situation?</SPAN></FONT></DIV> <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20 class=3D741553517-15042004></SPAN></FONT> </DIV> <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN = class=3D741553517-15042004>Thanks=20 in advance,</SPAN></FONT></DIV> <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20 class=3D741553517-15042004></SPAN></FONT> </DIV> <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN = class=3D741553517-15042004>Miguel=20 Rodriguez</SPAN></FONT></DIV> <BLOCKQUOTE=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px = solid; MARGIN-RIGHT: 0px"> <DIV></DIV> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr = align=3Dleft><FONT=20 face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B> Bill = Burns=20 [mailto:shadow@aol.com] <BR><B>Sent:</B> Wednesday, April 07, 2004 = 7:43=20 PM<BR><B>To:</B> Stephen Kent<BR><B>Cc:</B> Miguel Rodriguez;=20 ietf-pkix@imc.org<BR><B>Subject:</B> Re: key uniqueness in a=20 PKI<BR><BR></FONT></DIV><FONT face=3DTahoma,sans-serif><FONT = size=3D2><SPAN=20 type=3D"cite">Stephen Kent wrote on 4/7/04, 1:39 PM:</SPAN> = </FONT></FONT> <P><FONT face=3DTahoma,sans-serif size=3D2></FONT></P> <BLOCKQUOTE=20 style=3D"PADDING-LEFT: 10px; MARGIN-LEFT: 0pt; BORDER-LEFT: blue thin = solid"=20 type=3D"cite"><FONT face=3DTahoma,sans-serif size=3D2></FONT> <DIV><FONT face=3DTahoma,sans-serif size=3D2>At 10:39 AM -0500 = 4/7/04, Miguel=20 Rodriguez wrote:</FONT></DIV><FONT face=3DTahoma,sans-serif = size=3D2></FONT> <BLOCKQUOTE cite=3D"" type=3D"cite"><FONT face=3DArial = size=3D-1>Where can I find=20 information on key pair uniqueness in a PKI? Is this issue = discussed in an=20 RFC?</FONT></BLOCKQUOTE><FONT face=3DTahoma,sans-serif = size=3D2></FONT> <BLOCKQUOTE cite=3D"" type=3D"cite"><FONT face=3DArial size=3D-1>I = will also=20 appreciate comments on this issue, particularly when considering a = PKI=20 with several CAs.</FONT></BLOCKQUOTE><FONT = face=3DTahoma,sans-serif=20 size=3D2></FONT> <BLOCKQUOTE cite=3D"" type=3D"cite"><FONT face=3DTahoma,sans-serif=20 size=3D2></FONT> </BLOCKQUOTE><FONT face=3DTahoma,sans-serif = size=3D2></FONT> <BLOCKQUOTE cite=3D"" type=3D"cite"><FONT face=3DArial=20 size=3D-1>Thanks.</FONT></BLOCKQUOTE><FONT face=3DTahoma,sans-serif=20 size=3D2></FONT> <BLOCKQUOTE cite=3D"" type=3D"cite"><FONT face=3DTahoma,sans-serif=20 size=3D2></FONT> </BLOCKQUOTE><FONT face=3DTahoma,sans-serif = size=3D2></FONT> <BLOCKQUOTE cite=3D"" type=3D"cite"><FONT face=3DArial = size=3D-1>Miguel A=20 Rodriguez</FONT></BLOCKQUOTE><FONT face=3DTahoma,sans-serif = size=3D2></FONT> <BLOCKQUOTE cite=3D"" type=3D"cite"><FONT face=3DArial=20 size=3D-1>SeguriData</FONT></BLOCKQUOTE><FONT = face=3DTahoma,sans-serif=20 size=3D2></FONT> <BLOCKQUOTE cite=3D"" type=3D"cite"><FONT face=3DArial=20 size=3D-1>Mexico</FONT></BLOCKQUOTE><FONT face=3DTahoma,sans-serif=20 size=3D2></FONT> <DIV><FONT face=3DTahoma,sans-serif size=3D2><BR></FONT></DIV><FONT=20 face=3DTahoma,sans-serif size=3D2></FONT> <DIV><FONT face=3DTahoma,sans-serif size=3D2>there is no = standards-based=20 requirement that a CA verify that each cert request contain a unique = public=20 key, neither globally nor relative to the certs that the CA has = perviously=20 issued. A CA might choose to try to make checks relative to = the certs=20 it has issued, and for which it still has this info, but there is no = requirement to do so in X.509 nor PKIX standards.</FONT></DIV><FONT=20 face=3DTahoma,sans-serif size=3D2></FONT> <DIV><FONT face=3DTahoma,sans-serif size=3D2><BR></FONT></DIV><FONT=20 face=3DTahoma,sans-serif size=3D2></FONT> <DIV><FONT face=3DTahoma,sans-serif = size=3D2>Steve</FONT></DIV></BLOCKQUOTE><FONT=20 size=3D2><FONT face=3DTahoma,sans-serif><BR></FONT></FONT><FONT=20 face=3DTahoma,sans-serif size=3D2><FONT size=3D2>FWIW, there's also a = mention of=20 this in the WebTrust for CA's documentation. It's not a = "requirement"=20 per se, but they seem to suggest that it's a good idea. = Nevertheless,=20 that's a pretty expensive operation to perform...especially as the = Member base=20 grows.<BR><BR>bill</FONT></FONT><BR></BLOCKQUOTE></BODY></HTML> ------=_NextPart_000_0013_01C422E6.899348D0-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3FHQomu081520; Thu, 15 Apr 2004 10:26:50 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3FHQown081519; Thu, 15 Apr 2004 10:26:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from exchange.microsoft.com ([131.107.8.4]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3FHQoEf081513 for <ietf-pkix@imc.org>; Thu, 15 Apr 2004 10:26:50 -0700 (PDT) (envelope-from trevorf@exchange.microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 15 Apr 2004 10:26:56 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 15 Apr 2004 10:26:53 -0700 Received: from DF-GROMMIT-01.mercury.corp.microsoft.com ([10.197.0.61]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 15 Apr 2004 10:26:25 -0700 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Signing Untrusted SCVP? Date: Thu, 15 Apr 2004 10:26:49 -0700 Message-ID: <33E7A1613A3480448996047B69308A2F02559338@df-grommit-01.dogfood> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Signing Untrusted SCVP? Thread-Index: AcQhtqs3z17A/1PHTM+OceIVKUxpXwBV/m4w From: "Trevor Freeman" <trevorf@exchange.microsoft.com> To: "Michael Myers" <mmyers@fastq.com>, <ietf-pkix@imc.org> X-OriginalArrivalTime: 15 Apr 2004 17:26:25.0606 (UTC) FILETIME=[C774EE60:01C4230E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i3FHQoEf081514 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Hi Michael, Given Dave agrees that cached server responses meets his needs, what issues are left? Trevor -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Michael Myers Sent: Tuesday, April 13, 2004 4:04 PM To: ietf-pkix@imc.org Subject: RE: Signing Untrusted SCVP? Trevor, It seeks to establish a consensus within the WG on this draft work product. Mike -----Original Message----- From: Trevor Freeman [mailto:trevorf@exchange.microsoft.com] Sent: Tuesday, April 13, 2004 2:44 PM To: Michael Myers; Dave Engberg Cc: ietf-pkix@imc.org Subject: RE: Signing Untrusted SCVP? Mike, I have no idea what this proposed change seeks to accomplish other than defeating the objective on having a reasonable expectation of an onteropabe standard since it make it totally opaque as to what a valid response is. Trevor -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Michael Myers Sent: Tuesday, April 13, 2004 11:17 AM To: Dave Engberg Cc: ietf-pkix@imc.org Subject: RE: Signing Untrusted SCVP? Trevor? Mike -----Original Message----- From: Dave Engberg [mailto:dengberg@corestreet.com] Sent: Tuesday, April 13, 2004 11:03 AM To: Michael Myers Cc: ietf-pkix@imc.org Subject: RE: Signing Untrusted SCVP? Sounds good. -----Original Message----- From: Michael Myers [mailto:mmyers@fastq.com] Sent: Tuesday, April 13, 2004 2:01 PM To: Dave Engberg Cc: ietf-pkix@imc.org Subject: RE: Signing Untrusted SCVP? Dave, Installation from original distribution media is perfectly acceptable to my understanding of "be capable of". The understanding I wish to achieve is that selectable functionality (as defined by "be capable of") is produced, fully tested, and shipped at the same time as mandated functionality--versus rapidly writing the code, perhaps not testing it too much if at all, and hustling out a patch in the context of an emerging threat. Another way of saying it is that "be capable of" does NOT IMHO mean "we'll write, ship and be prepared to support the code when the marketplace asks for it". I see that Steve has provided us his opinion. Can close this thread with a consensus to change the relevant MUSTs to "MUST be capable of"?. Mike Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3EEWK9u093884; Wed, 14 Apr 2004 07:32:20 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3EEWKtl093883; Wed, 14 Apr 2004 07:32:20 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.8) with ESMTP id i3EEWJO6093877 for <ietf-pkix@imc.org>; Wed, 14 Apr 2004 07:32:19 -0700 (PDT) (envelope-from wpolk@nist.gov) Received: from real2.localdomain ([192.168.2.11]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id i3EEWKmV029093 for <ietf-pkix@imc.org>; Wed, 14 Apr 2004 10:32:20 -0400 Received: from real2.localdomain (real2.localdomain [127.0.0.1]) by real2.localdomain (8.12.8/8.12.8) with ESMTP id i3EEWKW9014503 for <ietf-pkix@imc.org>; Wed, 14 Apr 2004 10:32:20 -0400 Received: (from apache@localhost) by real2.localdomain (8.12.8/8.12.8/Submit) id i3EEWKrh014501 for ietf-pkix@imc.org; Wed, 14 Apr 2004 10:32:20 -0400 Received: from h193007.nist.gov (h193007.nist.gov [129.6.193.7]) by webmail.nist.gov (IMP) with HTTP for <wpolk@localhost>; Wed, 14 Apr 2004 10:32:20 -0400 Message-ID: <1081953140.407d4b7416187@webmail.nist.gov> Date: Wed, 14 Apr 2004 10:32:20 -0400 From: wpolk@nist.gov To: ietf-pkix@imc.org Subject: WG Last Call: Path Building MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.1 X-Originating-IP: 129.6.193.7 X-NIST-MailScanner: Found to be clean X-MailScanner-From: wpolk@nist.gov Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> This message initiates Working Group Last Call for "Certification Path Building". Upon successful completion of WG Last Call, we intend to request progression as an Informational track document. This will be a two week last call. That is, Last call will complete on or after April 28. The document is available at: http://www.ietf.org/internet-drafts/draft-ietf-pkix-certpathbuild-03.txt Thanks, Tim Polk Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3EDStEb085255; Wed, 14 Apr 2004 06:28:55 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3EDStVo085254; Wed, 14 Apr 2004 06:28:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mclean-vscan5.bah.com (mclean-vscan5.bah.com [156.80.3.66]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3EDSsxd085238 for <ietf-pkix@imc.org>; Wed, 14 Apr 2004 06:28:55 -0700 (PDT) (envelope-from chokhani@orionsec.com) Received: from mclean-vscan5.bah.com (mclean-vscan5.bah.com [156.80.3.66]) by mclean-vscan5.bah.com (8.11.0/8.11.0) with SMTP id i3EDSot19357 for <ietf-pkix@imc.org>; Wed, 14 Apr 2004 09:28:51 -0400 (EDT) Received: from mclean-mail.usae.bah.com ([156.80.5.109]) by mclean-vscan5.bah.com (NAVGW 2.5.2.12) with SMTP id M2004041409285010114 for <ietf-pkix@imc.org>; Wed, 14 Apr 2004 09:28:50 -0400 Received: from wchokhani3 ([156.80.127.95]) by mclean-mail.usae.bah.com (Netscape Messaging Server 4.15) with ESMTP id HW5XG200.KDO for <ietf-pkix@imc.org>; Wed, 14 Apr 2004 09:28:50 -0400 From: "Santosh Chokhani" <chokhani@orionsec.com> To: <ietf-pkix@imc.org> Subject: RE: Signing Untrusted SCVP? Date: Wed, 14 Apr 2004 09:28:50 -0400 Message-ID: <000301c42224$6c427c00$5f7f509c@hq.orionsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal In-Reply-To: <407C6E7C.8040006@corestreet.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> I would vote for this be to optional for both the client and the server. Server should be apply the signature if it wants. The client should be able to ignore the signature or unsigned responses if it wants. -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of David Engberg Sent: Tuesday, April 13, 2004 6:50 PM To: Trevor Freeman Cc: Santosh Chokhani; ietf-pkix@imc.org Subject: Re: Signing Untrusted SCVP? My wife would disagree with the assertion that I get smarter with time. Like I said, my company is happy with signed and cached responses as a second choice to improve SCVP DPD scalability. I still believe that some large public deployments would be better off deploying true "Untrusted SCVP" servers with no client-trusted keys to manage and protect at every server. If an Untrusted SCVP server's signing key is really important for security, then it must be really protected, which is generally tricky and expensive. If an Untrusted SCVP server's signing key is not really important for security (i.e. if it is only mitigating one minor waste of client CPU), then the solution isn't to cheaply implement insecure keys. The right solution is for a deployer to remove the key to dispel the illusion that the server should be "Trusted" as an independent PKI authority. But we obviously disagree on this point, and I'll defer to the decision of the PKIX drafters and magistrates. Trevor Freeman wrote: > Dave, > I hope with time we get smarter. Given weare discusting DPD, which > mandated a lage amout of processing, with lots of signatue > validations, I don't see any measuable benefit to htat kind of client. > Given cached respocnes are now caterd for. What is the problems? Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3DN2pUl005055; Tue, 13 Apr 2004 16:02:51 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3DN2pWa005054; Tue, 13 Apr 2004 16:02:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3DN2o0i005048 for <ietf-pkix@imc.org>; Tue, 13 Apr 2004 16:02:50 -0700 (PDT) (envelope-from mmyers@fastq.com) Received: from MMyersLapTop ([65.39.77.135]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id i3DN2uw79319 for <ietf-pkix@imc.org>; Tue, 13 Apr 2004 16:02:56 -0700 (MST) (envelope-from mmyers@fastq.com) From: "Michael Myers" <mmyers@fastq.com> To: <ietf-pkix@imc.org> Subject: RE: Signing Untrusted SCVP? Date: Tue, 13 Apr 2004 16:03:33 -0700 Message-ID: <EOEGJNFMMIBDKGFONJJDKEPADMAA.mmyers@fastq.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <33E7A1613A3480448996047B69308A2F024D0CC0@df-grommit-01.dogfood> Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Trevor, It seeks to establish a consensus within the WG on this draft work product. Mike -----Original Message----- From: Trevor Freeman [mailto:trevorf@exchange.microsoft.com] Sent: Tuesday, April 13, 2004 2:44 PM To: Michael Myers; Dave Engberg Cc: ietf-pkix@imc.org Subject: RE: Signing Untrusted SCVP? Mike, I have no idea what this proposed change seeks to accomplish other than defeating the objective on having a reasonable expectation of an onteropabe standard since it make it totally opaque as to what a valid response is. Trevor -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Michael Myers Sent: Tuesday, April 13, 2004 11:17 AM To: Dave Engberg Cc: ietf-pkix@imc.org Subject: RE: Signing Untrusted SCVP? Trevor? Mike -----Original Message----- From: Dave Engberg [mailto:dengberg@corestreet.com] Sent: Tuesday, April 13, 2004 11:03 AM To: Michael Myers Cc: ietf-pkix@imc.org Subject: RE: Signing Untrusted SCVP? Sounds good. -----Original Message----- From: Michael Myers [mailto:mmyers@fastq.com] Sent: Tuesday, April 13, 2004 2:01 PM To: Dave Engberg Cc: ietf-pkix@imc.org Subject: RE: Signing Untrusted SCVP? Dave, Installation from original distribution media is perfectly acceptable to my understanding of "be capable of". The understanding I wish to achieve is that selectable functionality (as defined by "be capable of") is produced, fully tested, and shipped at the same time as mandated functionality--versus rapidly writing the code, perhaps not testing it too much if at all, and hustling out a patch in the context of an emerging threat. Another way of saying it is that "be capable of" does NOT IMHO mean "we'll write, ship and be prepared to support the code when the marketplace asks for it". I see that Steve has provided us his opinion. Can close this thread with a consensus to change the relevant MUSTs to "MUST be capable of"?. Mike Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3DMlnff004263; Tue, 13 Apr 2004 15:47:49 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3DMlnAo004262; Tue, 13 Apr 2004 15:47:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3DMljVe004254 for <ietf-pkix@imc.org>; Tue, 13 Apr 2004 15:47:49 -0700 (PDT) (envelope-from dengberg@corestreet.com) Received: from localhost (h005008001124.ne.client2.attbi.com[66.31.43.88]) by comcast.net (rwcrmhc11) with ESMTP id <2004041322474401300flidpe>; Tue, 13 Apr 2004 22:47:45 +0000 Received: from localhost ([127.0.0.1] helo=corestreet.com ident=dave) by localhost with esmtp (Exim 3.35 #1 (Debian)) id 1BDWii-0003TJ-00; Tue, 13 Apr 2004 18:49:32 -0400 Message-ID: <407C6E7C.8040006@corestreet.com> Date: Tue, 13 Apr 2004 18:49:32 -0400 From: David Engberg <dengberg@corestreet.com> Organization: CoreStreet User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Trevor Freeman <trevorf@exchange.microsoft.com> CC: Santosh Chokhani <chokhani@orionsec.com>, ietf-pkix@imc.org Subject: Re: Signing Untrusted SCVP? References: <33E7A1613A3480448996047B69308A2F024D0CD8@df-grommit-01.dogfood> In-Reply-To: <33E7A1613A3480448996047B69308A2F024D0CD8@df-grommit-01.dogfood> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> My wife would disagree with the assertion that I get smarter with time. Like I said, my company is happy with signed and cached responses as a second choice to improve SCVP DPD scalability. I still believe that some large public deployments would be better off deploying true "Untrusted SCVP" servers with no client-trusted keys to manage and protect at every server. If an Untrusted SCVP server's signing key is really important for security, then it must be really protected, which is generally tricky and expensive. If an Untrusted SCVP server's signing key is not really important for security (i.e. if it is only mitigating one minor waste of client CPU), then the solution isn't to cheaply implement insecure keys. The right solution is for a deployer to remove the key to dispel the illusion that the server should be "Trusted" as an independent PKI authority. But we obviously disagree on this point, and I'll defer to the decision of the PKIX drafters and magistrates. Trevor Freeman wrote: > Dave, > I hope with time we get smarter. Given weare discusting DPD, which > mandated a lage amout of processing, with lots of signatue validations, > I don't see any measuable benefit to htat kind of client. Given cached > respocnes are now caterd for. What is the problems? Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3DKDuke078674; Tue, 13 Apr 2004 13:13:56 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3DKDus9078672; Tue, 13 Apr 2004 13:13:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from av4-1-sn3.vrr.skanova.net (av4-1-sn3.vrr.skanova.net [81.228.9.111]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3DKDstW078645 for <ietf-pkix@imc.org>; Tue, 13 Apr 2004 13:13:55 -0700 (PDT) (envelope-from anders.rundgren@telia.com) Received: by av4-1-sn3.vrr.skanova.net (Postfix, from userid 502) id 0274D37EAC; Tue, 13 Apr 2004 22:13:53 +0200 (CEST) Received: from smtp1-1-sn3.vrr.skanova.net (smtp1-1-sn3.vrr.skanova.net [81.228.9.177]) by av4-1-sn3.vrr.skanova.net (Postfix) with ESMTP id E036237E96; Tue, 13 Apr 2004 22:13:53 +0200 (CEST) Received: from arport (t11o913p105.telia.com [213.64.28.105]) by smtp1-1-sn3.vrr.skanova.net (Postfix) with SMTP id E963938017; Tue, 13 Apr 2004 22:13:50 +0200 (CEST) Message-ID: <017a01c42192$cb215e40$0500a8c0@arport> From: "Anders Rundgren" <anders.rundgren@telia.com> To: "Stephen Kent" <kent@bbn.com> Cc: <ietf-pkix@imc.org> References: <024001c4216e$3b1ef420$0500a8c0@arport> <p06020403bca1cd55043c@[128.89.89.75]> Subject: Re: Intel killed the smart ID-card Date: Tue, 13 Apr 2004 22:06:21 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0175_01C421A3.8DFA8D50" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> This is a multi-part message in MIME format. ------=_NextPart_000_0175_01C421A3.8DFA8D50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: Intel killed the smart ID-cardSteve, IMO you should rather be happy as this means that the technology you = have been preaching about since ages ago, may finally become mainstream. = Yes, it will also bring new life to "indirect" PKI schemes like SAML = and 3D Secure, but I believe this is just fine. The only major reason why smart cards may be more secure than mobile = phones (here not including physical attacks on the chips) is that they = are so powerless in comparison to the latter.=20 Talking about security: How secure is it really to use PIN-codes in = public or unknown PCs? Using the described concept, PIN-codes never = leave your trusted device. Assume you are on a the road and don't bring your laptop around, where = would you be able to use your smart ID card? Probably nowhere. Using = mobile phones as "carriers", you are much more likely to have the ID = (and be able to use it) when you actually need it. Smart ID cards will indeed survive, but only in the DoD and similar = places where it is OK to burn any amount of tax-payer money in the name = of the nation. The smart card vendors have had ample of time to launch a ubiquitous PKI = card and free software but they didn't. Now it is "harvest time" :-) Anders ----- Original Message -----=20 From: Stephen Kent=20 To: Anders Rundgren=20 Cc: ietf-pkix@imc.org=20 Sent: Tuesday, April 13, 2004 19:02 Subject: Re: Intel killed the smart ID-card At 5:44 PM +0200 4/13/04, Anders Rundgren wrote: From a recent Intel pressrelease: The Intel PXA27x family of processors, formerly code-named = "Bulverde," adds a number of new technologies to address the needs of = cell phone and PDA users. It is the first product to integrate the Intel = Wireless MMX technology, providing additional performance for 3-D games = and advanced video while improving battery-life. The new chip also = utilizes Wireless Intel SpeedStep technology, enabling significant power = savings by intelligently managing voltage and frequency changes similar = to the technology used in the company=B4s notebook processors. Also for the first time, Intel has integrated important security = features through its Intel Wireless Trusted Platform to provide services = such as trusted boot, secure storage of private information and = cryptographic keys, and support for common security protocols. -------------------------------------------------------------------------= --- If you have a device that you already use extensively for other = purposes, that can connect to various services including to local PCs = using WLAN, and this device has a processor of the type above, why would = you ever want a smart ID card that only supports a fraction of the other = device's ID-related use-cases? maybe because a smart card is less likely to be corrupted by e-mail = viruses or the raft of other code that the smart phone is likely to = process, and because I have less than complete confidence in the folks = who can't do floating point division properly, to do security properly = :-) Steve ------=_NextPart_000_0175_01C421A3.8DFA8D50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD><TITLE>Re: Intel killed the smart ID-card</TITLE> <META http-equiv=3DContent-Type content=3D"text/html; = charset=3Diso-8859-1"> <STYLE type=3Dtext/css>BLOCKQUOTE { PADDING-BOTTOM: 0px; PADDING-TOP: 0px } DL { PADDING-BOTTOM: 0px; PADDING-TOP: 0px } UL { PADDING-BOTTOM: 0px; PADDING-TOP: 0px } OL { PADDING-BOTTOM: 0px; PADDING-TOP: 0px } LI { PADDING-BOTTOM: 0px; PADDING-TOP: 0px } </STYLE> <META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR></HEAD> <BODY bgColor=3D#ffffff> <DIV><FONT face=3DArial size=3D2>Steve,</FONT></DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV><FONT face=3DArial size=3D2>IMO you should rather be happy as this = means that=20 the technology you have been preaching about since ages ago, may finally = become=20 mainstream. Yes, it will also bring new life to "indirect" PKI=20 schemes like SAML and 3D Secure, but I believe this is just=20 fine.</FONT></DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV><FONT face=3DArial size=3D2>The only major reason why smart cards = <EM>may=20 </EM>be more secure than mobile phones (here not including physical = attacks on=20 the chips) is that they are so powerless in comparison to the=20 latter. </FONT></DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV><FONT face=3DArial size=3D2>Talking about security: How = secure is it=20 really to use PIN-codes in public or unknown PCs? Using the = described=20 concept, PIN-codes never leave <EM>your</EM> trusted = device.</FONT></DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV><FONT face=3DArial size=3D2>Assume you are on a the road and don't = bring your=20 laptop around, where would you be able to use your smart ID=20 card? Probably nowhere. Using mobile phones as=20 "carriers", you are much more likely to have the ID (and be able to = use=20 it) when you actually need it.</FONT></DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV><FONT face=3DArial size=3D2>Smart ID cards will = indeed survive, but only=20 in the DoD and similar places where it is OK to burn any = amount of=20 tax-payer money in the name of the nation.</FONT></DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV><FONT face=3DArial size=3D2>The smart card vendors have had ample = of time to=20 launch a ubiquitous PKI card and free software but they didn't. = Now it is=20 "harvest time" :-)</FONT></DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV><FONT face=3DArial size=3D2>Anders</FONT></DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; = BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px"> <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV> <DIV=20 style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: = black"><B>From:</B>=20 <A title=3Dkent@bbn.com href=3D"mailto:kent@bbn.com">Stephen Kent</A> = </DIV> <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A = title=3Danders.rundgren@telia.com=20 href=3D"mailto:anders.rundgren@telia.com">Anders Rundgren</A> </DIV> <DIV style=3D"FONT: 10pt arial"><B>Cc:</B> <A = title=3Dietf-pkix@imc.org=20 href=3D"mailto:ietf-pkix@imc.org">ietf-pkix@imc.org</A> </DIV> <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Tuesday, April 13, 2004 = 19:02</DIV> <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> Re: Intel killed the = smart=20 ID-card</DIV> <DIV><BR></DIV> <DIV>At 5:44 PM +0200 4/13/04, Anders Rundgren wrote:</DIV> <BLOCKQUOTE cite=3D"" type=3D"cite"><FONT face=3DArial size=3D-1>From = a recent Intel=20 pressrelease:</FONT></BLOCKQUOTE> <BLOCKQUOTE cite=3D"" type=3D"cite"> </BLOCKQUOTE> <BLOCKQUOTE cite=3D"" type=3D"cite"><FONT face=3DArial size=3D-1>The = Intel PXA27x=20 family of processors, formerly code-named "Bulverde," adds a number = of new=20 technologies to address the needs of cell phone and PDA users. It is = the=20 first product to integrate the Intel Wireless MMX technology, = providing=20 additional performance for 3-D games and advanced video while = improving=20 battery-life. The new chip also utilizes Wireless Intel SpeedStep=20 technology, enabling significant power savings by intelligently = managing=20 voltage and frequency changes similar to the technology used in the=20 company=B4s notebook processors.<BR><BR><FONT = color=3D#0000ff><B>Also for the=20 first time, Intel has integrated important security features through = its=20 Intel Wireless Trusted Platform to provide services such as trusted = boot,=20 secure storage of private information and cryptographic keys, and = support=20 for common security protocols.</B></FONT></FONT></BLOCKQUOTE> <BLOCKQUOTE cite=3D"" type=3D"cite"> </BLOCKQUOTE> <BLOCKQUOTE cite=3D"" type=3D"cite"> <HR> </BLOCKQUOTE> <BLOCKQUOTE cite=3D"" type=3D"cite"><FONT face=3DArial size=3D-1>If = you have a=20 device that you already use extensively for other purposes, = that can=20 connect to various services including to local PCs using WLAN, = and this=20 device has a processor of the type above, why would you ever want a = smart ID=20 card that only supports a fraction of the other device's ID-related=20 use-cases?</FONT></BLOCKQUOTE> <DIV><BR></DIV> <DIV>maybe because a smart card is less likely to be corrupted by = e-mail=20 viruses or the raft of other code that the smart phone is likely to = process,=20 and because I have less than complete confidence in the folks who = can't do=20 floating point division properly, to do security properly :-)</DIV> <DIV><BR></DIV> <DIV>Steve</DIV></BLOCKQUOTE></BODY></HTML> ------=_NextPart_000_0175_01C421A3.8DFA8D50-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3DIGUAs062652; Tue, 13 Apr 2004 11:16:30 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3DIGUoX062651; Tue, 13 Apr 2004 11:16:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3DIGUIU062643 for <ietf-pkix@imc.org>; Tue, 13 Apr 2004 11:16:30 -0700 (PDT) (envelope-from mmyers@fastq.com) Received: from MMyersLapTop ([65.39.77.135]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id i3DIGWw47298; Tue, 13 Apr 2004 11:16:32 -0700 (MST) (envelope-from mmyers@fastq.com) From: "Michael Myers" <mmyers@fastq.com> To: "Dave Engberg" <dengberg@corestreet.com> Cc: <ietf-pkix@imc.org> Subject: RE: Signing Untrusted SCVP? Date: Tue, 13 Apr 2004 11:17:11 -0700 Message-ID: <EOEGJNFMMIBDKGFONJJDEEOPDMAA.mmyers@fastq.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <DE909E05406F3340B186DA5A410B05F642A55D@mongo.corestreet.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Trevor? Mike -----Original Message----- From: Dave Engberg [mailto:dengberg@corestreet.com] Sent: Tuesday, April 13, 2004 11:03 AM To: Michael Myers Cc: ietf-pkix@imc.org Subject: RE: Signing Untrusted SCVP? Sounds good. -----Original Message----- From: Michael Myers [mailto:mmyers@fastq.com] Sent: Tuesday, April 13, 2004 2:01 PM To: Dave Engberg Cc: ietf-pkix@imc.org Subject: RE: Signing Untrusted SCVP? Dave, Installation from original distribution media is perfectly acceptable to my understanding of "be capable of". The understanding I wish to achieve is that selectable functionality (as defined by "be capable of") is produced, fully tested, and shipped at the same time as mandated functionality--versus rapidly writing the code, perhaps not testing it too much if at all, and hustling out a patch in the context of an emerging threat. Another way of saying it is that "be capable of" does NOT IMHO mean "we'll write, ship and be prepared to support the code when the marketplace asks for it". I see that Steve has provided us his opinion. Can close this thread with a consensus to change the relevant MUSTs to "MUST be capable of"?. Mike Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3DI3hNH061702; Tue, 13 Apr 2004 11:03:43 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3DI3hCQ061701; Tue, 13 Apr 2004 11:03:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mongo.corestreet.com (mail.corestreet.com [68.162.232.130]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3DI3gg5061693 for <ietf-pkix@imc.org>; Tue, 13 Apr 2004 11:03:42 -0700 (PDT) (envelope-from dengberg@corestreet.com) X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Signing Untrusted SCVP? Date: Tue, 13 Apr 2004 14:02:59 -0400 Message-ID: <DE909E05406F3340B186DA5A410B05F642A55D@mongo.corestreet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Signing Untrusted SCVP? Thread-Index: AcQhgQ59P2khrboPTqyc9uBjRaj4wwAAIyyQ From: "Dave Engberg" <dengberg@corestreet.com> To: "Michael Myers" <mmyers@fastq.com> Cc: <ietf-pkix@imc.org> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i3DI3hg5061696 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Sounds good. -----Original Message----- From: Michael Myers [mailto:mmyers@fastq.com] Sent: Tuesday, April 13, 2004 2:01 PM To: Dave Engberg Cc: ietf-pkix@imc.org Subject: RE: Signing Untrusted SCVP? Dave, Installation from original distribution media is perfectly acceptable to my understanding of "be capable of". The understanding I wish to achieve is that selectable functionality (as defined by "be capable of") is produced, fully tested, and shipped at the same time as mandated functionality--versus rapidly writing the code, perhaps not testing it too much if at all, and hustling out a patch in the context of an emerging threat. Another way of saying it is that "be capable of" does NOT IMHO mean "we'll write, ship and be prepared to support the code when the marketplace asks for it". I see that Steve has provided us his opinion. Can close this thread with a consensus to change the relevant MUSTs to "MUST be capable of"?. Mike Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3DI01kH061512; Tue, 13 Apr 2004 11:00:01 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3DI01ne061511; Tue, 13 Apr 2004 11:00:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3DI01cL061505 for <ietf-pkix@imc.org>; Tue, 13 Apr 2004 11:00:01 -0700 (PDT) (envelope-from mmyers@fastq.com) Received: from MMyersLapTop ([65.39.77.135]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id i3DI03w44645; Tue, 13 Apr 2004 11:00:03 -0700 (MST) (envelope-from mmyers@fastq.com) From: "Michael Myers" <mmyers@fastq.com> To: "David Engberg" <dengberg@corestreet.com> Cc: <ietf-pkix@imc.org> Subject: RE: Signing Untrusted SCVP? Date: Tue, 13 Apr 2004 11:00:41 -0700 Message-ID: <EOEGJNFMMIBDKGFONJJDOEOODMAA.mmyers@fastq.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <407BCC21.3060205@corestreet.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Dave, Installation from original distribution media is perfectly acceptable to my understanding of "be capable of". The understanding I wish to achieve is that selectable functionality (as defined by "be capable of") is produced, fully tested, and shipped at the same time as mandated functionality--versus rapidly writing the code, perhaps not testing it too much if at all, and hustling out a patch in the context of an emerging threat. Another way of saying it is that "be capable of" does NOT IMHO mean "we'll write, ship and be prepared to support the code when the marketplace asks for it". I see that Steve has provided us his opinion. Can close this thread with a consensus to change the relevant MUSTs to "MUST be capable of"?. Mike -----Original Message----- From: David Engberg Sent: Tuesday, April 13, 2004 4:17 AM Yes. Is that allowable? CoreStreet's OCSP server software can either be deployed in a traditional 1-tier configuration (all online servers have signing keys) or a 2-tier configuration (master servers have keys, lightweight responders have no keys or any code for signing). I'm just curious whether your language would permit SCVP software that not only allowed those two configurations, but also allowed a third configuration where only the lightweight responders (with no keys or signing code) were deployed. The complete software offering is "capable of" producing signatures, but the code running on servers in that third deployment would not be capable. Michael Myers wrote: > Dave, > > Do you mean by "removed" that a local administrator may choose > not to install DPD signing? > > Mike > > -----Original Message----- > From: David Engberg [mailto:dengberg@corestreet.com] > Sent: Monday, April 12, 2004 7:45 PM > > A software product includes a module for performing signatures > on SCVP responses, but an administrator deploys the software > with that module disabled or removed. That software product > would still be compliant because the software is capable of > performing signatures even though the server instance is. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3DH8cSX057686; Tue, 13 Apr 2004 10:08:38 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3DH8c4E057685; Tue, 13 Apr 2004 10:08:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3DH8b8m057678 for <ietf-pkix@imc.org>; Tue, 13 Apr 2004 10:08:37 -0700 (PDT) (envelope-from kent@bbn.com) Received: from [128.33.244.157] (col-dhcp33-244-157.bbn.com [128.33.244.157]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i3DH8Q7Z009402; Tue, 13 Apr 2004 13:08:27 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: <p06020402bca1cb147d21@[128.89.89.75]> In-Reply-To: <407B542B.8020100@corestreet.com> References: <EOEGJNFMMIBDKGFONJJDCEOJDMAA.mmyers@fastq.com> <407B542B.8020100@corestreet.com> Date: Tue, 13 Apr 2004 12:54:36 -0400 To: David Engberg <dengberg@corestreet.com> From: Stephen Kent <kent@bbn.com> Subject: Re: Signing Untrusted SCVP? Cc: Michael Myers <mmyers@fastq.com>, ietf-pkix@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Dave, In essentially all IETF standards we focus on what software must be capable of doing, so that users and administrators are afforded the opportunity to configure a compliant product to enable interoperation between peers or clients and servers, or whatever. I don't see a meaningful difference between the two sorts of configuration options you described. Both represent reasonable ways to allow the local user/admin to be able to interoperate, as desired. Steve Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3DH8V8l057676; Tue, 13 Apr 2004 10:08:31 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3DH8VCf057675; Tue, 13 Apr 2004 10:08:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3DH8UB5057664 for <ietf-pkix@imc.org>; Tue, 13 Apr 2004 10:08:31 -0700 (PDT) (envelope-from kent@bbn.com) Received: from [128.33.244.157] (col-dhcp33-244-157.bbn.com [128.33.244.157]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i3DH8Q7b009402; Tue, 13 Apr 2004 13:08:29 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: <p06020403bca1cd55043c@[128.89.89.75]> In-Reply-To: <024001c4216e$3b1ef420$0500a8c0@arport> References: <024001c4216e$3b1ef420$0500a8c0@arport> Date: Tue, 13 Apr 2004 13:02:52 -0400 To: "Anders Rundgren" <anders.rundgren@telia.com> From: Stephen Kent <kent@bbn.com> Subject: Re: Intel killed the smart ID-card Cc: <ietf-pkix@imc.org> Content-Type: multipart/alternative; boundary="============_-1130246439==_ma============" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> --============_-1130246439==_ma============ Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable At 5:44 PM +0200 4/13/04, Anders Rundgren wrote: >From a recent Intel pressrelease: > >The Intel PXA27x family of processors, formerly=20 >code-named "Bulverde," adds a number of new=20 >technologies to address the needs of cell phone=20 >and PDA users. It is the first product to=20 >integrate the Intel Wireless MMX technology,=20 >providing additional performance for 3-D games=20 >and advanced video while improving battery-life.=20 >The new chip also utilizes Wireless Intel=20 >SpeedStep technology, enabling significant power=20 >savings by intelligently managing voltage and=20 >frequency changes similar to the technology used=20 >in the company=B4s notebook processors. > >Also for the first time, Intel has integrated=20 >important security features through its Intel=20 >Wireless Trusted Platform to provide services=20 >such as trusted boot, secure storage of private=20 >information and cryptographic keys, and support=20 >for common security protocols. > > >If you have a device that you already use=20 >extensively for other purposes, that can connect=20 >to various services including to local PCs using=20 >WLAN, and this device has a processor of the=20 >type above, why would you ever want a smart ID=20 >card that only supports a fraction of the other=20 >device's ID-related use-cases? maybe because a smart card is less likely to be=20 corrupted by e-mail viruses or the raft of other=20 code that the smart phone is likely to process,=20 and because I have less than complete confidence=20 in the folks who can't do floating point division=20 properly, to do security properly :-) Steve --============_-1130246439==_ma============ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!doctype html public "-//W3C//DTD W3 HTML//EN"> <html><head><style type=3D"text/css"><!-- blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 } --></style><title>Re: Intel killed the smart ID-card</title></head><body> <div>At 5:44 PM +0200 4/13/04, Anders Rundgren wrote:</div> <blockquote type=3D"cite" cite><font face=3D"Arial" size=3D"-1">From a recent Intel pressrelease:</font></blockquote> <blockquote type=3D"cite" cite> </blockquote> <blockquote type=3D"cite" cite><font face=3D"Arial" size=3D"-1">The Intel PXA27x family of processors, formerly code-named "Bulverde," adds a number of new technologies to address the needs of cell phone and PDA users. It is the first product to integrate the Intel Wireless MMX technology, providing additional performance for 3-D games and advanced video while improving battery-life. The new chip also utilizes Wireless Intel SpeedStep technology, enabling significant power savings by intelligently managing voltage and frequency changes similar to the technology used in the company=B4s notebook processors.<br> <br> <font color=3D"#0000FF"><b>Also for the first time, Intel has integrated important security features through its Intel Wireless Trusted Platform to provide services such as trusted boot, secure storage of private information and cryptographic keys, and support for common security protocols.</b></font></font></blockquote> <blockquote type=3D"cite" cite> </blockquote> <blockquote type=3D"cite" cite> <hr></blockquote> <blockquote type=3D"cite" cite><font face=3D"Arial" size=3D"-1">If you have a device that you already use extensively for other purposes, that can connect to various services including to local PCs using WLAN, and this device has a processor of the type above, why would you ever want a smart ID card that only supports a fraction of the other device's ID-related use-cases?</font></blockquote> <div><br></div> <div>maybe because a smart card is less likely to be corrupted by e-mail viruses or the raft of other code that the smart phone is likely to process, and because I have less than complete confidence in the folks who can't do floating point division properly, to do security properly :-)</div> <div><br></div> <div>Steve</div> </body> </html> --============_-1130246439==_ma============-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3DFqER3051781; Tue, 13 Apr 2004 08:52:14 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3DFqEMr051780; Tue, 13 Apr 2004 08:52:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from av3-2-sn3.vrr.skanova.net (av3-2-sn3.vrr.skanova.net [81.228.9.110]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3DFqDKJ051772 for <ietf-pkix@imc.org>; Tue, 13 Apr 2004 08:52:14 -0700 (PDT) (envelope-from anders.rundgren@telia.com) Received: by av3-2-sn3.vrr.skanova.net (Postfix, from userid 502) id 2C67E37E63; Tue, 13 Apr 2004 17:52:09 +0200 (CEST) Received: from smtp1-2-sn3.vrr.skanova.net (smtp1-2-sn3.vrr.skanova.net [81.228.9.178]) by av3-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 1DABE37E43 for <ietf-pkix@imc.org>; Tue, 13 Apr 2004 17:52:09 +0200 (CEST) Received: from arport (t7o913p111.telia.com [213.64.26.111]) by smtp1-2-sn3.vrr.skanova.net (Postfix) with SMTP id 98CED38020 for <ietf-pkix@imc.org>; Tue, 13 Apr 2004 17:52:07 +0200 (CEST) Message-ID: <024001c4216e$3b1ef420$0500a8c0@arport> From: "Anders Rundgren" <anders.rundgren@telia.com> To: <ietf-pkix@imc.org> Subject: Intel killed the smart ID-card Date: Tue, 13 Apr 2004 17:44:38 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_023D_01C4217E.FDE118C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> This is a multi-part message in MIME format. ------=_NextPart_000_023D_01C4217E.FDE118C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >From a recent Intel pressrelease: The Intel PXA27x family of processors, formerly code-named "Bulverde," = adds a number of new technologies to address the needs of cell phone and = PDA users. It is the first product to integrate the Intel Wireless MMX = technology, providing additional performance for 3-D games and advanced = video while improving battery-life. The new chip also utilizes Wireless = Intel SpeedStep technology, enabling significant power savings by = intelligently managing voltage and frequency changes similar to the = technology used in the company=B4s notebook processors.=20 Also for the first time, Intel has integrated important security = features through its Intel Wireless Trusted Platform to provide services = such as trusted boot, secure storage of private information and = cryptographic keys, and support for common security protocols. -------------------------------------------------------------------------= ------- If you have a device that you already use extensively for other = purposes, that can connect to various services including to local PCs = using WLAN, and this device has a processor of the type above, why would = you ever want a smart ID card that only supports a fraction of the other = device's ID-related use-cases? -------------------------------------------------------------------------= ------- ------=_NextPart_000_023D_01C4217E.FDE118C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META http-equiv=3DContent-Type content=3D"text/html; = charset=3Diso-8859-1"> <META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR> <STYLE></STYLE> </HEAD> <BODY bgColor=3D#ffffff> <DIV><FONT face=3DArial size=3D2>From a recent Intel = pressrelease:</FONT></DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV><FONT face=3DArial size=3D2>The Intel PXA27x family of processors, = formerly=20 code-named "Bulverde," adds a number of new technologies to address the = needs of=20 cell phone and PDA users. It is the first product to integrate the Intel = Wireless MMX technology, providing additional performance for 3-D games = and=20 advanced video while improving battery-life. The new chip also utilizes = Wireless=20 Intel SpeedStep technology, enabling significant power savings by = intelligently=20 managing voltage and frequency changes similar to the technology used in = the=20 company=B4s notebook processors. <BR><BR><FONT = color=3D#0000ff><STRONG>Also for the=20 first time, Intel has integrated important security features through its = Intel=20 Wireless Trusted Platform to provide services such as trusted boot, = secure=20 storage of private information and cryptographic keys, and support for = common=20 security protocols.</STRONG></FONT></FONT></DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV><FONT face=3DArial size=3D2> <HR> </FONT></DIV> <DIV><FONT face=3DArial size=3D2>If you have a device that you already = use=20 extensively for other purposes, that can connect to various = services=20 including to local PCs</FONT><FONT face=3DArial size=3D2> using = WLAN, and this=20 device has a processor of the type above, why would you ever want a = smart ID=20 card that only supports a fraction of the other device's ID-related=20 use-cases?</FONT><FONT face=3DArial size=3D2></DIV> <DIV> <HR> </DIV></FONT></BODY></HTML> ------=_NextPart_000_023D_01C4217E.FDE118C0-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3DDCD6b040275; Tue, 13 Apr 2004 06:12:13 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3DDCD1Y040274; Tue, 13 Apr 2004 06:12:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp-ft6.fr.colt.net (smtp-ft6.fr.colt.net [213.41.78.209]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3DDCCCg040264 for <ietf-pkix@imc.org>; Tue, 13 Apr 2004 06:12:12 -0700 (PDT) (envelope-from jmdesp@free.fr) Received: from free.fr (host.104.92.68.195.rev.coltfrance.com [195.68.92.104]) by smtp-ft6.fr.colt.net with ESMTP id i3DDCAR12801 for <ietf-pkix@imc.org>; Tue, 13 Apr 2004 15:12:10 +0200 Message-ID: <407BE720.3010806@free.fr> Date: Tue, 13 Apr 2004 15:12:00 +0200 From: Jean-Marc Desperrier <jmdesp@free.fr> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:) Gecko/20040226 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: Re: R: RFC3280: doubt on the use of UTF8String in encoding RDNs References: <BE82E060F5EA2D44A4CFCFFA8363958803B4BA7D@ntexch00.office.sia.it> In-Reply-To: <BE82E060F5EA2D44A4CFCFFA8363958803B4BA7D@ntexch00.office.sia.it> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Santoni Adriano wrote: > Well, it turns out that - despite the topic has been debated in the > past - there is not much consense on the "true" intepretation of RFC > 3280, §4.1.2.4. The sentence " all certificates issued after December > 31, 2003 MUST use the UTF8String encoding of DirectoryString (except > as noted below) " is a prescriptive one, if I am not mistaken. > > Nontheless, Glassey says "you have to do so, full-stop", while Gutman > and Desperrier says "you'd better not" because a) some application > would not handle UTF-8 properly and b) the CA should not "alter" the > name if a certificate already exists for the same subject. I feel I have to say my post was not at all an interpretation of the meaning of RFC3280, and I did not intend to say that part of RFC3280 is not prescriptive. It was just a remark about the state of current applications. They are other aspects of RFC3280 that are certainly no more well supported in practice. This said, AFAIR when the topic was debated in the past, it was concluded that renewal cert were one of the "except as noted below" case. > Regarding point a), I personally agree that some applications will not > behave properly when encountering UTF8Strings, but that should have > been taken into account when drafting RFC 3280, not today! That part of RFC3280 was copied without any change (and I strongly suspect without discussion, or rereading) from RFC2459. At the time RFC2459 was drafted, 2003 was far in the future, and the redactors surely hoped UTF8String would be widely in use before the deadline, so that this deadline would not be much a constraint. > I am sure many of you have noticed that most CAs (all over the planet) > claiming conformance to RFC3280 have not started issuing certificates > with subject names encoded as UTF8String, after 31 december 2003. I > dare to say one of the reasons might be a little ambiguity in RFC 3280 > and probably insufficient debate on this specific topic. I'm not sure the problem is due to any ambiguity in RFC3280. I think some of the problem might be related to few people really trying to implement RFC3280 fully and carefully, many just implementing support for what they see the most often in use. If there is no UTF-8 around, they don't do it, and therefore nobody starts doing it. I'm afraid all what one can hope is that some people will start to implement it because it's written in the RFC, will meet interoperability problems, will tell other implementors they are the one who don't respect the norm, and the other implementators will progressively correct any problem related to that in their code. I now think expecting implementors to prepare for the future, or beginning to implement something until they are forced to is a lost cause, so the prescriptive aspect of RFC3280, and the fact applying it will break a few things, is a good thing if we really want certificates to support internationalization one day. What I also think in relation to that is that there should be a normalized, pkix approved test suite for RFC3280 as complete as possible so that it would be very easy to ask anybody claiming RFC3280 conformance what the result of the test suite is. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3DBFE9W032151; Tue, 13 Apr 2004 04:15:14 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3DBFE4X032150; Tue, 13 Apr 2004 04:15:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3DBFEng032134 for <ietf-pkix@imc.org>; Tue, 13 Apr 2004 04:15:14 -0700 (PDT) (envelope-from dengberg@corestreet.com) Received: from localhost (h005008001124.ne.client2.attbi.com[66.31.43.88]) by comcast.net (sccrmhc11) with ESMTP id <200404131115060110098c7ne>; Tue, 13 Apr 2004 11:15:10 +0000 Received: from localhost ([127.0.0.1] helo=corestreet.com ident=dave) by localhost with esmtp (Exim 3.35 #1 (Debian)) id 1BDLuP-0003DL-00; Tue, 13 Apr 2004 07:16:53 -0400 Message-ID: <407BCC21.3060205@corestreet.com> Date: Tue, 13 Apr 2004 07:16:49 -0400 From: David Engberg <dengberg@corestreet.com> Organization: CoreStreet User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Myers <mmyers@fastq.com> CC: ietf-pkix@imc.org Subject: Re: Signing Untrusted SCVP? References: <EOEGJNFMMIBDKGFONJJDKEOKDMAA.mmyers@fastq.com> In-Reply-To: <EOEGJNFMMIBDKGFONJJDKEOKDMAA.mmyers@fastq.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Yes. Is that allowable? CoreStreet's OCSP server software can either be deployed in a traditional 1-tier configuration (all online servers have signing keys) or a 2-tier configuration (master servers have keys, lightweight responders have no keys or any code for signing). I'm just curious whether your language would permit SCVP software that not only allowed those two configurations, but also allowed a third configuration where only the lightweight responders (with no keys or signing code) were deployed. The complete software offering is "capable of" producing signatures, but the code running on servers in that third deployment would not be capable. Michael Myers wrote: > Dave, > > Do you mean by "removed" that a local administrator may choose > not to install DPD signing? > > Mike > > -----Original Message----- > From: David Engberg [mailto:dengberg@corestreet.com] > Sent: Monday, April 12, 2004 7:45 PM > > A software product includes a module for performing signatures > on SCVP > responses, but an administrator deploys the software with that > module > disabled or removed. That software product would still be > compliant > because the software is capable of performing signatures even > though the > server instance is not ... (?) > > Or is there a subtle difference between configuration vs. code? > I.e. > would it be ok to turn off signing in an XML file, but not ok to > do so > by installing only half of a complete DPD/DPV suite? > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3DAuKeU030652; Tue, 13 Apr 2004 03:56:20 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3DAuKc8030651; Tue, 13 Apr 2004 03:56:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3DAuIan030631 for <ietf-pkix@imc.org>; Tue, 13 Apr 2004 03:56:19 -0700 (PDT) (envelope-from Peter.Sylvester@edelweb.fr) Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id i3DAuEN23452 for <ietf-pkix@imc.org>; Tue, 13 Apr 2004 12:56:14 +0200 (MEST) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Tue, 13 Apr 2004 12:56:14 +0200 (MET DST) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i3DAuDJ12500 for ietf-pkix@imc.org; Tue, 13 Apr 2004 12:56:13 +0200 (MEST) Date: Tue, 13 Apr 2004 12:56:13 +0200 (MEST) From: Peter Sylvester <Peter.Sylvester@edelweb.fr> Message-Id: <200404131056.i3DAuDJ12500@chandon.edelweb.fr> To: ietf-pkix@imc.org Subject: scvp X-Sun-Charset: US-ASCII Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> SCVP 14: 3.4 Requestor The OPTIONAL requestor item is a reference local to the requestor. The value is only of local significance to the requestor. If the SCVP client includes a requestor value in the request, then the SCVP server MUST return the same value in a unique SCVP response. The SCVP server MAY omit the requestor value from cached SCVP responses. SCVP 13: The OPTIONAL requestor item is a reference local to the requestor. The value is only of local significance to the requestor. If the SCVP client includes a requestor value in the request, then the SCVP server MUST return the same value in the response. As far as I remember, there was no discussion about this. I think that the following sentence of 4.6 does not respect the requirements. 4.6 Requestor The OPTIONAL requestor item is used to identify the requestor. The value is only of local significance to the requestor. requirements say: When the DPV request is authenticated, the client SHOULD be able to include a client identifier in the request for the DPV server to copy into the response. Mechanisms for matching this identifier with the authenticated identity depends on local DPV server conditions and/or the validation policy. The DPV server MAY choose to blindly copy the identifier, omit the identifier, or return an error response. IMO this clearly indicates that the identifier has a meaning for the server. Unless I have overlooked something, I have not seen any response to the following. Maybe the content of my message considered as pure nonsense. Date: Tue Oct 28 18:43:58 2003 To: kent@bbn.com, ietf-pkix@imc.org, trevorf@windows.microsoft.com Subject: RE: SCVP additions hello, It would be nice to hear whether all or which comments about SCVP have been addressed. Unless I have overlooked something, my remarks about the definitions of requestor and responder have not received any treatment. I simplify the content of my comments: requestor and responder should be GENERALNAMES which indicate and identify in global the partipating parties. IMO Using arbitrary octets with only LOCAL significance is not compatible with the procedure to detect loops. 4.6 indicates the there MUST NOt be null characters, something which is explicitly allowed for a server acting as a relay. What is the sense of 4.7? The responder field is never used anywhere in the actual protocol, what is the meaning of such an opaque value? 4.8.5 What is the reason of having an additional octet string encapsulation instead of an any defined by construct? Is it that some tools may break decodeing when they find an OID that is not known? If so, whay are there ANY DEFINED BYs at other places? can someone indicate me how a relay would return the response of the next server to a client as part of his response? regards Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3D9hxK2024471; Tue, 13 Apr 2004 02:43:59 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3D9hxCl024470; Tue, 13 Apr 2004 02:43:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from nic.lp.se (nic.lp.se [213.212.3.208]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3D9hwIB024461 for <ietf-pkix@imc.org>; Tue, 13 Apr 2004 02:43:58 -0700 (PDT) (envelope-from levitte@lp.se) Received: from localhost (127.0.0.1) by nic.lp.se (MX V5.3 VnHj) with ESMTP; Tue, 13 Apr 2004 11:43:36 +0200 Date: Tue, 13 Apr 2004 11:43:34 +0200 (CEST) Message-ID: <20040413.114334.116352625.levitte@lp.se> To: adriano.santoni@actalis.it CC: todd.glassey@worldnet.att.net, pgut001@cs.auckland.ac.nz, jmdesp@free.fr, ietf-pkix@imc.org Subject: Re: R: RFC3280: doubt on the use of UTF8String in encoding RDNs From: Richard Levitte - VMS Whacker <levitte@lp.se> In-Reply-To: <BE82E060F5EA2D44A4CFCFFA8363958803B4BA7D@ntexch00.office.sia.it> References: <BE82E060F5EA2D44A4CFCFFA8363958803B4BA7D@ntexch00.office.sia.it> X-URL: http://www.lp.se/ X-Waved: dead chicken, GNU emacs 21.3.1, Mew version 4.0.64 X-Mew: See http://www.mew.org/ X-Mailer: Mew version 4.0.64 on Emacs 21.3 / Mule 5.0 (SAKAKI) 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: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> In message <BE82E060F5EA2D44A4CFCFFA8363958803B4BA7D@ntexch00.office.sia.it> on Tue, 13 Apr 2004 08:42:40 +0200, Santoni Adriano <adriano.santoni@actalis.it> said: adriano.santoni> Regarding point a), I personally agree that some adriano.santoni> applications will not behave properly when adriano.santoni> encountering UTF8Strings, but that should have been adriano.santoni> taken into account when drafting RFC 3280, not today! A question, what does X.509 say about this? It may be that some people confuse X.509 with RFC3280, thinking they are interchangeable (they seem to be, more or less, at least last time I looked at the ASN.1 module). Having X.509 and RFC3280 differ on this point may be another cause for confusion... ----- Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte | http://richard.levitte.org/ | Tunnlandsv. 52 Levitte Programming | http://www.lp.se/ | S-168 36 Bromma T: +46-708-26 53 44 | | SWEDEN "Price, performance, quality... choose the two you like" Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3D6h1M6060453; Mon, 12 Apr 2004 23:43:01 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3D6h12S060452; Mon, 12 Apr 2004 23:43:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from ntexch03.office.sia.it (clients.sia.it [193.203.230.22] (may be forged)) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3D6gtbc060361 for <ietf-pkix@imc.org>; Mon, 12 Apr 2004 23:43:00 -0700 (PDT) (envelope-from adriano.santoni@actalis.it) Received: by ntexch03.office.sia.it with Internet Mail Service (5.5.2657.72) id <HJMG7RMN>; Tue, 13 Apr 2004 08:42:47 +0200 Message-ID: <BE82E060F5EA2D44A4CFCFFA8363958803B4BA7D@ntexch00.office.sia.it> From: Santoni Adriano <adriano.santoni@actalis.it> To: "'todd glassey'" <todd.glassey@worldnet.att.net>, pgut001@cs.auckland.ac.nz, "'jmdesp@free.fr'" <jmdesp@free.fr> Cc: ietf-pkix@imc.org Subject: R: RFC3280: doubt on the use of UTF8String in encoding RDNs Date: Tue, 13 Apr 2004 08:42:40 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C42122.84780F13" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C42122.84780F13 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Well, it turns out that - despite the topic has been debated in the = past - there is not much consense on the "true" intepretation of RFC 3280, =C2=A74.1.2.4. The sentence "all certificates issued after December 31, = 2003 MUST use the UTF8String encoding of DirectoryString (except as noted below)" = is a prescriptive one, if I am not mistaken. =20 Nontheless, Glassey says "you have to do so, full-stop", while Gutman = and Desperrier says "you'd better not" because a) some application would = not handle UTF-8 properly and b) the CA should not "alter" the name if a certificate already exists for the same subject. =20 Regarding point a), I personally agree that some applications will not behave properly when encountering UTF8Strings, but that should have = been taken into account when drafting RFC 3280, not today!=20 =20 Regarding point b), I think the problem may largely vary depending on specific circumstances. It depends very much on what the user asks and = pays for, and what the CA offers (only certificates or software as well?) = and claims (e.g. interoperability?). =20 I am sure many of you have noticed that most CAs (all over the planet) claiming conformance to RFC3280 have not started issuing certificates = with subject names encoded as UTF8String, after 31 december 2003. I dare to = say one of the reasons might be a little ambiguity in RFC 3280 and probably insufficient debate on this specific topic.=20 =20 AS =20 -----Messaggio originale----- Da: todd glassey [mailto:todd.glassey@worldnet.att.net]=20 Inviato: venerd=C3=AC 9 aprile 2004 15.32 A: Santoni Adriano; pgut001@cs.auckland.ac.nz Cc: ietf-pkix@imc.org Oggetto: Re: RFC3280: doubt on the use of UTF8String in encoding RDNs Peter - Santoni, the RFC is the RFC and it says MUST, and it addresses = the NameRollover issues as well with commentary about=20 =20 (a) CAs MAY issue "name rollover" certificates to support an orderly migration to UTF8String encoding. Such certificates = would include the CA's UTF8String encoded name as issuer and and the = old name encoding as subject, or vice-versa. ... http://www.faqs.org/rfcs/rfc3280.html <http://www.faqs.org/rfcs/rfc3280.html>=20 =20 So my reading is that UTF8 is not optional. =20 Todd Glassey =20 ----- Original Message -----=20 From: Santoni Adriano <mailto:adriano.santoni@actalis.it> =20 To: 'pgut001@cs.auckland.ac.nz' <mailto:'pgut001@cs.auckland.ac.nz'> =20 Cc: ietf-pkix@imc.org <mailto:ietf-pkix@imc.org> =20 Sent: Friday, April 09, 2004 3:35 AM Subject: R: RFC3280: doubt on the use of UTF8String in encoding RDNs Thanks for replying, although it seems a reply to another question (my fault, I presume).=20 I was referring to new certificates, issued "from today on" (so to = speak).=20 As a CA, we do not handle DNs "encoded by the originator"; which "originator" at any rate?=20 We register people, collecting their own true names, and then we build = the DNs to be inserted into certificates. The names can be e.g. the = ASCII-safe name "Peter Gutman", or the polish name "Anna Kr=C4=99glewska", or the = greek "=CE=91=CE=BD=CE=B4=CF=81=CE=B5=CE=B1=CF=83 = =CE=91=CE=BD=CE=B4=CF=81=CE=B5=CE=BF=CF=80=CE=BF=CF=85=CE=BB=CE=BF=CF=83= " or whatever else - can you read? :-). In the case of your name, a PrintableString would be "safe", as it would retain all = the original information. In the latter cases, it would not and so it makes = more sense to use Unicode encoded as UTF8String. Maybe I am just not getting what you mean...=20 Adriano=20 -----Messaggio originale-----=20 Da: pgut001 [ <mailto:pgut001@medusa01.cs.auckland.ac.nz> mailto:pgut001@medusa01.cs.auckland.ac.nz] Per conto di pgut001@cs.auckland.ac.nz=20 Inviato: mercoled=C3=AC 7 aprile 2004 15.55=20 A: adriano.santoni@actalis.it; ietf-pkix@imc.org=20 Oggetto: Re: RFC3280: doubt on the use of UTF8String in encoding RDNs=20 Santoni Adriano <adriano.santoni@actalis.it> writes:=20 >I am probably asking an old question, so ... please be patient.=20 >=20 >Rfc3280 states (<A7>4.1.2.4): "...all certificates issued after=20 >December 31, 2003 MUST use the UTF8String encoding of=20 >DirectoryString...".=20 >=20 >Does that mean that it is mandatory to always encode all RDNs (having = a=20 >type of DirectoryString) of the issuer and subject (and still other)=20 >certificate fields as UTF8Strings _even if they could be correctly=20 >encoded as a PrintableStrings_ ?=20 Hmm, see the previous thread on this a few months ago... in theory = you're supposed to do this, but that violates the primary rule of DN encoding, which is "Never change the DN once it's been encoded by the = originator". If you break that rule, you get to discover all the apps that reject = re-encoded DNs. If you're lucky, this will happen before your product ships and = not after. Peter.=20 *******************Internet Email Confidentiality = Footer*******************=20 Qualsiasi utilizzo non autorizzato del presente messaggio nonche' dei = suoi allegati e' vietato e potrebbe costituire reato. Se lei ha ricevuto erroneamente il presente messaggio, Le saremmo grati se, via e-mail, ce = ne comunicasse la ricezione e provvedesse alla distruzione del messaggio = stesso e dei suoi eventuali allegati. Le dichiarazioni contenute nel presente messaggio nonche' nei suoi eventuali allegati devono essere attribuite esclusivamente al mittente e non possono essere considerate come = trasmesse o autorizzate da SIA S.p.A.; le medesime dichiarazioni non impegnano SIA S.p.A. nei confronti del destinatario o di terzi.=20 SIA S.p.A. non si assume alcuna responsabilita' per eventuali intercettazioni, modifiche o danneggiamenti del presente messaggio = e-mail.=20 Any unauthorized use of this e-mail or any of its attachments is = prohibited and could constitute an offence. If you are not the intended addressee please advise immediately the sender by using the reply facility in = your e-mail software and destroy the message and its attachments. The = statements and opinions expressed in this e-mail message are those of the author = of the message and do not necessarily represent those of SIA. Besides, The = contents of this message shall be understood as neither given nor endorsed by = SIA S.p.A..=20 SIA S.p.A. does not accept liability for corruption, interception or amendment, if any, or the consequences thereof.=20 *******************Internet Email Confidentiality = Footer*******************=20 Qualsiasi utilizzo non autorizzato del presente messaggio nonche' dei = suoi allegati e' vietato e potrebbe costituire reato. Se lei ha ricevuto erroneamente il presente messaggio, Le saremmo grati se, via e-mail, ce = ne comunicasse la ricezione e provvedesse alla distruzione del messaggio = stesso e dei suoi eventuali allegati. Le dichiarazioni contenute nel presente messaggio nonche' nei suoi eventuali allegati devono essere attribuite esclusivamente al mittente e non possono essere considerate come = trasmesse o autorizzate da SIA S.p.A.; le medesime dichiarazioni non impegnano SIA S.p.A. nei confronti del destinatario o di terzi.=20 SIA S.p.A. non si assume alcuna responsabilita' per eventuali intercettazioni, modifiche o danneggiamenti del presente messaggio = e-mail.=20 Any unauthorized use of this e-mail or any of its attachments is = prohibited and could constitute an offence. If you are not the intended addressee please advise immediately the sender by using the reply facility in = your e-mail software and destroy the message and its attachments. The = statements and opinions expressed in this e-mail message are those of the author = of the message and do not necessarily represent those of SIA. Besides, The = contents of this message shall be understood as neither given nor endorsed by = SIA S.p.A..=20 SIA S.p.A. does not accept liability for corruption, interception or amendment, if any, or the consequences thereof.=20 ------_=_NextPart_001_01C42122.84780F13 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3DUTF-8"> <TITLE>Messaggio</TITLE> <META content=3D"MSHTML 6.00.2800.1400" name=3DGENERATOR> <STYLE></STYLE> </HEAD> <BODY bgColor=3D#ffffff> <DIV><SPAN class=3D215471806-13042004><FONT face=3DVerdana = color=3D#0000ff>Well, it=20 turns out that - despite the topic has been debated in the past - there = is not=20 much consense on the "true" intepretation of RFC 3280, =C2=A74.1.2.4. = The sentence=20 "<FONT color=3D#000000>all certificates issued after December 31, 2003 = MUST use=20 the UTF8String encoding of DirectoryString (except as noted = below)</FONT>" is a=20 prescriptive one, if I am not mistaken.</FONT></SPAN></DIV> <DIV><SPAN class=3D215471806-13042004><FONT face=3DVerdana=20 color=3D#0000ff></FONT></SPAN> </DIV> <DIV><SPAN class=3D215471806-13042004><FONT face=3DVerdana = color=3D#0000ff>Nontheless,=20 Glassey says "you have to do so, full-stop", while Gutman and = Desperrier says=20 "you'd better not" because </FONT></SPAN><SPAN=20 class=3D215471806-13042004><FONT face=3DVerdana color=3D#0000ff>a) some = application=20 would not handle UTF-8 properly and </FONT></SPAN><SPAN=20 class=3D215471806-13042004><FONT face=3DVerdana color=3D#0000ff>b) the = CA should not=20 "alter" the name if a certificate already exists for the same=20 subject.</FONT></SPAN></DIV> <DIV><SPAN class=3D215471806-13042004><FONT face=3DVerdana=20 color=3D#0000ff></FONT></SPAN> </DIV> <DIV><SPAN class=3D215471806-13042004><FONT face=3DVerdana = color=3D#0000ff>Regarding=20 point a), I personally agree that some applications will not behave = properly=20 when encountering UTF8Strings, but that should have been taken into = account when=20 drafting RFC 3280, not today! </FONT></SPAN></DIV> <DIV><SPAN class=3D215471806-13042004></SPAN> </DIV> <DIV><SPAN class=3D215471806-13042004></SPAN><SPAN = class=3D215471806-13042004><FONT=20 face=3DVerdana color=3D#0000ff><SPAN class=3D215471806-13042004><FONT = face=3DVerdana=20 color=3D#0000ff>Regarding point b), I think the problem may largely = vary depending=20 on specific circumstances</FONT></SPAN></FONT></SPAN><SPAN=20 class=3D215471806-13042004><FONT face=3DVerdana color=3D#0000ff><SPAN=20 class=3D215471806-13042004><FONT face=3DVerdana color=3D#0000ff>. It = depends very much=20 on what the user asks and pays for, and what the CA offers (only = certificates or=20 software as well?) and claims (e.g.=20 interoperability?).</FONT></SPAN></FONT></SPAN></DIV> <DIV><SPAN class=3D215471806-13042004><FONT face=3DVerdana = color=3D#0000ff><SPAN=20 class=3D215471806-13042004></SPAN></FONT></SPAN> </DIV> <DIV><SPAN class=3D215471806-13042004><FONT face=3DVerdana = color=3D#0000ff><SPAN=20 class=3D215471806-13042004>I am sure many of you have noticed = that most CAs=20 (all over the planet) claiming conformance to RFC3280 have not started = issuing=20 certificates with subject names encoded as UTF8String, after 31 = december 2003. I=20 dare to say one of the reasons might be a little ambiguity in RFC 3280 = and=20 probably insufficient debate on this specific=20 topic. </SPAN></FONT></SPAN></DIV> <DIV><SPAN class=3D215471806-13042004><FONT face=3DVerdana = color=3D#0000ff><SPAN=20 class=3D215471806-13042004></SPAN></FONT></SPAN> </DIV> <DIV><SPAN class=3D215471806-13042004><FONT face=3DVerdana = color=3D#0000ff><SPAN=20 class=3D215471806-13042004>AS</SPAN></FONT></SPAN></DIV> <DIV><SPAN class=3D215471806-13042004><FONT face=3DVerdana=20 color=3D#0000ff></FONT></SPAN> </DIV> <BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px"> <DIV></DIV> <DIV class=3DOutlookMessageHeader lang=3Dit dir=3Dltr = align=3Dleft><FONT face=3DTahoma=20 size=3D2>-----Messaggio originale-----<BR><B>Da:</B> todd glassey=20 [mailto:todd.glassey@worldnet.att.net] <BR><B>Inviato:</B> = venerd=C3=AC 9 aprile=20 2004 15.32<BR><B>A:</B> Santoni Adriano;=20 pgut001@cs.auckland.ac.nz<BR><B>Cc:</B> ietf-pkix@imc.org<BR><B>Oggett= o:</B>=20 Re: RFC3280: doubt on the use of UTF8String in encoding=20 RDNs<BR><BR></FONT></DIV> <DIV><FONT face=3DArial size=3D2>Peter - Santoni, the RFC is the RFC = and it says=20 MUST, and it addresses the NameRollover issues as well with = commentary about=20 </FONT></DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV><FONT face=3DArial> (a) CAs = MAY issue=20 "name rollover" certificates to support = an<BR> =20 orderly migration to UTF8String encoding. Such certificates=20 would<BR> include the CA's UTF8String = encoded=20 name as issuer and and the old<BR> name = encoding=20 as subject, or vice-versa.<BR></FONT></DIV> <DIV><FONT face=3DArial size=3D2>... <A=20 = href=3D"http://www.faqs.org/rfcs/rfc3280.html">http://www.faqs.org/rfcs/= rfc3280.html</A></FONT></DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV><FONT face=3DArial size=3D2>So my reading is that UTF8 is not=20 optional.</FONT></DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV><FONT face=3DArial size=3D2>Todd Glassey</FONT></DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <BLOCKQUOTE=20 style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; = BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px"> <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV> <DIV=20 style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: = black"><B>From:</B>=20 <A title=3Dadriano.santoni@actalis.it=20 href=3D"mailto:adriano.santoni@actalis.it">Santoni Adriano</A> = </DIV> <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A = title=3Dpgut001@cs.auckland.ac.nz=20 = href=3D"mailto:'pgut001@cs.auckland.ac.nz'">'pgut001@cs.auckland.ac.nz'<= /A>=20 </DIV> <DIV style=3D"FONT: 10pt arial"><B>Cc:</B> <A = title=3Dietf-pkix@imc.org=20 href=3D"mailto:ietf-pkix@imc.org">ietf-pkix@imc.org</A> </DIV> <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Friday, April 09, 2004 = 3:35=20 AM</DIV> <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> R: RFC3280: doubt = on the use=20 of UTF8String in encoding RDNs</DIV> <DIV><BR></DIV> <P><FONT face=3DVerdana color=3D#0000ff>Thanks for replying, = although it seems a=20 reply to another question (my fault, I presume). </FONT></P> <P><FONT face=3DVerdana color=3D#0000ff>I was referring to new = certificates,=20 issued "from today on" (so to speak). </FONT></P> <P><FONT face=3DVerdana color=3D#0000ff>As a CA, we do not handle = DNs "encoded=20 by the originator"; which "originator" at any rate? </FONT></P> <P><FONT face=3DVerdana color=3D#0000ff>We register people, = collecting their own=20 true names, and then we build the DNs to be inserted into = certificates. The=20 names can be e.g. the ASCII-safe name "Peter Gutman", or the polish = name=20 "Anna Kr</FONT><FONT face=3DVerdana = color=3D#0000ff>=C4=99glewska</FONT><FONT=20 face=3DVerdana color=3D#0000ff>", or the greek "</FONT><FONT = face=3DVerdana=20 color=3D#0000ff>=CE=91=CE=BD=CE=B4=CF=81=CE=B5=CE=B1=CF=83 = =CE=91=CE=BD=CE=B4=CF=81=CE=B5=CE=BF=CF=80=CE=BF=CF=85=CE=BB=CE=BF=CF=83= </FONT><FONT face=3DVerdana color=3D#0000ff>"=20 or whatever else - can you read? :-). In the case of your name, a=20 PrintableString would be "safe", as it would retain all the = original=20 information. In the latter cases, it would not and so it makes more = sense to=20 use Unicode encoded as UTF8String.</FONT></P> <P><FONT face=3DVerdana color=3D#0000ff>Maybe I am just not getting = what you=20 mean...</FONT> </P> <P><FONT face=3DVerdana color=3D#0000ff>Adriano</FONT> </P><BR> <P><FONT face=3DArial size=3D2>-----Messaggio originale-----</FONT> = <BR><FONT=20 face=3DArial size=3D2>Da: pgut001 [</FONT><A=20 href=3D"mailto:pgut001@medusa01.cs.auckland.ac.nz"><U><FONT = face=3DArial=20 color=3D#0000ff=20 = size=3D2>mailto:pgut001@medusa01.cs.auckland.ac.nz</FONT></U></A><FONT=20 face=3DArial size=3D2>] Per conto di = pgut001@cs.auckland.ac.nz</FONT> <BR><FONT=20 face=3DArial size=3D2>Inviato: mercoled=C3=AC 7 aprile 2004 = 15.55</FONT> <BR><FONT=20 face=3DArial size=3D2>A: adriano.santoni@actalis.it; = ietf-pkix@imc.org</FONT>=20 <BR><FONT face=3DArial size=3D2>Oggetto: Re: RFC3280: doubt on the = use of=20 UTF8String in encoding RDNs</FONT> </P><BR> <P><FONT face=3DArial size=3D2>Santoni Adriano=20 <adriano.santoni@actalis.it> writes:</FONT> </P> <P><FONT face=3DArial size=3D2>>I am probably asking an old = question, so ...=20 please be patient.</FONT> <BR><FONT face=3DArial = size=3D2>></FONT> <BR><FONT=20 face=3DArial size=3D2>>Rfc3280 states (<A7>4.1.2.4): = "...all=20 certificates issued after </FONT><BR><FONT face=3DArial = size=3D2>>December=20 31, 2003 MUST use the UTF8String encoding of </FONT><BR><FONT = face=3DArial=20 size=3D2>>DirectoryString...".</FONT> <BR><FONT face=3DArial=20 size=3D2>></FONT> <BR><FONT face=3DArial size=3D2>>Does that = mean that it is=20 mandatory to always encode all RDNs (having a </FONT><BR><FONT = face=3DArial=20 size=3D2>>type of DirectoryString) of the issuer and subject = (and still=20 other) </FONT><BR><FONT face=3DArial size=3D2>>certificate = fields as=20 UTF8Strings _even if they could be correctly </FONT><BR><FONT = face=3DArial=20 size=3D2>>encoded as a PrintableStrings_ ?</FONT> </P> <P><FONT face=3DArial size=3D2>Hmm, see the previous thread on this = a few months=20 ago... in theory you're supposed to do this, but that violates the = primary=20 rule of DN encoding, which is "Never change the DN once it's been = encoded by=20 the originator". If you break that rule, you get to discover = all the=20 apps that reject re-encoded DNs. If you're lucky, this will happen = before=20 your product ships and not after.</FONT></P> <P><FONT face=3DArial size=3D2>Peter.</FONT> </P><BR> <P><FONT face=3DArial size=3D2>*******************Internet Email = Confidentiality=20 Footer******************* </FONT><BR><FONT face=3DArial = size=3D2>Qualsiasi=20 utilizzo non autorizzato del presente messaggio nonche' dei suoi = allegati e'=20 vietato e potrebbe costituire reato. Se lei ha ricevuto = erroneamente il=20 presente messaggio, Le saremmo grati se, via e-mail, ce ne = comunicasse la=20 ricezione e provvedesse alla distruzione del messaggio stesso e dei = suoi=20 eventuali allegati. Le dichiarazioni contenute nel presente = messaggio=20 nonche' nei suoi eventuali allegati devono essere attribuite = esclusivamente=20 al mittente e non possono essere considerate come trasmesse o = autorizzate da=20 SIA S.p.A.; le medesime dichiarazioni non impegnano SIA S.p.A. nei = confronti=20 del destinatario o di terzi. </FONT></P> <P><FONT face=3DArial size=3D2>SIA S.p.A. non si assume alcuna = responsabilita'=20 per eventuali intercettazioni, modifiche o danneggiamenti del = presente=20 messaggio e-mail. </FONT></P> <P><FONT face=3DArial size=3D2>Any unauthorized use of this e-mail = or any of its=20 attachments is prohibited and could constitute an offence. If you = are not=20 the intended addressee please advise immediately the sender by = using the=20 reply facility in your e-mail software and destroy the message and = its=20 attachments. The statements and opinions expressed in this e-mail = message=20 are those of the author of the message and do not necessarily = represent=20 those of SIA. Besides, The contents of this message shall be = understood as=20 neither given nor endorsed by SIA S.p.A.. </FONT></P> <P><FONT face=3DArial size=3D2>SIA S.p.A. does not accept liability = for=20 corruption, interception or amendment, if any, or the consequences = thereof.=20 </FONT></P><BR></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML> <BR> <BR> <P><FONT SIZE=3D2 FACE=3D"Arial">*******************Internet Email = Confidentiality Footer******************* </FONT></P> <P><FONT SIZE=3D2 FACE=3D"Arial">Qualsiasi utilizzo non autorizzato del = presente messaggio nonche' dei suoi allegati e' vietato e potrebbe = costituire reato. Se lei ha ricevuto erroneamente il presente = messaggio, Le saremmo grati se, via e-mail, ce ne comunicasse la = ricezione e provvedesse alla distruzione del messaggio stesso e dei = suoi eventuali allegati. Le dichiarazioni contenute nel presente = messaggio nonche' nei suoi eventuali allegati devono essere attribuite = esclusivamente al mittente e non possono essere considerate come = trasmesse o autorizzate da SIA S.p.A.; le medesime dichiarazioni non = impegnano SIA S.p.A. nei confronti del destinatario o di terzi. = </FONT></P> <P><FONT SIZE=3D2 FACE=3D"Arial">SIA S.p.A. non si assume alcuna = responsabilita' per eventuali intercettazioni, modifiche o = danneggiamenti del presente messaggio e-mail. </FONT></P> <BR> <P><FONT SIZE=3D2 FACE=3D"Arial">Any unauthorized use of this e-mail or = any of its attachments is prohibited and could constitute an offence. = If you are not the intended addressee please advise immediately the = sender by using the reply facility in your e-mail software and destroy = the message and its attachments. The statements and opinions expressed = in this e-mail message are those of the author of the message and do = not necessarily represent those of SIA. Besides, The contents of this = message shall be understood as neither given nor endorsed by SIA = S.p.A.. </FONT></P> <P><FONT SIZE=3D2 FACE=3D"Arial">SIA S.p.A. does not accept liability = for corruption, interception or amendment, if any, or the consequences = thereof. </FONT></P> <BR> <BR> ------_=_NextPart_001_01C42122.84780F13-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3D4CoBJ011906; Mon, 12 Apr 2004 21:12:50 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3D4CopV011905; Mon, 12 Apr 2004 21:12:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3D4CnUF011899 for <ietf-pkix@imc.org>; Mon, 12 Apr 2004 21:12:50 -0700 (PDT) (envelope-from mmyers@fastq.com) Received: from MMyersLapTop ([65.39.77.135]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id i3D4Crw72609; Mon, 12 Apr 2004 21:12:53 -0700 (MST) (envelope-from mmyers@fastq.com) From: "Michael Myers" <mmyers@fastq.com> To: "David Engberg" <dengberg@corestreet.com> Cc: <ietf-pkix@imc.org> Subject: RE: Signing Untrusted SCVP? Date: Mon, 12 Apr 2004 21:13:32 -0700 Message-ID: <EOEGJNFMMIBDKGFONJJDKEOKDMAA.mmyers@fastq.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <407B542B.8020100@corestreet.com> Importance: Normal Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Dave, Do you mean by "removed" that a local administrator may choose not to install DPD signing? Mike -----Original Message----- From: David Engberg [mailto:dengberg@corestreet.com] Sent: Monday, April 12, 2004 7:45 PM A software product includes a module for performing signatures on SCVP responses, but an administrator deploys the software with that module disabled or removed. That software product would still be compliant because the software is capable of performing signatures even though the server instance is not ... (?) Or is there a subtle difference between configuration vs. code? I.e. would it be ok to turn off signing in an XML file, but not ok to do so by installing only half of a complete DPD/DPV suite? Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3D2hEZQ098455; Mon, 12 Apr 2004 19:43:14 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3D2hEtR098454; Mon, 12 Apr 2004 19:43:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3D2hDwJ098435 for <ietf-pkix@imc.org>; Mon, 12 Apr 2004 19:43:13 -0700 (PDT) (envelope-from dengberg@corestreet.com) Received: from localhost (h005008001124.ne.client2.attbi.com[66.31.43.88]) by comcast.net (rwcrmhc11) with ESMTP id <2004041302431401300feckre>; Tue, 13 Apr 2004 02:43:15 +0000 Received: from localhost ([127.0.0.1] helo=corestreet.com ident=dave) by localhost with esmtp (Exim 3.35 #1 (Debian)) id 1BDDv2-000334-00; Mon, 12 Apr 2004 22:45:00 -0400 Message-ID: <407B542B.8020100@corestreet.com> Date: Mon, 12 Apr 2004 22:44:59 -0400 From: David Engberg <dengberg@corestreet.com> Organization: CoreStreet User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Myers <mmyers@fastq.com> CC: ietf-pkix@imc.org Subject: Re: Signing Untrusted SCVP? References: <EOEGJNFMMIBDKGFONJJDCEOJDMAA.mmyers@fastq.com> In-Reply-To: <EOEGJNFMMIBDKGFONJJDCEOJDMAA.mmyers@fastq.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> A software product includes a module for performing signatures on SCVP responses, but an administrator deploys the software with that module disabled or removed. That software product would still be compliant because the software is capable of performing signatures even though the server instance is not ... (?) Or is there a subtle difference between configuration vs. code? I.e. would it be ok to turn off signing in an XML file, but not ok to do so by installing only half of a complete DPD/DPV suite? Michael Myers wrote: > Dave, > > Please expand "may not deploy with this feature." > > Mike > > > > -----Original Message----- > From: Dave Engberg > Sent: Monday, April 12, 2004 2:31 PM > > I assumed that "MUST be capable of" meant that every running > server > instance itself must have the ability to perform signatures. If > the > correct interpretation for "capable of" is that the software > product has > the capability, but some instances may not deploy with this > feature, > then this sounds good to me. > > In short, yes. > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3D2UlDV096754; Mon, 12 Apr 2004 19:30:47 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3D2UllY096753; Mon, 12 Apr 2004 19:30:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3D2UkVF096745 for <ietf-pkix@imc.org>; Mon, 12 Apr 2004 19:30:46 -0700 (PDT) (envelope-from mmyers@fastq.com) Received: from MMyersLapTop ([65.39.77.135]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id i3D2Upw62374; Mon, 12 Apr 2004 19:30:51 -0700 (MST) (envelope-from mmyers@fastq.com) From: "Michael Myers" <mmyers@fastq.com> To: "Dave Engberg" <dengberg@corestreet.com>, <ietf-pkix@imc.org> Subject: RE: Signing Untrusted SCVP? Date: Mon, 12 Apr 2004 19:31:30 -0700 Message-ID: <EOEGJNFMMIBDKGFONJJDCEOJDMAA.mmyers@fastq.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <DE909E05406F3340B186DA5A410B05F642A512@mongo.corestreet.com> Importance: Normal Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Dave, Please expand "may not deploy with this feature." Mike -----Original Message----- From: Dave Engberg Sent: Monday, April 12, 2004 2:31 PM I assumed that "MUST be capable of" meant that every running server instance itself must have the ability to perform signatures. If the correct interpretation for "capable of" is that the software product has the capability, but some instances may not deploy with this feature, then this sounds good to me. In short, yes. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3D0gXoq081287; Mon, 12 Apr 2004 17:42:33 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3D0gXT3081286; Mon, 12 Apr 2004 17:42:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3D0gWrM081254 for <ietf-pkix@imc.org>; Mon, 12 Apr 2004 17:42:32 -0700 (PDT) (envelope-from kent@bbn.com) Received: from [10.84.130.97] (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i3D0gD7Z004263; Mon, 12 Apr 2004 20:42:22 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@localhost Message-Id: <p06020404bca0e6cfe956@[10.84.130.97]> In-Reply-To: <DE909E05406F3340B186DA5A410B05F642A512@mongo.corestreet.com> References: <DE909E05406F3340B186DA5A410B05F642A512@mongo.corestreet.com> Date: Mon, 12 Apr 2004 20:39:15 -0400 To: "Dave Engberg" <dengberg@corestreet.com> From: Stephen Kent <kent@bbn.com> Subject: RE: Signing Untrusted SCVP? Cc: <ietf-pkix@imc.org> Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> At 5:30 PM -0400 4/12/04, Dave Engberg wrote: >I assumed that "MUST be capable of" meant that every running server >instance itself must have the ability to perform signatures. If the >correct interpretation for "capable of" is that the software product has >the capability, but some instances may not deploy with this feature, >then this sounds good to me. > >In short, yes. > Dave, MUST in this context means that it must be possible for the user/admin/owner to configure the server to perform the operation, not that the server must always be ready to perform the operation irrespective of the locally managed configuration. Steve Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3CLVVdt055066; Mon, 12 Apr 2004 14:31:31 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3CLVVin055065; Mon, 12 Apr 2004 14:31:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mongo.corestreet.com (mail.corestreet.com [68.162.232.130]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3CLVU4w055045 for <ietf-pkix@imc.org>; Mon, 12 Apr 2004 14:31:31 -0700 (PDT) (envelope-from dengberg@corestreet.com) X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Signing Untrusted SCVP? Date: Mon, 12 Apr 2004 17:30:48 -0400 Message-ID: <DE909E05406F3340B186DA5A410B05F642A512@mongo.corestreet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Signing Untrusted SCVP? Thread-Index: AcQg1KiESFBqXLqJTni64BKTMvJx2QAAAfrw From: "Dave Engberg" <dengberg@corestreet.com> To: <ietf-pkix@imc.org> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i3CLVV4w055060 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> I assumed that "MUST be capable of" meant that every running server instance itself must have the ability to perform signatures. If the correct interpretation for "capable of" is that the software product has the capability, but some instances may not deploy with this feature, then this sounds good to me. In short, yes. -----Original Message----- From: Michael Myers Sent: Sat, 10 Apr 2004 15:24:18 -0700 Subject: RE: Signing Untrusted SCVP? My opinion is that as long as DPD-only servers are capable of signing responses, I don't see a problem with such servers not shipping with active key material. They may not be operationally capable nor deployed so but would be functionally capable of compliance. The distinction is that a local security administrator is able to activate DPD signing in response to emerging threats without recourse to a vendor's software update. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3CEJLoP002461; Mon, 12 Apr 2004 07:19:21 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3CEJLeg002460; Mon, 12 Apr 2004 07:19:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3CEJLIO002441 for <ietf-pkix@imc.org>; Mon, 12 Apr 2004 07:19:21 -0700 (PDT) (envelope-from kent@bbn.com) Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i3CEJE7b002750; Mon, 12 Apr 2004 10:19:18 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: <p06020403bca04f47f68a@[128.89.89.75]> In-Reply-To: <407793C0.30400@strongauth.com> References: <428a370f.370f428a@noorhome.net> <p06020403bc97150f71da@[128.89.89.75]> <40724DEC.3060007@strongauth.com> <p06020404bc985cf94cad@[128.89.89.75]> <4073866D.4090507@strongauth.com> <p06020403bc99b5e1231c@[128.89.89.75]> <4074D666.3090002@strongauth.com> <p06020417bc9c9973795e@[128.89.89.75]> <407793C0.30400@strongauth.com> Date: Mon, 12 Apr 2004 09:55:31 -0400 To: Arshad Noor <arshad.noor@strongauth.com> From: Stephen Kent <kent@bbn.com> Subject: Re: Identity Firewalls - Was: PKI International Consortium Cc: PKIX list <ietf-pkix@imc.org> Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> At 11:27 PM -0700 4/9/04, Arshad Noor wrote: >It is unrealistic only if we accept status quo, Steve. If we change >the operating conditions - based on reason - then reality changes. >I don't deny that it is an arduous task - but I do not accept that >it is impossible. I would not say that it is impossible, just highly unlikely and not very desirable. I won't bother boring the list with responses to each of your comments. If you believe this is both a feasible and desirable outcome, and want to convince others, then you should write papers that are peer reviewed and published, to demonstrate that you are not alone in this view. Web pages published by oneself or one's company are merely advertisements and warrant no serious consideration in a debate like this. Steve Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3BMfmG4017792; Sun, 11 Apr 2004 15:41:48 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3BMfmDV017791; Sun, 11 Apr 2004 15:41:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from imf17aec.mail.bellsouth.net (imf17aec.mail.bellsouth.net [205.152.59.65]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3BMflms017775 for <ietf-pkix@imc.org>; Sun, 11 Apr 2004 15:41:47 -0700 (PDT) (envelope-from brian@holmespun.biz) Received: from holmespun.biz ([68.157.45.154]) by imf17aec.mail.bellsouth.net (InterMail vM.5.01.06.08 201-253-122-130-108-20031117) with ESMTP id <20040411224147.GBTG5947.imf17aec.mail.bellsouth.net@holmespun.biz>; Sun, 11 Apr 2004 18:41:47 -0400 Message-ID: <4079CA25.4010603@holmespun.biz> Date: Sun, 11 Apr 2004 18:43:49 -0400 From: "Brian G. Holmes" <brian@holmespun.biz> Organization: Holmespun Solutions, LLC User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Gutmann <pgut001@cs.auckland.ac.nz> CC: ietf-pkix@imc.org Subject: Re: Decoding Service Support References: <E1BCK08-0008Vj-Tp@medusa01> In-Reply-To: <E1BCK08-0008Vj-Tp@medusa01> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> The dumpasn1 tool is similar to the 'decode ber' functionality provided by the Berasno service. The 'decode ber' function provides information extracted only from the data; the structure encoded there. http://www.holmespun.biz/berasno/example/index.html The Berasno service is capable of providing much more. Please see the examples displayed at the address above. The 'decode ietf snmp', 'decode itu tcap', and 'decode gsm map' functions are able to name the elements (the TLVs) that are found within the data. Consider the certs/DSAParametersInheritedCACert.crt certificate from NIST's PKITS_data.zip test data file. Where the 'decode ber' function would tell us that the 0x30 tag at offset 4 represents a [UNIVERSAL 16] SEQUENCE, a 'decode x509' function would strive to identify that element as an instance of a PKIX1Explicit88.Certificate.tbsCertificate. Where the 'decode ber' function would tell us that the 0xA3 tag at offset 349 represents an [APPLICATION 3] SEQUENCE, a 'decode x509' function would strive to identify that element as an instance of PKIX1Explicit88.Certificate.tbsCertificate.extensions. As I alluded to in my previous message, the 'decode gsm map' function extends the identification of elements from one layer (TCAP) using OID information to do the same for a second/nested layer (MAP). The 'decode x509' function would likely do the same for certificate extensions. I envision supporting additional input formats, and providing additional output formats, to meet the needs of the users of the service. One improvement would see value decoding for primitives whose tags are not UNIVERSAL. Another improvement that I would like to introduce would be to produce output using a Basic XER (XML) format; a format that may be easier to read than the one currently in use. BGH Peter Gutmann wrote: > "Brian G. Holmes" <brian@holmespun.biz> writes: > > >>I support a free BER for ASN.1 decoding service known as the Berasno Decoding >>Service. > > > How is this different from something like dumpasn1? > > Peter. > -- Holmespun Solutions, LLC http://www.holmespun.biz 919-844-7713 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3BFU77g058437; Sun, 11 Apr 2004 08:30:07 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3BFU7IK058436; Sun, 11 Apr 2004 08:30:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from av3-1-sn4.m-sp.skanova.net (av3-1-sn4.m-sp.skanova.net [81.228.10.114]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3BFU6Dw058426 for <ietf-pkix@imc.org>; Sun, 11 Apr 2004 08:30:06 -0700 (PDT) (envelope-from anders.rundgren@telia.com) Received: by av3-1-sn4.m-sp.skanova.net (Postfix, from userid 502) id E60BA37E67; Sun, 11 Apr 2004 17:30:01 +0200 (CEST) Received: from smtp2-1-sn4.m-sp.skanova.net (smtp2-1-sn4.m-sp.skanova.net [81.228.10.183]) by av3-1-sn4.m-sp.skanova.net (Postfix) with ESMTP id D726B37E4D; Sun, 11 Apr 2004 17:30:01 +0200 (CEST) Received: from arport (t11o913p27.telia.com [213.64.28.27]) by smtp2-1-sn4.m-sp.skanova.net (Postfix) with SMTP id 9CE4937E56; Sun, 11 Apr 2004 17:29:59 +0200 (CEST) Message-ID: <003101c41fd8$d0f460d0$0500a8c0@arport> From: "Anders Rundgren" <anders.rundgren@telia.com> To: <lynn.wheeler@firstdata.com> Cc: "PKIX list" <ietf-pkix@imc.org> References: <OF05034AAF.537BC923-ON87256E73.004CA7DA@firstdata.com> Subject: SAML/3D Secure vs Kerberos. l PKI International Consortium Date: Sun, 11 Apr 2004 17:22:32 +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 Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> >i was at a presentation of a vendor SAML product about a year ago that was >being deployed in a number of institutions. the CTO was presenting all the >message flows. I made some comment that the message flows looked nearly the >same as a Kerberos presentation i had sat thru circa 1990. The response was >that there was just only so many ways that distributed security control >could be implemented. This is correct. Same goes for 3D Secure which is really very much a dedicated SAML. What's making these schemes more powerful (in a web- environment nota bene), than Kerberos is that they build on XML allowing assertions of any size and semantics. Web- browser redirects and ECMA-script-driven auto-POSTs does the rest. Now, what does this has to do with PKI and the Identity Firewall? Well, the 3D Secure and SAML credentials are typically secured by signatures and certificates operating at "business partner level". Voila! The same "level" typically used for leased lines in B2B networks. The rest is for the PKI community to understand the huge consequences of (and some day maybe take action on). Anders anders rundgre wrote: What Steve did not mention, is that the authentication and authorization schemes that are firmly in place since three decades or so for bank-to-bank and supplier-to-manufacturer networks, together with recent developmemts like SAML and 3D Secure, will likely forever change how PKI is applied, which also will affect schemes like the Identity Firewall. Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3BE3Nwl047997; Sun, 11 Apr 2004 07:03:23 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3BE3MqJ047996; Sun, 11 Apr 2004 07:03:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mdhagsmtp01.firstdata.com (mdhagsmtp01.firstdata.com [198.184.5.21]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3BE3MeW047989 for <ietf-pkix@imc.org>; Sun, 11 Apr 2004 07:03:22 -0700 (PDT) (envelope-from lynn.wheeler@firstdata.com) Subject: Re:Identity Firewall. l PKI International Consortium To: "Anders Rundgren" <anders.rundgren@telia.com> Cc: "Arshad Noor" <arshad.noor@strongauth.com>, "PKIX list" <ietf-pkix@imc.org>, "Stephen Kent" <kent@bbn.com>, owner-ietf-pkix@mail.imc.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: <OF05034AAF.537BC923-ON87256E73.004CA7DA@firstdata.com> From: lynn.wheeler@firstdata.com Date: Sun, 11 Apr 2004 08:02:28 -0600 X-MIMETrack: Serialize by Router on MDHAGSMTP/FDMS/FDC(Release 6.0.2CF2|July 23, 2003) at 04/11/2004 10:02:25 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> i was at a presentation of a vendor SAML product about a year ago that was being deployed in a number of institutions. the CTO was presenting all the message flows. I made some comment that the message flows looked nearly the same as a Kerberos presentation i had sat thru circa 1990. The response was that there was just only so many ways that distributed security control could be implemented. anders rundgre wrote: What Steve did not mention, is that the authentication and authorization schemes that are firmly in place since three decades or so for bank-to-bank and supplier-to-manufacturer networks, together with recent developmemts like SAML and 3D Secure, will likely forever change how PKI is applied, which also will affect schemes like the Identity Firewall. -- Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3B9uH3H024263; Sun, 11 Apr 2004 02:56:17 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3B9uHX9024262; Sun, 11 Apr 2004 02:56:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from av9-1-sn1.fre.skanova.net (av9-1-sn1.fre.skanova.net [81.228.11.115]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3B9uFwS024254 for <ietf-pkix@imc.org>; Sun, 11 Apr 2004 02:56:16 -0700 (PDT) (envelope-from anders.rundgren@telia.com) Received: by av9-1-sn1.fre.skanova.net (Postfix, from userid 502) id 4414A37E92; Sun, 11 Apr 2004 11:56:11 +0200 (CEST) Received: from smtp3-2-sn1.fre.skanova.net (smtp3-2-sn1.fre.skanova.net [81.228.11.164]) by av9-1-sn1.fre.skanova.net (Postfix) with ESMTP id 33ECA37E60; Sun, 11 Apr 2004 11:56:11 +0200 (CEST) Received: from arport (t10o913p41.telia.com [213.64.27.161]) by smtp3-2-sn1.fre.skanova.net (Postfix) with SMTP id 3BE1637E45; Sun, 11 Apr 2004 11:56:08 +0200 (CEST) Message-ID: <014b01c41faa$2cc9caa0$0500a8c0@arport> From: "Anders Rundgren" <anders.rundgren@telia.com> To: "PKIX list" <ietf-pkix@imc.org>, <Shaheen.Nasirudheen@chase.com> References: <OF5BA7C79A.7B5B42C5-ON85256E71.0064F031@chase.com> Subject: Re: Single Identity. Was: PKI International Consortium Date: Sun, 11 Apr 2004 11:48:41 +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 Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Shaheen, May I as a long-term PKIX-list subscriber share some experiences of what can be successfully discussed/RFCed etc and what does not seem to work too well? If we talk about FIs in an international consortium we are probably into commercial activities. If we assume (this is not a truth, just an assumption) that existing RFCs are suitable, the IETF does not form a good foundation for discussing commercial, deployment, or policy issues. If you compare such an activity with payment- networks like VISA, such discussions have been a fairly private issues for the VISA members. However, if the goal is a global TTP trust network, I don't believe that the VISA approach works, as identity is much more complex (as well as potentially considerably more far-reaching) than transferring money in a closed payment network. I would personally like to participate in a development of the kind you are mentioning, although I believe that the "in scope" issues are extremely hard as well as politically sensitive. Here is an non-exhaustive list of issues that have to be dealt with: 1. Who is the relying party? Some possible answers: FIs only. FIs + e-govs. "All", All but FIs(!). 2. Without having a standard card/container, is this really feasible? 3. Business model? Some possible answers: Four corner model. Subscriber-based cost model. Mixed model? 4. How to express FI identities? Some possible answers: Credit-card-like ID (ffffnnnnnnnnnnnn). National IDs. Other. multiple credentials (national + CC-like) Although very interesting and potentially very lucrative, my experiences so far with the financial industry, is that they don't want to work "in open" which IMO is a prerequisite for a global high-value TTP looking for a billions of customers. Nothing below that level is going to work as the "brand" will not be able to survive otherwise. best regards Anders ----- Original Message ----- From: <Shaheen.Nasirudheen@chase.com> To: "Anders Rundgren" <anders.rundgren@telia.com>; "Al Arsenault" <aarsenau@bbn.com>; <amg@lcc.uma.es>; "Arshad Noor" <arshad.noor@strongauth.com>; "Terwilliger, Ann" <aterwil@visa.com>; "Eric Norman" <ejnorman@doit.wisc.edu>; "PKIX list" <ietf-pkix@imc.org>; "Stephen Kent" <kent@bbn.com>; <owner-ietf-pkix@mail.imc.org> Sent: Friday, April 09, 2004 23:30 Subject: Re: Single Identity. Was: PKI International Consortium Hello everyone. Though new to this group, within a short span I understand there are people who favor single identity and who does not. I also understand that there is an effort towards standardizing or centralizing PKI among the Financial Institutions. One such effort is Identrus. Thanks to some of the members of this group who helped me with good information. However, moving forward, can I look forward for a single identity that I can use to identify myself to any public system that require identification and authentication? If there is an ongoing effort in this regard, please let me know so that I can participate. Regards, Shaheen Nasirudheen ----------------------------------- This message may contain legally privileged and/or confidential information. If you are not the intended recipient(s), or the employee or agent responsible for delivery of this message to the intended recipient(s), you are hereby notified that any dissemination, distribution or copying of this message is strictly prohibited. If you have received this message in error, please immediately notify the sender and delete this e-mail message from your computer. "Anders Rundgren" <anders.rundgren@t To: "Al Arsenault" <aarsenau@bbn.com>, "PKIX list" elia.com> <ietf-pkix@imc.org>, Shaheen Nasirudheen/JPMCHASE@JPMCHASE Sent by: cc: "Stephen Kent" <kent@bbn.com>, "Arshad Noor" owner-ietf-pkix@ma <arshad.noor@strongauth.com>, <amg@lcc.uma.es>, "Terwilliger, Ann" il.imc.org <aterwil@visa.com>, "Eric Norman" <ejnorman@doit.wisc.edu> Subject: Re: Single Identity. Was: PKI International Consortium 04/05/2004 09:01 AM AWA: Speaking from practical experience (having a physical wallet lifted in Prague a few years back), it was easier NOT having a single credential. Okay, the wallet with the cash, credit cards, US driver's license, pictures of the kids, medical insurance card, etc. is gone. But, NOT the passport, and not the emergency credit card kept separate from the rest for exactly this eventuality. Survival was assured until recovery could be accomplished. AR: In my opinion you are describing something like a "credential backup" scheme which is pretty unrelated to the single credential issue. Valid questions arise, like: Where do you keep the backups? Where would you keep your electronic IDs when on the road (where you need them)? It looks to me that the "always connected" world creates new problems requiring more robust and universal solutions. The globally supported trust network is my shot as this problem. AWA: Now, map this to the virtual world, where everything is stored in your mobile phone. Whoops - mobile phone is lost/stolen. So I go to the nearest branch of the "issuing agency". The conversation goes something like Me: "excuse me, my name is Al Arsenault, and my ID was stolen. I need a new one". Agency: "Prove that's who you are". Me: "How? My one single ID was stolen, I need a new one". Agency: "Yes, but if we believed you based on just what you're telling us, it could deny service to the REAL Al Arsenault, who our records show is out blithely spending money right now". (Somebody call John Cleese - there's a great Monty Python skit in here somewhere.) AR: This situation is indeed a tricky one. However, it gets more manageable when issuers have 24/7 helpdesks which allows the agency to look-up records and ask you to answer a few questions that only the original issuer and you have the answers to. Since agencies have to authenticate to access external records (or identify themselves to an issuer helpdesk), a screw-up may lead to the agency's loss of their license. AWA: Yes, there's likely a way to PROVE that I'm the real Al Arsenault, but I hope it doesn't involve biometrics - don't get me started down that road. :-( AR: Biometrics is of indeed a very vital part of such verifications. Today this may just be your picture but tomorrow it will be DNA. Since identity theft is admittedly the weak spot of the described scheme there are really no alternatives to biometrics except abandoning the whole thing. AFAIK the US immigration authorities require (or are about to require) an extensive set of biometrics in passports so either we foreigners have to stay at home or deal with it. AR: Regarding the value of single identities it is also a matter of cost. The majority of people work for small businesses and these may find that using the already existing bank-issued IDs will be easier to use than putting out user-IDs and passwords. The identity does not have to be an SSN, it may be your bank client number or some completely artificial number. That is, bank-IDs do not have to "emulate" passports to be useful. AR: Regarding multiple banks, I agree with you, you should not (mostly for commercial and political reasons) force a network of TTPs to be direct TTPs for each other. So here there will be a deviation from the single ID. However, you typically only need one "primary ID" for all your TTP-based ID-relations. best AR = Anders Rundgren Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3B8su1l009746; Sun, 11 Apr 2004 01:54:56 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3B8suvx009745; Sun, 11 Apr 2004 01:54:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from av3-2-sn1.fre.skanova.net (av3-2-sn1.fre.skanova.net [81.228.11.110]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3B8st6g009643 for <ietf-pkix@imc.org>; Sun, 11 Apr 2004 01:54:55 -0700 (PDT) (envelope-from anders.rundgren@telia.com) Received: by av3-2-sn1.fre.skanova.net (Postfix, from userid 502) id 7F61C37E90; Sun, 11 Apr 2004 10:54:44 +0200 (CEST) Received: from smtp3-2-sn1.fre.skanova.net (smtp3-2-sn1.fre.skanova.net [81.228.11.164]) by av3-2-sn1.fre.skanova.net (Postfix) with ESMTP id 6ECE237E48; Sun, 11 Apr 2004 10:54:44 +0200 (CEST) Received: from arport (t10o913p114.telia.com [213.64.27.234]) by smtp3-2-sn1.fre.skanova.net (Postfix) with SMTP id C0F0237E44; Sun, 11 Apr 2004 10:54:37 +0200 (CEST) Message-ID: <007b01c41fa1$97fe5600$0500a8c0@arport> From: "Anders Rundgren" <anders.rundgren@telia.com> To: "Arshad Noor" <arshad.noor@strongauth.com>, "Stephen Kent" <kent@bbn.com> Cc: "PKIX list" <ietf-pkix@imc.org> References: <428a370f.370f428a@noorhome.net> <p06020403bc97150f71da@[128.89.89.75]> <40724DEC.3060007@strongauth.com> <p06020404bc985cf94cad@[128.89.89.75]> <4073866D.4090507@strongauth.com> <p06020403bc99b5e1231c@[128.89.89.75]> <4074D666.3090002@strongauth.com> <p06020417bc9c9973795e@[128.89.89.75]> Subject: Re:Identity Firewall. l PKI International Consortium Date: Sun, 11 Apr 2004 10:47:10 +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 Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Arshad, >Steve Kent wrote: >I'll respond to just one of your examples, so show why I think this >is very unrealistic for most of the grouping you chose. >> 2) Education - for schools, colleges, professional associations; >there is no single source appropriate for all schools. elementary, >high school, undergraduate, graduate, professionlal associations. >each is potentially a valid issuer of a cert, just as each issues a >paper credential attesting to graduation, professional certification, >etc. thus, one would not acquire one cert associated with educational >institutions, but several. so, here, as in most of the examples you >cite, an individual would acquire several certs, not just one. Although I hardly ever agree with Steve, he is correct. I think the same is even more valid for industrial segments where it is likely to be impossible to raise money for running top CAs, cross-certify, or even creating a common certificate policy. What Steve did not mention, is that the authentication and authorization schemes that are firmly in place since three decades or so for bank-to-bank and supplier-to-manufacturer networks, together with recent developmemts like SAML and 3D Secure, will likely forever change how PKI is applied, which also will affect schemes like the Identity Firewall. >The reality is that there is generally very little motivation for an >organization to issue a credential that identifies a person, unless >the issuer plans the use the resulting credential for some form of >authorization, at least with regard to the issuer. TTP CAs are >typically in the business of issuing identity credentials that don't >match this model, but then I tend to think of them as anomalous >anyway ;-) Probably PKI deployment will follow two main directions, relying-party-only and general purpose TTPs. Which one will be dominating depends IMHO not on technical issues but on business models and costs. There are to my knowledge practically no limitations to what you can do with an identity credential using indirect auth* schemes. Indirect auth* schemes BTW offer huge cost, control, and scalability advantages over the schemes currently being deployed by many public sector PKI programs. Anders Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3ANZfsf092863; Sat, 10 Apr 2004 16:35:41 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3ANZftv092862; Sat, 10 Apr 2004 16:35:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mdhagsmtp01.firstdata.com (mdhagsmtp01.firstdata.com [198.184.5.21]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3ANZeVX092854 for <ietf-pkix@imc.org>; Sat, 10 Apr 2004 16:35:41 -0700 (PDT) (envelope-from lynn.wheeler@firstdata.com) Subject: privacy, authentication, identification , authorization To: "PKIX list" <ietf-pkix@imc.org> X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: <OF01D2D2F6.814085CC-ON87256E72.00817066@firstdata.com> From: lynn.wheeler@firstdata.com Date: Sat, 10 Apr 2004 17:34:40 -0600 X-MIMETrack: Serialize by Router on MDHAGSMTP/FDMS/FDC(Release 6.0.2CF2|July 23, 2003) at 04/10/2004 07:34:47 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> basically somebody provides some authentication information, in public/private key scenario ... a digital signature is generated by a private key as part of a "something you have" authentication paradigm. there could be some certification process where a hardware token is involved (certifies the operation of specific hardware token analogous to FIPS or common criteria, not as in a public key certificate issuing institition), the hardware token is certified as generating (on-chip) a key pair where the private key never leaves the chip. the hardware token could also be certified as generating specific kinds of digital signature when correct PIN or biometric is presented. with such a certificate infrastructure .... the relying party might then have grounds to believe that in addition to "something you have", there may bave been "something you know" and/or "something you are" authentication. This wouldn't be a shared-secret based operation .... but the relying-party could infer "something you know" and/or "something you are" if it trusted the certification process for the hardware token operation. the relying-party then obtains a public-key and validates the digital signature. the infrastructure for the public-key could be a database (conforming to most existing business processes for authentication material) or a certificate (in the PKI model). the infrastructure typically has bound the public-key to some identification, index, and/or authorization information. In the case of identification or index, that information is frequently then used to lookup some authorization information (i.e. specific identity is allowed to do specific stuff). A trivial example is a generic employee certificate ... all it contains is some generic employer information and the public key, if the digital signature authenticates ... then it is known that the person is some employee and is entitled to do whatever generic employees are entitled to do. the issue here is that there aren't a lot of business processes that perform identification (or authentication) just for the sake of it (having absolutely no other purpose) .... the business process is performing the operation as part of some additional activity. For instance, there aren't a lot of identification stores in malls, where you walk in authenticate/identify ... and then walk out (with no other operation occuring). The early x.509 identity certificates tended to contain a lot of arbitrary information that ran afoul of various pricacy issues. The result was retrenching to relying-party-only certificates that contain an indication or domain-specific index ... which was then used to index a database entry that then provided the actual information needed for executing a business process. Putting in generic identity information or possibly institutional specific identity and/or authorization information (like clearance levels) in a public certificate (targeted for uncontrolled distribution) tends to violate various privacy and/or institutional rules/policies. just because some item of information is encapsulated in a public certificate doesn't magically mitigate all rules and policies regarding the handling of that information -- Anne & Lynn Wheeler - http://www.garlic.com/~lynn/ Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3AMNYBr086179; Sat, 10 Apr 2004 15:23:34 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3AMNYu4086178; Sat, 10 Apr 2004 15:23:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3AMNXti086172 for <ietf-pkix@imc.org>; Sat, 10 Apr 2004 15:23:33 -0700 (PDT) (envelope-from mmyers@fastq.com) Received: from MMyersLapTop ([65.39.77.135]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id i3AMNbw95879; Sat, 10 Apr 2004 15:23:37 -0700 (MST) (envelope-from mmyers@fastq.com) From: "Michael Myers" <mmyers@fastq.com> To: "David Engberg" <dengberg@corestreet.com> Cc: <ietf-pkix@imc.org> Subject: RE: Signing Untrusted SCVP? Date: Sat, 10 Apr 2004 15:24:18 -0700 Message-ID: <EOEGJNFMMIBDKGFONJJDAEOFDMAA.mmyers@fastq.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <40786773.10700@corestreet.com> Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> My opinion is that as long as DPD-only servers are capable of signing responses, I don't see a problem with such servers not shipping with active key material. They may not be operationally capable nor deployed so but would be functionally capable of compliance. The distinction is that a local security administrator is able to activate DPD signing in response to emerging threats without recourse to a vendor's software update. Mike -----Original Message----- From: David Engberg [mailto:dengberg@corestreet.com] Sent: Saturday, April 10, 2004 2:30 PM To: Michael Myers Cc: ietf-pkix@imc.org Subject: Re: Signing Untrusted SCVP? I could live with this (and so could my company), but my personal preference would be language changes which would also permit a customer to deploy SCVP servers which are only used for DPD and have no keys at all. These servers would not be "capable of" signing responses, and no one would ever ask them to (or they would get an unsigned error if they did). This would be the same as current PKIs that distributed certs and CRLs through LDAP directories that do not even have SSL keys. I know there are dozens of options for implementing insecure software keys at every server, but by removing the keys entirely you avoid giving the incorrect impression that the servers should ever be "trusted" in the sense of DPV. No client should be misconfigured to accept the signature of those servers as a replacement for its own local PKI validation. Michael Myers wrote: > > Does anyone else agree or object? > > Mike > > -----Original Message----- > From: Santosh Chokhani > Sent: Thursday, April 08, 2004 4:40 AM > > I agree > > -----Original Message----- > From: Michael Myers > Sent: Wednesday, April 07, 2004 4:14 PM > > I think we should just change the relevant MUSTs to "MUST be > capable of". > > Mike > > > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3ALSmpU082875; Sat, 10 Apr 2004 14:28:48 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3ALSmfo082874; Sat, 10 Apr 2004 14:28:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3ALSlfT082854 for <ietf-pkix@imc.org>; Sat, 10 Apr 2004 14:28:47 -0700 (PDT) (envelope-from dengberg@corestreet.com) Received: from localhost (h005008001124.ne.client2.attbi.com[66.31.43.88]) by comcast.net (rwcrmhc12) with ESMTP id <20040410212847014009g6lfe>; Sat, 10 Apr 2004 21:28:47 +0000 Received: from localhost ([127.0.0.1] helo=corestreet.com ident=dave) by localhost with esmtp (Exim 3.35 #1 (Debian)) id 1BCQ3Y-0001LX-00; Sat, 10 Apr 2004 17:30:28 -0400 Message-ID: <40786773.10700@corestreet.com> Date: Sat, 10 Apr 2004 17:30:27 -0400 From: David Engberg <dengberg@corestreet.com> Organization: CoreStreet User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Myers <mmyers@fastq.com> CC: ietf-pkix@imc.org Subject: Re: Signing Untrusted SCVP? References: <EOEGJNFMMIBDKGFONJJDAEOADMAA.mmyers@fastq.com> In-Reply-To: <EOEGJNFMMIBDKGFONJJDAEOADMAA.mmyers@fastq.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> I could live with this (and so could my company), but my personal preference would be language changes which would also permit a customer to deploy SCVP servers which are only used for DPD and have no keys at all. These servers would not be "capable of" signing responses, and no one would ever ask them to (or they would get an unsigned error if they did). This would be the same as current PKIs that distributed certs and CRLs through LDAP directories that do not even have SSL keys. I know there are dozens of options for implementing insecure software keys at every server, but by removing the keys entirely you avoid giving the incorrect impression that the servers should ever be "trusted" in the sense of DPV. No client should be misconfigured to accept the signature of those servers as a replacement for its own local PKI validation. Michael Myers wrote: > > Does anyone else agree or object? > > Mike > > -----Original Message----- > From: Santosh Chokhani > Sent: Thursday, April 08, 2004 4:40 AM > > I agree > > -----Original Message----- > From: Michael Myers > Sent: Wednesday, April 07, 2004 4:14 PM > > I think we should just change the relevant MUSTs to "MUST be > capable of". > > Mike > > > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3AF2Xj1040472; Sat, 10 Apr 2004 08:02:33 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3AF2Xkk040471; Sat, 10 Apr 2004 08:02:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp.cs.auckland.ac.nz (smtp.cs.auckland.ac.nz [130.216.33.151]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3AF2Sg2040448 for <ietf-pkix@imc.org>; Sat, 10 Apr 2004 08:02:30 -0700 (PDT) (envelope-from pgut001@cs.auckland.ac.nz) Received: from medusa01 (medusa01.cs.auckland.ac.nz [130.216.34.33]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id A60EC3402B; Sun, 11 Apr 2004 03:00:22 +1200 (NZST) Received: from pgut001 by medusa01 with local (Exim 4.30) id 1BCK08-0008Vj-Tp; Sun, 11 Apr 2004 03:02:32 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: brian@holmespun.biz, ietf-pkix@imc.org Subject: Re: Decoding Service Support In-Reply-To: <4075B024.6050002@holmespun.biz> Message-Id: <E1BCK08-0008Vj-Tp@medusa01> Date: Sun, 11 Apr 2004 03:02:32 +1200 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> "Brian G. Holmes" <brian@holmespun.biz> writes: >I support a free BER for ASN.1 decoding service known as the Berasno Decoding >Service. How is this different from something like dumpasn1? Peter. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3ABssCx017837; Sat, 10 Apr 2004 04:54:54 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3ABssHD017836; Sat, 10 Apr 2004 04:54:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp.cs.auckland.ac.nz (smtp.cs.auckland.ac.nz [130.216.33.151]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3ABsrXF017820 for <ietf-pkix@imc.org>; Sat, 10 Apr 2004 04:54:53 -0700 (PDT) (envelope-from pgut001@cs.auckland.ac.nz) Received: from medusa01 (medusa01.cs.auckland.ac.nz [130.216.34.33]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id 46C333408E; Sat, 10 Apr 2004 23:52:49 +1200 (NZST) Received: from pgut001 by medusa01 with local (Exim 4.30) id 1BCH4b-0008MF-M0; Sat, 10 Apr 2004 23:54:57 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-pkix@imc.org, jmdesp@free.fr Subject: Re: R: RFC3280: doubt on the use of UTF8String in encoding RDNs In-Reply-To: <407698C2.6080907@free.fr> Message-Id: <E1BCH4b-0008MF-M0@medusa01> Date: Sat, 10 Apr 2004 23:54:57 +1200 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Jean-Marc Desperrier <jmdesp@free.fr> writes: >But I'm positive clients *never* check if the response cert is coherent with >the name in the request they sent Some do. I know of client apps that reject the cert if the cert DN doesn't match the request DN (by "match" I mean if memcmp() reports that they differ). Peter. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3ABXhpH014892; Sat, 10 Apr 2004 04:33:43 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3ABXhju014891; Sat, 10 Apr 2004 04:33:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp.cs.auckland.ac.nz (smtp.cs.auckland.ac.nz [130.216.33.151]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3ABXXOU014863 for <ietf-pkix@imc.org>; Sat, 10 Apr 2004 04:33:38 -0700 (PDT) (envelope-from pgut001@cs.auckland.ac.nz) Received: from medusa01 (medusa01.cs.auckland.ac.nz [130.216.34.33]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id EFE5234129; Sat, 10 Apr 2004 23:31:24 +1200 (NZST) Received: from pgut001 by medusa01 with local (Exim 4.30) id 1BCGjt-0008LT-57; Sat, 10 Apr 2004 23:33:33 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: adriano.santoni@actalis.it, pgut001@cs.auckland.ac.nz Subject: Re: R: RFC3280: doubt on the use of UTF8String in encoding RDNs Cc: ietf-pkix@imc.org In-Reply-To: <BE82E060F5EA2D44A4CFCFFA8363958803B4BA71@ntexch00.office.sia.it> Message-Id: <E1BCGjt-0008LT-57@medusa01> Date: Sat, 10 Apr 2004 23:33:33 +1200 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Santoni Adriano <adriano.santoni@actalis.it> writes: >As a CA, we do not handle DNs "encoded by the originator"; which "originator" >at any rate? > >We register people, collecting their own true names, and then we build the >DNs to be inserted into certificates. In that case you're the originator, so you can encode them in whatever way you want, and other apps will preserve the encoding. So encoding as UTF-8 should be fine, although some apps (particularly older ones) may not be able to display it very well, and old (4.x) versions of Netscape will crash when they encounter it. You can probably ignore that though, although there are some CAs that still use 4.x-compatibility as an excuse for doing weird things with certs. Peter. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3A6TP7J030468; Fri, 9 Apr 2004 23:29:25 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3A6TPiq030467; Fri, 9 Apr 2004 23:29:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from igw (adsl-63-194-79-229.dsl.snfc21.pacbell.net [63.194.79.229]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3A6TOJ9030428 for <ietf-pkix@imc.org>; Fri, 9 Apr 2004 23:29:24 -0700 (PDT) (envelope-from arshad.noor@strongauth.com) Received: from strongauth.com (athena.noorhome.net [192.168.0.10]) by igw.noorhome.net (iPlanet Messaging Server 5.2 Patch 1 (built Aug 19 2002)) with ESMTP id <0HVX00MB3YL9I4@igw.noorhome.net> for ietf-pkix@imc.org; Fri, 09 Apr 2004 23:12:45 -0700 (PDT) Date: Fri, 09 Apr 2004 23:27:12 -0700 From: Arshad Noor <arshad.noor@strongauth.com> Subject: Re: Identity Firewalls - Was: PKI International Consortium In-reply-to: <p06020417bc9c9973795e@[128.89.89.75]> To: Stephen Kent <kent@bbn.com> Cc: PKIX list <ietf-pkix@imc.org> Message-id: <407793C0.30400@strongauth.com> Organization: StrongAuth, Inc. MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) References: <428a370f.370f428a@noorhome.net> <p06020403bc97150f71da@[128.89.89.75]> <40724DEC.3060007@strongauth.com> <p06020404bc985cf94cad@[128.89.89.75]> <4073866D.4090507@strongauth.com> <p06020403bc99b5e1231c@[128.89.89.75]> <4074D666.3090002@strongauth.com> <p06020417bc9c9973795e@[128.89.89.75]> Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> It is unrealistic only if we accept status quo, Steve. If we change the operating conditions - based on reason - then reality changes. I don't deny that it is an arduous task - but I do not accept that it is impossible. Please see other comments below. Arshad Noor StrongAuth, Inc. Stephen Kent wrote: > Arshad, > > I'll respond to just one of your examples, [t]o show why I think this is > very unrealistic for most of the grouping you chose. > >> 2) Education - for schools, colleges, professional associations; > > > there is no single source appropriate for all schools. elementary, high > school, undergraduate, graduate, professionlal associations. This is accurate. However, there are a number of associations that represent such institutions - NEA, ITEA, AACSB, AMA, ABA, IEEE, IETF, etc. - that could have an influence amongst their members after they were convinced of the benefits. Once convinced, a small working group of representatives - one for the Elementary school, one for the Middle school, for High School, Undergraduate, Graduate school and a Professional Association - could create the technical and business standards necessary (with some support from members of this august forum). Much like individuals participate in the creation of IETF standards (as in this forum), so will these associations through their representatives. Will it take time? Definitely. Will it please everybody? Definitely not. But will a standard come out of it? Almost certainly, if the working group is dedicated. each is > potentially a valid issuer of a cert, just as each issues a paper > credential attesting to graduation, professional certification, etc. > thus, one would not acquire one cert associated with educational > institutions, but several. so, here, as in most of the examples you > cite, an individual would acquire several certs, not just one. > I would not recommend the issuance of a cert to attest to one's graduation or professional certification. The business objective is that someone needs to verify that you truly graduated from some school. There are many simpler ways of accomplishing this: 1) A secured website that would provide the unique cert DN, the educational qualification and year of graduation to anyone that wanted to view it; alumni that would rather not have this information visible on the Internet could opt out of this type of service, and go with #2; 2) An asynchronous e-mail service that would send a signed e-mail to the RP, from the alma mater, providing the above information at the individual's request, AFTER having authenticated him by his Education credential and having duly determined his authorization to make such a request; 3) A synchronous web-service available to anyone that requested the information; those alumni that would rather not have this information sent out unless they authorized it, could opt out of this type of service, and stay with #2; I am sure there are many other ways that members of this forum could solve this business problem, in addition to the above. In this manner, you end up issuing a single credential to serve an individual's needs in the Education industry from KG to Ph.D. and still attest to RP's about the individuals' educational qualifications without issuing additional certs. (Similar response for the travel and financial industry examples you provided.) > A public key cert PKC) may attest to identity and be used as an input to > an ACL to determine authorization. Or, one may issue a PKC and include > authorization info. Or one may issue a PKC and issue one or more ACs to > provide authorization info. There is not one right way to achieve the > goal of authorization. However, in practice, essentially every identity > credential we issue that is of value, also happens to be an > authorization credential as well. A driver's license is an authorization > to drive a certain class of vehicle. An employee ID usually grants the > employee access to basic employ facilities, generic employee discounts, > etc. > I agree with you. Even in my own example to Anders yesterday, a Financial Industry credential without any accounts associated with it, still has the implicit authorization to open a new account, if desired, at supporting institutions. To some extent, every industry group will probably associate some base level of authorization to the industry-specific identity; BUT since it serves just that industry, they reap the benefits, or pay for the consequences of their good or short- sighted decisions, if any. > The reality is that there is generally very little motivation for an > organization to issue a credential that identifies a person, unless the > issuer plans the use the resulting credential for some form of > authorization, at least with regard to the issuer. If the issuer were a "super-association" for an industry, as opposed to a company within the industry or an association representing a segment of the industry, then there are huge cost savings to everyone in the industry - as well as the consumer they serve. That will be the motivation; and I hope to document this in my treatise. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3A4otZf091127; Fri, 9 Apr 2004 21:50:55 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3A4otXM091126; Fri, 9 Apr 2004 21:50:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from igw (adsl-63-194-79-229.dsl.snfc21.pacbell.net [63.194.79.229]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3A4otlg091119 for <ietf-pkix@imc.org>; Fri, 9 Apr 2004 21:50:55 -0700 (PDT) (envelope-from arshad.noor@strongauth.com) Received: from strongauth.com (athena.noorhome.net [192.168.0.10]) by igw.noorhome.net (iPlanet Messaging Server 5.2 Patch 1 (built Aug 19 2002)) with ESMTP id <0HVX00M9FU15I4@igw.noorhome.net> for ietf-pkix@imc.org; Fri, 09 Apr 2004 21:34:18 -0700 (PDT) Date: Fri, 09 Apr 2004 21:48:45 -0700 From: Arshad Noor <arshad.noor@strongauth.com> Subject: Re: PKI International Consortium In-reply-to: <4073A6E1.6F65D002@nma.com> To: Ed Gerck <egerck@nma.com> Cc: PKIX list <ietf-pkix@imc.org> Message-id: <40777CAD.8010104@strongauth.com> Organization: StrongAuth, Inc. MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) References: <428a370f.370f428a@noorhome.net> <p06020403bc97150f71da@[128.89.89.75]> <40724DEC.3060007@strongauth.com> <p06020404bc985cf94cad@[128.89.89.75]> <4073866D.4090507@strongauth.com> <4073A6E1.6F65D002@nma.com> Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Ed Gerck wrote: > > Empirical evidence supports the assertion > that we all have a growing number of credentials with time, > including all the expired ones. Yes, expired credentials are > useful. For example, as supporting evidence to issue a renewed > credential and/or as a credential with less privileges. > I have nothing against the number of expired credentials, Ed; just the number of active credentials. Expired certs are invisible to me, even if they're still lying around in my authentication token. Arshad Noor StrongAuth, Inc. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3A286SE076840; Fri, 9 Apr 2004 19:08:06 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3A286Nc076839; Fri, 9 Apr 2004 19:08:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mdhagsmtp01.firstdata.com (mdhagsmtp01.firstdata.com [198.184.5.21]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3A2862I076826 for <ietf-pkix@imc.org>; Fri, 9 Apr 2004 19:08:06 -0700 (PDT) (envelope-from lynn.wheeler@firstdata.com) Subject: Re: Single Identity. Was: PKI International Consortium To: Shaheen.Nasirudheen@chase.com Cc: "Al Arsenault" <aarsenau@bbn.com>, amg@lcc.uma.es, "Anders Rundgren" <anders.rundgren@telia.com>, "Arshad Noor" <arshad.noor@strongauth.com>, "Terwilliger, Ann" <aterwil@visa.com>, "Eric Norman" <ejnorman@doit.wisc.edu>, "PKIX list" <ietf-pkix@imc.org>, "Stephen Kent" <kent@bbn.com>, owner-ietf-pkix@mail.imc.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: <OFFC8D2611.603DF4CF-ON87256E72.00048700@firstdata.com> From: lynn.wheeler@firstdata.com Date: Fri, 9 Apr 2004 20:03:06 -0600 X-MIMETrack: Serialize by Router on MDHAGSMTP/FDMS/FDC(Release 6.0.2CF2|July 23, 2003) at 04/09/2004 10:07:14 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> note that the financial examples aren't really identification ... they really are authentication ... and that actually helps make it work. it is somewhat a fabrication to call it identification. if i my financial authentication device is lost/stolen/breaks/fails/etc, i can call up and AUTHENICATE myself as the owner of the account and get a new one. The various questions are all effectively some form of shared-secret ... that they hope the person on the street can remember. They ask things like transactions on previous statements ... but they also ask address, social security number, and mothers-maiden-name. For mothers-maiden-name ... they've never actually ID you ... they've effectively asked for a shared-secret that they hope you can remember/answer. Because of some issue about mothers-maiden-name might not be the best of secrets ... I know people that make up values to fill in that field .... you just have to make sure you remember that when the mothers-maiden-name tag shows up ... you remember what secret you actually filled in. The use of SSN is something of a schizophrenic problem ... it is dual-use both as a (mandatory) identification (by gov. requirements) and as a shared-secret (something you can answer for authentication). The problem with the mandatory identification aspect of SSN is that it becomes propogated to a large number of places, compromizing is use as a shared-secret authentication mechanism. the authentication taxonomy is * something you have * something you know * someting you are shared-secrets are part of "something you know". hardware tokens are example of "something you have". Digital signatures for authentication purposes tend to be of the "something you have" nature ... i.e. in theory you and only you have a copy of your private key. Note in this context ... whether or not certificates are part of the paradigm is orthogonal to the authentication paradigm. Financial cards have also been of the "something you have" paradigm. In the past, there has been great deal of effort in making it hard to counterfeit these cards .... majority of it based on assuming that the criminal generates the counterfeit cards completely from scratch. The current problem is one of skimming where all the information to make a duplicate card is copied (as opposed to having to start from scratch creating a counterfeit card). "something you have" authentication paradigm breaks down when the object is no longer unique. this can happen with private keys if wherever it is stored becomes compromized. It has also happened in the case of the EMV counterfeit "yes cards" .... i.e. effectively the same technology for skimming to make duplicate (counterfeit) magstripe cards is also used to make duplicate (counterfeit) EMV cards. the issue regarding the contents or nature of a certificate is totally orthogonal to the use of publib/private key system as a "something you have" authentication mechanism. The advantages that the mechanism has over existing shared-secret paradigms ... 1) resilent to insider attacks that copy the master secret database (there is no shared secret that they can get that allows them to impersonate you), 2) phishing attacks are slightly more complicated since you don't actually "remember" your private key. The downside of private keys in a file on your PC ... is that it is relatively suseptable to phishing and virus attacks ... if they can get you to click on something and give up your logon password ... they can get you to click on something and give up the (private key) file encryption key (transmitting the file at the same time). Placing the private key in a hardware token where effectively nobody can get it .... then requires change in tactics. They have to convince you to mail off the hardware token along with any PIN ... or get you to use the hardware token in transactions on their behalf. Again ... nothing in the uses of private key and/or hardware tokens for authentication is directly related to certificates. The certificates paradigm is part of a structure for validating the results of the authentication .... but is not part of the generation of the authentication or the authentication taxonomy. shaheen nasirudheen wrote: Hello everyone. Though new to this group, within a short span I understand there are people who favor single identity and who does not. I also understand that there is an effort towards standardizing or centralizing PKI among the Financial Institutions. One such effort is Identrus. Thanks to some of the members of this group who helped me with good information. However, moving forward, can I look forward for a single identity that I can use to identify myself to any public system that require identification and authentication? If there is an ongoing effort in this regard, please let me know so that I can participate. Regards, Shaheen Nasirudheen -- Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3A0fmua069694; Fri, 9 Apr 2004 17:41:48 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3A0fmpE069693; Fri, 9 Apr 2004 17:41:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3A0flnk069687 for <ietf-pkix@imc.org>; Fri, 9 Apr 2004 17:41:47 -0700 (PDT) (envelope-from mmyers@fastq.com) Received: from MMyersLapTop ([65.39.77.135]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id i3A0frw73689 for <ietf-pkix@imc.org>; Fri, 9 Apr 2004 17:41:53 -0700 (MST) (envelope-from mmyers@fastq.com) From: "Michael Myers" <mmyers@fastq.com> To: <ietf-pkix@imc.org> Subject: RE: Signing Untrusted SCVP? Date: Fri, 9 Apr 2004 17:42:33 -0700 Message-ID: <EOEGJNFMMIBDKGFONJJDAEOADMAA.mmyers@fastq.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <006001c41d5e$28572e70$9a00a8c0@hq.orionsec.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Does anyone else agree or object? Mike -----Original Message----- From: Santosh Chokhani Sent: Thursday, April 08, 2004 4:40 AM I agree -----Original Message----- From: Michael Myers Sent: Wednesday, April 07, 2004 4:14 PM I think we should just change the relevant MUSTs to "MUST be capable of". Mike Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i39LVkW5048619; Fri, 9 Apr 2004 14:31:46 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i39LVkOV048618; Fri, 9 Apr 2004 14:31:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from emampe14.jpmchase.com (mailms.chase.com [170.148.48.205]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i39LVhhd048597; Fri, 9 Apr 2004 14:31:43 -0700 (PDT) (envelope-from Shaheen.Nasirudheen@chase.com) Received: J.P. Morgan Chase & Co.; Fri, 9 Apr 2004 17:31:21 -0400 (EDT); Message Subject: Re: Single Identity. Was: PKI International Consortium To: "Anders Rundgren" <anders.rundgren@telia.com>, "Al Arsenault" <aarsenau@bbn.com>, amg@lcc.uma.es, "Arshad Noor" <arshad.noor@strongauth.com>, "Terwilliger, Ann" <aterwil@visa.com>, "Eric Norman" <ejnorman@doit.wisc.edu>, "PKIX list" <ietf-pkix@imc.org>, "Stephen Kent" <kent@bbn.com>, owner-ietf-pkix@mail.imc.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: <OF5BA7C79A.7B5B42C5-ON85256E71.0064F031@chase.com> From: Shaheen.Nasirudheen@chase.com Date: Fri, 9 Apr 2004 17:30:36 -0400 X-MIMETrack: Serialize by Router on EMAMPE12/CHASE(Release 5.0.8 |June 18, 2001) at 04/09/2004 05:26:50 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Hello everyone. Though new to this group, within a short span I understand there are people who favor single identity and who does not. I also understand that there is an effort towards standardizing or centralizing PKI among the Financial Institutions. One such effort is Identrus. Thanks to some of the members of this group who helped me with good information. However, moving forward, can I look forward for a single identity that I can use to identify myself to any public system that require identification and authentication? If there is an ongoing effort in this regard, please let me know so that I can participate. Regards, Shaheen Nasirudheen ----------------------------------- This message may contain legally privileged and/or confidential information. If you are not the intended recipient(s), or the employee or agent responsible for delivery of this message to the intended recipient(s), you are hereby notified that any dissemination, distribution or copying of this message is strictly prohibited. If you have received this message in error, please immediately notify the sender and delete this e-mail message from your computer. "Anders Rundgren" <anders.rundgren@t To: "Al Arsenault" <aarsenau@bbn.com>, "PKIX list" elia.com> <ietf-pkix@imc.org>, Shaheen Nasirudheen/JPMCHASE@JPMCHASE Sent by: cc: "Stephen Kent" <kent@bbn.com>, "Arshad Noor" owner-ietf-pkix@ma <arshad.noor@strongauth.com>, <amg@lcc.uma.es>, "Terwilliger, Ann" il.imc.org <aterwil@visa.com>, "Eric Norman" <ejnorman@doit.wisc.edu> Subject: Re: Single Identity. Was: PKI International Consortium 04/05/2004 09:01 AM AWA: Speaking from practical experience (having a physical wallet lifted in Prague a few years back), it was easier NOT having a single credential. Okay, the wallet with the cash, credit cards, US driver's license, pictures of the kids, medical insurance card, etc. is gone. But, NOT the passport, and not the emergency credit card kept separate from the rest for exactly this eventuality. Survival was assured until recovery could be accomplished. AR: In my opinion you are describing something like a "credential backup" scheme which is pretty unrelated to the single credential issue. Valid questions arise, like: Where do you keep the backups? Where would you keep your electronic IDs when on the road (where you need them)? It looks to me that the "always connected" world creates new problems requiring more robust and universal solutions. The globally supported trust network is my shot as this problem. AWA: Now, map this to the virtual world, where everything is stored in your mobile phone. Whoops - mobile phone is lost/stolen. So I go to the nearest branch of the "issuing agency". The conversation goes something like Me: "excuse me, my name is Al Arsenault, and my ID was stolen. I need a new one". Agency: "Prove that's who you are". Me: "How? My one single ID was stolen, I need a new one". Agency: "Yes, but if we believed you based on just what you're telling us, it could deny service to the REAL Al Arsenault, who our records show is out blithely spending money right now". (Somebody call John Cleese - there's a great Monty Python skit in here somewhere.) AR: This situation is indeed a tricky one. However, it gets more manageable when issuers have 24/7 helpdesks which allows the agency to look-up records and ask you to answer a few questions that only the original issuer and you have the answers to. Since agencies have to authenticate to access external records (or identify themselves to an issuer helpdesk), a screw-up may lead to the agency's loss of their license. AWA: Yes, there's likely a way to PROVE that I'm the real Al Arsenault, but I hope it doesn't involve biometrics - don't get me started down that road. :-( AR: Biometrics is of indeed a very vital part of such verifications. Today this may just be your picture but tomorrow it will be DNA. Since identity theft is admittedly the weak spot of the described scheme there are really no alternatives to biometrics except abandoning the whole thing. AFAIK the US immigration authorities require (or are about to require) an extensive set of biometrics in passports so either we foreigners have to stay at home or deal with it. AR: Regarding the value of single identities it is also a matter of cost. The majority of people work for small businesses and these may find that using the already existing bank-issued IDs will be easier to use than putting out user-IDs and passwords. The identity does not have to be an SSN, it may be your bank client number or some completely artificial number. That is, bank-IDs do not have to "emulate" passports to be useful. AR: Regarding multiple banks, I agree with you, you should not (mostly for commercial and political reasons) force a network of TTPs to be direct TTPs for each other. So here there will be a deviation from the single ID. However, you typically only need one "primary ID" for all your TTP-based ID-relations. best AR = Anders Rundgren Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i39K3Hti038848; Fri, 9 Apr 2004 13:03:17 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i39K3HkF038847; Fri, 9 Apr 2004 13:03:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i39K3Gfo038825 for <ietf-pkix@imc.org>; Fri, 9 Apr 2004 13:03:16 -0700 (PDT) (envelope-from kent@bbn.com) Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i39K2h7X014011; Fri, 9 Apr 2004 16:02:43 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: <p06020419bc9ca00e05ce@[128.89.89.75]> In-Reply-To: <008101c41e57$4a3d5ce0$010aff0a@gw> References: <40620A08.20BBD37E@sun.com> <4076BE45.7080803@bull.net> <008101c41e57$4a3d5ce0$010aff0a@gw> Date: Fri, 9 Apr 2004 14:48:03 -0400 To: "todd glassey" <todd.glassey@worldnet.att.net> From: Stephen Kent <kent@bbn.com> Subject: Re: Successor to RFC 3280? Cc: "Denis Pinkas" <Denis.Pinkas@bull.net>, "PKIX List" <ietf-pkix@imc.org> Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> At 10:22 AM -0700 4/9/04, todd glassey wrote: >----- Original Message ----- >From: "Denis Pinkas" <Denis.Pinkas@bull.net> >To: "Steve Hanna" <Steve.Hanna@Sun.COM> >Cc: "PKIX List" <ietf-pkix@imc.org> >Sent: Friday, April 09, 2004 8:16 AM >Subject: Re: Successor to RFC 3280? > > >> >> Steve, >> >> This is an additional change proposal to the successor to RFC 3280. >> We are currently deprecating the use of the private key usage period. >> >> 4.2.1.4 Private Key Usage Period >> >> This extension SHOULD NOT be used within the Internet PKI. CAs >> conforming to this profile MUST NOT generate certificates that >> include a critical private key usage period extension. > >yes I agree - and IMHO this use of time as part of the keying validation >model clearly violates the Glassey-McNeil Patent's use claims. Todd, you were warned by Russ to not bring this issue up on PKIX anymore. One more time and I'll have to ask Paul Hoffman to revoke your posting privileges. Steve Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i39IkaQq029788; Fri, 9 Apr 2004 11:46:36 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i39Ikadd029787; Fri, 9 Apr 2004 11:46:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i39IkaJf029765 for <ietf-pkix@imc.org>; Fri, 9 Apr 2004 11:46:36 -0700 (PDT) (envelope-from kent@bbn.com) Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i39IkV7b010303; Fri, 9 Apr 2004 14:46:34 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: <p06020417bc9c9973795e@[128.89.89.75]> In-Reply-To: <4074D666.3090002@strongauth.com> References: <428a370f.370f428a@noorhome.net> <p06020403bc97150f71da@[128.89.89.75]> <40724DEC.3060007@strongauth.com> <p06020404bc985cf94cad@[128.89.89.75]> <4073866D.4090507@strongauth.com> <p06020403bc99b5e1231c@[128.89.89.75]> <4074D666.3090002@strongauth.com> Date: Fri, 9 Apr 2004 14:45:46 -0400 To: Arshad Noor <arshad.noor@strongauth.com> From: Stephen Kent <kent@bbn.com> Subject: Re: PKI International Consortium Cc: PKIX list <ietf-pkix@imc.org> Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Arshad, I'll respond to just one of your examples, so show why I think this is very unrealistic for most of the grouping you chose. > 2) Education - for schools, colleges, professional associations; there is no single source appropriate for all schools. elementary, high school, undergraduate, graduate, professionlal associations. each is potentially a valid issuer of a cert, just as each issues a paper credential attesting to graduation, professional certification, etc. thus, one would not acquire one cert associated with educational institutions, but several. so, here, as in most of the examples you cite, an individual would acquire several certs, not just one. certainly any frequent traveller already knows how many distinct credentials he/she acquires. these are separate and each identifies you by an account number that is managed by the issuer, not by any travel-industry wide oversight organization. in the financial sector, we also have separate credentials, each issued by a separate institution. there is no single organization that has oversight responsibility for all of these institutions, and smart people like to maintain separation to insulate themselves against bad behavior at any one of these institutions. > <SNIP> >> >>I too am in favor of the use of certs with private keys maintained >>in hardware tokens and a high assurance issuing process, when the >>resources being accessed warrant such measures. But, "optimal" is >>an inappropriate term when we have such a wide range of resources >>that people access. >> > Therein lies the fallacy of PKI - or any other authentication > technology - today: implied authorization to use of resources > based on the authentication credential! > > To me, the use of certs with private keys in hardware tokens and > a high assurance process is good enough only to IDENTIFY the > presenter of the credential. I will still want to go through > whatever number of business rules I choose, to determine whether > the identified entity has the authorization to use the resource. A public key cert PKC) may attest to identity and be used as an input to an ACL to determine authorization. Or, one may issue a PKC and include authorization info. Or one may issue a PKC and issue one or more ACs to provide authorization info. There is not one right way to achieve the goal of authorization. However, in practice, essentially every identity credential we issue that is of value, also happens to be an authorization credential as well. A driver's license is an authorization to drive a certain class of vehicle. An employee ID usually grants the employee access to basic employ facilities, generic employee discounts, etc. The reality is that there is generally very little motivation for an organization to issue a credential that identifies a person, unless the issuer plans the use the resulting credential for some form of authorization, at least with regard to the issuer. TTP CAs are typically in the business of issuing identity credentials that don't match this model, but then I tend to think of them as anomalous anyway ;-) Steve Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i39IkXKT029772; Fri, 9 Apr 2004 11:46:33 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i39IkXXv029771; Fri, 9 Apr 2004 11:46:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i39IkWh1029761 for <ietf-pkix@imc.org>; Fri, 9 Apr 2004 11:46:32 -0700 (PDT) (envelope-from kent@bbn.com) Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i39IkV7X010303; Fri, 9 Apr 2004 14:46:31 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: <p06020415bc9c8e8beb25@[128.89.89.75]> In-Reply-To: <0C3042E92D8A714783E2C44AB9936E1DE34701@EUR-MSG-03.europe.corp.microsoft.c om> References: <0C3042E92D8A714783E2C44AB9936E1DE34701@EUR-MSG-03.europe.corp.microsoft.c om> Date: Fri, 9 Apr 2004 13:33:59 -0400 To: "Stefan Santesson" <stefans@microsoft.com> From: Stephen Kent <kent@bbn.com> Subject: Re: SMIME Capabilities in X.509 certificates. Cc: <ietf-pkix@imc.org> Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Stefan, There have been no responses on the list to your proposal. I think it would help to give examples of what sorts of info you envision in the extension, starting with what MS has put in certs under using this extension. Also note that this might be the topic of a separate RFC, or part of a 3280 update, but not a new work item unless the cognizant AD agrees. Steve Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i39HW67q021955; Fri, 9 Apr 2004 10:32:06 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i39HW6rA021954; Fri, 9 Apr 2004 10:32:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i39HW3oS021932 for <ietf-pkix@imc.org>; Fri, 9 Apr 2004 10:32:05 -0700 (PDT) (envelope-from kent@bbn.com) Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i39HVU7X006465; Fri, 9 Apr 2004 13:31:30 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: <p06020411bc9c8ca779a3@[128.89.89.75]> In-Reply-To: <4076BE45.7080803@bull.net> References: <40620A08.20BBD37E@sun.com> <4076BE45.7080803@bull.net> Date: Fri, 9 Apr 2004 13:24:44 -0400 To: Denis Pinkas <Denis.Pinkas@bull.net> From: Stephen Kent <kent@bbn.com> Subject: Re: Successor to RFC 3280? Cc: Steve Hanna <Steve.Hanna@Sun.COM>, PKIX List <ietf-pkix@imc.org> Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Denis, Good point. It might make sense to say that this extension is reasonable under such circumstances. Steve Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i39HNX6A021123; Fri, 9 Apr 2004 10:23:33 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i39HNX19021122; Fri, 9 Apr 2004 10:23:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mtiwmhc11.worldnet.att.net (mtiwmhc11.worldnet.att.net [204.127.131.115]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i39HNWv9021105 for <ietf-pkix@imc.org>; Fri, 9 Apr 2004 10:23:32 -0700 (PDT) (envelope-from todd.glassey@worldnet.att.net) Received: from gw (184.san-jose-04-05rs.ca.dial-access.att.net[12.72.193.184]) by worldnet.att.net (mtiwmhc11) with SMTP id <20040409172329111006h3m6e>; Fri, 9 Apr 2004 17:23:30 +0000 Message-ID: <008101c41e57$4a3d5ce0$010aff0a@gw> From: "todd glassey" <todd.glassey@worldnet.att.net> To: "Denis Pinkas" <Denis.Pinkas@bull.net> Cc: "PKIX List" <ietf-pkix@imc.org> References: <40620A08.20BBD37E@sun.com> <4076BE45.7080803@bull.net> Subject: Re: Successor to RFC 3280? Date: Fri, 9 Apr 2004 10:22:49 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> ----- Original Message ----- From: "Denis Pinkas" <Denis.Pinkas@bull.net> To: "Steve Hanna" <Steve.Hanna@Sun.COM> Cc: "PKIX List" <ietf-pkix@imc.org> Sent: Friday, April 09, 2004 8:16 AM Subject: Re: Successor to RFC 3280? > > Steve, > > This is an additional change proposal to the successor to RFC 3280. > We are currently deprecating the use of the private key usage period. > > 4.2.1.4 Private Key Usage Period > > This extension SHOULD NOT be used within the Internet PKI. CAs > conforming to this profile MUST NOT generate certificates that > include a critical private key usage period extension. yes I agree - and IMHO this use of time as part of the keying validation model clearly violates the Glassey-McNeil Patent's use claims. > > I have been advocating this in the past, while being (too much) focussed on > keys for human beings: it is not possible to prevent a human being to use > his private key beyond that date. > > However, if this key is placed within a(n evaluated) security module that > has a secure clock, it possible to make sure that the security module > prevents the use of the private key beyond the expiration date (e.g. the key > can be zeroized). This is fully pertinent for time-stamping modules which > must have a clock synchronised with UTC. No Denis it is not. It is possible to say that "this use conforms to this recommendation" but there in fact is no way with today's technologies to stop anyone from doing anything that they want to with SW systems. So... the issues for time stamping systems that must be synchronized with UTC services are just a recommendation and we wont talk about this use's violation (in my opinion) of my patent rights in the Datum Controlling Access to Stored Information Patent. > > Thus I would propose to allow and even recommend the use of this extension > for keys located in security modules that have a secure clock, in particular > time-stamping modules, where it is possible to enforce this control. > > Denis > > > I have heard some folks say that we should have > > a successor to RFC 3280 (and 3279) and some folks > > say that we shouldn't. I'd like to raise this topic > > for discussion on the PKIX list to settle this matter. > > > > I believe that an update to RFC 3280 is necessary > > for two reasons. First, some minor problems have > > been found during implementation and deployment > > (mostly typos and clarifications). These should > > be fixed so that future implementors don't have > > to suffer through them. Second, we are almost ready > > for RFC 3280 to progress to Draft Standard status. > > In order to do this, it must be revised. So I > > believe that an update to RFC 3280 (and 3279) > > should be undertaken. > > > > HOWEVER, I think it is essential for us to limit > > the scope of this update. We should not add features > > to the spec or make substantial changes, especially > > changes that would break compatibility with RFC 3280. > > The scope of the update should be limited to > > "clarifying and correcting the document in light > > of implementation experience". > > > > That's my perspective on this important matter. > > I would like to hear other perspectives and > > opinions so that we can arrive at a rough working > > group consensus on this. > > > > Thanks, > > > > Steve > > > > P.S. I have a list of typos and clarifications > > that need to be fixed in the next version of > > RFC 3280. If we decide to proceed with a revision, > > I'll forward it to the editor and cc the PKIX list. > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i39Gk41p016706; Fri, 9 Apr 2004 09:46:04 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i39Gk4ro016705; Fri, 9 Apr 2004 09:46:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mtiwmhc13.worldnet.att.net (mtiwmhc13.worldnet.att.net [204.127.131.117]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i39Gk3qb016686 for <ietf-pkix@imc.org>; Fri, 9 Apr 2004 09:46:03 -0700 (PDT) (envelope-from todd.glassey@worldnet.att.net) Received: from gw (184.san-jose-04-05rs.ca.dial-access.att.net[12.72.193.184]) by worldnet.att.net (mtiwmhc13) with SMTP id <2004040916455911300bv4c5e>; Fri, 9 Apr 2004 16:46:00 +0000 Message-ID: <003d01c41e52$0d809a60$010aff0a@gw> From: "todd glassey" <todd.glassey@worldnet.att.net> To: <lynn.wheeler@firstdata.com> Cc: "Al Arsenault" <aarsenau@bbn.com>, "Eric Norman" <ejnorman@doit.wisc.edu>, "PKIX list" <ietf-pkix@imc.org>, <owner-ietf-pkix@mail.imc.org> References: <OFFFFEF09C.EBF46225-ON87256E71.005B1E3E@firstdata.com> Subject: Re: Identity (was PKI International Consortium) Date: Fri, 9 Apr 2004 09:45:13 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Here again Lynn we as technologists are telling the world what it needs rather than looking at its existing processes, and figuring out how they would work in a paperless model. But I do hear what you are saying and I do realize the overhead of having a HGN fingerprint installed into a token and BTW - I am in the process of filing a patent for a PKI adaptation for signing the chromosomal matrix so that it generates a set of hashes and simple signatures. This in fact is a DNS Signature. Filing should be done by next week... Todd Glassey ----- Original Message ----- From: <lynn.wheeler@firstdata.com> To: "todd glassey" <todd.glassey@worldnet.att.net> Cc: "Al Arsenault" <aarsenau@bbn.com>; "Eric Norman" <ejnorman@doit.wisc.edu>; "PKIX list" <ietf-pkix@imc.org>; <owner-ietf-pkix@mail.imc.org> Sent: Friday, April 09, 2004 9:40 AM Subject: Re: Identity (was PKI International Consortium) > > > > > the down side is that DNA is one of those PIIs ... with high assurance > requirements. > > private key values would likely be placed in a public certificates ... long > before DNA information > > todd glassey wrote: > > DNA is reasonably constant > > -- > Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i39GfikA016287; Fri, 9 Apr 2004 09:41:45 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i39Gfiww016284; Fri, 9 Apr 2004 09:41:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mdhagsmtp01.firstdata.com (mdhagsmtp01.firstdata.com [198.184.5.21]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i39Gfhlr016254 for <ietf-pkix@imc.org>; Fri, 9 Apr 2004 09:41:43 -0700 (PDT) (envelope-from lynn.wheeler@firstdata.com) Subject: Re: Identity (was PKI International Consortium) To: "todd glassey" <todd.glassey@worldnet.att.net> Cc: "Al Arsenault" <aarsenau@bbn.com>, "Eric Norman" <ejnorman@doit.wisc.edu>, "PKIX list" <ietf-pkix@imc.org>, owner-ietf-pkix@mail.imc.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: <OFFFFEF09C.EBF46225-ON87256E71.005B1E3E@firstdata.com> From: lynn.wheeler@firstdata.com Date: Fri, 9 Apr 2004 10:40:42 -0600 X-MIMETrack: Serialize by Router on MDHAGSMTP/FDMS/FDC(Release 6.0.2CF2|July 23, 2003) at 04/09/2004 12:40:48 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> the down side is that DNA is one of those PIIs ... with high assurance requirements. private key values would likely be placed in a public certificates ... long before DNA information todd glassey wrote: DNA is reasonably constant -- Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i39FGXYi003785; Fri, 9 Apr 2004 08:16:33 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i39FGXgx003784; Fri, 9 Apr 2004 08:16:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i39FGVIM003761 for <ietf-pkix@imc.org>; Fri, 9 Apr 2004 08:16:32 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net) Received: from clbull.frcl.bull.fr (IDENT:root@clbull.frcl.bull.fr [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id RAA19586; Fri, 9 Apr 2004 17:25:19 +0200 Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id RAA03273; Fri, 9 Apr 2004 17:12:01 +0200 Message-ID: <4076BE45.7080803@bull.net> Date: Fri, 09 Apr 2004 17:16:21 +0200 From: Denis Pinkas <Denis.Pinkas@bull.net> Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: Steve Hanna <Steve.Hanna@Sun.COM> CC: PKIX List <ietf-pkix@imc.org> Subject: Re: Successor to RFC 3280? References: <40620A08.20BBD37E@sun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Steve, This is an additional change proposal to the successor to RFC 3280. We are currently deprecating the use of the private key usage period. 4.2.1.4 Private Key Usage Period This extension SHOULD NOT be used within the Internet PKI. CAs conforming to this profile MUST NOT generate certificates that include a critical private key usage period extension. I have been advocating this in the past, while being (too much) focussed on keys for human beings: it is not possible to prevent a human being to use his private key beyond that date. However, if this key is placed within a(n evaluated) security module that has a secure clock, it possible to make sure that the security module prevents the use of the private key beyond the expiration date (e.g. the key can be zeroized). This is fully pertinent for time-stamping modules which must have a clock synchronised with UTC. Thus I would propose to allow and even recommend the use of this extension for keys located in security modules that have a secure clock, in particular time-stamping modules, where it is possible to enforce this control. Denis > I have heard some folks say that we should have > a successor to RFC 3280 (and 3279) and some folks > say that we shouldn't. I'd like to raise this topic > for discussion on the PKIX list to settle this matter. > > I believe that an update to RFC 3280 is necessary > for two reasons. First, some minor problems have > been found during implementation and deployment > (mostly typos and clarifications). These should > be fixed so that future implementors don't have > to suffer through them. Second, we are almost ready > for RFC 3280 to progress to Draft Standard status. > In order to do this, it must be revised. So I > believe that an update to RFC 3280 (and 3279) > should be undertaken. > > HOWEVER, I think it is essential for us to limit > the scope of this update. We should not add features > to the spec or make substantial changes, especially > changes that would break compatibility with RFC 3280. > The scope of the update should be limited to > "clarifying and correcting the document in light > of implementation experience". > > That's my perspective on this important matter. > I would like to hear other perspectives and > opinions so that we can arrive at a rough working > group consensus on this. > > Thanks, > > Steve > > P.S. I have a list of typos and clarifications > that need to be fixed in the next version of > RFC 3280. If we decide to proceed with a revision, > I'll forward it to the editor and cc the PKIX list. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i39DYN6s090639; Fri, 9 Apr 2004 06:34:23 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i39DYNb0090638; Fri, 9 Apr 2004 06:34:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mtiwmhc11.worldnet.att.net (mtiwmhc11.worldnet.att.net [204.127.131.115]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i39DYHal090617 for <ietf-pkix@imc.org>; Fri, 9 Apr 2004 06:34:17 -0700 (PDT) (envelope-from todd.glassey@worldnet.att.net) Received: from gw (184.san-jose-04-05rs.ca.dial-access.att.net[12.72.193.184]) by worldnet.att.net (mtiwmhc11) with SMTP id <20040409133411111006cvs6e>; Fri, 9 Apr 2004 13:34:12 +0000 Message-ID: <005501c41e37$415d88e0$010aff0a@gw> From: "todd glassey" <todd.glassey@worldnet.att.net> To: "Santoni Adriano" <adriano.santoni@actalis.it>, <pgut001@cs.auckland.ac.nz> Cc: <ietf-pkix@imc.org> References: <BE82E060F5EA2D44A4CFCFFA8363958803B4BA71@ntexch00.office.sia.it> Subject: Re: RFC3280: doubt on the use of UTF8String in encoding RDNs Date: Fri, 9 Apr 2004 06:31:46 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003C_01C41DFC.5504D280" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> This is a multi-part message in MIME format. ------=_NextPart_000_003C_01C41DFC.5504D280 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable R: RFC3280: doubt on the use of UTF8String in encoding RDNsPeter - = Santoni, the RFC is the RFC and it says MUST, and it addresses the = NameRollover issues as well with commentary about=20 (a) CAs MAY issue "name rollover" certificates to support an orderly migration to UTF8String encoding. Such certificates would include the CA's UTF8String encoded name as issuer and and the old name encoding as subject, or vice-versa. ... http://www.faqs.org/rfcs/rfc3280.html So my reading is that UTF8 is not optional. Todd Glassey ----- Original Message -----=20 From: Santoni Adriano=20 To: 'pgut001@cs.auckland.ac.nz'=20 Cc: ietf-pkix@imc.org=20 Sent: Friday, April 09, 2004 3:35 AM Subject: R: RFC3280: doubt on the use of UTF8String in encoding RDNs Thanks for replying, although it seems a reply to another question (my = fault, I presume).=20 I was referring to new certificates, issued "from today on" (so to = speak).=20 As a CA, we do not handle DNs "encoded by the originator"; which = "originator" at any rate?=20 We register people, collecting their own true names, and then we build = the DNs to be inserted into certificates. The names can be e.g. the = ASCII-safe name "Peter Gutman", or the polish name "Anna = Kr=C4=99glewska", or the greek = "=CE=91=CE=BD=CE=B4=CF=81=CE=B5=CE=B1=CF=83 = =CE=91=CE=BD=CE=B4=CF=81=CE=B5=CE=BF=CF=80=CE=BF=CF=85=CE=BB=CE=BF=CF=83"= or whatever else - can you read? :-). In the case of your name, a = PrintableString would be "safe", as it would retain all the original = information. In the latter cases, it would not and so it makes more = sense to use Unicode encoded as UTF8String. Maybe I am just not getting what you mean...=20 Adriano=20 -----Messaggio originale-----=20 Da: pgut001 [mailto:pgut001@medusa01.cs.auckland.ac.nz] Per conto di = pgut001@cs.auckland.ac.nz=20 Inviato: mercoled=C3=AC 7 aprile 2004 15.55=20 A: adriano.santoni@actalis.it; ietf-pkix@imc.org=20 Oggetto: Re: RFC3280: doubt on the use of UTF8String in encoding RDNs=20 Santoni Adriano <adriano.santoni@actalis.it> writes:=20 >I am probably asking an old question, so ... please be patient.=20 >=20 >Rfc3280 states (<A7>4.1.2.4): "...all certificates issued after=20 >December 31, 2003 MUST use the UTF8String encoding of=20 >DirectoryString...".=20 >=20 >Does that mean that it is mandatory to always encode all RDNs (having = a=20 >type of DirectoryString) of the issuer and subject (and still other)=20 >certificate fields as UTF8Strings _even if they could be correctly=20 >encoded as a PrintableStrings_ ?=20 Hmm, see the previous thread on this a few months ago... in theory = you're supposed to do this, but that violates the primary rule of DN = encoding, which is "Never change the DN once it's been encoded by the = originator". If you break that rule, you get to discover all the apps = that reject re-encoded DNs. If you're lucky, this will happen before = your product ships and not after. Peter.=20 *******************Internet Email Confidentiality = Footer*******************=20 Qualsiasi utilizzo non autorizzato del presente messaggio nonche' dei = suoi allegati e' vietato e potrebbe costituire reato. Se lei ha ricevuto = erroneamente il presente messaggio, Le saremmo grati se, via e-mail, ce = ne comunicasse la ricezione e provvedesse alla distruzione del messaggio = stesso e dei suoi eventuali allegati. Le dichiarazioni contenute nel = presente messaggio nonche' nei suoi eventuali allegati devono essere = attribuite esclusivamente al mittente e non possono essere considerate = come trasmesse o autorizzate da SIA S.p.A.; le medesime dichiarazioni = non impegnano SIA S.p.A. nei confronti del destinatario o di terzi.=20 SIA S.p.A. non si assume alcuna responsabilita' per eventuali = intercettazioni, modifiche o danneggiamenti del presente messaggio = e-mail.=20 Any unauthorized use of this e-mail or any of its attachments is = prohibited and could constitute an offence. If you are not the intended = addressee please advise immediately the sender by using the reply = facility in your e-mail software and destroy the message and its = attachments. The statements and opinions expressed in this e-mail = message are those of the author of the message and do not necessarily = represent those of SIA. Besides, The contents of this message shall be = understood as neither given nor endorsed by SIA S.p.A..=20 SIA S.p.A. does not accept liability for corruption, interception or = amendment, if any, or the consequences thereof.=20 ------=_NextPart_000_003C_01C41DFC.5504D280 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable =EF=BB=BF<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD><TITLE>R: RFC3280: doubt on the use of UTF8String in = encoding RDNs</TITLE> <META http-equiv=3DContent-Type content=3D"text/html; charset=3DUTF-8"> <META content=3D"MSHTML 6.00.2800.1400" name=3DGENERATOR> <STYLE></STYLE> </HEAD> <BODY bgColor=3D#ffffff> <DIV><FONT face=3DArial size=3D2>Peter - Santoni, the RFC is the RFC and = it says=20 MUST, and it addresses the NameRollover issues as well with commentary = about=20 </FONT></DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV><FONT face=3DArial> (a) CAs MAY = issue=20 "name rollover" certificates to support = an<BR> =20 orderly migration to UTF8String encoding. Such certificates=20 would<BR> include the CA's UTF8String = encoded name=20 as issuer and and the old<BR> name = encoding as=20 subject, or vice-versa.<BR></FONT></DIV> <DIV><FONT face=3DArial size=3D2>... <A=20 href=3D"http://www.faqs.org/rfcs/rfc3280.html">http://www.faqs.org/rfcs/r= fc3280.html</A></FONT></DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV><FONT face=3DArial size=3D2>So my reading is that UTF8 is not=20 optional.</FONT></DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV><FONT face=3DArial size=3D2>Todd Glassey</FONT></DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <BLOCKQUOTE=20 style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; = BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px"> <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV> <DIV=20 style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: = black"><B>From:</B>=20 <A title=3Dadriano.santoni@actalis.it=20 href=3D"mailto:adriano.santoni@actalis.it">Santoni Adriano</A> </DIV> <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A = title=3Dpgut001@cs.auckland.ac.nz=20 = href=3D"mailto:'pgut001@cs.auckland.ac.nz'">'pgut001@cs.auckland.ac.nz'</= A>=20 </DIV> <DIV style=3D"FONT: 10pt arial"><B>Cc:</B> <A = title=3Dietf-pkix@imc.org=20 href=3D"mailto:ietf-pkix@imc.org">ietf-pkix@imc.org</A> </DIV> <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Friday, April 09, 2004 = 3:35=20 AM</DIV> <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> R: RFC3280: doubt on = the use of=20 UTF8String in encoding RDNs</DIV> <DIV><BR></DIV> <P><FONT face=3DVerdana color=3D#0000ff>Thanks for replying, although = it seems a=20 reply to another question (my fault, I presume). </FONT></P> <P><FONT face=3DVerdana color=3D#0000ff>I was referring to new = certificates,=20 issued "from today on" (so to speak). </FONT></P> <P><FONT face=3DVerdana color=3D#0000ff>As a CA, we do not handle DNs = "encoded by=20 the originator"; which "originator" at any rate? </FONT></P> <P><FONT face=3DVerdana color=3D#0000ff>We register people, collecting = their own=20 true names, and then we build the DNs to be inserted into = certificates. The=20 names can be e.g. the ASCII-safe name "Peter Gutman", or the polish = name "Anna=20 Kr</FONT><FONT face=3DVerdana = color=3D#0000ff>=C4=99glewska</FONT><FONT face=3DVerdana=20 color=3D#0000ff>", or the greek "</FONT><FONT face=3DVerdana = color=3D#0000ff>=CE=91=CE=BD=CE=B4=CF=81=CE=B5=CE=B1=CF=83=20 = =CE=91=CE=BD=CE=B4=CF=81=CE=B5=CE=BF=CF=80=CE=BF=CF=85=CE=BB=CE=BF=CF=83<= /FONT><FONT face=3DVerdana color=3D#0000ff>" or whatever else - can=20 you read? :-). In the case of your name, a PrintableString would be = "safe", as=20 it would retain all the original information. In the latter cases, it = would=20 not and so it makes more sense to use Unicode encoded as=20 UTF8String.</FONT></P> <P><FONT face=3DVerdana color=3D#0000ff>Maybe I am just not getting = what you=20 mean...</FONT> </P> <P><FONT face=3DVerdana color=3D#0000ff>Adriano</FONT> </P><BR> <P><FONT face=3DArial size=3D2>-----Messaggio originale-----</FONT> = <BR><FONT=20 face=3DArial size=3D2>Da: pgut001 [</FONT><A=20 href=3D"mailto:pgut001@medusa01.cs.auckland.ac.nz"><U><FONT = face=3DArial=20 color=3D#0000ff=20 size=3D2>mailto:pgut001@medusa01.cs.auckland.ac.nz</FONT></U></A><FONT = face=3DArial size=3D2>] Per conto di pgut001@cs.auckland.ac.nz</FONT> = <BR><FONT=20 face=3DArial size=3D2>Inviato: mercoled=C3=AC 7 aprile 2004 = 15.55</FONT> <BR><FONT=20 face=3DArial size=3D2>A: adriano.santoni@actalis.it; = ietf-pkix@imc.org</FONT>=20 <BR><FONT face=3DArial size=3D2>Oggetto: Re: RFC3280: doubt on the use = of=20 UTF8String in encoding RDNs</FONT> </P><BR> <P><FONT face=3DArial size=3D2>Santoni Adriano = <adriano.santoni@actalis.it>=20 writes:</FONT> </P> <P><FONT face=3DArial size=3D2>>I am probably asking an old = question, so ...=20 please be patient.</FONT> <BR><FONT face=3DArial size=3D2>></FONT> = <BR><FONT=20 face=3DArial size=3D2>>Rfc3280 states (<A7>4.1.2.4): "...all = certificates=20 issued after </FONT><BR><FONT face=3DArial size=3D2>>December 31, = 2003 MUST use=20 the UTF8String encoding of </FONT><BR><FONT face=3DArial=20 size=3D2>>DirectoryString...".</FONT> <BR><FONT face=3DArial = size=3D2>></FONT>=20 <BR><FONT face=3DArial size=3D2>>Does that mean that it is = mandatory to always=20 encode all RDNs (having a </FONT><BR><FONT face=3DArial = size=3D2>>type of=20 DirectoryString) of the issuer and subject (and still other) = </FONT><BR><FONT=20 face=3DArial size=3D2>>certificate fields as UTF8Strings _even if = they could be=20 correctly </FONT><BR><FONT face=3DArial size=3D2>>encoded as a=20 PrintableStrings_ ?</FONT> </P> <P><FONT face=3DArial size=3D2>Hmm, see the previous thread on this a = few months=20 ago... in theory you're supposed to do this, but that violates the = primary=20 rule of DN encoding, which is "Never change the DN once it's been = encoded by=20 the originator". If you break that rule, you get to discover all = the=20 apps that reject re-encoded DNs. If you're lucky, this will happen = before your=20 product ships and not after.</FONT></P> <P><FONT face=3DArial size=3D2>Peter.</FONT> </P><BR> <P><FONT face=3DArial size=3D2>*******************Internet Email = Confidentiality=20 Footer******************* </FONT><BR><FONT face=3DArial = size=3D2>Qualsiasi=20 utilizzo non autorizzato del presente messaggio nonche' dei suoi = allegati e'=20 vietato e potrebbe costituire reato. Se lei ha ricevuto erroneamente = il=20 presente messaggio, Le saremmo grati se, via e-mail, ce ne comunicasse = la=20 ricezione e provvedesse alla distruzione del messaggio stesso e dei = suoi=20 eventuali allegati. Le dichiarazioni contenute nel presente messaggio = nonche'=20 nei suoi eventuali allegati devono essere attribuite esclusivamente al = mittente e non possono essere considerate come trasmesse o autorizzate = da SIA=20 S.p.A.; le medesime dichiarazioni non impegnano SIA S.p.A. nei = confronti del=20 destinatario o di terzi. </FONT></P> <P><FONT face=3DArial size=3D2>SIA S.p.A. non si assume alcuna = responsabilita' per=20 eventuali intercettazioni, modifiche o danneggiamenti del presente = messaggio=20 e-mail. </FONT></P> <P><FONT face=3DArial size=3D2>Any unauthorized use of this e-mail or = any of its=20 attachments is prohibited and could constitute an offence. If you are = not the=20 intended addressee please advise immediately the sender by using the = reply=20 facility in your e-mail software and destroy the message and its = attachments.=20 The statements and opinions expressed in this e-mail message are those = of the=20 author of the message and do not necessarily represent those of SIA. = Besides,=20 The contents of this message shall be understood as neither given nor = endorsed=20 by SIA S.p.A.. </FONT></P> <P><FONT face=3DArial size=3D2>SIA S.p.A. does not accept liability = for=20 corruption, interception or amendment, if any, or the consequences = thereof.=20 </FONT></P><BR></BLOCKQUOTE></BODY></HTML> ------=_NextPart_000_003C_01C41DFC.5504D280-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i39CamOf083710; Fri, 9 Apr 2004 05:36:48 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i39CamPI083709; Fri, 9 Apr 2004 05:36:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp-ft4.fr.colt.net (smtp-ft4.fr.colt.net [213.41.78.203]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i39CaecO083669 for <ietf-pkix@imc.org>; Fri, 9 Apr 2004 05:36:40 -0700 (PDT) (envelope-from jmdesp@free.fr) Received: from free.fr (host.104.92.68.195.rev.coltfrance.com [195.68.92.104]) by smtp-ft4.fr.colt.net with ESMTP id i39CaOq03399 for <ietf-pkix@imc.org>; Fri, 9 Apr 2004 14:36:24 +0200 Message-ID: <407698C2.6080907@free.fr> Date: Fri, 09 Apr 2004 14:36:18 +0200 From: Jean-Marc Desperrier <jmdesp@free.fr> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:) Gecko/20040226 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: Re: R: RFC3280: doubt on the use of UTF8String in encoding RDNs References: <BE82E060F5EA2D44A4CFCFFA8363958803B4BA71@ntexch00.office.sia.it> In-Reply-To: <BE82E060F5EA2D44A4CFCFFA8363958803B4BA71@ntexch00.office.sia.it> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Santoni Adriano wrote: > As a CA, we do not handle DNs "encoded by the originator"; which > "originator" at any rate? > _You_ are the originator, it's the CA that fixes what the name is when creating the X509 cert, and anybody using that name after that never should change it. (But if you generate a cross -certificate or find yourself in a similar situation where another CA has already created the name, you shouldn't change it at all if you want to get good inter-operability). Peter is not of that mind, I understood he thinks it's important to preserve the name that is created in the request where the client presented you his public key, and I had no time to argue about that the last time he raised it on the list. But I'm positive clients *never* check if the response cert is coherent with the name in the request they sent, that anyway most CA just dump to the trash the name that whas included in the request and generate the name with a completely independant algorithm (they often use registration pages with a fixed name for the request), that in some case there is no request (pre-generated keys in tokens, the client just sends the token id, and the CA has OOB ways to know the corresponding public key). So when you CA issue the very first cert for a user, you are free to fix the name, and it can be good to normalize it. One this first cert is there, his "primary rule of DN encoding" actually applies, and application should better never touch the name and never use any transformation when doing comparisons to avoid problems, this including CA if renewing or cross-certificating. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i39AZOgr068771; Fri, 9 Apr 2004 03:35:24 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i39AZOO9068770; Fri, 9 Apr 2004 03:35:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from ntexch03.office.sia.it (clients.sia.it [193.203.230.22] (may be forged)) by above.proper.com (8.12.11/8.12.8) with ESMTP id i39AZGYa068762 for <ietf-pkix@imc.org>; Fri, 9 Apr 2004 03:35:23 -0700 (PDT) (envelope-from adriano.santoni@actalis.it) Received: by ntexch03.office.sia.it with Internet Mail Service (5.5.2657.72) id <HJMG7CB7>; Fri, 9 Apr 2004 12:35:17 +0200 Message-ID: <BE82E060F5EA2D44A4CFCFFA8363958803B4BA71@ntexch00.office.sia.it> From: Santoni Adriano <adriano.santoni@actalis.it> To: "'pgut001@cs.auckland.ac.nz'" <pgut001@cs.auckland.ac.nz> Cc: ietf-pkix@imc.org Subject: R: RFC3280: doubt on the use of UTF8String in encoding RDNs Date: Fri, 9 Apr 2004 12:35:08 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C41E1E.53FF5D25" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C41E1E.53FF5D25 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for replying, although it seems a reply to another question (my fault, I presume).=20 I was referring to new certificates, issued "from today on" (so to = speak).=20 As a CA, we do not handle DNs "encoded by the originator"; which "originator" at any rate?=20 We register people, collecting their own true names, and then we build = the DNs to be inserted into certificates. The names can be e.g. the = ASCII-safe name "Peter Gutman", or the polish name "Anna Kr=C4=99glewska", or the = greek "=CE=91=CE=BD=CE=B4=CF=81=CE=B5=CE=B1=CF=83 = =CE=91=CE=BD=CE=B4=CF=81=CE=B5=CE=BF=CF=80=CE=BF=CF=85=CE=BB=CE=BF=CF=83= " or whatever else - can you read? :-). In the case of your name, a PrintableString would be "safe", as it would retain all = the original information. In the latter cases, it would not and so it makes = more sense to use Unicode encoded as UTF8String. Maybe I am just not getting what you mean... Adriano -----Messaggio originale----- Da: pgut001 [mailto:pgut001@medusa01.cs.auckland.ac.nz <mailto:pgut001@medusa01.cs.auckland.ac.nz> ] Per conto di pgut001@cs.auckland.ac.nz Inviato: mercoled=C3=AC 7 aprile 2004 15.55 A: adriano.santoni@actalis.it; ietf-pkix@imc.org Oggetto: Re: RFC3280: doubt on the use of UTF8String in encoding RDNs Santoni Adriano <adriano.santoni@actalis.it> writes: >I am probably asking an old question, so ... please be patient. > >Rfc3280 states (<A7>4.1.2.4): "...all certificates issued after=20 >December 31, 2003 MUST use the UTF8String encoding of=20 >DirectoryString...". > >Does that mean that it is mandatory to always encode all RDNs (having = a=20 >type of DirectoryString) of the issuer and subject (and still other)=20 >certificate fields as UTF8Strings _even if they could be correctly=20 >encoded as a PrintableStrings_ ? Hmm, see the previous thread on this a few months ago... in theory = you're supposed to do this, but that violates the primary rule of DN encoding, which is "Never change the DN once it's been encoded by the = originator". If you break that rule, you get to discover all the apps that reject = re-encoded DNs. If you're lucky, this will happen before your product ships and = not after. Peter. *******************Internet Email Confidentiality = Footer*******************=20 Qualsiasi utilizzo non autorizzato del presente messaggio nonche' dei = suoi allegati e' vietato e potrebbe costituire reato. Se lei ha ricevuto erroneamente il presente messaggio, Le saremmo grati se, via e-mail, ce = ne comunicasse la ricezione e provvedesse alla distruzione del messaggio = stesso e dei suoi eventuali allegati. Le dichiarazioni contenute nel presente messaggio nonche' nei suoi eventuali allegati devono essere attribuite esclusivamente al mittente e non possono essere considerate come = trasmesse o autorizzate da SIA S.p.A.; le medesime dichiarazioni non impegnano SIA S.p.A. nei confronti del destinatario o di terzi.=20 SIA S.p.A. non si assume alcuna responsabilita' per eventuali intercettazioni, modifiche o danneggiamenti del presente messaggio = e-mail.=20 Any unauthorized use of this e-mail or any of its attachments is = prohibited and could constitute an offence. If you are not the intended addressee please advise immediately the sender by using the reply facility in = your e-mail software and destroy the message and its attachments. The = statements and opinions expressed in this e-mail message are those of the author = of the message and do not necessarily represent those of SIA. Besides, The = contents of this message shall be understood as neither given nor endorsed by = SIA S.p.A..=20 SIA S.p.A. does not accept liability for corruption, interception or amendment, if any, or the consequences thereof.=20 ------_=_NextPart_001_01C41E1E.53FF5D25 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3DUTF-8"> <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version = 5.5.2657.88"> <TITLE>R: RFC3280: doubt on the use of UTF8String in encoding = RDNs</TITLE> </HEAD> <BODY> <P><FONT COLOR=3D"#0000FF" FACE=3D"Verdana">Thanks for replying, = although it seems a reply to another question (my fault, I presume). = </FONT> </P> <P><FONT COLOR=3D"#0000FF" FACE=3D"Verdana">I was referring to new = certificates, issued "from today on" (so to speak). </FONT> </P> <P><FONT COLOR=3D"#0000FF" FACE=3D"Verdana">As a CA, we do not handle = DNs "encoded by the originator"; which "originator" = at any rate? </FONT> </P> <P><FONT COLOR=3D"#0000FF" FACE=3D"Verdana">We register people, = collecting their own true names, and then we build the DNs to be = inserted into certificates. The names can be e.g. the ASCII-safe name = "Peter Gutman", or the polish name "Anna Kr</FONT><FONT = COLOR=3D"#0000FF" FACE=3D"Verdana">=C4=99glewska</FONT><FONT = COLOR=3D"#0000FF" FACE=3D"Verdana">", or the greek = "</FONT><FONT COLOR=3D"#0000FF" = FACE=3D"Verdana">=CE=91=CE=BD=CE=B4=CF=81=CE=B5=CE=B1=CF=83 = =CE=91=CE=BD=CE=B4=CF=81=CE=B5=CE=BF=CF=80=CE=BF=CF=85=CE=BB=CE=BF=CF=83= </FONT><FONT COLOR=3D"#0000FF" FACE=3D"Verdana">" or whatever else = - can you read? :-). In the case of your name, a PrintableString would = be "safe", as it would retain all the original information. = In the latter cases, it would not and so it makes more sense to use = Unicode encoded as UTF8String.</FONT></P> <P><FONT COLOR=3D"#0000FF" FACE=3D"Verdana">Maybe I am just not getting = what you mean...</FONT> </P> <P><FONT COLOR=3D"#0000FF" FACE=3D"Verdana">Adriano</FONT> </P> <BR> <P><FONT SIZE=3D2 FACE=3D"Arial">-----Messaggio originale-----</FONT> <BR><FONT SIZE=3D2 FACE=3D"Arial">Da: pgut001 [</FONT><A = HREF=3D"mailto:pgut001@medusa01.cs.auckland.ac.nz"><U><FONT = COLOR=3D"#0000FF" SIZE=3D2 = FACE=3D"Arial">mailto:pgut001@medusa01.cs.auckland.ac.nz</FONT></U></A><= FONT SIZE=3D2 FACE=3D"Arial">] Per conto di = pgut001@cs.auckland.ac.nz</FONT> <BR><FONT SIZE=3D2 FACE=3D"Arial">Inviato: mercoled=C3=AC 7 aprile 2004 = 15.55</FONT> <BR><FONT SIZE=3D2 FACE=3D"Arial">A: adriano.santoni@actalis.it; = ietf-pkix@imc.org</FONT> <BR><FONT SIZE=3D2 FACE=3D"Arial">Oggetto: Re: RFC3280: doubt on the = use of UTF8String in encoding RDNs</FONT> </P> <BR> <P><FONT SIZE=3D2 FACE=3D"Arial">Santoni Adriano = <adriano.santoni@actalis.it> writes:</FONT> </P> <P><FONT SIZE=3D2 FACE=3D"Arial">>I am probably asking an old = question, so ... please be patient.</FONT> <BR><FONT SIZE=3D2 FACE=3D"Arial">></FONT> <BR><FONT SIZE=3D2 FACE=3D"Arial">>Rfc3280 states = (<A7>4.1.2.4): "...all certificates issued after </FONT> <BR><FONT SIZE=3D2 FACE=3D"Arial">>December 31, 2003 MUST use the = UTF8String encoding of </FONT> <BR><FONT SIZE=3D2 FACE=3D"Arial">>DirectoryString...".</FONT> <BR><FONT SIZE=3D2 FACE=3D"Arial">></FONT> <BR><FONT SIZE=3D2 FACE=3D"Arial">>Does that mean that it is = mandatory to always encode all RDNs (having a </FONT> <BR><FONT SIZE=3D2 FACE=3D"Arial">>type of DirectoryString) of the = issuer and subject (and still other) </FONT> <BR><FONT SIZE=3D2 FACE=3D"Arial">>certificate fields as UTF8Strings = _even if they could be correctly </FONT> <BR><FONT SIZE=3D2 FACE=3D"Arial">>encoded as a PrintableStrings_ = ?</FONT> </P> <P><FONT SIZE=3D2 FACE=3D"Arial">Hmm, see the previous thread on this a = few months ago... in theory you're supposed to do this, but that = violates the primary rule of DN encoding, which is "Never change = the DN once it's been encoded by the originator". If you = break that rule, you get to discover all the apps that reject = re-encoded DNs. If you're lucky, this will happen before your product = ships and not after.</FONT></P> <P><FONT SIZE=3D2 FACE=3D"Arial">Peter.</FONT> </P> <BR> <P><FONT SIZE=3D2 FACE=3D"Arial">*******************Internet Email = Confidentiality Footer******************* </FONT> <BR><FONT SIZE=3D2 FACE=3D"Arial">Qualsiasi utilizzo non autorizzato = del presente messaggio nonche' dei suoi allegati e' vietato e potrebbe = costituire reato. Se lei ha ricevuto erroneamente il presente = messaggio, Le saremmo grati se, via e-mail, ce ne comunicasse la = ricezione e provvedesse alla distruzione del messaggio stesso e dei = suoi eventuali allegati. Le dichiarazioni contenute nel presente = messaggio nonche' nei suoi eventuali allegati devono essere attribuite = esclusivamente al mittente e non possono essere considerate come = trasmesse o autorizzate da SIA S.p.A.; le medesime dichiarazioni non = impegnano SIA S.p.A. nei confronti del destinatario o di terzi. = </FONT></P> <P><FONT SIZE=3D2 FACE=3D"Arial">SIA S.p.A. non si assume alcuna = responsabilita' per eventuali intercettazioni, modifiche o = danneggiamenti del presente messaggio e-mail. </FONT></P> <P><FONT SIZE=3D2 FACE=3D"Arial">Any unauthorized use of this e-mail or = any of its attachments is prohibited and could constitute an offence. = If you are not the intended addressee please advise immediately the = sender by using the reply facility in your e-mail software and destroy = the message and its attachments. The statements and opinions expressed = in this e-mail message are those of the author of the message and do = not necessarily represent those of SIA. Besides, The contents of this = message shall be understood as neither given nor endorsed by SIA = S.p.A.. </FONT></P> <P><FONT SIZE=3D2 FACE=3D"Arial">SIA S.p.A. does not accept liability = for corruption, interception or amendment, if any, or the consequences = thereof. </FONT> </P> <BR> </BODY> </HTML> ------_=_NextPart_001_01C41E1E.53FF5D25-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i39232Fs033034; Thu, 8 Apr 2004 19:03:02 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i39232Q8033033; Thu, 8 Apr 2004 19:03:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mtiwmhc11.worldnet.att.net (mtiwmhc11.worldnet.att.net [204.127.131.115]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3922xjt033015 for <ietf-pkix@imc.org>; Thu, 8 Apr 2004 19:02:59 -0700 (PDT) (envelope-from todd.glassey@worldnet.att.net) Received: from gw (101.san-jose-09-10rs.ca.dial-access.att.net[12.72.195.101]) by worldnet.att.net (mtiwmhc11) with SMTP id <20040409020253111006pn0de>; Fri, 9 Apr 2004 02:02:57 +0000 Message-ID: <00ce01c41dd6$afd0a570$010aff0a@gw> From: "todd glassey" <todd.glassey@worldnet.att.net> To: "Al Arsenault" <aarsenau@bbn.com>, "Eric Norman" <ejnorman@doit.wisc.edu>, "PKIX list" <ietf-pkix@imc.org> References: <GBEOIAAPLLBIMLPDGHDHOEOCCIAA.aarsenau@bbn.com> Subject: Re: Identity (was PKI International Consortium) Date: Thu, 8 Apr 2004 19:02:08 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> ----- Original Message ----- From: "Al Arsenault" <aarsenau@bbn.com> To: "Eric Norman" <ejnorman@doit.wisc.edu>; "PKIX list" <ietf-pkix@imc.org> Sent: Sunday, April 04, 2004 6:19 PM Subject: RE: Identity (was PKI International Consortium) > > > > > > > > On Sun, 4 Apr 2004 amg@lcc.uma.es wrote: > > > > > So, again, in the design of Identity Certificates we should > > concentrate on > > > Identity issues, and on the needs of systems requiring > > identification. Trying > > > to use Identity Certificates for other uses is wrong. > > > > Well, my opinion is that you won't have much luck dealing with "Identity > > issues" until you have a good definition of "identity". > > > > Here's my shot at it. If you start from the premise that identity is > > just a set of attributes, then your identity is those attributes that > > are constant and last forever. > > AWA: "reasonably forever". :-) There aren't any attributes guaranteed to last forever. People change their names, for reasons of marriage, divorce, or because they just want to. Affiliations - employers, university attended, etc. - change when circumstances change. DNA is reasonably constant > > > > > So, my "Identity certificate" asserts an association between me and > > the University of Wisconsin. Is that part of my identity? It depends > > on how you interpret that assertion. If you interpret it as "was at > > one time affiliated with that university", then that lasts forever and > > it is (Winston Smith to the contrary). If you interpret it as "is > > currently affiliated...", then it isn't. > > > > The only observation I can make right now is that with the former > > interpretation, Lynn Wheeler doesn't get to use the adjectives "stale" > > and "static". Whether that's any more useful than counting angels > > dancing on pinheads remains to be seen, I suppose. > > > > > > AWA: I tend to agree with this. > > > Eric Norman > > > > "Congress shall make no law restricting the size of integers > > that may be multiplied together, or the number of times that > > an integer may be multiplied by itself, or the modulus by > > which an integer may be reduced". > > Al Arsenault > BBN Technologies > > (should I add "no longer a Verizon company"? :-) > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i38NaaFF019834; Thu, 8 Apr 2004 16:36:36 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i38NaaKf019833; Thu, 8 Apr 2004 16:36:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from 21cn.com (send.forptr.21cn.com [61.140.60.52]) by above.proper.com (8.12.11/8.12.8) with SMTP id i38NaYOM019825 for <ietf-pkix@imc.org>; Thu, 8 Apr 2004 16:36:35 -0700 (PDT) (envelope-from aarsenau@bbn.com) Received: from 21cn.com([127.0.0.1]) by 21cn.com(AIMC 2.9.5.6) with SMTP id jm440761403; Fri, 09 Apr 2004 07:51:54 +0800 X-MaxRuleNumber-200: 1907127 23219347 X-MatchRuleNumber-200: 1880690 13652005 X-Action-200: D Received: from 21cn.com([10.2.1.3]) by 21cn.com(AIMC 2.9.5.4) with SMTP id AISP action; Fri, 09 Apr 2004 07:51:54 +0800 Received: from above.proper.com([127.0.0.1]) by 21cn.com(AIMC 2.9.5.6) with SMTP id jm904071577c; Mon, 05 Apr 2004 13:31:40 +0800 X-MaxRuleNumber-200: 1895476 6969843 X-MatchRuleNumber-200: 1880690 13652005 X-Action-200: D Received: from above.proper.com([208.184.76.39]) by 21cn.com(AIMC 2.9.5.4) with SMTP id AISP action; Mon, 05 Apr 2004 13:31:39 +0800 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i351KK8e041412; Sun, 4 Apr 2004 18:20:20 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i351KKvA041411; Sun, 4 Apr 2004 18:20:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i351KKsF041402 for <ietf-pkix@imc.org>; Sun, 4 Apr 2004 18:20:20 -0700 (PDT) (envelope-from aarsenau@bbn.com) Received: from arsenaultd2 (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with SMTP id i351KK7W019468; Sun, 4 Apr 2004 21:20:20 -0400 (EDT) From: "Al Arsenault" <aarsenau@bbn.com> To: "Eric Norman" <ejnorman@doit.wisc.edu>, "PKIX list" <ietf-pkix@imc.org> Subject: RE: Identity (was PKI International Consortium) Date: Sun, 4 Apr 2004 21:19:23 -0400 Message-ID: <GBEOIAAPLLBIMLPDGHDHOEOCCIAA.aarsenau@bbn.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <Pine.A41.4.44.0404041925340.18426-100000@holstein.doit.wisc.edu> X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i351KKsF041406 List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> X-AIMC-AUTH: (null) X-AIMC-MAILFROM: owner-ietf-pkix@mail.imc.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: aarsenau@bbn.com Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> > > On Sun, 4 Apr 2004 amg@lcc.uma.es wrote: > > > So, again, in the design of Identity Certificates we should > concentrate on > > Identity issues, and on the needs of systems requiring > identification. Trying > > to use Identity Certificates for other uses is wrong. > > Well, my opinion is that you won't have much luck dealing with "Identity > issues" until you have a good definition of "identity". > > Here's my shot at it. If you start from the premise that identity is > just a set of attributes, then your identity is those attributes that > are constant and last forever. AWA: "reasonably forever". :-) There aren't any attributes guaranteed to last forever. People change their names, for reasons of marriage, divorce, or because they just want to. Affiliations - employers, university attended, etc. - change when circumstances change. > > So, my "Identity certificate" asserts an association between me and > the University of Wisconsin. Is that part of my identity? It depends > on how you interpret that assertion. If you interpret it as "was at > one time affiliated with that university", then that lasts forever and > it is (Winston Smith to the contrary). If you interpret it as "is > currently affiliated...", then it isn't. > > The only observation I can make right now is that with the former > interpretation, Lynn Wheeler doesn't get to use the adjectives "stale" > and "static". Whether that's any more useful than counting angels > dancing on pinheads remains to be seen, I suppose. > > AWA: I tend to agree with this. > Eric Norman > > "Congress shall make no law restricting the size of integers > that may be multiplied together, or the number of times that > an integer may be multiplied by itself, or the modulus by > which an integer may be reduced". Al Arsenault BBN Technologies (should I add "no longer a Verizon company"? :-) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i38Kt6lq010002; Thu, 8 Apr 2004 13:55:06 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i38Kt63t010001; Thu, 8 Apr 2004 13:55:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mongo.corestreet.com (mongo.corestreet.com [68.162.232.130]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i38Kt5Fq009992 for <ietf-pkix@imc.org>; Thu, 8 Apr 2004 13:55:05 -0700 (PDT) (envelope-from dengberg@corestreet.com) X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: draft-ietf-pkix-scvp-14.txt Date: Thu, 8 Apr 2004 16:54:19 -0400 Message-ID: <DE909E05406F3340B186DA5A410B05F642A459@mongo.corestreet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-pkix-scvp-14.txt Thread-Index: AcQdqVji5Fd34llRQDe9tjFF8vVyGwAAbx8g From: "Dave Engberg" <dengberg@corestreet.com> To: <ietf-pkix@imc.org> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i38Kt6Fq009996 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> It is not clear in this draft what the value of the response's "RequestReference" should be if a non-unique (i.e. cached & signed) DPD response is provided by the server. I would recommend making this field optional, or else clarify that clients should not perform a comparison unless they have requested a unique response. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i38Kqhfd009858; Thu, 8 Apr 2004 13:52:43 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i38Kqh7w009857; Thu, 8 Apr 2004 13:52:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mdhagsmtp01.firstdata.com (mdhagsmtp01.firstdata.com [198.184.5.21]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i38KqgJd009851 for <ietf-pkix@imc.org>; Thu, 8 Apr 2004 13:52:42 -0700 (PDT) (envelope-from lynn.wheeler@firstdata.com) Subject: Privacy, personally identifiable information, identity theft To: PKIX list <ietf-pkix@imc.org> X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: <OF1E90F7BC.58064631-ON87256E70.0072344F@firstdata.com> From: lynn.wheeler@firstdata.com Date: Thu, 8 Apr 2004 14:51:10 -0600 X-MIMETrack: Serialize by Router on MDHAGSMTP/FDMS/FDC(Release 6.0.2CF2|July 23, 2003) at 04/08/2004 04:51:49 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> minor references to eu data privacy directive related to those email issues: http//www.dmeurope.com/default.asp?ArticleID=1417 http//www.dmnews.com/cgi-bin/artprevbot.cgi?article_id=27045 lynn.wheeler wrote: we were called in by one of the industry groups to do some work on the cal. e-sign legistlation ... and then later on the federal bill. their interest was focused on some of the implications between e-sign and privacy. one of the things that they had studied was the driving factors behind privacy legislation ... which they claimed to be 1) identity theft and 2) denial of (institutional) service. Note that since then, there are issues with exposure of email addresses ... for instance look at the postings in the PKIX archive: http://www.imc.org/ietf-pkix/mail-archive/maillist.html Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i38KKuSI008100; Thu, 8 Apr 2004 13:20:56 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i38KKuWS008099; Thu, 8 Apr 2004 13:20:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i38KKsQX008093 for <ietf-pkix@imc.org>; Thu, 8 Apr 2004 13:20:55 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18475; Thu, 8 Apr 2004 16:20:57 -0400 (EDT) Message-Id: <200404082020.QAA18475@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-pkix@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pkix-scvp-14.txt Date: Thu, 08 Apr 2004 16:20:57 -0400 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. Title : Simple Certificate Validation Protocol (SCVP) Author(s) : A. Malpani, et al. Filename : draft-ietf-pkix-scvp-14.txt Pages : 53 Date : 2004-4-8 SCVP allows a client to offload certificate handling to a server. The server can provide the client with a variety of valuable information about the certificate, such as whether the certificate is valid, a certification path to a trust anchor, and revocation status. SCVP has many purposes, including simplifying client implementations and allowing companies to centralize trust and policy management. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-scvp-14.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pkix-scvp-14.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pkix-scvp-14.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-4-8164344.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pkix-scvp-14.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pkix-scvp-14.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-8164344.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i38K1xue006944; Thu, 8 Apr 2004 13:01:59 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i38K1xuq006943; Thu, 8 Apr 2004 13:01:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from imf24aec.mail.bellsouth.net (imf24aec.mail.bellsouth.net [205.152.59.72]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i38K1xhi006937 for <ietf-pkix@imc.org>; Thu, 8 Apr 2004 13:01:59 -0700 (PDT) (envelope-from brian@holmespun.biz) Received: from holmespun.biz ([68.157.45.154]) by imf24aec.mail.bellsouth.net (InterMail vM.5.01.06.08 201-253-122-130-108-20031117) with ESMTP id <20040408200158.MFIQ26287.imf24aec.mail.bellsouth.net@holmespun.biz> for <ietf-pkix@imc.org>; Thu, 8 Apr 2004 16:01:58 -0400 Message-ID: <4075B024.6050002@holmespun.biz> Date: Thu, 08 Apr 2004 16:03:48 -0400 From: "Brian G. Holmes" <brian@holmespun.biz> Organization: Holmespun Solutions, LLC User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: Decoding Service Support Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> PKIX Discussion List Members... I am writing to you in order to determine whether or not I should invest more of my time to support the PKIX family of protocols. I support a free BER for ASN.1 decoding service known as the Berasno Decoding Service. The service was originally established for decoding the GSM MAP and ITU TCAP protocols. Now I am looking for other protocols to support. I am new to the PKIX family of protocols. In my investigation of RFC 3280, I found that the protocol has a straight-forward ASN.1 definition. It appears that there would be a need to support Extensions based on OID; that functionality would be very similar to one used to identify GSM MAP information within TCAP. I may also be able to support protocols like the one defined in draft-ietf-pkix-tap-00.txt (using RFCs 3280, 3281, 3161, 3369, and 2510). I am looking for guidance. I need your opinions, and some sample data. I want the Berasno Decoding Service to be used, so I am looking for ways to make it useful. What protocols would you like to see supported? What information would you like to see presented? Do you have a favorite decode report format? Should the service support Base64 as an input data format? Thank you for your time. ...Brian NOTE: If this is an inappropriate topic for discussion on this list then please let a list administrator say so ASAP. Of course, you are welcome to send your responses directly to me. -- Holmespun Solutions, LLC http://www.holmespun.biz 919-844-7713 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i38EOoSP085172; Thu, 8 Apr 2004 07:24:50 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i38EOoMB085171; Thu, 8 Apr 2004 07:24:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mdhagsmtp01.firstdata.com (mdhagsmtp01.firstdata.com [198.184.5.21]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i38EOnU9085165 for <ietf-pkix@imc.org>; Thu, 8 Apr 2004 07:24:49 -0700 (PDT) (envelope-from lynn.wheeler@firstdata.com) Subject: Privacy, personally identifiable information, identity theft To: PKIX list <ietf-pkix@imc.org> X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: <OF38D29493.668A3083-ON87256E70.004E8E31@firstdata.com> From: lynn.wheeler@firstdata.com Date: Thu, 8 Apr 2004 08:19:34 -0600 X-MIMETrack: Serialize by Router on MDHAGSMTP/FDMS/FDC(Release 6.0.2CF2|July 23, 2003) at 04/08/2004 10:23:54 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> <resend from 4/6, there appears to be some email tarpit> we were called in by one of the industry groups to do some work on the cal. e-sign legistlation ... and then later on the federal bill. their interest was focused on some of the implications between e-sign and privacy. one of the things that they had studied was the driving factors behind privacy legislation ... which they claimed to be 1) identity theft and 2) denial of (institutional) service. Note that since then, there are issues with exposure of email addresses ... for instance look at the postings in the PKIX archive: http://www.imc.org/ietf-pkix/mail-archive/maillist.html the issue with institutions in the mid-90s retrenching from the early x.509 identity certificates to relying-party-only certificates (basically a public key and an account number ... or other database index ... where the actual information might be located) .... wasn't directly an identity theft issue .... it was the significant privacy issues. Some of the privacy issues are related to identity theft ... but it isn't solely an identity theft issue. the various privacy legislative and regulatory aspects are related to exposing personal identifiable information ... how and where that information might be exposed ... regardless of whether or not that information might be contained in a certificate or any other form. some of the exposure issues may be related to identity theft. GLB has a bunch of stuff about sharing of information within an institutions and/or affiliated third parties. One could imagine a document (certificate or otherwise) ... where it would be perfectly ok to transmit and/or exchange between the individual and the primary institution ... but there would be a requirement that no other entity be allowed to see it. If some types of that information happened to be contained in a certificate ... then how that certificate was used, how it was transmitted, and who was allowed to see it might be subject to various privacy legislation and/or privacy regulations. Recently issue was rasied that the proposed google email service may be in violation of various privacy legislation and/or regulations. In hypothetical scenario an entity digitally signs a perfectly acceptable transaction. In a certificate-based authentication paradigm, the certificate could contain personably identifiable information that has absolutely nothing at all to do with the subject transaction. There could be one or more relying-parties that had interest in authenticating the digital signature. Under various legislative and/or regulatory constraints it might be possible that some relying-parties would not be permitted access to the certificate because of privacy constraints. Such privacy constraints might also impose restrictions on how the certificate was transmitted and/or handled. Arshad Noor wrote: I do not believe identity theft will ever be eradicated regardless of the number of certs. However, if we assume that identity certs are useful, then there is some optimal number that balances the risk against the inconvenience of carrying too many credentials. In the absence of objective research recommending the precise number, or range, the identity firewalls concept advances one figure. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i38Ck4pk077427; Thu, 8 Apr 2004 05:46:04 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i38Ck4oJ077426; Thu, 8 Apr 2004 05:46:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mongo.corestreet.com (mongo.corestreet.com [68.162.232.130]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i38Ck3Zx077417 for <ietf-pkix@imc.org>; Thu, 8 Apr 2004 05:46:04 -0700 (PDT) (envelope-from dengberg@corestreet.com) X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Signing Untrusted SCVP? Date: Thu, 8 Apr 2004 08:45:15 -0400 Message-ID: <DE909E05406F3340B186DA5A410B05F642A41A@mongo.corestreet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Signing Untrusted SCVP? Thread-Index: AcQdYVtQJtk1CaBQQXyO/lvz935V8QABP2vA From: "Dave Engberg" <dengberg@corestreet.com> To: "Santosh Chokhani" <chokhani@orionsec.com>, <ietf-pkix@imc.org> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i38Ck4Zx077421 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> If an SCVP client were implemented to use Microsoft's unpatched ASN.1 parsing library for all aspects of the protocol, then I think the attack could also be used even if the responses are signed (e.g. I could encode a bad 'version' for the SignedData or SignerInfo). If a client were written to use a different parsing library for all ASN.1, this would not be a problem. The only scenario where this would be relevant to the signed/unsigned question is if requests were processed by a non-broken non-Microsoft ASN.1 library, but then the raw certificate bytes were handed to the unpatched Microsoft DLL for parsing. -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Santosh Chokhani Sent: Thursday, April 08, 2004 7:36 AM To: ietf-pkix@imc.org Subject: RE: Signing Untrusted SCVP? I do see some benefit to the signature in light of the current ASN.1 vulnerability. This will help the clients that have not applied the patch. I have not done an analysis of the vulnerability to determine if the attacker could manipulate the signed payload to exploit the ASN.1 bug in the client. I suspect so. While LDAP is not PKIX, directory world will continue to be vulnerable to that. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i38C32bS074179; Thu, 8 Apr 2004 05:03:02 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i38C32KI074178; Thu, 8 Apr 2004 05:03:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i38C32Cp074168 for <ietf-pkix@imc.org>; Thu, 8 Apr 2004 05:03:02 -0700 (PDT) (envelope-from dengberg@corestreet.com) Received: from localhost (h005008001124.ne.client2.attbi.com[66.31.43.88]) by comcast.net (rwcrmhc11) with ESMTP id <2004040812025801300sop9pe>; Thu, 8 Apr 2004 12:02:58 +0000 Received: from localhost ([127.0.0.1] helo=corestreet.com ident=dave) by localhost with esmtp (Exim 3.35 #1 (Debian)) id 1BBYGn-0008Qt-00; Thu, 08 Apr 2004 08:04:33 -0400 Message-ID: <40753FD0.4020206@corestreet.com> Date: Thu, 08 Apr 2004 08:04:32 -0400 From: David Engberg <dengberg@corestreet.com> Organization: CoreStreet User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Trevor Freeman <trevorf@windows.microsoft.com> CC: Santosh Chokhani <chokhani@orionsec.com>, ietf-pkix@imc.org Subject: Re: Signing Untrusted SCVP? References: <340B5AC242DEF44AAFCD6DC102B51CD30595EDC3@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <340B5AC242DEF44AAFCD6DC102B51CD30595EDC3@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> There are a large number of protocols (S/MIME, SSL/TLS) that send clients an unsigned bag of certificates for path discovery. The reason some of us feel that the "garbage path" client attack is of minor impact is because: * Effort is medium * Payoff is low: a few (or even a few dozen) RSA-2048 verifies on the client. I don't believe any client will launch a web browser during a path validation attempt, particularly for manufactured certs that don't chain to a client's trusted root (since validation goes from the root down). * The attack is immediately detected by the client as a major problem to be remedied I agree that no client should ever be forced to receive unsigned DPD responses, and no server should ever be forced to send unsigned DPD responses, but if both the client and the server are willing, I argue that unsigned should be possible. Trevor Freeman wrote: > I think it is that bad. An attacker is giving you a response which is of > a content total their making which one would assume the client would > pass to its own chaining engine who then acts upon it. The simple act of > trying to validate the bag of carefully crafted certificates at the very > minimal send some unsuspecting client to the attacker web page. With a > signed response, if the client explicitly trust the signer, the attacker > can invalidate the signature or insert an error, but that is about it. > The client does not take the response at attempt some action upon it. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i38BijDV073076; Thu, 8 Apr 2004 04:44:45 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i38Biimu073075; Thu, 8 Apr 2004 04:44:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i38BiiAL073067 for <ietf-pkix@imc.org>; Thu, 8 Apr 2004 04:44:44 -0700 (PDT) (envelope-from dengberg@corestreet.com) Received: from localhost (h005008001124.ne.client2.attbi.com[66.31.43.88]) by comcast.net (rwcrmhc11) with ESMTP id <2004040811444001300su7g4e>; Thu, 8 Apr 2004 11:44:41 +0000 Received: from localhost ([127.0.0.1] helo=corestreet.com ident=dave) by localhost with esmtp (Exim 3.35 #1 (Debian)) id 1BBXz5-0008QP-00; Thu, 08 Apr 2004 07:46:15 -0400 Message-ID: <40753B86.2090104@corestreet.com> Date: Thu, 08 Apr 2004 07:46:14 -0400 From: David Engberg <dengberg@corestreet.com> Organization: CoreStreet User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Trevor Freeman <trevorf@windows.microsoft.com> CC: Michael Myers <mmyers@fastq.com>, ietf-pkix@imc.org Subject: Re: SCVP Change Proposal (was: Signing Untrusted SCVP?) References: <340B5AC242DEF44AAFCD6DC102B51CD30595EDC9@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <340B5AC242DEF44AAFCD6DC102B51CD30595EDC9@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Mike's right that my proposal was to allow unsigned responses for pure DPD (see my proposed change to Section 3, below), and also to permit caching for responses by making the RequestReference optional (Section 4). Trevor Freeman wrote: > The proposal is allowing cached responses and the presence or absence of > the nonce indicates to the server if cached signed responses are > acceptable. > Trevor > > -----Original Message----- > From: Michael Myers [mailto:mmyers@fastq.com] > Sent: Wednesday, April 07, 2004 4:09 PM > To: Trevor Freeman; Dave Engberg; Santosh Chokhani; ietf-pkix@imc.org > Subject: RE: SCVP Change Proposal (was: Signing Untrusted SCVP?) > > Dave asked about signing DPD responses. Why are we talking > about nonces? > > Mike > > > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org > [mailto:owner-ietf-pkix@mail.imc.org] > On Behalf Of Dave Engberg > Sent: Wednesday, April 07, 2004 9:11 AM > To: Santosh Chokhani; ietf-pkix@imc.org > Subject: SCVP Change Proposal (was: Signing Untrusted SCVP?) > > > In Section 3, replace: > > If a > server is responding to an unsigned request or a signed > request, it > MUST use a signed response or an unsigned error response. > > With: > > If a server is responding to an unsigned request or a signed > request, > it MUST use a signed response or an unsigned error response if > either > of the following is true: > > - The request wantBack includes one or more of the > following: > > * id-swb-pkc-public-key-info > * id-swb-pkc-cert-status > * id-swb-ac-cert-status > > - The request includes a requestNonce > > If neither is true, a server responding to an unsigned request > or > signed request MAY use a signed response, an unsigned > response, or > an unsigned error response. > > > In Section 4, replace: > > requestRef RequestReference, > > With: > > requestRef [0] RequestReference OPTIONAL, > > In Section 4.5, replace: > > The requestRef allows the SCVP server to identify the request > that > > With: > > The OPTIONAL requestRef item allows the SCVP server to > identify > the request that ... Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i38BdUnh072746; Thu, 8 Apr 2004 04:39:30 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i38BdUMD072745; Thu, 8 Apr 2004 04:39:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i38BdTYx072738 for <ietf-pkix@imc.org>; Thu, 8 Apr 2004 04:39:30 -0700 (PDT) (envelope-from chokhani@orionsec.com) Received: from wchokhani3 (dpvc-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i38BdVAt030516 for <ietf-pkix@imc.org>; Thu, 8 Apr 2004 07:39:31 -0400 From: "Santosh Chokhani" <chokhani@orionsec.com> To: <ietf-pkix@imc.org> Subject: RE: Signing Untrusted SCVP? Date: Thu, 8 Apr 2004 07:39:31 -0400 Message-ID: <006001c41d5e$28572e70$9a00a8c0@hq.orionsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <EOEGJNFMMIBDKGFONJJDOENEDMAA.mmyers@fastq.com> Importance: Normal Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> I agree -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Michael Myers Sent: Wednesday, April 07, 2004 4:14 PM To: ietf-pkix@imc.org Subject: RE: Signing Untrusted SCVP? I think we should just change the relevant MUSTs to "MUST be capable of". Mike Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i38BcQgq072472; Thu, 8 Apr 2004 04:38:26 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i38BcQPs072471; Thu, 8 Apr 2004 04:38:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i38BcPCH072464 for <ietf-pkix@imc.org>; Thu, 8 Apr 2004 04:38:26 -0700 (PDT) (envelope-from chokhani@orionsec.com) Received: from wchokhani3 (dpvc-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i38BcMAt030329 for <ietf-pkix@imc.org>; Thu, 8 Apr 2004 07:38:22 -0400 From: "Santosh Chokhani" <chokhani@orionsec.com> To: <ietf-pkix@imc.org> Subject: RE: Signing Untrusted SCVP? Date: Thu, 8 Apr 2004 07:38:22 -0400 Message-ID: <005f01c41d5d$ff6771f0$9a00a8c0@hq.orionsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <340B5AC242DEF44AAFCD6DC102B51CD30595EA95@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i38BcQCH072466 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Trevor: I would say more the server since the client can always ignore the signature if it wishes and reject an unsigned response. -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Trevor Freeman Sent: Wednesday, April 07, 2004 5:52 PM To: Santosh Chokhani; ietf-pkix@imc.org Subject: RE: Signing Untrusted SCVP? Hi Santosh, I don't view the benefit as minimal. I see it as blocking some exploits by attackers. Given we are now allowing cached values to be returned, what is the concern? Are we trying to help the server or client? Trevor -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Santosh Chokhani Sent: Wednesday, April 07, 2004 12:34 PM To: ietf-pkix@imc.org Subject: RE: Signing Untrusted SCVP? Trevor: >From technical philosophy viewpoint, I do not have a problem. But, from my understanding of how IETF works, given that the benefit is minimal, we need to define the standard that accommodates products with varying degree of functionality. I think SCVP requirement to sign DPD responses may be too much. -----Original Message----- From: Trevor Freeman [mailto:trevorf@windows.microsoft.com] Sent: Wednesday, April 07, 2004 2:07 PM To: Santosh Chokhani; ietf-pkix@imc.org Subject: RE: Signing Untrusted SCVP? Hi Santosh, My argument cannot be construed as an argument to sign everything. It is an argument to sign all positive responses. I am equally not convinced that no singing achieves anything other than weaker security. The act of signing is not a major burden, especially if this is no longer on a per request basis and allows the client to be assured of positive. Not signing positive responses allows an attacker to manipulate the client beyond inserting errors which is very, very bad. How the server protects the cache is an implementation decision. Assuming untrusted transport is reasonable for the RFC. Trevor -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Santosh Chokhani Sent: Wednesday, April 07, 2004 9:00 AM To: ietf-pkix@imc.org Subject: RE: Signing Untrusted SCVP? Trevor: This argument can be the basis for signing everything all the time, which we do not do. The attacker can still manipulate and inject data. I am not persuaded by the argument that checking the signature first will save lot of client processing time. If the product developer and consumers want to have the option for not signing this data, they should. I see a bigger problem with the DPD server maintaining a cache and some one attacking that cache (if unsigned) since a stationary server may be easier to hack at then data in transit. Now, if the DPD server signed cached paths on request or if the DPD, you have the same problem. Also, my suggestion would be for the client to have the option of requesting signed responses and having the option of rejecting responses that are not signed. -----Original Message----- From: Trevor Freeman [mailto:trevorf@windows.microsoft.com] Sent: Wednesday, April 07, 2004 11:46 AM To: Santosh Chokhani; ietf-pkix@imc.org Subject: RE: Signing Untrusted SCVP? I think there is significant value in signing the response from the SCVP server. Given the main issue seems to be SCVP operating in an environment where an attacker has the ability to inject packets going between client and server into the data stream. Signing the response relegates the attacker to injecting error packets - which is a low grade DoS. Sending unsigned responses allows the attacker to inject a packed as the server whatever they want as a genuine response, with certificates and content of there choosing. So we just turned every SCVP client into a potential web beacon. Where the client has direct trust in the server signing key this is a very secure process with DPD. Trevor -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Santosh Chokhani Sent: Wednesday, April 07, 2004 5:32 AM To: ietf-pkix@imc.org Subject: RE: Signing Untrusted SCVP? Given the limited value of signature, DPD response signature by the server should be optional and signature verification by the client should be optional. The question we should answer is that is there any benefit to adding an option for the client to request a signature and then should the DPD server be forced to sign the response (shades of OCSP nonce) -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of David Engberg Sent: Tuesday, April 06, 2004 11:32 PM To: Stephen Kent Cc: ietf-pkix@imc.org Subject: Re: Signing Untrusted SCVP? Stephen - You have provided interesting techniques that an attacker could use to make a DPD client waste an extra 500ms verifying signatures before displaying a "bad path returned from server" dialog (or the equivalent). That same attacker with the same advantages (DNS spoofing, etc.) could achieve the same effective denial of path discovery even if an extra signature is thrown on responses. The attacker could obviously make clients waste time & bandwidth in lots of sneaky ways, although the relying application would ultimately report different error messages ("unknown host: 'scvp.eubridge.org'", "connection timed out", "no route to host", "response signature verify failed", etc.). I am curious whether the type of attack that you describe has ever been performed against a non-SSL LDAP directory in a manner that would not have been equally effective if SSL was in use. While there is definitely a difference here, I think (hope?) that we agree that it may be useful for a PKI administrator to have the choice to deploy a path discovery mechanism which does not require a fresh signature from a protected server key for every request. This would allow an administrator to balance the DoS risks for clients against the DoS risks for servers. My guess is that virtually all real world DoS attacks exploit the centralized nature of secured servers, and the best cure for this is the sort of distributed redundancy that a keyless or two-tier-caching DPD responder architecture would permit. For example, Akamai has 16,000+ servers around the world with no SSL private keys. They are subjected to daily DoS attempts (e.g. they host www.whitehouse.gov), which fail not due to the magic of PKI, but rather due to the redundancy you can build when you don't have to secure keys at every server. Thanks Stephen Kent wrote: ... > if an attacker can spoof a DNS response, he can cause the client to > connect to him instead of the server, which would enable the bogus > server to receive the request as well as generate and send the > response, and in the absence of a signed response, the client cannot > know that he is not communicating with the intended server. > > a bogus server could then return bogus cert chains that fail to > validate, but which waste client resources. just how effective this > may be will be a function of client implementation details, which are > outside the scope of our standards. ... Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i38BaNTg072374; Thu, 8 Apr 2004 04:36:23 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i38BaNe0072373; Thu, 8 Apr 2004 04:36:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i38BaMIG072367 for <ietf-pkix@imc.org>; Thu, 8 Apr 2004 04:36:22 -0700 (PDT) (envelope-from chokhani@orionsec.com) Received: from wchokhani3 (dpvc-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i38BaNAt030066 for <ietf-pkix@imc.org>; Thu, 8 Apr 2004 07:36:23 -0400 From: "Santosh Chokhani" <chokhani@orionsec.com> To: <ietf-pkix@imc.org> Subject: RE: Signing Untrusted SCVP? Date: Thu, 8 Apr 2004 07:36:23 -0400 Message-ID: <005e01c41d5d$b8a23a20$9a00a8c0@hq.orionsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <340B5AC242DEF44AAFCD6DC102B51CD30595EDC3@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i38BaMIG072368 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> I do see some benefit to the signature in light of the current ASN.1 vulnerability. This will help the clients that have not applied the patch. I have not done an analysis of the vulnerability to determine if the attacker could manipulate the signed payload to exploit the ASN.1 bug in the client. I suspect so. While LDAP is not PKIX, directory world will continue to be vulnerable to that. -----Original Message----- From: Trevor Freeman [mailto:trevorf@windows.microsoft.com] Sent: Wednesday, April 07, 2004 8:32 PM To: Dave Engberg; Santosh Chokhani; ietf-pkix@imc.org Subject: RE: Signing Untrusted SCVP? Hi Dave, I think it is that bad. An attacker is giving you a response which is of a content total their making which one would assume the client would pass to its own chaining engine who then acts upon it. The simple act of trying to validate the bag of carefully crafted certificates at the very minimal send some unsuspecting client to the attacker web page. With a signed response, if the client explicitly trust the signer, the attacker can invalidate the signature or insert an error, but that is about it. The client does not take the response at attempt some action upon it. Trevor -----Original Message----- From: Dave Engberg [mailto:dengberg@corestreet.com] Sent: Wednesday, April 07, 2004 1:23 PM To: Trevor Freeman; Santosh Chokhani; ietf-pkix@imc.org Subject: RE: Signing Untrusted SCVP? I think that "very, very bad" might be a bit strong. Steve pointed out that an attacker could use unsigned responses to waste client CPU resources before the client rejects an unsigned DPD response, and possibly to lead a smart client to "hot list" the bad server. Even with signed responses, an attacker could achieve the same end result (or worse) through all of the normal bad-guy means. For example, spoofed DNS could send clients to bad IP addresses (30 second timeout while MS Outlook hangs ...) or servers that faked flaky TCP packets for infinite exponential backoff, etc. Steve's right that a signature might allow a very clever client to mitigate a very specific type of time-wasting client DoS, but obviously an attacker who can seize your networking or DNS can cause a DoS regardless of whether the responses are signed. "Very, very bad" would apply if an attacker could trick a non-buggy client into accepting a cert for which there is no valid path. This is absolutly not possible with unsigned DPD lookups (or non-SSL LDAP), although it definitely is a risk for "Trusted SCVP" if any server is compromised. -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Trevor Freeman Sent: Wednesday, April 07, 2004 2:07 PM To: Santosh Chokhani; ietf-pkix@imc.org Subject: RE: Signing Untrusted SCVP? Hi Santosh, My argument cannot be construed as an argument to sign everything. It is an argument to sign all positive responses. I am equally not convinced that no singing achieves anything other than weaker security. The act of signing is not a major burden, especially if this is no longer on a per request basis and allows the client to be assured of positive. Not signing positive responses allows an attacker to manipulate the client beyond inserting errors which is very, very bad. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i38A5SnB063698; Thu, 8 Apr 2004 03:05:28 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i38A5SaH063697; Thu, 8 Apr 2004 03:05:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mallaury.noc.nerim.net (smtp-104-thursday.noc.nerim.net [62.4.17.104]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i38A5RX4063691 for <ietf-pkix@imc.org>; Thu, 8 Apr 2004 03:05:27 -0700 (PDT) (envelope-from julien.stern@cryptolog.com) Received: from jupiter.cry.pto (cryptolog.net1.nerim.net [80.65.224.225]) by mallaury.noc.nerim.net (Postfix) with ESMTP id C293262E0B for <ietf-pkix@imc.org>; Thu, 8 Apr 2004 12:05:21 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by jupiter.cry.pto (Postfix) with ESMTP id AF08D4197 for <ietf-pkix@imc.org>; Thu, 8 Apr 2004 12:05:21 +0200 (CEST) Received: from jupiter.cry.pto ([127.0.0.1]) by localhost (jupiter [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 23974-06 for <ietf-pkix@imc.org>; Thu, 8 Apr 2004 12:05:21 +0200 (CEST) Received: from callisto.cry.pto (callisto.cry.pto [10.0.1.4]) by jupiter.cry.pto (Postfix) with SMTP id 85DBD4193 for <ietf-pkix@imc.org>; Thu, 8 Apr 2004 12:05:21 +0200 (CEST) Received: by callisto.cry.pto (sSMTP sendmail emulation); Thu, 8 Apr 2004 12:05:21 +0200 From: "Julien Stern" <julien.stern@cryptolog.com> Date: Thu, 8 Apr 2004 12:05:21 +0200 To: ietf-pkix@imc.org Subject: Re: Current status of CRL validation ? Message-ID: <20040408100521.GA6307@cryptolog.com> References: <20040407163512.GA1250@cryptolog.com> <018c01c41cdb$48899c10$9a00a8c0@hq.orionsec.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <018c01c41cdb$48899c10$9a00a8c0@hq.orionsec.com> User-Agent: Mutt/1.5.5.1+cvs20040105i X-Virus-Scanned: by amavisd-new-20030314-p2 (Debian) at cryptolog.com Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> On Wed, Apr 07, 2004 at 04:02:41PM -0400, Santosh Chokhani wrote: > > Julien: > > (snip) > > It is also not clear what your thesis or agenda is. > May be you are still trying understand it. If you are challenging the > rules we have proposed for CRL path, let me know. I am quite honestly still trying to understand. We have a validation algorithm with policy mappings and CRL/Indirect CRL/OCSP support. The simple case (one cert -> one chain) is trivial. We are interested in cases where one can potentially reconstructs many chains for the certificate and for the CRL/OCSP response. When I can actually build at least one chain to a TA to verify the certificate, the revocation status of the certificate can be: - UNREVOKED - REVOKED (with reason) - UNTERMINED When there is only one revocation source, obviously, different implementations cannot give UNREVOKED on one hand and REVOKED on the other, but they could possibly give, say, either REVOKED or UNTERMINED depending on how they implement verifications. That seems OK: a "smart" verification algorithm will get the answer, a "simpler" one will just indicate it did not find it. Now, my understanding of RFC3280 is that several entities could potentially indicate that a given certificate is revoked, using, say, Indirect CRLs. In this case, am I supposed to assume they are all in sync ? That the first one checked is authoritative ? That I have to check them all ? My MAJOR problem in this case, is that our current algorithm can give either REVOKED or UNREVOKED depending on: - Initial Trust Anchors - Policy mappings - Even implementations details like path building order or Extension processing order To be specific, I though one could want to have many "Local CAs" issuing their own CRLs, plus a CRLDP to the CRL of a common "Revocation Center" which is authorized to process revocations for all the Local CAs. So maybe this case is just stupid, or even forbidden, but if not, I have a serious soundness problem in my current verification algorithm ;) Sincerely, -- Julien Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i388gocd046288; Thu, 8 Apr 2004 01:42:50 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i388goTE046287; Thu, 8 Apr 2004 01:42:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from postman-pat.actimage.fr (postman-pat.actimage.net [80.87.224.5]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i388gmW7046240 for <ietf-pkix@imc.org>; Thu, 8 Apr 2004 01:42:49 -0700 (PDT) (envelope-from muriel@actimage.net) Received: from leila (inet-gate3 [80.87.224.93]) by postman-pat.actimage.fr (8.11.4/8.11.4) with SMTP id i388doK18554 for <ietf-pkix@imc.org>; Thu, 8 Apr 2004 10:39:50 +0200 (CEST) Message-ID: <161601c41d45$a33fc1b0$4406a8c0@leila> From: "Muriel Souville" <muriel@actimage.net> To: "'Ietf-Pkix@Imc. Org'" <ietf-pkix@imc.org> Subject: ETSI Interoperability Event Date: Thu, 8 Apr 2004 10:43:59 +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 Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Dear all, As you probably know, The European Telecommunications Standards Institute (ETSI) is organising an interoperability event in the field of security. We already have many participants working on PKIs and XadES. But some of them are also interested in testing IKEv2, that's why we are searching new actors working on this field. I remind you that the deadline is the 5th of May. If you are interested in, please contact us at interop@actimage.net or just take a look at http://www.etsi.org/plugtests/security.htm Thanks for your attention. Best regards, Muriel SOUVILLE ETSI Consultant ----------------------------- +33 3 90 23 63 63 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i384Yk2l063759; Wed, 7 Apr 2004 21:34:46 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i384Ykkd063758; Wed, 7 Apr 2004 21:34:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from igw (adsl-63-194-79-229.dsl.snfc21.pacbell.net [63.194.79.229]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i384Yj0g063746 for <ietf-pkix@imc.org>; Wed, 7 Apr 2004 21:34:46 -0700 (PDT) (envelope-from arshad.noor@strongauth.com) Received: from strongauth.com (athena.noorhome.net [192.168.0.10]) by igw.noorhome.net (iPlanet Messaging Server 5.2 Patch 1 (built Aug 19 2002)) with ESMTP id <0HVU00K9T3YG3D@igw.noorhome.net> for ietf-pkix@imc.org; Wed, 07 Apr 2004 21:18:16 -0700 (PDT) Date: Wed, 07 Apr 2004 21:34:46 -0700 From: Arshad Noor <arshad.noor@strongauth.com> Subject: Re: PKI International Consortium In-reply-to: <p06020403bc99b5e1231c@[128.89.89.75]> To: Stephen Kent <kent@bbn.com> Cc: PKIX list <ietf-pkix@imc.org> Message-id: <4074D666.3090002@strongauth.com> Organization: StrongAuth, Inc. MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_wkuYifgQq9RZoSdtOU7r/w)" X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) References: <428a370f.370f428a@noorhome.net> <p06020403bc97150f71da@[128.89.89.75]> <40724DEC.3060007@strongauth.com> <p06020404bc985cf94cad@[128.89.89.75]> <4073866D.4090507@strongauth.com> <p06020403bc99b5e1231c@[128.89.89.75]> Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> This is a multi-part message in MIME format. --Boundary_(ID_wkuYifgQq9RZoSdtOU7r/w) Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT Stephen Kent wrote: > At 9:41 PM -0700 4/6/04, Arshad Noor wrote: > >> Taken to its logical conclusion, an infinite number of >> credentials per entity must lead to minimal impact of an >> identity theft incident. However, humans cannot be expected to >> deal with such mathematical elegance without becoming blithering >> idiots. (Some of us just need a few Internet accounts to reach >> that state :-)). >> >> Therefore, there must be some optimal number between 1 and >> infinity that balances risk vs. the inconvenience of carrying >> mulitple credentials. Once again, for lack of empirical >> evidence, the identity firewall concept advances seven as the >> optimal number. > > this is silly, almost to the point of being absurd. "Seven" as the > optimal number sounds practically mystical. > Anything fantastic appears mystical and absurd if the logic behind it is not evident. Here's the rationale: Most people in industrialized nations will deal with companies, or agencies, in one or more of the following industries, at some point in their lives: 1) Healthcare - at birth, immunizations, medicines, etc.; 2) Education - for schools, colleges, professional associations; 3) Financial - for banks, brokerages, credit unions, etc. 4) Government - for taxes, permits, licenses, passport; 5) Employer 6) Retail/E-commerce - buy books, air tickets, flowers, etc. 7) Miscellaneous & personal uses - Sign e-mails to attorney, or receive encrypted e-mails from accountant, etc. By demarcating credential use strictly along industry lines, one allows each industry to come up with whatever issuance process that will serve their industry, for any legal purpose within that industry, without affecting any other industry. People may wind up with more or less credentials than seven. An attorney, working for herself may choose never to have an Employer credential; and not liking the whole e-commerce experience she never buys anything on the Internet. She may well have only 5 credentials. As a parts supplier to a major auto manufacturer, I may be given access to their Supply-Chain portal through a Partner credential, perhaps taking my number of credentials to eight. If I supply to 5 auto manufacturers and all of them issue me credentials, I will wind up with 12 credentials. At a macro level, the average will wind up being around seven, based on the usage pattern enumerated above. >> >>> That is also why one ought not assume that use of >>> certs, as a specific form of credential, will eradicate identity theft. >>> >> To paraphrase you, Steve, "My comment said nothing about >> eradicating identity theft." (I do not believe it can ever be >> eradicated - just made difficult enough to deter most people.) > > > This paragraph makes no sense. Your previous message explicitly talked > about eradicating identity theft, yet you are backtracking here. > My first posting to the list (see attached) clearly stated that "I do not believe identity theft will ever be eradicated regardless of the number of certs.". > > I too am in favor of the use of certs with private keys maintained in > hardware tokens and a high assurance issuing process, when the resources > being accessed warrant such measures. But, "optimal" is an inappropriate > term when we have such a wide range of resources that people access. > Therein lies the fallacy of PKI - or any other authentication technology - today: implied authorization to use of resources based on the authentication credential! To me, the use of certs with private keys in hardware tokens and a high assurance process is good enough only to IDENTIFY the presenter of the credential. I will still want to go through whatever number of business rules I choose, to determine whether the identified entity has the authorization to use the resource. I use the word "optimal" only to refer to the number of credentials needed to identify an entity across many industries; the term would be highly inappropriate when used in reference to authorizations. I would expect an infinite number of rules to exist in the business world, to accomodate for authorization policies that govern how a wide range of resources are used. Arshad Noor StrongAuth, Inc. --Boundary_(ID_wkuYifgQq9RZoSdtOU7r/w) Content-type: message/rfc822; name="Attached Message" Date: Mon, 05 Apr 2004 23:27:56 -0700 From: Arshad Noor <arshad.noor@strongauth.com> Subject: Re: PKI International Consortium In-reply-to: <p06020403bc97150f71da@[128.89.89.75]> To: Stephen Kent <kent@bbn.com> Cc: PKIX list <ietf-pkix@imc.org> Message-id: <40724DEC.3060007@strongauth.com> Organization: StrongAuth, Inc. MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) References: <428a370f.370f428a@noorhome.net> <p06020403bc97150f71da@[128.89.89.75]> Stephen Kent wrote: > two observations: > - the implicit ad for your company in the URL above is inappropriate > for the PKIX list If so, I apologize. This is the only archived copy of the newsletter, and it seemed appropriate to provide the URL to the article rather than repeat the concept. However, I will be more cognizant of that in the future. > - although one might imagine such certs, there are significant > adverse privacy implications (see > http://www.nap.edu/books/0309088968/html/) I will address this after I have had an opportunity to read the book. > > identity theft would likely be a bigger concern if we have fewer certs. > I do not believe identity theft will ever be eradicated regardless of the number of certs. However, if we assume that identity certs are useful, then there is some optimal number that balances the risk against the inconvenience of carrying too many credentials. In the absence of objective research recommending the precise number, or range, the identity firewalls concept advances one figure. > finally, I am concerned that your message seems to be so closely aligned > with you company's products. if you want to continue this discussion, > please do so without making it seem like an ad for your company's > products and services. > The message expressed a concept for how digital certificates can be used to solve some problems in a different way, Steve. No more, no less. Arshad Noor StrongAuth, Inc. --Boundary_(ID_wkuYifgQq9RZoSdtOU7r/w)-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i383eZ40061383; Wed, 7 Apr 2004 20:40:35 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i383eZnK061382; Wed, 7 Apr 2004 20:40:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from igw (adsl-63-194-79-229.dsl.snfc21.pacbell.net [63.194.79.229]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i383eYuv061376 for <ietf-pkix@imc.org>; Wed, 7 Apr 2004 20:40:35 -0700 (PDT) (envelope-from arshad.noor@strongauth.com) Received: from strongauth.com (athena.noorhome.net [192.168.0.10]) by igw.noorhome.net (iPlanet Messaging Server 5.2 Patch 1 (built Aug 19 2002)) with ESMTP id <0HVU00K831G53D@igw.noorhome.net> for ietf-pkix@imc.org; Wed, 07 Apr 2004 20:24:05 -0700 (PDT) Date: Wed, 07 Apr 2004 20:40:35 -0700 From: Arshad Noor <arshad.noor@strongauth.com> Subject: Re: Identity Firewall. Was: PKI International Consortium In-reply-to: <006701c41c7b$2f013560$0500a8c0@arport> To: Anders Rundgren <anders.rundgren@telia.com> Cc: PKIX list <ietf-pkix@imc.org> Message-id: <4074C9B3.7060303@strongauth.com> Organization: StrongAuth, Inc. MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) References: <200404031056.MAA21125@sol10.lcc.uma.es> <40739294.9050705@strongauth.com> <006701c41c7b$2f013560$0500a8c0@arport> Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Anders Rundgren wrote: > Arshad, > > >>So, one could get oneself a Financial industry credential, for >>instance, by going through the industry's issuance process, and >>yet not have a single bank/brokerage account at all (not very >>useful, I realize - nonetheless that is the premise). > > > Absolutely, this is BTW already a reality in Scandinavia. > If there are any pointers to websites that describe how Scandinavia implements this, Anders, I'd appreciate it. Thank you. > >>This individual, armed with the Financial credential, can now >>approach any financial institution that honored the credential, >>and open an account. However, depending on the context of the >>account & the transactions the individual may wish to carry out >>against that account, the financial institution may want to >>determine a number of attributes about that individual before >>granting him/her that privilege. > > > I would extend this to include *any* relying party that is prepared > to trust FI-issued credentials. e-governments are the first to make > use of this. > I would specifically NOT, Anders. Here's why. One of the biggest reasons why identity theft is so prevalent today, is because of the inappropriate use of identity data for secondary uses. If a specific industry credential were restricted by policy and contract, to only companies within that industry, the consequences of a compromised credential is restricted to only uses within that industry. Thus, if a FI credential was compromised, only the holders banking, brokerage, insurance uses might get affected. The credential that identifies them to hospitals, doctors, pharmacies would not. Neither would the credential identifying them to schools, colleges & professional associations. Thus the term "Identity Firewall". Even though it is technically, as well as contractually, possible for cross-industry uses, by deliberately putting up protection barriers between industries, we prevent the domino-effect of the compromise of a credential. > The use of employment-style certificates outside of the company > border is never going to happen on a wider scale because that idea > is conceptually completely flawed. Well, an IBM company badge > may indeed give you 10% discount at Tony's Pizza, but that's about it. > In fact, it should not be allowed to happen. If an airline, a hotel or a store wished to give specific company employees a discount, let them rely on the Retail Industry credential, or issue their own certificate to be stored on the RI smartcard or other crypto token. The principle is the same - if we do not allow compromises to cross industry boundaries, then the damage is limited to only that industry. Arshad Noor StrongAuth, Inc. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i381wCOc054872; Wed, 7 Apr 2004 18:58:12 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i381wCUN054871; Wed, 7 Apr 2004 18:58:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i381wB1N054863 for <ietf-pkix@imc.org>; Wed, 7 Apr 2004 18:58:11 -0700 (PDT) (envelope-from trevorf@windows.microsoft.com) Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 7 Apr 2004 18:57:00 -0700 Received: from 157.54.6.197 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 07 Apr 2004 18:58:06 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by INET-HUB-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 7 Apr 2004 18:58:08 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 7 Apr 2004 18:58:02 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 7 Apr 2004 18:58:02 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7195.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: SCVP Change Proposal (was: Signing Untrusted SCVP?) Date: Wed, 7 Apr 2004 18:58:10 -0700 Message-ID: <340B5AC242DEF44AAFCD6DC102B51CD3059E82BE@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SCVP Change Proposal (was: Signing Untrusted SCVP?) thread-index: AcQdCI7QI0HkhQ7FREaBfq7lfC18dgAA3eAQ From: "Trevor Freeman" <trevorf@windows.microsoft.com> To: "Michael Myers" <mmyers@fastq.com>, "Dave Engberg" <dengberg@corestreet.com>, "Santosh Chokhani" <chokhani@orionsec.com>, <ietf-pkix@imc.org> X-OriginalArrivalTime: 08 Apr 2004 01:58:02.0330 (UTC) FILETIME=[ECD34BA0:01C41D0C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i381wB1N054866 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Mike A specific response is not a cahed response but one made to a specific request. I am not sold on the description so any suggestions may win a prize. Trevor -----Original Message----- From: Michael Myers [mailto:mmyers@fastq.com] Sent: Wednesday, April 07, 2004 6:31 PM To: Trevor Freeman; Dave Engberg; Santosh Chokhani; ietf-pkix@imc.org Subject: RE: SCVP Change Proposal (was: Signing Untrusted SCVP?) Trevor, Please define "specific response" as used below in the proposed amendment to section 3.5. Nowhere does this term appear in -13 of SCVP. Mike -----Original Message----- From: Trevor Freeman [mailto:trevorf@windows.microsoft.com] Sent: Wednesday, April 07, 2004 5:33 PM The proposal is allowing cached responses and the presence or absence of the nonce indicates to the server if cached signed responses are acceptable. Trevor -----Original Message----- From: Michael Myers [mailto:mmyers@fastq.com] Sent: Wednesday, April 07, 2004 4:09 PM Dave asked about signing DPD responses. Why are we talking about nonces? Mike -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org]On Behalf Of Trevor Freeman Sent: Wednesday, April 07, 2004 3:25 PM Hi Dave, That is almost the proposed change. The presence of the nonce will indicate the request for a unique response, and I have added a wantBack. 3.5 requestNonce The OPTIONAL requestNonce item contains a request identifier generated by the SCVP client. If the client includes a requestNonce value in the request, it is expressing a preference the SCVP server SHOULD return a specific response. If the server returns a specific response it MUST include the requestNonce from the request in the response, but MAY return a cached success response which MUST NOT have a requestNonce. If the client includes a requestNonce and also sets a wantBack of id-swb-unique-resp-required, the client is indicating that the SCVP server MUST return either a specific response including the requestNonce or an error. The client SHOULD include a requestNonce item in every request to prevent an attacker from acting as a man-in-the-middle by replaying old responses from the server. The requestNonce value SHOULD change with every request sent by the client. The client MUST NOT include the wantBack of id-swb-unique-resp-required without a requestNonce, and a server receiving such a request SHOULD return an invalidRequest error Trevor Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i381Tx28052600; Wed, 7 Apr 2004 18:29:59 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i381TxSl052599; Wed, 7 Apr 2004 18:29:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i381TxfW052593 for <ietf-pkix@imc.org>; Wed, 7 Apr 2004 18:29:59 -0700 (PDT) (envelope-from mmyers@fastq.com) Received: from MMyersLapTop ([65.39.77.135]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id i381Txw12682; Wed, 7 Apr 2004 18:29:59 -0700 (MST) (envelope-from mmyers@fastq.com) From: "Michael Myers" <mmyers@fastq.com> To: "Trevor Freeman" <trevorf@windows.microsoft.com>, "Dave Engberg" <dengberg@corestreet.com>, "Santosh Chokhani" <chokhani@orionsec.com>, <ietf-pkix@imc.org> Subject: RE: SCVP Change Proposal (was: Signing Untrusted SCVP?) Date: Wed, 7 Apr 2004 18:30:40 -0700 Message-ID: <EOEGJNFMMIBDKGFONJJDOENJDMAA.mmyers@fastq.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <340B5AC242DEF44AAFCD6DC102B51CD30595EDC9@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> Importance: Normal Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Trevor, Please define "specific response" as used below in the proposed amendment to section 3.5. Nowhere does this term appear in -13 of SCVP. Mike -----Original Message----- From: Trevor Freeman [mailto:trevorf@windows.microsoft.com] Sent: Wednesday, April 07, 2004 5:33 PM The proposal is allowing cached responses and the presence or absence of the nonce indicates to the server if cached signed responses are acceptable. Trevor -----Original Message----- From: Michael Myers [mailto:mmyers@fastq.com] Sent: Wednesday, April 07, 2004 4:09 PM Dave asked about signing DPD responses. Why are we talking about nonces? Mike -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org]On Behalf Of Trevor Freeman Sent: Wednesday, April 07, 2004 3:25 PM Hi Dave, That is almost the proposed change. The presence of the nonce will indicate the request for a unique response, and I have added a wantBack. 3.5 requestNonce The OPTIONAL requestNonce item contains a request identifier generated by the SCVP client. If the client includes a requestNonce value in the request, it is expressing a preference the SCVP server SHOULD return a specific response. If the server returns a specific response it MUST include the requestNonce from the request in the response, but MAY return a cached success response which MUST NOT have a requestNonce. If the client includes a requestNonce and also sets a wantBack of id-swb-unique-resp-required, the client is indicating that the SCVP server MUST return either a specific response including the requestNonce or an error. The client SHOULD include a requestNonce item in every request to prevent an attacker from acting as a man-in-the-middle by replaying old responses from the server. The requestNonce value SHOULD change with every request sent by the client. The client MUST NOT include the wantBack of id-swb-unique-resp-required without a requestNonce, and a server receiving such a request SHOULD return an invalidRequest error Trevor Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i380qi2i049116; Wed, 7 Apr 2004 17:52:44 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i380qiMn049114; Wed, 7 Apr 2004 17:52:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from [63.202.92.152] (adsl-63-202-92-152.dsl.snfc21.pacbell.net [63.202.92.152]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.8) with ESMTP id i380qgrF049103 for <ietf-pkix@imc.org>; Wed, 7 Apr 2004 17:52:42 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: <p06100449bc9a5282d4fa@[63.202.92.152]> Date: Wed, 7 Apr 2004 17:52:45 -0700 To: ietf-pkix@imc.org From: Paul Hoffman / VPNC <paul.hoffman@vpnc.org> Subject: New open-source freeware CA product for creating PKIX certs Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Greetings again. The VPN Consortium is happy to announce SimpleCA, an open-source freeware CA product based on Peter Gutmann's cryptlib engine. Full information, including source and pre-made binaries for Linux, FreeBSD, and Windows, can be found at <http://www.vpnc.org/SimpleCA/>. This is just version 1. We look forward to hearing suggestions about how to make future versions more useful. And, of course, bug reports are also welcome. --Paul Hoffman, Director --VPN Consortium Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i380h3xJ048592; Wed, 7 Apr 2004 17:43:03 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i380h3Ot048591; Wed, 7 Apr 2004 17:43:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from imo-d05.mx.aol.com (imo-d05.mx.aol.com [205.188.157.37]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i380h2t9048582 for <ietf-pkix@imc.org>; Wed, 7 Apr 2004 17:43:02 -0700 (PDT) (envelope-from Shadow@aol.com) Received: from Shadow@aol.com by imo-d05.mx.aol.com (mail_out_v37_r1.2.) id 3.1a8.21ea2d57 (15876); Wed, 7 Apr 2004 20:42:52 -0400 (EDT) Received: from [192.168.1.106] (sera-10-169-186-4.nscp.aoltw.net [10.169.186.4]) by air-id07.mx.aol.com (v98.19) with ESMTP id MAILINID73-3e044074a00428; Wed, 07 Apr 2004 20:42:51 -0500 Date: Wed, 7 Apr 2004 17:42:50 -0700 (PDT) From: "Bill Burns" <shadow@aol.com> Subject: Re: key uniqueness in a PKI To: "Stephen Kent" <kent@bbn.com> cc: "Miguel Rodriguez" <mars@seguridata.com>, ietf-pkix@imc.org In-Reply-To: <p0602041fbc9a16a5d145@[128.89.89.75]> Message-ID: <4074A00A.5070602@aol.com> References: <001601c41cb6$8a6f6bc0$a600a8c0@seguridata.com> <p0602041fbc9a16a5d145@[128.89.89.75]> X-Mailer: AOL Communicator (20031204N1X.1 Mac) Organization: America Online MIME-Version: 1.0 Content-Type: TEXT/HTML; CHARSET=us-ascii X-AOL-IP: 10.169.186.4 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <title></title> </head> <body> <font face="Tahoma,sans-serif"><font size="2"><span type="cite">Stephen Kent wrote on 4/7/04, 1:39 PM:</span> </font></font> <p><font face="Tahoma,sans-serif" size="2"></font></p> <blockquote type="cite" style="border-left: thin solid blue; padding-left: 10px; margin-left: 0pt;"><font face="Tahoma,sans-serif" size="2"></font> <div><font face="Tahoma,sans-serif" size="2">At 10:39 AM -0500 4/7/04, Miguel Rodriguez wrote:</font></div> <font face="Tahoma,sans-serif" size="2"></font> <blockquote type="cite" cite=""><font face="Arial" size="-1">Where can I find information on key pair uniqueness in a PKI? Is this issue discussed in an RFC?</font></blockquote> <font face="Tahoma,sans-serif" size="2"></font> <blockquote type="cite" cite=""><font face="Arial" size="-1">I will also appreciate comments on this issue, particularly when considering a PKI with several CAs.</font></blockquote> <font face="Tahoma,sans-serif" size="2"></font> <blockquote type="cite" cite=""><font face="Tahoma,sans-serif" size="2"> </font></blockquote> <font face="Tahoma,sans-serif" size="2"></font> <blockquote type="cite" cite=""><font face="Arial" size="-1">Thanks.</font></blockquote> <font face="Tahoma,sans-serif" size="2"></font> <blockquote type="cite" cite=""><font face="Tahoma,sans-serif" size="2"> </font></blockquote> <font face="Tahoma,sans-serif" size="2"></font> <blockquote type="cite" cite=""><font face="Arial" size="-1">Miguel A Rodriguez</font></blockquote> <font face="Tahoma,sans-serif" size="2"></font> <blockquote type="cite" cite=""><font face="Arial" size="-1">SeguriData</font></blockquote> <font face="Tahoma,sans-serif" size="2"></font> <blockquote type="cite" cite=""><font face="Arial" size="-1">Mexico</font></blockquote> <font face="Tahoma,sans-serif" size="2"></font> <div><font face="Tahoma,sans-serif" size="2"><br> </font></div> <font face="Tahoma,sans-serif" size="2"></font> <div><font face="Tahoma,sans-serif" size="2">there is no standards-based requirement that a CA verify that each cert request contain a unique public key, neither globally nor relative to the certs that the CA has perviously issued. A CA might choose to try to make checks relative to the certs it has issued, and for which it still has this info, but there is no requirement to do so in X.509 nor PKIX standards.</font></div> <font face="Tahoma,sans-serif" size="2"></font> <div><font face="Tahoma,sans-serif" size="2"><br> </font></div> <font face="Tahoma,sans-serif" size="2"></font> <div><font face="Tahoma,sans-serif" size="2">Steve</font></div> </blockquote> <font size="2"><font face="Tahoma,sans-serif"><br> </font></font><font face="Tahoma,sans-serif" size="2"><font size="2">FWIW, there's also a mention of this in the WebTrust for CA's documentation. It's not a "requirement" per se, but they seem to suggest that it's a good idea. Nevertheless, that's a pretty expensive operation to perform...especially as the Member base grows.<br> <br> bill</font></font><br> </body> </html> Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i380XRSr047858; Wed, 7 Apr 2004 17:33:27 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i380XRLW047857; Wed, 7 Apr 2004 17:33:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i380XR1G047846 for <ietf-pkix@imc.org>; Wed, 7 Apr 2004 17:33:27 -0700 (PDT) (envelope-from trevorf@windows.microsoft.com) Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Wed, 7 Apr 2004 17:33:27 -0700 Received: from 157.54.6.197 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 07 Apr 2004 17:33:24 -0700 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by INET-HUB-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 7 Apr 2004 17:33:24 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 7 Apr 2004 17:33:29 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 7 Apr 2004 17:33:41 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7195.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: SCVP Change Proposal (was: Signing Untrusted SCVP?) Date: Wed, 7 Apr 2004 17:33:25 -0700 Message-ID: <340B5AC242DEF44AAFCD6DC102B51CD30595EDC9@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SCVP Change Proposal (was: Signing Untrusted SCVP?) thread-index: AcQc90mjSGeYrF6/RFCpnlH6HEpX5AACZf8Q From: "Trevor Freeman" <trevorf@windows.microsoft.com> To: "Michael Myers" <mmyers@fastq.com>, "Dave Engberg" <dengberg@corestreet.com>, "Santosh Chokhani" <chokhani@orionsec.com>, <ietf-pkix@imc.org> X-OriginalArrivalTime: 08 Apr 2004 00:33:41.0548 (UTC) FILETIME=[245D3EC0:01C41D01] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i380XR1G047851 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> The proposal is allowing cached responses and the presence or absence of the nonce indicates to the server if cached signed responses are acceptable. Trevor -----Original Message----- From: Michael Myers [mailto:mmyers@fastq.com] Sent: Wednesday, April 07, 2004 4:09 PM To: Trevor Freeman; Dave Engberg; Santosh Chokhani; ietf-pkix@imc.org Subject: RE: SCVP Change Proposal (was: Signing Untrusted SCVP?) Dave asked about signing DPD responses. Why are we talking about nonces? Mike -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org]On Behalf Of Trevor Freeman Sent: Wednesday, April 07, 2004 3:25 PM To: Dave Engberg; Santosh Chokhani; ietf-pkix@imc.org Subject: RE: SCVP Change Proposal (was: Signing Untrusted SCVP?) Hi Dave, That is almost the proposed change. The presence of the nonce will indicate the request for a unique response, and I have added a wantBack. 3.5 requestNonce The OPTIONAL requestNonce item contains a request identifier generated by the SCVP client. If the client includes a requestNonce value in the request, it is expressing a preference the SCVP server SHOULD return a specific response. If the server returns a specific response it MUST include the requestNonce from the request in the response, but MAY return a cached success response which MUST NOT have a requestNonce. If the client includes a requestNonce and also sets a wantBack of id-swb-unique-resp-required, the client is indicating that the SCVP server MUST return either a specific response including the requestNonce or an error. The client SHOULD include a requestNonce item in every request to prevent an attacker from acting as a man-in-the-middle by replaying old responses from the server. The requestNonce value SHOULD change with every request sent by the client. The client MUST NOT include the wantBack of id-swb-unique-resp-required without a requestNonce, and a server receiving such a request SHOULD return an invalidRequest error Trevor -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Dave Engberg Sent: Wednesday, April 07, 2004 9:11 AM To: Santosh Chokhani; ietf-pkix@imc.org Subject: SCVP Change Proposal (was: Signing Untrusted SCVP?) Thanks, Santosh. Here's a specific list of changes to SCVP Draft 13 that would allow the use of signatures to be optional on pure DPD lookups, and permit server caching of signed responses when mutually acceptable by server and client security policies. Rather than defining a new request extension to signal a desire for a fresh signature, this proposal uses the request nonce. I assume there would be agreement that any client who sends a nonce would not want an unsigned or cached response in return, but I wouldn't have any problem with defining a separate new extension if that makes the intent more clear. The section 3 changes are separate from section 4, and either could be adopted independently. In Section 3, replace: If a server is responding to an unsigned request or a signed request, it MUST use a signed response or an unsigned error response. With: If a server is responding to an unsigned request or a signed request, it MUST use a signed response or an unsigned error response if either of the following is true: - The request wantBack includes one or more of the following: * id-swb-pkc-public-key-info * id-swb-pkc-cert-status * id-swb-ac-cert-status - The request includes a requestNonce If neither is true, a server responding to an unsigned request or signed request MAY use a signed response, an unsigned response, or an unsigned error response. In Section 4, replace: requestRef RequestReference, With: requestRef [0] RequestReference OPTIONAL, In Section 4.5, replace: The requestRef allows the SCVP server to identify the request that With: The OPTIONAL requestRef item allows the SCVP server to identify the request that ... -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Santosh Chokhani Sent: Wednesday, April 07, 2004 8:32 AM To: ietf-pkix@imc.org Subject: RE: Signing Untrusted SCVP? Given the limited value of signature, DPD response signature by the server should be optional and signature verification by the client should be optional. The question we should answer is that is there any benefit to adding an option for the client to request a signature and then should the DPD server be forced to sign the response Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i380VaS2047737; Wed, 7 Apr 2004 17:31:36 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i380VaQu047736; Wed, 7 Apr 2004 17:31:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i380VZtQ047728 for <ietf-pkix@imc.org>; Wed, 7 Apr 2004 17:31:35 -0700 (PDT) (envelope-from trevorf@windows.microsoft.com) Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Wed, 7 Apr 2004 17:31:35 -0700 Received: from 157.54.6.150 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 07 Apr 2004 17:31:32 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 7 Apr 2004 17:31:27 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 7 Apr 2004 17:31:36 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 7 Apr 2004 17:31:49 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7195.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Signing Untrusted SCVP? Date: Wed, 7 Apr 2004 17:31:33 -0700 Message-ID: <340B5AC242DEF44AAFCD6DC102B51CD30595EDC3@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Signing Untrusted SCVP? thread-index: AcQcwhcJ12iwHTU8ThSEyQZFN1H+MgABZn/AAAIqgmAAC6tJcA== From: "Trevor Freeman" <trevorf@windows.microsoft.com> To: "Dave Engberg" <dengberg@corestreet.com>, "Santosh Chokhani" <chokhani@orionsec.com>, <ietf-pkix@imc.org> X-OriginalArrivalTime: 08 Apr 2004 00:31:49.0381 (UTC) FILETIME=[E181EB50:01C41D00] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i380VZtQ047731 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Hi Dave, I think it is that bad. An attacker is giving you a response which is of a content total their making which one would assume the client would pass to its own chaining engine who then acts upon it. The simple act of trying to validate the bag of carefully crafted certificates at the very minimal send some unsuspecting client to the attacker web page. With a signed response, if the client explicitly trust the signer, the attacker can invalidate the signature or insert an error, but that is about it. The client does not take the response at attempt some action upon it. Trevor -----Original Message----- From: Dave Engberg [mailto:dengberg@corestreet.com] Sent: Wednesday, April 07, 2004 1:23 PM To: Trevor Freeman; Santosh Chokhani; ietf-pkix@imc.org Subject: RE: Signing Untrusted SCVP? I think that "very, very bad" might be a bit strong. Steve pointed out that an attacker could use unsigned responses to waste client CPU resources before the client rejects an unsigned DPD response, and possibly to lead a smart client to "hot list" the bad server. Even with signed responses, an attacker could achieve the same end result (or worse) through all of the normal bad-guy means. For example, spoofed DNS could send clients to bad IP addresses (30 second timeout while MS Outlook hangs ...) or servers that faked flaky TCP packets for infinite exponential backoff, etc. Steve's right that a signature might allow a very clever client to mitigate a very specific type of time-wasting client DoS, but obviously an attacker who can seize your networking or DNS can cause a DoS regardless of whether the responses are signed. "Very, very bad" would apply if an attacker could trick a non-buggy client into accepting a cert for which there is no valid path. This is absolutly not possible with unsigned DPD lookups (or non-SSL LDAP), although it definitely is a risk for "Trusted SCVP" if any server is compromised. -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Trevor Freeman Sent: Wednesday, April 07, 2004 2:07 PM To: Santosh Chokhani; ietf-pkix@imc.org Subject: RE: Signing Untrusted SCVP? Hi Santosh, My argument cannot be construed as an argument to sign everything. It is an argument to sign all positive responses. I am equally not convinced that no singing achieves anything other than weaker security. The act of signing is not a major burden, especially if this is no longer on a per request basis and allows the client to be assured of positive. Not signing positive responses allows an attacker to manipulate the client beyond inserting errors which is very, very bad. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37N8Ne3041432; Wed, 7 Apr 2004 16:08:23 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i37N8Nww041431; Wed, 7 Apr 2004 16:08:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37N8M6h041423 for <ietf-pkix@imc.org>; Wed, 7 Apr 2004 16:08:22 -0700 (PDT) (envelope-from mmyers@fastq.com) Received: from MMyersLapTop ([65.39.77.135]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id i37N8Lw98481; Wed, 7 Apr 2004 16:08:22 -0700 (MST) (envelope-from mmyers@fastq.com) From: "Michael Myers" <mmyers@fastq.com> To: "Trevor Freeman" <trevorf@windows.microsoft.com>, "Dave Engberg" <dengberg@corestreet.com>, "Santosh Chokhani" <chokhani@orionsec.com>, <ietf-pkix@imc.org> Subject: RE: SCVP Change Proposal (was: Signing Untrusted SCVP?) Date: Wed, 7 Apr 2004 16:09:02 -0700 Message-ID: <EOEGJNFMMIBDKGFONJJDKENHDMAA.mmyers@fastq.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <340B5AC242DEF44AAFCD6DC102B51CD30595EB49@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> Importance: Normal Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Dave asked about signing DPD responses. Why are we talking about nonces? Mike -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org]On Behalf Of Trevor Freeman Sent: Wednesday, April 07, 2004 3:25 PM To: Dave Engberg; Santosh Chokhani; ietf-pkix@imc.org Subject: RE: SCVP Change Proposal (was: Signing Untrusted SCVP?) Hi Dave, That is almost the proposed change. The presence of the nonce will indicate the request for a unique response, and I have added a wantBack. 3.5 requestNonce The OPTIONAL requestNonce item contains a request identifier generated by the SCVP client. If the client includes a requestNonce value in the request, it is expressing a preference the SCVP server SHOULD return a specific response. If the server returns a specific response it MUST include the requestNonce from the request in the response, but MAY return a cached success response which MUST NOT have a requestNonce. If the client includes a requestNonce and also sets a wantBack of id-swb-unique-resp-required, the client is indicating that the SCVP server MUST return either a specific response including the requestNonce or an error. The client SHOULD include a requestNonce item in every request to prevent an attacker from acting as a man-in-the-middle by replaying old responses from the server. The requestNonce value SHOULD change with every request sent by the client. The client MUST NOT include the wantBack of id-swb-unique-resp-required without a requestNonce, and a server receiving such a request SHOULD return an invalidRequest error Trevor -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Dave Engberg Sent: Wednesday, April 07, 2004 9:11 AM To: Santosh Chokhani; ietf-pkix@imc.org Subject: SCVP Change Proposal (was: Signing Untrusted SCVP?) Thanks, Santosh. Here's a specific list of changes to SCVP Draft 13 that would allow the use of signatures to be optional on pure DPD lookups, and permit server caching of signed responses when mutually acceptable by server and client security policies. Rather than defining a new request extension to signal a desire for a fresh signature, this proposal uses the request nonce. I assume there would be agreement that any client who sends a nonce would not want an unsigned or cached response in return, but I wouldn't have any problem with defining a separate new extension if that makes the intent more clear. The section 3 changes are separate from section 4, and either could be adopted independently. In Section 3, replace: If a server is responding to an unsigned request or a signed request, it MUST use a signed response or an unsigned error response. With: If a server is responding to an unsigned request or a signed request, it MUST use a signed response or an unsigned error response if either of the following is true: - The request wantBack includes one or more of the following: * id-swb-pkc-public-key-info * id-swb-pkc-cert-status * id-swb-ac-cert-status - The request includes a requestNonce If neither is true, a server responding to an unsigned request or signed request MAY use a signed response, an unsigned response, or an unsigned error response. In Section 4, replace: requestRef RequestReference, With: requestRef [0] RequestReference OPTIONAL, In Section 4.5, replace: The requestRef allows the SCVP server to identify the request that With: The OPTIONAL requestRef item allows the SCVP server to identify the request that ... -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Santosh Chokhani Sent: Wednesday, April 07, 2004 8:32 AM To: ietf-pkix@imc.org Subject: RE: Signing Untrusted SCVP? Given the limited value of signature, DPD response signature by the server should be optional and signature verification by the client should be optional. The question we should answer is that is there any benefit to adding an option for the client to request a signature and then should the DPD server be forced to sign the response Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37MxLHB040863; Wed, 7 Apr 2004 15:59:21 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i37MxLOq040862; Wed, 7 Apr 2004 15:59:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail7.atl.registeredsite.com (nobody@mail7.atl.registeredsite.com [64.224.219.81]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37MxK57040856 for <ietf-pkix@imc.org>; Wed, 7 Apr 2004 15:59:20 -0700 (PDT) (envelope-from egerck@nma.com) Received: from taurus.hosting4u.net (taurus.hosting4u.net [209.35.191.122]) by mail7.atl.registeredsite.com (8.12.8/8.12.8) with ESMTP id i37MxP9F019017; Wed, 7 Apr 2004 22:59:25 GMT Received: from nma.com ([63.204.17.85]) by taurus.hosting4u.net ; Wed, 07 Apr 2004 17:59:24 -0500 Message-ID: <407487B0.A76FC305@nma.com> Date: Wed, 07 Apr 2004 15:58:56 -0700 From: Ed Gerck <egerck@nma.com> X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Stefan Santesson <stefans@microsoft.com> CC: PKIX <ietf-pkix@imc.org> Subject: Re: clarification proposal -- Re: Current status of CRL validation? References: <0C3042E92D8A714783E2C44AB9936E1DE3531A@EUR-MSG-03.europe.corp.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Stefan Santesson wrote: > > Or as RFC 3280 currently defines it in section 6, top of page 65: > > "A particular certification path may not, however, be appropriate for > all applications. Therefore, an application MAY augment this > algorithm to further limit the set of valid paths. " That text would be clearer if "RP software" replaces "application". Otherwise, I agree that it does seem equivalent to: Since there may be more than one path used to validate the same certificate, it is possible that some paths to that certificate are valid for some RPs while not valid to other RPs. BTW, the purpose of the clarification Note (that includes the paragraph above) is not to reinvent or change X.509 or related RFCs. The purpose is to clarify and unify EXISTING references (including WG context interpretation) in regard to certificate revocation. There should be lots of paragraphs in X.509 and related RFCs that are, with analysis, equivalent to the Note and vice versa. The only informative aspect of the Note should be in terms of ambiguity resolution. Cheers, Ed Gerck Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37MP4fU038221; Wed, 7 Apr 2004 15:25:04 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i37MP4c0038220; Wed, 7 Apr 2004 15:25:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37MP3Np038209 for <ietf-pkix@imc.org>; Wed, 7 Apr 2004 15:25:03 -0700 (PDT) (envelope-from trevorf@windows.microsoft.com) Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 7 Apr 2004 15:24:08 -0700 Received: from 157.54.8.109 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 07 Apr 2004 15:25:03 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 7 Apr 2004 15:25:11 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 7 Apr 2004 15:25:11 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 7 Apr 2004 15:25:01 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7195.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: SCVP Change Proposal (was: Signing Untrusted SCVP?) Date: Wed, 7 Apr 2004 15:25:01 -0700 Message-ID: <340B5AC242DEF44AAFCD6DC102B51CD30595EB49@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SCVP Change Proposal (was: Signing Untrusted SCVP?) thread-index: AcQcoRLyDCr64/a8SW+cv1GSmtiwVQAE9A0AAA1oMqA= From: "Trevor Freeman" <trevorf@windows.microsoft.com> To: "Dave Engberg" <dengberg@corestreet.com>, "Santosh Chokhani" <chokhani@orionsec.com>, <ietf-pkix@imc.org> X-OriginalArrivalTime: 07 Apr 2004 22:25:01.0977 (UTC) FILETIME=[2B243090:01C41CEF] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i37MP3Np038215 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Hi Dave, That is almost the proposed change. The presence of the nonce will indicate the request for a unique response, and I have added a wantBack. 3.5 requestNonce The OPTIONAL requestNonce item contains a request identifier generated by the SCVP client. If the client includes a requestNonce value in the request, it is expressing a preference the SCVP server SHOULD return a specific response. If the server returns a specific response it MUST include the requestNonce from the request in the response, but MAY return a cached success response which MUST NOT have a requestNonce. If the client includes a requestNonce and also sets a wantBack of id-swb-unique-resp-required, the client is indicating that the SCVP server MUST return either a specific response including the requestNonce or an error. The client SHOULD include a requestNonce item in every request to prevent an attacker from acting as a man-in-the-middle by replaying old responses from the server. The requestNonce value SHOULD change with every request sent by the client. The client MUST NOT include the wantBack of id-swb-unique-resp-required without a requestNonce, and a server receiving such a request SHOULD return an invalidRequest error Trevor -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Dave Engberg Sent: Wednesday, April 07, 2004 9:11 AM To: Santosh Chokhani; ietf-pkix@imc.org Subject: SCVP Change Proposal (was: Signing Untrusted SCVP?) Thanks, Santosh. Here's a specific list of changes to SCVP Draft 13 that would allow the use of signatures to be optional on pure DPD lookups, and permit server caching of signed responses when mutually acceptable by server and client security policies. Rather than defining a new request extension to signal a desire for a fresh signature, this proposal uses the request nonce. I assume there would be agreement that any client who sends a nonce would not want an unsigned or cached response in return, but I wouldn't have any problem with defining a separate new extension if that makes the intent more clear. The section 3 changes are separate from section 4, and either could be adopted independently. In Section 3, replace: If a server is responding to an unsigned request or a signed request, it MUST use a signed response or an unsigned error response. With: If a server is responding to an unsigned request or a signed request, it MUST use a signed response or an unsigned error response if either of the following is true: - The request wantBack includes one or more of the following: * id-swb-pkc-public-key-info * id-swb-pkc-cert-status * id-swb-ac-cert-status - The request includes a requestNonce If neither is true, a server responding to an unsigned request or signed request MAY use a signed response, an unsigned response, or an unsigned error response. In Section 4, replace: requestRef RequestReference, With: requestRef [0] RequestReference OPTIONAL, In Section 4.5, replace: The requestRef allows the SCVP server to identify the request that With: The OPTIONAL requestRef item allows the SCVP server to identify the request that ... -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Santosh Chokhani Sent: Wednesday, April 07, 2004 8:32 AM To: ietf-pkix@imc.org Subject: RE: Signing Untrusted SCVP? Given the limited value of signature, DPD response signature by the server should be optional and signature verification by the client should be optional. The question we should answer is that is there any benefit to adding an option for the client to request a signature and then should the DPD server be forced to sign the response Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37LpeBj035869; Wed, 7 Apr 2004 14:51:40 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i37LpeWQ035868; Wed, 7 Apr 2004 14:51:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37LpebR035841 for <ietf-pkix@imc.org>; Wed, 7 Apr 2004 14:51:40 -0700 (PDT) (envelope-from trevorf@windows.microsoft.com) Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 7 Apr 2004 14:50:45 -0700 Received: from 157.54.8.23 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 07 Apr 2004 14:51:39 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 7 Apr 2004 14:51:47 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 7 Apr 2004 14:51:45 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 7 Apr 2004 14:51:38 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7195.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Signing Untrusted SCVP? Date: Wed, 7 Apr 2004 14:51:37 -0700 Message-ID: <340B5AC242DEF44AAFCD6DC102B51CD30595EA95@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Signing Untrusted SCVP? thread-index: AcQc6PP+ryoXHZuSRcyqPbGvU9ej5QAAOMqg From: "Trevor Freeman" <trevorf@windows.microsoft.com> To: "Santosh Chokhani" <chokhani@orionsec.com>, <ietf-pkix@imc.org> X-OriginalArrivalTime: 07 Apr 2004 21:51:38.0297 (UTC) FILETIME=[80DAE290:01C41CEA] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i37LpebR035863 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Hi Santosh, I don't view the benefit as minimal. I see it as blocking some exploits by attackers. Given we are now allowing cached values to be returned, what is the concern? Are we trying to help the server or client? Trevor -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Santosh Chokhani Sent: Wednesday, April 07, 2004 12:34 PM To: ietf-pkix@imc.org Subject: RE: Signing Untrusted SCVP? Trevor: >From technical philosophy viewpoint, I do not have a problem. But, from my understanding of how IETF works, given that the benefit is minimal, we need to define the standard that accommodates products with varying degree of functionality. I think SCVP requirement to sign DPD responses may be too much. -----Original Message----- From: Trevor Freeman [mailto:trevorf@windows.microsoft.com] Sent: Wednesday, April 07, 2004 2:07 PM To: Santosh Chokhani; ietf-pkix@imc.org Subject: RE: Signing Untrusted SCVP? Hi Santosh, My argument cannot be construed as an argument to sign everything. It is an argument to sign all positive responses. I am equally not convinced that no singing achieves anything other than weaker security. The act of signing is not a major burden, especially if this is no longer on a per request basis and allows the client to be assured of positive. Not signing positive responses allows an attacker to manipulate the client beyond inserting errors which is very, very bad. How the server protects the cache is an implementation decision. Assuming untrusted transport is reasonable for the RFC. Trevor -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Santosh Chokhani Sent: Wednesday, April 07, 2004 9:00 AM To: ietf-pkix@imc.org Subject: RE: Signing Untrusted SCVP? Trevor: This argument can be the basis for signing everything all the time, which we do not do. The attacker can still manipulate and inject data. I am not persuaded by the argument that checking the signature first will save lot of client processing time. If the product developer and consumers want to have the option for not signing this data, they should. I see a bigger problem with the DPD server maintaining a cache and some one attacking that cache (if unsigned) since a stationary server may be easier to hack at then data in transit. Now, if the DPD server signed cached paths on request or if the DPD, you have the same problem. Also, my suggestion would be for the client to have the option of requesting signed responses and having the option of rejecting responses that are not signed. -----Original Message----- From: Trevor Freeman [mailto:trevorf@windows.microsoft.com] Sent: Wednesday, April 07, 2004 11:46 AM To: Santosh Chokhani; ietf-pkix@imc.org Subject: RE: Signing Untrusted SCVP? I think there is significant value in signing the response from the SCVP server. Given the main issue seems to be SCVP operating in an environment where an attacker has the ability to inject packets going between client and server into the data stream. Signing the response relegates the attacker to injecting error packets - which is a low grade DoS. Sending unsigned responses allows the attacker to inject a packed as the server whatever they want as a genuine response, with certificates and content of there choosing. So we just turned every SCVP client into a potential web beacon. Where the client has direct trust in the server signing key this is a very secure process with DPD. Trevor -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Santosh Chokhani Sent: Wednesday, April 07, 2004 5:32 AM To: ietf-pkix@imc.org Subject: RE: Signing Untrusted SCVP? Given the limited value of signature, DPD response signature by the server should be optional and signature verification by the client should be optional. The question we should answer is that is there any benefit to adding an option for the client to request a signature and then should the DPD server be forced to sign the response (shades of OCSP nonce) -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of David Engberg Sent: Tuesday, April 06, 2004 11:32 PM To: Stephen Kent Cc: ietf-pkix@imc.org Subject: Re: Signing Untrusted SCVP? Stephen - You have provided interesting techniques that an attacker could use to make a DPD client waste an extra 500ms verifying signatures before displaying a "bad path returned from server" dialog (or the equivalent). That same attacker with the same advantages (DNS spoofing, etc.) could achieve the same effective denial of path discovery even if an extra signature is thrown on responses. The attacker could obviously make clients waste time & bandwidth in lots of sneaky ways, although the relying application would ultimately report different error messages ("unknown host: 'scvp.eubridge.org'", "connection timed out", "no route to host", "response signature verify failed", etc.). I am curious whether the type of attack that you describe has ever been performed against a non-SSL LDAP directory in a manner that would not have been equally effective if SSL was in use. While there is definitely a difference here, I think (hope?) that we agree that it may be useful for a PKI administrator to have the choice to deploy a path discovery mechanism which does not require a fresh signature from a protected server key for every request. This would allow an administrator to balance the DoS risks for clients against the DoS risks for servers. My guess is that virtually all real world DoS attacks exploit the centralized nature of secured servers, and the best cure for this is the sort of distributed redundancy that a keyless or two-tier-caching DPD responder architecture would permit. For example, Akamai has 16,000+ servers around the world with no SSL private keys. They are subjected to daily DoS attempts (e.g. they host www.whitehouse.gov), which fail not due to the magic of PKI, but rather due to the redundancy you can build when you don't have to secure keys at every server. Thanks Stephen Kent wrote: ... > if an attacker can spoof a DNS response, he can cause the client to > connect to him instead of the server, which would enable the bogus > server to receive the request as well as generate and send the > response, and in the absence of a signed response, the client cannot > know that he is not communicating with the intended server. > > a bogus server could then return bogus cert chains that fail to > validate, but which waste client resources. just how effective this > may be will be a function of client implementation details, which are > outside the scope of our standards. ... Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37Lp25G035801; Wed, 7 Apr 2004 14:51:02 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i37Lp2u7035800; Wed, 7 Apr 2004 14:51:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail-dub.microsoft.com (mail-dub.microsoft.com [213.199.128.160]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37Lp1Rv035786 for <ietf-pkix@imc.org>; Wed, 7 Apr 2004 14:51:01 -0700 (PDT) (envelope-from stefans@microsoft.com) Received: from dub-imc-01.europe.corp.microsoft.com ([65.53.196.22]) by mail-dub.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 7 Apr 2004 22:51:21 +0100 Received: from 65.53.196.22 by dub-imc-01.europe.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 07 Apr 2004 22:51:21 +0100 Received: from EUR-MSG-03.europe.corp.microsoft.com ([65.53.192.44]) by dub-imc-01.europe.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 7 Apr 2004 22:51:21 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7195.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: clarification proposal -- Re: Current status of CRL validation? Date: Wed, 7 Apr 2004 22:51:00 +0100 Message-ID: <0C3042E92D8A714783E2C44AB9936E1DE3531A@EUR-MSG-03.europe.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: clarification proposal -- Re: Current status of CRL validation? Thread-Index: AcQc59fqZvC4tXFFQHmOKbDNc9TQFQAAio6w From: "Stefan Santesson" <stefans@microsoft.com> To: "Ed Gerck" <egerck@nma.com>, "PKIX" <ietf-pkix@imc.org> X-OriginalArrivalTime: 07 Apr 2004 21:51:21.0194 (UTC) FILETIME=[76A92CA0:01C41CEA] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i37Lp2Rv035794 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Or as RFC 3280 currently defines it in section 6, top of page 65: "A particular certification path may not, however, be appropriate for all applications. Therefore, an application MAY augment this algorithm to further limit the set of valid paths. " /Stefan > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] > On Behalf Of Ed Gerck > Sent: den 7 april 2004 11:47 > To: PKIX > Subject: Re: clarification proposal -- Re: Current status of CRL > validation? > > > > > Stefan Santesson wrote: > > > > The basic assumption for the whole discussion seems to be very confused: > > > > Snip: > > > > > > "Since there may be more than one path used to validate the > > > same certificate, it is possible that some paths to that > > > certificate are valid while others are not." > > > > > > > There is only 1 kind of path that can be used to validate a certificate, > > and that is a valid path. > > Valid to a RP may not be valid to another RP. To clarify this, > the text could say: > > Since there may be more than one path used to validate the same > certificate, it is possible that some paths to that certificate > are valid for some RPs while not valid to other RPs. > > > Valid being defined as a path that pass the > > RPs validation policy (defined at the discretion of the relying party). > > Exactly. It depends on what each RP may choose to rely upon. Different > RPs may define "valid path" in a different way. > > The RP may also receive different answers from valid paths. > > > All other paths are invalid by definition. So among the valid paths > > there is no ambiguity, since they are all valid. > > > > Why complicate things? > > The RPs are complicated ;-) > > Cheers, > Ed Gerck Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37LUHcj033318; Wed, 7 Apr 2004 14:30:17 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i37LUHu3033317; Wed, 7 Apr 2004 14:30:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37LUG8t033309 for <ietf-pkix@imc.org>; Wed, 7 Apr 2004 14:30:16 -0700 (PDT) (envelope-from chokhani@orionsec.com) Received: from wchokhani3 (dpvc-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i37LUJAt028890 for <ietf-pkix@imc.org>; Wed, 7 Apr 2004 17:30:20 -0400 From: "Santosh Chokhani" <chokhani@orionsec.com> To: <ietf-pkix@imc.org> Subject: RE: Re-certification Date: Wed, 7 Apr 2004 17:30:16 -0400 Message-ID: <01d701c41ce7$871ffc60$9a00a8c0@hq.orionsec.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <03a701c41cdb$9e785bc0$be00a8c0@jurujuba> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_01D2_01C41CC5.FDBF1530" Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> This is a multi-part message in MIME format. ------=_NextPart_000_01D2_01C41CC5.FDBF1530 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In that case, the following may work: 1. The new CA reissues all the old CA issued certificates that are not yet expired. It can keep the same serial number if possible. 2. Everyone has the new root using secure means. -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Rodrigo Botafogo Sent: Wednesday, April 07, 2004 4:05 PM To: ietf-pkix@imc.org Subject: RES: Re-certification Santosh, Sorry, I missed your reply. But unfortunately, my product does not allow me to have two CAs with the same DN active at the same time. So, once I create the new CA, I'll have to deactivate somehow the old CA. But I agree, that probably would be a good solution. Thanks Rodrigo Botafogo > As my answer said, there would not be a problem with CRL since each serial > number will be unique and both keys will be used to sign the CRL. > > Please go back and read my response. > ------=_NextPart_000_01D2_01C41CC5.FDBF1530 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQyzCCA9Yw ggK+oAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwVTELMAkGA1UEBhMCVVMxITAfBgNVBAoTGE9yaW9u IFNlY3VyaXR5IFNvbHV0aW9uczELMAkGA1UECxMCSFExFjAUBgNVBAMTDU9yaW9uIFJvb3QgQ0Ew HhcNMDMwODEzMTcwMTI0WhcNMTMwODEwMTcwMTI0WjBVMQswCQYDVQQGEwJVUzEhMB8GA1UEChMY T3Jpb24gU2VjdXJpdHkgU29sdXRpb25zMQswCQYDVQQLEwJIUTEWMBQGA1UEAxMNT3Jpb24gUm9v dCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOd3fg/nIELr3rAuxpkcxiAn7ayU /30RPxYBMgcvn0BJbBXBXIkTHgm3jh0TwHGQk76nqTSo1fUqpkkEcSSwEtfz1jF0QCKPHoQvNxza 5ffqH2gBSTgjpwqLA34RDxFDwcdNibIG/s6Zj2PpVDDWVBYxMbLrhKluMAfufhOMT6uyYxw+XPcU ndqy4bRo08BONIoLdoUoOsvOwHla+zPYsBnTncMEL26lnKgCQgJpcFfrQRLrM84Rlc9EmvPbU+tO 5jRfdnvJpCm8LbIcTvAwQLiM+5qr4GPTg73S+9ZMAjlaZWG/VGe5b+KtQCgDu2TPB+wtiz2csG5q YN14mFpKMdMCAwEAAaOBsDCBrTAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNV HQ4EFgQUvpoqeR5tpH+G2bn1P06LoHH9Mq0wHwYDVR0jBBgwFoAUvpoqeR5tpH+G2bn1P06LoHH9 Mq0wEQYJYIZIAYb4QgEBBAQDAgAHMDcGA1UdHwQwMC4wLKAqoCiGJmh0dHA6Ly93d3cub3Jpb25z ZWMuY29tL29yaW9uX3Jvb3QuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAch1imNzh8/wx6Ym3ti6FI LyJMsktilc4I5zJ6ZRrZUMye/3v9XJDIutBPb472wOwQT+OR3DTbWX8loNybf3Ew3wWzZg+D14kQ d/+rm3ZAJ3EeX67/g9XevAkrv951Q7QSucZMbbzrLqIWSkgjxJbcujNdeQsSlUz5I2Q9qYdAhg6G 85gf+GaStpaGlR5siWwJAQ/KeWrntfwNbh1P81Vmq/MovUQWPNKeM80FHcqHVVpQWasPTkGb0eW2 NOBsxGBCSQjc5QQdxPIMIuxmyVX42kGTK3O/IxI2O2QBK+pmFHEm4o+p+ekxxHekZTowPSeFXFYQ SrnpmJyfcHa2vLTpMIID1zCCAr+gAwIBAgIBAjANBgkqhkiG9w0BAQUFADBVMQswCQYDVQQGEwJV UzEhMB8GA1UEChMYT3Jpb24gU2VjdXJpdHkgU29sdXRpb25zMQswCQYDVQQLEwJIUTEWMBQGA1UE AxMNT3Jpb24gUm9vdCBDQTAeFw0wMzA4MTQxNjQ4MzZaFw0wNDA4MTMxNjQ4MzZaMFYxCzAJBgNV BAYTAlVTMSEwHwYDVQQKExhPcmlvbiBTZWN1cml0eSBTb2x1dGlvbnMxCzAJBgNVBAsTAkhRMRcw FQYDVQQDEw5PcmlvbiBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL65 aM5ISSZ1ERaIjEaBDvZJ+U1iEEvdLoILkmuwzqrN0DMNhBwLUPJSYjGZ6xlGE5sRmDbUcFhRX0Dt p/t0lKBl0zajquPRbO5t3whqhb0h5IgIRP19NOZ9Mo/XWML2eCVmDyy6lqK5NC+Uvdhf8SjjH+P2 WCk68KmELfqXSfHoKy9gKMEH9IFyL1EqbE8DTUuFmUzg3ZIpR9UMX0Yorx4YdQRyblH4fEUDNfUu PHvRTZkyfAm8nrpsWCqOY0Q3Vl6OsfMqBaVYOORA9fDPLZLXvYc7Im3LDTAXvy+DTki2cR3rjLrO +p3POH/SoH8/9eHhNk4fX/w4FvQMv9hIonECAwEAAaOBsDCBrTAPBgNVHRMBAf8EBTADAQH/MA4G A1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQU+NvSaD0SiHYB9QkgqlK4n+fFAKEwHwYDVR0jBBgwFoAU vpoqeR5tpH+G2bn1P06LoHH9Mq0wEQYJYIZIAYb4QgEBBAQDAgAHMDcGA1UdHwQwMC4wLKAqoCiG Jmh0dHA6Ly93d3cub3Jpb25zZWMuY29tL29yaW9uX3Jvb3QuY3JsMA0GCSqGSIb3DQEBBQUAA4IB AQDPS+PvtkWJ6V235n4Ntn5xWFgvS+GVMI3tBVid/DW2h3AxDWzKctlybc/FhO0sj7nlLXE5CQfm ocx7m3mf1DcEz83b3BJNO9Dwa0U1kNL0kAFSXb9i+jaL3ovNoZlXxOcl73dK77eEohYbioUOtglM HwXXOdbpbOPH1tX0fUr70Zp4KBczNdsQnSrbnHIe2zdNPKY5VPYonB6gxJTNxlbqcHYg56abe0En Ad0C5IoMEG13CbHfDCm9uhRC5yHfylEZMOYA644+2d73FUsIstAdwK+pyeWXSaWGwN/xgLAGE5S1 Ryihlql/q4BXxqqU8RPm90g+2aj1e+PlnlXHxLWCMIIEdzCCA1+gAwIBAgIBIjANBgkqhkiG9w0B AQUFADBWMQswCQYDVQQGEwJVUzEhMB8GA1UEChMYT3Jpb24gU2VjdXJpdHkgU29sdXRpb25zMQsw CQYDVQQLEwJIUTEXMBUGA1UEAxMOT3Jpb24gRW1haWwgQ0EwHhcNMDMwODE1MTgyMDM3WhcNMDQw ODE0MTgyMDM3WjB+MQswCQYDVQQGEwJVUzEhMB8GA1UEChMYT3Jpb24gU2VjdXJpdHkgU29sdXRp b25zMQswCQYDVQQLEwJIUTEZMBcGA1UEAxMQU2FudG9zaCBDaG9raGFuaTEkMCIGCSqGSIb3DQEJ ARYVY2hva2hhbmlAb3Jpb25zZWMuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA 0EadobvmWyC1UbtEuos8DmEK7vsk72z3USFc4MF4I71ctasTuT7n3eY0RsXK5NSrGNufwwup7ksd ZAo/a6GPxiGMDOaQtJi8VaACzPUyqzZZJEKtaolcD4fS8V6OFyBdMmdMBebd0GrcNVmabvgVIm3h 5Oe3sUzZxqkduueAkjMstGnBtUWG431HzM3vOTzkbHzkMoNTFgMEayhHrklyecveHOgiqhOypAiK Sv5acM2vgzreh5gbHEJfqOfS56+exTAz/MrpdzvXmv0kmrwMBOtTM1rOYhyjw2yzM07lBxstBMR0 DIeqpf2dZN1IHOnnGWxSqql2Gdjn9bpplVN2EQIDAQABo4IBJjCCASIwHQYDVR0OBBYEFPQLCXgN tykUjPyCwMO9MWrT0A86MB8GA1UdIwQYMBaAFPjb0mg9Eoh2AfUJIKpSuJ/nxQChMDcGA1UdHwQw MC4wLKAqoCiGJmh0dHA6Ly93d3cub3Jpb25zZWMuY29tL29yaW9uX21haWwuY3JsMAkGA1UdEwQC MAAwQgYIKwYBBQUHAQEENjA0MDIGCCsGAQUFBzAChiZodHRwOi8vd3d3Lm9yaW9uc2VjLmNvbS9v cmlvbl9tYWlsLmRlcjAOBgNVHQ8BAf8EBAMCBDAwEwYDVR0lBAwwCgYIKwYBBQUHAwQwEQYJYIZI AYb4QgEBBAQDAgWgMCAGA1UdEQQZMBeBFWNob2toYW5pQG9yaW9uc2VjLmNvbTANBgkqhkiG9w0B AQUFAAOCAQEAOMNwcRoKaH2+5wC7MWhDrG98bOyphlE51btwmPHS9Ob5XpJMJMlZI2kb2/4A71ri aZZPcuFypMqxGIjaH7Y/Gi0aHsk7iWRMEMXiaCT2fq0WM1Wq/sDgwMYVCvOjU8s5x+4i7y4tvS/e P01qcmqz5RABM85bmZ45qypM+JV246LxYRkVpESl62+iSkcgU8hmtruiV7C8CX3yUZj//uwPH9F+ 7iwvSEAmH6vm4MxGxrMbo2yThsvJ6KNZ1XVlT3jtA66AhoKBh++f7KfuqJbWUaQXVuvGESCHI79D CtXVUK7YFdHQxLU1Y63NkqRYTncrHtJlqzY2kxq5B/0vnPhg1zCCBJcwggN/oAMCAQICASEwDQYJ KoZIhvcNAQEFBQAwVjELMAkGA1UEBhMCVVMxITAfBgNVBAoTGE9yaW9uIFNlY3VyaXR5IFNvbHV0 aW9uczELMAkGA1UECxMCSFExFzAVBgNVBAMTDk9yaW9uIEVtYWlsIENBMB4XDTAzMDgxNTE4MjAx N1oXDTA0MDgxNDE4MjAxN1owfjELMAkGA1UEBhMCVVMxITAfBgNVBAoTGE9yaW9uIFNlY3VyaXR5 IFNvbHV0aW9uczELMAkGA1UECxMCSFExGTAXBgNVBAMTEFNhbnRvc2ggQ2hva2hhbmkxJDAiBgkq hkiG9w0BCQEWFWNob2toYW5pQG9yaW9uc2VjLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAMLUZwZhoWYVw7zKNe5KLxQfXo0dKMKkph9MA+fNX9YPW/LEbsjqdofCRJ1F8VZalpBr lz61ITyJ7/y+W1My0n0oOJhwvdhqRxE2QUv+bOP80i7BGqIm4/wd35ZyABDG2mt5Jj2anwXUIK1K ENCo1pYxhroil3qLhtd9xPiOOjUZ2wAmNEgFwxDcQE1xsNJtJ3Ro1O3VfceF53AxomEIZM300usi xqnUSKbk8D8oVwUNBnMXdj+7K/0G/YJ9EPJFF5orwI1j9LE3tdWBVY9a7WY1+ygHDMXaeYAnM2Tk AuVGtWqTHTGmdNuyxsapFY7UFLtRjItA2oFb3bs/ho1tKrUCAwEAAaOCAUYwggFCMB0GA1UdDgQW BBQSo0Fab6xpwZ5BxERoEuUigr/N2zAfBgNVHSMEGDAWgBT429JoPRKIdgH1CSCqUrif58UAoTA3 BgNVHR8EMDAuMCygKqAohiZodHRwOi8vd3d3Lm9yaW9uc2VjLmNvbS9vcmlvbl9tYWlsLmNybDAJ BgNVHRMEAjAAMEIGCCsGAQUFBwEBBDYwNDAyBggrBgEFBQcwAoYmaHR0cDovL3d3dy5vcmlvbnNl Yy5jb20vb3Jpb25fbWFpbC5kZXIwDgYDVR0PAQH/BAQDAgbAMDMGA1UdJQQsMCoGCCsGAQUFBwMC BggrBgEFBQcDBAYIKwYBBQUHAwcGCisGAQQBgjcUAgIwEQYJYIZIAYb4QgEBBAQDAgWgMCAGA1Ud EQQZMBeBFWNob2toYW5pQG9yaW9uc2VjLmNvbTANBgkqhkiG9w0BAQUFAAOCAQEAmnUXuCAU2nzN bCAaRmH0JE1bFUr/bNPUoOHU7ATGfmk/QhiGPxaApPSU+CC8JNgGOs6z6o/WCfKMj4srMkWjBKcF HNASw7oxsLdEj/JvIAcPVPwfV4RUBY7SU3svNPQILSYdD0LUuhryAqMlNePrDPi5LWSyJ1q4ftRt ZZlJdu50UjBSPwJcOhrn4CJAzu4DHRAWNLvVZ91m7c/E6LF4Ajj1QC8Sd2HWpgc0iQf7XAN58+7Y 9fF+F6VebVeuLws2IZNPfdTvq+1kHTOCVYasbh2IqdM7ryyrz3rL0l3LOySD73mv/YU4Dt1brScF Xq4hA5IcXNGvyn1gUw3HD8/cbjGCAyYwggMiAgEBMFswVjELMAkGA1UEBhMCVVMxITAfBgNVBAoT GE9yaW9uIFNlY3VyaXR5IFNvbHV0aW9uczELMAkGA1UECxMCSFExFzAVBgNVBAMTDk9yaW9uIEVt YWlsIENBAgEhMAkGBSsOAwIaBQCgggGgMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTA0MDQwNzIxMzAxNlowIwYJKoZIhvcNAQkEMRYEFFOmpiRZ/Mw3dBws/zlS8Znj dcWmMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwBwYFKw4DAhowDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAoGCCqGSIb3DQIFMGoGCSsG AQQBgjcQBDFdMFswVjELMAkGA1UEBhMCVVMxITAfBgNVBAoTGE9yaW9uIFNlY3VyaXR5IFNvbHV0 aW9uczELMAkGA1UECxMCSFExFzAVBgNVBAMTDk9yaW9uIEVtYWlsIENBAgEiMGwGCyqGSIb3DQEJ EAILMV2gWzBWMQswCQYDVQQGEwJVUzEhMB8GA1UEChMYT3Jpb24gU2VjdXJpdHkgU29sdXRpb25z MQswCQYDVQQLEwJIUTEXMBUGA1UEAxMOT3Jpb24gRW1haWwgQ0ECASIwDQYJKoZIhvcNAQEBBQAE ggEAZg6g/AXLlov7Ig7edlr11P2k5zqE6V/dtCcW3J3RL+TVzn6KkAnxCkD5Hc4gRLy7vVS3LDIo qjVC1TkBozd4NhH+hHy7WawEw9/2ju6/wuFoCoJiAFuFyioPerWphYZFebiKy7FFaZ5z33JHrqGL VCRShSydDkMIF5xs9jqv1mxI8mfXPV92vgZwIPV55EIPu8QNnopgDMG7vyHwL3BpTHZgqLHQv1vN B6s5pdX81P/gLNVaAs6ptifWAANvDgxGOHiNYIvk3QmDoPlhtb3whgUlRtvz0QlpC2G3Un2cS8T8 ULsLgs9mcRFK4EhYrNSd0BAN9RXPrjd+fmuG6eWteAAAAAAAAA== ------=_NextPart_000_01D2_01C41CC5.FDBF1530-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37Km7hV030571; Wed, 7 Apr 2004 13:48:07 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i37Km78l030570; Wed, 7 Apr 2004 13:48:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37Km6TO030564 for <ietf-pkix@imc.org>; Wed, 7 Apr 2004 13:48:07 -0700 (PDT) (envelope-from chokhani@orionsec.com) Received: from wchokhani3 (dpvc-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i37KmBAt014903 for <ietf-pkix@imc.org>; Wed, 7 Apr 2004 16:48:11 -0400 From: "Santosh Chokhani" <chokhani@orionsec.com> To: <ietf-pkix@imc.org> Subject: RE: Signing Untrusted SCVP? Date: Wed, 7 Apr 2004 16:48:11 -0400 Message-ID: <01ad01c41ce1$a3f52d70$9a00a8c0@hq.orionsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <p0602041abc9a117f9c44@[128.89.89.75]> Importance: Normal Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Steve: I agree. -----Original Message----- From: Stephen Kent [mailto:kent@bbn.com] Sent: Wednesday, April 07, 2004 4:15 PM To: Santosh Chokhani Cc: ietf-pkix@imc.org Subject: RE: Signing Untrusted SCVP? At 3:33 PM -0400 4/7/04, Santosh Chokhani wrote: >Trevor: > >>From technical philosophy viewpoint, I do not have a problem. > >But, from my understanding of how IETF works, given that the benefit is >minimal, we need to define the standard that accommodates products with >varying degree of functionality. I think SCVP requirement to sign DPD >responses may be too much. This is a value judgement call. If one starts from the premise that the benefit is minimal, then the answer seems obvious. if one does not characterize the benefit that way, the answer is probably different. Steve Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37Kf7DD030168; Wed, 7 Apr 2004 13:41:07 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i37Kf7Yo030167; Wed, 7 Apr 2004 13:41:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37Kf6ew030147 for <ietf-pkix@imc.org>; Wed, 7 Apr 2004 13:41:06 -0700 (PDT) (envelope-from kent@bbn.com) Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i37Kea7h026261; Wed, 7 Apr 2004 16:40:39 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: <p0602041ebc9a15bf9b3c@[128.89.89.75]> In-Reply-To: <20040407163512.GA1250@cryptolog.com> References: <20040407144450.GA742@cryptolog.com> <011b01c41cba$70bbff00$9a00a8c0@hq.orionsec.com> <20040407163512.GA1250@cryptolog.com> Date: Wed, 7 Apr 2004 16:34:49 -0400 To: "Julien Stern" <julien.stern@cryptolog.com> From: Stephen Kent <kent@bbn.com> Subject: Re: Current status of CRL validation ? Cc: ietf-pkix@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> At 6:35 PM +0200 4/7/04, Julien Stern wrote: >On Wed, Apr 07, 2004 at 12:07:34PM -0400, Santosh Chokhani wrote: >> >> Julien: >> >> I am not sure that two distinct CAs with the same key (putting aside the >> same DN) should be the basis for analysis. That situation will always lead >> to problems. We are relying on randomness of large numbers to help us that >> this will not happen. >> >> Consider providing an example where different CAs do not have the same key. > >You should view my "two" CAs as the same CA with two different keys. >I might not have been totally clear about that, sorry. >This can be "either due to multiple concurrent key pairs or >due to changeover" (to quote RFC3280 :)). Well, that would make this a very different example. it also means that the two CAs, with different keys, would not both point to the same cert, since that would yield different cert signatures. So, let me suggest you recreate a valid example before we expend any more ffort on this. Steve Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37Kem2Y030129; Wed, 7 Apr 2004 13:40:48 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i37KemGT030128; Wed, 7 Apr 2004 13:40:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37KelwK030120 for <ietf-pkix@imc.org>; Wed, 7 Apr 2004 13:40:47 -0700 (PDT) (envelope-from kent@bbn.com) Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i37Kea7j026261; Wed, 7 Apr 2004 16:40:47 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: <p0602041fbc9a16a5d145@[128.89.89.75]> In-Reply-To: <001601c41cb6$8a6f6bc0$a600a8c0@seguridata.com> References: <001601c41cb6$8a6f6bc0$a600a8c0@seguridata.com> Date: Wed, 7 Apr 2004 16:39:48 -0400 To: "Miguel Rodriguez" <mars@seguridata.com> From: Stephen Kent <kent@bbn.com> Subject: Re: key uniqueness in a PKI Cc: <ietf-pkix@imc.org> Content-Type: multipart/alternative; boundary="============_-1130752094==_ma============" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> --============_-1130752094==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 10:39 AM -0500 4/7/04, Miguel Rodriguez wrote: >Where can I find information on key pair uniqueness in a PKI? Is >this issue discussed in an RFC? >I will also appreciate comments on this issue, particularly when >considering a PKI with several CAs. > >Thanks. > >Miguel A Rodriguez >SeguriData >Mexico there is no standards-based requirement that a CA verify that each cert request contain a unique public key, neither globally nor relative to the certs that the CA has perviously issued. A CA might choose to try to make checks relative to the certs it has issued, and for which it still has this info, but there is no requirement to do so in X.509 nor PKIX standards. Steve --============_-1130752094==_ma============ Content-Type: text/html; charset="us-ascii" <!doctype html public "-//W3C//DTD W3 HTML//EN"> <html><head><style type="text/css"><!-- blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 } --></style><title>Re: key uniqueness in a PKI</title></head><body> <div>At 10:39 AM -0500 4/7/04, Miguel Rodriguez wrote:</div> <blockquote type="cite" cite><font face="Arial" size="-1">Where can I find information on key pair uniqueness in a PKI? Is this issue discussed in an RFC?</font></blockquote> <blockquote type="cite" cite><font face="Arial" size="-1">I will also appreciate comments on this issue, particularly when considering a PKI with several CAs.</font></blockquote> <blockquote type="cite" cite> </blockquote> <blockquote type="cite" cite><font face="Arial" size="-1">Thanks.</font></blockquote> <blockquote type="cite" cite> </blockquote> <blockquote type="cite" cite><font face="Arial" size="-1">Miguel A Rodriguez</font></blockquote> <blockquote type="cite" cite><font face="Arial" size="-1">SeguriData</font></blockquote> <blockquote type="cite" cite><font face="Arial" size="-1">Mexico</font></blockquote> <div><br></div> <div>there is no standards-based requirement that a CA verify that each cert request contain a unique public key, neither globally nor relative to the certs that the CA has perviously issued. A CA might choose to try to make checks relative to the certs it has issued, and for which it still has this info, but there is no requirement to do so in X.509 nor PKIX standards.</div> <div><br></div> <div>Steve</div> </body> </html> --============_-1130752094==_ma============-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37KednP030110; Wed, 7 Apr 2004 13:40:39 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i37KedvN030109; Wed, 7 Apr 2004 13:40:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37KecD6030102 for <ietf-pkix@imc.org>; Wed, 7 Apr 2004 13:40:38 -0700 (PDT) (envelope-from kent@bbn.com) Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i37Kea7b026261; Wed, 7 Apr 2004 16:40:37 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: <p0602041abc9a117f9c44@[128.89.89.75]> In-Reply-To: <016e01c41cd7$4617d590$9a00a8c0@hq.orionsec.com> References: <016e01c41cd7$4617d590$9a00a8c0@hq.orionsec.com> Date: Wed, 7 Apr 2004 16:15:25 -0400 To: "Santosh Chokhani" <chokhani@orionsec.com> From: Stephen Kent <kent@bbn.com> Subject: RE: Signing Untrusted SCVP? Cc: <ietf-pkix@imc.org> Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> At 3:33 PM -0400 4/7/04, Santosh Chokhani wrote: >Trevor: > >>From technical philosophy viewpoint, I do not have a problem. > >But, from my understanding of how IETF works, given that the benefit is >minimal, we need to define the standard that accommodates products with >varying degree of functionality. I think SCVP requirement to sign DPD >responses may be too much. This is a value judgement call. If one starts from the premise that the benefit is minimal, then the answer seems obvious. if one does not characterize the benefit that way, the answer is probably different. Steve Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37KY6Ci029397; Wed, 7 Apr 2004 13:34:06 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i37KY6UU029396; Wed, 7 Apr 2004 13:34:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail11.atl.registeredsite.com (nobody@mail11.atl.registeredsite.com [64.224.219.85]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37KY5xL029390 for <ietf-pkix@imc.org>; Wed, 7 Apr 2004 13:34:05 -0700 (PDT) (envelope-from egerck@nma.com) Received: from taurus.hosting4u.net (taurus.hosting4u.net [209.35.191.122]) by mail11.atl.registeredsite.com (8.12.8/8.12.8) with ESMTP id i37KY87m008170; Wed, 7 Apr 2004 20:34:08 GMT Received: from nma.com ([63.204.17.85]) by taurus.hosting4u.net ; Wed, 07 Apr 2004 15:34:07 -0500 Message-ID: <40746575.D400B582@nma.com> Date: Wed, 07 Apr 2004 13:32:53 -0700 From: Ed Gerck <egerck@nma.com> X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Santosh Chokhani <chokhani@orionsec.com> CC: ietf-pkix@imc.org Subject: Re: clarification proposal -- Re: Current status of CRL validation? References: <016f01c41cd7$a6356500$9a00a8c0@hq.orionsec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Santosh Chokhani wrote: > > Ed: > > I see no benefit of having this dialog. Our understanding of security, PKI, > X.509, 3280, and ASN.1 are so far apart, I better go and back to > kindergarten and learn some stuff. ;-) we have not discussed ASN.1 yet, so how could you have guessed? > Rest of the PKIXers: > > My lack of response to Ed on this thread from now on should not be viewed as > concurrence. That's SOP. Anyway, I have benefited greatly by your responses and I am always happy to see your comments as you usually bring a different POV. Cheers, Ed Gerck Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37KNsnv028720; Wed, 7 Apr 2004 13:23:54 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i37KNs95028719; Wed, 7 Apr 2004 13:23:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mongo.corestreet.com (mongo.corestreet.com [68.162.232.130]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37KNrdc028708 for <ietf-pkix@imc.org>; Wed, 7 Apr 2004 13:23:53 -0700 (PDT) (envelope-from dengberg@corestreet.com) X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Signing Untrusted SCVP? Date: Wed, 7 Apr 2004 16:23:06 -0400 Message-ID: <DE909E05406F3340B186DA5A410B05F642A3F2@mongo.corestreet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Signing Untrusted SCVP? Thread-Index: AcQcwhcJ12iwHTU8ThSEyQZFN1H+MgABZn/AAAIqgmA= From: "Dave Engberg" <dengberg@corestreet.com> To: "Trevor Freeman" <trevorf@windows.microsoft.com>, "Santosh Chokhani" <chokhani@orionsec.com>, <ietf-pkix@imc.org> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i37KNrdc028714 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> I think that "very, very bad" might be a bit strong. Steve pointed out that an attacker could use unsigned responses to waste client CPU resources before the client rejects an unsigned DPD response, and possibly to lead a smart client to "hot list" the bad server. Even with signed responses, an attacker could achieve the same end result (or worse) through all of the normal bad-guy means. For example, spoofed DNS could send clients to bad IP addresses (30 second timeout while MS Outlook hangs ...) or servers that faked flaky TCP packets for infinite exponential backoff, etc. Steve's right that a signature might allow a very clever client to mitigate a very specific type of time-wasting client DoS, but obviously an attacker who can seize your networking or DNS can cause a DoS regardless of whether the responses are signed. "Very, very bad" would apply if an attacker could trick a non-buggy client into accepting a cert for which there is no valid path. This is absolutly not possible with unsigned DPD lookups (or non-SSL LDAP), although it definitely is a risk for "Trusted SCVP" if any server is compromised. -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Trevor Freeman Sent: Wednesday, April 07, 2004 2:07 PM To: Santosh Chokhani; ietf-pkix@imc.org Subject: RE: Signing Untrusted SCVP? Hi Santosh, My argument cannot be construed as an argument to sign everything. It is an argument to sign all positive responses. I am equally not convinced that no singing achieves anything other than weaker security. The act of signing is not a major burden, especially if this is no longer on a per request basis and allows the client to be assured of positive. Not signing positive responses allows an attacker to manipulate the client beyond inserting errors which is very, very bad. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37KD4t8028091; Wed, 7 Apr 2004 13:13:04 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i37KD4SK028090; Wed, 7 Apr 2004 13:13:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37KD3Yc028082 for <ietf-pkix@imc.org>; Wed, 7 Apr 2004 13:13:03 -0700 (PDT) (envelope-from mmyers@fastq.com) Received: from MMyersLapTop ([65.39.77.135]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id i37KD7w65936 for <ietf-pkix@imc.org>; Wed, 7 Apr 2004 13:13:07 -0700 (MST) (envelope-from mmyers@fastq.com) From: "Michael Myers" <mmyers@fastq.com> To: <ietf-pkix@imc.org> Subject: RE: Signing Untrusted SCVP? Date: Wed, 7 Apr 2004 13:13:49 -0700 Message-ID: <EOEGJNFMMIBDKGFONJJDOENEDMAA.mmyers@fastq.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <016e01c41cd7$4617d590$9a00a8c0@hq.orionsec.com> Importance: Normal Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> I think we should just change the relevant MUSTs to "MUST be capable of". Mike Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37K7we0027522; Wed, 7 Apr 2004 13:07:58 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i37K7wuD027521; Wed, 7 Apr 2004 13:07:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from caveiras.certisign.com.br (caveiras.certisign.com.br [200.219.128.102]) by above.proper.com (8.12.11/8.12.8) with SMTP id i37K7uUo027514 for <ietf-pkix@imc.org>; Wed, 7 Apr 2004 13:07:57 -0700 (PDT) (envelope-from rbotafogo@certisign.com.br) Received: through eSafe SMTP Relay 1075129843; Wed Apr 07 17:08:00 2004 From: "Rodrigo Botafogo" <rbotafogo@certisign.com.br> To: <ietf-pkix@imc.org> Subject: RES: Re-certification Date: Wed, 7 Apr 2004 17:05:03 -0300 MIME-Version: 1.0 Message-ID: <03a701c41cdb$9e785bc0$be00a8c0@jurujuba> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=MD5; boundary="----=_NextPart_000_03A2_01C41CC2.77081CB0" Importance: Normal In-Reply-To: <016b01c41cd6$b4505880$9a00a8c0@hq.orionsec.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> This is a multi-part message in MIME format. ------=_NextPart_000_03A2_01C41CC2.77081CB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Santosh, Sorry, I missed your reply. But unfortunately, my product does not allow me to have two CAs with the same DN active at the same time. So, once I create the new CA, I'll have to deactivate somehow the old CA. But I agree, that probably would be a good solution. Thanks Rodrigo Botafogo > As my answer said, there would not be a problem with CRL since each serial > number will be unique and both keys will be used to sign the CRL. > > Please go back and read my response. > ------=_NextPart_000_03A2_01C41CC2.77081CB0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDjAMBggqhkiG9w0CBQUAMIAGCSqGSIb3DQEHAQAAoIIKtDCC Aj0wggGmAhEAzbp/VvDf5LxU/iKss3KqVTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEX MBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkg Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMjgwODAxMjM1OTU5WjBf MQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEg UHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQAD gY0AMIGJAoGBAOUZv22jVmEtmUhx9mfeuY3rt56GgAqRDvo4Ja9GiILlc6igmyRdDR/MZW4MsNBW hBiHmgabEKFz37RYOWtuwfYV1aioP6oSBo0xrH+wNNePNGeICc0UEeJORVZpH3gCgNrcR5EpuzbJ Y1zF4Ncth3uhtzKwezC6Ki8xqu6jZ9rbAgMBAAEwDQYJKoZIhvcNAQECBQADgYEATD+4i8Zo3+5D Mw5d6abLB4RNejP/khv0Nq3YlSI2aBFsfELM85wuxAc/FLAPT/+Qknb54rxK6Y/NoIAK98Up8YIi Xbix3YEjo3slFUYweRb46gVLlH8dwhzI47f0EEA8E8NfH1PoSOSGtHuhNbB7Jbq4046rPzidADQA mPPRcZQwggNeMIICx6ADAgECAhA84jSriQsTpcYCE6HiUrg6MA0GCSqGSIb3DQEBBAUAMF8xCzAJ BgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJs aWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wMDA1MjAwMDAwMDBaFw0wNTA1 MTEyMzU5NTlaMIHQMS4wLAYDVQQKEyVDZXJ0aXNpZ24gQ2VydGlmaWNhZG9yYSBEaWdpdGFsIEx0 ZGEuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMT8wPQYDVQQLEzZUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cuY2VydGlzaWduLmNvbS5ici9SUEEgKGMpMDAxPDA6BgNVBAMTM0Nl cnRpc2lnbiBDbGFzcyAxIENvbnN1bWVyIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTCBnzANBgkq hkiG9w0BAQEFAAOBjQAwgYkCgYEAwv+tzSHkVlZMd8vKtQSOMxeZmi60OqvKGBnqTT/fB2lFkJA4 jyonCwVhW3AoBRmG2CoJHXO8qDGHCJ1euUVhfsBbqEbzpHCXabkQ8nwjdrG2dsNNdjS03ihbqJzS /gYcnikf4pUrYI+ogGvo2l0TzM+d3A1+aABEg1334Ld97ZsCAwEAAaOBqDCBpTApBgNVHREEIjAg pB4wHDEaMBgGA1UEAxMRQ2VydGlzaWduQzFDMi0xLTEwEQYJYIZIAYb4QgEBBAQDAgEGMEcGA1Ud IARAMD4wPAYKYIZIAYb4RQEHDzAuMCwGCCsGAQUFBwIBFiBodHRwczovL3d3dy5jZXJ0aXNpZ24u Y29tLmJyL1JQQTAPBgNVHRMECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOB gQB/ETCpNnaDii6nSsh+8JjF3cNvr1+HRDm5WQ2VsY+JR2NwbNYqYL/JWdagF5C/77rk7my6kwyc H1wByZi5BPcZZfimEkXgbQcad7C6JZLB9huB4KH9YB7/nPVDjl3X6oIU6uDVt8EbOlR6XdG8gd4L AyZAS10UsMt++Dz24MDyTTCCBQ0wggR2oAMCAQICEAGfzOriggkEmT5x2OammSgwDQYJKoZIhvcN AQEEBQAwgdAxLjAsBgNVBAoTJUNlcnRpc2lnbiBDZXJ0aWZpY2Fkb3JhIERpZ2l0YWwgTHRkYS4x HzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxPzA9BgNVBAsTNlRlcm1zIG9mIHVzZSBh dCBodHRwczovL3d3dy5jZXJ0aXNpZ24uY29tLmJyL1JQQSAoYykwMDE8MDoGA1UEAxMzQ2VydGlz aWduIENsYXNzIDEgQ29uc3VtZXIgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMB4XDTAzMDkxNjAw MDAwMFoXDTA0MDkxNTIzNTk1OVowggFmMSswKQYDVQQKFCJDZXJ0aVNpZ24gQ2VydGlmaWNhZG9y YSBEaWdpdGFsIFNBMREwDwYDVQQLFAhDbGFzc2UgMTE3MDUGA1UECxMuVGVybXMgb2YgdXNlIGF0 IHd3dy5jZXJ0aXNpZ24uY29tLmJyL1JQQSAoYykwMDE/MD0GA1UECxM2QXV0aGVudGljYXRlZCBi eSBDZXJ0aXNpZ24gQ2VydGlmaWNhZG9yYSBEaWdpdGFsIEx0ZGEuMScwJQYDVQQLEx5NZW1iZXIs IFZlcmlTaWduIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEb MBkGA1UECxMSRGlnaXRhbCBJRCBDbGFzcyAxMRkwFwYDVQQDExBSb2RyaWdvIEJvdGFmb2dvMSkw JwYJKoZIhvcNAQkBFhpyYm90YWZvZ29AY2VydGlzaWduLmNvbS5icjCBnzANBgkqhkiG9w0BAQEF AAOBjQAwgYkCgYEA5opHs5mo0q+gH3ejR6UJLs6ppE9ssOMLUsrDkeBSNSBd9Z8aBYtGU1vh/1Fo MFDCXEbZflxlBBAualq+O4xxwnL+I0955hPUlpcarTJJ7Tk6NHAHp/U6ajeBR5KWVyuFsrbY6687 V4k6oOBe93eJDfYW5N9O2TEv86GYCKJksSUCAwEAAaOCAU0wggFJMAkGA1UdEwQCMAAwZwYDVR0f BGAwXjBcoFqgWIZWaHR0cDovL29uc2l0ZWNybC5jZXJ0aXNpZ24uY29tLmJyL0NlcnRpU2lnbkNl cnRpZmljYWRvcmFEaWdpdGFsU0FDbGFzc2UxL0xhdGVzdENSTC5jcmwwgawGA1UdIASBpDCBoTCB ngYLYIZIAYb4RQEHAQEwgY4wKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9D UFMwYgYIKwYBBQUHAgIwVjAVFg5WZXJpU2lnbiwgSW5jLjADAgEBGj1WZXJpU2lnbidzIENQUyBp bmNvcnAuIGJ5IHJlZmVyZW5jZSBsaWFiLiBsdGQuIChjKTk3IFZlcmlTaWduMBEGCWCGSAGG+EIB AQQEAwIHgDARBgpghkgBhvhFAQYJBAMBAf8wDQYJKoZIhvcNAQEEBQADgYEAC+ACr4MSMbhFCpPr LhCeQpl/smArUeKUAfMHoO/Xhf9ecpONi++BnMqXGqnhGA2w9foPMLOqGFrwvzb8bPGhxJcqQn8r 1M0litTFOsaSASLrnTEyECgXPBQUHnTyFPPnbw6KU+XQbe4vPETWFkQd7rctBX/6X0SwM8X99q+Q 6OUxggRBMIIEPQIBATCB5TCB0DEuMCwGA1UEChMlQ2VydGlzaWduIENlcnRpZmljYWRvcmEgRGln aXRhbCBMdGRhLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE/MD0GA1UECxM2VGVy bXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LmNlcnRpc2lnbi5jb20uYnIvUlBBIChjKTAwMTwwOgYD VQQDEzNDZXJ0aXNpZ24gQ2xhc3MgMSBDb25zdW1lciBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EC EAGfzOriggkEmT5x2OammSgwDAYIKoZIhvcNAgUFAKCCAq4wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMDQwNDA3MjAwNTAxWjAfBgkqhkiG9w0BCQQxEgQQi5HW5rm7 L5faABmZPNV5QDBfBgkqhkiG9w0BCQ8xUjBQMA4GCCqGSIb3DQMCAgIAgDAKBggqhkiG9w0CBTAL BglghkgBZQIBAQQwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfYGCSsG AQQBgjcQBDGB6DCB5TCB0DEuMCwGA1UEChMlQ2VydGlzaWduIENlcnRpZmljYWRvcmEgRGlnaXRh bCBMdGRhLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE/MD0GA1UECxM2VGVybXMg b2YgdXNlIGF0IGh0dHBzOi8vd3d3LmNlcnRpc2lnbi5jb20uYnIvUlBBIChjKTAwMTwwOgYDVQQD EzNDZXJ0aXNpZ24gQ2xhc3MgMSBDb25zdW1lciBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ECEAGf zOriggkEmT5x2OammSgwgfgGCyqGSIb3DQEJEAILMYHooIHlMIHQMS4wLAYDVQQKEyVDZXJ0aXNp Z24gQ2VydGlmaWNhZG9yYSBEaWdpdGFsIEx0ZGEuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMT8wPQYDVQQLEzZUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cuY2VydGlzaWduLmNv bS5ici9SUEEgKGMpMDAxPDA6BgNVBAMTM0NlcnRpc2lnbiBDbGFzcyAxIENvbnN1bWVyIEluZGl2 aWR1YWwgU3Vic2NyaWJlciBDQQIQAZ/M6uKCCQSZPnHY5qaZKDANBgkqhkiG9w0BAQEFAASBgBiX JuBNGp2wUQBNw89pAVQULBrqAU5MERCekRIaXM2HbRGFw80UDs3xXP9ErNu4ioVbXCmKzVzNVoBZ +K9wJgYkd1j9x+rkOKD8RdSyLRpAWe5x5rlxZe/nKZLG+y6Iy/ymLDU/EWSYn/tRjaMYaJSxEEcR 4NiOw87gCqfDyzbKAAAAAAAA ------=_NextPart_000_03A2_01C41CC2.77081CB0-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37K2cXx027101; Wed, 7 Apr 2004 13:02:38 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i37K2c6W027100; Wed, 7 Apr 2004 13:02:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37K2a3d027088 for <ietf-pkix@imc.org>; Wed, 7 Apr 2004 13:02:37 -0700 (PDT) (envelope-from chokhani@orionsec.com) Received: from wchokhani3 (dpvc-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i37K2fAt000415 for <ietf-pkix@imc.org>; Wed, 7 Apr 2004 16:02:41 -0400 From: "Santosh Chokhani" <chokhani@orionsec.com> To: <ietf-pkix@imc.org> Subject: RE: Current status of CRL validation ? Date: Wed, 7 Apr 2004 16:02:41 -0400 Message-ID: <018c01c41cdb$48899c10$9a00a8c0@hq.orionsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <20040407163512.GA1250@cryptolog.com> Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i37K2b3d027089 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Julien: There is still poor terminology being used. Neither multiple concurrent key pairs nor rekey will lead to the same CA to have the same key. Actually, it is the other way around. The DN will be the same and the keys will be different. Nonetheless, I will try to deal with your example assuming that it is the same CA. First of all, if you can not find a CRL that does not mean you conclude the certificate to be valid. Second, if the certification path you have for the CRL does not match, you do not give up, you try other paths. One of the basic tricks is: try to verify the signature on the CRL using the same CA public key as you used to verify the signature on the certificate whose status you want to check. If that does not succeed, you can create variation of that path one link at a time to account for re-key. Your example has errors and lack of specificity to answer the question. The simply answer is that you do not need a separate path for CRL since PK4 is used to sign both the certificate and CRL. It is also not clear what your thesis or agenda is. May be you are still trying understand it. If you are challenging the rules we have proposed for CRL path, let me know. May be you are saying that certificate issuing CA may not be the only authoritative source for revocation information. If that is the case, I agree with you, but your example does not illustrate that. -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Julien Stern Sent: Wednesday, April 07, 2004 12:35 PM To: ietf-pkix@imc.org Subject: Re: Current status of CRL validation ? On Wed, Apr 07, 2004 at 12:07:34PM -0400, Santosh Chokhani wrote: > > Julien: > > I am not sure that two distinct CAs with the same key (putting aside > the same DN) should be the basis for analysis. That situation will > always lead to problems. We are relying on randomness of large > numbers to help us that this will not happen. > > Consider providing an example where different CAs do not have the same > key. You should view my "two" CAs as the same CA with two different keys. I might not have been totally clear about that, sorry. This can be "either due to multiple concurrent key pairs or due to changeover" (to quote RFC3280 :)). -- Julien > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org > [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Julien Stern > Sent: Wednesday, April 07, 2004 10:45 AM > To: ietf-pkix@imc.org > Subject: Re: Current status of CRL validation ? > > > > On Tue, Mar 23, 2004 at 11:56:01AM -0500, Stephen Kent wrote: > > > > Julien, > > > > The confusion stems from somewhat sloppy use of terminology in these > > discussions. > > > > Only the issuer of a cert can revoke it and in X.509 (unlike PGP) > > there is only one issuer for a given cert. So, the revocation > > question as you stated it was not well formed. > > Stephen, > > I do not believe that only the issuer of a cert can revoke it, notably > when indirect CRL are used. > > > A cert is either revoked or not. > > Well, I'm sincerely starting to believe this is not true :) and not > because of lack of available information. Please point me to the flaw > in the following setting: > > +-----+ +-----+ I have a certificate (Cert). Two > | CA1 | | | Different CAs (CA4 and CA5) have > | DN1 | | DN1 | matching issuer DN and keys for it. > | PK1 | | | > +-----+ +-----+ These two CAs have two super CAs > / \ | signed by the same root. > +-----+ +-----+ +-----+ > | CA2 | | CA3 | | | I also have a CRL which refers to > | DN2 | | DN3 | | DN3 | the certificate but whose only > | PK2 | | PK3 | | | chain up to DN1 is going through > +-----+ +-----+ +-----+ DN4 and DN3 (but NOT DN2). > | | | > +-----+ +-----+ +-----+ Now assume that the left path > | CA4 | | CA5 | | | (CA1 -> CA2 -> CA4 -> Cert) > | DN4 | | DN4 | | DN4 | is valid for SOME policies, and > | PK4 | | PK4 | | | the right path is valid for some > +-----+ +-----+ +-----+ OTHER policies. > \ / | > +-----+ +-----+ > |Cert | | CRL | > +-----+ +-----+ > > If I try to validate the certificate with the "left" policy mappings, > only the "left" chain will be valid. Then, I will check the chain for > the CRL, which will be valid and will match the DN matching rule, so I > will conclude that the certificate is revoked. > > If I try to validate the certificate with the "right" policy mappings, > onle the "right" chain will be valid. Then, I will check the chain for > the CRL, which will not match the DN matching rule, so I will not be > able to verify the validity of the CRL, and hence conclude that the > certificate is valid. > > Sincerely, > > -- > Julien > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37Jaabl024974; Wed, 7 Apr 2004 12:36:36 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i37JaaSA024973; Wed, 7 Apr 2004 12:36:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37JaaqF024966 for <ietf-pkix@imc.org>; Wed, 7 Apr 2004 12:36:36 -0700 (PDT) (envelope-from chokhani@orionsec.com) Received: from wchokhani3 (dpvc-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i37JaeAt023836; Wed, 7 Apr 2004 15:36:40 -0400 From: "Santosh Chokhani" <chokhani@orionsec.com> To: "'Ed Gerck'" <egerck@nma.com> Cc: <ietf-pkix@imc.org> Subject: RE: clarification proposal -- Re: Current status of CRL validation? Date: Wed, 7 Apr 2004 15:36:40 -0400 Message-ID: <016f01c41cd7$a6356500$9a00a8c0@hq.orionsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <40743797.CD0836B@nma.com> Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i37JaaqF024968 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Ed: I see no benefit of having this dialog. Our understanding of security, PKI, X.509, 3280, and ASN.1 are so far apart, I better go and back to kindergarten and learn some stuff. Rest of the PKIXers: My lack of response to Ed on this thread from now on should not be viewed as concurrence. -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Ed Gerck Sent: Wednesday, April 07, 2004 1:17 PM To: Santosh Chokhani Cc: ietf-pkix@imc.org Subject: Re: clarification proposal -- Re: Current status of CRL validation? Santosh Chokhani wrote: > Please read X.509 and 3280 carefully. There is no mechanism to limit > the time of delegation. I find this interpretation interesting. I wonder how many people would agree with that. We now have eternal certs, that don't expire and cannot be revoked. This would certainly solve the revocation problem ;-) As an alternative reading to eternal delegation, X.509 should be interpreted in its entirety. Since there is nothing that mandates eternal delegation, the CA is free to use its CPS to control delegation as the CA so chooses --including expiration dates and revocation mechanisms-- both off-line and on-line. > See the syntax and semantics of CRL DP extension. I see the semantics of the CPS. There is nothing stated there that would bar a CA from limiting the time and scope of delegation. > Also, there is no requirement for the certificate issuing CA to issue > a CRL My point exactly -- the CA can control all aspects of its revocation management policy. > and if the Indirect CRL is checked by the relying party, there is no > requirement to check any CRL issued by the issuing CA. Yes, but that check was not done absolutely. It was done in reference to what the issuer CA defines in its CPS, including its revocation management policy. For example, look for words such as "...MAKES NO REPRESENTATION ..." and "...MAKES NO ASSURANCES ...". The issuer CA can also change its CPS at any time, possibly excluding any delegation from some time on. > Actually, if the CRL DP extension is marked critical and it points to > an indirect CRL issuer, you MUST check that CRL. My point exactly -- the issuer CA can control all aspects of its revocation management policy. Let's ask, who signed that critical CRL DP extension? Who controls whether the RP MUST check that CRL at that indirect CRL issuer or not? Further, who can revoke such critical CRL DP extension? Cheers, Ed Gerck Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37JXtxV024794; Wed, 7 Apr 2004 12:33:55 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i37JXtQf024793; Wed, 7 Apr 2004 12:33:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37JXt9n024787 for <ietf-pkix@imc.org>; Wed, 7 Apr 2004 12:33:55 -0700 (PDT) (envelope-from chokhani@orionsec.com) Received: from wchokhani3 (dpvc-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i37JXxAt022935 for <ietf-pkix@imc.org>; Wed, 7 Apr 2004 15:33:59 -0400 From: "Santosh Chokhani" <chokhani@orionsec.com> To: <ietf-pkix@imc.org> Subject: RE: Signing Untrusted SCVP? Date: Wed, 7 Apr 2004 15:33:59 -0400 Message-ID: <016e01c41cd7$4617d590$9a00a8c0@hq.orionsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <340B5AC242DEF44AAFCD6DC102B51CD30595E605@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i37JXt9n024788 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Trevor: >From technical philosophy viewpoint, I do not have a problem. But, from my understanding of how IETF works, given that the benefit is minimal, we need to define the standard that accommodates products with varying degree of functionality. I think SCVP requirement to sign DPD responses may be too much. -----Original Message----- From: Trevor Freeman [mailto:trevorf@windows.microsoft.com] Sent: Wednesday, April 07, 2004 2:07 PM To: Santosh Chokhani; ietf-pkix@imc.org Subject: RE: Signing Untrusted SCVP? Hi Santosh, My argument cannot be construed as an argument to sign everything. It is an argument to sign all positive responses. I am equally not convinced that no singing achieves anything other than weaker security. The act of signing is not a major burden, especially if this is no longer on a per request basis and allows the client to be assured of positive. Not signing positive responses allows an attacker to manipulate the client beyond inserting errors which is very, very bad. How the server protects the cache is an implementation decision. Assuming untrusted transport is reasonable for the RFC. Trevor -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Santosh Chokhani Sent: Wednesday, April 07, 2004 9:00 AM To: ietf-pkix@imc.org Subject: RE: Signing Untrusted SCVP? Trevor: This argument can be the basis for signing everything all the time, which we do not do. The attacker can still manipulate and inject data. I am not persuaded by the argument that checking the signature first will save lot of client processing time. If the product developer and consumers want to have the option for not signing this data, they should. I see a bigger problem with the DPD server maintaining a cache and some one attacking that cache (if unsigned) since a stationary server may be easier to hack at then data in transit. Now, if the DPD server signed cached paths on request or if the DPD, you have the same problem. Also, my suggestion would be for the client to have the option of requesting signed responses and having the option of rejecting responses that are not signed. -----Original Message----- From: Trevor Freeman [mailto:trevorf@windows.microsoft.com] Sent: Wednesday, April 07, 2004 11:46 AM To: Santosh Chokhani; ietf-pkix@imc.org Subject: RE: Signing Untrusted SCVP? I think there is significant value in signing the response from the SCVP server. Given the main issue seems to be SCVP operating in an environment where an attacker has the ability to inject packets going between client and server into the data stream. Signing the response relegates the attacker to injecting error packets - which is a low grade DoS. Sending unsigned responses allows the attacker to inject a packed as the server whatever they want as a genuine response, with certificates and content of there choosing. So we just turned every SCVP client into a potential web beacon. Where the client has direct trust in the server signing key this is a very secure process with DPD. Trevor -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Santosh Chokhani Sent: Wednesday, April 07, 2004 5:32 AM To: ietf-pkix@imc.org Subject: RE: Signing Untrusted SCVP? Given the limited value of signature, DPD response signature by the server should be optional and signature verification by the client should be optional. The question we should answer is that is there any benefit to adding an option for the client to request a signature and then should the DPD server be forced to sign the response (shades of OCSP nonce) -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of David Engberg Sent: Tuesday, April 06, 2004 11:32 PM To: Stephen Kent Cc: ietf-pkix@imc.org Subject: Re: Signing Untrusted SCVP? Stephen - You have provided interesting techniques that an attacker could use to make a DPD client waste an extra 500ms verifying signatures before displaying a "bad path returned from server" dialog (or the equivalent). That same attacker with the same advantages (DNS spoofing, etc.) could achieve the same effective denial of path discovery even if an extra signature is thrown on responses. The attacker could obviously make clients waste time & bandwidth in lots of sneaky ways, although the relying application would ultimately report different error messages ("unknown host: 'scvp.eubridge.org'", "connection timed out", "no route to host", "response signature verify failed", etc.). I am curious whether the type of attack that you describe has ever been performed against a non-SSL LDAP directory in a manner that would not have been equally effective if SSL was in use. While there is definitely a difference here, I think (hope?) that we agree that it may be useful for a PKI administrator to have the choice to deploy a path discovery mechanism which does not require a fresh signature from a protected server key for every request. This would allow an administrator to balance the DoS risks for clients against the DoS risks for servers. My guess is that virtually all real world DoS attacks exploit the centralized nature of secured servers, and the best cure for this is the sort of distributed redundancy that a keyless or two-tier-caching DPD responder architecture would permit. For example, Akamai has 16,000+ servers around the world with no SSL private keys. They are subjected to daily DoS attempts (e.g. they host www.whitehouse.gov), which fail not due to the magic of PKI, but rather due to the redundancy you can build when you don't have to secure keys at every server. Thanks Stephen Kent wrote: ... > if an attacker can spoof a DNS response, he can cause the client to > connect to him instead of the server, which would enable the bogus > server to receive the request as well as generate and send the > response, and in the absence of a signed response, the client cannot > know that he is not communicating with the intended server. > > a bogus server could then return bogus cert chains that fail to > validate, but which waste client resources. just how effective this > may be will be a function of client implementation details, which are > outside the scope of our standards. ... Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37JTpVT024362; Wed, 7 Apr 2004 12:29:51 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i37JTpdn024361; Wed, 7 Apr 2004 12:29:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37JTors024355 for <ietf-pkix@imc.org>; Wed, 7 Apr 2004 12:29:50 -0700 (PDT) (envelope-from chokhani@orionsec.com) Received: from wchokhani3 (dpvc-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i37JTsAt021493 for <ietf-pkix@imc.org>; Wed, 7 Apr 2004 15:29:54 -0400 From: "Santosh Chokhani" <chokhani@orionsec.com> To: <ietf-pkix@imc.org> Subject: RE: Re-certification Date: Wed, 7 Apr 2004 15:29:54 -0400 Message-ID: <016b01c41cd6$b4505880$9a00a8c0@hq.orionsec.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <01d701c41cb7$b4234620$be00a8c0@jurujuba> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0167_01C41CB5.2CEC52C0" Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> This is a multi-part message in MIME format. ------=_NextPart_000_0167_01C41CB5.2CEC52C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit As my answer said, there would not be a problem with CRL since each serial number will be unique and both keys will be used to sign the CRL. Please go back and read my response. -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Rodrigo Botafogo Sent: Wednesday, April 07, 2004 11:48 AM To: ietf-pkix@imc.org Subject: RES: Re-certification Thanks for the answers, but I haven't seen any comments about the CRL issue that I've also asked about. Anybody cares to comment. I see that there is a thread about CRL validation and it might somehow indicate how the validation in this case should happen. As I have stated previously, We've made some tests and when a new key is generated for the same DN, some RP, Outlook for instance, sees the CRL signed with the new key as another CA and not the same CA with a new key. Certificates revoked before the new key generation are not seen as revoked, the RP seems to tread the CRL as an "invalid" CRL for this certificate. I couldn't find anyway to configure Outlook so that it would recognize that the cert was revoked. Is there any application out there that does the right thing? Sorry if discussing real apps is not in the scope of the group. If so, let me know. Thanks again, Rodrigo Jean-Marc Desperrier <jmdesp@free.fr> writes: >AFAIK I have never seen Verisign *change* the key pair of an authority. They >always extend validity, while keeping the same key pair. Ah, sorry, I was a bit too quick in my reply, what I meant was that they kept the DN, key, and start date, and only changed the end date and serial number. I was never quite sure why they kept the validFrom date, I can understand wanting to leave a bit of overlap, but the new certs were backdated many years through the direct copying of the validFrom. Peter. ------=_NextPart_000_0167_01C41CB5.2CEC52C0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQyzCCA9Yw ggK+oAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwVTELMAkGA1UEBhMCVVMxITAfBgNVBAoTGE9yaW9u IFNlY3VyaXR5IFNvbHV0aW9uczELMAkGA1UECxMCSFExFjAUBgNVBAMTDU9yaW9uIFJvb3QgQ0Ew HhcNMDMwODEzMTcwMTI0WhcNMTMwODEwMTcwMTI0WjBVMQswCQYDVQQGEwJVUzEhMB8GA1UEChMY T3Jpb24gU2VjdXJpdHkgU29sdXRpb25zMQswCQYDVQQLEwJIUTEWMBQGA1UEAxMNT3Jpb24gUm9v dCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOd3fg/nIELr3rAuxpkcxiAn7ayU /30RPxYBMgcvn0BJbBXBXIkTHgm3jh0TwHGQk76nqTSo1fUqpkkEcSSwEtfz1jF0QCKPHoQvNxza 5ffqH2gBSTgjpwqLA34RDxFDwcdNibIG/s6Zj2PpVDDWVBYxMbLrhKluMAfufhOMT6uyYxw+XPcU ndqy4bRo08BONIoLdoUoOsvOwHla+zPYsBnTncMEL26lnKgCQgJpcFfrQRLrM84Rlc9EmvPbU+tO 5jRfdnvJpCm8LbIcTvAwQLiM+5qr4GPTg73S+9ZMAjlaZWG/VGe5b+KtQCgDu2TPB+wtiz2csG5q YN14mFpKMdMCAwEAAaOBsDCBrTAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNV HQ4EFgQUvpoqeR5tpH+G2bn1P06LoHH9Mq0wHwYDVR0jBBgwFoAUvpoqeR5tpH+G2bn1P06LoHH9 Mq0wEQYJYIZIAYb4QgEBBAQDAgAHMDcGA1UdHwQwMC4wLKAqoCiGJmh0dHA6Ly93d3cub3Jpb25z ZWMuY29tL29yaW9uX3Jvb3QuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAch1imNzh8/wx6Ym3ti6FI LyJMsktilc4I5zJ6ZRrZUMye/3v9XJDIutBPb472wOwQT+OR3DTbWX8loNybf3Ew3wWzZg+D14kQ d/+rm3ZAJ3EeX67/g9XevAkrv951Q7QSucZMbbzrLqIWSkgjxJbcujNdeQsSlUz5I2Q9qYdAhg6G 85gf+GaStpaGlR5siWwJAQ/KeWrntfwNbh1P81Vmq/MovUQWPNKeM80FHcqHVVpQWasPTkGb0eW2 NOBsxGBCSQjc5QQdxPIMIuxmyVX42kGTK3O/IxI2O2QBK+pmFHEm4o+p+ekxxHekZTowPSeFXFYQ SrnpmJyfcHa2vLTpMIID1zCCAr+gAwIBAgIBAjANBgkqhkiG9w0BAQUFADBVMQswCQYDVQQGEwJV UzEhMB8GA1UEChMYT3Jpb24gU2VjdXJpdHkgU29sdXRpb25zMQswCQYDVQQLEwJIUTEWMBQGA1UE AxMNT3Jpb24gUm9vdCBDQTAeFw0wMzA4MTQxNjQ4MzZaFw0wNDA4MTMxNjQ4MzZaMFYxCzAJBgNV BAYTAlVTMSEwHwYDVQQKExhPcmlvbiBTZWN1cml0eSBTb2x1dGlvbnMxCzAJBgNVBAsTAkhRMRcw FQYDVQQDEw5PcmlvbiBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL65 aM5ISSZ1ERaIjEaBDvZJ+U1iEEvdLoILkmuwzqrN0DMNhBwLUPJSYjGZ6xlGE5sRmDbUcFhRX0Dt p/t0lKBl0zajquPRbO5t3whqhb0h5IgIRP19NOZ9Mo/XWML2eCVmDyy6lqK5NC+Uvdhf8SjjH+P2 WCk68KmELfqXSfHoKy9gKMEH9IFyL1EqbE8DTUuFmUzg3ZIpR9UMX0Yorx4YdQRyblH4fEUDNfUu PHvRTZkyfAm8nrpsWCqOY0Q3Vl6OsfMqBaVYOORA9fDPLZLXvYc7Im3LDTAXvy+DTki2cR3rjLrO +p3POH/SoH8/9eHhNk4fX/w4FvQMv9hIonECAwEAAaOBsDCBrTAPBgNVHRMBAf8EBTADAQH/MA4G A1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQU+NvSaD0SiHYB9QkgqlK4n+fFAKEwHwYDVR0jBBgwFoAU vpoqeR5tpH+G2bn1P06LoHH9Mq0wEQYJYIZIAYb4QgEBBAQDAgAHMDcGA1UdHwQwMC4wLKAqoCiG Jmh0dHA6Ly93d3cub3Jpb25zZWMuY29tL29yaW9uX3Jvb3QuY3JsMA0GCSqGSIb3DQEBBQUAA4IB AQDPS+PvtkWJ6V235n4Ntn5xWFgvS+GVMI3tBVid/DW2h3AxDWzKctlybc/FhO0sj7nlLXE5CQfm ocx7m3mf1DcEz83b3BJNO9Dwa0U1kNL0kAFSXb9i+jaL3ovNoZlXxOcl73dK77eEohYbioUOtglM HwXXOdbpbOPH1tX0fUr70Zp4KBczNdsQnSrbnHIe2zdNPKY5VPYonB6gxJTNxlbqcHYg56abe0En Ad0C5IoMEG13CbHfDCm9uhRC5yHfylEZMOYA644+2d73FUsIstAdwK+pyeWXSaWGwN/xgLAGE5S1 Ryihlql/q4BXxqqU8RPm90g+2aj1e+PlnlXHxLWCMIIEdzCCA1+gAwIBAgIBIjANBgkqhkiG9w0B AQUFADBWMQswCQYDVQQGEwJVUzEhMB8GA1UEChMYT3Jpb24gU2VjdXJpdHkgU29sdXRpb25zMQsw CQYDVQQLEwJIUTEXMBUGA1UEAxMOT3Jpb24gRW1haWwgQ0EwHhcNMDMwODE1MTgyMDM3WhcNMDQw ODE0MTgyMDM3WjB+MQswCQYDVQQGEwJVUzEhMB8GA1UEChMYT3Jpb24gU2VjdXJpdHkgU29sdXRp b25zMQswCQYDVQQLEwJIUTEZMBcGA1UEAxMQU2FudG9zaCBDaG9raGFuaTEkMCIGCSqGSIb3DQEJ ARYVY2hva2hhbmlAb3Jpb25zZWMuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA 0EadobvmWyC1UbtEuos8DmEK7vsk72z3USFc4MF4I71ctasTuT7n3eY0RsXK5NSrGNufwwup7ksd ZAo/a6GPxiGMDOaQtJi8VaACzPUyqzZZJEKtaolcD4fS8V6OFyBdMmdMBebd0GrcNVmabvgVIm3h 5Oe3sUzZxqkduueAkjMstGnBtUWG431HzM3vOTzkbHzkMoNTFgMEayhHrklyecveHOgiqhOypAiK Sv5acM2vgzreh5gbHEJfqOfS56+exTAz/MrpdzvXmv0kmrwMBOtTM1rOYhyjw2yzM07lBxstBMR0 DIeqpf2dZN1IHOnnGWxSqql2Gdjn9bpplVN2EQIDAQABo4IBJjCCASIwHQYDVR0OBBYEFPQLCXgN tykUjPyCwMO9MWrT0A86MB8GA1UdIwQYMBaAFPjb0mg9Eoh2AfUJIKpSuJ/nxQChMDcGA1UdHwQw MC4wLKAqoCiGJmh0dHA6Ly93d3cub3Jpb25zZWMuY29tL29yaW9uX21haWwuY3JsMAkGA1UdEwQC MAAwQgYIKwYBBQUHAQEENjA0MDIGCCsGAQUFBzAChiZodHRwOi8vd3d3Lm9yaW9uc2VjLmNvbS9v cmlvbl9tYWlsLmRlcjAOBgNVHQ8BAf8EBAMCBDAwEwYDVR0lBAwwCgYIKwYBBQUHAwQwEQYJYIZI AYb4QgEBBAQDAgWgMCAGA1UdEQQZMBeBFWNob2toYW5pQG9yaW9uc2VjLmNvbTANBgkqhkiG9w0B AQUFAAOCAQEAOMNwcRoKaH2+5wC7MWhDrG98bOyphlE51btwmPHS9Ob5XpJMJMlZI2kb2/4A71ri aZZPcuFypMqxGIjaH7Y/Gi0aHsk7iWRMEMXiaCT2fq0WM1Wq/sDgwMYVCvOjU8s5x+4i7y4tvS/e P01qcmqz5RABM85bmZ45qypM+JV246LxYRkVpESl62+iSkcgU8hmtruiV7C8CX3yUZj//uwPH9F+ 7iwvSEAmH6vm4MxGxrMbo2yThsvJ6KNZ1XVlT3jtA66AhoKBh++f7KfuqJbWUaQXVuvGESCHI79D CtXVUK7YFdHQxLU1Y63NkqRYTncrHtJlqzY2kxq5B/0vnPhg1zCCBJcwggN/oAMCAQICASEwDQYJ KoZIhvcNAQEFBQAwVjELMAkGA1UEBhMCVVMxITAfBgNVBAoTGE9yaW9uIFNlY3VyaXR5IFNvbHV0 aW9uczELMAkGA1UECxMCSFExFzAVBgNVBAMTDk9yaW9uIEVtYWlsIENBMB4XDTAzMDgxNTE4MjAx N1oXDTA0MDgxNDE4MjAxN1owfjELMAkGA1UEBhMCVVMxITAfBgNVBAoTGE9yaW9uIFNlY3VyaXR5 IFNvbHV0aW9uczELMAkGA1UECxMCSFExGTAXBgNVBAMTEFNhbnRvc2ggQ2hva2hhbmkxJDAiBgkq hkiG9w0BCQEWFWNob2toYW5pQG9yaW9uc2VjLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAMLUZwZhoWYVw7zKNe5KLxQfXo0dKMKkph9MA+fNX9YPW/LEbsjqdofCRJ1F8VZalpBr lz61ITyJ7/y+W1My0n0oOJhwvdhqRxE2QUv+bOP80i7BGqIm4/wd35ZyABDG2mt5Jj2anwXUIK1K ENCo1pYxhroil3qLhtd9xPiOOjUZ2wAmNEgFwxDcQE1xsNJtJ3Ro1O3VfceF53AxomEIZM300usi xqnUSKbk8D8oVwUNBnMXdj+7K/0G/YJ9EPJFF5orwI1j9LE3tdWBVY9a7WY1+ygHDMXaeYAnM2Tk AuVGtWqTHTGmdNuyxsapFY7UFLtRjItA2oFb3bs/ho1tKrUCAwEAAaOCAUYwggFCMB0GA1UdDgQW BBQSo0Fab6xpwZ5BxERoEuUigr/N2zAfBgNVHSMEGDAWgBT429JoPRKIdgH1CSCqUrif58UAoTA3 BgNVHR8EMDAuMCygKqAohiZodHRwOi8vd3d3Lm9yaW9uc2VjLmNvbS9vcmlvbl9tYWlsLmNybDAJ BgNVHRMEAjAAMEIGCCsGAQUFBwEBBDYwNDAyBggrBgEFBQcwAoYmaHR0cDovL3d3dy5vcmlvbnNl Yy5jb20vb3Jpb25fbWFpbC5kZXIwDgYDVR0PAQH/BAQDAgbAMDMGA1UdJQQsMCoGCCsGAQUFBwMC BggrBgEFBQcDBAYIKwYBBQUHAwcGCisGAQQBgjcUAgIwEQYJYIZIAYb4QgEBBAQDAgWgMCAGA1Ud EQQZMBeBFWNob2toYW5pQG9yaW9uc2VjLmNvbTANBgkqhkiG9w0BAQUFAAOCAQEAmnUXuCAU2nzN bCAaRmH0JE1bFUr/bNPUoOHU7ATGfmk/QhiGPxaApPSU+CC8JNgGOs6z6o/WCfKMj4srMkWjBKcF HNASw7oxsLdEj/JvIAcPVPwfV4RUBY7SU3svNPQILSYdD0LUuhryAqMlNePrDPi5LWSyJ1q4ftRt ZZlJdu50UjBSPwJcOhrn4CJAzu4DHRAWNLvVZ91m7c/E6LF4Ajj1QC8Sd2HWpgc0iQf7XAN58+7Y 9fF+F6VebVeuLws2IZNPfdTvq+1kHTOCVYasbh2IqdM7ryyrz3rL0l3LOySD73mv/YU4Dt1brScF Xq4hA5IcXNGvyn1gUw3HD8/cbjGCAyYwggMiAgEBMFswVjELMAkGA1UEBhMCVVMxITAfBgNVBAoT GE9yaW9uIFNlY3VyaXR5IFNvbHV0aW9uczELMAkGA1UECxMCSFExFzAVBgNVBAMTDk9yaW9uIEVt YWlsIENBAgEhMAkGBSsOAwIaBQCgggGgMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTA0MDQwNzE5Mjk1NFowIwYJKoZIhvcNAQkEMRYEFGTb2mYBOaRnXOkgmrDOiSmr 5+P2MGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwBwYFKw4DAhowDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAoGCCqGSIb3DQIFMGoGCSsG AQQBgjcQBDFdMFswVjELMAkGA1UEBhMCVVMxITAfBgNVBAoTGE9yaW9uIFNlY3VyaXR5IFNvbHV0 aW9uczELMAkGA1UECxMCSFExFzAVBgNVBAMTDk9yaW9uIEVtYWlsIENBAgEiMGwGCyqGSIb3DQEJ EAILMV2gWzBWMQswCQYDVQQGEwJVUzEhMB8GA1UEChMYT3Jpb24gU2VjdXJpdHkgU29sdXRpb25z MQswCQYDVQQLEwJIUTEXMBUGA1UEAxMOT3Jpb24gRW1haWwgQ0ECASIwDQYJKoZIhvcNAQEBBQAE ggEAG6qOY1e5YKwqvRmsQTssab4aUaF/td/qD0aBffkWP+nQYMlCdoLkkt1vzNyfhwjbWeTR6+9R ftaRu2cYN+T0aS8zd7zCSbDn+Hkx7afULtSpkos6T4Sbq3V3Burva/iNS0Xfd6xRhco/hsj7p5+y P2lb7HBN4rVCnUEDTs4IycX14FM+8ZjzQWScizR8lz5q0Yx+KjZLohrwq6JQAXUVIpbxl5z+raha plhQztjZ05pWAqGqlA/+9GJWQX+G1DMEBrHyz2EyJxE1m+n2us6Fjx5nfl/SJsGa9fy/UJJL7I4X cZ+O3pJQX4oY/t6TIwSDirmTTXFy5M2rVepibusJyAAAAAAAAA== ------=_NextPart_000_0167_01C41CB5.2CEC52C0-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37ImEm7021678; Wed, 7 Apr 2004 11:48:14 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i37ImE59021677; Wed, 7 Apr 2004 11:48:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail7.atl.registeredsite.com (nobody@mail7.atl.registeredsite.com [64.224.219.81]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37ImER0021670 for <ietf-pkix@imc.org>; Wed, 7 Apr 2004 11:48:14 -0700 (PDT) (envelope-from egerck@nma.com) Received: from taurus.hosting4u.net (taurus.hosting4u.net [209.35.191.122]) by mail7.atl.registeredsite.com (8.12.8/8.12.8) with ESMTP id i37ImH9F002958 for <ietf-pkix@imc.org>; Wed, 7 Apr 2004 18:48:17 GMT Received: from nma.com ([63.204.17.85]) by taurus.hosting4u.net ; Wed, 07 Apr 2004 13:48:16 -0500 Message-ID: <40744CAD.A9FA6983@nma.com> Date: Wed, 07 Apr 2004 11:47:09 -0700 From: Ed Gerck <egerck@nma.com> X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: PKIX <ietf-pkix@imc.org> Subject: Re: clarification proposal -- Re: Current status of CRL validation? References: <0C3042E92D8A714783E2C44AB9936E1DE352CC@EUR-MSG-03.europe.corp.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Rcpt-To: <ietf-pkix@imc.org> Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Stefan Santesson wrote: > > The basic assumption for the whole discussion seems to be very confused: > > Snip: > > > > "Since there may be more than one path used to validate the > > same certificate, it is possible that some paths to that > > certificate are valid while others are not." > > > > There is only 1 kind of path that can be used to validate a certificate, > and that is a valid path. Valid to a RP may not be valid to another RP. To clarify this, the text could say: Since there may be more than one path used to validate the same certificate, it is possible that some paths to that certificate are valid for some RPs while not valid to other RPs. > Valid being defined as a path that pass the > RPs validation policy (defined at the discretion of the relying party). Exactly. It depends on what each RP may choose to rely upon. Different RPs may define "valid path" in a different way. The RP may also receive different answers from valid paths. > All other paths are invalid by definition. So among the valid paths > there is no ambiguity, since they are all valid. > > Why complicate things? The RPs are complicated ;-) Cheers, Ed Gerck Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37IMUnU019086; Wed, 7 Apr 2004 11:22:30 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i37IMUKw019085; Wed, 7 Apr 2004 11:22:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail1.atl.registeredsite.com (nobody@mail1.atl.registeredsite.com [64.224.219.75]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37IMTl3019078 for <ietf-pkix@imc.org>; Wed, 7 Apr 2004 11:22:29 -0700 (PDT) (envelope-from egerck@nma.com) Received: from taurus.hosting4u.net (taurus.hosting4u.net [209.35.191.122]) by mail1.atl.registeredsite.com (8.12.8/8.12.8) with ESMTP id i37IMRKw018419; Wed, 7 Apr 2004 18:22:27 GMT Received: from nma.com ([63.204.17.85]) by taurus.hosting4u.net ; Wed, 07 Apr 2004 13:22:25 -0500 Message-ID: <40744697.70E81808@nma.com> Date: Wed, 07 Apr 2004 11:21:11 -0700 From: Ed Gerck <egerck@nma.com> X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Stephen Kent <kent@bbn.com> CC: "David P. Kemp" <dpkemp@missi.ncsc.mil>, ietf-pkix@imc.org Subject: restated -- Re: clarification proposal -- Re: Current status of CRLvalidation? References: <20040323103412.GA23286@cryptolog.com> <004f01c410dc$2c0681d0$df294d0c@hq.orionsec.com> <20040323142525.GA27672@cryptolog.com> <p06020406bc861b0a4627@[128.33.244.157]> <406A0839.14F7C3A1@nma.com> <p06020401bc909a0b8ec1@[128.89.89.75]> <406B0593.FD2E1F6B@nma.com> <p06020408bc90bbc275a7@[128.89.89.75]> <406DE8AD.BC0DA38@nma.com> <p06020411bc9750745da7@[128.89.89.75]> <4071AB84.14898140@nma.com> <p0602041ebc977ad14b67@[128.89.89.75]> <4071DE2E.B5BED74A@nma.com> <p06020405bc9860671a8f@[128.89.89.75]> <4072EABB.D2A50271@nma.com> <p06020412bc98a5af5793@[128.89.89.75]> <40733B79.2A0AF2C8@nma.com> <p06020405bc99b8e5d82e@[128.89.89.75]> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Steve, We agree. The purpose, after all is to clarify ;-) There are three meanings re that pesky phrase "...anything other than their value as a representation of the issuer CA revocation management policy." The first two you list in your reply inlined below. The third meaning has to do with limitations on the edge cases mentioned by Santoshi: - relying on revocation status mechanisms such as OCSP and indirect CRLs is subject to conditions defined the issuer CA. Based on the input so far, I now restate the clarification NOTE. NOTE: In X.509/PKIX only the issuer of a certificate is authoritative for revocation and there is only one issuer for a given certificate. Therefore, a certificate is either revoked or not from the issuer CA point of view. From the RP point of view, the ability of a RP to establish the validity of a certificate is a function of the certificate path that the RP uses to validate the certificate, and of the access to revocation status information available to the RP. Since there may be more than one path used to validate the same certificate, it is possible that some paths to that certificate are valid while others are not. It is also possible to obtain different answers to the question whether a certificate is valid or not. Also, two RPs may have access to different revocation status data for the EE certificate or for a CA certificate along a path, so that each RP may arrive at a different view of the validity of the EE certificate at any given time. When a RP relies on revocation status mechanisms such as OCSP and indirect CRLs, the data is subject to conditions defined by the issuer of the certificate. Such conditions may change from time to time. Also, the RP may not have direct evidence of the issuer CA's assertion of a certificate's revocation status at that time. In terms of a RP software, resolution may be difficult in practical terms. For example, it may need more time than what's available, and/or need additional channels not included/reachable by that RP software, and/or need human intervention. However, because a RP is always subject to conditions defined the issuer CA, revocation status is ultimately definable by a RP. Comments? Cheers, Ed Gerck Stephen Kent wrote: > > Ed, > > We agree that there are some edge cases re revocation, as Santosh > noted. My objection to your text is that it fails to clarify. > > If you meant to say that > - only the issuer of a cert is authoritative for revocation, and > - relying on revocation status mechanisms such as OCSP and > indirect CRLs may not provide direct evidence of the issuer's > assertion of a cert's revocation status > > then say that. phrases like "...anything other than their value as a > representation of the issuer CA revocation management policy" are > just not helpful to most folks. > > Steve Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37I6wQA017668; Wed, 7 Apr 2004 11:06:58 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i37I6wj1017667; Wed, 7 Apr 2004 11:06:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37I6v76017660 for <ietf-pkix@imc.org>; Wed, 7 Apr 2004 11:06:57 -0700 (PDT) (envelope-from trevorf@windows.microsoft.com) Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 7 Apr 2004 11:06:07 -0700 Received: from 157.54.6.197 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 07 Apr 2004 11:06:55 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by INET-HUB-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 7 Apr 2004 11:06:55 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 7 Apr 2004 11:06:55 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 7 Apr 2004 11:06:54 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7195.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Signing Untrusted SCVP? Date: Wed, 7 Apr 2004 11:06:54 -0700 Message-ID: <340B5AC242DEF44AAFCD6DC102B51CD30595E605@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Signing Untrusted SCVP? thread-index: AcQcwhcJ12iwHTU8ThSEyQZFN1H+MgABZn/A From: "Trevor Freeman" <trevorf@windows.microsoft.com> To: "Santosh Chokhani" <chokhani@orionsec.com>, <ietf-pkix@imc.org> X-OriginalArrivalTime: 07 Apr 2004 18:06:54.0759 (UTC) FILETIME=[1C0A4370:01C41CCB] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i37I6v76017662 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Hi Santosh, My argument cannot be construed as an argument to sign everything. It is an argument to sign all positive responses. I am equally not convinced that no singing achieves anything other than weaker security. The act of signing is not a major burden, especially if this is no longer on a per request basis and allows the client to be assured of positive. Not signing positive responses allows an attacker to manipulate the client beyond inserting errors which is very, very bad. How the server protects the cache is an implementation decision. Assuming untrusted transport is reasonable for the RFC. Trevor -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Santosh Chokhani Sent: Wednesday, April 07, 2004 9:00 AM To: ietf-pkix@imc.org Subject: RE: Signing Untrusted SCVP? Trevor: This argument can be the basis for signing everything all the time, which we do not do. The attacker can still manipulate and inject data. I am not persuaded by the argument that checking the signature first will save lot of client processing time. If the product developer and consumers want to have the option for not signing this data, they should. I see a bigger problem with the DPD server maintaining a cache and some one attacking that cache (if unsigned) since a stationary server may be easier to hack at then data in transit. Now, if the DPD server signed cached paths on request or if the DPD, you have the same problem. Also, my suggestion would be for the client to have the option of requesting signed responses and having the option of rejecting responses that are not signed. -----Original Message----- From: Trevor Freeman [mailto:trevorf@windows.microsoft.com] Sent: Wednesday, April 07, 2004 11:46 AM To: Santosh Chokhani; ietf-pkix@imc.org Subject: RE: Signing Untrusted SCVP? I think there is significant value in signing the response from the SCVP server. Given the main issue seems to be SCVP operating in an environment where an attacker has the ability to inject packets going between client and server into the data stream. Signing the response relegates the attacker to injecting error packets - which is a low grade DoS. Sending unsigned responses allows the attacker to inject a packed as the server whatever they want as a genuine response, with certificates and content of there choosing. So we just turned every SCVP client into a potential web beacon. Where the client has direct trust in the server signing key this is a very secure process with DPD. Trevor -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Santosh Chokhani Sent: Wednesday, April 07, 2004 5:32 AM To: ietf-pkix@imc.org Subject: RE: Signing Untrusted SCVP? Given the limited value of signature, DPD response signature by the server should be optional and signature verification by the client should be optional. The question we should answer is that is there any benefit to adding an option for the client to request a signature and then should the DPD server be forced to sign the response (shades of OCSP nonce) -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of David Engberg Sent: Tuesday, April 06, 2004 11:32 PM To: Stephen Kent Cc: ietf-pkix@imc.org Subject: Re: Signing Untrusted SCVP? Stephen - You have provided interesting techniques that an attacker could use to make a DPD client waste an extra 500ms verifying signatures before displaying a "bad path returned from server" dialog (or the equivalent). That same attacker with the same advantages (DNS spoofing, etc.) could achieve the same effective denial of path discovery even if an extra signature is thrown on responses. The attacker could obviously make clients waste time & bandwidth in lots of sneaky ways, although the relying application would ultimately report different error messages ("unknown host: 'scvp.eubridge.org'", "connection timed out", "no route to host", "response signature verify failed", etc.). I am curious whether the type of attack that you describe has ever been performed against a non-SSL LDAP directory in a manner that would not have been equally effective if SSL was in use. While there is definitely a difference here, I think (hope?) that we agree that it may be useful for a PKI administrator to have the choice to deploy a path discovery mechanism which does not require a fresh signature from a protected server key for every request. This would allow an administrator to balance the DoS risks for clients against the DoS risks for servers. My guess is that virtually all real world DoS attacks exploit the centralized nature of secured servers, and the best cure for this is the sort of distributed redundancy that a keyless or two-tier-caching DPD responder architecture would permit. For example, Akamai has 16,000+ servers around the world with no SSL private keys. They are subjected to daily DoS attempts (e.g. they host www.whitehouse.gov), which fail not due to the magic of PKI, but rather due to the redundancy you can build when you don't have to secure keys at every server. Thanks Stephen Kent wrote: ... > if an attacker can spoof a DNS response, he can cause the client to > connect to him instead of the server, which would enable the bogus > server to receive the request as well as generate and send the > response, and in the absence of a signed response, the client cannot > know that he is not communicating with the intended server. > > a bogus server could then return bogus cert chains that fail to > validate, but which waste client resources. just how effective this > may be will be a function of client implementation details, which are > outside the scope of our standards. ... Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37Hv8Yp016797; Wed, 7 Apr 2004 10:57:08 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i37Hv8vu016796; Wed, 7 Apr 2004 10:57:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp-ft5.fr.colt.net (smtp-ft5.fr.colt.net [213.41.78.204]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37Hv7Wx016783 for <ietf-pkix@imc.org>; Wed, 7 Apr 2004 10:57:08 -0700 (PDT) (envelope-from jmdesp@free.fr) Received: from free.fr (host.106.92.68.195.rev.coltfrance.com [195.68.92.106]) by smtp-ft5.fr.colt.net with ESMTP id i37Hv6a11453 for <ietf-pkix@imc.org>; Wed, 7 Apr 2004 19:57:06 +0200 Message-ID: <407440ED.2070708@free.fr> Date: Wed, 07 Apr 2004 19:57:01 +0200 From: Jean-Marc Desperrier <jmdesp@free.fr> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:) Gecko/20040226 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: Re: RES: Re-certification References: <01d701c41cb7$b4234620$be00a8c0@jurujuba> In-Reply-To: <01d701c41cb7$b4234620$be00a8c0@jurujuba> 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: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Rodrigo Botafogo wrote: >[...] I haven't seen any comments about the CRL >issue that I've also asked about. [...] > AFAIC what you did about the CRL seemed really special, and I wasn't sure I understood it fully. >[...] We've made some tests and when a new key is >generated for the same DN, some RP, Outlook for instance, sees the CRL >signed with the new key as another CA and not the same CA with a new >key. > Does it have both the old and the new CA certificate in it's store ? You can't say "Outlook" and expect answers. Depending on the exact version, the behavior (especially CRL) has major differences. >[...] Certificates revoked before the new key generation are not seen as >revoked, the RP seems to tread the CRL as an "invalid" CRL for this >certificate. > > Quite interesting. Whatever the RFC say about the subject, accepting as valid a CRL emitted by a CA that has the same DN as the CA that emitted the subject (but a different key) is very delicate thing to handle without dangerous security implications, and I think most implementors just safely refuse it all together, which is a better solution than to do it without being able to define adequate safegards. But the thing you can rely on to get this working is AKI identifiers. The Microsoft implementation places a lot of confidence in AKI, even accepting to follow a path based on the AKI when the DN don't match (which is invalid). So you can hope to get some succesful results if you generate two CRL in parallel, one by the old CA one by the new CA, and use an AKI inside the CRL to link them strongly to the adequate CA. And always revoke certs in the CRL signed by the keypair that issued them. If you're still concerned about being able to revoke certs emitted by the old CA, that mean that old CA is not yet expired and still can emit CRL, doesn't it ? >I couldn't find anyway to configure Outlook so that it would recognize >that the cert was revoked. Is there any application out there that does >the right thing? > I'm surprised Outlook goes as far as you apparently describe. Since years, people have reached the conclusion with the applications on the market, CA changeover with key renewal and the same DN doesn't work, and always either keeped the same key, or (even if only slightly) changed the DN. AKI is theorically the key to getting it working correctly, but it's adventurous to really test it. >Sorry if discussing real apps is not in the scope of >the group. If so, let me know. > > I too sometime wonder too why this lists spends astounding amount of time discussing very advanced points, and so little discussing the actual shortcomings of existing implementations on basic things. But this said yes to some degree detailled discussion of how to get such specific implementation to do some thing might be out of the scope. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37HIYqK013516; Wed, 7 Apr 2004 10:18:34 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i37HIXZ2013514; Wed, 7 Apr 2004 10:18:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail8.atl.registeredsite.com (nobody@mail8.atl.registeredsite.com [64.224.219.82]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37HIXMv013507 for <ietf-pkix@imc.org>; Wed, 7 Apr 2004 10:18:33 -0700 (PDT) (envelope-from egerck@nma.com) Received: from taurus.hosting4u.net (taurus.hosting4u.net [209.35.191.122]) by mail8.atl.registeredsite.com (8.12.8/8.12.8) with ESMTP id i37HIZp3005800; Wed, 7 Apr 2004 17:18:36 GMT Received: from nma.com ([63.204.17.85]) by taurus.hosting4u.net ; Wed, 07 Apr 2004 12:18:33 -0500 Message-ID: <40743797.CD0836B@nma.com> Date: Wed, 07 Apr 2004 10:17:11 -0700 From: Ed Gerck <egerck@nma.com> X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Santosh Chokhani <chokhani@orionsec.com> CC: ietf-pkix@imc.org Subject: Re: clarification proposal -- Re: Current status of CRL validation? References: <006901c41c9e$ce5676c0$9a00a8c0@hq.orionsec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Santosh Chokhani wrote: > Please read X.509 and 3280 carefully. There is no mechanism to limit the > time of delegation. I find this interpretation interesting. I wonder how many people would agree with that. We now have eternal certs, that don't expire and cannot be revoked. This would certainly solve the revocation problem ;-) As an alternative reading to eternal delegation, X.509 should be interpreted in its entirety. Since there is nothing that mandates eternal delegation, the CA is free to use its CPS to control delegation as the CA so chooses --including expiration dates and revocation mechanisms-- both off-line and on-line. > See the syntax and semantics of CRL DP extension. I see the semantics of the CPS. There is nothing stated there that would bar a CA from limiting the time and scope of delegation. > Also, there is no requirement for the certificate issuing CA to issue a CRL My point exactly -- the CA can control all aspects of its revocation management policy. > and if the Indirect CRL is checked by the relying party, there is no > requirement to check any CRL issued by the issuing CA. Yes, but that check was not done absolutely. It was done in reference to what the issuer CA defines in its CPS, including its revocation management policy. For example, look for words such as "...MAKES NO REPRESENTATION ..." and "...MAKES NO ASSURANCES ...". The issuer CA can also change its CPS at any time, possibly excluding any delegation from some time on. > Actually, if the CRL DP extension is marked critical and it points to an > indirect CRL issuer, you MUST check that CRL. My point exactly -- the issuer CA can control all aspects of its revocation management policy. Let's ask, who signed that critical CRL DP extension? Who controls whether the RP MUST check that CRL at that indirect CRL issuer or not? Further, who can revoke such critical CRL DP extension? Cheers, Ed Gerck Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37H5kYI012380; Wed, 7 Apr 2004 10:05:46 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i37H5kp4012379; Wed, 7 Apr 2004 10:05:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37H5jEl012370 for <ietf-pkix@imc.org>; Wed, 7 Apr 2004 10:05:46 -0700 (PDT) (envelope-from kent@bbn.com) Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i37H5d7Z013901; Wed, 7 Apr 2004 13:05:40 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: <p06020411bc99d1fab8e9@[128.89.89.75]> In-Reply-To: <20040407144450.GA742@cryptolog.com> References: <20040323103412.GA23286@cryptolog.com> <004f01c410dc$2c0681d0$df294d0c@hq.orionsec.com> <20040323142525.GA27672@cryptolog.com> <p06020406bc861b0a4627@[128.33.244.157]> <20040407144450.GA742@cryptolog.com> Date: Wed, 7 Apr 2004 11:47:28 -0400 To: "Julien Stern" <julien.stern@cryptolog.com> From: Stephen Kent <kent@bbn.com> Subject: Re: Current status of CRL validation ? Cc: ietf-pkix@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Julien, I think you must be a bit behind on reading PKIX mail, since Santosh and I have been discussing the indirect CRL issue for two days now. In your example, the first flaw I see is that the cert in question is supposedly signed by two CAs (CA4 and CA5), which have the same DN and public keys. if they have the same DN and the same public key, then they are the same CA, so the example is broken at that point, period. Steve Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37GZDbG010394; Wed, 7 Apr 2004 09:35:13 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i37GZDLU010393; Wed, 7 Apr 2004 09:35:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mallaury.noc.nerim.net (smtp-103-wednesday.noc.nerim.net [62.4.17.103]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37GZC6D010385 for <ietf-pkix@imc.org>; Wed, 7 Apr 2004 09:35:12 -0700 (PDT) (envelope-from julien.stern@cryptolog.com) Received: from jupiter.cry.pto (cryptolog.net1.nerim.net [80.65.224.225]) by mallaury.noc.nerim.net (Postfix) with ESMTP id 44A3962D50 for <ietf-pkix@imc.org>; Wed, 7 Apr 2004 18:35:11 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by jupiter.cry.pto (Postfix) with ESMTP id ED28E4195 for <ietf-pkix@imc.org>; Wed, 7 Apr 2004 18:35:12 +0200 (CEST) Received: from jupiter.cry.pto ([127.0.0.1]) by localhost (jupiter [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 20176-09 for <ietf-pkix@imc.org>; Wed, 7 Apr 2004 18:35:12 +0200 (CEST) Received: from callisto.cry.pto (callisto.cry.pto [10.0.1.4]) by jupiter.cry.pto (Postfix) with SMTP id B807740B0 for <ietf-pkix@imc.org>; Wed, 7 Apr 2004 18:35:12 +0200 (CEST) Received: by callisto.cry.pto (sSMTP sendmail emulation); Wed, 7 Apr 2004 18:35:12 +0200 From: "Julien Stern" <julien.stern@cryptolog.com> Date: Wed, 7 Apr 2004 18:35:12 +0200 To: ietf-pkix@imc.org Subject: Re: Current status of CRL validation ? Message-ID: <20040407163512.GA1250@cryptolog.com> References: <20040407144450.GA742@cryptolog.com> <011b01c41cba$70bbff00$9a00a8c0@hq.orionsec.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <011b01c41cba$70bbff00$9a00a8c0@hq.orionsec.com> User-Agent: Mutt/1.5.5.1+cvs20040105i X-Virus-Scanned: by amavisd-new-20030314-p2 (Debian) at cryptolog.com Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> On Wed, Apr 07, 2004 at 12:07:34PM -0400, Santosh Chokhani wrote: > > Julien: > > I am not sure that two distinct CAs with the same key (putting aside the > same DN) should be the basis for analysis. That situation will always lead > to problems. We are relying on randomness of large numbers to help us that > this will not happen. > > Consider providing an example where different CAs do not have the same key. You should view my "two" CAs as the same CA with two different keys. I might not have been totally clear about that, sorry. This can be "either due to multiple concurrent key pairs or due to changeover" (to quote RFC3280 :)). -- Julien > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On > Behalf Of Julien Stern > Sent: Wednesday, April 07, 2004 10:45 AM > To: ietf-pkix@imc.org > Subject: Re: Current status of CRL validation ? > > > > On Tue, Mar 23, 2004 at 11:56:01AM -0500, Stephen Kent wrote: > > > > Julien, > > > > The confusion stems from somewhat sloppy use of terminology in these > > discussions. > > > > Only the issuer of a cert can revoke it and in X.509 (unlike PGP) > > there is only one issuer for a given cert. So, the revocation > > question as you stated it was not well formed. > > Stephen, > > I do not believe that only the issuer of a cert can revoke it, notably when > indirect CRL are used. > > > A cert is either revoked or not. > > Well, I'm sincerely starting to believe this is not true :) > and not because of lack of available information. > Please point me to the flaw in the following setting: > > +-----+ +-----+ I have a certificate (Cert). Two > | CA1 | | | Different CAs (CA4 and CA5) have > | DN1 | | DN1 | matching issuer DN and keys for it. > | PK1 | | | > +-----+ +-----+ These two CAs have two super CAs > / \ | signed by the same root. > +-----+ +-----+ +-----+ > | CA2 | | CA3 | | | I also have a CRL which refers to > | DN2 | | DN3 | | DN3 | the certificate but whose only > | PK2 | | PK3 | | | chain up to DN1 is going through > +-----+ +-----+ +-----+ DN4 and DN3 (but NOT DN2). > | | | > +-----+ +-----+ +-----+ Now assume that the left path > | CA4 | | CA5 | | | (CA1 -> CA2 -> CA4 -> Cert) > | DN4 | | DN4 | | DN4 | is valid for SOME policies, and > | PK4 | | PK4 | | | the right path is valid for some > +-----+ +-----+ +-----+ OTHER policies. > \ / | > +-----+ +-----+ > |Cert | | CRL | > +-----+ +-----+ > > If I try to validate the certificate with the "left" policy mappings, only > the "left" chain will be valid. Then, I will check the chain for the CRL, > which will be valid and will match the DN matching rule, so I will conclude > that the certificate is revoked. > > If I try to validate the certificate with the "right" policy mappings, onle > the "right" chain will be valid. Then, I will check the chain for the CRL, > which will not match the DN matching rule, so I will not be able to verify > the validity of the CRL, and hence conclude that the certificate is valid. > > Sincerely, > > -- > Julien > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37GC6if007849; Wed, 7 Apr 2004 09:12:06 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i37GC618007848; Wed, 7 Apr 2004 09:12:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mongo.corestreet.com (mongo.corestreet.com [68.162.232.130]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37GC5ki007823 for <ietf-pkix@imc.org>; Wed, 7 Apr 2004 09:12:05 -0700 (PDT) (envelope-from dengberg@corestreet.com) X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: SCVP Change Proposal (was: Signing Untrusted SCVP?) Date: Wed, 7 Apr 2004 12:11:15 -0400 Message-ID: <DE909E05406F3340B186DA5A410B05F642A3CE@mongo.corestreet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SCVP Change Proposal (was: Signing Untrusted SCVP?) Thread-Index: AcQcoRLyDCr64/a8SW+cv1GSmtiwVQAE9A0A From: "Dave Engberg" <dengberg@corestreet.com> To: "Santosh Chokhani" <chokhani@orionsec.com>, <ietf-pkix@imc.org> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i37GC5ki007843 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Thanks, Santosh. Here's a specific list of changes to SCVP Draft 13 that would allow the use of signatures to be optional on pure DPD lookups, and permit server caching of signed responses when mutually acceptable by server and client security policies. Rather than defining a new request extension to signal a desire for a fresh signature, this proposal uses the request nonce. I assume there would be agreement that any client who sends a nonce would not want an unsigned or cached response in return, but I wouldn't have any problem with defining a separate new extension if that makes the intent more clear. The section 3 changes are separate from section 4, and either could be adopted independently. In Section 3, replace: If a server is responding to an unsigned request or a signed request, it MUST use a signed response or an unsigned error response. With: If a server is responding to an unsigned request or a signed request, it MUST use a signed response or an unsigned error response if either of the following is true: - The request wantBack includes one or more of the following: * id-swb-pkc-public-key-info * id-swb-pkc-cert-status * id-swb-ac-cert-status - The request includes a requestNonce If neither is true, a server responding to an unsigned request or signed request MAY use a signed response, an unsigned response, or an unsigned error response. In Section 4, replace: requestRef RequestReference, With: requestRef [0] RequestReference OPTIONAL, In Section 4.5, replace: The requestRef allows the SCVP server to identify the request that With: The OPTIONAL requestRef item allows the SCVP server to identify the request that ... -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Santosh Chokhani Sent: Wednesday, April 07, 2004 8:32 AM To: ietf-pkix@imc.org Subject: RE: Signing Untrusted SCVP? Given the limited value of signature, DPD response signature by the server should be optional and signature verification by the client should be optional. The question we should answer is that is there any benefit to adding an option for the client to request a signature and then should the DPD server be forced to sign the response Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37G7XVT007329; Wed, 7 Apr 2004 09:07:33 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i37G7WQH007328; Wed, 7 Apr 2004 09:07:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37G7WG1007322 for <ietf-pkix@imc.org>; Wed, 7 Apr 2004 09:07:32 -0700 (PDT) (envelope-from chokhani@orionsec.com) Received: from wchokhani3 (dpvc-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i37G7ZAt014664 for <ietf-pkix@imc.org>; Wed, 7 Apr 2004 12:07:35 -0400 From: "Santosh Chokhani" <chokhani@orionsec.com> To: <ietf-pkix@imc.org> Subject: RE: Current status of CRL validation ? Date: Wed, 7 Apr 2004 12:07:34 -0400 Message-ID: <011b01c41cba$70bbff00$9a00a8c0@hq.orionsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <20040407144450.GA742@cryptolog.com> Importance: Normal Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Julien: I am not sure that two distinct CAs with the same key (putting aside the same DN) should be the basis for analysis. That situation will always lead to problems. We are relying on randomness of large numbers to help us that this will not happen. Consider providing an example where different CAs do not have the same key. -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Julien Stern Sent: Wednesday, April 07, 2004 10:45 AM To: ietf-pkix@imc.org Subject: Re: Current status of CRL validation ? On Tue, Mar 23, 2004 at 11:56:01AM -0500, Stephen Kent wrote: > > Julien, > > The confusion stems from somewhat sloppy use of terminology in these > discussions. > > Only the issuer of a cert can revoke it and in X.509 (unlike PGP) > there is only one issuer for a given cert. So, the revocation > question as you stated it was not well formed. Stephen, I do not believe that only the issuer of a cert can revoke it, notably when indirect CRL are used. > A cert is either revoked or not. Well, I'm sincerely starting to believe this is not true :) and not because of lack of available information. Please point me to the flaw in the following setting: +-----+ +-----+ I have a certificate (Cert). Two | CA1 | | | Different CAs (CA4 and CA5) have | DN1 | | DN1 | matching issuer DN and keys for it. | PK1 | | | +-----+ +-----+ These two CAs have two super CAs / \ | signed by the same root. +-----+ +-----+ +-----+ | CA2 | | CA3 | | | I also have a CRL which refers to | DN2 | | DN3 | | DN3 | the certificate but whose only | PK2 | | PK3 | | | chain up to DN1 is going through +-----+ +-----+ +-----+ DN4 and DN3 (but NOT DN2). | | | +-----+ +-----+ +-----+ Now assume that the left path | CA4 | | CA5 | | | (CA1 -> CA2 -> CA4 -> Cert) | DN4 | | DN4 | | DN4 | is valid for SOME policies, and | PK4 | | PK4 | | | the right path is valid for some +-----+ +-----+ +-----+ OTHER policies. \ / | +-----+ +-----+ |Cert | | CRL | +-----+ +-----+ If I try to validate the certificate with the "left" policy mappings, only the "left" chain will be valid. Then, I will check the chain for the CRL, which will be valid and will match the DN matching rule, so I will conclude that the certificate is revoked. If I try to validate the certificate with the "right" policy mappings, onle the "right" chain will be valid. Then, I will check the chain for the CRL, which will not match the DN matching rule, so I will not be able to verify the validity of the CRL, and hence conclude that the certificate is valid. Sincerely, -- Julien Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37G0IfE006812; Wed, 7 Apr 2004 09:00:18 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i37G0IVY006811; Wed, 7 Apr 2004 09:00:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37G0IbH006805 for <ietf-pkix@imc.org>; Wed, 7 Apr 2004 09:00:18 -0700 (PDT) (envelope-from chokhani@orionsec.com) Received: from wchokhani3 (dpvc-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i37G0KAt012263 for <ietf-pkix@imc.org>; Wed, 7 Apr 2004 12:00:21 -0400 From: "Santosh Chokhani" <chokhani@orionsec.com> To: <ietf-pkix@imc.org> Subject: RE: Signing Untrusted SCVP? Date: Wed, 7 Apr 2004 12:00:20 -0400 Message-ID: <011201c41cb9$6dd6aed0$9a00a8c0@hq.orionsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <340B5AC242DEF44AAFCD6DC102B51CD30595E37B@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i37G0IbH006806 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Trevor: This argument can be the basis for signing everything all the time, which we do not do. The attacker can still manipulate and inject data. I am not persuaded by the argument that checking the signature first will save lot of client processing time. If the product developer and consumers want to have the option for not signing this data, they should. I see a bigger problem with the DPD server maintaining a cache and some one attacking that cache (if unsigned) since a stationary server may be easier to hack at then data in transit. Now, if the DPD server signed cached paths on request or if the DPD, you have the same problem. Also, my suggestion would be for the client to have the option of requesting signed responses and having the option of rejecting responses that are not signed. -----Original Message----- From: Trevor Freeman [mailto:trevorf@windows.microsoft.com] Sent: Wednesday, April 07, 2004 11:46 AM To: Santosh Chokhani; ietf-pkix@imc.org Subject: RE: Signing Untrusted SCVP? I think there is significant value in signing the response from the SCVP server. Given the main issue seems to be SCVP operating in an environment where an attacker has the ability to inject packets going between client and server into the data stream. Signing the response relegates the attacker to injecting error packets - which is a low grade DoS. Sending unsigned responses allows the attacker to inject a packed as the server whatever they want as a genuine response, with certificates and content of there choosing. So we just turned every SCVP client into a potential web beacon. Where the client has direct trust in the server signing key this is a very secure process with DPD. Trevor -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Santosh Chokhani Sent: Wednesday, April 07, 2004 5:32 AM To: ietf-pkix@imc.org Subject: RE: Signing Untrusted SCVP? Given the limited value of signature, DPD response signature by the server should be optional and signature verification by the client should be optional. The question we should answer is that is there any benefit to adding an option for the client to request a signature and then should the DPD server be forced to sign the response (shades of OCSP nonce) -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of David Engberg Sent: Tuesday, April 06, 2004 11:32 PM To: Stephen Kent Cc: ietf-pkix@imc.org Subject: Re: Signing Untrusted SCVP? Stephen - You have provided interesting techniques that an attacker could use to make a DPD client waste an extra 500ms verifying signatures before displaying a "bad path returned from server" dialog (or the equivalent). That same attacker with the same advantages (DNS spoofing, etc.) could achieve the same effective denial of path discovery even if an extra signature is thrown on responses. The attacker could obviously make clients waste time & bandwidth in lots of sneaky ways, although the relying application would ultimately report different error messages ("unknown host: 'scvp.eubridge.org'", "connection timed out", "no route to host", "response signature verify failed", etc.). I am curious whether the type of attack that you describe has ever been performed against a non-SSL LDAP directory in a manner that would not have been equally effective if SSL was in use. While there is definitely a difference here, I think (hope?) that we agree that it may be useful for a PKI administrator to have the choice to deploy a path discovery mechanism which does not require a fresh signature from a protected server key for every request. This would allow an administrator to balance the DoS risks for clients against the DoS risks for servers. My guess is that virtually all real world DoS attacks exploit the centralized nature of secured servers, and the best cure for this is the sort of distributed redundancy that a keyless or two-tier-caching DPD responder architecture would permit. For example, Akamai has 16,000+ servers around the world with no SSL private keys. They are subjected to daily DoS attempts (e.g. they host www.whitehouse.gov), which fail not due to the magic of PKI, but rather due to the redundancy you can build when you don't have to secure keys at every server. Thanks Stephen Kent wrote: ... > if an attacker can spoof a DNS response, he can cause the client to > connect to him instead of the server, which would enable the bogus > server to receive the request as well as generate and send the > response, and in the absence of a signed response, the client cannot > know that he is not communicating with the intended server. > > a bogus server could then return bogus cert chains that fail to > validate, but which waste client resources. just how effective this > may be will be a function of client implementation details, which are > outside the scope of our standards. ... Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37FovAj005632; Wed, 7 Apr 2004 08:50:57 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i37Fovwm005631; Wed, 7 Apr 2004 08:50:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from caveiras.certisign.com.br (caveiras.certisign.com.br [200.219.128.102]) by above.proper.com (8.12.11/8.12.8) with SMTP id i37FotUZ005624 for <ietf-pkix@imc.org>; Wed, 7 Apr 2004 08:50:56 -0700 (PDT) (envelope-from rbotafogo@certisign.com.br) Received: through eSafe SMTP Relay 1075129843; Wed Apr 07 12:50:54 2004 From: "Rodrigo Botafogo" <rbotafogo@certisign.com.br> To: <ietf-pkix@imc.org> Subject: RES: Re-certification Date: Wed, 7 Apr 2004 12:47:57 -0300 MIME-Version: 1.0 Message-ID: <01d701c41cb7$b4234620$be00a8c0@jurujuba> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=MD5; boundary="----=_NextPart_000_01D2_01C41C9E.86C403E0" Importance: Normal In-Reply-To: <E1BBDRz-0007xA-S9@medusa01> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> This is a multi-part message in MIME format. ------=_NextPart_000_01D2_01C41C9E.86C403E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thanks for the answers, but I haven't seen any comments about the CRL issue that I've also asked about. Anybody cares to comment. I see that there is a thread about CRL validation and it might somehow indicate how the validation in this case should happen. As I have stated previously, We've made some tests and when a new key is generated for the same DN, some RP, Outlook for instance, sees the CRL signed with the new key as another CA and not the same CA with a new key. Certificates revoked before the new key generation are not seen as revoked, the RP seems to tread the CRL as an "invalid" CRL for this certificate. I couldn't find anyway to configure Outlook so that it would recognize that the cert was revoked. Is there any application out there that does the right thing? Sorry if discussing real apps is not in the scope of the group. If so, let me know. Thanks again, Rodrigo Jean-Marc Desperrier <jmdesp@free.fr> writes: >AFAIK I have never seen Verisign *change* the key pair of an authority. They >always extend validity, while keeping the same key pair. Ah, sorry, I was a bit too quick in my reply, what I meant was that they kept the DN, key, and start date, and only changed the end date and serial number. I was never quite sure why they kept the validFrom date, I can understand wanting to leave a bit of overlap, but the new certs were backdated many years through the direct copying of the validFrom. Peter. ------=_NextPart_000_01D2_01C41C9E.86C403E0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDjAMBggqhkiG9w0CBQUAMIAGCSqGSIb3DQEHAQAAoIIKtDCC Aj0wggGmAhEAzbp/VvDf5LxU/iKss3KqVTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEX MBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkg Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMjgwODAxMjM1OTU5WjBf MQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEg UHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQAD gY0AMIGJAoGBAOUZv22jVmEtmUhx9mfeuY3rt56GgAqRDvo4Ja9GiILlc6igmyRdDR/MZW4MsNBW hBiHmgabEKFz37RYOWtuwfYV1aioP6oSBo0xrH+wNNePNGeICc0UEeJORVZpH3gCgNrcR5EpuzbJ Y1zF4Ncth3uhtzKwezC6Ki8xqu6jZ9rbAgMBAAEwDQYJKoZIhvcNAQECBQADgYEATD+4i8Zo3+5D Mw5d6abLB4RNejP/khv0Nq3YlSI2aBFsfELM85wuxAc/FLAPT/+Qknb54rxK6Y/NoIAK98Up8YIi Xbix3YEjo3slFUYweRb46gVLlH8dwhzI47f0EEA8E8NfH1PoSOSGtHuhNbB7Jbq4046rPzidADQA mPPRcZQwggNeMIICx6ADAgECAhA84jSriQsTpcYCE6HiUrg6MA0GCSqGSIb3DQEBBAUAMF8xCzAJ BgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJs aWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wMDA1MjAwMDAwMDBaFw0wNTA1 MTEyMzU5NTlaMIHQMS4wLAYDVQQKEyVDZXJ0aXNpZ24gQ2VydGlmaWNhZG9yYSBEaWdpdGFsIEx0 ZGEuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMT8wPQYDVQQLEzZUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cuY2VydGlzaWduLmNvbS5ici9SUEEgKGMpMDAxPDA6BgNVBAMTM0Nl cnRpc2lnbiBDbGFzcyAxIENvbnN1bWVyIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTCBnzANBgkq hkiG9w0BAQEFAAOBjQAwgYkCgYEAwv+tzSHkVlZMd8vKtQSOMxeZmi60OqvKGBnqTT/fB2lFkJA4 jyonCwVhW3AoBRmG2CoJHXO8qDGHCJ1euUVhfsBbqEbzpHCXabkQ8nwjdrG2dsNNdjS03ihbqJzS /gYcnikf4pUrYI+ogGvo2l0TzM+d3A1+aABEg1334Ld97ZsCAwEAAaOBqDCBpTApBgNVHREEIjAg pB4wHDEaMBgGA1UEAxMRQ2VydGlzaWduQzFDMi0xLTEwEQYJYIZIAYb4QgEBBAQDAgEGMEcGA1Ud IARAMD4wPAYKYIZIAYb4RQEHDzAuMCwGCCsGAQUFBwIBFiBodHRwczovL3d3dy5jZXJ0aXNpZ24u Y29tLmJyL1JQQTAPBgNVHRMECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOB gQB/ETCpNnaDii6nSsh+8JjF3cNvr1+HRDm5WQ2VsY+JR2NwbNYqYL/JWdagF5C/77rk7my6kwyc H1wByZi5BPcZZfimEkXgbQcad7C6JZLB9huB4KH9YB7/nPVDjl3X6oIU6uDVt8EbOlR6XdG8gd4L AyZAS10UsMt++Dz24MDyTTCCBQ0wggR2oAMCAQICEAGfzOriggkEmT5x2OammSgwDQYJKoZIhvcN AQEEBQAwgdAxLjAsBgNVBAoTJUNlcnRpc2lnbiBDZXJ0aWZpY2Fkb3JhIERpZ2l0YWwgTHRkYS4x HzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxPzA9BgNVBAsTNlRlcm1zIG9mIHVzZSBh dCBodHRwczovL3d3dy5jZXJ0aXNpZ24uY29tLmJyL1JQQSAoYykwMDE8MDoGA1UEAxMzQ2VydGlz aWduIENsYXNzIDEgQ29uc3VtZXIgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMB4XDTAzMDkxNjAw MDAwMFoXDTA0MDkxNTIzNTk1OVowggFmMSswKQYDVQQKFCJDZXJ0aVNpZ24gQ2VydGlmaWNhZG9y YSBEaWdpdGFsIFNBMREwDwYDVQQLFAhDbGFzc2UgMTE3MDUGA1UECxMuVGVybXMgb2YgdXNlIGF0 IHd3dy5jZXJ0aXNpZ24uY29tLmJyL1JQQSAoYykwMDE/MD0GA1UECxM2QXV0aGVudGljYXRlZCBi eSBDZXJ0aXNpZ24gQ2VydGlmaWNhZG9yYSBEaWdpdGFsIEx0ZGEuMScwJQYDVQQLEx5NZW1iZXIs IFZlcmlTaWduIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEb MBkGA1UECxMSRGlnaXRhbCBJRCBDbGFzcyAxMRkwFwYDVQQDExBSb2RyaWdvIEJvdGFmb2dvMSkw JwYJKoZIhvcNAQkBFhpyYm90YWZvZ29AY2VydGlzaWduLmNvbS5icjCBnzANBgkqhkiG9w0BAQEF AAOBjQAwgYkCgYEA5opHs5mo0q+gH3ejR6UJLs6ppE9ssOMLUsrDkeBSNSBd9Z8aBYtGU1vh/1Fo MFDCXEbZflxlBBAualq+O4xxwnL+I0955hPUlpcarTJJ7Tk6NHAHp/U6ajeBR5KWVyuFsrbY6687 V4k6oOBe93eJDfYW5N9O2TEv86GYCKJksSUCAwEAAaOCAU0wggFJMAkGA1UdEwQCMAAwZwYDVR0f BGAwXjBcoFqgWIZWaHR0cDovL29uc2l0ZWNybC5jZXJ0aXNpZ24uY29tLmJyL0NlcnRpU2lnbkNl cnRpZmljYWRvcmFEaWdpdGFsU0FDbGFzc2UxL0xhdGVzdENSTC5jcmwwgawGA1UdIASBpDCBoTCB ngYLYIZIAYb4RQEHAQEwgY4wKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9D UFMwYgYIKwYBBQUHAgIwVjAVFg5WZXJpU2lnbiwgSW5jLjADAgEBGj1WZXJpU2lnbidzIENQUyBp bmNvcnAuIGJ5IHJlZmVyZW5jZSBsaWFiLiBsdGQuIChjKTk3IFZlcmlTaWduMBEGCWCGSAGG+EIB AQQEAwIHgDARBgpghkgBhvhFAQYJBAMBAf8wDQYJKoZIhvcNAQEEBQADgYEAC+ACr4MSMbhFCpPr LhCeQpl/smArUeKUAfMHoO/Xhf9ecpONi++BnMqXGqnhGA2w9foPMLOqGFrwvzb8bPGhxJcqQn8r 1M0litTFOsaSASLrnTEyECgXPBQUHnTyFPPnbw6KU+XQbe4vPETWFkQd7rctBX/6X0SwM8X99q+Q 6OUxggRBMIIEPQIBATCB5TCB0DEuMCwGA1UEChMlQ2VydGlzaWduIENlcnRpZmljYWRvcmEgRGln aXRhbCBMdGRhLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE/MD0GA1UECxM2VGVy bXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LmNlcnRpc2lnbi5jb20uYnIvUlBBIChjKTAwMTwwOgYD VQQDEzNDZXJ0aXNpZ24gQ2xhc3MgMSBDb25zdW1lciBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EC EAGfzOriggkEmT5x2OammSgwDAYIKoZIhvcNAgUFAKCCAq4wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMDQwNDA3MTU0NzQ2WjAfBgkqhkiG9w0BCQQxEgQQ5fo50cDo nqwuevAIsLoUXDBfBgkqhkiG9w0BCQ8xUjBQMA4GCCqGSIb3DQMCAgIAgDAKBggqhkiG9w0CBTAL BglghkgBZQIBAQQwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfYGCSsG AQQBgjcQBDGB6DCB5TCB0DEuMCwGA1UEChMlQ2VydGlzaWduIENlcnRpZmljYWRvcmEgRGlnaXRh bCBMdGRhLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE/MD0GA1UECxM2VGVybXMg b2YgdXNlIGF0IGh0dHBzOi8vd3d3LmNlcnRpc2lnbi5jb20uYnIvUlBBIChjKTAwMTwwOgYDVQQD EzNDZXJ0aXNpZ24gQ2xhc3MgMSBDb25zdW1lciBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ECEAGf zOriggkEmT5x2OammSgwgfgGCyqGSIb3DQEJEAILMYHooIHlMIHQMS4wLAYDVQQKEyVDZXJ0aXNp Z24gQ2VydGlmaWNhZG9yYSBEaWdpdGFsIEx0ZGEuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMT8wPQYDVQQLEzZUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cuY2VydGlzaWduLmNv bS5ici9SUEEgKGMpMDAxPDA6BgNVBAMTM0NlcnRpc2lnbiBDbGFzcyAxIENvbnN1bWVyIEluZGl2 aWR1YWwgU3Vic2NyaWJlciBDQQIQAZ/M6uKCCQSZPnHY5qaZKDANBgkqhkiG9w0BAQEFAASBgMsA 9fptmABMNtwJOYVVmYq77mgdD9a9lHlIp//zP0xXu8TV3CQ/oAJGUfkjPryqw/bHJU3pvQ+5nl8J Yy1BHrN7I+0rRRhjVY6PZvdgfjj9Lu+UeqXPg7VNb2AI/w0t+2epy4zlquPHfBtTcQ6X0PrCbL7A oRwYOUB10qn12qdbAAAAAAAA ------=_NextPart_000_01D2_01C41C9E.86C403E0-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37FkICD005304; Wed, 7 Apr 2004 08:46:18 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i37FkIfZ005303; Wed, 7 Apr 2004 08:46:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37FkHl1005295 for <ietf-pkix@imc.org>; Wed, 7 Apr 2004 08:46:18 -0700 (PDT) (envelope-from trevorf@windows.microsoft.com) Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Wed, 7 Apr 2004 08:46:15 -0700 Received: from 157.54.8.23 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 07 Apr 2004 08:46:14 -0700 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 7 Apr 2004 08:47:43 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 7 Apr 2004 08:46:15 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 7 Apr 2004 08:46:13 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7195.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Signing Untrusted SCVP? Date: Wed, 7 Apr 2004 08:46:13 -0700 Message-ID: <340B5AC242DEF44AAFCD6DC102B51CD30595E37B@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Signing Untrusted SCVP? thread-index: AcQcqY9RZru4QawlTay3MbzIudXKYwAC9ljQ From: "Trevor Freeman" <trevorf@windows.microsoft.com> To: "Santosh Chokhani" <chokhani@orionsec.com>, <ietf-pkix@imc.org> X-OriginalArrivalTime: 07 Apr 2004 15:46:13.0326 (UTC) FILETIME=[748DCEE0:01C41CB7] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i37FkIl1005298 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> I think there is significant value in signing the response from the SCVP server. Given the main issue seems to be SCVP operating in an environment where an attacker has the ability to inject packets going between client and server into the data stream. Signing the response relegates the attacker to injecting error packets - which is a low grade DoS. Sending unsigned responses allows the attacker to inject a packed as the server whatever they want as a genuine response, with certificates and content of there choosing. So we just turned every SCVP client into a potential web beacon. Where the client has direct trust in the server signing key this is a very secure process with DPD. Trevor -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Santosh Chokhani Sent: Wednesday, April 07, 2004 5:32 AM To: ietf-pkix@imc.org Subject: RE: Signing Untrusted SCVP? Given the limited value of signature, DPD response signature by the server should be optional and signature verification by the client should be optional. The question we should answer is that is there any benefit to adding an option for the client to request a signature and then should the DPD server be forced to sign the response (shades of OCSP nonce) -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of David Engberg Sent: Tuesday, April 06, 2004 11:32 PM To: Stephen Kent Cc: ietf-pkix@imc.org Subject: Re: Signing Untrusted SCVP? Stephen - You have provided interesting techniques that an attacker could use to make a DPD client waste an extra 500ms verifying signatures before displaying a "bad path returned from server" dialog (or the equivalent). That same attacker with the same advantages (DNS spoofing, etc.) could achieve the same effective denial of path discovery even if an extra signature is thrown on responses. The attacker could obviously make clients waste time & bandwidth in lots of sneaky ways, although the relying application would ultimately report different error messages ("unknown host: 'scvp.eubridge.org'", "connection timed out", "no route to host", "response signature verify failed", etc.). I am curious whether the type of attack that you describe has ever been performed against a non-SSL LDAP directory in a manner that would not have been equally effective if SSL was in use. While there is definitely a difference here, I think (hope?) that we agree that it may be useful for a PKI administrator to have the choice to deploy a path discovery mechanism which does not require a fresh signature from a protected server key for every request. This would allow an administrator to balance the DoS risks for clients against the DoS risks for servers. My guess is that virtually all real world DoS attacks exploit the centralized nature of secured servers, and the best cure for this is the sort of distributed redundancy that a keyless or two-tier-caching DPD responder architecture would permit. For example, Akamai has 16,000+ servers around the world with no SSL private keys. They are subjected to daily DoS attempts (e.g. they host www.whitehouse.gov), which fail not due to the magic of PKI, but rather due to the redundancy you can build when you don't have to secure keys at every server. Thanks Stephen Kent wrote: ... > if an attacker can spoof a DNS response, he can cause the client to > connect to him instead of the server, which would enable the bogus > server to receive the request as well as generate and send the > response, and in the absence of a signed response, the client cannot > know that he is not communicating with the intended server. > > a bogus server could then return bogus cert chains that fail to > validate, but which waste client resources. just how effective this > may be will be a function of client implementation details, which are > outside the scope of our standards. ... Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37Fk8f4005293; Wed, 7 Apr 2004 08:46:08 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i37Fk8Gx005292; Wed, 7 Apr 2004 08:46:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail-dub.microsoft.com (mail-dub.microsoft.com [213.199.128.160]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37Fk7Pb005281 for <ietf-pkix@imc.org>; Wed, 7 Apr 2004 08:46:08 -0700 (PDT) (envelope-from stefans@microsoft.com) Received: from dub-imc-01.europe.corp.microsoft.com ([65.53.196.22]) by mail-dub.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 7 Apr 2004 16:46:06 +0100 Received: from 65.53.196.22 by dub-imc-01.europe.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 07 Apr 2004 16:46:06 +0100 Received: from EUR-MSG-03.europe.corp.microsoft.com ([65.53.192.44]) by dub-imc-01.europe.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 7 Apr 2004 16:46:06 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7195.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: clarification proposal -- Re: Current status of CRL validation? Date: Wed, 7 Apr 2004 16:45:56 +0100 Message-ID: <0C3042E92D8A714783E2C44AB9936E1DE352CC@EUR-MSG-03.europe.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: clarification proposal -- Re: Current status of CRL validation? Thread-Index: AcQcdNI/b0tg+2/+Qtex7IOuBnH60wAQNwdQ From: "Stefan Santesson" <stefans@microsoft.com> To: <ietf-pkix@imc.org> X-OriginalArrivalTime: 07 Apr 2004 15:46:06.0852 (UTC) FILETIME=[70B1F440:01C41CB7] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i37Fk8Pb005287 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> The basic assumption for the whole discussion seems to be very confused: Snip: > > "Since there may be more than one path used to validate the > same certificate, it is possible that some paths to that > certificate are valid while others are not." > There is only 1 kind of path that can be used to validate a certificate, and that is a valid path. Valid being defined as a path that pass the RPs validation policy (defined at the discretion of the relying party). All other paths are invalid by definition. So among the valid paths there is no ambiguity, since they are all valid. Why complicate things? /Stefan Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37FeRl0004808; Wed, 7 Apr 2004 08:40:27 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i37FeRY1004807; Wed, 7 Apr 2004 08:40:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from seguridata1.seguridata.com ([200.57.34.107]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37FeQjQ004789 for <ietf-pkix@imc.org>; Wed, 7 Apr 2004 08:40:27 -0700 (PDT) (envelope-from mars@seguridata.com) Received: from MarsXP ([200.67.231.235]) by seguridata1.seguridata.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 7 Apr 2004 10:41:03 -0500 From: "Miguel Rodriguez" <mars@seguridata.com> To: <ietf-pkix@imc.org> Subject: key uniqueness in a PKI Date: Wed, 7 Apr 2004 10:39:40 -0500 Message-ID: <001601c41cb6$8a6f6bc0$a600a8c0@seguridata.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0017_01C41C8C.A19963C0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-OriginalArrivalTime: 07 Apr 2004 15:41:03.0328 (UTC) FILETIME=[BBC7DE00:01C41CB6] Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> This is a multi-part message in MIME format. ------=_NextPart_000_0017_01C41C8C.A19963C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Where can I find information on key pair uniqueness in a PKI? Is this issue discussed in an RFC? I will also appreciate comments on this issue, particularly when considering a PKI with several CAs. Thanks. Miguel A Rodriguez SeguriData Mexico ------=_NextPart_000_0017_01C41C8C.A19963C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Dus-ascii"> <TITLE>Message</TITLE> <META content=3D"MSHTML 6.00.2800.1400" name=3DGENERATOR></HEAD> <BODY> <DIV><FONT face=3DArial size=3D2><SPAN class=3D359323615-07042004>Where = can I find=20 information on key pair uniqueness in a PKI? Is this issue discussed in = an=20 RFC?</SPAN></FONT></DIV> <DIV><FONT face=3DArial size=3D2><SPAN class=3D359323615-07042004>I will = also=20 appreciate comments on this issue, particularly when considering a PKI = with=20 several CAs.</SPAN></FONT></DIV> <DIV><FONT face=3DArial size=3D2><SPAN=20 class=3D359323615-07042004></SPAN></FONT> </DIV> <DIV><FONT face=3DArial size=3D2><SPAN=20 class=3D359323615-07042004>Thanks.</SPAN></FONT></DIV> <DIV><FONT face=3DArial size=3D2><SPAN=20 class=3D359323615-07042004></SPAN></FONT> </DIV> <DIV><FONT face=3DArial size=3D2><SPAN class=3D359323615-07042004>Miguel = A=20 Rodriguez</SPAN></FONT></DIV> <DIV><FONT face=3DArial size=3D2><SPAN=20 class=3D359323615-07042004>SeguriData</SPAN></FONT></DIV> <DIV><FONT face=3DArial size=3D2><SPAN=20 class=3D359323615-07042004>Mexico</SPAN></FONT></DIV></BODY></HTML> ------=_NextPart_000_0017_01C41C8C.A19963C0-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37FB588001449; Wed, 7 Apr 2004 08:11:05 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i37FB5LG001447; Wed, 7 Apr 2004 08:11:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37FB4ie001407 for <ietf-pkix@imc.org>; Wed, 7 Apr 2004 08:11:04 -0700 (PDT) (envelope-from kent@bbn.com) Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i37FAt7r004992; Wed, 7 Apr 2004 11:11:01 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: <p0602040bbc99c11cc4ff@[128.89.89.75]> In-Reply-To: <005c01c41c9c$5f98c5a0$9a00a8c0@hq.orionsec.com> References: <005c01c41c9c$5f98c5a0$9a00a8c0@hq.orionsec.com> Date: Wed, 7 Apr 2004 10:32:05 -0400 To: "Santosh Chokhani" <chokhani@orionsec.com> From: Stephen Kent <kent@bbn.com> Subject: RE: Signing Untrusted SCVP? Cc: <ietf-pkix@imc.org> Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> At 8:32 AM -0400 4/7/04, Santosh Chokhani wrote: >Given the limited value of signature, DPD response signature by the server >should be optional and signature verification by the client should be >optional. > >The question we should answer is that is there any benefit to adding an >option for the client to request a signature and then should the DPD server >be forced to sign the response > >(shades of OCSP nonce) > I disagree with your first assertion, and thus, not surprisingly, the conclusion. I think signature support for client and server should be mandated, but local amdins can choose to not invoke the feature. Steve Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37FB5hV001450; Wed, 7 Apr 2004 08:11:05 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i37FB50K001448; Wed, 7 Apr 2004 08:11:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37FB3XK001406 for <ietf-pkix@imc.org>; Wed, 7 Apr 2004 08:11:04 -0700 (PDT) (envelope-from kent@bbn.com) Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i37FAt7l004992; Wed, 7 Apr 2004 11:11:00 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: <p06020407bc99bb7f7429@[128.89.89.75]> In-Reply-To: <40737613.3080801@corestreet.com> References: <B04FB2812116384A87D2968369C086977352A9@exchange.cenzic.com> <407210D5.4070404@corestreet.com> <p06020419bc98c58ecfd6@[128.89.89.75]> <40737613.3080801@corestreet.com> Date: Wed, 7 Apr 2004 10:24:00 -0400 To: David Engberg <dengberg@corestreet.com> From: Stephen Kent <kent@bbn.com> Subject: Re: Signing Untrusted SCVP? Cc: ietf-pkix@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> At 11:31 PM -0400 4/6/04, David Engberg wrote: >Stephen - > >You have provided interesting techniques that an attacker could use >to make a DPD client waste an extra 500ms verifying signatures >before displaying a "bad path returned from server" dialog (or the >equivalent). Your next paragraph admits the problem is not the 500ms wasted in verifying signatures that lead to a dead end, but rather the errors that effectively kill the process and result in user error messages that deny service. So, I wonder why you chose to lead off with this red herring? >That same attacker with the same advantages (DNS spoofing, etc.) >could achieve the same effective denial of path discovery even if an >extra signature is thrown on responses. The attacker could >obviously make clients waste time & bandwidth in lots of sneaky >ways, although the relying application would ultimately report >different error messages ("unknown host: 'scvp.eubridge.org'", >"connection timed out", "no route to host", "response signature >verify failed", etc.). If the attacker cannot forge signatures on DPD server responses, then the DPD software will not be so easily led into error states based on the assumption that it is talking with a valid server. Thus reduces the opportunities for attackers to steer the user into a state of confusion. If one believed the argument you cite above, then we ought to not bother with checksums on TCP packets (which is often the slowest part of TCP processing), because the users will eventually figure out if a transmission was corrupted, and there are so many other ways that an attacker could deny a user service. >I am curious whether the type of attack that you describe has ever >been performed against a non-SSL LDAP directory in a manner that >would not have been equally effective if SSL was in use. I don't know, and I don't care. It is a bad strategy to rely on past attack behavior as a primary predictor of future attacks. >While there is definitely a difference here, I think (hope?) that we >agree that it may be useful for a PKI administrator to have the >choice to deploy a path discovery mechanism which does not require a >fresh signature from a protected server key for every request. This >would allow an administrator to balance the DoS risks for clients >against the DoS risks for servers. I think it could be reasonable to give local admins that option, which requires that products support signatures and allow local admins to decide whether to employ the signatures. >My guess is that virtually all real world DoS attacks exploit the >centralized nature of secured servers, and the best cure for this is >the sort of distributed redundancy that a keyless or >two-tier-caching DPD responder architecture would permit. For >example, Akamai has 16,000+ servers around the world with no SSL >private keys. They are subjected to daily DoS attempts (e.g. they >host www.whitehouse.gov), which fail not due to the magic of PKI, >but rather due to the redundancy you can build when you don't have >to secure keys at every server. Your Akamai example is a poor one; it says nothing about the need to secure keys at every server. And, by the way, every one of those severs does have a key in it, for use with Kerberos for managing the servers. Steve Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37FB2CF001429; Wed, 7 Apr 2004 08:11:02 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i37FB2f1001426; Wed, 7 Apr 2004 08:11:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37FB0cT001403 for <ietf-pkix@imc.org>; Wed, 7 Apr 2004 08:11:01 -0700 (PDT) (envelope-from kent@bbn.com) Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i37FAt7f004992; Wed, 7 Apr 2004 11:10:58 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: <p06020404bc99b85bb7d8@[128.89.89.75]> In-Reply-To: <011201c41c24$e5b9b590$9a00a8c0@hq.orionsec.com> References: <011201c41c24$e5b9b590$9a00a8c0@hq.orionsec.com> Date: Wed, 7 Apr 2004 09:54:12 -0400 To: "Santosh Chokhani" <chokhani@orionsec.com> From: Stephen Kent <kent@bbn.com> Subject: RE: clarification proposal -- Re: Current status of CRL validation ? Cc: <ietf-pkix@imc.org> Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> At 6:17 PM -0400 4/6/04, Santosh Chokhani wrote: >Steve: > >Here is the quote from 3280, paragraph 3, Section 5. > >"CRL issuers issue CRLs. In general, the CRL issuer is the CA. CAs > publish CRLs to provide status information about the certificates > they issued. However, a CA may delegate this responsibility to > another trusted authority. Whenever the CRL issuer is not the CA > that issued the certificates, the CRL is referred to as an indirect > CRL." > >This may have been done to accommodate OCSP, but as the RFC is written, it >should be interpreted to accommodate various situations, not just OCSP. > Agreed that the wording is not OVCS-specific. maybe we can add that to the list of fixes for 3280 as we go forward. Steve Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37FB2b2001431; Wed, 7 Apr 2004 08:11:02 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i37FB29f001428; Wed, 7 Apr 2004 08:11:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37FB15E001404 for <ietf-pkix@imc.org>; Wed, 7 Apr 2004 08:11:01 -0700 (PDT) (envelope-from kent@bbn.com) Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i37FAt7h004992; Wed, 7 Apr 2004 11:10:59 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: <p06020405bc99b8e5d82e@[128.89.89.75]> In-Reply-To: <40733B79.2A0AF2C8@nma.com> References: <20040323103412.GA23286@cryptolog.com> <004f01c410dc$2c0681d0$df294d0c@hq.orionsec.com> <20040323142525.GA27672@cryptolog.com> <p06020406bc861b0a4627@[128.33.244.157]> <406A0839.14F7C3A1@nma.com> <p06020401bc909a0b8ec1@[128.89.89.75]> <406B0593.FD2E1F6B@nma.com> <p06020408bc90bbc275a7@[128.89.89.75]> <406DE8AD.BC0DA38@nma.com> <p06020411bc9750745da7@[128.89.89.75]> <4071AB84.14898140@nma.com> <p0602041ebc977ad14b67@[128.89.89.75]> <4071DE2E.B5BED74A@nma.com> <p06020405bc9860671a8f@[128.89.89.75]> <4072EABB.D2A50271@nma.com> <p06020412bc98a5af5793@[128.89.89.75]> <40733B79.2A0AF2C8@nma.com> Date: Wed, 7 Apr 2004 10:02:09 -0400 To: Ed Gerck <egerck@nma.com> From: Stephen Kent <kent@bbn.com> Subject: Re: clarification proposal -- Re: Current status of CRLvalidation? Cc: ietf-pkix@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Ed, We agree that there are some edge cases re revocation, as Santosh noted. My objection to your text is that it fails to clarify. If you meant to say that - only the issuer of a cert is authoritative for revocation, and - relying on revocation status mechanisms such as OCSP and indirect CRLs may not provide direct evidence of the issuer's assertion of a cert's revocation status then say that. phrases like "...anything other than their value as a representation of the issuer CA revocation management policy" are just not helpful to most folks. Steve Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37FB2gp001430; Wed, 7 Apr 2004 08:11:02 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i37FB2aK001427; Wed, 7 Apr 2004 08:11:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37FB0De001402 for <ietf-pkix@imc.org>; Wed, 7 Apr 2004 08:11:00 -0700 (PDT) (envelope-from kent@bbn.com) Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i37FAt7d004992; Wed, 7 Apr 2004 11:10:58 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: <p06020403bc99b5e1231c@[128.89.89.75]> In-Reply-To: <4073866D.4090507@strongauth.com> References: <428a370f.370f428a@noorhome.net> <p06020403bc97150f71da@[128.89.89.75]> <40724DEC.3060007@strongauth.com> <p06020404bc985cf94cad@[128.89.89.75]> <4073866D.4090507@strongauth.com> Date: Wed, 7 Apr 2004 09:51:17 -0400 To: Arshad Noor <arshad.noor@strongauth.com> From: Stephen Kent <kent@bbn.com> Subject: Re: PKI International Consortium Cc: PKIX list <ietf-pkix@imc.org> Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> At 9:41 PM -0700 4/6/04, Arshad Noor wrote: >Stephen Kent wrote: > >>My suggestion is that the IMPACT of an identity theft incident >>would be worse if there are fewer credentials (e.g., certs) >>associated with an individual, rather than more. That notion is >>based on the assumption, stated elsewhere, that when we have more >>credentials, each has a narrower scope than if we have fewer, and >>thus the impact of a compromised credential is less severe. >> > Taken to its logical conclusion, an infinite number of > credentials per entity must lead to minimal impact of an > identity theft incident. However, humans cannot be expected to > deal with such mathematical elegance without becoming blithering > idiots. (Some of us just need a few Internet accounts to reach > that state :-)). > > Therefore, there must be some optimal number between 1 and > infinity that balances risk vs. the inconvenience of carrying > mulitple credentials. Once again, for lack of empirical > evidence, the identity firewall concept advances seven as the > optimal number. this is silly, almost to the point of being absurd. "Seven" as the optimal number sounds practically mystical. >There is no reason to believe that there is an optimal number of >credentials for an individual, since other factors affecting the >ease of identity theft have to do with the procedures used to issue >the credentials, and the extent to which secondary [uses] for >selected credentials are condoned. In fact, secondary uses are a >major factor in identity theft, which is often more of a procedural >failure than a technical, credential failure. > > My point exactly when I spoke of "inappropriate use of identity > data". However, in order to correct procedural failures, one > must look at all elements of the process - including the > technology and the data itself - and determine if that needs to > be corrected with with the process. > >>That is also why one ought not assume that use of >>certs, as a specific form of credential, will eradicate identity theft. >> > To paraphrase you, Steve, "My comment said nothing about > eradicating identity theft." (I do not believe it can ever be > eradicated - just made difficult enough to deter most people.) This paragraph makes no sense. Your previous message explicitly talked about eradicating identity theft, yet you are backtracking here. > Given the range of options that are available to technologists > today, balancing usability, cost and security, digital > certificates coupled with external cryptographic tokens and a > high-assurance issuance process, are an optimal solution. As > time goes by, it may very well not be so, but until I see > something better, that is the position I hold. I too am in favor of the use of certs with private keys maintained in hardware tokens and a high assurance issuing process, when the resources being accessed warrant such measures. But, "optimal" is an inappropriate term when we have such a wide range of resources that people access. Steve Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37EioGH099078; Wed, 7 Apr 2004 07:44:50 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i37EioxI099077; Wed, 7 Apr 2004 07:44:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from kraid.nerim.net (smtp-103-wednesday.nerim.net [62.4.16.103]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37Ein2B099071 for <ietf-pkix@imc.org>; Wed, 7 Apr 2004 07:44:49 -0700 (PDT) (envelope-from julien.stern@cryptolog.com) Received: from jupiter.cry.pto (cryptolog.net1.nerim.net [80.65.224.225]) by kraid.nerim.net (Postfix) with ESMTP id 07BDE418FB for <ietf-pkix@imc.org>; Wed, 7 Apr 2004 16:44:50 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by jupiter.cry.pto (Postfix) with ESMTP id 95B214195 for <ietf-pkix@imc.org>; Wed, 7 Apr 2004 16:44:50 +0200 (CEST) Received: from jupiter.cry.pto ([127.0.0.1]) by localhost (jupiter [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 19338-07 for <ietf-pkix@imc.org>; Wed, 7 Apr 2004 16:44:50 +0200 (CEST) Received: from callisto.cry.pto (callisto.cry.pto [10.0.1.4]) by jupiter.cry.pto (Postfix) with SMTP id 6787740B0 for <ietf-pkix@imc.org>; Wed, 7 Apr 2004 16:44:50 +0200 (CEST) Received: by callisto.cry.pto (sSMTP sendmail emulation); Wed, 7 Apr 2004 16:44:50 +0200 From: "Julien Stern" <julien.stern@cryptolog.com> Date: Wed, 7 Apr 2004 16:44:50 +0200 To: ietf-pkix@imc.org Subject: Re: Current status of CRL validation ? Message-ID: <20040407144450.GA742@cryptolog.com> References: <20040323103412.GA23286@cryptolog.com> <004f01c410dc$2c0681d0$df294d0c@hq.orionsec.com> <20040323142525.GA27672@cryptolog.com> <p06020406bc861b0a4627@[128.33.244.157]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <p06020406bc861b0a4627@[128.33.244.157]> User-Agent: Mutt/1.5.5.1+cvs20040105i X-Virus-Scanned: by amavisd-new-20030314-p2 (Debian) at cryptolog.com Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> On Tue, Mar 23, 2004 at 11:56:01AM -0500, Stephen Kent wrote: > > Julien, > > The confusion stems from somewhat sloppy use of terminology in these > discussions. > > Only the issuer of a cert can revoke it and in X.509 (unlike PGP) > there is only one issuer for a given cert. So, the revocation > question as you stated it was not well formed. Stephen, I do not believe that only the issuer of a cert can revoke it, notably when indirect CRL are used. > A cert is either revoked or not. Well, I'm sincerely starting to believe this is not true :) and not because of lack of available information. Please point me to the flaw in the following setting: +-----+ +-----+ I have a certificate (Cert). Two | CA1 | | | Different CAs (CA4 and CA5) have | DN1 | | DN1 | matching issuer DN and keys for it. | PK1 | | | +-----+ +-----+ These two CAs have two super CAs / \ | signed by the same root. +-----+ +-----+ +-----+ | CA2 | | CA3 | | | I also have a CRL which refers to | DN2 | | DN3 | | DN3 | the certificate but whose only | PK2 | | PK3 | | | chain up to DN1 is going through +-----+ +-----+ +-----+ DN4 and DN3 (but NOT DN2). | | | +-----+ +-----+ +-----+ Now assume that the left path | CA4 | | CA5 | | | (CA1 -> CA2 -> CA4 -> Cert) | DN4 | | DN4 | | DN4 | is valid for SOME policies, and | PK4 | | PK4 | | | the right path is valid for some +-----+ +-----+ +-----+ OTHER policies. \ / | +-----+ +-----+ |Cert | | CRL | +-----+ +-----+ If I try to validate the certificate with the "left" policy mappings, only the "left" chain will be valid. Then, I will check the chain for the CRL, which will be valid and will match the DN matching rule, so I will conclude that the certificate is revoked. If I try to validate the certificate with the "right" policy mappings, onle the "right" chain will be valid. Then, I will check the chain for the CRL, which will not match the DN matching rule, so I will not be able to verify the validity of the CRL, and hence conclude that the certificate is valid. Sincerely, -- Julien Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37DsfkN095177; Wed, 7 Apr 2004 06:54:41 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i37DsfZq095176; Wed, 7 Apr 2004 06:54:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp.cs.auckland.ac.nz (smtp.cs.auckland.ac.nz [130.216.33.151]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37DsXRG095063 for <ietf-pkix@imc.org>; Wed, 7 Apr 2004 06:54:34 -0700 (PDT) (envelope-from pgut001@cs.auckland.ac.nz) Received: from medusa01 (medusa01.cs.auckland.ac.nz [130.216.34.33]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id 9454E34045; Thu, 8 Apr 2004 01:52:39 +1200 (NZST) Received: from pgut001 by medusa01 with local (Exim 4.30) id 1BBDVo-0007xX-6o; Thu, 08 Apr 2004 01:54:40 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: adriano.santoni@actalis.it, ietf-pkix@imc.org Subject: Re: RFC3280: doubt on the use of UTF8String in encoding RDNs In-Reply-To: <BE82E060F5EA2D44A4CFCFFA83639588015D32B4@ntexch00.office.sia.it> Message-Id: <E1BBDVo-0007xX-6o@medusa01> Date: Thu, 08 Apr 2004 01:54:40 +1200 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Santoni Adriano <adriano.santoni@actalis.it> writes: >I am probably asking an old question, so ... please be patient. > >Rfc3280 states (<A7>4.1.2.4): "...all certificates issued after December 31, >2003 MUST use the UTF8String encoding of DirectoryString...". > >Does that mean that it is mandatory to always encode all RDNs (having a type >of DirectoryString) of the issuer and subject (and still other) certificate >fields as UTF8Strings _even if they could be correctly encoded as a >PrintableStrings_ ? Hmm, see the previous thread on this a few months ago... in theory you're supposed to do this, but that violates the primary rule of DN encoding, which is "Never change the DN once it's been encoded by the originator". If you break that rule, you get to discover all the apps that reject re-encoded DNs. If you're lucky, this will happen before your product ships and not after. Peter. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37Dokms094776; Wed, 7 Apr 2004 06:50:46 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i37Doku4094775; Wed, 7 Apr 2004 06:50:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp.cs.auckland.ac.nz (smtp.cs.auckland.ac.nz [130.216.33.151]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37Doco9094762 for <ietf-pkix@imc.org>; Wed, 7 Apr 2004 06:50:41 -0700 (PDT) (envelope-from pgut001@cs.auckland.ac.nz) Received: from medusa01 (medusa01.cs.auckland.ac.nz [130.216.34.33]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id 4F95F34045; Thu, 8 Apr 2004 01:48:43 +1200 (NZST) Received: from pgut001 by medusa01 with local (Exim 4.30) id 1BBDRz-0007xA-S9; Thu, 08 Apr 2004 01:50:43 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-pkix@imc.org, jmdesp@free.fr Subject: Re: Re-certification In-Reply-To: <40706853.2030401@free.fr> Message-Id: <E1BBDRz-0007xA-S9@medusa01> Date: Thu, 08 Apr 2004 01:50:43 +1200 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Jean-Marc Desperrier <jmdesp@free.fr> writes: >AFAIK I have never seen Verisign *change* the key pair of an authority. They >always extend validity, while keeping the same key pair. Ah, sorry, I was a bit too quick in my reply, what I meant was that they kept the DN, key, and start date, and only changed the end date and serial number. I was never quite sure why they kept the validFrom date, I can understand wanting to leave a bit of overlap, but the new certs were backdated many years through the direct copying of the validFrom. Peter. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37CnjGO090753; Wed, 7 Apr 2004 05:49:45 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i37Cnj4g090752; Wed, 7 Apr 2004 05:49:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37CniaM090746 for <ietf-pkix@imc.org>; Wed, 7 Apr 2004 05:49:44 -0700 (PDT) (envelope-from chokhani@orionsec.com) Received: from wchokhani3 (dpvc-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i37CnkAt012502 for <ietf-pkix@imc.org>; Wed, 7 Apr 2004 08:49:46 -0400 From: "Santosh Chokhani" <chokhani@orionsec.com> To: <ietf-pkix@imc.org> Subject: RE: clarification proposal -- Re: Current status of CRL validation? Date: Wed, 7 Apr 2004 08:49:46 -0400 Message-ID: <006901c41c9e$ce5676c0$9a00a8c0@hq.orionsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <4073BC11.8D67D601@nma.com> Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i37CnjaM090747 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> -----Original Message----- From: Ed Gerck [mailto:egerck@nma.com] Sent: Wednesday, April 07, 2004 4:30 AM To: Santosh Chokhani Cc: ietf-pkix@imc.org Subject: Re: clarification proposal -- Re: Current status of CRL validation? Ed: Please read X.509 and 3280 carefully. There is no mechanism to limit the time of delegation. See the syntax and semantics of CRL DP extension. Also, there is no requirement for the certificate issuing CA to issue a CRL and if the Indirect CRL is checked by the relying party, there is no requirement to check any CRL issued by the issuing CA. Actually, if the CRL DP extension is marked critical and it points to an indirect CRL issuer, you MUST check that CRL. Santosh Chokhani wrote: > > Any chnage of this nature is inconsistent with how X.509 and 3280 are. Can you please point to the inconsistency in each case? I don't see it. When X.509 says that a CA may delegate the responsibility of issuing CRLs to another trusted authority, X.509 does not bar the issuer CA from using its revocation management policy to govern all representations made to RPs, whether they are delegated or not. In fact, I understand that the issuer CA is authoritative to decide all aspects of such delegation. What happens, for example, if the delegated CRL issuer oversteps the limits of the issuer CA delegation when issuing a CRL (e.g., by issuing the CRL after the delegation expires)? As I understand it, X.509 says that the CRL is not valid in this case. The responsibility of issuing the CRL was not, in fact, delegated by the issuer CA when the CRL was issued. Thus, with delegation or not, a RP cannot rely upon the confirmation procedures of any party that the RP chooses (e.g., a delegated CRL issuer, or an indirect CRL issuer) for anything other than their value as a representation of the issuer CA revocation management policy. Comments? Cheers, Ed Gerck Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37CWKpT089470; Wed, 7 Apr 2004 05:32:20 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i37CWKOb089469; Wed, 7 Apr 2004 05:32:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37CWJRH089463 for <ietf-pkix@imc.org>; Wed, 7 Apr 2004 05:32:20 -0700 (PDT) (envelope-from chokhani@orionsec.com) Received: from wchokhani3 (dpvc-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i37CWLAt007549 for <ietf-pkix@imc.org>; Wed, 7 Apr 2004 08:32:21 -0400 From: "Santosh Chokhani" <chokhani@orionsec.com> To: <ietf-pkix@imc.org> Subject: RE: Signing Untrusted SCVP? Date: Wed, 7 Apr 2004 08:32:21 -0400 Message-ID: <005c01c41c9c$5f98c5a0$9a00a8c0@hq.orionsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <40737613.3080801@corestreet.com> Importance: Normal Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Given the limited value of signature, DPD response signature by the server should be optional and signature verification by the client should be optional. The question we should answer is that is there any benefit to adding an option for the client to request a signature and then should the DPD server be forced to sign the response (shades of OCSP nonce) -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of David Engberg Sent: Tuesday, April 06, 2004 11:32 PM To: Stephen Kent Cc: ietf-pkix@imc.org Subject: Re: Signing Untrusted SCVP? Stephen - You have provided interesting techniques that an attacker could use to make a DPD client waste an extra 500ms verifying signatures before displaying a "bad path returned from server" dialog (or the equivalent). That same attacker with the same advantages (DNS spoofing, etc.) could achieve the same effective denial of path discovery even if an extra signature is thrown on responses. The attacker could obviously make clients waste time & bandwidth in lots of sneaky ways, although the relying application would ultimately report different error messages ("unknown host: 'scvp.eubridge.org'", "connection timed out", "no route to host", "response signature verify failed", etc.). I am curious whether the type of attack that you describe has ever been performed against a non-SSL LDAP directory in a manner that would not have been equally effective if SSL was in use. While there is definitely a difference here, I think (hope?) that we agree that it may be useful for a PKI administrator to have the choice to deploy a path discovery mechanism which does not require a fresh signature from a protected server key for every request. This would allow an administrator to balance the DoS risks for clients against the DoS risks for servers. My guess is that virtually all real world DoS attacks exploit the centralized nature of secured servers, and the best cure for this is the sort of distributed redundancy that a keyless or two-tier-caching DPD responder architecture would permit. For example, Akamai has 16,000+ servers around the world with no SSL private keys. They are subjected to daily DoS attempts (e.g. they host www.whitehouse.gov), which fail not due to the magic of PKI, but rather due to the redundancy you can build when you don't have to secure keys at every server. Thanks Stephen Kent wrote: ... > if an attacker can spoof a DNS response, he can cause the client to > connect to him instead of the server, which would enable the bogus > server to receive the request as well as generate and send the > response, and in the absence of a signed response, the client cannot > know that he is not communicating with the intended server. > > a bogus server could then return bogus cert chains that fail to > validate, but which waste client resources. just how effective this > may be will be a function of client implementation details, which are > outside the scope of our standards. ... Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i378gGCw063515; Wed, 7 Apr 2004 01:42:16 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i378gGvT063514; Wed, 7 Apr 2004 01:42:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from av5-1-sn1.fre.skanova.net (av5-1-sn1.fre.skanova.net [81.228.11.111]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i378gEp7063475 for <ietf-pkix@imc.org>; Wed, 7 Apr 2004 01:42:15 -0700 (PDT) (envelope-from anders.rundgren@telia.com) Received: by av5-1-sn1.fre.skanova.net (Postfix, from userid 502) id 1511737EC8; Wed, 7 Apr 2004 10:42:10 +0200 (CEST) Received: from smtp3-2-sn1.fre.skanova.net (smtp3-2-sn1.fre.skanova.net [81.228.11.164]) by av5-1-sn1.fre.skanova.net (Postfix) with ESMTP id 083D737E4F; Wed, 7 Apr 2004 10:42:10 +0200 (CEST) Received: from arport (t10o913p100.telia.com [213.64.27.220]) by smtp3-2-sn1.fre.skanova.net (Postfix) with SMTP id E7B5037E73; Wed, 7 Apr 2004 10:42:02 +0200 (CEST) Message-ID: <006701c41c7b$2f013560$0500a8c0@arport> From: "Anders Rundgren" <anders.rundgren@telia.com> To: "Arshad Noor" <arshad.noor@strongauth.com> Cc: "PKIX list" <ietf-pkix@imc.org> References: <200404031056.MAA21125@sol10.lcc.uma.es> <40739294.9050705@strongauth.com> Subject: IF-issued credentials. Was: PKI International Consortium Date: Wed, 7 Apr 2004 10:34:38 +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 Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Arshad, >So, one could get oneself a Financial industry credential, for >instance, by going through the industry's issuance process, and >yet not have a single bank/brokerage account at all (not very >useful, I realize - nonetheless that is the premise). Absolutely, this is BTW already a reality in Scandinavia. >This individual, armed with the Financial credential, can now >approach any financial institution that honored the credential, >and open an account. However, depending on the context of the >account & the transactions the individual may wish to carry out >against that account, the financial institution may want to >determine a number of attributes about that individual before >granting him/her that privilege. I would extend this to include *any* relying party that is prepared to trust FI-issued credentials. e-governments are the first to make use of this. Now, to the more general use of FI-issued identity credentials. The need for certificates specifying employment or similar is greatly exaggerated which is proven by the fact that the current "authentication standard" (userid/password), does not force you to specify "John Doe, Marketing, IBM, Armonk, US" but rather "JohnDoe34" (and maybe a domain) as the various backend systems already have all other information needed to authorize access to the different internal systems. The use of employment-style certificates outside of the company border is never going to happen on a wider scale because that idea is conceptually completely flawed. Well, an IBM company badge may indeed give you 10% discount at Tony's Pizza, but that's about it. >I realize that there may be situations where AC's may be more >effective, but I haven't seen a convincing business example that >cannot be implemented more effectively - and just as securely - >with LDAP-based Directories, at lower costs. I agree 100%. rgds Anders R Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i378VBJU059889; Wed, 7 Apr 2004 01:31:11 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i378VBwO059888; Wed, 7 Apr 2004 01:31:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail13.atl.registeredsite.com (nobody@mail13.atl.registeredsite.com [64.224.219.87]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i378VBF4059878 for <ietf-pkix@imc.org>; Wed, 7 Apr 2004 01:31:11 -0700 (PDT) (envelope-from egerck@nma.com) Received: from taurus.hosting4u.net (taurus.hosting4u.net [209.35.191.122]) by mail13.atl.registeredsite.com (8.12.8/8.12.8) with ESMTP id i378VBbG000573; Wed, 7 Apr 2004 08:31:11 GMT Received: from nma.com ([63.204.17.85]) by taurus.hosting4u.net ; Wed, 07 Apr 2004 03:31:10 -0500 Message-ID: <4073BC11.8D67D601@nma.com> Date: Wed, 07 Apr 2004 01:30:09 -0700 From: Ed Gerck <egerck@nma.com> X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Santosh Chokhani <chokhani@orionsec.com> CC: ietf-pkix@imc.org Subject: Re: clarification proposal -- Re: Current status of CRL validation? References: <20040323103412.GA23286@cryptolog.com> <004f01c410dc$2c0681d0$df294d0c@hq.orionsec.com> <20040323142525.GA27672@cryptolog.com> <p06020406bc861b0a4627@[128.33.244.157]> <406A0839.14F7C3A1@nma.com> <p06020401bc909a0b8ec1@[128.89.89.75]> <406B0593.FD2E1F6B@nma.com> <p06020408bc90bbc275a7@[128.89.89.75]> <406DE8AD.BC0DA38@nma.com> <p06020411bc9750745da7@[128.89.89.75]> <4071AB84.14898140@nma.com> <p0602041ebc977ad14b67@[128.89.89.75]> <4071DE2E.B5BED74A@nma.com> <p06020405bc9860671a8f@[128.89.89.75]> <4072EABB.D2A50271@nma.com> <p06020412bc98a5af5793@[128.89.89.75]> <40733B79.2A0AF2C8@nma.com> <20040407011016.M67361@orionsec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Santosh Chokhani wrote: > > Any chnage of this nature is inconsistent with how X.509 and 3280 are. Can you please point to the inconsistency in each case? I don't see it. When X.509 says that a CA may delegate the responsibility of issuing CRLs to another trusted authority, X.509 does not bar the issuer CA from using its revocation management policy to govern all representations made to RPs, whether they are delegated or not. In fact, I understand that the issuer CA is authoritative to decide all aspects of such delegation. What happens, for example, if the delegated CRL issuer oversteps the limits of the issuer CA delegation when issuing a CRL (e.g., by issuing the CRL after the delegation expires)? As I understand it, X.509 says that the CRL is not valid in this case. The responsibility of issuing the CRL was not, in fact, delegated by the issuer CA when the CRL was issued. Thus, with delegation or not, a RP cannot rely upon the confirmation procedures of any party that the RP chooses (e.g., a delegated CRL issuer, or an indirect CRL issuer) for anything other than their value as a representation of the issuer CA revocation management policy. Comments? Cheers, Ed Gerck Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3770m5L028549; Wed, 7 Apr 2004 00:00:48 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3770maq028547; Wed, 7 Apr 2004 00:00:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail13.atl.registeredsite.com (nobody@mail13.atl.registeredsite.com [64.224.219.87]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3770lr0028538 for <ietf-pkix@imc.org>; Wed, 7 Apr 2004 00:00:47 -0700 (PDT) (envelope-from egerck@nma.com) Received: from taurus.hosting4u.net (taurus.hosting4u.net [209.35.191.122]) by mail13.atl.registeredsite.com (8.12.8/8.12.8) with ESMTP id i3770kbG007765 for <ietf-pkix@imc.org>; Wed, 7 Apr 2004 07:00:46 GMT Received: from nma.com ([63.204.17.85]) by taurus.hosting4u.net ; Wed, 07 Apr 2004 02:00:45 -0500 Message-ID: <4073A6E1.6F65D002@nma.com> Date: Tue, 06 Apr 2004 23:59:45 -0700 From: Ed Gerck <egerck@nma.com> X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: PKIX list <ietf-pkix@imc.org> Subject: Re: PKI International Consortium References: <428a370f.370f428a@noorhome.net> <p06020403bc97150f71da@[128.89.89.75]> <40724DEC.3060007@strongauth.com> <p06020404bc985cf94cad@[128.89.89.75]> <4073866D.4090507@strongauth.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Rcpt-To: <ietf-pkix@imc.org> Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Arshad Noor wrote: > Therefore, there must be some optimal number between 1 and > infinity that balances risk vs. the inconvenience of carrying > mulitple credentials. Once again, for lack of empirical > evidence, the identity firewall concept advances seven as the > optimal number. There is no logic requiring a global optimum, or even the same global optimum, for the number of credentials for all users and all uses at all times. Empirical evidence supports the assertion that we all have a growing number of credentials with time, including all the expired ones. Yes, expired credentials are useful. For example, as supporting evidence to issue a renewed credential and/or as a credential with less privileges. In such context, the idea that "seven" might be a magical number is already outdated ;-) Cheers, Ed Gerck Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i376ium0022968; Tue, 6 Apr 2004 23:44:56 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i376iuxB022967; Tue, 6 Apr 2004 23:44:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail12.atl.registeredsite.com (nobody@mail12.atl.registeredsite.com [64.224.219.86]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i376itB2022958 for <ietf-pkix@imc.org>; Tue, 6 Apr 2004 23:44:55 -0700 (PDT) (envelope-from egerck@nma.com) Received: from taurus.hosting4u.net (taurus.hosting4u.net [209.35.191.122]) by mail12.atl.registeredsite.com (8.12.8/8.12.8) with ESMTP id i376is8E023211; Wed, 7 Apr 2004 06:44:54 GMT Received: from nma.com ([63.204.17.85]) by taurus.hosting4u.net ; Wed, 07 Apr 2004 01:44:53 -0500 Message-ID: <4073A329.F1580375@nma.com> Date: Tue, 06 Apr 2004 23:43:53 -0700 From: Ed Gerck <egerck@nma.com> X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "David P. Kemp" <dpkemp@missi.ncsc.mil> CC: ietf-pkix@imc.org Subject: Re: clarification proposal -- Re: Current status of CRL validation? References: <20040323103412.GA23286@cryptolog.com> <004f01c410dc$2c0681d0$df294d0c@hq.orionsec.com> <20040323142525.GA27672@cryptolog.com> <p06020406bc861b0a4627@[128.33.244.157]> <406A0839.14F7C3A1@nma.com> <p06020401bc909a0b8ec1@[128.89.89.75]> <406B0593.FD2E1F6B@nma.com> <p06020408bc90bbc275a7@[128.89.89.75]> <406DE8AD.BC0DA38@nma.com> <p06020411bc9750745da7@[128.89.89.75]> <4071AB84.14898140@nma.com> <p0602041ebc977ad14b67@[128.89.89.75]> <4071DE2E.B5BED74A@nma.com> <200404062119.i36LJ3RK028502@stingray.missi.ncsc.mil> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Dave, I agree: "Since there may be more than one path used to validate the same certificate, it is possible that some paths to that certificate are valid while others are not." However: (1) the valid paths may present the same answer but at least one of the answers is stale and should have been different at that time (e.g., due to delays before and after publication), (2) the valid paths may present conflicting answers (e.g., due to race conditions), (3) even though in principle the answers are always resolvable to one conclusion (since an X.509/PKIX cert is either revoked or not), resolution may be impossible in practical terms by a RP software. For example, it may need more time than what's available, and/or need additional channels not included/reachable by that RP software, and/or need human intervention. An ambiguous answer may exist by conditions (1), (2), (3) or their combinations. In other words, it is possible for a RP to obtain two *conflicting* answers for the same cert. It is also possible for different RPs to obtain *conflicting* answers for the same cert. These possibilities, and you are correct, can be concluded from that first paragraph. Nonetheless, from the issuer CA viewpoint, the cert is either revoked or not. Unambiguously. Is this a flaw? The rather surprising answer is that it isn't. An ambiguous answer is more informative than an unknown answer -- which is also possible. In other words, a RP would rather have an ambiguous answer than an unknown answer. For example, the issuer CA informs that the cert is not in the current CRL while an indirect CRL issuer informs that the cert is "revoked". This is informative and might be used by the RP software. Moreover, even when a validation engine used by RP software does return answers that are all valid and look unambiguous there is always some degree of unreliability because the occurrence of (1), (2), (3) or their combinations cannot be ruled out. When such things are considered, is revocation information useful? Surely, as it allows the RP software to have more information on the cert revocation status than without it. However, there are caveats and even experts may disagree on their description. Presenting those caveats in a clear and unified way, with some degree of consensus, was the purpose behind the proposed two paragraphs in the clarification Note (with their edits/improvements as further discussed in this thread). Comments? Cheers, Ed Gerck PS: In information theory terms, a RP software should need to use more than one reporting channel in order to validate cert revocation status with some degree of reliability. The improved results should compensate the additional efforts. This may validate the use of indirect CRL issuers and responders trusted by the RP, in addition to the issuer CA. As a counter example, if the RP has only one channel (e.g., the issuer CA CRL) presenting the information that the cert is not revoked, that information is accurate (there is only one value) but is not reliable (the issuer CA CRL may be outdated). Conversely, if we have three or more channels (e.g., the issuer CA CRL, an indirect CRL issuer, a responder trusted by the RP) presenting the information that the cert is not revoked, that information can be accurate (even if 2 out of 3 agree) and reliable. The use of two channels, even though it would lead to an ambiguity in case of a single failure, would still be an improvement over the single channel case (that has a single point of failure) of the issuer CA alone providing the revocation information. "David P. Kemp" wrote: > > Ed, > > While the first paragraph is factually correct, it nonetheless may > lead the careless reader to an incorrect conclusion, namely that > it is possible for an RP to obtain two *conflicting* answers, rather > than merely two different answers. > > If you ask whether an IP packet can reach its destination through > a mesh of routers, the answer may well be that some paths are valid > while others are not due to link failures. But as long as at least > one path is valid, the destination is reachable. There is no > conflict between paths that are up and those that are down. > > There would be less chance of misinterpretation if your Note were > to say: > "Since there may be more than one path used to validate the > same certificate, it is possible that some paths to that > certificate are valid while others are not." > > As you say, there is an unambiguous validity status for each > certificate in every potential path. Validation engines used > by RP software can always return an unambiguous answer: > * valid if at least one valid path exists, > * invalid if no path is valid and all CRLs are available, or > * unknown if no path is known valid and at least one CRL for > a potentially valid path is unavailable. > > Dave > > Ed Gerck wrote: > > > > > > > Stephen Kent wrote: > > > >>Ed, > >> > >>PKIX is winding down now; we are not taking on any new work items. I > >>suspect that anything as basic as what you allude to would be a > >>significant departure from what we have done, and thus is not > >>appropriate for PKIX to pursue. > > > > > > Steve, > > > > How about a clarification to be added to the current PKIX documents > > that deal with revocation and validation of certs? This would help > > the weary reader, who must otherwise wade through this list's archives > > in order to find the limitations we have been discussing. For example > > (using some of your previous text): > > > > NOTE: > > In X.509/PKIX only the issuer of a certificate can revoke it and there > > is only one issuer for a given certificate. Therefore, a certificate > > is either revoked or not. However, the ability of a RP to establish > > the validity of a certificate is a function of the certificate path > > that the RP uses to validate the certificate, and of the access to > > revocation status information available to the RP. Since there may be > > more than one path used to validate the same certificate, it is possible > > to obtain different answers to the question whether a certificate is > > valid, depending on which path the RP uses. Also, two RPs may have > > access to different revocation status data for the EE certificate or for > > a CA certificate along a path, so that each RP may arrive at a different > > view of the validity of the EE certificate at any given time. > > > > Moreover, in X.509/PKIX reliance terms, one may trust the confirmation > > procedures of the issuer CA, the issuer CA Designated Responder or any > > Trusted Responder during certificate reliance (i.e., whether the > > certificate has been revoked or not) under CRLs or OCSPs, but one cannot > > rely upon them for other than their value as a representation of the > > issuer CA revocation management as expressed in the issuer CA own terms > > and rules, usually contained in the CA CPS. > > > > Comments? > > > > Cheers, > > Ed Gerck > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i375X8lG092502; Tue, 6 Apr 2004 22:33:08 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i375X8xk092501; Tue, 6 Apr 2004 22:33:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from igw (adsl-63-194-79-229.dsl.snfc21.pacbell.net [63.194.79.229]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i375X8bF092444 for <ietf-pkix@imc.org>; Tue, 6 Apr 2004 22:33:08 -0700 (PDT) (envelope-from arshad.noor@strongauth.com) Received: from strongauth.com (athena.noorhome.net [192.168.0.10]) by igw.noorhome.net (iPlanet Messaging Server 5.2 Patch 1 (built Aug 19 2002)) with ESMTP id <0HVS00IB8BZTVA@igw.noorhome.net> for ietf-pkix@imc.org; Tue, 06 Apr 2004 22:16:41 -0700 (PDT) Date: Tue, 06 Apr 2004 22:33:08 -0700 From: Arshad Noor <arshad.noor@strongauth.com> Subject: Re: PKI International Consortium In-reply-to: <200404031056.MAA21125@sol10.lcc.uma.es> To: amg@lcc.uma.es Cc: PKIX list <ietf-pkix@imc.org> Message-id: <40739294.9050705@strongauth.com> Organization: StrongAuth, Inc. MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) References: <200404031056.MAA21125@sol10.lcc.uma.es> Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Antonio, some comments inline. amg@lcc.uma.es wrote: > Hi all, > > In line with Arshad's comments, I think there's some kind of misunderstanding > in this discussion. It seems that we're confusing Identity and Attributes (or > privileges). It is reasonable to think that one entity (anything that can have > a certificate) should have only one Identity (and therefore, only one Identity > Certificate). There are reasons that may justify having more than one > Identity, and I will come to that later, but let's assume for now that only > one Identity is enough. > > What has been mentioned in this thread is the need to have several (identity) > certificates for different purposes. Therefore, each of these "identity > certificates" will be "industry-specific" and will have different associated > semantics depending on the "industry" or purpose. In this way a "Financial > identity certificate" would mean "The cert holder has an associated account in > bank X and blah, blah". On the other hand my university certificate would > state that I am "professor of the Computer Science Department". Well, in my > opinion these are not "identity certificates" but "attribute certificates". > By proposing identity firewalls between industry-specific certs, I did not imply that any attributes would be associated with the identity (other than the basic DN, public key, key usages, etc). Although, each industry will almost certainly have some basic attributes implied, the advantage for the industry would come from having the minimum information in the identity cert to assure an RP of the identity, and leave the RP to address what information they needed to have to make authorization decisions. So, one could get oneself a Financial industry credential, for instance, by going through the industry's issuance process, and yet not have a single bank/brokerage account at all (not very useful, I realize - nonetheless that is the premise). This individual, armed with the Financial credential, can now approach any financial institution that honored the credential, and open an account. However, depending on the context of the account & the transactions the individual may wish to carry out against that account, the financial institution may want to determine a number of attributes about that individual before granting him/her that privilege. But the authorization process - which, as you rightly point out, now depends on the attributes associated with that individual - should be completely distinct from the identification process, and must be in the control of the context owner. > The newest version of X.509 provides a more suitable solution because it > clearly defines a framework where identity and attribute certificates, > although related, can be independently managed. That recommendation defines > new types of authorities, Attribute Authorities (AA), for the assignment of > privileges. It also defines the Source of Authority (SOA) as the ultimate > authority to assign a set of privileges. Additionally, it provides a > foundation to build a Privilege Management Infrastructure (PMI) that contain a > multiplicity of AAs, SOAs and final users. > > So, summarizing, if the idea is to have "context-sensitive identities", > then "Attribute Certificates" linked to a single "Identity Certificate" are > the best solution. > While Attribute Certficates appear to have some appealing characteristics, there are a number of competing technologies that may appear less daunting to corporate developers currently. LDAP-based Directories, for instance, allow a rich set of ACI's that can be used to build authorization frameworks. Since a vast majority of authorization decisions will occur within "closed" networks, it may turn out to be far more cost effective to build such frameworks out of LDAP-based Directories than AC based infrastructures. It is difficult enough getting companies to deploy regular PKI's correctly - and use them appropriately - without adding the complexity of Attribute Cert infrastructures. I realize that there may be situations where AC's may be more effective, but I haven't seen a convincing business example that cannot be implemented more effectively - and just as securely - with LDAP-based Directories, at lower costs. Arshad Noor StrongAuth, Inc. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i374fHbu074735; Tue, 6 Apr 2004 21:41:17 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i374fHFP074734; Tue, 6 Apr 2004 21:41:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from igw (adsl-63-194-79-229.dsl.snfc21.pacbell.net [63.194.79.229]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i374fHiE074699 for <ietf-pkix@imc.org>; Tue, 6 Apr 2004 21:41:17 -0700 (PDT) (envelope-from arshad.noor@strongauth.com) Received: from strongauth.com (athena.noorhome.net [192.168.0.10]) by igw.noorhome.net (iPlanet Messaging Server 5.2 Patch 1 (built Aug 19 2002)) with ESMTP id <0HVS00I9X9LEVA@igw.noorhome.net> for ietf-pkix@imc.org; Tue, 06 Apr 2004 21:24:50 -0700 (PDT) Date: Tue, 06 Apr 2004 21:41:17 -0700 From: Arshad Noor <arshad.noor@strongauth.com> Subject: Re: PKI International Consortium In-reply-to: <p06020404bc985cf94cad@[128.89.89.75]> To: Stephen Kent <kent@bbn.com> Cc: PKIX list <ietf-pkix@imc.org> Message-id: <4073866D.4090507@strongauth.com> Organization: StrongAuth, Inc. MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) References: <428a370f.370f428a@noorhome.net> <p06020403bc97150f71da@[128.89.89.75]> <40724DEC.3060007@strongauth.com> <p06020404bc985cf94cad@[128.89.89.75]> Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Stephen Kent wrote: > My suggestion > is that the IMPACT of an identity theft incident would be worse if there > are fewer credentials (e.g., certs) associated with an individual, > rather than more. That notion is based on the assumption, stated > elsewhere, that when we have more credentials, each has a narrower scope > than if we have fewer, and thus the impact of a compromised credential > is less severe. > Taken to its logical conclusion, an infinite number of credentials per entity must lead to minimal impact of an identity theft incident. However, humans cannot be expected to deal with such mathematical elegance without becoming blithering idiots. (Some of us just need a few Internet accounts to reach that state :-)). Therefore, there must be some optimal number between 1 and infinity that balances risk vs. the inconvenience of carrying mulitple credentials. Once again, for lack of empirical evidence, the identity firewall concept advances seven as the optimal number. > There is no reason to believe that there is an optimal number of > credentials for an individual, since other factors affecting the ease of > identity theft have to do with the procedures used to issue the > credentials, and the extent to which secondary [uses] for selected credentials > are condoned. In fact, secondary uses are a major factor in identity > theft, which is often more of a procedural failure than a technical, > credential failure. My point exactly when I spoke of "inappropriate use of identity data". However, in order to correct procedural failures, one must look at all elements of the process - including the technology and the data itself - and determine if that needs to be corrected with with the process. That is also why one ought not assume that use of > certs, as a specific form of credential, will eradicate identity theft. > To paraphrase you, Steve, "My comment said nothing about eradicating identity theft." (I do not believe it can ever be eradicated - just made difficult enough to deter most people.) Given the range of options that are available to technologists today, balancing usability, cost and security, digital certificates coupled with external cryptographic tokens and a high-assurance issuance process, are an optimal solution. As time goes by, it may very well not be so, but until I see something better, that is the position I hold. Arshad Noor StrongAuth, Inc. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i373U5IG057176; Tue, 6 Apr 2004 20:30:05 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i373U5bS057175; Tue, 6 Apr 2004 20:30:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i373U5s0057131 for <ietf-pkix@imc.org>; Tue, 6 Apr 2004 20:30:05 -0700 (PDT) (envelope-from dengberg@corestreet.com) Received: from localhost (h005008001124.ne.client2.attbi.com[66.31.43.88]) by comcast.net (rwcrmhc12) with ESMTP id <2004040703300101400sd796e>; Wed, 7 Apr 2004 03:30:07 +0000 Received: from localhost ([127.0.0.1] helo=corestreet.com ident=dave) by localhost with esmtp (Exim 3.35 #1 (Debian)) id 1BB3mm-0007dx-00; Tue, 06 Apr 2004 23:31:32 -0400 Message-ID: <40737613.3080801@corestreet.com> Date: Tue, 06 Apr 2004 23:31:31 -0400 From: David Engberg <dengberg@corestreet.com> Organization: CoreStreet User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Kent <kent@bbn.com> CC: ietf-pkix@imc.org Subject: Re: Signing Untrusted SCVP? References: <B04FB2812116384A87D2968369C086977352A9@exchange.cenzic.com> <407210D5.4070404@corestreet.com> <p06020419bc98c58ecfd6@[128.89.89.75]> In-Reply-To: <p06020419bc98c58ecfd6@[128.89.89.75]> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Stephen - You have provided interesting techniques that an attacker could use to make a DPD client waste an extra 500ms verifying signatures before displaying a "bad path returned from server" dialog (or the equivalent). That same attacker with the same advantages (DNS spoofing, etc.) could achieve the same effective denial of path discovery even if an extra signature is thrown on responses. The attacker could obviously make clients waste time & bandwidth in lots of sneaky ways, although the relying application would ultimately report different error messages ("unknown host: 'scvp.eubridge.org'", "connection timed out", "no route to host", "response signature verify failed", etc.). I am curious whether the type of attack that you describe has ever been performed against a non-SSL LDAP directory in a manner that would not have been equally effective if SSL was in use. While there is definitely a difference here, I think (hope?) that we agree that it may be useful for a PKI administrator to have the choice to deploy a path discovery mechanism which does not require a fresh signature from a protected server key for every request. This would allow an administrator to balance the DoS risks for clients against the DoS risks for servers. My guess is that virtually all real world DoS attacks exploit the centralized nature of secured servers, and the best cure for this is the sort of distributed redundancy that a keyless or two-tier-caching DPD responder architecture would permit. For example, Akamai has 16,000+ servers around the world with no SSL private keys. They are subjected to daily DoS attempts (e.g. they host www.whitehouse.gov), which fail not due to the magic of PKI, but rather due to the redundancy you can build when you don't have to secure keys at every server. Thanks Stephen Kent wrote: ... > if an attacker can spoof a DNS response, he can cause the client to > connect to him instead of the server, which would enable the bogus > server to receive the request as well as generate and send the > response, and in the absence of a signed response, the client cannot > know that he is not communicating with the intended server. > > a bogus server could then return bogus cert chains that fail to > validate, but which waste client resources. just how effective this > may be will be a function of client implementation details, which are > outside the scope of our standards. ... Received: from dsl-201-128-127-206.prod-infinitum.com.mx (dsl-201-128-127-206.prod-infinitum.com.mx [201.128.127.206] (may be forged)) by above.proper.com (8.12.11/8.12.8) with SMTP id i3731mQ4049073; Tue, 6 Apr 2004 20:02:04 -0700 (PDT) (envelope-from Administration@computeradmin.org) Received: from 9vguq.kzf4.net ([89.149.170.109]) by dsl-201-128-127-206.prod-infinitum.com.mx; Wed, 07 Apr 2004 03:02:19 -0100 Message-ID: <438$$-1ob8-73$0b$64@x6r0a> From: "Admin" <Administration@computeradmin.org> To: equest@imc.org Subject: ADV: Attention All Nonprofit Orgs: (Members, Staff and Associates): Date: Wed, 07 Apr 04 03:02:19 GMT X-Priority: 1 X-MSMail-Priority: High X-Mailer: Microsoft Outlook, Build 10.0.2627 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="A5.F.C.B__593." This is a multi-part message in MIME format. --A5.F.C.B__593. Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Attention All Nonprofit Organizations, Members, Staff and Associates: You Must Respond By 5 P.M. Thursday, April 8, 2004. Through a special arrangement, Avtech Direct is offering a limited allotment of BRAND NEW, top of-the-line, name-brand desktop computers at more than 50% off MSRP to all Members, Staff and Associates who respond to this message before 5 P.M., Thursday, April 8, 2004. All desktop computers are brand-new packed in their original boxes, and come with a full manufacturer's warranty plus a 100% satisfaction guarantee. These professional grade Desktops are fully equipped with 2004 next generation technology, making these the best performing computers money can buy. Avtech Direct is offering these feature rich, top performing Desktop Computers with the latest Intel technology at an amazing price to all who call: 1-800-884-9510 by 5 P.M. Thursday, April 8, 2004 The fast and powerful AT-2400 series Desktop features: * Intel 2.0Ghz Processor for amazing speed and performance * 128MB DDR RAM, --- Upgradeable to 1024 * 20 GB UDMA Hard Drive, --- Upgradeable to 80 GB * 52X CD-Rom Drive, --- Upgradeable to DVD/CDRW * 1.44 Floppy disk drive * Next Generation Technology * ATI Premium video and sound * Full Connectivity with Fax modem/Lan/IEE 1394/USB 2.0 * Soft Touch Keyboard and scroll mouse * Internet Ready * Network Ready * 1 Year parts and labor warranty * Priority customer service and tech support MSRP $699 ........................................ Your Cost $297 How to qualify: 1. You must be a Member, Staff or Associate of a Nonprofit: 2. All desktop computers will be available on a first come first serve basis. 3. You must call 1-800-884-9510 by 5 P.M. Thursday, April 8, 2004 and we will hold the desktops you request on will call. 4. You are not obligated in any way. 5. 100% Satisfaction Guaranteed. Call Avtech Direct 1-800-884-9510 before 5 P.M. Thursday, April 8, 2004 If you wish to unsubscribe from this list, please go to: http://www.computeradvice.org/unsubscribe.asp --A5.F.C.B__593.-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i371ABxf000827; Tue, 6 Apr 2004 18:10:11 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i371ABpv000826; Tue, 6 Apr 2004 18:10:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i371AAVF000820 for <ietf-pkix@imc.org>; Tue, 6 Apr 2004 18:10:10 -0700 (PDT) (envelope-from chokhani@orionsec.com) Received: from orionsec.com (localhost [127.0.0.1]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i371AGAt008697 for <ietf-pkix@imc.org>; Tue, 6 Apr 2004 21:10:16 -0400 From: "Santosh Chokhani" <chokhani@orionsec.com> To: ietf-pkix@imc.org Subject: Re: clarification proposal -- Re: Current status of CRLvalidation? Date: Tue, 6 Apr 2004 21:10:16 -0400 Message-Id: <20040407011016.M67361@orionsec.com> In-Reply-To: <40733B79.2A0AF2C8@nma.com> References: <20040323103412.GA23286@cryptolog.com> <004f01c410dc$2c0681d0$df294d0c@hq.orionsec.com> <20040323142525.GA27672@cryptolog.com> <p06020406bc861b0a4627@[128.33.244.157]> <406A0839.14F7C3A1@nma.com> <p06020401bc909a0b8ec1@[128.89.89.75]> <406B0593.FD2E1F6B@nma.com> <p06020408bc90bbc275a7@[128.89.89.75]> <406DE8AD.BC0DA38@nma.com> <p06020411bc9750745da7@[128.89.89.75]> <4071AB84.14898140@nma.com> <p0602041ebc977ad14b67@[128.89.89.75]> <4071DE2E.B5BED74A@nma.com> <p06020405bc9860671a8f@[128.89.89.75]> <4072EABB.D2A50271@nma.com> <p06020412bc98a5af5793@[128.89.89.75]> <40733B79.2A0AF2C8@nma.com> X-Mailer: Open WebMail 1.81 20021127 X-OriginatingIP: 69.143.113.169 (chokhani) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Any chnage of this nature is inconsistent with how X.509 and 3280 are. On Tue, 06 Apr 2004 16:21:29 -0700, Ed Gerck wrote > Stephen Kent wrote: > > > > Ed Gerck wrote: > > > > > > To decide whether a certificate has been revoked or not, a RP may > > > trust the confirmation procedures of the issuer CA, or a proxy > > > designated by the CA, or any third party that the RP so chooses. > > > However, the RP cannot rely upon them for other than their value > > > as a representation of the issuer CA revocation management policy. > > > > Getting better. But the last sentence, as best I can make out, just > > says that the CA or its designees can only tell an RP about the > > revocation status of a cert as seen by the CA. This seems almost a > > tautology, and does not shed light on whatever subtle issue is > > lurking behind the words. > > Steve, > > I think your reply to Santoshi exemplifies why the second paragraph > is needed in the proposed clarification. It is not about the > "revocation status of a cert as seen by the CA". It is about who has > authoritative management of that status in what context. > > The second paragraph is needed to assert that the issuer CA is and > remains authoritative for the policy governing revocation management > of certs issued by that CA in *all* contexts. Even when such > revocation is delegated by the CA, or is designated to another > entity by the cert subscriber or by the RP. This goes beyond the > crypto math assurances underlying and linking the issuer CA > signature of the cert and its possible CRL. > > BTW, as an alternative to that second paragraph, I suggest: > > When deciding whether a certificate has been revoked or not, a RP > cannot rely upon the confirmation procedures of any party that the > RP chooses (e.g., a delegated CRL issuer, or an indirect CRL issuer) > for anything other than their value as a representation of the > issuer CA revocation management policy. The issuer CA is > authoritative for the revocation management of certificates issued > by that CA. > > Cheers, > Ed Gerck Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i36NMRSS090618; Tue, 6 Apr 2004 16:22:27 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i36NMRl3090617; Tue, 6 Apr 2004 16:22:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail14.atl.registeredsite.com (nobody@mail14.atl.registeredsite.com [64.224.219.88]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i36NMQ9Y090611 for <ietf-pkix@imc.org>; Tue, 6 Apr 2004 16:22:26 -0700 (PDT) (envelope-from egerck@nma.com) Received: from taurus.hosting4u.net (taurus.hosting4u.net [209.35.191.122]) by mail14.atl.registeredsite.com (8.12.8/8.12.8) with ESMTP id i36NMPQA015606; Tue, 6 Apr 2004 23:22:25 GMT Received: from nma.com ([63.204.17.85]) by taurus.hosting4u.net ; Tue, 06 Apr 2004 18:22:23 -0500 Message-ID: <40733B79.2A0AF2C8@nma.com> Date: Tue, 06 Apr 2004 16:21:29 -0700 From: Ed Gerck <egerck@nma.com> X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Stephen Kent <kent@bbn.com> CC: ietf-pkix@imc.org Subject: Re: clarification proposal -- Re: Current status of CRLvalidation? References: <20040323103412.GA23286@cryptolog.com> <004f01c410dc$2c0681d0$df294d0c@hq.orionsec.com> <20040323142525.GA27672@cryptolog.com> <p06020406bc861b0a4627@[128.33.244.157]> <406A0839.14F7C3A1@nma.com> <p06020401bc909a0b8ec1@[128.89.89.75]> <406B0593.FD2E1F6B@nma.com> <p06020408bc90bbc275a7@[128.89.89.75]> <406DE8AD.BC0DA38@nma.com> <p06020411bc9750745da7@[128.89.89.75]> <4071AB84.14898140@nma.com> <p0602041ebc977ad14b67@[128.89.89.75]> <4071DE2E.B5BED74A@nma.com> <p06020405bc9860671a8f@[128.89.89.75]> <4072EABB.D2A50271@nma.com> <p06020412bc98a5af5793@[128.89.89.75]> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Stephen Kent wrote: > > Ed Gerck wrote: > > > > To decide whether a certificate has been revoked or not, a RP may > > trust the confirmation procedures of the issuer CA, or a proxy > > designated by the CA, or any third party that the RP so chooses. > > However, the RP cannot rely upon them for other than their value > > as a representation of the issuer CA revocation management policy. > > Getting better. But the last sentence, as best I can make out, just > says that the CA or its designees can only tell an RP about the > revocation status of a cert as seen by the CA. This seems almost a > tautology, and does not shed light on whatever subtle issue is > lurking behind the words. Steve, I think your reply to Santoshi exemplifies why the second paragraph is needed in the proposed clarification. It is not about the "revocation status of a cert as seen by the CA". It is about who has authoritative management of that status in what context. The second paragraph is needed to assert that the issuer CA is and remains authoritative for the policy governing revocation management of certs issued by that CA in *all* contexts. Even when such revocation is delegated by the CA, or is designated to another entity by the cert subscriber or by the RP. This goes beyond the crypto math assurances underlying and linking the issuer CA signature of the cert and its possible CRL. BTW, as an alternative to that second paragraph, I suggest: When deciding whether a certificate has been revoked or not, a RP cannot rely upon the confirmation procedures of any party that the RP chooses (e.g., a delegated CRL issuer, or an indirect CRL issuer) for anything other than their value as a representation of the issuer CA revocation management policy. The issuer CA is authoritative for the revocation management of certificates issued by that CA. Cheers, Ed Gerck Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i36MvR7K089372; Tue, 6 Apr 2004 15:57:27 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i36MvRdq089371; Tue, 6 Apr 2004 15:57:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail13.atl.registeredsite.com (nobody@mail13.atl.registeredsite.com [64.224.219.87]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i36MvQOE089365 for <ietf-pkix@imc.org>; Tue, 6 Apr 2004 15:57:27 -0700 (PDT) (envelope-from egerck@nma.com) Received: from taurus.hosting4u.net (taurus.hosting4u.net [209.35.191.122]) by mail13.atl.registeredsite.com (8.12.8/8.12.8) with ESMTP id i36MvVbG019909; Tue, 6 Apr 2004 22:57:31 GMT Received: from nma.com ([63.204.17.85]) by taurus.hosting4u.net ; Tue, 06 Apr 2004 17:57:30 -0500 Message-ID: <407335A3.C37F2E24@nma.com> Date: Tue, 06 Apr 2004 15:56:35 -0700 From: Ed Gerck <egerck@nma.com> X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Santosh Chokhani <chokhani@orionsec.com> CC: ietf-pkix@imc.org Subject: Re: clarification proposal -- Re: Current status of CRL validation ? References: <009f01c41c00$8049e280$9a00a8c0@hq.orionsec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Santosh Chokhani wrote: > > Steve: > > I do not have objection to parts of the first paragraph. But, the first two > sentences of the paragraph are not accurate by most interpretations. I > quote: > > "In X.509/PKIX only the issuer of a certificate can revoke it and there is > only one issuer for a given certificate. Therefore, a certificate is either > revoked or not." > > Through indirect CRL issuer mechanism (as defined in X.509 and in 3280), an > indirect CRL issuer can revoke a certificate with or without the knowledge > of the certificate issuing CA. Since neither standard provide operations > related guidance (lack of this guidance is appropriate in the case of both > the standards), a subscriber can directly contact indirect CRL issuer and > have their certificate placed on the CRL. Santosh, Yes, semantically, an indirect CRL issuer can "revoke" a cert as requested by the cert's subscriber. However, does this mean that the revocation signature is chained to the issuer CA of that cert? Not necessarily. Thus, a RP may have no way of knowing whether such "revocation" is bogus or not. The issuer CA is the only authoritative source, by virtue of crypto math, that can revoke a cert (or delegate such revocation by chaining). Anything else is not much more than hearsay. That's exactly why I added the second paragraph to the proposed clarification note. It says that, when deciding whether a certificate has been revoked or not, a RP cannot rely upon the confirmation procedures of any party that the RP chooses (e.g., a delegated CRL issuer, or an indirect CRL issuer) for anything other than their value as a representation of the issuer CA revocation management policy. Cheers, Ed Gerck Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i36MH288086723; Tue, 6 Apr 2004 15:17:02 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i36MH21L086722; Tue, 6 Apr 2004 15:17:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i36MH1xL086716 for <ietf-pkix@imc.org>; Tue, 6 Apr 2004 15:17:02 -0700 (PDT) (envelope-from chokhani@orionsec.com) Received: from wchokhani3 (dpvc-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i36MH6At020200 for <ietf-pkix@imc.org>; Tue, 6 Apr 2004 18:17:07 -0400 From: "Santosh Chokhani" <chokhani@orionsec.com> To: <ietf-pkix@imc.org> Subject: RE: clarification proposal -- Re: Current status of CRL validation ? Date: Tue, 6 Apr 2004 18:17:06 -0400 Message-ID: <011201c41c24$e5b9b590$9a00a8c0@hq.orionsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <p0602041dbc98da4eaca5@[128.89.89.75]> Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Steve: Here is the quote from 3280, paragraph 3, Section 5. "CRL issuers issue CRLs. In general, the CRL issuer is the CA. CAs publish CRLs to provide status information about the certificates they issued. However, a CA may delegate this responsibility to another trusted authority. Whenever the CRL issuer is not the CA that issued the certificates, the CRL is referred to as an indirect CRL." This may have been done to accommodate OCSP, but as the RFC is written, it should be interpreted to accommodate various situations, not just OCSP. -----Original Message----- From: Stephen Kent [mailto:kent@bbn.com] Sent: Tuesday, April 06, 2004 6:08 PM To: Santosh Chokhani Cc: ietf-pkix@imc.org Subject: RE: clarification proposal -- Re: Current status of CRL validation ? At 5:48 PM -0400 4/6/04, Santosh Chokhani wrote: >Steve: > >Both X.509 and 3280 are very clear in this area. The CA need not issue >CRL >(ref: introduction in 3280 and paragraph 3 in introduction of Section 5 in >3280 just as a start and there is more). yes, but I thought that was an accommodation for OCSP, in the case of 3280. >The relying party software can use the indirect CRL issuer information >and thus from software viewpoint, certificate issuer may not be >involved. yes, but doing so is dangerous unless there are appropriate controls on the set of CAs for which the indicates CA can issue indirect CRLs. I bet such controls are rarely if ever available on clients. > >From operations, viewpoint, I gave a simple model where the >certificate issuer is not involved. > >Thus, adding those sentences creates conflict in the standard. > >Now, to the security issue, I agree that indirect CRL mechanism is not >a good idea. It should be a matter of relying party policy. well, at least we agree on that, which is the underlying issue here. Steve Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i36M9aHn086024; Tue, 6 Apr 2004 15:09:36 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i36M9aav086023; Tue, 6 Apr 2004 15:09:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i36M9aeD086017 for <ietf-pkix@imc.org>; Tue, 6 Apr 2004 15:09:36 -0700 (PDT) (envelope-from kent@bbn.com) Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i36M9a7X003970; Tue, 6 Apr 2004 18:09:36 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: <p0602041dbc98da4eaca5@[128.89.89.75]> In-Reply-To: <00ff01c41c20$e9fe60f0$9a00a8c0@hq.orionsec.com> References: <00ff01c41c20$e9fe60f0$9a00a8c0@hq.orionsec.com> Date: Tue, 6 Apr 2004 18:08:10 -0400 To: "Santosh Chokhani" <chokhani@orionsec.com> From: Stephen Kent <kent@bbn.com> Subject: RE: clarification proposal -- Re: Current status of CRL validation ? Cc: <ietf-pkix@imc.org> Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> At 5:48 PM -0400 4/6/04, Santosh Chokhani wrote: >Steve: > >Both X.509 and 3280 are very clear in this area. The CA need not issue CRL >(ref: introduction in 3280 and paragraph 3 in introduction of Section 5 in >3280 just as a start and there is more). yes, but I thought that was an accommodation for OCSP, in the case of 3280. >The relying party software can use the indirect CRL issuer information and >thus from software viewpoint, certificate issuer may not be involved. yes, but doing so is dangerous unless there are appropriate controls on the set of CAs for which the indicates CA can issue indirect CRLs. I bet such controls are rarely if ever available on clients. > >From operations, viewpoint, I gave a simple model where the certificate >issuer is not involved. > >Thus, adding those sentences creates conflict in the standard. > >Now, to the security issue, I agree that indirect CRL mechanism is not a >good idea. It should be a matter of relying party policy. well, at least we agree on that, which is the underlying issue here. Steve Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i36LnVnj084027; Tue, 6 Apr 2004 14:49:31 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i36LnVBH084026; Tue, 6 Apr 2004 14:49:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i36LnUf7084019 for <ietf-pkix@imc.org>; Tue, 6 Apr 2004 14:49:30 -0700 (PDT) (envelope-from dpkemp@missi.ncsc.mil) Message-ID: <200404062119.i36LJ3RK028502@stingray.missi.ncsc.mil> Date: Tue, 06 Apr 2004 17:49:29 -0400 From: "David P. Kemp" <dpkemp@missi.ncsc.mil> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: Re: clarification proposal -- Re: Current status of CRL validation ? References: <20040323103412.GA23286@cryptolog.com> <004f01c410dc$2c0681d0$df294d0c@hq.orionsec.com> <20040323142525.GA27672@cryptolog.com> <p06020406bc861b0a4627@[128.33.244.157]> <406A0839.14F7C3A1@nma.com> <p06020401bc909a0b8ec1@[128.89.89.75]> <406B0593.FD2E1F6B@nma.com> <p06020408bc90bbc275a7@[128.89.89.75]> <406DE8AD.BC0DA38@nma.com> <p06020411bc9750745da7@[128.89.89.75]> <4071AB84.14898140@nma.com> <p0602041ebc977ad14b67@[128.89.89.75]> <4071DE2E.B5BED74A@nma.com> In-Reply-To: <4071DE2E.B5BED74A@nma.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Ed, While the first paragraph is factually correct, it nonetheless may lead the careless reader to an incorrect conclusion, namely that it is possible for an RP to obtain two *conflicting* answers, rather than merely two different answers. If you ask whether an IP packet can reach its destination through a mesh of routers, the answer may well be that some paths are valid while others are not due to link failures. But as long as at least one path is valid, the destination is reachable. There is no conflict between paths that are up and those that are down. There would be less chance of misinterpretation if your Note were to say: "Since there may be more than one path used to validate the same certificate, it is possible that some paths to that certificate are valid while others are not." As you say, there is an unambiguous validity status for each certificate in every potential path. Validation engines used by RP software can always return an unambiguous answer: * valid if at least one valid path exists, * invalid if no path is valid and all CRLs are available, or * unknown if no path is known valid and at least one CRL for a potentially valid path is unavailable. Dave Ed Gerck wrote: > > > Stephen Kent wrote: > >>Ed, >> >>PKIX is winding down now; we are not taking on any new work items. I >>suspect that anything as basic as what you allude to would be a >>significant departure from what we have done, and thus is not >>appropriate for PKIX to pursue. > > > Steve, > > How about a clarification to be added to the current PKIX documents > that deal with revocation and validation of certs? This would help > the weary reader, who must otherwise wade through this list's archives > in order to find the limitations we have been discussing. For example > (using some of your previous text): > > NOTE: > In X.509/PKIX only the issuer of a certificate can revoke it and there > is only one issuer for a given certificate. Therefore, a certificate > is either revoked or not. However, the ability of a RP to establish > the validity of a certificate is a function of the certificate path > that the RP uses to validate the certificate, and of the access to > revocation status information available to the RP. Since there may be > more than one path used to validate the same certificate, it is possible > to obtain different answers to the question whether a certificate is > valid, depending on which path the RP uses. Also, two RPs may have > access to different revocation status data for the EE certificate or for > a CA certificate along a path, so that each RP may arrive at a different > view of the validity of the EE certificate at any given time. > > Moreover, in X.509/PKIX reliance terms, one may trust the confirmation > procedures of the issuer CA, the issuer CA Designated Responder or any > Trusted Responder during certificate reliance (i.e., whether the > certificate has been revoked or not) under CRLs or OCSPs, but one cannot > rely upon them for other than their value as a representation of the > issuer CA revocation management as expressed in the issuer CA own terms > and rules, usually contained in the CA CPS. > > Comments? > > Cheers, > Ed Gerck > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i36LmVt0083907; Tue, 6 Apr 2004 14:48:31 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i36LmVOA083906; Tue, 6 Apr 2004 14:48:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i36LmVtP083900 for <ietf-pkix@imc.org>; Tue, 6 Apr 2004 14:48:31 -0700 (PDT) (envelope-from chokhani@orionsec.com) Received: from wchokhani3 (dpvc-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i36LmZAt012827 for <ietf-pkix@imc.org>; Tue, 6 Apr 2004 17:48:36 -0400 From: "Santosh Chokhani" <chokhani@orionsec.com> To: <ietf-pkix@imc.org> Subject: RE: clarification proposal -- Re: Current status of CRL validation ? Date: Tue, 6 Apr 2004 17:48:35 -0400 Message-ID: <00ff01c41c20$e9fe60f0$9a00a8c0@hq.orionsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <p06020413bc98a68c8b3f@[128.89.89.75]> Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Steve: Both X.509 and 3280 are very clear in this area. The CA need not issue CRL (ref: introduction in 3280 and paragraph 3 in introduction of Section 5 in 3280 just as a start and there is more). The relying party software can use the indirect CRL issuer information and thus from software viewpoint, certificate issuer may not be involved. >From operations, viewpoint, I gave a simple model where the certificate issuer is not involved. Thus, adding those sentences creates conflict in the standard. Now, to the security issue, I agree that indirect CRL mechanism is not a good idea. It should be a matter of relying party policy. -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stephen Kent Sent: Tuesday, April 06, 2004 3:09 PM To: Santosh Chokhani Cc: ietf-pkix@imc.org Subject: RE: clarification proposal -- Re: Current status of CRL validation ? At 1:56 PM -0400 4/6/04, Santosh Chokhani wrote: >Steve: > >I do not have objection to parts of the first paragraph. But, the >first two sentences of the paragraph are not accurate by most >interpretations. I >quote: > >"In X.509/PKIX only the issuer of a certificate can revoke it and there >is only one issuer for a given certificate. Therefore, a certificate is >either revoked or not." > >Through indirect CRL issuer mechanism (as defined in X.509 and in >3280), an indirect CRL issuer can revoke a certificate with or without >the knowledge of the certificate issuing CA. Since neither standard >provide operations related guidance (lack of this guidance is >appropriate in the case of both the standards), a subscriber can >directly contact indirect CRL issuer and have their certificate placed >on the CRL. Good point. I overlooked that "feature" of the newer CRLs. Of course, I always thought it was a very questionable feature, so maybe I was pre-disposed to overlook it ;-) The problem is not so much that a subscriber could ask someone other than the issuer of his cert to list it on an indirect CRL, but rather that we have no way for an RP to know whether certs listed in this way are appropriately revoked, in the general case. An indirect CRL is not authoritative for the entries that refer to certs issued by other CAs. In that sense I would still argue that only the issuer can revoke the certs that it issues. The use of indirect CRLs is much like using OCSP, in that an RP that is configured to accept revocation status data from a CA issuing an indirect CRL implicitly assumes that the CA is authorized to revoke whatever certs it chooses to list in this fashion. i don't think we would say that any OCSP server can revoke any cert, even though any server can issue a respnse that asserts that any cert is revoked. It's an issue of whether a RP is configured to accept status info from an OCSP server, or in the case of an indirect CRL, to accept indirect (non-authoritative) CRL entries. Steve Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i36LCK2J081746; Tue, 6 Apr 2004 14:12:20 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i36LCKmk081745; Tue, 6 Apr 2004 14:12:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i36LCKx4081736 for <ietf-pkix@imc.org>; Tue, 6 Apr 2004 14:12:20 -0700 (PDT) (envelope-from kent@bbn.com) Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i36LBw7X001152; Tue, 6 Apr 2004 17:12:08 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: <p06020419bc98c58ecfd6@[128.89.89.75]> In-Reply-To: <407210D5.4070404@corestreet.com> References: <B04FB2812116384A87D2968369C086977352A9@exchange.cenzic.com> <407210D5.4070404@corestreet.com> Date: Tue, 6 Apr 2004 17:11:09 -0400 To: David Engberg <dengberg@corestreet.com> From: Stephen Kent <kent@bbn.com> Subject: Re: Signing Untrusted SCVP? Cc: Ambarish Malpani <ambarish@malpani.biz>, ietf-pkix@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> David, <SNIP> >Am I correct that this is the only reason to require mandatory >signatures on DPD responses? no, you are not. You described a class of attacks, but not at all what I hand in mind. an attacker can create a response without intercepting the query. the question is what the client with do with such a response, e.g., how much effort will the client expend before it determines that the response is not appropriate. there are options in SCVP that would make it harder for an attacker to do this, but since these are options, we can't be sure that they would be used. the difficulty in sending a bogus response is also dependent on the transport mechanism employed. HTTP is suggested as the like method, but e-mail is cited as well, and other transports might be used in the future. if an attacker can spoof a DNS response, he can cause the client to connect to him instead of the server, which would enable the bogus server to receive the request as well as generate and send the response, and in the absence of a signed response, the client cannot know that he is not communicating with the intended server. a bogus server could then return bogus cert chains that fail to validate, but which waste client resources. just how effective this may be will be a function of client implementation details, which are outside the scope of our standards. when the client decides (via some unspecified means) that the server is "bad" the client is left not knowing whether the bad response was from the indicated server, or from some bogus server, if we have no signature. what is the client supposed to do? if he elects to locally "hot list" the server, then in a few attempts, the attacker may be able to cause the client to decide that there are no viable servers available to him, i.e., he may give up. he may back off for an unspecified period. (remember the chaos that resulted when VeriSign's CRL services were overwhelmed not long ago? many clients hung for a while, I was told.) The hallmark of a good DoS attack is one in which the attacker emits as few bad packets as possible, and inflicts the greatest denial or degradation of service. use of signatures in responses (and preferably on requests) minimizes opportunities for such attacks. Steve Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i36Jtt4i077188; Tue, 6 Apr 2004 12:55:55 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i36JttOq077187; Tue, 6 Apr 2004 12:55:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i36JtsPL077166 for <ietf-pkix@imc.org>; Tue, 6 Apr 2004 12:55:54 -0700 (PDT) (envelope-from kent@bbn.com) Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i36Jtn7d026798; Tue, 6 Apr 2004 15:55:52 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: <p06020413bc98a68c8b3f@[128.89.89.75]> In-Reply-To: <009f01c41c00$8049e280$9a00a8c0@hq.orionsec.com> References: <009f01c41c00$8049e280$9a00a8c0@hq.orionsec.com> Date: Tue, 6 Apr 2004 15:08:32 -0400 To: "Santosh Chokhani" <chokhani@orionsec.com> From: Stephen Kent <kent@bbn.com> Subject: RE: clarification proposal -- Re: Current status of CRL validation ? Cc: <ietf-pkix@imc.org> Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> At 1:56 PM -0400 4/6/04, Santosh Chokhani wrote: >Steve: > >I do not have objection to parts of the first paragraph. But, the first two >sentences of the paragraph are not accurate by most interpretations. I >quote: > >"In X.509/PKIX only the issuer of a certificate can revoke it and there is >only one issuer for a given certificate. Therefore, a certificate is either >revoked or not." > >Through indirect CRL issuer mechanism (as defined in X.509 and in 3280), an >indirect CRL issuer can revoke a certificate with or without the knowledge >of the certificate issuing CA. Since neither standard provide operations >related guidance (lack of this guidance is appropriate in the case of both >the standards), a subscriber can directly contact indirect CRL issuer and >have their certificate placed on the CRL. Good point. I overlooked that "feature" of the newer CRLs. Of course, I always thought it was a very questionable feature, so maybe I was pre-disposed to overlook it ;-) The problem is not so much that a subscriber could ask someone other than the issuer of his cert to list it on an indirect CRL, but rather that we have no way for an RP to know whether certs listed in this way are appropriately revoked, in the general case. An indirect CRL is not authoritative for the entries that refer to certs issued by other CAs. In that sense I would still argue that only the issuer can revoke the certs that it issues. The use of indirect CRLs is much like using OCSP, in that an RP that is configured to accept revocation status data from a CA issuing an indirect CRL implicitly assumes that the CA is authorized to revoke whatever certs it chooses to list in this fashion. i don't think we would say that any OCSP server can revoke any cert, even though any server can issue a respnse that asserts that any cert is revoked. It's an issue of whether a RP is configured to accept status info from an OCSP server, or in the case of an indirect CRL, to accept indirect (non-authoritative) CRL entries. Steve Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i36JtqQD077180; Tue, 6 Apr 2004 12:55:52 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i36Jtqs2077179; Tue, 6 Apr 2004 12:55:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i36Jtpvi077164 for <ietf-pkix@imc.org>; Tue, 6 Apr 2004 12:55:52 -0700 (PDT) (envelope-from kent@bbn.com) Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i36Jtn7b026798; Tue, 6 Apr 2004 15:55:50 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: <p06020412bc98a5af5793@[128.89.89.75]> In-Reply-To: <4072EABB.D2A50271@nma.com> References: <20040323103412.GA23286@cryptolog.com> <004f01c410dc$2c0681d0$df294d0c@hq.orionsec.com> <20040323142525.GA27672@cryptolog.com> <p06020406bc861b0a4627@[128.33.244.157]> <406A0839.14F7C3A1@nma.com> <p06020401bc909a0b8ec1@[128.89.89.75]> <406B0593.FD2E1F6B@nma.com> <p06020408bc90bbc275a7@[128.89.89.75]> <406DE8AD.BC0DA38@nma.com> <p06020411bc9750745da7@[128.89.89.75]> <4071AB84.14898140@nma.com> <p0602041ebc977ad14b67@[128.89.89.75]> <4071DE2E.B5BED74A@nma.com> <p06020405bc9860671a8f@[128.89.89.75]> <4072EABB.D2A50271@nma.com> Date: Tue, 6 Apr 2004 14:24:30 -0400 To: Ed Gerck <egerck@nma.com> From: Stephen Kent <kent@bbn.com> Subject: Re: clarification proposal -- Re: Current status of CRLvalidation ? Cc: ietf-pkix@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Ed, > > >Agree. I reworded it as: > > To decide whether a certificate has been revoked or not, a RP may > trust the confirmation procedures of the issuer CA, or a proxy > designated by the CA, or any third party that the RP so chooses. > However, the RP cannot rely upon them for other than their value > as a representation of the issuer CA revocation management policy. Getting better. But the last sentence, as best I can make out, just says that the CA or its designees can only tell an RP about the revocation status of a cert as seen by the CA. This seems almost a tautology, and does not shed light on whatever subtle issue is lurking behind the words. Steve Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i36HuWLC067475; Tue, 6 Apr 2004 10:56:32 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i36HuW87067474; Tue, 6 Apr 2004 10:56:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i36HuVhD067468 for <ietf-pkix@imc.org>; Tue, 6 Apr 2004 10:56:31 -0700 (PDT) (envelope-from chokhani@orionsec.com) Received: from wchokhani3 (dpvc-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i36HuYAt027271 for <ietf-pkix@imc.org>; Tue, 6 Apr 2004 13:56:34 -0400 From: "Santosh Chokhani" <chokhani@orionsec.com> To: <ietf-pkix@imc.org> Subject: RE: clarification proposal -- Re: Current status of CRL validation ? Date: Tue, 6 Apr 2004 13:56:34 -0400 Message-ID: <009f01c41c00$8049e280$9a00a8c0@hq.orionsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <p06020405bc9860671a8f@[128.89.89.75]> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i36HuVhD067469 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Steve: I do not have objection to parts of the first paragraph. But, the first two sentences of the paragraph are not accurate by most interpretations. I quote: "In X.509/PKIX only the issuer of a certificate can revoke it and there is only one issuer for a given certificate. Therefore, a certificate is either revoked or not." Through indirect CRL issuer mechanism (as defined in X.509 and in 3280), an indirect CRL issuer can revoke a certificate with or without the knowledge of the certificate issuing CA. Since neither standard provide operations related guidance (lack of this guidance is appropriate in the case of both the standards), a subscriber can directly contact indirect CRL issuer and have their certificate placed on the CRL. -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stephen Kent Sent: Tuesday, April 06, 2004 9:31 AM To: Ed Gerck Cc: ietf-pkix@imc.org Subject: Re: clarification proposal -- Re: Current status of CRL validation ? At 3:31 PM -0700 4/5/04, Ed Gerck wrote: >Stephen Kent wrote: >> Ed, >> >> PKIX is winding down now; we are not taking on any new work items. I >> suspect that anything as basic as what you allude to would be a >> significant departure from what we have done, and thus is not >> appropriate for PKIX to pursue. > >Steve, > >How about a clarification to be added to the current PKIX documents >that deal with revocation and validation of certs? This would help the >weary reader, who must otherwise wade through this list's archives in >order to find the limitations we have been discussing. For example >(using some of your previous text): > >NOTE: > In X.509/PKIX only the issuer of a certificate can revoke it and >there > is only one issuer for a given certificate. Therefore, a certificate > is either revoked or not. However, the ability of a RP to establish > the validity of a certificate is a function of the certificate path > that the RP uses to validate the certificate, and of the access to > revocation status information available to the RP. Since there may be > more than one path used to validate the same certificate, it is possible > to obtain different answers to the question whether a certificate is > valid, depending on which path the RP uses. Also, two RPs may have > access to different revocation status data for the EE certificate or for > a CA certificate along a path, so that each RP may arrive at a different > view of the validity of the EE certificate at any given time. > > Moreover, in X.509/PKIX reliance terms, one may trust the > confirmation procedures of the issuer CA, the issuer CA Designated > Responder or any Trusted Responder during certificate reliance (i.e., > whether the certificate has been revoked or not) under CRLs or OCSPs, > but one cannot rely upon them for other than their value as a > representation of the issuer CA revocation management as expressed in > the issuer CA own terms and rules, usually contained in the CA CPS. > >Comments? > >Cheers, >Ed Gerck We have a suggestion before the WG to issue an update to 3280, so the WG can decide if text of the sort noted above should be part of the update, if we proceed on that work item. With regard to the text above, I like the first paragraph :-), but the second one becomes murky very quickly. The paragraph doesn't convey any meaning to me. It probably doesn't help that the paragraph is one, 6 line sentence, or that it introduces terms such as "CA Designated Responder," "Trusted Responder," ... Steve Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i36Hbr0W066574; Tue, 6 Apr 2004 10:37:53 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i36HbrxH066573; Tue, 6 Apr 2004 10:37:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail9.atl.registeredsite.com (nobody@mail9.atl.registeredsite.com [64.224.219.83]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i36Hbqnu066567 for <ietf-pkix@imc.org>; Tue, 6 Apr 2004 10:37:53 -0700 (PDT) (envelope-from egerck@nma.com) Received: from taurus.hosting4u.net (taurus.hosting4u.net [209.35.191.122]) by mail9.atl.registeredsite.com (8.12.8/8.12.8) with ESMTP id i36HbnKS024871; Tue, 6 Apr 2004 17:37:49 GMT Received: from nma.com ([63.204.17.85]) by taurus.hosting4u.net ; Tue, 06 Apr 2004 12:37:48 -0500 Message-ID: <4072EABB.D2A50271@nma.com> Date: Tue, 06 Apr 2004 10:36:59 -0700 From: Ed Gerck <egerck@nma.com> X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Stephen Kent <kent@bbn.com> CC: ietf-pkix@imc.org Subject: Re: clarification proposal -- Re: Current status of CRLvalidation ? References: <20040323103412.GA23286@cryptolog.com> <004f01c410dc$2c0681d0$df294d0c@hq.orionsec.com> <20040323142525.GA27672@cryptolog.com> <p06020406bc861b0a4627@[128.33.244.157]> <406A0839.14F7C3A1@nma.com> <p06020401bc909a0b8ec1@[128.89.89.75]> <406B0593.FD2E1F6B@nma.com> <p06020408bc90bbc275a7@[128.89.89.75]> <406DE8AD.BC0DA38@nma.com> <p06020411bc9750745da7@[128.89.89.75]> <4071AB84.14898140@nma.com> <p0602041ebc977ad14b67@[128.89.89.75]> <4071DE2E.B5BED74A@nma.com> <p06020405bc9860671a8f@[128.89.89.75]> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Stephen Kent wrote: > > At 3:31 PM -0700 4/5/04, Ed Gerck wrote: > >NOTE: > > In X.509/PKIX only the issuer of a certificate can revoke it and there > > is only one issuer for a given certificate. Therefore, a certificate > > is either revoked or not. However, the ability of a RP to establish > > the validity of a certificate is a function of the certificate path > > that the RP uses to validate the certificate, and of the access to > > revocation status information available to the RP. Since there may be > > more than one path used to validate the same certificate, it is possible > > to obtain different answers to the question whether a certificate is > > valid, depending on which path the RP uses. Also, two RPs may have > > access to different revocation status data for the EE certificate or for > > a CA certificate along a path, so that each RP may arrive at a different > > view of the validity of the EE certificate at any given time. > > > > Moreover, in X.509/PKIX reliance terms, one may trust the confirmation > > procedures of the issuer CA, the issuer CA Designated Responder or any > > Trusted Responder during certificate reliance (i.e., whether the > > certificate has been revoked or not) under CRLs or OCSPs, but one cannot > > rely upon them for other than their value as a representation of the > > issuer CA revocation management as expressed in the issuer CA own terms > > and rules, usually contained in the CA CPS. > > > >Comments? > > > >Cheers, > >Ed Gerck > > We have a suggestion before the WG to issue an update to 3280, so the > WG can decide if text of the sort noted above should be part of the > update, if we proceed on that work item. Sounds like good timing. > With regard to the text above, I like the first paragraph :-), ;-) I improved it a bit. > but > the second one becomes murky very quickly. The paragraph doesn't > convey any meaning to me. > It probably doesn't help that the paragraph is one, 6 line sentence, > or that it introduces terms such as "CA Designated Responder," > "Trusted Responder," ... Agree. I reworded it as: To decide whether a certificate has been revoked or not, a RP may trust the confirmation procedures of the issuer CA, or a proxy designated by the CA, or any third party that the RP so chooses. However, the RP cannot rely upon them for other than their value as a representation of the issuer CA revocation management policy. Cheers, Ed Gerck Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i36FFW9v058628; Tue, 6 Apr 2004 08:15:32 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i36FFWaD058627; Tue, 6 Apr 2004 08:15:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from kraid.nerim.net (smtp-102-tuesday.nerim.net [62.4.16.102]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i36FFVGn058616 for <ietf-pkix@imc.org>; Tue, 6 Apr 2004 08:15:31 -0700 (PDT) (envelope-from julien.stern@cryptolog.com) Received: from jupiter.cry.pto (cryptolog.net1.nerim.net [80.65.224.225]) by kraid.nerim.net (Postfix) with ESMTP id 2636D41A43 for <ietf-pkix@imc.org>; Tue, 6 Apr 2004 17:15:30 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by jupiter.cry.pto (Postfix) with ESMTP id 4FE7240D2 for <ietf-pkix@imc.org>; Tue, 6 Apr 2004 17:15:30 +0200 (CEST) Received: from jupiter.cry.pto ([127.0.0.1]) by localhost (jupiter [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 11001-10 for <ietf-pkix@imc.org>; Tue, 6 Apr 2004 17:15:30 +0200 (CEST) Received: from callisto.cry.pto (callisto.cry.pto [10.0.1.4]) by jupiter.cry.pto (Postfix) with SMTP id 19BC540B1 for <ietf-pkix@imc.org>; Tue, 6 Apr 2004 17:15:30 +0200 (CEST) Received: by callisto.cry.pto (sSMTP sendmail emulation); Tue, 6 Apr 2004 17:15:30 +0200 From: "Julien Stern" <julien.stern@cryptolog.com> Date: Tue, 6 Apr 2004 17:15:30 +0200 To: ietf-pkix@imc.org Subject: Problem with Indirect CRL with DPV/DPD Message-ID: <20040406151529.GA27862@cryptolog.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.5.1+cvs20040105i X-Virus-Scanned: by amavisd-new-20030314-p2 (Debian) at cryptolog.com Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Greetings, I keep on having a major problem with indirect CRLs, and I do not see how they can be used with DPV/DPD (or RFC3126 actually, but this might be out of scope). As a matter of fact, my understanding of RFC3379 (requirements for DPV/DPD) and the draft DPV and DPD over OCSP is that in DPD the client should receive enough information to perform all the validity checks by himself. I can see that this works very well when no indirect CRL is used. However, when an indirect CRL is used, an EXTRA certificate path that should be used to validate the CRL issuer certificate should be provided to the client. And if there is any other indirect CRL in this new path, yet another extra CRL and another extra certificate path should be sent, and so on (recursively). I do not see how this information can be provided through DPD. As a side note, the same problem occurs in RFC3126 where it seems the validation information provided is not enough when indirect CRL are used. All these protocols seem to imply that the same path can be used to validate a certificate and the corresponding CRL, which is not the case. How am I supposed to verify an (indirect) CRL when the only information provided to me is the X500Name of the CRL issuer ? Any clarification would be appreciated. -- Julien Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i36Dowxa052746; Tue, 6 Apr 2004 06:50:58 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i36DowTT052743; Tue, 6 Apr 2004 06:50:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i36Dovxt052734 for <ietf-pkix@imc.org>; Tue, 6 Apr 2004 06:50:57 -0700 (PDT) (envelope-from kent@bbn.com) Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i36Doo7d002699; Tue, 6 Apr 2004 09:50:54 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: <p06020404bc985cf94cad@[128.89.89.75]> In-Reply-To: <40724DEC.3060007@strongauth.com> References: <428a370f.370f428a@noorhome.net> <p06020403bc97150f71da@[128.89.89.75]> <40724DEC.3060007@strongauth.com> Date: Tue, 6 Apr 2004 09:21:28 -0400 To: Arshad Noor <arshad.noor@strongauth.com> From: Stephen Kent <kent@bbn.com> Subject: Re: PKI International Consortium Cc: PKIX list <ietf-pkix@imc.org> Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> At 11:27 PM -0700 4/5/04, Arshad Noor wrote: <SNIP> >>identity theft would likely be a bigger concern if we have fewer certs. >> > I do not believe identity theft will ever be eradicated > regardless of the number of certs. However, if we assume > that identity certs are useful, then there is some optimal > number that balances the risk against the inconvenience of > carrying too many credentials. In the absence of objective > research recommending the precise number, or range, the > identity firewalls concept advances one figure. My comment said nothing about eradicating identity theft. My suggestion is that the IMPACT of an identity theft incident would be worse if there are fewer credentials (e.g., certs) associated with an individual, rather than more. That notion is based on the assumption, stated elsewhere, that when we have more credentials, each has a narrower scope than if we have fewer, and thus the impact of a compromised credential is less severe. There is no reason to believe that there is an optimal number of credentials for an individual, since other factors affecting the ease of identity theft have to do with the procedures used to issue the credentials, and the extent to which secondary for selected credentials are condoned. In fact, secondary uses are a major factor in identity theft, which is often more of a procedural failure than a technical, credential failure. That is also why one ought not assume that use of certs, as a specific form of credential, will eradicate identity theft. Steve Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i36DowTj052752; Tue, 6 Apr 2004 06:50:58 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i36Dowfa052751; Tue, 6 Apr 2004 06:50:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i36DovPH052735 for <ietf-pkix@imc.org>; Tue, 6 Apr 2004 06:50:57 -0700 (PDT) (envelope-from kent@bbn.com) Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i36Doo7f002699; Tue, 6 Apr 2004 09:50:55 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: <p06020405bc9860671a8f@[128.89.89.75]> In-Reply-To: <4071DE2E.B5BED74A@nma.com> References: <20040323103412.GA23286@cryptolog.com> <004f01c410dc$2c0681d0$df294d0c@hq.orionsec.com> <20040323142525.GA27672@cryptolog.com> <p06020406bc861b0a4627@[128.33.244.157]> <406A0839.14F7C3A1@nma.com> <p06020401bc909a0b8ec1@[128.89.89.75]> <406B0593.FD2E1F6B@nma.com> <p06020408bc90bbc275a7@[128.89.89.75]> <406DE8AD.BC0DA38@nma.com> <p06020411bc9750745da7@[128.89.89.75]> <4071AB84.14898140@nma.com> <p0602041ebc977ad14b67@[128.89.89.75]> <4071DE2E.B5BED74A@nma.com> Date: Tue, 6 Apr 2004 09:31:12 -0400 To: Ed Gerck <egerck@nma.com> From: Stephen Kent <kent@bbn.com> Subject: Re: clarification proposal -- Re: Current status of CRL validation ? Cc: ietf-pkix@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> At 3:31 PM -0700 4/5/04, Ed Gerck wrote: >Stephen Kent wrote: >> Ed, >> >> PKIX is winding down now; we are not taking on any new work items. I >> suspect that anything as basic as what you allude to would be a >> significant departure from what we have done, and thus is not >> appropriate for PKIX to pursue. > >Steve, > >How about a clarification to be added to the current PKIX documents >that deal with revocation and validation of certs? This would help >the weary reader, who must otherwise wade through this list's archives >in order to find the limitations we have been discussing. For example >(using some of your previous text): > >NOTE: > In X.509/PKIX only the issuer of a certificate can revoke it and there > is only one issuer for a given certificate. Therefore, a certificate > is either revoked or not. However, the ability of a RP to establish > the validity of a certificate is a function of the certificate path > that the RP uses to validate the certificate, and of the access to > revocation status information available to the RP. Since there may be > more than one path used to validate the same certificate, it is possible > to obtain different answers to the question whether a certificate is > valid, depending on which path the RP uses. Also, two RPs may have > access to different revocation status data for the EE certificate or for > a CA certificate along a path, so that each RP may arrive at a different > view of the validity of the EE certificate at any given time. > > Moreover, in X.509/PKIX reliance terms, one may trust the confirmation > procedures of the issuer CA, the issuer CA Designated Responder or any > Trusted Responder during certificate reliance (i.e., whether the > certificate has been revoked or not) under CRLs or OCSPs, but one cannot > rely upon them for other than their value as a representation of the > issuer CA revocation management as expressed in the issuer CA own terms > and rules, usually contained in the CA CPS. > >Comments? > >Cheers, >Ed Gerck We have a suggestion before the WG to issue an update to 3280, so the WG can decide if text of the sort noted above should be part of the update, if we proceed on that work item. With regard to the text above, I like the first paragraph :-), but the second one becomes murky very quickly. The paragraph doesn't convey any meaning to me. It probably doesn't help that the paragraph is one, 6 line sentence, or that it introduces terms such as "CA Designated Responder," "Trusted Responder," ... Steve Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i366SAjf075730; Mon, 5 Apr 2004 23:28:10 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i366SAAP075728; Mon, 5 Apr 2004 23:28:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from igw (adsl-63-194-79-229.dsl.snfc21.pacbell.net [63.194.79.229]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i366S94U075693 for <ietf-pkix@imc.org>; Mon, 5 Apr 2004 23:28:09 -0700 (PDT) (envelope-from arshad.noor@strongauth.com) Received: from strongauth.com (athena.noorhome.net [192.168.0.10]) by igw.noorhome.net (iPlanet Messaging Server 5.2 Patch 1 (built Aug 19 2002)) with ESMTP id <0HVQ00HBKJV7MF@igw.noorhome.net> for ietf-pkix@imc.org; Mon, 05 Apr 2004 23:11:32 -0700 (PDT) Date: Mon, 05 Apr 2004 23:27:56 -0700 From: Arshad Noor <arshad.noor@strongauth.com> Subject: Re: PKI International Consortium In-reply-to: <p06020403bc97150f71da@[128.89.89.75]> To: Stephen Kent <kent@bbn.com> Cc: PKIX list <ietf-pkix@imc.org> Message-id: <40724DEC.3060007@strongauth.com> Organization: StrongAuth, Inc. MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) References: <428a370f.370f428a@noorhome.net> <p06020403bc97150f71da@[128.89.89.75]> Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Stephen Kent wrote: > two observations: > - the implicit ad for your company in the URL above is inappropriate > for the PKIX list If so, I apologize. This is the only archived copy of the newsletter, and it seemed appropriate to provide the URL to the article rather than repeat the concept. However, I will be more cognizant of that in the future. > - although one might imagine such certs, there are significant > adverse privacy implications (see > http://www.nap.edu/books/0309088968/html/) I will address this after I have had an opportunity to read the book. > > identity theft would likely be a bigger concern if we have fewer certs. > I do not believe identity theft will ever be eradicated regardless of the number of certs. However, if we assume that identity certs are useful, then there is some optimal number that balances the risk against the inconvenience of carrying too many credentials. In the absence of objective research recommending the precise number, or range, the identity firewalls concept advances one figure. > finally, I am concerned that your message seems to be so closely aligned > with you company's products. if you want to continue this discussion, > please do so without making it seem like an ad for your company's > products and services. > The message expressed a concept for how digital certificates can be used to solve some problems in a different way, Steve. No more, no less. Arshad Noor StrongAuth, Inc. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i364PfuU037828; Mon, 5 Apr 2004 21:25:41 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i364PfN1037827; Mon, 5 Apr 2004 21:25:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i364PeAc037821 for <ietf-pkix@imc.org>; Mon, 5 Apr 2004 21:25:40 -0700 (PDT) (envelope-from mmyers@fastq.com) Received: from MMyersLapTop ([65.39.77.135]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id i364Pmw29217 for <ietf-pkix@imc.org>; Mon, 5 Apr 2004 21:25:48 -0700 (MST) (envelope-from mmyers@fastq.com) From: "Michael Myers" <mmyers@fastq.com> To: <ietf-pkix@imc.org> Subject: RE: Signing Untrusted SCVP? Date: Mon, 5 Apr 2004 21:26:31 -0700 Message-ID: <EOEGJNFMMIBDKGFONJJDOEMKDMAA.mmyers@fastq.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <340B5AC242DEF44AAFCD6DC102B51CD3058466A7@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Trevor, That's not how I read the genesis of this thread. As excerpted below, I read Dave asking why in an SCVP context DPD responses MUST be signed. Mike -----Original Message----- From: Trevor Freeman Sent: Monday, April 05, 2004 5:43 PM Hi Michael, I thought the question was scaling given Dave's comments on pre-generation of responses. I seem to remember somewhere else a discussion on pre-canned vs. non-pre-canned responses. Trevor -----Original Message----- From: Michael Myers [mailto:mmyers@fastq.com] Sent: Monday, April 05, 2004 3:34 PM Trevor, Is not the issue at hand whether or not DPD responses MUST be signed? Mike -----Original Message----- From: Dave Engberg Sent: Thursday, April 01, 2004 3:43 PM . . . Given that the spec goes to some lengths to support pure DPD by clients, why is there a requirement (section 3) that every SCVP response be digitally signed? . . . The extra dynamic signature around the entire package is gratuitously expensive overhead . . . . Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i363Ywtf034295; Mon, 5 Apr 2004 20:34:58 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i363Yw0Z034294; Mon, 5 Apr 2004 20:34:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail12.atl.registeredsite.com (nobody@mail12.atl.registeredsite.com [64.224.219.86]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i363Ywoe034286; Mon, 5 Apr 2004 20:34:58 -0700 (PDT) (envelope-from egerck@nma.com) Received: from taurus.hosting4u.net (taurus.hosting4u.net [209.35.191.122]) by mail12.atl.registeredsite.com (8.12.8/8.12.8) with ESMTP id i363Z48E008451; Tue, 6 Apr 2004 03:35:04 GMT Received: from nma.com ([63.204.17.85]) by taurus.hosting4u.net ; Mon, 05 Apr 2004 22:35:03 -0500 Message-ID: <40722544.9666892C@nma.com> Date: Mon, 05 Apr 2004 20:34:28 -0700 From: Ed Gerck <egerck@nma.com> X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Paul Hoffman / IMC <phoffman@imc.org> CC: ietf-pkix@imc.org Subject: Re: clarification proposal -- Re: Current status of CRL validation ? References: <20040323103412.GA23286@cryptolog.com> <004f01c410dc$2c0681d0$df294d0c@hq.orionsec.com> <20040323142525.GA27672@cryptolog.com> <p06020406bc861b0a4627@[128.33.244.157]> <406A0839.14F7C3A1@nma.com> <p06020401bc909a0b8ec1@[128.89.89.75]> <406B0593.FD2E1F6B@nma.com> <p06020408bc90bbc275a7@[128.89.89.75]> <406DE8AD.BC0DA38@nma.com> <p06020411bc9750745da7@[128.89.89.75]> <4071AB84.14898140@nma.com> <p0602041ebc977ad14b67@[128.89.89.75]> <4071DE2E.B5BED74A@nma.com> <p06100443bc97a9b2934f@[172.27.172.24]> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Paul Hoffman / IMC wrote: > > At 3:31 PM -0700 4/5/04, Ed Gerck wrote: > > > >How about a clarification to be added to the current PKIX documents > >that deal with revocation and validation of certs? This would help > >the weary reader, who must otherwise wade through this list's archives > >in order to find the limitations we have been discussing. For example > >(using some of your previous text): > > New work items are decided by the WG, not just one co-chair. You are > asking the WG whether or not we should take up a clarification > document based on just two paragraphs of text. No, I'm based on the recent list traffic Re this subject line. > As Steve said, we're > trying to wind down, so such a generic request is really hard to > support. What is generic about it? It's two paragraphs of text that address head on the question whether a cert is revoked or not, both from the issuer CA point of view as well as from the RP's. > If you are serious about this work item (and I'm not suggesting that > you are), please put together an abstract and a reasonably complete > outline so the WG can see if we want to do it. Thanks! My abstract is my previous posting; the reasonably complete outline is this list's archive with all ~20 messages re "Current status of CRL validation ?" If you are serious about your comment (and I see no reason to suggest you are not), please note that the WG already has in the recent list archive all ~20 messages it needs in order to consider my proposal, including my very succinct suggestion for the clarification. I think that the WG can reasonably expand or rework what I have already presented as my input. I am of course available for a second, third or n-pass. Cheers, Ed Gerck Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3625o3k027941; Mon, 5 Apr 2004 19:05:50 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3625o0Q027940; Mon, 5 Apr 2004 19:05:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3625nCk027934 for <ietf-pkix@imc.org>; Mon, 5 Apr 2004 19:05:49 -0700 (PDT) (envelope-from dengberg@corestreet.com) Received: from localhost (h005008001124.ne.client2.attbi.com[66.31.43.88]) by comcast.net (sccrmhc12) with ESMTP id <20040406020550012002gm93e>; Tue, 6 Apr 2004 02:05:50 +0000 Received: from localhost ([127.0.0.1] helo=corestreet.com ident=dave) by localhost with esmtp (Exim 3.35 #1 (Debian)) id 1BAfzi-00075B-00; Mon, 05 Apr 2004 22:07:18 -0400 Message-ID: <407210D5.4070404@corestreet.com> Date: Mon, 05 Apr 2004 22:07:17 -0400 From: David Engberg <dengberg@corestreet.com> Organization: CoreStreet User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ambarish Malpani <ambarish@malpani.biz> CC: ietf-pkix@imc.org Subject: Re: Signing Untrusted SCVP? References: <B04FB2812116384A87D2968369C086977352A9@exchange.cenzic.com> In-Reply-To: <B04FB2812116384A87D2968369C086977352A9@exchange.cenzic.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Rather than assuming that SCVP DPD signatures must be mandatory and discussing low security ways of implementing them (no HSM, etc.), perhaps it would be useful to discuss what those signatures give you in a pure DPD response. Unless I'm missing something, here's a full description of the only attack that is possible with unsigned pure DPD that is not possible with signed pure DPD: In an environment with multiple SCVP servers in separate network locations, an attacker who can take complete control of the network link close to one of the servers could intercept SCVP requests and then provide syntactically correct (but unsigned) SCVP responses to clients to indicate that the server is unable to find a usable path that meets the client requirements. A client with alternate SCVP server URLs explicitly configured would have to try the other URLs in an unsigned environment to be sure that none of them have a path, whereas in a signed environment, the client could assume from the signature that no path is available without trying the alternate URLs. This would potentially save a few extra HTTP requests for every "no path" response for this hypothetical multi-URL client. Any variation on this scenario renders the signed vs. unsigned equivalent. E.g.: * If the attacker has control of the network closer to the client, or control in front of multiple servers, s/he could DoS all requests to any of the SCVP servers (HTTP 404 errors, etc.). * If the attacker has control of the SCVP server, s/he could issue a signed response with the same "no path" content. * If clients only have one server URL (i.e. only one local server, or all servers are balanced from one host name), then the result is equivalent (unsigned error from attacker, client is stuck). This attack sounds so awkward, and the payoff is so minor, that I really don't see the point of managing and protecting keys at every DPD server just to prevent it. If I were an attacker who wanted to DoS a cert discovery mechanism like Untrusted SCVP or non-SSL LDAP, I could come up with about 20 easier and more fruitful attacks. Am I correct that this is the only reason to require mandatory signatures on DPD responses? Ambarish Malpani wrote: > > Hi Dave, > I don't thing speed of signing is a legitimate concern these > days. If folks want to deploy a DPD server without needing to > worry about key security, they can always use 512 bit software > keys for their RSA operations. > > I can generate over 1000 512 bit RSA signatures on my laptop. I am > sure the other work that the SCVP server will do in path creation > will overwhelm the work done for the signing. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i361JZvN025245; Mon, 5 Apr 2004 18:19:35 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i361JZm2025244; Mon, 5 Apr 2004 18:19:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from ns.malpani.biz (adsl-63-194-89-166.dsl.snfc21.pacbell.net [63.194.89.166]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i361JZkn025225 for <ietf-pkix@imc.org>; Mon, 5 Apr 2004 18:19:35 -0700 (PDT) (envelope-from ambarish@malpani.biz) Received: from ambarisht40 (ns.malpani.biz [192.168.25.5]) by ns.malpani.biz (8.12.9/8.12.9) with ESMTP id i361JF8C010047; Mon, 5 Apr 2004 18:19:16 -0700 From: "Ambarish Malpani" <ambarish@malpani.biz> To: "'Dave Engberg'" <dengberg@corestreet.com>, "'Stephen Kent'" <kent@bbn.com> Cc: <ietf-pkix@imc.org> Subject: RE: Signing Untrusted SCVP? Date: Mon, 5 Apr 2004 18:17:20 -0700 Message-ID: <B04FB2812116384A87D2968369C086977352A9@exchange.cenzic.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <DE909E05406F3340B186DA5A410B05F642A2E6@mongo.corestreet.com> Importance: Normal Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Hi Dave, I don't thing speed of signing is a legitimate concern these days. If folks want to deploy a DPD server without needing to worry about key security, they can always use 512 bit software keys for their RSA operations. I can generate over 1000 512 bit RSA signatures on my laptop. I am sure the other work that the SCVP server will do in path creation will overwhelm the work done for the signing. A > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org > [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Dave Engberg > Sent: Monday, April 05, 2004 1:18 PM > To: Stephen Kent > Cc: ietf-pkix@imc.org > Subject: RE: Signing Untrusted SCVP? > > > > > Stephen - > > Sorry, I wasn't clear enough on pregeneration. In the > current draft, the combination of a mandatory signature (or > MAC) plus the mandatory RequestReference inclusion in every > response means that you can never provide SCVP DPD without > using a protected online key for each transaction. No caching (e.g. > http://www.rfc-editor.org/internet-drafts/draft-deacon-lightwe > ight-ocsp- > profile-00.txt, section 4.2), no pregeneration, no keyless > DPD servers. > > > My preference would be support for keyless DPD through > optional signatures, but pregeneration with a keyless HTTP > caching tier would be an unpleasant second option that would > require that the RequestReference be made optional. Without > at least one of these options, I'm pessimistic about SCVP's > usability for the sort of big (e.g. governmental, > inter-banking) PKIs that my company works with. > > My reference to DPV security is well summarized in section 10 > of the SCVP spec: > > A client that trusts a server's response for validation of a > certificate inherently trusts that server as much as it > would trust > its own validation software. This means that if an attacker > compromises a trusted SCVP server, the attacker can change the > validation processing for every client that relies on that > server. > Thus, an SCVP server must be protected at least as well as the > trust anchors that the SCVP server trusts. > > In a serious PKI, most trust anchors are highly secured > offline roots with armed guards and missile launchers and > whatnot. I'm nervous about trying to secure online DPV > servers "at least as well as" PKI trust anchors, and then > service millions of requests a day from them over public > networks. Server compromise (network or physical) of an > explicitly-trusted DPV server would be a very bad thing until > you catch it and reconfigure every relying client. > > > > -----Original Message----- > From: Stephen Kent [mailto:kent@bbn.com] > Sent: Monday, April 05, 2004 1:58 PM > To: Dave Engberg > Cc: ietf-pkix@imc.org > Subject: RE: Signing Untrusted SCVP? > > At 12:17 PM -0400 4/5/04, Dave Engberg wrote: > > ... > > >I actually have a strong preference > >AGAINST pre-signing (or any kind of signing) for DPD responses, which > >is the opposite of CoreStreet's preferred approach to OCSP. > > I'm surprised by that assertion, given your comment in the > previous message that pre-signed responses were a problem if > we require signed, nonced (pardon the neologism) responses > for DVD. if you are not a fan of pre-signed responses, I > would not have expected you to cite that concern, nor raise > the related issue of the cost of an expensive crypto module. > But, I'll take your word that these arguments, which seem to > be motivated by a preference for pre-signing, are not really > representative of your personal views. > > ... > > >To be less > >circumspect about my motives: I am interested in DPD and DPV, but > >believe that SCVP DPV is a gigantic step backward for PKI security, > > What parts of the rationale in 3379 for DPV do you not > believe are true? > > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i360hEKV022986; Mon, 5 Apr 2004 17:43:14 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i360hE8C022985; Mon, 5 Apr 2004 17:43:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i360hDD7022977 for <ietf-pkix@imc.org>; Mon, 5 Apr 2004 17:43:13 -0700 (PDT) (envelope-from trevorf@windows.microsoft.com) Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Mon, 5 Apr 2004 17:43:15 -0700 Received: from 157.54.5.25 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 05 Apr 2004 17:43:15 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 5 Apr 2004 17:43:06 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 5 Apr 2004 17:43:12 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Mon, 5 Apr 2004 17:43:15 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7195.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Signing Untrusted SCVP? Date: Mon, 5 Apr 2004 17:43:13 -0700 Message-ID: <340B5AC242DEF44AAFCD6DC102B51CD3058466A7@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Signing Untrusted SCVP? thread-index: AcQbXf61N1dnMs9BQPalBOEbCaS6VgAEaJew From: "Trevor Freeman" <trevorf@windows.microsoft.com> To: "Michael Myers" <mmyers@fastq.com>, "Dave Engberg" <dengberg@corestreet.com>, "Stephen Kent" <kent@bbn.com> Cc: <ietf-pkix@imc.org> X-OriginalArrivalTime: 06 Apr 2004 00:43:15.0063 (UTC) FILETIME=[25613070:01C41B70] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i360hDD7022980 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Hi Michael, I thought the question was scaling given Dave's comments on pre-generation of responses. I seem to remember somewhere else a discussion on pre-canned vs. non-pre-canned responses. Trevor -----Original Message----- From: Michael Myers [mailto:mmyers@fastq.com] Sent: Monday, April 05, 2004 3:34 PM To: Trevor Freeman; Dave Engberg; Stephen Kent Cc: ietf-pkix@imc.org Subject: RE: Signing Untrusted SCVP? Trevor, Is not the issue at hand whether not DPD responses MUST be signed? Mike -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org]On Behalf Of Trevor Freeman Sent: Monday, April 05, 2004 2:44 PM To: Dave Engberg; Stephen Kent Cc: ietf-pkix@imc.org Subject: RE: Signing Untrusted SCVP? So Dave, if we supported the ability for the client to specify if it wanted a fresh response vs. would accept a pre caned response - would that address you concern? Trevor -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Dave Engberg Sent: Monday, April 05, 2004 1:18 PM To: Stephen Kent Cc: ietf-pkix@imc.org Subject: RE: Signing Untrusted SCVP? Stephen - Sorry, I wasn't clear enough on pregeneration. In the current draft, the combination of a mandatory signature (or MAC) plus the mandatory RequestReference inclusion in every response means that you can never provide SCVP DPD without using a protected online key for each transaction. No caching (e.g. http://www.rfc-editor.org/internet-drafts/draft-deacon-lightweig ht-ocsp- profile-00.txt, section 4.2), no pregeneration, no keyless DPD servers. My preference would be support for keyless DPD through optional signatures, but pregeneration with a keyless HTTP caching tier would be an unpleasant second option that would require that the RequestReference be made optional. Without at least one of these options, I'm pessimistic about SCVP's usability for the sort of big (e.g. governmental, inter-banking) PKIs that my company works with. My reference to DPV security is well summarized in section 10 of the SCVP spec: A client that trusts a server's response for validation of a certificate inherently trusts that server as much as it would trust its own validation software. This means that if an attacker compromises a trusted SCVP server, the attacker can change the validation processing for every client that relies on that server. Thus, an SCVP server must be protected at least as well as the trust anchors that the SCVP server trusts. In a serious PKI, most trust anchors are highly secured offline roots with armed guards and missile launchers and whatnot. I'm nervous about trying to secure online DPV servers "at least as well as" PKI trust anchors, and then service millions of requests a day from them over public networks. Server compromise (network or physical) of an explicitly-trusted DPV server would be a very bad thing until you catch it and reconfigure every relying client. -----Original Message----- From: Stephen Kent [mailto:kent@bbn.com] Sent: Monday, April 05, 2004 1:58 PM To: Dave Engberg Cc: ietf-pkix@imc.org Subject: RE: Signing Untrusted SCVP? At 12:17 PM -0400 4/5/04, Dave Engberg wrote: ... >I actually have a strong preference >AGAINST pre-signing (or any kind of signing) for DPD responses, which >is the opposite of CoreStreet's preferred approach to OCSP. I'm surprised by that assertion, given your comment in the previous message that pre-signed responses were a problem if we require signed, nonced (pardon the neologism) responses for DVD. if you are not a fan of pre-signed responses, I would not have expected you to cite that concern, nor raise the related issue of the cost of an expensive crypto module. But, I'll take your word that these arguments, which seem to be motivated by a preference for pre-signing, are not really representative of your personal views. ... >To be less >circumspect about my motives: I am interested in DPD and DPV, but >believe that SCVP DPV is a gigantic step backward for PKI security, What parts of the rationale in 3379 for DPV do you not believe are true? Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i35NU4md017977; Mon, 5 Apr 2004 16:30:04 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i35NU4fJ017976; Mon, 5 Apr 2004 16:30:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from [172.27.172.24] (p168.n-dcpop06.stsn.com [63.240.221.168]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.8) with ESMTP id i35NU2Z8017970 for <ietf-pkix@imc.org>; Mon, 5 Apr 2004 16:30:03 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: <p06100443bc97a9b2934f@[172.27.172.24]> In-Reply-To: <4071DE2E.B5BED74A@nma.com> References: <20040323103412.GA23286@cryptolog.com> <004f01c410dc$2c0681d0$df294d0c@hq.orionsec.com> <20040323142525.GA27672@cryptolog.com> <p06020406bc861b0a4627@[128.33.244.157]> <406A0839.14F7C3A1@nma.com> <p06020401bc909a0b8ec1@[128.89.89.75]> <406B0593.FD2E1F6B@nma.com> <p06020408bc90bbc275a7@[128.89.89.75]> <406DE8AD.BC0DA38@nma.com> <p06020411bc9750745da7@[128.89.89.75]> <4071AB84.14898140@nma.com> <p0602041ebc977ad14b67@[128.89.89.75]> <4071DE2E.B5BED74A@nma.com> Date: Mon, 5 Apr 2004 19:30:10 -0500 To: ietf-pkix@imc.org From: Paul Hoffman / IMC <phoffman@imc.org> Subject: Re: clarification proposal -- Re: Current status of CRL validation ? Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> At 3:31 PM -0700 4/5/04, Ed Gerck wrote: > >How about a clarification to be added to the current PKIX documents >that deal with revocation and validation of certs? This would help >the weary reader, who must otherwise wade through this list's archives >in order to find the limitations we have been discussing. For example >(using some of your previous text): New work items are decided by the WG, not just one co-chair. You are asking the WG whether or not we should take up a clarification document based on just two paragraphs of text. As Steve said, we're trying to wind down, so such a generic request is really hard to support. If you are serious about this work item (and I'm not suggesting that you are), please put together an abstract and a reasonably complete outline so the WG can see if we want to do it. Thanks! --Paul Hoffman, Director --Internet Mail Consortium Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i35MklZn014709; Mon, 5 Apr 2004 15:46:47 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i35MklQ1014708; Mon, 5 Apr 2004 15:46:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i35Mkkjs014700 for <ietf-pkix@imc.org>; Mon, 5 Apr 2004 15:46:46 -0700 (PDT) (envelope-from dengberg@corestreet.com) Received: from localhost (h005008001124.ne.client2.attbi.com[66.31.43.88]) by comcast.net (sccrmhc12) with ESMTP id <20040405224646012002n0i6e>; Mon, 5 Apr 2004 22:46:46 +0000 Received: from localhost ([127.0.0.1] helo=corestreet.com ident=dave) by localhost with esmtp (Exim 3.35 #1 (Debian)) id 1BAct5-0006yA-00; Mon, 05 Apr 2004 18:48:15 -0400 Message-ID: <4071E22E.2010704@corestreet.com> Date: Mon, 05 Apr 2004 18:48:14 -0400 From: David Engberg <dengberg@corestreet.com> Organization: CoreStreet User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Trevor Freeman <trevorf@windows.microsoft.com> CC: ietf-pkix@imc.org Subject: Re: Signing Untrusted SCVP? References: <340B5AC242DEF44AAFCD6DC102B51CD30584636F@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <340B5AC242DEF44AAFCD6DC102B51CD30584636F@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Trevor Freeman wrote: > So Dave, if we supported the ability for the client to specify if it > wanted a fresh response vs. would accept a pre caned response - would > that address you concern? That would be my second choice. When a client asks an untrusted SCVP DPD server, "Please give me a path between certs A and E that satisfy constraints X," my first choice would be that the client could say "I don't need a signed response because I don't explicitly trust you." The untrusted server would be able to provide a response ("B, C, and D") with an empty Set of SignerInfo. The DPD server would not need to have any protected keys, in the same way that an LDAP directory fulfilling the same task would not be required to support SSL. It lets a mature PKI use DPD without having to add yet another set of protected keys or new certificate profiles, etc. My second choice would be what you describe. I wouldn't continue to call this "untrusted" SCVP ... it's more like "semi-trusted." In this mode, a client would indicate that it doesn't require a RequestReference (or a nonce), and a local keyless cache server could provide a cached or pregenerated response ("B, C, and D") which was previously signed. Thanks Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i35MX48N013341; Mon, 5 Apr 2004 15:33:04 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i35MX4GQ013340; Mon, 5 Apr 2004 15:33:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i35MX4DW013334 for <ietf-pkix@imc.org>; Mon, 5 Apr 2004 15:33:04 -0700 (PDT) (envelope-from mmyers@fastq.com) Received: from MMyersLapTop ([65.39.77.135]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id i35MX0w93996; Mon, 5 Apr 2004 15:33:01 -0700 (MST) (envelope-from mmyers@fastq.com) From: "Michael Myers" <mmyers@fastq.com> To: "Trevor Freeman" <trevorf@windows.microsoft.com>, "Dave Engberg" <dengberg@corestreet.com>, "Stephen Kent" <kent@bbn.com> Cc: <ietf-pkix@imc.org> Subject: RE: Signing Untrusted SCVP? Date: Mon, 5 Apr 2004 15:33:42 -0700 Message-ID: <EOEGJNFMMIBDKGFONJJDOEMIDMAA.mmyers@fastq.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <340B5AC242DEF44AAFCD6DC102B51CD30584636F@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> Importance: Normal Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Trevor, Is not the issue at hand whether not DPD responses MUST be signed? Mike -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org]On Behalf Of Trevor Freeman Sent: Monday, April 05, 2004 2:44 PM To: Dave Engberg; Stephen Kent Cc: ietf-pkix@imc.org Subject: RE: Signing Untrusted SCVP? So Dave, if we supported the ability for the client to specify if it wanted a fresh response vs. would accept a pre caned response - would that address you concern? Trevor -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Dave Engberg Sent: Monday, April 05, 2004 1:18 PM To: Stephen Kent Cc: ietf-pkix@imc.org Subject: RE: Signing Untrusted SCVP? Stephen - Sorry, I wasn't clear enough on pregeneration. In the current draft, the combination of a mandatory signature (or MAC) plus the mandatory RequestReference inclusion in every response means that you can never provide SCVP DPD without using a protected online key for each transaction. No caching (e.g. http://www.rfc-editor.org/internet-drafts/draft-deacon-lightweig ht-ocsp- profile-00.txt, section 4.2), no pregeneration, no keyless DPD servers. My preference would be support for keyless DPD through optional signatures, but pregeneration with a keyless HTTP caching tier would be an unpleasant second option that would require that the RequestReference be made optional. Without at least one of these options, I'm pessimistic about SCVP's usability for the sort of big (e.g. governmental, inter-banking) PKIs that my company works with. My reference to DPV security is well summarized in section 10 of the SCVP spec: A client that trusts a server's response for validation of a certificate inherently trusts that server as much as it would trust its own validation software. This means that if an attacker compromises a trusted SCVP server, the attacker can change the validation processing for every client that relies on that server. Thus, an SCVP server must be protected at least as well as the trust anchors that the SCVP server trusts. In a serious PKI, most trust anchors are highly secured offline roots with armed guards and missile launchers and whatnot. I'm nervous about trying to secure online DPV servers "at least as well as" PKI trust anchors, and then service millions of requests a day from them over public networks. Server compromise (network or physical) of an explicitly-trusted DPV server would be a very bad thing until you catch it and reconfigure every relying client. -----Original Message----- From: Stephen Kent [mailto:kent@bbn.com] Sent: Monday, April 05, 2004 1:58 PM To: Dave Engberg Cc: ietf-pkix@imc.org Subject: RE: Signing Untrusted SCVP? At 12:17 PM -0400 4/5/04, Dave Engberg wrote: ... >I actually have a strong preference >AGAINST pre-signing (or any kind of signing) for DPD responses, which >is the opposite of CoreStreet's preferred approach to OCSP. I'm surprised by that assertion, given your comment in the previous message that pre-signed responses were a problem if we require signed, nonced (pardon the neologism) responses for DVD. if you are not a fan of pre-signed responses, I would not have expected you to cite that concern, nor raise the related issue of the cost of an expensive crypto module. But, I'll take your word that these arguments, which seem to be motivated by a preference for pre-signing, are not really representative of your personal views. ... >To be less >circumspect about my motives: I am interested in DPD and DPV, but >believe that SCVP DPV is a gigantic step backward for PKI security, What parts of the rationale in 3379 for DPV do you not believe are true? Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i35MVwEt013296; Mon, 5 Apr 2004 15:32:03 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i35MVwRp013295; Mon, 5 Apr 2004 15:31:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail9.atl.registeredsite.com (nobody@mail9.atl.registeredsite.com [64.224.219.83]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i35MVjwv013279 for <ietf-pkix@imc.org>; Mon, 5 Apr 2004 15:31:58 -0700 (PDT) (envelope-from egerck@nma.com) Received: from taurus.hosting4u.net (taurus.hosting4u.net [209.35.191.122]) by mail9.atl.registeredsite.com (8.12.8/8.12.8) with ESMTP id i35MVhKS000497; Mon, 5 Apr 2004 22:31:43 GMT Received: from nma.com ([63.204.17.85]) by taurus.hosting4u.net ; Mon, 05 Apr 2004 17:31:42 -0500 Message-ID: <4071DE2E.B5BED74A@nma.com> Date: Mon, 05 Apr 2004 15:31:10 -0700 From: Ed Gerck <egerck@nma.com> X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Stephen Kent <kent@bbn.com> CC: ietf-pkix@imc.org Subject: clarification proposal -- Re: Current status of CRL validation ? References: <20040323103412.GA23286@cryptolog.com> <004f01c410dc$2c0681d0$df294d0c@hq.orionsec.com> <20040323142525.GA27672@cryptolog.com> <p06020406bc861b0a4627@[128.33.244.157]> <406A0839.14F7C3A1@nma.com> <p06020401bc909a0b8ec1@[128.89.89.75]> <406B0593.FD2E1F6B@nma.com> <p06020408bc90bbc275a7@[128.89.89.75]> <406DE8AD.BC0DA38@nma.com> <p06020411bc9750745da7@[128.89.89.75]> <4071AB84.14898140@nma.com> <p0602041ebc977ad14b67@[128.89.89.75]> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Stephen Kent wrote: > Ed, > > PKIX is winding down now; we are not taking on any new work items. I > suspect that anything as basic as what you allude to would be a > significant departure from what we have done, and thus is not > appropriate for PKIX to pursue. Steve, How about a clarification to be added to the current PKIX documents that deal with revocation and validation of certs? This would help the weary reader, who must otherwise wade through this list's archives in order to find the limitations we have been discussing. For example (using some of your previous text): NOTE: In X.509/PKIX only the issuer of a certificate can revoke it and there is only one issuer for a given certificate. Therefore, a certificate is either revoked or not. However, the ability of a RP to establish the validity of a certificate is a function of the certificate path that the RP uses to validate the certificate, and of the access to revocation status information available to the RP. Since there may be more than one path used to validate the same certificate, it is possible to obtain different answers to the question whether a certificate is valid, depending on which path the RP uses. Also, two RPs may have access to different revocation status data for the EE certificate or for a CA certificate along a path, so that each RP may arrive at a different view of the validity of the EE certificate at any given time. Moreover, in X.509/PKIX reliance terms, one may trust the confirmation procedures of the issuer CA, the issuer CA Designated Responder or any Trusted Responder during certificate reliance (i.e., whether the certificate has been revoked or not) under CRLs or OCSPs, but one cannot rely upon them for other than their value as a representation of the issuer CA revocation management as expressed in the issuer CA own terms and rules, usually contained in the CA CPS. Comments? Cheers, Ed Gerck Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i35LhZcW010348; Mon, 5 Apr 2004 14:43:35 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i35LhZbH010347; Mon, 5 Apr 2004 14:43:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i35LhY6b010341 for <ietf-pkix@imc.org>; Mon, 5 Apr 2004 14:43:34 -0700 (PDT) (envelope-from trevorf@windows.microsoft.com) Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 5 Apr 2004 14:43:34 -0700 Received: from 157.54.5.25 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 05 Apr 2004 14:43:34 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 5 Apr 2004 14:43:28 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Mon, 5 Apr 2004 14:43:11 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Mon, 5 Apr 2004 14:43:34 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7195.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Signing Untrusted SCVP? Date: Mon, 5 Apr 2004 14:43:30 -0700 Message-ID: <340B5AC242DEF44AAFCD6DC102B51CD30584636F@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Signing Untrusted SCVP? thread-index: AcQbOPbngWulJYAzTAiApI9hN7k7/gADcwPgAAQE+FA= From: "Trevor Freeman" <trevorf@windows.microsoft.com> To: "Dave Engberg" <dengberg@corestreet.com>, "Stephen Kent" <kent@bbn.com> Cc: <ietf-pkix@imc.org> X-OriginalArrivalTime: 05 Apr 2004 21:43:34.0789 (UTC) FILETIME=[0BD5EB50:01C41B57] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i35LhY6b010342 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> So Dave, if we supported the ability for the client to specify if it wanted a fresh response vs. would accept a pre caned response - would that address you concern? Trevor -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Dave Engberg Sent: Monday, April 05, 2004 1:18 PM To: Stephen Kent Cc: ietf-pkix@imc.org Subject: RE: Signing Untrusted SCVP? Stephen - Sorry, I wasn't clear enough on pregeneration. In the current draft, the combination of a mandatory signature (or MAC) plus the mandatory RequestReference inclusion in every response means that you can never provide SCVP DPD without using a protected online key for each transaction. No caching (e.g. http://www.rfc-editor.org/internet-drafts/draft-deacon-lightweight-ocsp- profile-00.txt, section 4.2), no pregeneration, no keyless DPD servers. My preference would be support for keyless DPD through optional signatures, but pregeneration with a keyless HTTP caching tier would be an unpleasant second option that would require that the RequestReference be made optional. Without at least one of these options, I'm pessimistic about SCVP's usability for the sort of big (e.g. governmental, inter-banking) PKIs that my company works with. My reference to DPV security is well summarized in section 10 of the SCVP spec: A client that trusts a server's response for validation of a certificate inherently trusts that server as much as it would trust its own validation software. This means that if an attacker compromises a trusted SCVP server, the attacker can change the validation processing for every client that relies on that server. Thus, an SCVP server must be protected at least as well as the trust anchors that the SCVP server trusts. In a serious PKI, most trust anchors are highly secured offline roots with armed guards and missile launchers and whatnot. I'm nervous about trying to secure online DPV servers "at least as well as" PKI trust anchors, and then service millions of requests a day from them over public networks. Server compromise (network or physical) of an explicitly-trusted DPV server would be a very bad thing until you catch it and reconfigure every relying client. -----Original Message----- From: Stephen Kent [mailto:kent@bbn.com] Sent: Monday, April 05, 2004 1:58 PM To: Dave Engberg Cc: ietf-pkix@imc.org Subject: RE: Signing Untrusted SCVP? At 12:17 PM -0400 4/5/04, Dave Engberg wrote: ... >I actually have a strong preference >AGAINST pre-signing (or any kind of signing) for DPD responses, which >is the opposite of CoreStreet's preferred approach to OCSP. I'm surprised by that assertion, given your comment in the previous message that pre-signed responses were a problem if we require signed, nonced (pardon the neologism) responses for DVD. if you are not a fan of pre-signed responses, I would not have expected you to cite that concern, nor raise the related issue of the cost of an expensive crypto module. But, I'll take your word that these arguments, which seem to be motivated by a preference for pre-signing, are not really representative of your personal views. ... >To be less >circumspect about my motives: I am interested in DPD and DPV, but >believe that SCVP DPV is a gigantic step backward for PKI security, What parts of the rationale in 3379 for DPV do you not believe are true? Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i35LEvsV008736; Mon, 5 Apr 2004 14:14:57 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i35LEv4S008735; Mon, 5 Apr 2004 14:14:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i35LEuas008729 for <ietf-pkix@imc.org>; Mon, 5 Apr 2004 14:14:56 -0700 (PDT) (envelope-from kent@bbn.com) Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i35LEu7X003951; Mon, 5 Apr 2004 17:14:56 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: <p0602041ebc977ad14b67@[128.89.89.75]> In-Reply-To: <4071AB84.14898140@nma.com> References: <20040323103412.GA23286@cryptolog.com> <004f01c410dc$2c0681d0$df294d0c@hq.orionsec.com> <20040323142525.GA27672@cryptolog.com> <p06020406bc861b0a4627@[128.33.244.157]> <406A0839.14F7C3A1@nma.com> <p06020401bc909a0b8ec1@[128.89.89.75]> <406B0593.FD2E1F6B@nma.com> <p06020408bc90bbc275a7@[128.89.89.75]> <406DE8AD.BC0DA38@nma.com> <p06020411bc9750745da7@[128.89.89.75]> <4071AB84.14898140@nma.com> Date: Mon, 5 Apr 2004 17:14:07 -0400 To: Ed Gerck <egerck@nma.com> From: Stephen Kent <kent@bbn.com> Subject: Re: Current status of CRL validation ? Cc: ietf-pkix@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> >Stephen Kent wrote: >> >> Ed, >> >> I'd like to respond to each of your points, but experience has shown >> that we never manage to get closure in these exchanges. >> >> Since you are convinced that X.509 and PKIX standards do not address >> the real problems that a certification system should address, and >> since this list is devoted to PKIX standards development, let's just >> stop now and save everyone's time. > >Steve, > >Let me clarify. Nothing that I wrote is a critique of X.509 or >PKIX. I use X.509/PKIX everyday. I'm simply stating that there is >a problem with certificate validation in X.509/PKIX. The problem >is very basic, as I outlined. I think it's incumbent upon the PKIX >WG, sooner or later, to address the need for a better revocation >mechanism. > >BTW, there is no closure possible ;-) I'd like keep this old >grudge until it's solved. > >Cheers, >Ed Gerck > >PS: Private mail is also fine if you want to exchange tentative ideas >on this. Ed, PKIX is winding down now; we are not taking on any new work items. I suspect that anything as basic as what you allude to would be a significant departure from what we have done, and thus is not appropriate for PKIX to pursue. Stev Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i35L2kYE007908; Mon, 5 Apr 2004 14:02:46 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i35L2kwg007907; Mon, 5 Apr 2004 14:02:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i35L2kKP007900 for <ietf-pkix@imc.org>; Mon, 5 Apr 2004 14:02:46 -0700 (PDT) (envelope-from kent@bbn.com) Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i35L2T7b003366; Mon, 5 Apr 2004 17:02:33 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: <p0602041dbc9772e36faf@[128.89.89.75]> In-Reply-To: <DE909E05406F3340B186DA5A410B05F642A2E6@mongo.corestreet.com> References: <DE909E05406F3340B186DA5A410B05F642A2E6@mongo.corestreet.com> Date: Mon, 5 Apr 2004 17:00:50 -0400 To: "Dave Engberg" <dengberg@corestreet.com> From: Stephen Kent <kent@bbn.com> Subject: RE: Signing Untrusted SCVP? Cc: <ietf-pkix@imc.org> Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> At 4:18 PM -0400 4/5/04, Dave Engberg wrote: >Stephen - > >Sorry, I wasn't clear enough on pregeneration. In the current draft, >the combination of a mandatory signature (or MAC) plus the mandatory >RequestReference inclusion in every response means that you can never >provide SCVP DPD without using a protected online key for each >transaction. No caching (e.g. >http://www.rfc-editor.org/internet-drafts/draft-deacon-lightweight-ocsp- >profile-00.txt, section 4.2), no pregeneration, no keyless DPD servers. There is a difference between pre-generated OCSP responses and reliance on a lower level security protocol to provide integrity for queries and responses. But, you are right that the latter still requires a key in the server to authenticate it to clients. >My preference would be support for keyless DPD through optional >signatures, but pregeneration with a keyless HTTP caching tier would be >an unpleasant second option that would require that the RequestReference >be made optional. Without at least one of these options, I'm >pessimistic about SCVP's usability for the sort of big (e.g. >governmental, inter-banking) PKIs that my company works with. I'm not sure I have a preference, not having though about it in as much detail. >My reference to DPV security is well summarized in section 10 of the >SCVP spec: > > A client that trusts a server's response for validation of a > certificate inherently trusts that server as much as it would trust > its own validation software. This means that if an attacker > compromises a trusted SCVP server, the attacker can change the > validation processing for every client that relies on that server. > Thus, an SCVP server must be protected at least as well as the > trust anchors that the SCVP server trusts. > >In a serious PKI, most trust anchors are highly secured offline roots >with armed guards and missile launchers and whatnot. I'm nervous about >trying to secure online DPV servers "at least as well as" PKI trust >anchors, and then service millions of requests a day from them over >public networks. Server compromise (network or physical) of an >explicitly-trusted DPV server would be a very bad thing until you catch >it and reconfigure every relying client. > first, the argument about well protected trust anchors is not only a bit hyperbolic, but it is also backwards, since a TA is defined as a public key and associated parameters, not a private key. Anyway, we should be more precise in analyzing the two approaches. for example, the private keys that are maintained offline and are very well protected, are not used except as a compromise recovery mechanism. the keys can't be both offline and used for day to day issuance of certs and CRLs. rather the common mode of use entails a second tier of CAs that are used daily, and thus are not offline. these keys should be well protected and that's where the expensive FIPS-evaluated (gee, I hope you get better than level 2 for $20K, we used to sell our level 3 device for less than that!) crypto module comes into play. for cert & CRL signing the centralization of the CA function does not pose a problem, so one need not spend a lot on high quality crypto modules, since they are not being widely distributed. the problem arose when we adopted OCSP, because now there was a notion of an online server that had a much higher transaction rate, and the compromise of the private key was almost as bad as compromise of the key used to sign CRLs (not certs). it is not literally as bad, because if one has a small population of users that access a given OCSP server, then the number of folks affected by a compromise of that one sever is correspondingly small. On the other hand, that local server is the authoritative revocation status source for ALL CAs, for its client population, so the impact of a local compromise is different. But how bnad is it to deal with a compromise of an OCSP server's key? One might have a set of OCSP servers whose certs are issued by an offline CA, and the CRL for this set is issued by the same CA. then if there is a compromise of a server's key, one can revoke the server's cert, issue a new one, and notify clients via a CRL. that CRL, if limited to just OCSP servers, should not grow too big and thus its distribution and caching is not onerous. this hybrid scheme would help mitigate the risks associated with having keys in OCSP servers. The residual problem for live responses is performance, not security. Still, I think we agree that DPV, like OCSP, is most appropriate for enterprise customers, not as a public service. the impact of compromise is less severe and ability to recover from compromise is better when the scope is limited. one has to balance the ability of an enterprise security admin to configuration manage lots of workstations and servers, vs. the ability to secure a few DPV servers. we have a lot of experience that suggests the configuration management task is hard and that admins usually fail. firewalls are attractive because they allow admins to focus efforts on a few, centrally managed resources that the admins control. there is a lesson here. Steve Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i35KMdSd005178; Mon, 5 Apr 2004 13:22:39 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i35KMdmi005177; Mon, 5 Apr 2004 13:22:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i35KMcPV005159 for <ietf-pkix@imc.org>; Mon, 5 Apr 2004 13:22:38 -0700 (PDT) (envelope-from trevorf@windows.microsoft.com) Received: from mail6.microsoft.com ([157.54.6.196]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 5 Apr 2004 13:21:43 -0700 Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Mon, 5 Apr 2004 13:22:21 -0700 Received: from 157.54.8.23 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 05 Apr 2004 13:22:37 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 5 Apr 2004 13:21:50 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 5 Apr 2004 13:23:38 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Mon, 5 Apr 2004 13:22:37 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7195.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Signing Untrusted SCVP? Date: Mon, 5 Apr 2004 13:22:34 -0700 Message-ID: <340B5AC242DEF44AAFCD6DC102B51CD3057C075F@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Signing Untrusted SCVP? thread-index: AcQY+9PjHSPkaf/0QsudW+srer5kuwABUDWAAIszI8AAAIrr0AAGzwMg From: "Trevor Freeman" <trevorf@windows.microsoft.com> To: "Dave Engberg" <dengberg@corestreet.com> Cc: <ietf-pkix@imc.org> X-OriginalArrivalTime: 05 Apr 2004 20:22:37.0415 (UTC) FILETIME=[BC9D7770:01C41B4B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i35KMcPV005172 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Dave, The private key protection is a question of assurance which is an implementation and deployment issue. A large % of the world continues to function with FIPS- level 1 crypto since that level of assurance meets their needs. Trevor -----Original Message----- From: Dave Engberg [mailto:dengberg@corestreet.com] Sent: Monday, April 05, 2004 10:08 AM To: Trevor Freeman Cc: ietf-pkix@imc.org Subject: RE: Signing Untrusted SCVP? The issue isn't performance, it's security. If the private/secret keys that you are using matter, then a real-world PKI will need to protect them with an appropriate FIPS Level 2+ token. This limits where you can deploy the servers, who can manage it, per-server cost, and overall solution scalability. If the keys don't matter, than the signature/MAC shouldn't be mandatory. -----Original Message----- From: Trevor Freeman [mailto:trevorf@windows.microsoft.com] Sent: Monday, April 05, 2004 12:56 PM To: Dave Engberg; Stephen Kent Cc: ietf-pkix@imc.org Subject: RE: Signing Untrusted SCVP? Hi Dave, I don't see the need for the option you suggest. Give today system performance there is no need to add HSMs to do PK signatures. We also don't mandate that the response be PK signed since we also support HMAC reposes which are very trivial to generate. Trevor Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i35KJ8Td004938; Mon, 5 Apr 2004 13:19:08 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i35KJ8Wa004937; Mon, 5 Apr 2004 13:19:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mongo.corestreet.com (mongo.corestreet.com [68.162.232.130]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i35KJ7Ak004894 for <ietf-pkix@imc.org>; Mon, 5 Apr 2004 13:19:08 -0700 (PDT) (envelope-from dengberg@corestreet.com) X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message Subject: RE: Signing Untrusted SCVP? MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 5 Apr 2004 16:18:18 -0400 Message-ID: <DE909E05406F3340B186DA5A410B05F642A2E6@mongo.corestreet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Signing Untrusted SCVP? Thread-Index: AcQbOPbngWulJYAzTAiApI9hN7k7/gADcwPg From: "Dave Engberg" <dengberg@corestreet.com> To: "Stephen Kent" <kent@bbn.com> Cc: <ietf-pkix@imc.org> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i35KJ8Ak004929 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Stephen - Sorry, I wasn't clear enough on pregeneration. In the current draft, the combination of a mandatory signature (or MAC) plus the mandatory RequestReference inclusion in every response means that you can never provide SCVP DPD without using a protected online key for each transaction. No caching (e.g. http://www.rfc-editor.org/internet-drafts/draft-deacon-lightweight-ocsp- profile-00.txt, section 4.2), no pregeneration, no keyless DPD servers. My preference would be support for keyless DPD through optional signatures, but pregeneration with a keyless HTTP caching tier would be an unpleasant second option that would require that the RequestReference be made optional. Without at least one of these options, I'm pessimistic about SCVP's usability for the sort of big (e.g. governmental, inter-banking) PKIs that my company works with. My reference to DPV security is well summarized in section 10 of the SCVP spec: A client that trusts a server's response for validation of a certificate inherently trusts that server as much as it would trust its own validation software. This means that if an attacker compromises a trusted SCVP server, the attacker can change the validation processing for every client that relies on that server. Thus, an SCVP server must be protected at least as well as the trust anchors that the SCVP server trusts. In a serious PKI, most trust anchors are highly secured offline roots with armed guards and missile launchers and whatnot. I'm nervous about trying to secure online DPV servers "at least as well as" PKI trust anchors, and then service millions of requests a day from them over public networks. Server compromise (network or physical) of an explicitly-trusted DPV server would be a very bad thing until you catch it and reconfigure every relying client. -----Original Message----- From: Stephen Kent [mailto:kent@bbn.com] Sent: Monday, April 05, 2004 1:58 PM To: Dave Engberg Cc: ietf-pkix@imc.org Subject: RE: Signing Untrusted SCVP? At 12:17 PM -0400 4/5/04, Dave Engberg wrote: ... >I actually have a strong preference >AGAINST pre-signing (or any kind of signing) for DPD responses, which >is the opposite of CoreStreet's preferred approach to OCSP. I'm surprised by that assertion, given your comment in the previous message that pre-signed responses were a problem if we require signed, nonced (pardon the neologism) responses for DVD. if you are not a fan of pre-signed responses, I would not have expected you to cite that concern, nor raise the related issue of the cost of an expensive crypto module. But, I'll take your word that these arguments, which seem to be motivated by a preference for pre-signing, are not really representative of your personal views. ... >To be less >circumspect about my motives: I am interested in DPD and DPV, but >believe that SCVP DPV is a gigantic step backward for PKI security, What parts of the rationale in 3379 for DPV do you not believe are true? Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i35ItXj7000366; Mon, 5 Apr 2004 11:55:33 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i35ItXQ4000365; Mon, 5 Apr 2004 11:55:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail2.atl.registeredsite.com (nobody@mail2.atl.registeredsite.com [64.224.219.76]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i35ItXdl000356 for <ietf-pkix@imc.org>; Mon, 5 Apr 2004 11:55:33 -0700 (PDT) (envelope-from egerck@nma.com) Received: from taurus.hosting4u.net (taurus.hosting4u.net [209.35.191.122]) by mail2.atl.registeredsite.com (8.12.8/8.12.8) with ESMTP id i35ItUV1026266; Mon, 5 Apr 2004 18:55:31 GMT Received: from nma.com ([63.204.17.85]) by taurus.hosting4u.net ; Mon, 05 Apr 2004 13:55:29 -0500 Message-ID: <4071AB84.14898140@nma.com> Date: Mon, 05 Apr 2004 11:55:00 -0700 From: Ed Gerck <egerck@nma.com> X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Stephen Kent <kent@bbn.com> CC: ietf-pkix@imc.org Subject: Re: Current status of CRL validation ? References: <20040323103412.GA23286@cryptolog.com> <004f01c410dc$2c0681d0$df294d0c@hq.orionsec.com> <20040323142525.GA27672@cryptolog.com> <p06020406bc861b0a4627@[128.33.244.157]> <406A0839.14F7C3A1@nma.com> <p06020401bc909a0b8ec1@[128.89.89.75]> <406B0593.FD2E1F6B@nma.com> <p06020408bc90bbc275a7@[128.89.89.75]> <406DE8AD.BC0DA38@nma.com> <p06020411bc9750745da7@[128.89.89.75]> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Stephen Kent wrote: > > Ed, > > I'd like to respond to each of your points, but experience has shown > that we never manage to get closure in these exchanges. > > Since you are convinced that X.509 and PKIX standards do not address > the real problems that a certification system should address, and > since this list is devoted to PKIX standards development, let's just > stop now and save everyone's time. Steve, Let me clarify. Nothing that I wrote is a critique of X.509 or PKIX. I use X.509/PKIX everyday. I'm simply stating that there is a problem with certificate validation in X.509/PKIX. The problem is very basic, as I outlined. I think it's incumbent upon the PKIX WG, sooner or later, to address the need for a better revocation mechanism. BTW, there is no closure possible ;-) I'd like keep this old grudge until it's solved. Cheers, Ed Gerck PS: Private mail is also fine if you want to exchange tentative ideas on this. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i35I94CM096869; Mon, 5 Apr 2004 11:09:04 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i35I94o6096868; Mon, 5 Apr 2004 11:09:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i35I93Cb096842 for <ietf-pkix@imc.org>; Mon, 5 Apr 2004 11:09:03 -0700 (PDT) (envelope-from kent@bbn.com) Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i35I8t7X023928; Mon, 5 Apr 2004 14:08:55 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: <p0602040fbc9749b5c8c1@[128.89.89.75]> In-Reply-To: <DE909E05406F3340B186DA5A410B05F642A2B8@mongo.corestreet.com> References: <DE909E05406F3340B186DA5A410B05F642A2B8@mongo.corestreet.com> Date: Mon, 5 Apr 2004 13:57:46 -0400 To: "Dave Engberg" <dengberg@corestreet.com> From: Stephen Kent <kent@bbn.com> Subject: RE: Signing Untrusted SCVP? Cc: <ietf-pkix@imc.org> Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> At 12:17 PM -0400 4/5/04, Dave Engberg wrote: >Stephen - > >I assume that the "From" address in my email message makes it pretty >up-front what company I work for. yes, but I don't assume an employee necessarily agrees with all of his/her employer's technical positions, and IETF policy argues that one ought not make such assumptions. >I actually have a strong preference >AGAINST pre-signing (or any kind of signing) for DPD responses, which is >the opposite of CoreStreet's preferred approach to OCSP. I'm surprised by that assertion, given your comment in the previous message that pre-signed responses were a problem if we require signed, nonced (pardon the neologism) responses for DVD. if you are not a fan of pre-signed responses, I would not have expected you to cite that concern, nor raise the related issue of the cost of an expensive crypto module. But, I'll take your word that these arguments, which seem to be motivated by a preference for pre-signing, are not really representative of your personal views. >To be less >circumspect about my motives: I am interested in DPD and DPV, but >believe that SCVP DPV is a gigantic step backward for PKI security, What parts of the rationale in 3379 for DPV do you not believe are true? >and >want to figure out whether SCVP DPD can be tweaked to support large >(multi-million-user) environments with hundreds of DPD servers around >the world on public networks. If so, CoreStreet may consider product >development in this area, probably without a pregeneration approach. > >Anyhoo ... my preference is your second option. Allow SCVP servers to >be deployed by environments that only use DPD, without requiring that >those servers protect any private keys "just in case". This is the same >as allowing some CAs to distribute CRLs only via LDAP or HTTP >directories that don't implement SSL. This avoids "over PKIing" the >SCVP DPD protocol just to slightly mitigate one minor and baroque type >of DoS. Well, at least we agree on a resolution to the issue. Steve Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i35I91Nh096861; Mon, 5 Apr 2004 11:09:01 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i35I91L7096860; Mon, 5 Apr 2004 11:09:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i35I90Ji096830 for <ietf-pkix@imc.org>; Mon, 5 Apr 2004 11:09:00 -0700 (PDT) (envelope-from kent@bbn.com) Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i35I8t7b023928; Mon, 5 Apr 2004 14:08:59 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: <p06020411bc9750745da7@[128.89.89.75]> In-Reply-To: <406DE8AD.BC0DA38@nma.com> References: <20040323103412.GA23286@cryptolog.com> <004f01c410dc$2c0681d0$df294d0c@hq.orionsec.com> <20040323142525.GA27672@cryptolog.com> <p06020406bc861b0a4627@[128.33.244.157]> <406A0839.14F7C3A1@nma.com> <p06020401bc909a0b8ec1@[128.89.89.75]> <406B0593.FD2E1F6B@nma.com> <p06020408bc90bbc275a7@[128.89.89.75]> <406DE8AD.BC0DA38@nma.com> Date: Mon, 5 Apr 2004 14:08:05 -0400 To: Ed Gerck <egerck@nma.com> From: Stephen Kent <kent@bbn.com> Subject: Re: Current status of CRL validation ? Cc: ietf-pkix@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Ed, I'd like to respond to each of your points, but experience has shown that we never manage to get closure in these exchanges. Since you are convinced that X.509 and PKIX standards do not address the real problems that a certification system should address, and since this list is devoted to PKIX standards development, let's just stop now and save everyone's time. Steve Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i35I900Y096852; Mon, 5 Apr 2004 11:09:00 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i35I90Iv096851; Mon, 5 Apr 2004 11:09:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i35I8xs7096829 for <ietf-pkix@imc.org>; Mon, 5 Apr 2004 11:08:59 -0700 (PDT) (envelope-from kent@bbn.com) Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i35I8t7Z023928; Mon, 5 Apr 2004 14:08:57 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: <p06020410bc974f8a26e6@[128.89.89.75]> In-Reply-To: <20040403040323.M36717@orionsec.com> References: <DE909E05406F3340B186DA5A410B05F642A286@mongo.corestreet.com> <20040403040323.M36717@orionsec.com> Date: Mon, 5 Apr 2004 14:04:21 -0400 To: "Santosh Chokhani" <chokhani@orionsec.com> From: Stephen Kent <kent@bbn.com> Subject: RE: Signing Untrusted SCVP? Cc: <ietf-pkix@imc.org> Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> At 12:03 AM -0400 4/3/04, Santosh Chokhani wrote: >Steve: > >I do not see a particular reason to require a DPD Server to be held to a >higher standard then a Directory Server. We do not require signed responses >from Directories. Both being stationary servers, are equally prone to >hacking. Also, in order to verify the DPD Server signature, the client may >get into another problem of obtaining a path for the DPD Server itself, which >may not be a circular problem, but will degrade performance We are not the LDAP WG, so we don't make requirements for directory access, as I noted in my previous message. (Our last foray into that area is a superceded RFC that had mixed feelings about DoS issues.) I thought there was a clear need to configure clients with an ability to directly verify signatures for DPD and DPV servers. Otherwsie, as you note, a circular dependency can arise. Steve Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i35Hh3H6094806; Mon, 5 Apr 2004 10:43:03 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i35Hh3f0094805; Mon, 5 Apr 2004 10:43:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i35Hh1ar094797 for <ietf-pkix@imc.org>; Mon, 5 Apr 2004 10:43:02 -0700 (PDT) (envelope-from Peter.Sylvester@edelweb.fr) Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id i35Hh4N28243 for <ietf-pkix@imc.org>; Mon, 5 Apr 2004 19:43:04 +0200 (MEST) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Mon, 5 Apr 2004 19:43:04 +0200 (MET DST) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i35Hh4615077 for ietf-pkix@imc.org; Mon, 5 Apr 2004 19:43:04 +0200 (MEST) Date: Mon, 5 Apr 2004 19:43:04 +0200 (MEST) From: Peter Sylvester <Peter.Sylvester@edelweb.fr> Message-Id: <200404051743.i35Hh4615077@chandon.edelweb.fr> To: ietf-pkix@imc.org Subject: RE: Signing Untrusted SCVP? X-Sun-Charset: US-ASCII Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> > > Hi Dave, > I don't see the need for the option you suggest. Give today system > performance there is no need to add HSMs to do PK signatures. We also > don't mandate that the response be PK signed since we also support HMAC > reposes which are very trivial to generate. > Trevor The current text seems unclear to me concerning the interoperability between clients and servers. What if a client can only support authenticated data and the server can only support signeddata. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i35H8gVh092703; Mon, 5 Apr 2004 10:08:42 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i35H8gKK092702; Mon, 5 Apr 2004 10:08:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mongo.corestreet.com (mongo.corestreet.com [68.162.232.130]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i35H8gSV092685 for <ietf-pkix@imc.org>; Mon, 5 Apr 2004 10:08:42 -0700 (PDT) (envelope-from dengberg@corestreet.com) X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message Subject: RE: Signing Untrusted SCVP? MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 5 Apr 2004 13:07:51 -0400 Message-ID: <DE909E05406F3340B186DA5A410B05F642A2C0@mongo.corestreet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Signing Untrusted SCVP? Thread-Index: AcQY+9PjHSPkaf/0QsudW+srer5kuwABUDWAAIszI8AAAIrr0A== From: "Dave Engberg" <dengberg@corestreet.com> To: "Trevor Freeman" <trevorf@windows.microsoft.com> Cc: <ietf-pkix@imc.org> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i35H8gSV092697 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> The issue isn't performance, it's security. If the private/secret keys that you are using matter, then a real-world PKI will need to protect them with an appropriate FIPS Level 2+ token. This limits where you can deploy the servers, who can manage it, per-server cost, and overall solution scalability. If the keys don't matter, than the signature/MAC shouldn't be mandatory. -----Original Message----- From: Trevor Freeman [mailto:trevorf@windows.microsoft.com] Sent: Monday, April 05, 2004 12:56 PM To: Dave Engberg; Stephen Kent Cc: ietf-pkix@imc.org Subject: RE: Signing Untrusted SCVP? Hi Dave, I don't see the need for the option you suggest. Give today system performance there is no need to add HSMs to do PK signatures. We also don't mandate that the response be PK signed since we also support HMAC reposes which are very trivial to generate. Trevor Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i35Gu2cq091851; Mon, 5 Apr 2004 09:56:02 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i35Gu28e091850; Mon, 5 Apr 2004 09:56:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i35Gu1F1091841 for <ietf-pkix@imc.org>; Mon, 5 Apr 2004 09:56:01 -0700 (PDT) (envelope-from trevorf@windows.microsoft.com) Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 5 Apr 2004 09:55:57 -0700 Received: from 157.54.8.155 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 05 Apr 2004 09:56:02 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 5 Apr 2004 09:55:06 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 5 Apr 2004 09:56:33 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Mon, 5 Apr 2004 09:56:04 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7195.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Signing Untrusted SCVP? Date: Mon, 5 Apr 2004 09:55:55 -0700 Message-ID: <340B5AC242DEF44AAFCD6DC102B51CD3057C0322@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Signing Untrusted SCVP? thread-index: AcQY+9PjHSPkaf/0QsudW+srer5kuwABUDWAAIszI8A= From: "Trevor Freeman" <trevorf@windows.microsoft.com> To: "Dave Engberg" <dengberg@corestreet.com>, "Stephen Kent" <kent@bbn.com> Cc: <ietf-pkix@imc.org> X-OriginalArrivalTime: 05 Apr 2004 16:56:04.0542 (UTC) FILETIME=[E1E31DE0:01C41B2E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i35Gu1F1091844 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Hi Dave, I don't see the need for the option you suggest. Give today system performance there is no need to add HSMs to do PK signatures. We also don't mandate that the response be PK signed since we also support HMAC reposes which are very trivial to generate. Trevor -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Dave Engberg Sent: Friday, April 02, 2004 2:33 PM To: Stephen Kent Cc: ietf-pkix@imc.org Subject: RE: Signing Untrusted SCVP? An attacker with the ability to intercept your SCVP calls and send back spoofed responses has a more obvious way to deny service ... More seriously, I think we agree that there should absolutely be an option in the protocol to allow a client to request a signed response, and for the server to provide it. But by making this an absolute hard requirement for every client-server pair, you are permanently preventing the SCVP protocol from being used with any caching or pregeneration at the server level when used for pure DPD, and you're adding 150 bytes and 50 ms onto every response (plus $20k for a FIPS HSM, if you're serious). Think of pure DPD as an optimized mechanism for doing certificate lookups, as an alternative to LDAP. Previously, PKI standards have not forced every LDAP lookup to use authenticated SSL tunnels, because most clients derive their security from the signatures on the retrieved objects rather than the transport mechanism. The gratuitous requirement for SSL on every LDAP query would just further reduce performance and increase costs for PKI deployments. -----Original Message----- From: Stephen Kent [mailto:kent@bbn.com] Sent: Friday, April 02, 2004 4:45 PM To: Dave Engberg Cc: ietf-pkix@imc.org Subject: Re: Signing Untrusted SCVP? Dave, I agree that one might not want to invest as much effort and money in securing a DPD server as a DPV server. But that does not necessarily translate into removing the need for signatures on responses from such servers. If responses from a DPD server are spoofed, a client may be subject to a form of DoS attack, as it tries to make use of bogus certs formed chains intended to maximize the amount of crypto processing the client does, before realizing that the chain is bad. Or certs might be returned that conflict with certs from some other DPD server. Without signed responses it could be very hard to determine what went wrong and what servers ought to be avoided, based on bad behavior. Steve Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i35GIAMn088664; Mon, 5 Apr 2004 09:18:10 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i35GIA5V088663; Mon, 5 Apr 2004 09:18:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mongo.corestreet.com (mongo.corestreet.com [68.162.232.130]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i35GI9BB088655 for <ietf-pkix@imc.org>; Mon, 5 Apr 2004 09:18:09 -0700 (PDT) (envelope-from dengberg@corestreet.com) X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message Subject: RE: Signing Untrusted SCVP? MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 5 Apr 2004 12:17:18 -0400 Message-ID: <DE909E05406F3340B186DA5A410B05F642A2B8@mongo.corestreet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Signing Untrusted SCVP? Thread-Index: AcQbJIE15cmWUqr3TNy42+gBRbhaZgAAa4rg From: "Dave Engberg" <dengberg@corestreet.com> To: "Stephen Kent" <kent@bbn.com> Cc: <ietf-pkix@imc.org> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i35GI9BB088658 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Stephen - I assume that the "From" address in my email message makes it pretty up-front what company I work for. I actually have a strong preference AGAINST pre-signing (or any kind of signing) for DPD responses, which is the opposite of CoreStreet's preferred approach to OCSP. To be less circumspect about my motives: I am interested in DPD and DPV, but believe that SCVP DPV is a gigantic step backward for PKI security, and want to figure out whether SCVP DPD can be tweaked to support large (multi-million-user) environments with hundreds of DPD servers around the world on public networks. If so, CoreStreet may consider product development in this area, probably without a pregeneration approach. Anyhoo ... my preference is your second option. Allow SCVP servers to be deployed by environments that only use DPD, without requiring that those servers protect any private keys "just in case". This is the same as allowing some CAs to distribute CRLs only via LDAP or HTTP directories that don't implement SSL. This avoids "over PKIing" the SCVP DPD protocol just to slightly mitigate one minor and baroque type of DoS. -----Original Message----- From: Stephen Kent [mailto:kent@bbn.com] Sent: Monday, April 05, 2004 11:41 AM To: Dave Engberg Cc: ietf-pkix@imc.org Subject: RE: Signing Untrusted SCVP? ... - the pre-generation issue is what I bet is your major concern, consistent with you company's model for OCSP, and your should have been more up front about that in your first message ... RFC 3379 (2002) established requirements for DPD and said that authenticated requests and responses MAY be required. So, that RFC does not mandate integrity and authenticity for these exchanges, and it explicitly allows for use of lower layer mechanisms to provide these services. So, we could mandate that DPD servers support signed requests and responses, and allow local users and admins to choose whether to invoke the feature, or we make it an optional aspect of implementations. I do worry that the latter approach will result in depriving clients of the option, due to the sort of marketplace pressures that became evident in our discussion of pre-generated OCSP responses. Steve Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i35Fgd1f086288; Mon, 5 Apr 2004 08:42:39 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i35Fgd5q086286; Mon, 5 Apr 2004 08:42:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i35Fgc7h086259 for <ietf-pkix@imc.org>; Mon, 5 Apr 2004 08:42:38 -0700 (PDT) (envelope-from kent@bbn.com) Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i35FfY7p015027; Mon, 5 Apr 2004 11:42:35 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: <p06020409bc971c4f250f@[128.89.89.75]> In-Reply-To: <002801c41a52$6db40010$0500a8c0@arport> References: <OF169CF168.3D170BCC-ON85256E6A.0078DDD6@chase.com> <002801c41a52$6db40010$0500a8c0@arport> Date: Mon, 5 Apr 2004 11:15:43 -0400 To: "Anders Rundgren" <anders.rundgren@telia.com> From: Stephen Kent <kent@bbn.com> Subject: Re: Single Identity. Was: PKI International Consortium Cc: "PKIX list" <ietf-pkix@imc.org>, <Shaheen.Nasirudheen@chase.com>, "Arshad Noor" <arshad.noor@strongauth.com>, <amg@lcc.uma.es>, "Terwilliger, Ann" <aterwil@visa.com>, "Eric Norman" <ejnorman@doit.wisc.edu> Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> At 4:37 PM +0200 4/4/04, Anders Rundgren wrote: >Dear PKIers, >I could not resist this one as I have worked with this idea since >1997.... > >The quest for a single identity >--------------------------------- >Assume that an international consortium of banks indeed agreed >on a common certificate issuance policy of a relatively high level >(as well as shelving the four-corner model), I believe you would >have a very good foundation for a universal single-identity scheme. >It is worth noting that a single identity is a reality in Sweden since >around 1960 so this is a time-proven scheme as well. As Al notes, different cultures have different operating models. What may work for Sweden may not work elsewhere. >A tricky real-life use-case >----------------------------- >Now assume that you one day lose your wallet [1] with ID- >certificates when you are on an oversea trip. Who will have >the swift and secure way back? The individual with a handful >of locally issued credentials, or the individual who have a >single credential issued by a member of a trusted network of >international issuers having branch offices in every town of >any size worth mentioning? As Al pointed out, reality is much different from your model. A real advantage to having multiple credentials for different purposes is that you can use the alternatives that were not lost/stolen. Also, in the U.S. some folks subscribe to a service that will notify affected credential issuers when you lose credentials, and that eases the burden if multiple credentials are lost at the same time. >Most security folks only look to revocation issues but it is >really at least as critical to get replacement credentials as you >in an anticipated "e-society" will be completely handicapped >without getting access to your work, bank, e-government etc. When I needed to have my wife's Amex card replaced a few years ago, not because we lost it but because of fraudulent use, we had a new one in less than 48 hours. That is not the sort of service I would expect from my government ;-) BTW, given your notion of a "trusted network of International issuers" I guess Amex would qualify, but I doubt that my Amex card will be accepted by immigration folks at either end of my return trip. I'll need to contact my embassy or consulate for that sort of assistance. > >TTPs rule - Like it or not >----------------------------- >Some people object to the TTP idea but the reality is that >all issuances not based on DNA or similar "body-based- >authentication", already fully depend on TTP-issued >passports, driver licenses, gas bills (!) etc. nonsense. an organization that is authoritative for the credentials it issues is NOT like the TTPs you cite, which are authoritative for nothing, but which are good at collecting fees. I won't bother addressing the rest of your message; Al did a good job of noting the issues I would have commented upon. Steve Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i35Fgcfs086279; Mon, 5 Apr 2004 08:42:38 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i35FgcvV086278; Mon, 5 Apr 2004 08:42:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i35Fgb5w086257 for <ietf-pkix@imc.org>; Mon, 5 Apr 2004 08:42:37 -0700 (PDT) (envelope-from kent@bbn.com) Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i35FfY7n015027; Mon, 5 Apr 2004 11:42:34 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: <p06020408bc971bd307d4@[128.89.89.75]> In-Reply-To: <Pine.A41.4.44.0404031406040.18426-100000@holstein.doit.wisc.edu> References: <Pine.A41.4.44.0404031406040.18426-100000@holstein.doit.wisc.edu> Date: Mon, 5 Apr 2004 10:22:31 -0400 To: Eric Norman <ejnorman@doit.wisc.edu> From: Stephen Kent <kent@bbn.com> Subject: Re: PKI International Consortium Cc: PKIX list <ietf-pkix@imc.org> Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> At 2:35 PM -0600 4/3/04, Eric Norman wrote: >On Sat, 3 Apr 2004 amg@lcc.uma.es wrote: > >> The newest version of X.509 provides a more suitable solution because it >> clearly defines a framework where identity and attribute certificates, >> although related, can be independently managed. That recommendation defines >> new types of authorities, Attribute Authorities (AA), for the assignment of >> privileges. It also defines the Source of Authority (SOA) as the ultimate >> authority to assign a set of privileges. Additionally, it provides a >> foundation to build a Privilege Management Infrastructure (PMI) >>that contain a >> multiplicity of AAs, SOAs and final users. >> >> So, summarizing, if the idea is to have "context-sensitive identities", >> then "Attribute Certificates" linked to a single "Identity Certificate" are >> the best solution. > >If a relying party needs to know that I possess certain attributes, and >if I can present an "Attribute Certificate" that convinces them that I >do indeed possess those attributes, then what purpose is served by also >having me present an "Identity Certificate"? Eric, recall that an attribute cert does not contain a public key, so presentation of an attribute cert does not provide a secure association between the presenter and the cert. Steve Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i35FgbFg086271; Mon, 5 Apr 2004 08:42:37 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i35Fgbnb086270; Mon, 5 Apr 2004 08:42:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i35FgaRJ086256 for <ietf-pkix@imc.org>; Mon, 5 Apr 2004 08:42:37 -0700 (PDT) (envelope-from kent@bbn.com) Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i35FfY7f015027; Mon, 5 Apr 2004 11:42:24 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: <p06020404bc9715b197d1@[128.89.89.75]> In-Reply-To: <DE909E05406F3340B186DA5A410B05F642A286@mongo.corestreet.com> References: <DE909E05406F3340B186DA5A410B05F642A286@mongo.corestreet.com> Date: Mon, 5 Apr 2004 11:40:44 -0400 To: "Dave Engberg" <dengberg@corestreet.com> From: Stephen Kent <kent@bbn.com> Subject: RE: Signing Untrusted SCVP? Cc: <ietf-pkix@imc.org> Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> At 5:32 PM -0500 4/2/04, Dave Engberg wrote: >An attacker with the ability to intercept your SCVP calls and send back >spoofed responses has a more obvious way to deny service ... remember, the example I gave has the property that it burns cycles on the client computer, irrespective of consuming network bandwidth. also, since you mention pre-generated responses below (a favorite technical strategy for your company, if I recall), then there would be no basis for a challenge response scheme. thus whether the adversary has to intercept you request or not is not at all clear. >More seriously, I think we agree that there should absolutely be an >option in the protocol to allow a client to request a signed response, >and for the server to provide it. But by making this an absolute hard >requirement for every client-server pair, you are permanently preventing >the SCVP protocol from being used with any caching or pregeneration at >the server level when used for pure DPD, and you're adding 150 bytes and >50 ms onto every response (plus $20k for a FIPS HSM, if you're serious). - the pre-generation issue is what I bet is your major concern, consistent with you company's model for OCSP, and your should have been more up front about that in your first message - given the size of the certs being returned, often multiple certs, it is hard to get excited about the bandwidth devoted to carrying a signature - you keep mentioning the costs of a FIPS evaluated HSM, which is a red herring, since PKIX makes NO statements about the level of assurance for the crypto implementations required for any of our standards. >Think of pure DPD as an optimized mechanism for doing certificate >lookups, as an alternative to LDAP. Previously, PKI standards have not >forced every LDAP lookup to use authenticated SSL tunnels, because most >clients derive their security from the signatures on the retrieved >objects rather than the transport mechanism. The gratuitous requirement >for SSL on every LDAP query would just further reduce performance and >increase costs for PKI deployments. this is a better line of argument. The old PKIX document on this topic was RFC 2559 (from 1999). It was replaced by an RFC that is NOT a PKIX document, and thus does not necessarily represent a PKIX view of what is or is not appropriate in this context. 2559 said that additional integrity services were not required for LDAP responses, although it did call for SSL use for CA access to an LDAP server, to prevent denial of service attacks that could result if CRLs or certs were replaced with bogus replicas. So, that RFC acknowledges that if a client gets only bogus certs (because the LDAP entries are corrupted) we have a DoS problem, yet if did not require integrity on retrieval of certs and CRLs from the LDAP server. We seemed to have been of two minds here :-) RFC 3379 (2002) established requirements for DPD and said that authenticated requests and responses MAY be required. So, that RFC does not mandate integrity and authenticity for these exchanges, and it explicitly allows for use of lower layer mechanisms to provide these services. So, we could mandate that DPD servers support signed requests and responses, and allow local users and admins to choose whether to invoke the feature, or we make it an optional aspect of implementations. I do worry that the latter approach will result in depriving clients of the option, due to the sort of marketplace pressures that became evident in our discussion of pre-generated OCSP responses. Steve Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i35FgTG0086251; Mon, 5 Apr 2004 08:42:29 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i35FgTQa086250; Mon, 5 Apr 2004 08:42:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i35FgSD7086230 for <ietf-pkix@imc.org>; Mon, 5 Apr 2004 08:42:28 -0700 (PDT) (envelope-from kent@bbn.com) Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i35FfY7l015027; Mon, 5 Apr 2004 11:42:26 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: <p06020407bc971b00d66b@[128.89.89.75]> In-Reply-To: <200404031056.MAA21125@sol10.lcc.uma.es> References: <200404031056.MAA21125@sol10.lcc.uma.es> Date: Mon, 5 Apr 2004 11:15:59 -0400 To: amg@lcc.uma.es From: Stephen Kent <kent@bbn.com> Subject: Re: PKI International Consortium Cc: Arshad Noor <arshad.noor@strongauth.com>, PKIX list <ietf-pkix@imc.org> Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> At 12:57 PM +0100 4/3/04, amg@lcc.uma.es wrote: >Hi all, > >In line with Arshad's comments, I think there's some kind of misunderstanding >in this discussion. It seems that we're confusing Identity and Attributes (or >privileges). It is reasonable to think that one entity (anything that can have >a certificate) should have only one Identity (and therefore, only one Identity >Certificate). There are reasons that may justify having more than one >Identity, and I will come to that later, but let's assume for now that only >one Identity is enough. See the recent National Research Council report: "Who Goes there? Authentication Through the Lens of Privacy" for a detailed discussion of why there is not really ONE identity for an individual, in the sense that we're discussing here. Steve Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i35FgS16086242; Mon, 5 Apr 2004 08:42:28 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i35FgSmn086241; Mon, 5 Apr 2004 08:42:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i35FgRWw086229 for <ietf-pkix@imc.org>; Mon, 5 Apr 2004 08:42:27 -0700 (PDT) (envelope-from kent@bbn.com) Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i35FfY7h015027; Mon, 5 Apr 2004 11:42:25 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: <p06020405bc97173af3ee@[128.89.89.75]> In-Reply-To: <OF169CF168.3D170BCC-ON85256E6A.0078DDD6@chase.com> References: <OF169CF168.3D170BCC-ON85256E6A.0078DDD6@chase.com> Date: Mon, 5 Apr 2004 11:12:32 -0400 To: Shaheen.Nasirudheen@chase.com From: Stephen Kent <kent@bbn.com> Subject: Re: PKI International Consortium Cc: PKIX list <ietf-pkix@imc.org>, Arshad Noor <arshad.noor@strongauth.com>, "Anders Rundgren" <anders.rundgren@telia.com> Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> At 5:37 PM -0500 4/2/04, Shaheen.Nasirudheen@chase.com wrote: >Hello everyone, > >Quote from bbn.com : "In 1968, the Advanced Research Projects Agency (ARPA) >sent out a Request for Quotation (RFQ) to build a network of four Interface >Message Processors (IMPs). Many of the large computer and >telecommunications organizations didn't even respond--they thought it was >impossible. " - http://bbn.com/arpanet/index.html. > >If the pioneers believed that "Internet" is impossible, then I dont think >we would enjoy sending these emails today. As the Chief Scientist for Information Security here at BBN, I don't think the analogy is at all relevant to our current discussion. >Anyway, consider the following: > >1. A central authority issues and maintains certificates for the customers >of FI. The central authority prescribes a set of standards and regulations >on creation, issuance and maintenance of the certificate. >2. The FI or independent agents may issue the certificate on behalf of the >central authority. However, the certificate issued to the customer should >not have any direct relation to the FI (Financial Institution). >3. The customer may subscribe for the services of an FI, identifying >himself producing the certificate issued by the central authority. >4. All verification of the certificate should be verified referring to the >central authority. >5. The customer has to produce the certificate to the FI whenever he/she >would like to do a transaction. The FI may check for subscription of the >customer and verify the credentials referring to the central authority. > >Of course, the availability, integrity and confidentiality of the system >has to be considered for an ideal process such as above. However, with >right technology and prevention mechanism in place, I believe such a system >may be possible. Think about an "International Passport" with which you can >travel to any country. However, your passport require an entry visa >(subscription) to the destination country. This way I avoid travelling >with multiple passport (for person with multiple citizenship). You miss the point, and your analogy is seriously flawed. Most folks have only one passport; unless you hold dual citizenship you generally don't get another passport. Visas are sometime required to admission to a country, in conjunction with a passport. In that sense, they are a lot like attribute certs used with identity certs. A passport is the appropriate credential for identifying you as a citizen of a specified country, but that's all it does. The name info on it is not unique, and the unique ID (the passport number) is not of use to most relying parties. Try using your passport to make a purchase, instead of using a credit card and see how well this universal ID works. Conversely, try giving your credit card to the immigration officials and see what happens :-) Steve Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i35FfdQc086187; Mon, 5 Apr 2004 08:41:39 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i35Ffd70086186; Mon, 5 Apr 2004 08:41:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i35FfdS4086179 for <ietf-pkix@imc.org>; Mon, 5 Apr 2004 08:41:39 -0700 (PDT) (envelope-from kent@bbn.com) Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i35FfY7d015027; Mon, 5 Apr 2004 11:41:36 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: <p06020403bc97150f71da@[128.89.89.75]> In-Reply-To: <428a370f.370f428a@noorhome.net> References: <428a370f.370f428a@noorhome.net> Date: Mon, 5 Apr 2004 11:16:29 -0400 To: Arshad Noor <arshad.noor@strongauth.com> From: Stephen Kent <kent@bbn.com> Subject: Re: PKI International Consortium Cc: Shaheen.Nasirudheen@chase.com, PKIX list <ietf-pkix@imc.org> Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> At 1:39 PM -0800 4/2/04, Arshad Noor wrote: >I would concur with you, Steve, that a single certificate that serves all >purposes, is neither practical nor desirable. (Although I must confess >to occassionally dreaming of such a utopian environment, sometimes). > >However, I believe, it is reasonable - assuming appropriate policy, >process, implementation and most importantly, cooperation - to have >industry-specific identities that may serve us all better. ("Identity >Firewalls" - http://www.strongauth.com/newsletters/2003Jan17.html). two observations: - the implicit ad for your company in the URL above is inappropriate for the PKIX list - although one might imagine such certs, there are significant adverse privacy implications (see http://www.nap.edu/books/0309088968/html/) >Companies waste far too much time and money today, building >duplicate identity infrastructures - and consequently tying their own >hands with context-sensitive identities - because it appears to be the >path of least resistance to them. But as the cost of identity theft & >of managing those numerous identity infrastructures surpasses the >perceived savings from using this path of least resistance, companies >will be forced to rethink that strategy. identity theft would likely be a bigger concern if we have fewer certs. finally, I am concerned that your message seems to be so closely aligned with you company's products. if you want to continue this discussion, please do so without making it seem like an ad for your company's products and services. Steve Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i35FTDdG085209; Mon, 5 Apr 2004 08:29:13 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i35FTD9w085208; Mon, 5 Apr 2004 08:29:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from ntexch03.office.sia.it (clients.sia.it [193.203.230.22] (may be forged)) by above.proper.com (8.12.11/8.12.8) with ESMTP id i35FT7VA085199 for <ietf-pkix@imc.org>; Mon, 5 Apr 2004 08:29:12 -0700 (PDT) (envelope-from adriano.santoni@actalis.it) Received: by ntexch03.office.sia.it with Internet Mail Service (5.5.2657.72) id <HJMG523W>; Mon, 5 Apr 2004 17:29:06 +0200 Message-ID: <BE82E060F5EA2D44A4CFCFFA83639588015D32B4@ntexch00.office.sia.it> From: Santoni Adriano <adriano.santoni@actalis.it> To: "'ietf-pkix@imc.org'" <ietf-pkix@imc.org> Subject: RFC3280: doubt on the use of UTF8String in encoding RDNs Date: Mon, 5 Apr 2004 17:28:58 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i35FTCVA085203 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Dear all, I am probably asking an old question, so ... please be patient. Rfc3280 states (§4.1.2.4): "...all certificates issued after December 31, 2003 MUST use the UTF8String encoding of DirectoryString...". Does that mean that it is mandatory to always encode all RDNs (having a type of DirectoryString) of the issuer and subject (and still other) certificate fields as UTF8Strings _even if they could be correctly encoded as a PrintableStrings_ ? TIA to all volunteers, Adriano *******************Internet Email Confidentiality Footer******************* Qualsiasi utilizzo non autorizzato del presente messaggio nonche' dei suoi allegati e' vietato e potrebbe costituire reato. Se lei ha ricevuto erroneamente il presente messaggio, Le saremmo grati se, via e-mail, ce ne comunicasse la ricezione e provvedesse alla distruzione del messaggio stesso e dei suoi eventuali allegati. Le dichiarazioni contenute nel presente messaggio nonche' nei suoi eventuali allegati devono essere attribuite esclusivamente al mittente e non possono essere considerate come trasmesse o autorizzate da SIA S.p.A.; le medesime dichiarazioni non impegnano SIA S.p.A. nei confronti del destinatario o di terzi. SIA S.p.A. non si assume alcuna responsabilita' per eventuali intercettazioni, modifiche o danneggiamenti del presente messaggio e-mail. Any unauthorized use of this e-mail or any of its attachments is prohibited and could constitute an offence. If you are not the intended addressee please advise immediately the sender by using the reply facility in your e-mail software and destroy the message and its attachments. The statements and opinions expressed in this e-mail message are those of the author of the message and do not necessarily represent those of SIA. Besides, The contents of this message shall be understood as neither given nor endorsed by SIA S.p.A.. SIA S.p.A. does not accept liability for corruption, interception or amendment, if any, or the consequences thereof. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i35D8pDM074009; Mon, 5 Apr 2004 06:08:51 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i35D8p1k074008; Mon, 5 Apr 2004 06:08:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from av7-2-sn1.fre.skanova.net (av7-2-sn1.fre.skanova.net [81.228.11.114]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i35D8n1T073997 for <ietf-pkix@imc.org>; Mon, 5 Apr 2004 06:08:50 -0700 (PDT) (envelope-from anders.rundgren@telia.com) Received: by av7-2-sn1.fre.skanova.net (Postfix, from userid 502) id 1DA7D37E7F; Mon, 5 Apr 2004 15:08:44 +0200 (CEST) Received: from smtp3-2-sn1.fre.skanova.net (smtp3-2-sn1.fre.skanova.net [81.228.11.164]) by av7-2-sn1.fre.skanova.net (Postfix) with ESMTP id 0AAC537E5A; Mon, 5 Apr 2004 15:08:44 +0200 (CEST) Received: from arport (t11o913p119.telia.com [213.64.28.119]) by smtp3-2-sn1.fre.skanova.net (Postfix) with SMTP id 1E16337E58; Mon, 5 Apr 2004 15:08:33 +0200 (CEST) Message-ID: <007e01c41b0e$17dae4d0$0500a8c0@arport> From: "Anders Rundgren" <anders.rundgren@telia.com> To: "Al Arsenault" <aarsenau@bbn.com>, "PKIX list" <ietf-pkix@imc.org>, <Shaheen.Nasirudheen@chase.com> Cc: "Stephen Kent" <kent@bbn.com>, "Arshad Noor" <arshad.noor@strongauth.com>, <amg@lcc.uma.es>, "Terwilliger, Ann" <aterwil@visa.com>, "Eric Norman" <ejnorman@doit.wisc.edu> References: <GBEOIAAPLLBIMLPDGHDHIEOCCIAA.aarsenau@bbn.com> Subject: Re: Single Identity. Was: PKI International Consortium Date: Mon, 5 Apr 2004 15:01:13 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0075_01C41B1E.D68DE9D0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> This is a multi-part message in MIME format. ------=_NextPart_000_0075_01C41B1E.D68DE9D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable AWA: Speaking from practical experience (having a physical wallet = lifted in Prague a few years back), it was easier NOT having a single = credential. Okay, the wallet with the cash, credit cards, US driver's = license, pictures of the kids, medical insurance card, etc. is gone. = But, NOT the passport, and not the emergency credit card kept separate = from the rest for exactly this eventuality. Survival was assured until = recovery could be accomplished. AR: In my opinion you are describing something like a "credential = backup" scheme which is pretty unrelated to the single credential issue. = Valid questions arise, like: Where do you keep the backups? Where would = you keep your electronic IDs when on the road (where you need them)? It = looks to me that the "always connected" world creates new problems = requiring more robust and universal solutions. The globally supported = trust network is my shot as this problem. AWA: Now, map this to the virtual world, where everything is stored in = your mobile phone. Whoops - mobile phone is lost/stolen. So I go to = the nearest branch of the "issuing agency". The conversation goes = something like Me: "excuse me, my name is Al Arsenault, and my ID was = stolen. I need a new one". Agency: "Prove that's who you are". Me: = "How? My one single ID was stolen, I need a new one". Agency: "Yes, = but if we believed you based on just what you're telling us, it could = deny service to the REAL Al Arsenault, who our records show is out = blithely spending money right now". (Somebody call John Cleese - there's = a great Monty Python skit in here somewhere.) AR: This situation is indeed a tricky one. However, it gets more = manageable when issuers have 24/7 helpdesks which allows the agency to = look-up records and ask you to answer a few questions that only the = original issuer and you have the answers to. Since agencies have to = authenticate to access external records (or identify themselves to an = issuer helpdesk), a screw-up may lead to the agency's loss of their = license. AWA: Yes, there's likely a way to PROVE that I'm the real Al Arsenault, = but I hope it doesn't involve biometrics - don't get me started down = that road. :-( AR: Biometrics is of indeed a very vital part of such verifications. = Today this may just be your picture but tomorrow it will be DNA. Since = identity theft is admittedly the weak spot of the described scheme there = are really no alternatives to biometrics except abandoning the whole = thing. AFAIK the US immigration authorities require (or are about to = require) an extensive set of biometrics in passports so either we = foreigners have to stay at home or deal with it. AR: Regarding the value of single identities it is also a matter of = cost. The majority of people work for small businesses and these may = find that using the already existing bank-issued IDs will be easier to = use than putting out user-IDs and passwords. The identity does not have = to be an SSN, it may be your bank client number or some completely = artificial number. That is, bank-IDs do not have to "emulate" passports = to be useful. AR: Regarding multiple banks, I agree with you, you should not (mostly = for commercial and political reasons) force a network of TTPs to be = direct TTPs for each other. So here there will be a deviation from the = single ID. However, you typically only need one "primary ID" for all = your TTP-based ID-relations. best AR =3D Anders Rundgren ------=_NextPart_000_0075_01C41B1E.D68DE9D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META http-equiv=3DContent-Type content=3D"text/html; = charset=3Diso-8859-1"> <META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR> <STYLE></STYLE> </HEAD> <BODY bgColor=3D#ffffff> <DIV><FONT face=3DArial size=3D2>AWA: Speaking from practical = experience=20 (having a physical wallet lifted in Prague a few years back), it was = easier NOT=20 having a single credential. Okay, the wallet with the cash, credit = cards,=20 US driver's license, pictures of the kids, medical insurance card, etc. = is=20 gone. But, NOT the passport, and not the emergency credit card = kept=20 separate from the rest for exactly this eventuality. Survival was = assured=20 until recovery could be accomplished.</FONT></DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV><FONT face=3DArial size=3D2>AR: In my opinion you are describing = something like=20 a "credential backup" scheme which is pretty unrelated to the = single=20 credential issue. Valid questions arise, like: Where do you = keep the=20 backups? Where would you keep your electronic IDs when on the road = (where you=20 need them)? It looks to me that the "always connected" world = creates=20 new problems requiring more robust and universal=20 solutions. The globally supported trust network is my shot = as this=20 problem.</FONT></DIV> <DIV><FONT face=3DArial size=3D2><FONT face=3D"Times New Roman"=20 size=3D3></FONT><BR>AWA: Now, map this to the virtual world, where = everything is stored in your mobile phone. Whoops - mobile phone = is=20 lost/stolen. So I go to the nearest branch of the "issuing = agency". =20 The conversation goes something like Me: "excuse me, my name is Al = Arsenault,=20 and my ID was stolen. I need a new one". Agency: = "Prove=20 that's who you are". Me: "How? My one single ID was = stolen, I=20 need a new one". Agency: "Yes, but if we believed you based on = just what=20 you're telling us, it could deny service to the REAL Al Arsenault, who = our=20 records show is out blithely spending money right now". (Somebody call = John=20 Cleese - there's a great Monty Python skit in here = somewhere.)</FONT></DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV><FONT face=3DArial size=3D2>AR: This situation is indeed a tricky = one. =20 However, it gets more manageable when issuers have 24/7 helpdesks which = allows=20 the agency to look-up records and ask you to answer a few questions that = only=20 the original issuer and you have the answers to. Since = agencies have=20 to authenticate to access external records (or identify themselves to an = issuer helpdesk), a screw-up may lead to the agency's loss of their = license.<BR><BR>AWA: Yes, there's likely a way to PROVE that I'm = the real=20 Al Arsenault, but I hope it doesn't involve biometrics - don't get me = started=20 down that road. :-(</FONT></DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV><FONT face=3DArial size=3D2>AR: Biometrics is of indeed a very = vital part of=20 such verifications. Today this may just be your picture but = tomorrow it=20 will be DNA. Since identity theft is admittedly the weak spot of = the=20 described scheme there are really no alternatives to biometrics except=20 abandoning the whole thing. AFAIK the US immigration authorities = require=20 (or are about to require) an extensive set of biometrics in passports so = either=20 we foreigners have to stay at home or deal with it.</FONT></DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV><FONT face=3DArial size=3D2>AR: Regarding the value of single = identities it is=20 also a matter of cost. The majority of people work for small = businesses=20 and these may find that using the <EM>already existing</EM> bank-issued = IDs will=20 be easier to use than putting out user-IDs and passwords. =20 The identity does not have to be an SSN, it may be your bank client = number=20 or some completely artificial number. That is, bank-IDs do not = have to=20 "emulate" passports to be useful.</FONT></DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV><FONT face=3DArial size=3D2>AR: Regarding multiple banks, I agree = with you, you=20 should not (mostly for commercial and political reasons) force a = network=20 of TTPs to be direct TTPs for each other. So here there will = be a=20 deviation from the single ID. However, you typically only need one = "primary ID" for all your TTP-based ID-relations.</FONT></DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV><FONT face=3DArial size=3D2>best</FONT></DIV> <DIV><FONT face=3DArial size=3D2>AR =3D Anders Rundgren</FONT></DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV></BODY></HTML> ------=_NextPart_000_0075_01C41B1E.D68DE9D0-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i353Dg3Y050165; Sun, 4 Apr 2004 20:13:42 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i353DgXm050164; Sun, 4 Apr 2004 20:13:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail9.atl.registeredsite.com (nobody@mail9.atl.registeredsite.com [64.224.219.83]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i353DfKP050156 for <ietf-pkix@imc.org>; Sun, 4 Apr 2004 20:13:41 -0700 (PDT) (envelope-from egerck@nma.com) Received: from taurus.hosting4u.net (taurus.hosting4u.net [209.35.191.122]) by mail9.atl.registeredsite.com (8.12.8/8.12.8) with ESMTP id i353DkKS003942; Mon, 5 Apr 2004 03:13:46 GMT Received: from nma.com ([63.204.17.85]) by taurus.hosting4u.net ; Sun, 04 Apr 2004 22:13:45 -0500 Message-ID: <4070CED2.2B9A5EBA@nma.com> Date: Sun, 04 Apr 2004 20:13:22 -0700 From: Ed Gerck <egerck@nma.com> X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Eric Norman <ejnorman@doit.wisc.edu> CC: PKIX list <ietf-pkix@imc.org> Subject: Re: Identity (was PKI International Consortium) References: <Pine.A41.4.44.0404041925340.18426-100000@holstein.doit.wisc.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Eric Norman wrote: > > On Sun, 4 Apr 2004 amg@lcc.uma.es wrote: > > > So, again, in the design of Identity Certificates we should concentrate on > > Identity issues, and on the needs of systems requiring identification. Trying > > to use Identity Certificates for other uses is wrong. > > Well, my opinion is that you won't have much luck dealing with "Identity > issues" until you have a good definition of "identity". > > Here's my shot at it. If you start from the premise that identity is > just a set of attributes, then your identity is those attributes that > are constant and last forever. Not even your fingerprints are constant and last forever (or, for your lifetime). Identity is not a thing or a set of things. Identity is the connection -- to identify is to seek connections [1]. In identification we look for logical or natural connections, where absence of connections also counts. For example: - between a fingerprint and the person that has it, - between a PK certificate and its private key, - between a name and the person that answers by that name, - between an Internet host and a URL that connects to it, - between an idea and the way we can represent it in words, - conversely, between words and the ideas they represent, - etc. Identification can thus be understood not only in the sense of an "identity" connection, but in the wider sense of any connection. That's why it does not make much sense to have *one* identity certificate -- we do have many identities (connections) and we may need to use them in separate. Which one to use is just a matter of protocol expression, need, cost and (very importantly) privacy concerns [1]. Cheers, Ed Gerck [1] For my '98 draft on this concept, please see http://nma.com/mcg-mirror/coherence.txt This work shows that not identity but coherence (as natural or logical connections) is the general metric for identification. More coherence and more coherence modes mean stronger identification, even if anonymous. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i352wsix049019; Sun, 4 Apr 2004 19:58:54 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i352wsIp049018; Sun, 4 Apr 2004 19:58:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mdhagsmtp01.firstdata.com (mdhagsmtp01.firstdata.com [198.184.5.21]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i352wsH5049010 for <ietf-pkix@imc.org>; Sun, 4 Apr 2004 19:58:54 -0700 (PDT) (envelope-from lynn.wheeler@firstdata.com) Subject: Re: Identity (was PKI International Consortium) To: Eric Norman <ejnorman@doit.wisc.edu> Cc: PKIX list <ietf-pkix@imc.org>, owner-ietf-pkix@mail.imc.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: <OFEA2D5749.0934D35B-ON87256E6D.000DDEF5@firstdata.com> From: lynn.wheeler@firstdata.com Date: Sun, 4 Apr 2004 20:57:59 -0600 X-MIMETrack: Serialize by Router on MDHAGSMTP/FDMS/FDC(Release 6.0.2CF2|July 23, 2003) at 04/04/2004 10:58:02 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> I've lately been busy working on X9.99 financial industry financial standard for privacy, learning more than i want to do about EU-DPD, GLB and HiPPA, etc. Somewhat to complement the merged security taxonomy & glossary work http://www.garlic.com/~lynn/index.html#glosnote I've started a merged privacy taxonomy & glossary ... pulling from EU data privacy directive, GLB, HiPPA, OMB, FTC and a couple others. My earlier statement was that there was significant retrenchment from the X.509 Identity certificates of the early '90s because of the serious privacy issues that the information represented. The issue wasn't so much what features in X.509 Identity certificates were related to identity ... but what features in X.509 identity certificates that raised serious privacy issues. EU-DPD, HiPPA, and GLB have issues about PHI (protected health information) and PII (personally identifiable information) and sensitive perosnally identifiable information. >From their standpoint, it isn't so much identity information per se ... it is any kind of personal information that adversely affect a person's quality of living (like fraud, phishing, identity theft, etc). In the past i've defined a taxonomy for authentication information and certificates. In effect, there is some entity information that is registered someplace ... likely at a certificate issuer ... but possibly someplace else. The certificate issuer packages up a R/O copy of that information and creates a static certificate containing that information and distributes it (or at least returns the r/o copy of the information, i.e. the certificate to the entity requesting the certificate). The certificate by its very nature is static ... the digital signature of the certificate issuer goes to a great deal of trouble to establish it as static (and if it ever does change ... the certificate becomes invalid). The certificate is, in a way, a high-integrity, static, r/o cached copy of some information stored some place else. This allows it to be used in an offline process when the relying-party doesn't otherwise have recourse to the original information. In that sense, it is directly analogous to CPU r/o cached entries, or filesystem r/o cached records, or database r/o cached entriess. Once the cached copy (certificate) is distributed, it by definition is stale ... representing the state of some record at some time in the past. The information contained in the cached certificate/copy may or may not be stale, but by definition the certificate itself is stale. So therefor, I assert that it is perfectly reasonable to refer to certificates as static and stale (regardless of whether or not the information contained within the certificate has yet become stale). One point in using the characteristics static and stale to describe the certificate paradigm .... is to highlight that certificates are in effect, r/o cached entries of some other information. It makes a distinction between the information that might be contained in a certificate from the certificate paradigm itself. There has been a lot of work on the basic nature of cached information ... which i believe is applicable to the certificate paradigm. That work is totally orthogonal to the nature of the information itself (that might be contained in a certificate). ejnorman@doit.wisc.edu wrote: Well, my opinion is that you won't have much luck dealing with "Identity issues" until you have a good definition of "identity". Here's my shot at it. If you start from the premise that identity is just a set of attributes, then your identity is those attributes that are constant and last forever. So, my "Identity certificate" asserts an association between me and the University of Wisconsin. Is that part of my identity? It depends on how you interpret that assertion. If you interpret it as "was at one time affiliated with that university", then that lasts forever and it is (Winston Smith to the contrary). If you interpret it as "is currently affiliated...", then it isn't. The only observation I can make right now is that with the former interpretation, Lynn Wheeler doesn't get to use the adjectives "stale" and "static". Whether that's any more useful than counting angels dancing on pinheads remains to be seen, I suppose. -- Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i352tXF1048837; Sun, 4 Apr 2004 19:55:33 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i352tXuU048836; Sun, 4 Apr 2004 19:55:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mdhagsmtp01.firstdata.com (mdhagsmtp01.firstdata.com [198.184.5.21]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i352tWE3048822 for <ietf-pkix@imc.org>; Sun, 4 Apr 2004 19:55:32 -0700 (PDT) (envelope-from lynn.wheeler@firstdata.com) Subject: Re: PKI International Consortium To: "todd glassey" <todd.glassey@worldnet.att.net> Cc: "Arshad Noor" <arshad.noor@strongauth.com>, "PKIX list" <ietf-pkix@imc.org>, owner-ietf-pkix@mail.imc.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: <OF6EA7C1C2.869BE2AE-ON87256E6D.000C67DA@firstdata.com> From: lynn.wheeler@firstdata.com Date: Sun, 4 Apr 2004 20:28:38 -0600 X-MIMETrack: Serialize by Router on MDHAGSMTP/FDMS/FDC(Release 6.0.2CF2|July 23, 2003) at 04/04/2004 10:54:41 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> the EU directive just said something about being as anonymous as cash .... in general the privacy mandates signficantly reduce the run of the mill phishing .... it is somewhat like cryptography .... some cryptography is secure for all but the most determined government operations. it is possible to make account number electronic financial transactions like x9.59 http://www.garlic.com/~lynn/index.html#x959 .... authenticated but not identified. In that sense they become pretty agnostic with respect to identification. Governments are able to mandate "know your customer" rules for the accounts ... which given the appropriate government action can extract all sorts of details. However, it doesn't preclude other governments allowing purely anonymous accounts. todd.glassey@worldnet.att.nte wrote: Lynn - good commentary - but I also want to add that cash transactions are not anonymous in that they leave finger prints and they survived this "reduction in their anonymity" after the adoption of fingerprinting by law enforcement... i.e. Someone handles the money and there is all kind of tangible evidence left, the issue is the cost of collecting and maintaining it. Todd -- Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i351KK8e041412; Sun, 4 Apr 2004 18:20:20 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i351KKvA041411; Sun, 4 Apr 2004 18:20:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i351KKsF041402 for <ietf-pkix@imc.org>; Sun, 4 Apr 2004 18:20:20 -0700 (PDT) (envelope-from aarsenau@bbn.com) Received: from arsenaultd2 (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with SMTP id i351KK7W019468; Sun, 4 Apr 2004 21:20:20 -0400 (EDT) From: "Al Arsenault" <aarsenau@bbn.com> To: "Eric Norman" <ejnorman@doit.wisc.edu>, "PKIX list" <ietf-pkix@imc.org> Subject: RE: Identity (was PKI International Consortium) Date: Sun, 4 Apr 2004 21:19:23 -0400 Message-ID: <GBEOIAAPLLBIMLPDGHDHOEOCCIAA.aarsenau@bbn.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <Pine.A41.4.44.0404041925340.18426-100000@holstein.doit.wisc.edu> X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i351KKsF041406 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> > > On Sun, 4 Apr 2004 amg@lcc.uma.es wrote: > > > So, again, in the design of Identity Certificates we should > concentrate on > > Identity issues, and on the needs of systems requiring > identification. Trying > > to use Identity Certificates for other uses is wrong. > > Well, my opinion is that you won't have much luck dealing with "Identity > issues" until you have a good definition of "identity". > > Here's my shot at it. If you start from the premise that identity is > just a set of attributes, then your identity is those attributes that > are constant and last forever. AWA: "reasonably forever". :-) There aren't any attributes guaranteed to last forever. People change their names, for reasons of marriage, divorce, or because they just want to. Affiliations - employers, university attended, etc. - change when circumstances change. > > So, my "Identity certificate" asserts an association between me and > the University of Wisconsin. Is that part of my identity? It depends > on how you interpret that assertion. If you interpret it as "was at > one time affiliated with that university", then that lasts forever and > it is (Winston Smith to the contrary). If you interpret it as "is > currently affiliated...", then it isn't. > > The only observation I can make right now is that with the former > interpretation, Lynn Wheeler doesn't get to use the adjectives "stale" > and "static". Whether that's any more useful than counting angels > dancing on pinheads remains to be seen, I suppose. > > AWA: I tend to agree with this. > Eric Norman > > "Congress shall make no law restricting the size of integers > that may be multiplied together, or the number of times that > an integer may be multiplied by itself, or the modulus by > which an integer may be reduced". Al Arsenault BBN Technologies (should I add "no longer a Verizon company"? :-) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i351GKNm041083; Sun, 4 Apr 2004 18:16:20 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i351GKP0041082; Sun, 4 Apr 2004 18:16:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i351GJcb041073 for <ietf-pkix@imc.org>; Sun, 4 Apr 2004 18:16:19 -0700 (PDT) (envelope-from aarsenau@bbn.com) Received: from arsenaultd2 (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with SMTP id i351GF7W019383; Sun, 4 Apr 2004 21:16:16 -0400 (EDT) From: "Al Arsenault" <aarsenau@bbn.com> To: "Anders Rundgren" <anders.rundgren@telia.com>, "PKIX list" <ietf-pkix@imc.org>, <Shaheen.Nasirudheen@chase.com> Cc: "Stephen Kent" <kent@bbn.com>, "Arshad Noor" <arshad.noor@strongauth.com>, <amg@lcc.uma.es>, "Terwilliger, Ann" <aterwil@visa.com>, "Eric Norman" <ejnorman@doit.wisc.edu> Subject: RE: Single Identity. Was: PKI International Consortium Date: Sun, 4 Apr 2004 21:15:18 -0400 Message-ID: <GBEOIAAPLLBIMLPDGHDHIEOCCIAA.aarsenau@bbn.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <002801c41a52$6db40010$0500a8c0@arport> X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i351GKcb041077 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> A few comments in-line, prefaced by my initials, "AWA". > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org > [mailto:owner-ietf-pkix@mail.imc.org]On Behalf Of Anders Rundgren > Sent: Sunday, April 04, 2004 10:38 AM > To: PKIX list; Shaheen.Nasirudheen@chase.com > Cc: Stephen Kent; Arshad Noor; amg@lcc.uma.es; Terwilliger, Ann; Eric > Norman > Subject: Single Identity. Was: PKI International Consortium > > > > Dear PKIers, > I could not resist this one as I have worked with this idea since > 1997.... > > The quest for a single identity > --------------------------------- > Assume that an international consortium of banks indeed agreed > on a common certificate issuance policy of a relatively high level > (as well as shelving the four-corner model), I believe you would > have a very good foundation for a universal single-identity scheme. > It is worth noting that a single identity is a reality in Sweden since > around 1960 so this is a time-proven scheme as well. AWA: This really seems to be a function of national culture. In some places - Sweden and other countries among them - a "single identity" is accepted as part of life. In other cultures, it's not only not accepted, but the entire idea is abhorrent. This is actually a good thing, to me: the world is different; let different people/cultures live by their own rules rather than trying to force them all into one thing. > > A tricky real-life use-case > ----------------------------- > Now assume that you one day lose your wallet [1] with ID- > certificates when you are on an oversea trip. Who will have > the swift and secure way back? The individual with a handful > of locally issued credentials, or the individual who have a > single credential issued by a member of a trusted network of > international issuers having branch offices in every town of > any size worth mentioning? > AWA: Speaking from practical experience (having a physical wallet lifted in Prague a few years back), it was easier NOT having a single credential. Okay, the wallet with the cash, credit cards, US driver's license, pictures of the kids, medical insurance card, etc. is gone. But, NOT the passport, and not the emergency credit card kept separate from the rest for exactly this eventuality. Survival was assured until recovery could be accomplished. AWA: Now, map this to the virtual world, where everything is stored in your mobile phone. Whoops - mobile phone is lost/stolen. So I go to the nearest branch of the "issuing agency". The conversation goes something like Me: "excuse me, my name is Al Arsenault, and my ID was stolen. I need a new one". Agency: "Prove that's who you are". Me: "How? My one single ID was stolen, I need a new one". Agency: "Yes, but if we believed you based on just what you're telling us, it could deny service to the REAL Al Arsenault, who our records show is out blithely spending money right now". (Somebody call John Cleese - there's a great Monty Python skit in here somewhere.) AWA: Yes, there's likely a way to PROVE that I'm the real Al Arsenault, but I hope it doesn't involve biometrics - don't get me started down that road. :-( > Most security folks only look to revocation issues but it is > really at least as critical to get replacement credentials as you > in an anticipated "e-society" will be completely handicapped > without getting access to your work, bank, e-government etc. AWA: Yes, absolutely. > > TTPs rule - Like it or not > ----------------------------- > Some people object to the TTP idea but the reality is that > all issuances not based on DNA or similar "body-based- > authentication", already fully depend on TTP-issued > passports, driver licenses, gas bills (!) etc. > AWA: I disagree. These are generally Second-Party (not third) for their primary purposes. Examples: - Governments issue passports. They're used to identify you to other Governments (and your own). Second party issuance. Yes, it's true that passports are sometimes used in other circumstances, but that's not their primary reason for being. - Driver's licenses are issued, in the US, by state Motor Vehicle Agencies (the names vary, but the principle's the same). They're meant to show that you are allowed to drive under some conditions (e.g., must wear glasses/contact lenses; under-age so cannot drive alone at night; can operate a motorcycle; can operate a commercial truck/bus; etc.) Second party issuance. Yes, these get used a lot for purposes other than showing that you can legally operate a motor vehicle just because it's so darned easy, but that's not the purpose for which they were created. - Gas bills are generated and managed by the utility company. They don't want to know or care about my driver's license or whether I have a passport; they care about my address and payment history. Yes, it's true that in many cases, the second parties who issue these IDs outsource some of their IT infrastructure, so there are some "third parties" involved. But the bottom line is that the US Department of State doesn't go to VeriSign or anybody else to issue you a passport. They do it by themselves or with the aid of selected Registration Agents like the US Postal Sservice. > So you really need multiple identities? > ------------------------------------------- > The need for multiple identity when you interact with your own > trusted providers including your employers, banks, or emerging > e-government services seems hard to justify (unless for potential > cost issues with respect to the issuer). > AWA: The issue is part cultural, part cost. My employer knows me as an employee. I have an employee number, which is NOT the same as my tax id, my social security number, my passport number, or any of my credit card or bank account numbers. BBN uses to reference all of my employment records since I started working here. That's it. There's no reason for them to know or care about any other number (except the tax/social security stuff, since they have to get the taxes right. But that's handled with a mapping.) Suppose I have relationships with several banks (not uncommon in the US). Bank 1 knows me as its account_1. Bank_2 knows me as its account_2. There's no reason these have to be synchronized; why force the two banks to combine/merge/whatever their account records? It would be a cost, with no benefit. And, it's just not necessary. There's no real reason why Bank 1 and Bank 2 need to know me by a common identifier. If I want them to be able to do things for me, like electronically transfer funds from one to the other, I'll provide them with the mapping. If I don't, I won't and they're happier not knowing about each other. Now, of course, it's likely that many places with whom I interact financially do know me by a common identifier - the US Social Security Number. (Not all of them know it, but the employers and banks certainly do.) They COULD if they want combine around that as a common identifier, but culturally, at least in the US, that's seen as a really bad idea. It lets too much information about you be aggregated, and is considered to be a major privacy problem. Other societies have similar views; e.g., the Hong Kong ID used by all legal residents of the HKSAR is considered to be private information and its unauthorized disclosure is generally a violation of laws. In societies where this cultural view is not held - e.g., in Sweden according to Anders - then it's quite likely that many of my arguments do not hold. Fine - different places are different. > When you OTOH interact with non-trusted providers or > providers where your identity as an individual is of secondary > importance or even is important to protect, SAML, 3D Secure, > etc. offer a great way of leveraging a single identity. That is, > these schemes allow you to be a VISA card, B2B purchaser, > etc. without having to have such resources issued to you to > be carried around, as they exploit the on-line paradigm [2]. > > The only real problem > ------------------------- > The only real problem stopping this vision is that banks are > slove movers, cooperate poorly, and do not participate in > the development of open standards, and may therefore miss > this golden opportunity. It is really about acknowledging > that an identity business potentially targeting the entire > "e-society" is very different to running payment networks, > as only e-the former reach into the hart of relying parties' > IT-systems. > AWA: No, the real "problem" is that many cultures in the world think having a single identifier for all purposes is a really bad idea. That's certainly what my opinion is. I recognize that others disagree, but.. > Regards > Anders Rundgren > Consultant, e-infrastructure > + 46 70 - 627 74 37 > > 1] The "wallet" is likely to be our mobile phones as this > device is developing at record speed, is replaced every 18 > months (ave.), and is already most people's favorite IT-toy. > The local wireless connectivity today shipping in about 25% > of all PCs is an excellent replacement for card readers. > > 2] A couple of papers showing how on-line changes everything: > http://www.x-obi.com/OBI400/pki4org.pdf > http://w1.181.telia.com/~u18116613/CAeXtraInfo.pdf > > > Al Arsenault BBN Technologies Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i350oT90039486; Sun, 4 Apr 2004 17:50:29 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i350oTLJ039485; Sun, 4 Apr 2004 17:50:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from imap1.doit.wisc.edu (imap1.doit.wisc.edu [144.92.9.75]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i350oTdO039477 for <ietf-pkix@imc.org>; Sun, 4 Apr 2004 17:50:29 -0700 (PDT) (envelope-from ejnorman@doit.wisc.edu) Received: from [128.104.19.109] (HELO holstein.doit.wisc.edu) by imap1.doit.wisc.edu (CommuniGate Pro SMTP 3.5.9) with ESMTP-TLS id 37781679 for ietf-pkix@imc.org; Sun, 04 Apr 2004 19:44:59 -0500 Date: Sun, 4 Apr 2004 19:50:34 -0500 (CDT) From: Eric Norman <ejnorman@doit.wisc.edu> To: PKIX list <ietf-pkix@imc.org> Subject: Identity (was PKI International Consortium) In-Reply-To: <200404041102.NAA13343@sol10.lcc.uma.es> Message-ID: <Pine.A41.4.44.0404041925340.18426-100000@holstein.doit.wisc.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> On Sun, 4 Apr 2004 amg@lcc.uma.es wrote: > So, again, in the design of Identity Certificates we should concentrate on > Identity issues, and on the needs of systems requiring identification. Trying > to use Identity Certificates for other uses is wrong. Well, my opinion is that you won't have much luck dealing with "Identity issues" until you have a good definition of "identity". Here's my shot at it. If you start from the premise that identity is just a set of attributes, then your identity is those attributes that are constant and last forever. So, my "Identity certificate" asserts an association between me and the University of Wisconsin. Is that part of my identity? It depends on how you interpret that assertion. If you interpret it as "was at one time affiliated with that university", then that lasts forever and it is (Winston Smith to the contrary). If you interpret it as "is currently affiliated...", then it isn't. The only observation I can make right now is that with the former interpretation, Lynn Wheeler doesn't get to use the adjectives "stale" and "static". Whether that's any more useful than counting angels dancing on pinheads remains to be seen, I suppose. Eric Norman "Congress shall make no law restricting the size of integers that may be multiplied together, or the number of times that an integer may be multiplied by itself, or the modulus by which an integer may be reduced". Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i34M3Gm0030545; Sun, 4 Apr 2004 15:03:16 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i34M3GdQ030544; Sun, 4 Apr 2004 15:03:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mtiwmhc11.worldnet.att.net (mtiwmhc11.worldnet.att.net [204.127.131.115]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i34M3FOM030526 for <ietf-pkix@imc.org>; Sun, 4 Apr 2004 15:03:15 -0700 (PDT) (envelope-from todd.glassey@worldnet.att.net) Received: from gw (35.san-jose-04-05rs.ca.dial-access.att.net[12.72.193.35]) by worldnet.att.net (mtiwmhc11) with SMTP id <20040404220302111006j503e>; Sun, 4 Apr 2004 22:03:04 +0000 Message-ID: <018701c41a90$8940e1c0$010aff0a@gw> From: "todd glassey" <todd.glassey@worldnet.att.net> To: "Arshad Noor" <arshad.noor@strongauth.com>, <lynn.wheeler@firstdata.com> Cc: "PKIX list" <ietf-pkix@imc.org>, <owner-ietf-pkix@mail.imc.org> References: <OF1C03E577.940E997C-ON87256E6B.00511420@firstdata.com> Subject: Re: PKI International Consortium Date: Sun, 4 Apr 2004 15:02:28 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Lynn - good commentary - but I also want to add that cash transactions are not anonymous in that they leave finger prints and they survived this "reduction in their anonymity" after the adoption of fingerprinting by law enforcement... i.e. Someone handles the money and there is all kind of tangible evidence left, the issue is the cost of collecting and maintaining it. Todd ----- Original Message ----- From: <lynn.wheeler@firstdata.com> To: "Arshad Noor" <arshad.noor@strongauth.com> Cc: "PKIX list" <ietf-pkix@imc.org>; <owner-ietf-pkix@mail.imc.org> Sent: Saturday, April 03, 2004 8:21 AM Subject: Re: PKI International Consortium > > > > > > An example with slight variation on this was some EU directive that > electronic payments at point-of-sale should be as anonymous as cash, aka it > should be possible to authenticate a transaction for authorization w/o > requiring any identification what-so-ever. > > The issue is that if you have some sort of authentication, aka "something > you have", "something you know", "something you are" .... and possibly > non-shared-secret based ... it is possible to have an authorization context > that just does authentication and no identification is involved. > > it that case, if there is an authorization context ... with some recorded > authentication mechanism ... then the authentication is bound to the > authorization context and there is no identification at all. > > in such a taxonomy .... a certificate represents a static, stale, > authorization context for offline environments ... where the public key is > the authentication mechanism bound to the authorization context. The > authentication mechanism is some form of "something you have" .... based on > uniquely having a private key that generates a digital signature that can > authenticated with the public key. This is basically the scenario for the > relying-party-only certificates from the mid-90s (somewhat resulting from > retrentching from the horrible privacy issues of full blown x.509 identity > certificates). Note, however, it isn't the certificate that creates the > "something you have" associated with the private key, the certificate > provides the portable, stale, static authorization context for offline > environments. It is equally possible to have an online environment where > the public key is bound to an online authorization mechanism and no > certificates are involved at all. The online payment point-of-sale > transactions with relying-party-only certificates exemplified redundant and > superfluous. The transaction was valuable enough that timely and aggregated > online information was deemed justified (the benefit of having an online, > timely transaction more than offset the incremental cost of having an > online transaction) .... but a relying-party-only certificate was provided > such that their could be an offline authorization context .... but that was > then made redundant and superfluous by having the transaction executed > online with an online authorization context. > > The example I've used for identity is the problems with issuing SSL server > domain certificates. The authoritative agency for domain names is the > domain name infrastructure. The typical process for obtaining an SSL server > domain certificate is to provide very strong identification information to > the SSL certificate issuer. The issue is that the domain name > infrastructure has some identification information registered for the owner > of the domain name. The challenge for the SSL certificate issuer is to be > able to perform some level of identification matching from what is provided > by the certificate applicant with the identification that is on file for > the domain name owner. The reason for the identification operation is that > there is no industry-specific authentication. This turns out to be > expensive and somewhat error prone. A suggestion, somewhat from the > certificate industry is that a public key is registered with the domain > name infrastructure when the domain name is registered. Then when somebody > applies for a certificate, they digitally sign the operation. The > certificate issuer then just needs an online authentication of the digital > signature with what is on file with the domain name infrastructure and a > very expensive and error-prone identification process is turned into a much > simpler industry-specific authentication operation. There is an implied > authorization that the owner of the domain name is allowed to obtain an SSL > domain certificate for that domain name. Of course, there is possibly a > slight Catch-22 for the SSL certificate industry ... that if the > certificate industry can make use of online public keys from the domain > name infrastructure .... that possibly the rest of the world could also ... > leading to possibly eliminating the need for SSL domain name certificates > with stale, static certificates binding public keys to domain names. > > > arshad.noor@strongauth.com on 4/2/2004 8:49 pm wrote: > > I am in complete agreement with you, Lynn. An industry-specifc > identity should be designed to perform only a single function - > authenticate the holder of the credential. Authorization must > ALWAYS be determined by the context that has successfully > authenticated the entity - and those authorization rules must > always be owned and controlled by the context owner. > > -- > Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i34JuGaA022120; Sun, 4 Apr 2004 12:56:16 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i34JuG8E022119; Sun, 4 Apr 2004 12:56:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp-ft6.fr.colt.net (smtp-ft6.fr.colt.net [213.41.78.209]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i34JuEU3022091 for <ietf-pkix@imc.org>; Sun, 4 Apr 2004 12:56:15 -0700 (PDT) (envelope-from jmdesp@free.fr) Received: from free.fr (host.107.92.68.195.rev.coltfrance.com [195.68.92.107]) by smtp-ft6.fr.colt.net with ESMTP id i34Ju7i09178 for <ietf-pkix@imc.org>; Sun, 4 Apr 2004 21:56:12 +0200 Message-ID: <40706853.2030401@free.fr> Date: Sun, 04 Apr 2004 21:56:03 +0200 From: Jean-Marc Desperrier <jmdesp@free.fr> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:) Gecko/20040226 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: Re: Re-certification References: <E1B9cfj-00063b-Cw@medusa01> In-Reply-To: <E1B9cfj-00063b-Cw@medusa01> 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: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Peter Gutmann wrote: >"Rodrigo Botafogo" <rbotafogo@certisign.com.br> writes: > > >>What the Certificate Authority did was: >>- Generated a new key pair; >>- Created a new certificate with: i) the same DN as the >>expiring CA, ii) the new key and iii) an extended expiration date >> >> >That's exactly what Verisign did when their root certs expired, > AFAIK I have never seen Verisign *change* the key pair of an authority. They always extend validity, while keeping the same key pair. About Rorigo's question : It's perfectly legal to do that, if you don't reuse the same serial number for the old CA and the new CA cert. The RFC proper way to do it is described in paragraph 2.4 of rfc2510. You might find interesting to read the following document : http://www.wide.ad.jp/wg/moca/CAkeychangeover.txt that describes that the rfc recommended way of doing it doesn't work very well in real life. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i34GsVGI009139; Sun, 4 Apr 2004 09:54:31 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i34GsUZu009138; Sun, 4 Apr 2004 09:54:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mdhagsmtp01.firstdata.com (mdhagsmtp01.firstdata.com [198.184.5.21]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i34GsUIx009123 for <ietf-pkix@imc.org>; Sun, 4 Apr 2004 09:54:30 -0700 (PDT) (envelope-from lynn.wheeler@firstdata.com) Subject: Re: PKI International Consortium To: amg@lcc.uma.es Cc: amg@lcc.uma.es, PKIX list <ietf-pkix@imc.org>, owner-ietf-pkix@mail.imc.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: <OF01843140.BEE79D0B-ON87256E6C.0050F131@firstdata.com> From: lynn.wheeler@firstdata.com Date: Sun, 4 Apr 2004 10:24:08 -0600 X-MIMETrack: Serialize by Router on MDHAGSMTP/FDMS/FDC(Release 6.0.2CF2|July 23, 2003) at 04/04/2004 12:53:35 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> The use of relying-party-only certificates were done in large part because of privacy issues ... which could be * personal privacy issues with identity information * personal privacy issues with personal attributes * institutional sensitivity/privacy issues with institutional attributes However, for a relying party that used an index/account number from a relying-party-only certificate to index an entity entry in a repository or access an online service, it can be shown that the stale, static replying-party-only certificate is redundant and superfluous. The issue is that the relying party is retrieving attributes and/or authorization from the online service and or an entity entry from their own respository ... and, in effect, a public key bound to an entity is then just another personal attribute. A public key personal attribute is safely stored in an entities entry in a repository just like any other personal attribute, no matter how many PKI infrastructures wish to infuse public keys with some sort of mystical properties (alhtough public key can be a non-shared-secret where so many other attributes take on shared-secret properties). One scenario is FAST project that was being done by FSTC http://www.fstc.org/ this basically attempted to leverage the 8583 real-time infrastructures to provide real-time yes/no answers about things other than authorizing financial transaction. For instance, rather than having an attribute certificate with date-of-birth (which currently represents a identity theft vulnerability) to establish whether a person is younger/older than 18 .... an entity would sign a age level question, much in the same way they might sign a x9.59 financial transaction. This is then sent off to the financial institution, which decodes it and replies yes/no to the relying party. The FI maintains a repository entry for the entity ... including things like timely, sensitive and/or aggregated information. The FI can answerr questions about younger/older than 18 (w/o having to reveal date-of-birth) or answer yes/no to a financial transaction w/o having to reveal credit limit or current balance. The current issue is that things like identity theft vulnerabilities aren't limited to just identity, but can include other personal attributes as well; in fact probably includes attribute that may potentially be used in part of a shared-secret paradigm. Also sensitivity of attributes may not be just be limited to personal attributes, but may also include institutional sensitivity regarding institutional attributes. amg@lcc.uma.es wrote: Hi, > If a relying party needs to know that I possess certain attributes, and > if I can present an "Attribute Certificate" that convinces them that I > do indeed possess those attributes, then what purpose is served by also > having me present an "Identity Certificate"? You are completely right, Eric. There are many situations that require the knowledge of certain attributes but do not require knowledge of identity. For instance, accesing the Playboy should require knowledge of the user being over 18, but no identity information should be revealed. -- Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i34DjPgX097861; Sun, 4 Apr 2004 06:45:25 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i34DjPJP097860; Sun, 4 Apr 2004 06:45:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from av4-2-sn3.vrr.skanova.net (av4-2-sn3.vrr.skanova.net [81.228.9.112]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i34DjOj7097839 for <ietf-pkix@imc.org>; Sun, 4 Apr 2004 06:45:24 -0700 (PDT) (envelope-from anders.rundgren@telia.com) Received: by av4-2-sn3.vrr.skanova.net (Postfix, from userid 502) id 6459737FD3; Sun, 4 Apr 2004 15:45:14 +0200 (CEST) Received: from smtp1-2-sn3.vrr.skanova.net (smtp1-2-sn3.vrr.skanova.net [81.228.9.178]) by av4-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 552C737E6E; Sun, 4 Apr 2004 15:45:14 +0200 (CEST) Received: from arport (t9o913p98.telia.com [213.64.27.98]) by smtp1-2-sn3.vrr.skanova.net (Postfix) with SMTP id 91E053800D; Sun, 4 Apr 2004 15:45:04 +0200 (CEST) Message-ID: <002801c41a52$6db40010$0500a8c0@arport> From: "Anders Rundgren" <anders.rundgren@telia.com> To: "PKIX list" <ietf-pkix@imc.org>, <Shaheen.Nasirudheen@chase.com> Cc: "Stephen Kent" <kent@bbn.com>, "Arshad Noor" <arshad.noor@strongauth.com>, <amg@lcc.uma.es>, "Terwilliger, Ann" <aterwil@visa.com>, "Eric Norman" <ejnorman@doit.wisc.edu> References: <OF169CF168.3D170BCC-ON85256E6A.0078DDD6@chase.com> Subject: Single Identity. Was: PKI International Consortium Date: Sun, 4 Apr 2004 16:37:51 +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 Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Dear PKIers, I could not resist this one as I have worked with this idea since 1997.... The quest for a single identity --------------------------------- Assume that an international consortium of banks indeed agreed on a common certificate issuance policy of a relatively high level (as well as shelving the four-corner model), I believe you would have a very good foundation for a universal single-identity scheme. It is worth noting that a single identity is a reality in Sweden since around 1960 so this is a time-proven scheme as well. A tricky real-life use-case ----------------------------- Now assume that you one day lose your wallet [1] with ID- certificates when you are on an oversea trip. Who will have the swift and secure way back? The individual with a handful of locally issued credentials, or the individual who have a single credential issued by a member of a trusted network of international issuers having branch offices in every town of any size worth mentioning? Most security folks only look to revocation issues but it is really at least as critical to get replacement credentials as you in an anticipated "e-society" will be completely handicapped without getting access to your work, bank, e-government etc. TTPs rule - Like it or not ----------------------------- Some people object to the TTP idea but the reality is that all issuances not based on DNA or similar "body-based- authentication", already fully depend on TTP-issued passports, driver licenses, gas bills (!) etc. So you really need multiple identities? ------------------------------------------- The need for multiple identity when you interact with your own trusted providers including your employers, banks, or emerging e-government services seems hard to justify (unless for potential cost issues with respect to the issuer). When you OTOH interact with non-trusted providers or providers where your identity as an individual is of secondary importance or even is important to protect, SAML, 3D Secure, etc. offer a great way of leveraging a single identity. That is, these schemes allow you to be a VISA card, B2B purchaser, etc. without having to have such resources issued to you to be carried around, as they exploit the on-line paradigm [2]. The only real problem ------------------------- The only real problem stopping this vision is that banks are slove movers, cooperate poorly, and do not participate in the development of open standards, and may therefore miss this golden opportunity. It is really about acknowledging that an identity business potentially targeting the entire "e-society" is very different to running payment networks, as only e-the former reach into the hart of relying parties' IT-systems. Regards Anders Rundgren Consultant, e-infrastructure + 46 70 - 627 74 37 1] The "wallet" is likely to be our mobile phones as this device is developing at record speed, is replaced every 18 months (ave.), and is already most people's favorite IT-toy. The local wireless connectivity today shipping in about 25% of all PCs is an excellent replacement for card readers. 2] A couple of papers showing how on-line changes everything: http://www.x-obi.com/OBI400/pki4org.pdf http://w1.181.telia.com/~u18116613/CAeXtraInfo.pdf --------------------------------------------------------- --------------------------------------------------------- ----- Original Message ----- From: <Shaheen.Nasirudheen@chase.com> To: "PKIX list" <ietf-pkix@imc.org> Cc: "Stephen Kent" <kent@bbn.com>; "Arshad Noor" <arshad.noor@strongauth.com>; "Anders Rundgren" <anders.rundgren@telia.com> Sent: Saturday, April 03, 2004 00:37 Subject: Re: PKI International Consortium Hello everyone, Quote from bbn.com : "In 1968, the Advanced Research Projects Agency (ARPA) sent out a Request for Quotation (RFQ) to build a network of four Interface Message Processors (IMPs). Many of the large computer and telecommunications organizations didn't even respond--they thought it was impossible. " - http://bbn.com/arpanet/index.html. If the pioneers believed that "Internet" is impossible, then I dont think we would enjoy sending these emails today. Anyway, consider the following: 1. A central authority issues and maintains certificates for the customers of FI. The central authority prescribes a set of standards and regulations on creation, issuance and maintenance of the certificate. 2. The FI or independent agents may issue the certificate on behalf of the central authority. However, the certificate issued to the customer should not have any direct relation to the FI (Financial Institution). 3. The customer may subscribe for the services of an FI, identifying himself producing the certificate issued by the central authority. 4. All verification of the certificate should be verified referring to the central authority. 5. The customer has to produce the certificate to the FI whenever he/she would like to do a transaction. The FI may check for subscription of the customer and verify the credentials referring to the central authority. Of course, the availability, integrity and confidentiality of the system has to be considered for an ideal process such as above. However, with right technology and prevention mechanism in place, I believe such a system may be possible. Think about an "International Passport" with which you can travel to any country. However, your passport require an entry visa (subscription) to the destination country. This way I avoid travelling with multiple passport (for person with multiple citizenship). Regards, Shaheen Nasirudheen JPMorgan ACCESS, Portal Security ----------------------------------- This message may contain legally privileged and/or confidential information. If you are not the intended recipient(s), or the employee or agent responsible for delivery of this message to the intended recipient(s), you are hereby notified that any dissemination, distribution or copying of this message is strictly prohibited. If you have received this message in error, please immediately notify the sender and delete this e-mail message from your computer. Arshad Noor <arshad.noor@stron To: Stephen Kent <kent@bbn.com> gauth.com> cc: Shaheen Nasirudheen/JPMCHASE@JPMCHASE, PKIX list <ietf-pkix@imc.org> 04/02/2004 04:39 Subject: Re: PKI International Consortium PM I would concur with you, Steve, that a single certificate that serves all purposes, is neither practical nor desirable. (Although I must confess to occassionally dreaming of such a utopian environment, sometimes). However, I believe, it is reasonable - assuming appropriate policy, process, implementation and most importantly, cooperation - to have industry-specific identities that may serve us all better. ("Identity Firewalls" - http://www.strongauth.com/newsletters/2003Jan17.html). Companies waste far too much time and money today, building duplicate identity infrastructures - and consequently tying their own hands with context-sensitive identities - because it appears to be the path of least resistance to them. But as the cost of identity theft & of managing those numerous identity infrastructures surpasses the perceived savings from using this path of least resistance, companies will be forced to rethink that strategy. Arshad Noor StrongAuth, Inc. ----- Original Message ----- From: Stephen Kent <kent@bbn.com> Date: Friday, April 2, 2004 8:47 am Subject: Re: PKI International Consortium > > At 10:57 AM -0500 4/2/04, Shaheen.Nasirudheen@chase.com wrote: > >Hello everyone, > > > >I appreciate your feedback and most of the replies were referring to > >identrus.com . My basic concern is from a customer's point of > view. If I > >have a digital certificate issued by a single authority that is > considered>trusted internationally by all financial as well as > other commercial > >institutions, then I do not require to have a certificate for > Institution>-1 and another for Institution -2. Do we have > something in place that takes > >of this issue. I would be happy to carry and protect that one > certificate>which is trusted by everyone. > > > >Thank you, > > > >Shaheen Nasirudheen > >JPMorgan ACCESS, Portal Security > >978 805 1815 > > > > The notion of the one cert that is good for everything is probably > never going to be a reality, fortunately. Note there there are no > physical credentials that have this property. Why would you > believe > that digital credentials could overcome the organizational > obstacles > that contribute to the existence of context-limited credentials? > Moreover, consider the awful consequences associated with a > compromise of the private key associated with such a cert, if it > existed. > > Steve > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i34B4feA087179; Sun, 4 Apr 2004 04:04:41 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i34B4f6u087178; Sun, 4 Apr 2004 04:04:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from nala.ctima.uma.es (nala.ctima.uma.es [150.214.57.23]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i34B4dIP087168 for <ietf-pkix@imc.org>; Sun, 4 Apr 2004 04:04:40 -0700 (PDT) (envelope-from amg@lcc.uma.es) Received: from nala.ctima.uma.es (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id B54052E92 for <ietf-pkix@imc.org>; Sun, 4 Apr 2004 13:04:35 +0200 (CEST) Received: from sol10.lcc.uma.es (sol10.lcc.uma.es [150.214.108.1]) by nala.ctima.uma.es (Postfix) with ESMTP id 8090C2E99 for <ietf-pkix@imc.org>; Sun, 4 Apr 2004 13:04:35 +0200 (CEST) Received: from Debug by sol10.lcc.uma.es (8.8.8+Sun/SMI-SVR4) id NAA13343; Sun, 4 Apr 2004 13:02:46 +0200 (MET DST) Message-Id: <200404041102.NAA13343@sol10.lcc.uma.es> To: PKIX list <ietf-pkix@imc.org> Cc: amg@lcc.uma.es From: amg@lcc.uma.es Subject: Re: PKI International Consortium Date: Sun, 4 Apr 2004 13:02:47 MET X-Mailer: Endymion MailMan Standard Edition v3.0.33 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Hi, > If a relying party needs to know that I possess certain attributes, and > if I can present an "Attribute Certificate" that convinces them that I > do indeed possess those attributes, then what purpose is served by also > having me present an "Identity Certificate"? You are completely right, Eric. There are many situations that require the knowledge of certain attributes but do not require knowledge of identity. For instance, accesing the Playboy should require knowledge of the user being over 18, but no identity information should be revealed. The paragraph about X.509 was extracted from a paper on interoperable access control for digital libraries [1]. In that paper we defend the idea of using no identity, or at least making the authorization usable without identity. This paragraph is also extracted from [1]: "Most of current access control schemes base their authorization approaches on locally-issued credentials that are linked to user identities. This type of credentials present many drawbacks. Among them we highlight: (a) they are not interoperable; (b) credentials for the same attribute are issued many times for each user, what introduces management and inconsistency problems; (c) credentials are issued by the Digital Library administrator, however, in most cases, the administrator does not have enough information or resources to establish trustworthy credentials; and (d) they are dependent on user identity. In practice, it is frequent that the identity of the user is not relevant for the access decision. Sometimes it is even desirable that the identity is not considered or revealed. Furthermore, in systems based on identity, the lack of a global authentication infrastructure (a global Public Key Infrastructure, PKI) forces the use of local authentication schemes. " So, again, in the design of Identity Certificates we should concentrate on Identity issues, and on the needs of systems requiring identification. Trying to use Identity Certificates for other uses is wrong. Antonio Maña. ------- [1] Yagüe, M.I., Maña, A., López, J., Pimentel, E., Troya, J.M. A Secure Solution for Commercial Digital Libraries. Online Information Review Journal, Vol. 27 Issue 3, pp. 147-159, Emerald, June 2003. > > There are, however, reasons to have more than one identity certificate, but > > these are related to privacy, anonymity and sometimes legal reasons. > > And I'm considering the possibility that there might be reasons to have > fewer than one identity certificate. > > > Eric Norman > > "Congress shall make no law restricting the size of integers > that may be multiplied together, or the number of times that > an integer may be multiplied by itself, or the modulus by > which an integer may be reduced". > > ------------------------------------------------------ Mensaje enviado desde el Servidor de Correo del Departamento de Lenguajes y Ciencias de la Computacion de la Universidad de Malaga ------------------------------------------------------ Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i33KZl0C069269; Sat, 3 Apr 2004 12:35:47 -0800 (PST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i33KZlJc069268; Sat, 3 Apr 2004 12:35:47 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from imap1.doit.wisc.edu (imap1.doit.wisc.edu [144.92.9.75]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i33KZk8W069262 for <ietf-pkix@imc.org>; Sat, 3 Apr 2004 12:35:47 -0800 (PST) (envelope-from ejnorman@doit.wisc.edu) Received: from [128.104.19.109] (HELO holstein.doit.wisc.edu) by imap1.doit.wisc.edu (CommuniGate Pro SMTP 3.5.9) with ESMTP-TLS id 37760146 for ietf-pkix@imc.org; Sat, 03 Apr 2004 14:30:20 -0600 Date: Sat, 3 Apr 2004 14:35:50 -0600 (CST) From: Eric Norman <ejnorman@doit.wisc.edu> To: PKIX list <ietf-pkix@imc.org> Subject: Re: PKI International Consortium In-Reply-To: <200404031056.MAA21125@sol10.lcc.uma.es> Message-ID: <Pine.A41.4.44.0404031406040.18426-100000@holstein.doit.wisc.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> On Sat, 3 Apr 2004 amg@lcc.uma.es wrote: > The newest version of X.509 provides a more suitable solution because it > clearly defines a framework where identity and attribute certificates, > although related, can be independently managed. That recommendation defines > new types of authorities, Attribute Authorities (AA), for the assignment of > privileges. It also defines the Source of Authority (SOA) as the ultimate > authority to assign a set of privileges. Additionally, it provides a > foundation to build a Privilege Management Infrastructure (PMI) that contain a > multiplicity of AAs, SOAs and final users. > > So, summarizing, if the idea is to have "context-sensitive identities", > then "Attribute Certificates" linked to a single "Identity Certificate" are > the best solution. If a relying party needs to know that I possess certain attributes, and if I can present an "Attribute Certificate" that convinces them that I do indeed possess those attributes, then what purpose is served by also having me present an "Identity Certificate"? > There are, however, reasons to have more than one identity certificate, but > these are related to privacy, anonymity and sometimes legal reasons. And I'm considering the possibility that there might be reasons to have fewer than one identity certificate. Eric Norman "Congress shall make no law restricting the size of integers that may be multiplied together, or the number of times that an integer may be multiplied by itself, or the modulus by which an integer may be reduced". Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i33FUUld053494; Sat, 3 Apr 2004 07:30:30 -0800 (PST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i33FUUFm053493; Sat, 3 Apr 2004 07:30:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mdhagsmtp01.firstdata.com (mdhagsmtp01.firstdata.com [198.184.5.21]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i33FUT5x053484 for <ietf-pkix@imc.org>; Sat, 3 Apr 2004 07:30:29 -0800 (PST) (envelope-from lynn.wheeler@firstdata.com) Subject: Re: PKI International Consortium To: Arshad Noor <arshad.noor@strongauth.com> Cc: PKIX list <ietf-pkix@imc.org>, owner-ietf-pkix@mail.imc.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: <OF1C03E577.940E997C-ON87256E6B.00511420@firstdata.com> From: lynn.wheeler@firstdata.com Date: Sat, 3 Apr 2004 08:21:17 -0700 X-MIMETrack: Serialize by Router on MDHAGSMTP/FDMS/FDC(Release 6.0.2CF2|July 23, 2003) at 04/03/2004 10:29:34 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> An example with slight variation on this was some EU directive that electronic payments at point-of-sale should be as anonymous as cash, aka it should be possible to authenticate a transaction for authorization w/o requiring any identification what-so-ever. The issue is that if you have some sort of authentication, aka "something you have", "something you know", "something you are" .... and possibly non-shared-secret based ... it is possible to have an authorization context that just does authentication and no identification is involved. it that case, if there is an authorization context ... with some recorded authentication mechanism ... then the authentication is bound to the authorization context and there is no identification at all. in such a taxonomy .... a certificate represents a static, stale, authorization context for offline environments ... where the public key is the authentication mechanism bound to the authorization context. The authentication mechanism is some form of "something you have" .... based on uniquely having a private key that generates a digital signature that can authenticated with the public key. This is basically the scenario for the relying-party-only certificates from the mid-90s (somewhat resulting from retrentching from the horrible privacy issues of full blown x.509 identity certificates). Note, however, it isn't the certificate that creates the "something you have" associated with the private key, the certificate provides the portable, stale, static authorization context for offline environments. It is equally possible to have an online environment where the public key is bound to an online authorization mechanism and no certificates are involved at all. The online payment point-of-sale transactions with relying-party-only certificates exemplified redundant and superfluous. The transaction was valuable enough that timely and aggregated online information was deemed justified (the benefit of having an online, timely transaction more than offset the incremental cost of having an online transaction) .... but a relying-party-only certificate was provided such that their could be an offline authorization context .... but that was then made redundant and superfluous by having the transaction executed online with an online authorization context. The example I've used for identity is the problems with issuing SSL server domain certificates. The authoritative agency for domain names is the domain name infrastructure. The typical process for obtaining an SSL server domain certificate is to provide very strong identification information to the SSL certificate issuer. The issue is that the domain name infrastructure has some identification information registered for the owner of the domain name. The challenge for the SSL certificate issuer is to be able to perform some level of identification matching from what is provided by the certificate applicant with the identification that is on file for the domain name owner. The reason for the identification operation is that there is no industry-specific authentication. This turns out to be expensive and somewhat error prone. A suggestion, somewhat from the certificate industry is that a public key is registered with the domain name infrastructure when the domain name is registered. Then when somebody applies for a certificate, they digitally sign the operation. The certificate issuer then just needs an online authentication of the digital signature with what is on file with the domain name infrastructure and a very expensive and error-prone identification process is turned into a much simpler industry-specific authentication operation. There is an implied authorization that the owner of the domain name is allowed to obtain an SSL domain certificate for that domain name. Of course, there is possibly a slight Catch-22 for the SSL certificate industry ... that if the certificate industry can make use of online public keys from the domain name infrastructure .... that possibly the rest of the world could also ... leading to possibly eliminating the need for SSL domain name certificates with stale, static certificates binding public keys to domain names. arshad.noor@strongauth.com on 4/2/2004 8:49 pm wrote: I am in complete agreement with you, Lynn. An industry-specifc identity should be designed to perform only a single function - authenticate the holder of the credential. Authorization must ALWAYS be determined by the context that has successfully authenticated the entity - and those authorization rules must always be owned and controlled by the context owner. -- Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i33Ax6gp036794; Sat, 3 Apr 2004 02:59:06 -0800 (PST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i33Ax63N036793; Sat, 3 Apr 2004 02:59:06 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from nala.ctima.uma.es (nala.ctima.uma.es [150.214.57.23]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i33Ax0D4036781 for <ietf-pkix@imc.org>; Sat, 3 Apr 2004 02:59:05 -0800 (PST) (envelope-from amg@lcc.uma.es) Received: from nala.ctima.uma.es (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id D9928321A; Sat, 3 Apr 2004 12:58:49 +0200 (CEST) Received: from sol10.lcc.uma.es (sol10.lcc.uma.es [150.214.108.1]) by nala.ctima.uma.es (Postfix) with ESMTP id BC4F931FB; Sat, 3 Apr 2004 12:58:49 +0200 (CEST) Received: from Debug by sol10.lcc.uma.es (8.8.8+Sun/SMI-SVR4) id MAA21125; Sat, 3 Apr 2004 12:56:58 +0200 (MET DST) Message-Id: <200404031056.MAA21125@sol10.lcc.uma.es> To: Arshad Noor <arshad.noor@strongauth.com>, PKIX list <ietf-pkix@imc.org> From: amg@lcc.uma.es Subject: Re: PKI International Consortium Date: Sat, 3 Apr 2004 12:57:02 MET X-Mailer: Endymion MailMan Standard Edition v3.0.33 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Hi all, In line with Arshad's comments, I think there's some kind of misunderstanding in this discussion. It seems that we're confusing Identity and Attributes (or privileges). It is reasonable to think that one entity (anything that can have a certificate) should have only one Identity (and therefore, only one Identity Certificate). There are reasons that may justify having more than one Identity, and I will come to that later, but let's assume for now that only one Identity is enough. What has been mentioned in this thread is the need to have several (identity) certificates for different purposes. Therefore, each of these "identity certificates" will be "industry-specific" and will have different associated semantics depending on the "industry" or purpose. In this way a "Financial identity certificate" would mean "The cert holder has an associated account in bank X and blah, blah". On the other hand my university certificate would state that I am "professor of the Computer Science Department". Well, in my opinion these are not "identity certificates" but "attribute certificates". The newest version of X.509 provides a more suitable solution because it clearly defines a framework where identity and attribute certificates, although related, can be independently managed. That recommendation defines new types of authorities, Attribute Authorities (AA), for the assignment of privileges. It also defines the Source of Authority (SOA) as the ultimate authority to assign a set of privileges. Additionally, it provides a foundation to build a Privilege Management Infrastructure (PMI) that contain a multiplicity of AAs, SOAs and final users. So, summarizing, if the idea is to have "context-sensitive identities", then "Attribute Certificates" linked to a single "Identity Certificate" are the best solution. There are, however, reasons to have more than one identity certificate, but these are related to privacy, anonymity and sometimes legal reasons. cheers, Antonio Maña. -- ___ /---------------------------------------------------/ | / _ , / /| | / Dr. Antonio Mana Gomez eMail: amg@lcc.uma.es / / | | / amana@acm.org / / | | / http://www.lcc.uma.es/~amg / /__ | | __ /---------------------------------------------------/_// ||_|/ | / University of Malaga. Computer Science Dept. / | / | / E.T.S.I.Informatica. Desp. 3.2.7 / /| | / /| | / Campus de Teatinos. / / | |/ / | | / 29071 MALAGA (SPAIN) / /__| / | | /-------------------------------------------------/_// /|__/ |_| / Phone: (+34) 95 213 71 42 / / _ / Fax: (+34) 95 213 13 97 / / | | / Alternative Phone: (+34) 95 213 41 86 / /___| | /------------------------------------------------/________| > > I am in complete agreement with you, Lynn. An industry-specifc > identity should be designed to perform only a single function - > authenticate the holder of the credential. Authorization must > ALWAYS be determined by the context that has successfully > authenticated the entity - and those authorization rules must > always be owned and controlled by the context owner. > > There are some assumptions I make wrt industry-specific identities > (not exhaustive): > > a) They are used only in an online context; while certificates > can be used perfectly well offline too, the RP has greater > assurances when used only within online contexts. Given the > nature of the always-online Internet and the services that are > being built on top of it, this is not an unreasanable assumption > anymore; > > b) The single credential for the individual will suffice regardless > of the value of the transaction; this implies that the level of > assurance that needs to be built into that credential is high, > thereby increasing the initial cost of issuance. However, since > that cost is spread out across an entire industry (hopefully, for > a very long duration) the actual cost borne by the industry per > credential will be lower than for any individual company within > that industry. The advantage for any given company to sign up to > this model? All companies within that industry have the same level > of assurance in the credential for any level transaction. (There > are other advantages too). > > c) Since the credential is industry-specific, each industry will come > up with its own identifier per entity (besides the unique certificate > DN in the credential) that will be completely unrelated to other > identifiers in other industries. This, coupled with more secure > practices in systems management, data-management & software > development will eliminate the privacy issues. It will make no > difference whether you know my Social Security Number, birthdate > or my mother's maiden name, because modified business practices > (based on these new credentials) will eliminate the value of this > data to identity thieves. Will other data become just as valuable > to the thieves? Almost certainly, but they're also going to have > to steal the physical device that stores my industry-credential > along with the PIN that I carry in my head to unlock the device. > The risk is never eliminated, but the probability of damage is > reduced. > > I do not deny that there are lots of other issues that need to be > addressed (I'm in the middle of writing a much more comprehensive > treatise to discuss these), however, given the losses borne by > consumers (ultimately) - $53B in 2003 according to the FTC > http://www.ftc.gov/opa/2003/09/idtheft.htm, I believe the issue > has become costly enough to consider a radical overhaul of America's > identity infrastructure. > > Arshad Noor > StrongAuth, Inc. > > > > lynn.wheeler@firstdata.com wrote: > > > > > > > > it isn't necessarily just authentication that a relying party may have to > > worry about with regard to the operation that they might be trusting the > > certificate for .... but also things like authorization. the concept of a > > certificate is that the relying party can trust the certificate in an > > offline environment w/o necessarily any recourse to any additional > > information. > > > > the issue of recourse to additional information may because of things like > > > > 1) privacy .... the early x.509 "identity" certificates were found to > > represent signficiant privacy compromise, especially when broadcasting all > > of the place. as a result, there was retrencement to relying-party-only > > certificates .... where it was sufficient to authenticate the entity as > > being authorized to perform some set of operations against some account > > record. > > > > 2) value ... the transaction is of sufficient value and/or complexity that > > it is worthwhile to perform a online transaction (as opposed to an offline > > operation purely relying on the contents of a certificate). > > > > Note, however, that majority of relying-party-only certificates were used > > in operations involving some value and therefor justified an online > > operation with access to timely and/or aggregated information (aka > > sufficient funds to actually cover a financial transaction). > > > > 3) authorization ... the issue may not have anything at all to do with your > > identity, but whether or not you can be authenticated (not identified) as > > being an authorized employee or an authorized individual to perform > > transactions against a specific bank account. Just because I can proov I'm > > John Smith ... isn't sufficient to establish that I'm an authorized > > employee of any specific corporation and therefor entitled to enter an > > employee only area. > > > > It isn't context-sensitive identity infrastructure ... they require > > context-sensitive authorization (although sometimes there is significant > > confusion and institutions build identity infrastructures that are totally > > orthogonal to their need for authenticationa nnd authorization > > infrastructures). > > > > In many of these situations, then stale, static certificates can be totally > > redundant and superfluous ... either because they are providing information > > that has no direct bearing on the operation being performed by the relying > > party and/or because the relying party will be doing an online operation > > with the authoritative agency providing real-time and/or aggregated > > information (not possible with a stale, static, offline certificate). > > > > > > arshad.noor@strongauth.com on 4/2/2004 2:39 pm wrote: > > > > I would concur with you, Steve, that a single certificate that serves all > > purposes, is neither practical nor desirable. (Although I must confess > > to occassionally dreaming of such a utopian environment, sometimes). > > > > However, I believe, it is reasonable - assuming appropriate policy, > > process, implementation and most importantly, cooperation - to have > > industry-specific identities that may serve us all better. ("Identity > > Firewalls" - http://www.strongauth.com/newsletters/2003Jan17.html). > > > > Companies waste far too much time and money today, building > > duplicate identity infrastructures - and consequently tying their own > > hands with context-sensitive identities - because it appears to be the > > path of least resistance to them. But as the cost of identity theft & > > of managing those numerous identity infrastructures surpasses the > > perceived savings from using this path of least resistance, companies > > will be forced to rethink that strategy. > > > > Arshad Noor > > StrongAuth, Inc. > > > > ------------------------------------------------------ Mensaje enviado desde el Servidor de Correo del Departamento de Lenguajes y Ciencias de la Computacion de la Universidad de Malaga ------------------------------------------------------ Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i334MHda037246; Fri, 2 Apr 2004 20:22:17 -0800 (PST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i334MGEu037245; Fri, 2 Apr 2004 20:22:16 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp.cs.auckland.ac.nz (smtp.cs.auckland.ac.nz [130.216.33.151]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i334MDkQ037238 for <ietf-pkix@imc.org>; Fri, 2 Apr 2004 20:22:16 -0800 (PST) (envelope-from pgut001@cs.auckland.ac.nz) Received: from medusa01 (medusa01.cs.auckland.ac.nz [130.216.34.33]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id 4237D3414D; Sat, 3 Apr 2004 16:20:36 +1200 (NZST) Received: from pgut001 by medusa01 with local (Exim 4.30) id 1B9cfj-00063b-Cw; Sat, 03 Apr 2004 16:22:19 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-pkix@imc.org, rbotafogo@certisign.com.br Subject: Re: Re-certification In-Reply-To: <03b501c418fb$9be2da90$be00a8c0@jurujuba> Message-Id: <E1B9cfj-00063b-Cw@medusa01> Date: Sat, 03 Apr 2004 16:22:19 +1200 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> "Rodrigo Botafogo" <rbotafogo@certisign.com.br> writes: >What the Certificate Authority did was: > >- Generated a new key pair; >- Created a new certificate with: i) the same DN as the >expiring CA, ii) the new key and iii) an extended expiration date That's exactly what Verisign did when their root certs expired, AFAIK there were no problems with apps using the certs (provided they got the new certs in time). Most CAs that started operating more recently (the Verisign roots are from 1996) have got around this problem with 10-20 year validity periods, so that whoever authorised this behaviour will have safely retired or moved on to another job by the time it becomes a problem. Peter. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3343GiI036318; Fri, 2 Apr 2004 20:03:16 -0800 (PST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3343GoT036317; Fri, 2 Apr 2004 20:03:16 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3343GUG036311 for <ietf-pkix@imc.org>; Fri, 2 Apr 2004 20:03:16 -0800 (PST) (envelope-from chokhani@orionsec.com) Received: from orionsec.com (localhost [127.0.0.1]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i3343NAt013018 for <ietf-pkix@imc.org>; Fri, 2 Apr 2004 23:03:23 -0500 From: "Santosh Chokhani" <chokhani@orionsec.com> To: <ietf-pkix@imc.org> Subject: RE: Signing Untrusted SCVP? Date: Sat, 3 Apr 2004 00:03:23 -0400 Message-Id: <20040403040323.M36717@orionsec.com> In-Reply-To: <DE909E05406F3340B186DA5A410B05F642A286@mongo.corestreet.com> References: <DE909E05406F3340B186DA5A410B05F642A286@mongo.corestreet.com> X-Mailer: Open WebMail 1.81 20021127 X-OriginatingIP: 69.143.113.169 (chokhani) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Steve: I do not see a particular reason to require a DPD Server to be held to a higher standard then a Directory Server. We do not require signed responses from Directories. Both being stationary servers, are equally prone to hacking. Also, in order to verify the DPD Server signature, the client may get into another problem of obtaining a path for the DPD Server itself, which may not be a circular problem, but will degrade performance > > -----Original Message----- > From: Stephen Kent [mailto:kent@bbn.com] > Sent: Friday, April 02, 2004 4:45 PM > To: Dave Engberg > Cc: ietf-pkix@imc.org > Subject: Re: Signing Untrusted SCVP? > > Dave, > > I agree that one might not want to invest as much effort and money in > securing a DPD server as a DPV server. But that does not necessarily > translate into removing the need for signatures on responses from > such servers. If responses from a DPD server are spoofed, a client > may be subject to a form of DoS attack, as it tries to make use of > bogus certs formed chains intended to maximize the amount of crypto > processing the client does, before realizing that the chain is bad. > Or certs might be returned that conflict with certs from some other DPD > server. Without signed responses it could be very hard to determine > what went wrong and what servers ought to be avoided, based on bad > behavior. > > Steve Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i333nnIG035922; Fri, 2 Apr 2004 19:49:49 -0800 (PST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i333nncu035921; Fri, 2 Apr 2004 19:49:49 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from igw (adsl-63-194-79-229.dsl.snfc21.pacbell.net [63.194.79.229]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i333nnpF035915 for <ietf-pkix@imc.org>; Fri, 2 Apr 2004 19:49:49 -0800 (PST) (envelope-from arshad.noor@strongauth.com) Received: from strongauth.com (athena.noorhome.net [192.168.0.10]) by igw.noorhome.net (iPlanet Messaging Server 5.2 Patch 1 (built Aug 19 2002)) with ESMTP id <0HVK00E8QSJV7F@igw.noorhome.net> for ietf-pkix@imc.org; Fri, 02 Apr 2004 19:33:31 -0800 (PST) Date: Fri, 02 Apr 2004 19:49:49 -0800 From: Arshad Noor <arshad.noor@strongauth.com> Subject: Re: PKI International Consortium In-reply-to: <OFA37833D9.D49AF44C-ON87256E6A.00806885@firstdata.com> To: PKIX list <ietf-pkix@imc.org> Message-id: <406E345D.4010806@strongauth.com> Organization: StrongAuth, Inc. MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) References: <OFA37833D9.D49AF44C-ON87256E6A.00806885@firstdata.com> Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> I am in complete agreement with you, Lynn. An industry-specifc identity should be designed to perform only a single function - authenticate the holder of the credential. Authorization must ALWAYS be determined by the context that has successfully authenticated the entity - and those authorization rules must always be owned and controlled by the context owner. There are some assumptions I make wrt industry-specific identities (not exhaustive): a) They are used only in an online context; while certificates can be used perfectly well offline too, the RP has greater assurances when used only within online contexts. Given the nature of the always-online Internet and the services that are being built on top of it, this is not an unreasanable assumption anymore; b) The single credential for the individual will suffice regardless of the value of the transaction; this implies that the level of assurance that needs to be built into that credential is high, thereby increasing the initial cost of issuance. However, since that cost is spread out across an entire industry (hopefully, for a very long duration) the actual cost borne by the industry per credential will be lower than for any individual company within that industry. The advantage for any given company to sign up to this model? All companies within that industry have the same level of assurance in the credential for any level transaction. (There are other advantages too). c) Since the credential is industry-specific, each industry will come up with its own identifier per entity (besides the unique certificate DN in the credential) that will be completely unrelated to other identifiers in other industries. This, coupled with more secure practices in systems management, data-management & software development will eliminate the privacy issues. It will make no difference whether you know my Social Security Number, birthdate or my mother's maiden name, because modified business practices (based on these new credentials) will eliminate the value of this data to identity thieves. Will other data become just as valuable to the thieves? Almost certainly, but they're also going to have to steal the physical device that stores my industry-credential along with the PIN that I carry in my head to unlock the device. The risk is never eliminated, but the probability of damage is reduced. I do not deny that there are lots of other issues that need to be addressed (I'm in the middle of writing a much more comprehensive treatise to discuss these), however, given the losses borne by consumers (ultimately) - $53B in 2003 according to the FTC http://www.ftc.gov/opa/2003/09/idtheft.htm, I believe the issue has become costly enough to consider a radical overhaul of America's identity infrastructure. Arshad Noor StrongAuth, Inc. lynn.wheeler@firstdata.com wrote: > > > > it isn't necessarily just authentication that a relying party may have to > worry about with regard to the operation that they might be trusting the > certificate for .... but also things like authorization. the concept of a > certificate is that the relying party can trust the certificate in an > offline environment w/o necessarily any recourse to any additional > information. > > the issue of recourse to additional information may because of things like > > 1) privacy .... the early x.509 "identity" certificates were found to > represent signficiant privacy compromise, especially when broadcasting all > of the place. as a result, there was retrencement to relying-party-only > certificates .... where it was sufficient to authenticate the entity as > being authorized to perform some set of operations against some account > record. > > 2) value ... the transaction is of sufficient value and/or complexity that > it is worthwhile to perform a online transaction (as opposed to an offline > operation purely relying on the contents of a certificate). > > Note, however, that majority of relying-party-only certificates were used > in operations involving some value and therefor justified an online > operation with access to timely and/or aggregated information (aka > sufficient funds to actually cover a financial transaction). > > 3) authorization ... the issue may not have anything at all to do with your > identity, but whether or not you can be authenticated (not identified) as > being an authorized employee or an authorized individual to perform > transactions against a specific bank account. Just because I can proov I'm > John Smith ... isn't sufficient to establish that I'm an authorized > employee of any specific corporation and therefor entitled to enter an > employee only area. > > It isn't context-sensitive identity infrastructure ... they require > context-sensitive authorization (although sometimes there is significant > confusion and institutions build identity infrastructures that are totally > orthogonal to their need for authenticationa nnd authorization > infrastructures). > > In many of these situations, then stale, static certificates can be totally > redundant and superfluous ... either because they are providing information > that has no direct bearing on the operation being performed by the relying > party and/or because the relying party will be doing an online operation > with the authoritative agency providing real-time and/or aggregated > information (not possible with a stale, static, offline certificate). > > > arshad.noor@strongauth.com on 4/2/2004 2:39 pm wrote: > > I would concur with you, Steve, that a single certificate that serves all > purposes, is neither practical nor desirable. (Although I must confess > to occassionally dreaming of such a utopian environment, sometimes). > > However, I believe, it is reasonable - assuming appropriate policy, > process, implementation and most importantly, cooperation - to have > industry-specific identities that may serve us all better. ("Identity > Firewalls" - http://www.strongauth.com/newsletters/2003Jan17.html). > > Companies waste far too much time and money today, building > duplicate identity infrastructures - and consequently tying their own > hands with context-sensitive identities - because it appears to be the > path of least resistance to them. But as the cost of identity theft & > of managing those numerous identity infrastructures surpasses the > perceived savings from using this path of least resistance, companies > will be forced to rethink that strategy. > > Arshad Noor > StrongAuth, Inc. > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i330C4GD023403; Fri, 2 Apr 2004 16:12:04 -0800 (PST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i330C4cN023402; Fri, 2 Apr 2004 16:12:04 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mdhagsmtp01.firstdata.com (mdhagsmtp01.firstdata.com [198.184.5.21]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i330C35f023377 for <ietf-pkix@imc.org>; Fri, 2 Apr 2004 16:12:03 -0800 (PST) (envelope-from lynn.wheeler@firstdata.com) Subject: Re: PKI International Consortium To: Shaheen.Nasirudheen@chase.com Cc: "Anders Rundgren" <anders.rundgren@telia.com>, Arshad Noor <arshad.noor@strongauth.com>, PKIX list <ietf-pkix@imc.org>, Stephen Kent <kent@bbn.com>, owner-ietf-pkix@mail.imc.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: <OF97D8D260.89300F8C-ON87256E6A.0082C4E6@firstdata.com> From: lynn.wheeler@firstdata.com Date: Fri, 2 Apr 2004 17:11:46 -0700 X-MIMETrack: Serialize by Router on MDHAGSMTP/FDMS/FDC(Release 6.0.2CF2|July 23, 2003) at 04/02/2004 07:11:11 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> The arpanet was a traditional, homogeneous network ... that happen to be a packet-switch implementation rather than circuit-switch implementation. Note however, it was NOT an internet. It corresponded much closer to the standard OSI model of homogeneous infrastructure (but having a packet orientation rather than a circuit orientation). I've claimed that one of the reasons that the internal network was larger than the arpaent for all of that period ... was that the internal network had effectively the equivalent of a gateway built into every node ... allowing support for heterogenous networking. The great switch-over from arpanet to internet occured on 1/1/83 ... with the introduction of internetworking .... a "layer" that doesn't even exist in the OSI model (sitting somewhere between layer3/networking and layer4/transport). At that time of the switchover the arpanet was around 250 nodes and the internal network was nearly 1000 nodes. The combination of internetworking, heterogeneous networking support, gateways, and the appearance of PCs and workstations as internet network nodes resulted in the internet eventually exceeding the number of nodes on the internal network sometime around mid-85. misc. past posts related to arpanet, csnet, nsfnet, internet, internet switch-over and the internal network: http://www.garlic.com/~lynn/internet.net a story not related in the above was some corporate type doing technology audit in the late 70s and being told about the size of the internal network. the person supposedly wrote a report stating that it was impossible ... because to build a network of that size using traditional homogeneous networking technology (common at the time) would have required more people total than had been working for the corporation over the previous ten years. misc. past posts related to OSI, arpanet, iso, etc: http://www.garlic.com/~lynn/subnetwork.html#xtphsp the above mentions another issue w/OSI. attempting to get HSP (high-speed protocol) work item in X3S3.3 (iso chartered us standards organization responsible for networking and transport layer standards). The problem was that ISO had a rule that there couldn't be standards work on protocols in this area that violated OSI. HSP was going to go directly from level4/transport to the MAC interface. This violated OSI in two respects 1) it bypassed the level3/level4 interface and 2) it interfaced to MAC layer. LANs/WANs/MAC are a violation of OSI with the MAC layer sitting somewhere in the middle of layer3/networking. Because of the OSI violation rule, X3S3.3 rejected the work item. in late '69, i did get involved in a project as an undergraduate building a telecommunication controller using an Interdata/3. this resulted in later getting blaimed for helping create the plug-compatible manufactoring (PCM) controller business: http://www.garlic.com/~lynn/subtopic.html#360pcm shaheen.nasirudheen@chase.com on 4/2/2004 3:37 pm wrote: Hello everyone, Quote from bbn.com : "In 1968, the Advanced Research Projects Agency (ARPA) sent out a Request for Quotation (RFQ) to build a network of four Interface Message Processors (IMPs). Many of the large computer and telecommunications organizations didn't even respond--they thought it was impossible. " - http://bbn.com/arpanet/index.html. If the pioneers believed that "Internet" is impossible, then I dont think we would enjoy sending these emails today. -- Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i32NmXor021818; Fri, 2 Apr 2004 15:48:33 -0800 (PST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i32NmX7T021817; Fri, 2 Apr 2004 15:48:33 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mdhagsmtp01.firstdata.com (mdhagsmtp01.firstdata.com [198.184.5.21]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i32NmUrh021809 for <ietf-pkix@imc.org>; Fri, 2 Apr 2004 15:48:31 -0800 (PST) (envelope-from lynn.wheeler@firstdata.com) Subject: Re: PKI International Consortium To: Arshad Noor <arshad.noor@strongauth.com> Cc: PKIX list <ietf-pkix@imc.org>, Stephen Kent <kent@bbn.com>, owner-ietf-pkix@mail.imc.org, Shaheen.Nasirudheen@chase.com X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: <OFA37833D9.D49AF44C-ON87256E6A.00806885@firstdata.com> From: lynn.wheeler@firstdata.com Date: Fri, 2 Apr 2004 16:46:04 -0700 X-MIMETrack: Serialize by Router on MDHAGSMTP/FDMS/FDC(Release 6.0.2CF2|July 23, 2003) at 04/02/2004 06:47:39 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> it isn't necessarily just authentication that a relying party may have to worry about with regard to the operation that they might be trusting the certificate for .... but also things like authorization. the concept of a certificate is that the relying party can trust the certificate in an offline environment w/o necessarily any recourse to any additional information. the issue of recourse to additional information may because of things like 1) privacy .... the early x.509 "identity" certificates were found to represent signficiant privacy compromise, especially when broadcasting all of the place. as a result, there was retrencement to relying-party-only certificates .... where it was sufficient to authenticate the entity as being authorized to perform some set of operations against some account record. 2) value ... the transaction is of sufficient value and/or complexity that it is worthwhile to perform a online transaction (as opposed to an offline operation purely relying on the contents of a certificate). Note, however, that majority of relying-party-only certificates were used in operations involving some value and therefor justified an online operation with access to timely and/or aggregated information (aka sufficient funds to actually cover a financial transaction). 3) authorization ... the issue may not have anything at all to do with your identity, but whether or not you can be authenticated (not identified) as being an authorized employee or an authorized individual to perform transactions against a specific bank account. Just because I can proov I'm John Smith ... isn't sufficient to establish that I'm an authorized employee of any specific corporation and therefor entitled to enter an employee only area. It isn't context-sensitive identity infrastructure ... they require context-sensitive authorization (although sometimes there is significant confusion and institutions build identity infrastructures that are totally orthogonal to their need for authenticationa nnd authorization infrastructures). In many of these situations, then stale, static certificates can be totally redundant and superfluous ... either because they are providing information that has no direct bearing on the operation being performed by the relying party and/or because the relying party will be doing an online operation with the authoritative agency providing real-time and/or aggregated information (not possible with a stale, static, offline certificate). arshad.noor@strongauth.com on 4/2/2004 2:39 pm wrote: I would concur with you, Steve, that a single certificate that serves all purposes, is neither practical nor desirable. (Although I must confess to occassionally dreaming of such a utopian environment, sometimes). However, I believe, it is reasonable - assuming appropriate policy, process, implementation and most importantly, cooperation - to have industry-specific identities that may serve us all better. ("Identity Firewalls" - http://www.strongauth.com/newsletters/2003Jan17.html). Companies waste far too much time and money today, building duplicate identity infrastructures - and consequently tying their own hands with context-sensitive identities - because it appears to be the path of least resistance to them. But as the cost of identity theft & of managing those numerous identity infrastructures surpasses the perceived savings from using this path of least resistance, companies will be forced to rethink that strategy. Arshad Noor StrongAuth, Inc. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i32NTHbo020845; Fri, 2 Apr 2004 15:29:17 -0800 (PST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i32NTHdq020844; Fri, 2 Apr 2004 15:29:17 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i32NTHsS020838 for <ietf-pkix@imc.org>; Fri, 2 Apr 2004 15:29:17 -0800 (PST) (envelope-from chokhani@orionsec.com) Received: from orionsec.com (localhost [127.0.0.1]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i32NTMAt007128 for <ietf-pkix@imc.org>; Fri, 2 Apr 2004 18:29:22 -0500 From: "Santosh Chokhani" <chokhani@orionsec.com> To: <ietf-pkix@imc.org> Subject: Re: Re-certification Date: Fri, 2 Apr 2004 19:29:22 -0400 Message-Id: <20040402232922.M8919@orionsec.com> In-Reply-To: <03b501c418fb$9be2da90$be00a8c0@jurujuba> References: <03b501c418fb$9be2da90$be00a8c0@jurujuba> X-Mailer: Open WebMail 1.81 20021127 X-OriginatingIP: 69.143.113.169 (chokhani) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> The best thing to do is for the new CA to pick up with the serial number wher the old CA left off and for both CAs ti produce the CRL for all certificates issued by both. I do not know if your product will support the capabilities required to do that. On Fri, 2 Apr 2004 18:44:00 -0300, Rodrigo Botafogo wrote > I'm new to this group, so sorry if I do not follow the groups culture > somehow. I have a question regarding re-certification: > > In Brazil, a Certificate Authority had one of its CA expiring. > According to the Brazilian legislation, a CA cannot re-certify its > key, that is, it cannot extend the certificates expiration date for > the same key. > > What the Certificate Authority did was: > > - Generated a new key pair; > - Created a new certificate with: i) the same DN as the > expiring CA, ii) the new key and iii) an extended expiration date > > First of all, is this legal according to X.509? If not, where do we find > that on the norm? > > If this is legal, how are the CRLs supposed to work in this case. Note > what happens: > > 1) There are two CA with certificates with the same DN. Lets call > them OLD and NEW. > 2) Lets call the CRLs generated CRLOld and CRLNew > 3) When CRLNew is issued, since the DN of OLD and NEW are the > same, all revoked certificates from OLD and NEW are stored in CRLNew. > This is the software's behavior. Question: is this ok according to > X.509? > 4) Lets suppose that CRLOld had the following certificates {1, > 3, 5} 5) Lets suppose that a new cert 8 is revoked. CRLNew > will have {1, 3, 5, 8} 6) When a third party receives an email > signed with Cert 1 what should it do? It will look at CRLNew, but > CRLNew is not signed with the same private key than Cert 1? > Question: Should the third party still say that the cert is invalid > or should it say that it could not verify the status of the > certificate? We made some tests and IE reported that it could not > verify the status of the certificate and did not show any warnings, > even though the certificate was expired. > > I'd appreciate any help on this. It seems to me that all that was > described should not be legal according to X.509, but this is an actual > case that is happening with the CA in Brazil and I couldn't find in the > norms where it is said that this is illegal. > > Thanks, > > > > Rodrigo Botafogo Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i32McDX4017025; Fri, 2 Apr 2004 14:38:13 -0800 (PST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i32McDHZ017024; Fri, 2 Apr 2004 14:38:13 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from emampe19.jpmchase.com (mailms.chase.com [170.148.48.205]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i32McBkC017015 for <ietf-pkix@imc.org>; Fri, 2 Apr 2004 14:38:12 -0800 (PST) (envelope-from Shaheen.Nasirudheen@chase.com) Received: J.P. Morgan Chase & Co.; Fri, 2 Apr 2004 17:37:46 -0500 (EST); Message Subject: Re: PKI International Consortium To: PKIX list <ietf-pkix@imc.org> Cc: Stephen Kent <kent@bbn.com>, Arshad Noor <arshad.noor@strongauth.com>, "Anders Rundgren" <anders.rundgren@telia.com> X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: <OF169CF168.3D170BCC-ON85256E6A.0078DDD6@chase.com> From: Shaheen.Nasirudheen@chase.com Date: Fri, 2 Apr 2004 17:37:04 -0500 X-MIMETrack: Serialize by Router on EMAMPE12/CHASE(Release 5.0.8 |June 18, 2001) at 04/02/2004 05:33:17 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Hello everyone, Quote from bbn.com : "In 1968, the Advanced Research Projects Agency (ARPA) sent out a Request for Quotation (RFQ) to build a network of four Interface Message Processors (IMPs). Many of the large computer and telecommunications organizations didn't even respond--they thought it was impossible. " - http://bbn.com/arpanet/index.html. If the pioneers believed that "Internet" is impossible, then I dont think we would enjoy sending these emails today. Anyway, consider the following: 1. A central authority issues and maintains certificates for the customers of FI. The central authority prescribes a set of standards and regulations on creation, issuance and maintenance of the certificate. 2. The FI or independent agents may issue the certificate on behalf of the central authority. However, the certificate issued to the customer should not have any direct relation to the FI (Financial Institution). 3. The customer may subscribe for the services of an FI, identifying himself producing the certificate issued by the central authority. 4. All verification of the certificate should be verified referring to the central authority. 5. The customer has to produce the certificate to the FI whenever he/she would like to do a transaction. The FI may check for subscription of the customer and verify the credentials referring to the central authority. Of course, the availability, integrity and confidentiality of the system has to be considered for an ideal process such as above. However, with right technology and prevention mechanism in place, I believe such a system may be possible. Think about an "International Passport" with which you can travel to any country. However, your passport require an entry visa (subscription) to the destination country. This way I avoid travelling with multiple passport (for person with multiple citizenship). Regards, Shaheen Nasirudheen JPMorgan ACCESS, Portal Security ----------------------------------- This message may contain legally privileged and/or confidential information. If you are not the intended recipient(s), or the employee or agent responsible for delivery of this message to the intended recipient(s), you are hereby notified that any dissemination, distribution or copying of this message is strictly prohibited. If you have received this message in error, please immediately notify the sender and delete this e-mail message from your computer. Arshad Noor <arshad.noor@stron To: Stephen Kent <kent@bbn.com> gauth.com> cc: Shaheen Nasirudheen/JPMCHASE@JPMCHASE, PKIX list <ietf-pkix@imc.org> 04/02/2004 04:39 Subject: Re: PKI International Consortium PM I would concur with you, Steve, that a single certificate that serves all purposes, is neither practical nor desirable. (Although I must confess to occassionally dreaming of such a utopian environment, sometimes). However, I believe, it is reasonable - assuming appropriate policy, process, implementation and most importantly, cooperation - to have industry-specific identities that may serve us all better. ("Identity Firewalls" - http://www.strongauth.com/newsletters/2003Jan17.html). Companies waste far too much time and money today, building duplicate identity infrastructures - and consequently tying their own hands with context-sensitive identities - because it appears to be the path of least resistance to them. But as the cost of identity theft & of managing those numerous identity infrastructures surpasses the perceived savings from using this path of least resistance, companies will be forced to rethink that strategy. Arshad Noor StrongAuth, Inc. ----- Original Message ----- From: Stephen Kent <kent@bbn.com> Date: Friday, April 2, 2004 8:47 am Subject: Re: PKI International Consortium > > At 10:57 AM -0500 4/2/04, Shaheen.Nasirudheen@chase.com wrote: > >Hello everyone, > > > >I appreciate your feedback and most of the replies were referring to > >identrus.com . My basic concern is from a customer's point of > view. If I > >have a digital certificate issued by a single authority that is > considered>trusted internationally by all financial as well as > other commercial > >institutions, then I do not require to have a certificate for > Institution>-1 and another for Institution -2. Do we have > something in place that takes > >of this issue. I would be happy to carry and protect that one > certificate>which is trusted by everyone. > > > >Thank you, > > > >Shaheen Nasirudheen > >JPMorgan ACCESS, Portal Security > >978 805 1815 > > > > The notion of the one cert that is good for everything is probably > never going to be a reality, fortunately. Note there there are no > physical credentials that have this property. Why would you > believe > that digital credentials could overcome the organizational > obstacles > that contribute to the existence of context-limited credentials? > Moreover, consider the awful consequences associated with a > compromise of the private key associated with such a cert, if it > existed. > > Steve > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i32MY0Zr016718; Fri, 2 Apr 2004 14:34:00 -0800 (PST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i32MY01u016717; Fri, 2 Apr 2004 14:34:00 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail2.atl.registeredsite.com (nobody@mail2.atl.registeredsite.com [64.224.219.76]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i32MXxXC016711 for <ietf-pkix@imc.org>; Fri, 2 Apr 2004 14:34:00 -0800 (PST) (envelope-from egerck@nma.com) Received: from taurus.hosting4u.net (taurus.hosting4u.net [209.35.191.122]) by mail2.atl.registeredsite.com (8.12.8/8.12.8) with ESMTP id i32MXwV1000757; Fri, 2 Apr 2004 22:33:58 GMT Received: from nma.com ([63.204.17.85]) by taurus.hosting4u.net ; Fri, 02 Apr 2004 16:33:57 -0600 Message-ID: <406DE8AD.BC0DA38@nma.com> Date: Fri, 02 Apr 2004 14:26:53 -0800 From: Ed Gerck <egerck@nma.com> X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Stephen Kent <kent@bbn.com> CC: ietf-pkix@imc.org Subject: Re: Current status of CRL validation ? References: <20040323103412.GA23286@cryptolog.com> <004f01c410dc$2c0681d0$df294d0c@hq.orionsec.com> <20040323142525.GA27672@cryptolog.com> <p06020406bc861b0a4627@[128.33.244.157]> <406A0839.14F7C3A1@nma.com> <p06020401bc909a0b8ec1@[128.89.89.75]> <406B0593.FD2E1F6B@nma.com> <p06020408bc90bbc275a7@[128.89.89.75]> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Stephen Kent wrote: > > Ed, > > I really should have asked the context in which you were referring to > an RP's reliance on revocation status info. I welcome this clarification. Saying that the RP "relies" is not enough. The context of an RP's reliance is what provides the RP's justification for reliance. It's easy to say that an RP's justification of reliance is a matter of need. But this is not quantitative. If we are to make some progress in this, we need to define those needs as degrees or levels -- i.e., in terms that we can identify their differences and their required revocation models. For starters, I'd suggest the following reliance levels (from weaker to stronger): (0) What the RP relies upon without any consideration of "why" and without any recourse (open reliance). (1) What the RP relies upon without any consideration of "why" (actual reliance). (2) What the RP relies upon because it is presented by a party accepted by the truster for that purpose (authorization reliance). (3) What the RP as a reasonable man might do, with all prudence that might be reasonable to use (reasonable reliance). In other words, "what would be reasonable for a prudent man to do under the circumstances". (4) What can be justified by the RP after an examination of the facts presented (justified reliance). As usually defined by a CA's CPS, revocation information provided by a CA is level (0). The RP has no contract relationship with the CA and is denied any warranties and rights to recourse. The revocation information is provided by the CA to an RP "as is". Therefore, it does not help much to talk about CRL issue dates and RP reliance if the RP is stuck in level (0). No matter how frequent we make those CRL updates (and how much excess traffic we impose on the RP), that's why I said that the RP is unable to measure with any desired confidence (i.e., desired by the RP) whether a cert is revoked or not. The RP can hope to move to levels (1) and (2) when using a Trusted Responder during certificate reliance (i.e., whether the cert has been revoked or not) under CRLs or OCSPs. However, as I said before, one cannot rely upon them for other than their value as a representation of the issuer CA revocation management as expressed in the issuer CA own terms and rules -- which are in level (0). Thus, even though a X.509/PKIX cert is either revoked or not (and, yes, this is strictly enforceable in X.509/PKIX), X.509/PKIX is unable to allow a RP to measure with any desired confidence whether the cert is in fact revoked or not. The real problem is to make the cert unusable when revoked. > If the RP is validating a > signature for NR purposes, then the RP is nominally protected if he > waits until the "next" CRL is issued before he acts on the signed > object. The "next" CRL is usually one or two weeks away. Hardly worth waiting for in an e-commerce transaction -- may as well fly there. And if the cycle is shorter, traffic shoots up. > The CRL issuer is the only game in town re authoritative info > on the revocation status of a cert. AN RP is, by definition, a > "relying" party and he relies on the cert and CRL issuer(s) to > provide this status data when they have said it becomes available. A relying party to whom? If in level (0), to himself. > if > the RP cannot tolerate the wait, tough luck. The wait would be one to two weeks today. And for an information without any reliance except as an open statement. Tough luck indeed ;-) > If the RP is using a signature in an access control context, then the > problem is often different. For access control purposes, one usually > will not have the luxury of waiting for the next CRL to determine > revocation status, and even use of OCSP may not help, as many OCSP > servers are driven by CRLs. But, this is not an X.509 problem per se. > If the operator of an access control systems wants to ensure that a > user's privileges are revoked quickly, then the best way to do that > is to change the ACLs associated with the resources being protected, > or to push a hot list to each resource access manager. When certs are > used to verify identity in support of access control, these general > rules apply, and they are not fundamentally different than if one had > chosen to use passwords for user authentication. If X.509 revocation information could be trusted in this context, access control would not have that security gap. > >We have struggled with this passage before. Thanks for helping me > >clarify it now. In short, I mean that revocation by reference (i.e., a > >X.509 reference that X is revoked) does not revoke anything. Actual > >revocation, OTOH, would make it impossible to use the cert -- even if > >a reference about its revocation is not available. > > One cannot, in general, make "it impossible to use the cert" but one > can make a cert unusable in a given context. But that is not > surprising. In many systems with capability-like properties, > revocation effected by seizing an access token is often infeasible. Seizing the token is not the only way to make the token unusable. > If I have a keyed padlock on a locker, I can change the lock to > effect revocation of access privileges for the holders of keys, and > reissue new keys for the new lock to the folks I want to authorize. > Do I know that the keys that are out there will not be able to open > any other padlocks? Not really/ There may have been another padlock > that would accept the same keys and I don't now, nor can I prevent > the use of the keys in that padlock. Even though I usually dislike physical metaphors for crypto locks/keys, I think that you surely can prevent the keys that are out there to open any other padlocks. It's called key management and is the same with crypto locks/keys. > So, I'm afraid I don't find your clarification helpful. Maybe we're > still just missing a concisely stated context for the comment. Revoking by reference (the current method with CRLs and OCSPs) has some unsolved and unsolvable problems, and does not solve the real problem. The real problem is to make the cert unusable when revoked. For that, one should also not need to trust user intervention (even to update software, as some certs have been revoked). Cheers, Ed Gerck Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i32MXMgq016676; Fri, 2 Apr 2004 14:33:22 -0800 (PST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i32MXMX8016675; Fri, 2 Apr 2004 14:33:22 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mongo.corestreet.com (mongo.corestreet.com [68.162.232.130]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i32MXLUQ016667 for <ietf-pkix@imc.org>; Fri, 2 Apr 2004 14:33:22 -0800 (PST) (envelope-from dengberg@corestreet.com) X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Signing Untrusted SCVP? Date: Fri, 2 Apr 2004 17:32:30 -0500 Message-ID: <DE909E05406F3340B186DA5A410B05F642A286@mongo.corestreet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Signing Untrusted SCVP? thread-index: AcQY+9PjHSPkaf/0QsudW+srer5kuwABUDWA From: "Dave Engberg" <dengberg@corestreet.com> To: "Stephen Kent" <kent@bbn.com> Cc: <ietf-pkix@imc.org> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i32MXMUQ016670 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> An attacker with the ability to intercept your SCVP calls and send back spoofed responses has a more obvious way to deny service ... More seriously, I think we agree that there should absolutely be an option in the protocol to allow a client to request a signed response, and for the server to provide it. But by making this an absolute hard requirement for every client-server pair, you are permanently preventing the SCVP protocol from being used with any caching or pregeneration at the server level when used for pure DPD, and you're adding 150 bytes and 50 ms onto every response (plus $20k for a FIPS HSM, if you're serious). Think of pure DPD as an optimized mechanism for doing certificate lookups, as an alternative to LDAP. Previously, PKI standards have not forced every LDAP lookup to use authenticated SSL tunnels, because most clients derive their security from the signatures on the retrieved objects rather than the transport mechanism. The gratuitous requirement for SSL on every LDAP query would just further reduce performance and increase costs for PKI deployments. -----Original Message----- From: Stephen Kent [mailto:kent@bbn.com] Sent: Friday, April 02, 2004 4:45 PM To: Dave Engberg Cc: ietf-pkix@imc.org Subject: Re: Signing Untrusted SCVP? Dave, I agree that one might not want to invest as much effort and money in securing a DPD server as a DPV server. But that does not necessarily translate into removing the need for signatures on responses from such servers. If responses from a DPD server are spoofed, a client may be subject to a form of DoS attack, as it tries to make use of bogus certs formed chains intended to maximize the amount of crypto processing the client does, before realizing that the chain is bad. Or certs might be returned that conflict with certs from some other DPD server. Without signed responses it could be very hard to determine what went wrong and what servers ought to be avoided, based on bad behavior. Steve Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i32MW3A6016600; Fri, 2 Apr 2004 14:32:03 -0800 (PST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i32MW3l5016599; Fri, 2 Apr 2004 14:32:03 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail2.atl.registeredsite.com (nobody@mail2.atl.registeredsite.com [64.224.219.76]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i32MW2Qa016592 for <ietf-pkix@imc.org>; Fri, 2 Apr 2004 14:32:02 -0800 (PST) (envelope-from egerck@nma.com) Received: from taurus.hosting4u.net (taurus.hosting4u.net [209.35.191.122]) by mail2.atl.registeredsite.com (8.12.8/8.12.8) with ESMTP id i32MW0V1030785; Fri, 2 Apr 2004 22:32:00 GMT Received: from nma.com ([63.204.17.85]) by taurus.hosting4u.net ; Fri, 02 Apr 2004 16:31:59 -0600 Message-ID: <406DE9D8.1B74399A@nma.com> Date: Fri, 02 Apr 2004 14:31:52 -0800 From: Ed Gerck <egerck@nma.com> X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Stephen Kent <kent@bbn.com> CC: ietf-pkix@imc.org Subject: Re: Current status of CRL validation ? References: <20040323103412.GA23286@cryptolog.com> <004f01c410dc$2c0681d0$df294d0c@hq.orionsec.com> <20040323142525.GA27672@cryptolog.com> <p06020406bc861b0a4627@[128.33.244.157]> <406A0839.14F7C3A1@nma.com> <p06020401bc909a0b8ec1@[128.89.89.75]> <406B0593.FD2E1F6B@nma.com> <p06020408bc90bbc275a7@[128.89.89.75]> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Stephen Kent wrote: > > Ed, > > I really should have asked the context in which you were referring to > an RP's reliance on revocation status info. I welcome this clarification. Saying that the RP "relies" is not enough. The context of an RP's reliance is what provides the RP's justification for reliance. It's easy to say that an RP's justification of reliance is a matter of need. But this is not quantitative. If we are to make some progress in this, we need to define those needs as degrees or levels -- i.e., in terms that we can identify their differences and their required revocation models. For starters, I'd suggest the following reliance levels (from weaker to stronger): (0) What the RP relies upon without any consideration of "why" and without any recourse (open reliance). (1) What the RP relies upon without any consideration of "why" (actual reliance). (2) What the RP relies upon because it is presented by a party accepted by the RP for that purpose (authorization reliance). (3) What the RP as a reasonable man might do, with all prudence that might be reasonable to use (reasonable reliance). In other words, "what would be reasonable for a prudent man to do under the circumstances". (4) What can be justified by the RP after an examination of the facts presented (justified reliance). As usually defined by a CA's CPS, revocation information provided by a CA is level (0). The RP has no contract relationship with the CA and is denied any warranties and rights to recourse. The revocation information is provided by the CA to an RP "as is". Therefore, it does not help much to talk about CRL issue dates and RP reliance if the RP is stuck in level (0). No matter how frequent we make those CRL updates (and how much excess traffic we impose on the RP), that's why I said that the RP is unable to measure with any desired confidence (i.e., desired by the RP) whether a cert is revoked or not. The RP can hope to move to levels (1) and (2) when using a Trusted Responder during certificate reliance (i.e., whether the cert has been revoked or not) under CRLs or OCSPs. However, as I said before, one cannot rely upon them for other than their value as a representation of the issuer CA revocation management as expressed in the issuer CA own terms and rules -- which are in level (0). Thus, even though a X.509/PKIX cert is either revoked or not (and, yes, this is strictly enforceable in X.509/PKIX), X.509/PKIX is unable to allow a RP to measure with any desired confidence whether the cert is in fact revoked or not. > If the RP is validating a > signature for NR purposes, then the RP is nominally protected if he > waits until the "next" CRL is issued before he acts on the signed > object. The "next" CRL is usually one or two weeks away. Hardly worth waiting for in an e-commerce transaction -- may as well fly there. And if the cycle is shorter, traffic shoots up. > The CRL issuer is the only game in town re authoritative info > on the revocation status of a cert. AN RP is, by definition, a > "relying" party and he relies on the cert and CRL issuer(s) to > provide this status data when they have said it becomes available. A relying party to whom? If in level (0), to himself. > if > the RP cannot tolerate the wait, tough luck. The wait would be one to two weeks today. And for an information without any reliance except as an open statement. Tough luck indeed ;-) > If the RP is using a signature in an access control context, then the > problem is often different. For access control purposes, one usually > will not have the luxury of waiting for the next CRL to determine > revocation status, and even use of OCSP may not help, as many OCSP > servers are driven by CRLs. But, this is not an X.509 problem per se. > If the operator of an access control systems wants to ensure that a > user's privileges are revoked quickly, then the best way to do that > is to change the ACLs associated with the resources being protected, > or to push a hot list to each resource access manager. When certs are > used to verify identity in support of access control, these general > rules apply, and they are not fundamentally different than if one had > chosen to use passwords for user authentication. If X.509 revocation information could be trusted in this context, access control would not have that security gap. > >We have struggled with this passage before. Thanks for helping me > >clarify it now. In short, I mean that revocation by reference (i.e., a > >X.509 reference that X is revoked) does not revoke anything. Actual > >revocation, OTOH, would make it impossible to use the cert -- even if > >a reference about its revocation is not available. > > One cannot, in general, make "it impossible to use the cert" but one > can make a cert unusable in a given context. But that is not > surprising. In many systems with capability-like properties, > revocation effected by seizing an access token is often infeasible. Seizing the token is not the only way to make the token unusable. > If I have a keyed padlock on a locker, I can change the lock to > effect revocation of access privileges for the holders of keys, and > reissue new keys for the new lock to the folks I want to authorize. > Do I know that the keys that are out there will not be able to open > any other padlocks? Not really/ There may have been another padlock > that would accept the same keys and I don't now, nor can I prevent > the use of the keys in that padlock. Even though I usually dislike physical metaphors for crypto locks/keys, I think that you surely can prevent the keys that are out there to open any other padlocks. It's called key management and is the same with crypto locks/keys. > So, I'm afraid I don't find your clarification helpful. Maybe we're > still just missing a concisely stated context for the comment. Revoking by reference (the current method with CRLs and OCSPs) has some unsolved and unsolvable problems, and does not solve the real problem. The real problem is to make the cert unusable when revoked. For that, one should also not need to trust user intervention (even to update software, as some certs have been revoked). Cheers, Ed Gerck Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i32LuDbi013420; Fri, 2 Apr 2004 13:56:13 -0800 (PST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i32LuD1D013419; Fri, 2 Apr 2004 13:56:13 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from igw (adsl-63-194-79-229.dsl.snfc21.pacbell.net [63.194.79.229]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i32LuDXW013412 for <ietf-pkix@imc.org>; Fri, 2 Apr 2004 13:56:13 -0800 (PST) (envelope-from arshad.noor@strongauth.com) Received: from noorhome.net (localhost [127.0.0.1]) by igw.noorhome.net (iPlanet Messaging Server 5.2 Patch 1 (built Aug 19 2002)) with ESMTP id <0HVK00DT8C680W@igw.noorhome.net> for ietf-pkix@imc.org; Fri, 02 Apr 2004 13:39:44 -0800 (PST) Received: from [198.241.217.3] by igw.noorhome.net (mshttpd); Fri, 02 Apr 2004 13:39:44 -0800 Date: Fri, 02 Apr 2004 13:39:44 -0800 From: Arshad Noor <arshad.noor@strongauth.com> Subject: Re: PKI International Consortium To: Stephen Kent <kent@bbn.com> Cc: Shaheen.Nasirudheen@chase.com, PKIX list <ietf-pkix@imc.org> Message-id: <428a370f.370f428a@noorhome.net> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 Patch 1 (built Aug 19 2002) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> I would concur with you, Steve, that a single certificate that serves all purposes, is neither practical nor desirable. (Although I must confess to occassionally dreaming of such a utopian environment, sometimes). However, I believe, it is reasonable - assuming appropriate policy, process, implementation and most importantly, cooperation - to have industry-specific identities that may serve us all better. ("Identity Firewalls" - http://www.strongauth.com/newsletters/2003Jan17.html). Companies waste far too much time and money today, building duplicate identity infrastructures - and consequently tying their own hands with context-sensitive identities - because it appears to be the path of least resistance to them. But as the cost of identity theft & of managing those numerous identity infrastructures surpasses the perceived savings from using this path of least resistance, companies will be forced to rethink that strategy. Arshad Noor StrongAuth, Inc. ----- Original Message ----- From: Stephen Kent <kent@bbn.com> Date: Friday, April 2, 2004 8:47 am Subject: Re: PKI International Consortium > > At 10:57 AM -0500 4/2/04, Shaheen.Nasirudheen@chase.com wrote: > >Hello everyone, > > > >I appreciate your feedback and most of the replies were referring to > >identrus.com . My basic concern is from a customer's point of > view. If I > >have a digital certificate issued by a single authority that is > considered>trusted internationally by all financial as well as > other commercial > >institutions, then I do not require to have a certificate for > Institution>-1 and another for Institution -2. Do we have > something in place that takes > >of this issue. I would be happy to carry and protect that one > certificate>which is trusted by everyone. > > > >Thank you, > > > >Shaheen Nasirudheen > >JPMorgan ACCESS, Portal Security > >978 805 1815 > > > > The notion of the one cert that is good for everything is probably > never going to be a reality, fortunately. Note there there are no > physical credentials that have this property. Why would you > believe > that digital credentials could overcome the organizational > obstacles > that contribute to the existence of context-limited credentials? > Moreover, consider the awful consequences associated with a > compromise of the private key associated with such a cert, if it > existed. > > Steve > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i32LkfaT012798; Fri, 2 Apr 2004 13:46:41 -0800 (PST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i32LkfoN012797; Fri, 2 Apr 2004 13:46:41 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from caveiras.certisign.com.br (caveiras.certisign.com.br [200.219.128.102]) by above.proper.com (8.12.11/8.12.8) with SMTP id i32LkdKH012791 for <ietf-pkix@imc.org>; Fri, 2 Apr 2004 13:46:40 -0800 (PST) (envelope-from rbotafogo@certisign.com.br) Received: through eSafe SMTP Relay 1075129843; Fri Apr 02 18:45:52 2004 From: "Rodrigo Botafogo" <rbotafogo@certisign.com.br> To: <ietf-pkix@imc.org> Subject: Re-certification Date: Fri, 2 Apr 2004 18:44:00 -0300 Message-ID: <03b501c418fb$9be2da90$be00a8c0@jurujuba> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_03AD_01C418E2.746F8E40"; micalg=MD5 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> This is a multi-part message in MIME format. ------=_NextPart_000_03AD_01C418E2.746F8E40 Content-Type: multipart/alternative; boundary="----=_NextPart_001_03AE_01C418E2.74729B80" ------=_NextPart_001_03AE_01C418E2.74729B80 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit I'm new to this group, so sorry if I do not follow the groups culture somehow. I have a question regarding re-certification: In Brazil, a Certificate Authority had one of its CA expiring. According to the Brazilian legislation, a CA cannot re-certify its key, that is, it cannot extend the certificates expiration date for the same key. What the Certificate Authority did was: - Generated a new key pair; - Created a new certificate with: i) the same DN as the expiring CA, ii) the new key and iii) an extended expiration date First of all, is this legal according to X.509? If not, where do we find that on the norm? If this is legal, how are the CRLs supposed to work in this case. Note what happens: 1) There are two CA with certificates with the same DN. Lets call them OLD and NEW. 2) Lets call the CRLs generated CRLOld and CRLNew 3) When CRLNew is issued, since the DN of OLD and NEW are the same, all revoked certificates from OLD and NEW are stored in CRLNew. This is the software's behavior. Question: is this ok according to X.509? 4) Lets suppose that CRLOld had the following certificates {1, 3, 5} 5) Lets suppose that a new cert 8 is revoked. CRLNew will have {1, 3, 5, 8} 6) When a third party receives an email signed with Cert 1 what should it do? It will look at CRLNew, but CRLNew is not signed with the same private key than Cert 1? Question: Should the third party still say that the cert is invalid or should it say that it could not verify the status of the certificate? We made some tests and IE reported that it could not verify the status of the certificate and did not show any warnings, even though the certificate was expired. I'd appreciate any help on this. It seems to me that all that was described should not be legal according to X.509, but this is an actual case that is happening with the CA in Brazil and I couldn't find in the norms where it is said that this is illegal. Thanks, Rodrigo Botafogo ------=_NextPart_001_03AE_01C418E2.74729B80 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable <html xmlns:o=3D"urn:schemas-microsoft-com:office:office" = xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" = xmlns=3D"http://www.w3.org/TR/REC-html40"> <head> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Dus-ascii"> <meta name=3DProgId content=3DWord.Document> <meta name=3DGenerator content=3D"Microsoft Word 10"> <meta name=3DOriginator content=3D"Microsoft Word 10"> <link rel=3DFile-List href=3D"cid:filelist.xml@01C418E2.6FEAC970"> <o:SmartTagType = namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" name=3D"country-region"/> <o:SmartTagType = namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" name=3D"place"/> <!--[if gte mso 9]><xml> <o:OfficeDocumentSettings> <o:DoNotRelyOnCSS/> </o:OfficeDocumentSettings> </xml><![endif]--><!--[if gte mso 9]><xml> <w:WordDocument> <w:SpellingState>Clean</w:SpellingState> <w:GrammarState>Clean</w:GrammarState> <w:DocumentKind>DocumentEmail</w:DocumentKind> <w:HyphenationZone>21</w:HyphenationZone> <w:EnvelopeVis/> <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel> </w:WordDocument> </xml><![endif]--><!--[if !mso]> <style> st1\:*{behavior:url(#default#ieooui) } </style> <![endif]--> <style> <!-- /* Font Definitions */ @font-face {font-family:Wingdings; panose-1:5 0 0 0 0 0 0 0 0 0; mso-font-charset:2; mso-generic-font-family:auto; mso-font-pitch:variable; mso-font-signature:0 268435456 0 0 -2147483648 0;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {mso-style-parent:""; margin:0cm; margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:12.0pt; font-family:"Times New Roman"; mso-fareast-font-family:"Times New Roman";} a:link, span.MsoHyperlink {color:blue; text-decoration:underline; text-underline:single;} a:visited, span.MsoHyperlinkFollowed {color:purple; text-decoration:underline; text-underline:single;} span.EstiloDeEmail17 {mso-style-type:personal-compose; mso-style-noshow:yes; mso-ansi-font-size:10.0pt; mso-bidi-font-size:10.0pt; font-family:Arial; mso-ascii-font-family:Arial; mso-hansi-font-family:Arial; mso-bidi-font-family:Arial; color:windowtext;} span.SpellE {mso-style-name:""; mso-spl-e:yes;} span.GramE {mso-style-name:""; mso-gram-e:yes;} @page Section1 {size:612.0pt 792.0pt; margin:70.85pt 3.0cm 70.85pt 3.0cm; mso-header-margin:35.4pt; mso-footer-margin:35.4pt; mso-paper-source:0;} div.Section1 {page:Section1;} /* List Definitions */ @list l0 {mso-list-id:1990010115; mso-list-type:hybrid; mso-list-template-ids:-2127900860 558148752 68550659 68550661 68550657 = 68550659 68550661 68550657 68550659 68550661;} @list l0:level1 {mso-level-start-at:0; mso-level-number-format:bullet; mso-level-text:-; mso-level-tab-stop:36.0pt; mso-level-number-position:left; text-indent:-18.0pt; font-family:Arial; mso-fareast-font-family:"Times New Roman";} @list l1 {mso-list-id:1990404705; mso-list-type:hybrid; mso-list-template-ids:662842690 68550673 68550681 68550683 68550671 = 68550681 68550683 68550671 68550681 68550683;} @list l1:level1 {mso-level-text:"%1\)"; mso-level-tab-stop:36.0pt; mso-level-number-position:left; text-indent:-18.0pt;} ol {margin-bottom:0cm;} ul {margin-bottom:0cm;} --> </style> <!--[if gte mso 10]> <style> /* Style Definitions */=20 table.MsoNormalTable {mso-style-name:"Tabela normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-parent:""; mso-padding-alt:0cm 5.4pt 0cm 5.4pt; mso-para-margin:0cm; mso-para-margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:10.0pt; font-family:"Times New Roman";} </style> <![endif]--> </head> <body lang=3DPT-BR link=3Dblue vlink=3Dpurple = style=3D'tab-interval:35.4pt'> <div class=3DSection1> <p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US = style=3D'font-size: 10.0pt;font-family:Arial;mso-ansi-language:EN-US'>I’m new to this = group, so sorry if I do not follow the groups culture somehow. <span style=3D'mso-spacerun:yes'> </span>I have a question regarding = re-certification:<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US = style=3D'font-size: 10.0pt;font-family:Arial;mso-ansi-language:EN-US'><o:p> </o:p></span= ></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US = style=3D'font-size: 10.0pt;font-family:Arial;mso-ansi-language:EN-US'>In = </span></font><st1:country-region><st1:place><font size=3D2 face=3DArial><span lang=3DEN-US = style=3D'font-size:10.0pt;font-family:Arial; = mso-ansi-language:EN-US'>Brazil</span></font></st1:place></st1:country-re= gion><font size=3D2 face=3DArial><span lang=3DEN-US = style=3D'font-size:10.0pt;font-family:Arial; mso-ansi-language:EN-US'>, a Certificate Authority had one of its CA = expiring. <span style=3D'mso-spacerun:yes'> </span>According to the Brazilian = legislation, a CA cannot re-certify its key, that is, it cannot extend the certificates expiration date for the same key.<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US = style=3D'font-size: 10.0pt;font-family:Arial;mso-ansi-language:EN-US'><o:p> </o:p></span= ></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US = style=3D'font-size: 10.0pt;font-family:Arial;mso-ansi-language:EN-US'>What the Certificate Authority did was:<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US = style=3D'font-size: 10.0pt;font-family:Arial;mso-ansi-language:EN-US'><o:p> </o:p></span= ></font></p> <p class=3DMsoNormal = style=3D'margin-left:36.0pt;text-indent:-18.0pt;mso-list:l0 level1 lfo1; tab-stops:list 36.0pt'><![if !supportLists]><font size=3D2 = face=3DArial><span lang=3DEN-US = style=3D'font-size:10.0pt;font-family:Arial;mso-fareast-font-family: Arial;mso-ansi-language:EN-US'><span style=3D'mso-list:Ignore'>-<font = size=3D1 face=3D"Times New Roman"><span style=3D'font:7.0pt "Times New = Roman"'> </span></font></span></span></font><![endif]><font size=3D2 = face=3DArial><span lang=3DEN-US = style=3D'font-size:10.0pt;font-family:Arial;mso-ansi-language:EN-US'>Gene= rated a new key pair;<o:p></o:p></span></font></p> <p class=3DMsoNormal = style=3D'margin-left:36.0pt;text-indent:-18.0pt;mso-list:l0 level1 lfo1; tab-stops:list 36.0pt'><![if !supportLists]><font size=3D2 = face=3DArial><span lang=3DEN-US = style=3D'font-size:10.0pt;font-family:Arial;mso-fareast-font-family: Arial;mso-ansi-language:EN-US'><span style=3D'mso-list:Ignore'>-<font = size=3D1 face=3D"Times New Roman"><span style=3D'font:7.0pt "Times New = Roman"'> </span></font></span></span></font><![endif]><font size=3D2 = face=3DArial><span lang=3DEN-US = style=3D'font-size:10.0pt;font-family:Arial;mso-ansi-language:EN-US'>Crea= ted a new certificate with: <span class=3DSpellE>i</span>) the same DN as = the expiring CA, ii) the new key and iii) an extended expiration = date<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US = style=3D'font-size: 10.0pt;font-family:Arial;mso-ansi-language:EN-US'><o:p> </o:p></span= ></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US = style=3D'font-size: 10.0pt;font-family:Arial;mso-ansi-language:EN-US'>First of all, is this = legal according to X.509? If not, where do we find that on the = norm?<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US = style=3D'font-size: 10.0pt;font-family:Arial;mso-ansi-language:EN-US'><o:p> </o:p></span= ></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US = style=3D'font-size: 10.0pt;font-family:Arial;mso-ansi-language:EN-US'>If this is legal, how = are the <span class=3DSpellE>CRLs</span> supposed to work in this case.<span style=3D'mso-spacerun:yes'> </span>Note what = happens:<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US = style=3D'font-size: 10.0pt;font-family:Arial;mso-ansi-language:EN-US'><o:p> </o:p></span= ></font></p> <p class=3DMsoNormal = style=3D'margin-left:36.0pt;text-indent:-18.0pt;mso-list:l1 level1 lfo2; tab-stops:list 36.0pt'><![if !supportLists]><font size=3D2 = face=3DArial><span lang=3DEN-US = style=3D'font-size:10.0pt;font-family:Arial;mso-fareast-font-family: Arial;mso-ansi-language:EN-US'><span style=3D'mso-list:Ignore'>1)<font = size=3D1 face=3D"Times New Roman"><span style=3D'font:7.0pt "Times New = Roman"'> </span></font></span></span></font><![endif]><font size=3D2 = face=3DArial><span lang=3DEN-US = style=3D'font-size:10.0pt;font-family:Arial;mso-ansi-language:EN-US'>Ther= e are two CA with certificates with the same DN.<span = style=3D'mso-spacerun:yes'> </span><span class=3DGramE>Lets</span> call them OLD and = NEW.<o:p></o:p></span></font></p> <p class=3DMsoNormal = style=3D'margin-left:36.0pt;text-indent:-18.0pt;mso-list:l1 level1 lfo2; tab-stops:list 36.0pt'><![if !supportLists]><font size=3D2 = face=3DArial><span lang=3DEN-US = style=3D'font-size:10.0pt;font-family:Arial;mso-fareast-font-family: Arial;mso-ansi-language:EN-US'><span style=3D'mso-list:Ignore'>2)<font = size=3D1 face=3D"Times New Roman"><span style=3D'font:7.0pt "Times New = Roman"'> </span></font></span></span></font><![endif]><font size=3D2 = face=3DArial><span lang=3DEN-US = style=3D'font-size:10.0pt;font-family:Arial;mso-ansi-language:EN-US'>Lets= call the <span class=3DSpellE>CRLs</span> generated <span = class=3DSpellE>CRLOld</span> and <span class=3DSpellE>CRLNew</span><o:p></o:p></span></font></p> <p class=3DMsoNormal = style=3D'margin-left:36.0pt;text-indent:-18.0pt;mso-list:l1 level1 lfo2; tab-stops:list 36.0pt'><![if !supportLists]><font size=3D2 = face=3DArial><span lang=3DEN-US = style=3D'font-size:10.0pt;font-family:Arial;mso-fareast-font-family: Arial;mso-ansi-language:EN-US'><span style=3D'mso-list:Ignore'>3)<font = size=3D1 face=3D"Times New Roman"><span style=3D'font:7.0pt "Times New = Roman"'> </span></font></span></span></font><![endif]><font size=3D2 = face=3DArial><span lang=3DEN-US = style=3D'font-size:10.0pt;font-family:Arial;mso-ansi-language:EN-US'>When= <span class=3DSpellE>CRLNew</span> is issued, since the DN of OLD and = NEW are the same, all revoked certificates from OLD and NEW are stored in <span class=3DSpellE>CRLNew</span>.<span style=3D'mso-spacerun:yes'> = </span>This is the software’s behavior.<span style=3D'mso-spacerun:yes'> = </span>Question: is this ok according to X.509?<o:p></o:p></span></font></p> <p class=3DMsoNormal = style=3D'margin-left:36.0pt;text-indent:-18.0pt;mso-list:l1 level1 lfo2; tab-stops:list 36.0pt'><![if !supportLists]><font size=3D2 = face=3DArial><span lang=3DEN-US = style=3D'font-size:10.0pt;font-family:Arial;mso-fareast-font-family: Arial;mso-ansi-language:EN-US'><span style=3D'mso-list:Ignore'>4)<font = size=3D1 face=3D"Times New Roman"><span style=3D'font:7.0pt "Times New = Roman"'> </span></font></span></span></font><![endif]><font size=3D2 = face=3DArial><span lang=3DEN-US = style=3D'font-size:10.0pt;font-family:Arial;mso-ansi-language:EN-US'>Lets= suppose that <span class=3DSpellE>CRLOld</span> had the following = certificates {1, 3, 5}<o:p></o:p></span></font></p> <p class=3DMsoNormal = style=3D'margin-left:36.0pt;text-indent:-18.0pt;mso-list:l1 level1 lfo2; tab-stops:list 36.0pt'><![if !supportLists]><font size=3D2 = face=3DArial><span lang=3DEN-US = style=3D'font-size:10.0pt;font-family:Arial;mso-fareast-font-family: Arial;mso-ansi-language:EN-US'><span style=3D'mso-list:Ignore'>5)<font = size=3D1 face=3D"Times New Roman"><span style=3D'font:7.0pt "Times New = Roman"'> </span></font></span></span></font><![endif]><span class=3DGramE><font = size=3D2 face=3DArial><span lang=3DEN-US = style=3D'font-size:10.0pt;font-family:Arial; mso-ansi-language:EN-US'>Lets</span></font></span><font size=3D2 = face=3DArial><span lang=3DEN-US = style=3D'font-size:10.0pt;font-family:Arial;mso-ansi-language:EN-US'> suppose that a new cert 8 is revoked.<span = style=3D'mso-spacerun:yes'> </span><span class=3DSpellE>CRLNew</span> will have {1, 3, 5, = 8}<o:p></o:p></span></font></p> <p class=3DMsoNormal = style=3D'margin-left:36.0pt;text-indent:-18.0pt;mso-list:l1 level1 lfo2; tab-stops:list 36.0pt'><![if !supportLists]><font size=3D2 = face=3DArial><span lang=3DEN-US = style=3D'font-size:10.0pt;font-family:Arial;mso-fareast-font-family: Arial;mso-ansi-language:EN-US'><span style=3D'mso-list:Ignore'>6)<font = size=3D1 face=3D"Times New Roman"><span style=3D'font:7.0pt "Times New = Roman"'> </span></font></span></span></font><![endif]><font size=3D2 = face=3DArial><span lang=3DEN-US = style=3D'font-size:10.0pt;font-family:Arial;mso-ansi-language:EN-US'>When= a third party receives an email signed with Cert 1 what should it = do?<span style=3D'mso-spacerun:yes'> </span>It will look at <span = class=3DSpellE>CRLNew</span>, but <span class=3DSpellE>CRLNew</span> is not signed with the same = private key than Cert 1?<span style=3D'mso-spacerun:yes'> </span>Question: = Should the third party still say that the cert is invalid or should it say that it could not = verify the status of the certificate? We made some tests and IE reported that = it could not verify the status of the certificate and did not show any warnings, = even though the certificate was expired.<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US = style=3D'font-size: 10.0pt;font-family:Arial;mso-ansi-language:EN-US'><o:p> </o:p></span= ></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US = style=3D'font-size: 10.0pt;font-family:Arial;mso-ansi-language:EN-US'>I’d appreciate = any help on this. <span style=3D'mso-spacerun:yes'> </span>It seems to me = that all that was described should not be legal according to X.509, but this is an = actual case that is happening with the CA in = </span></font><st1:country-region><st1:place><font size=3D2 face=3DArial><span lang=3DEN-US = style=3D'font-size:10.0pt;font-family:Arial; = mso-ansi-language:EN-US'>Brazil</span></font></st1:place></st1:country-re= gion><font size=3D2 face=3DArial><span lang=3DEN-US = style=3D'font-size:10.0pt;font-family:Arial; mso-ansi-language:EN-US'> and I couldn’t find in the norms where = it is said that this is illegal.<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US = style=3D'font-size: 10.0pt;font-family:Arial;mso-ansi-language:EN-US'><o:p> </o:p></span= ></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US = style=3D'font-size: 10.0pt;font-family:Arial;mso-ansi-language:EN-US'>Thanks,<o:p></o:p></spa= n></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US = style=3D'font-size: 10.0pt;font-family:Arial;mso-ansi-language:EN-US'><o:p> </o:p></span= ></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US = style=3D'font-size: 10.0pt;font-family:Arial;mso-ansi-language:EN-US'><o:p> </o:p></span= ></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US = style=3D'font-size: 10.0pt;font-family:Arial;mso-ansi-language:EN-US'><o:p> </o:p></span= ></font></p> <p class=3DMsoNormal><font size=3D2 face=3D"Times New Roman"><span = lang=3DEN-US style=3D'font-size:10.0pt;mso-ansi-language:EN-US;mso-no-proof:yes'>Rodri= go Botafogo<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span = lang=3DEN-US style=3D'font-size:12.0pt;mso-ansi-language:EN-US'><o:p> </o:p></spa= n></font></p> </div> </body> </html> ------=_NextPart_001_03AE_01C418E2.74729B80-- ------=_NextPart_000_03AD_01C418E2.746F8E40 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDjAMBggqhkiG9w0CBQUAMIAGCSqGSIb3DQEHAQAAoIIKtDCC Aj0wggGmAhEAzbp/VvDf5LxU/iKss3KqVTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEX MBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkg Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMjgwODAxMjM1OTU5WjBf MQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEg UHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQAD gY0AMIGJAoGBAOUZv22jVmEtmUhx9mfeuY3rt56GgAqRDvo4Ja9GiILlc6igmyRdDR/MZW4MsNBW hBiHmgabEKFz37RYOWtuwfYV1aioP6oSBo0xrH+wNNePNGeICc0UEeJORVZpH3gCgNrcR5EpuzbJ Y1zF4Ncth3uhtzKwezC6Ki8xqu6jZ9rbAgMBAAEwDQYJKoZIhvcNAQECBQADgYEATD+4i8Zo3+5D Mw5d6abLB4RNejP/khv0Nq3YlSI2aBFsfELM85wuxAc/FLAPT/+Qknb54rxK6Y/NoIAK98Up8YIi Xbix3YEjo3slFUYweRb46gVLlH8dwhzI47f0EEA8E8NfH1PoSOSGtHuhNbB7Jbq4046rPzidADQA mPPRcZQwggNeMIICx6ADAgECAhA84jSriQsTpcYCE6HiUrg6MA0GCSqGSIb3DQEBBAUAMF8xCzAJ BgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJs aWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wMDA1MjAwMDAwMDBaFw0wNTA1 MTEyMzU5NTlaMIHQMS4wLAYDVQQKEyVDZXJ0aXNpZ24gQ2VydGlmaWNhZG9yYSBEaWdpdGFsIEx0 ZGEuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMT8wPQYDVQQLEzZUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cuY2VydGlzaWduLmNvbS5ici9SUEEgKGMpMDAxPDA6BgNVBAMTM0Nl cnRpc2lnbiBDbGFzcyAxIENvbnN1bWVyIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTCBnzANBgkq hkiG9w0BAQEFAAOBjQAwgYkCgYEAwv+tzSHkVlZMd8vKtQSOMxeZmi60OqvKGBnqTT/fB2lFkJA4 jyonCwVhW3AoBRmG2CoJHXO8qDGHCJ1euUVhfsBbqEbzpHCXabkQ8nwjdrG2dsNNdjS03ihbqJzS /gYcnikf4pUrYI+ogGvo2l0TzM+d3A1+aABEg1334Ld97ZsCAwEAAaOBqDCBpTApBgNVHREEIjAg pB4wHDEaMBgGA1UEAxMRQ2VydGlzaWduQzFDMi0xLTEwEQYJYIZIAYb4QgEBBAQDAgEGMEcGA1Ud IARAMD4wPAYKYIZIAYb4RQEHDzAuMCwGCCsGAQUFBwIBFiBodHRwczovL3d3dy5jZXJ0aXNpZ24u Y29tLmJyL1JQQTAPBgNVHRMECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOB gQB/ETCpNnaDii6nSsh+8JjF3cNvr1+HRDm5WQ2VsY+JR2NwbNYqYL/JWdagF5C/77rk7my6kwyc H1wByZi5BPcZZfimEkXgbQcad7C6JZLB9huB4KH9YB7/nPVDjl3X6oIU6uDVt8EbOlR6XdG8gd4L AyZAS10UsMt++Dz24MDyTTCCBQ0wggR2oAMCAQICEAGfzOriggkEmT5x2OammSgwDQYJKoZIhvcN AQEEBQAwgdAxLjAsBgNVBAoTJUNlcnRpc2lnbiBDZXJ0aWZpY2Fkb3JhIERpZ2l0YWwgTHRkYS4x HzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxPzA9BgNVBAsTNlRlcm1zIG9mIHVzZSBh dCBodHRwczovL3d3dy5jZXJ0aXNpZ24uY29tLmJyL1JQQSAoYykwMDE8MDoGA1UEAxMzQ2VydGlz aWduIENsYXNzIDEgQ29uc3VtZXIgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMB4XDTAzMDkxNjAw MDAwMFoXDTA0MDkxNTIzNTk1OVowggFmMSswKQYDVQQKFCJDZXJ0aVNpZ24gQ2VydGlmaWNhZG9y YSBEaWdpdGFsIFNBMREwDwYDVQQLFAhDbGFzc2UgMTE3MDUGA1UECxMuVGVybXMgb2YgdXNlIGF0 IHd3dy5jZXJ0aXNpZ24uY29tLmJyL1JQQSAoYykwMDE/MD0GA1UECxM2QXV0aGVudGljYXRlZCBi eSBDZXJ0aXNpZ24gQ2VydGlmaWNhZG9yYSBEaWdpdGFsIEx0ZGEuMScwJQYDVQQLEx5NZW1iZXIs IFZlcmlTaWduIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEb MBkGA1UECxMSRGlnaXRhbCBJRCBDbGFzcyAxMRkwFwYDVQQDExBSb2RyaWdvIEJvdGFmb2dvMSkw JwYJKoZIhvcNAQkBFhpyYm90YWZvZ29AY2VydGlzaWduLmNvbS5icjCBnzANBgkqhkiG9w0BAQEF AAOBjQAwgYkCgYEA5opHs5mo0q+gH3ejR6UJLs6ppE9ssOMLUsrDkeBSNSBd9Z8aBYtGU1vh/1Fo MFDCXEbZflxlBBAualq+O4xxwnL+I0955hPUlpcarTJJ7Tk6NHAHp/U6ajeBR5KWVyuFsrbY6687 V4k6oOBe93eJDfYW5N9O2TEv86GYCKJksSUCAwEAAaOCAU0wggFJMAkGA1UdEwQCMAAwZwYDVR0f BGAwXjBcoFqgWIZWaHR0cDovL29uc2l0ZWNybC5jZXJ0aXNpZ24uY29tLmJyL0NlcnRpU2lnbkNl cnRpZmljYWRvcmFEaWdpdGFsU0FDbGFzc2UxL0xhdGVzdENSTC5jcmwwgawGA1UdIASBpDCBoTCB ngYLYIZIAYb4RQEHAQEwgY4wKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9D UFMwYgYIKwYBBQUHAgIwVjAVFg5WZXJpU2lnbiwgSW5jLjADAgEBGj1WZXJpU2lnbidzIENQUyBp bmNvcnAuIGJ5IHJlZmVyZW5jZSBsaWFiLiBsdGQuIChjKTk3IFZlcmlTaWduMBEGCWCGSAGG+EIB AQQEAwIHgDARBgpghkgBhvhFAQYJBAMBAf8wDQYJKoZIhvcNAQEEBQADgYEAC+ACr4MSMbhFCpPr LhCeQpl/smArUeKUAfMHoO/Xhf9ecpONi++BnMqXGqnhGA2w9foPMLOqGFrwvzb8bPGhxJcqQn8r 1M0litTFOsaSASLrnTEyECgXPBQUHnTyFPPnbw6KU+XQbe4vPETWFkQd7rctBX/6X0SwM8X99q+Q 6OUxggRBMIIEPQIBATCB5TCB0DEuMCwGA1UEChMlQ2VydGlzaWduIENlcnRpZmljYWRvcmEgRGln aXRhbCBMdGRhLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE/MD0GA1UECxM2VGVy bXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LmNlcnRpc2lnbi5jb20uYnIvUlBBIChjKTAwMTwwOgYD VQQDEzNDZXJ0aXNpZ24gQ2xhc3MgMSBDb25zdW1lciBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EC EAGfzOriggkEmT5x2OammSgwDAYIKoZIhvcNAgUFAKCCAq4wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMDQwNDAyMjE0MzU2WjAfBgkqhkiG9w0BCQQxEgQQ3c5RmJtQ kRQptB5q0o2bOTBfBgkqhkiG9w0BCQ8xUjBQMA4GCCqGSIb3DQMCAgIAgDAKBggqhkiG9w0CBTAL BglghkgBZQIBAQQwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfYGCSsG AQQBgjcQBDGB6DCB5TCB0DEuMCwGA1UEChMlQ2VydGlzaWduIENlcnRpZmljYWRvcmEgRGlnaXRh bCBMdGRhLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE/MD0GA1UECxM2VGVybXMg b2YgdXNlIGF0IGh0dHBzOi8vd3d3LmNlcnRpc2lnbi5jb20uYnIvUlBBIChjKTAwMTwwOgYDVQQD EzNDZXJ0aXNpZ24gQ2xhc3MgMSBDb25zdW1lciBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ECEAGf zOriggkEmT5x2OammSgwgfgGCyqGSIb3DQEJEAILMYHooIHlMIHQMS4wLAYDVQQKEyVDZXJ0aXNp Z24gQ2VydGlmaWNhZG9yYSBEaWdpdGFsIEx0ZGEuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMT8wPQYDVQQLEzZUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cuY2VydGlzaWduLmNv bS5ici9SUEEgKGMpMDAxPDA6BgNVBAMTM0NlcnRpc2lnbiBDbGFzcyAxIENvbnN1bWVyIEluZGl2 aWR1YWwgU3Vic2NyaWJlciBDQQIQAZ/M6uKCCQSZPnHY5qaZKDANBgkqhkiG9w0BAQEFAASBgEZh 8GUBv8yr6KFeqP+xsW+avN522Sb0TvHKrPUdXrkP8v27pXp1uj0tk/d6RQMH65giB4QwoJA+ICZ+ wB+Z0hffDm1vqoI1zKoaX5yRdNe1qk0MZqMC7c219elAzjK9rAUSep3P5LhN5ZR3XK/pasNcUm2j Ad1CwBUzQesm4yCTAAAAAAAA ------=_NextPart_000_03AD_01C418E2.746F8E40-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i32LkPq6012784; Fri, 2 Apr 2004 13:46:25 -0800 (PST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i32LkPxJ012783; Fri, 2 Apr 2004 13:46:25 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i32LkOZd012771 for <ietf-pkix@imc.org>; Fri, 2 Apr 2004 13:46:24 -0800 (PST) (envelope-from kent@bbn.com) Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i32LkC7X017860; Fri, 2 Apr 2004 16:46:14 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: <p06020427bc938e75d7a8@[128.89.89.75]> In-Reply-To: <DE909E05406F3340B186DA5A410B05F642A214@mongo.corestreet.com> References: <DE909E05406F3340B186DA5A410B05F642A214@mongo.corestreet.com> Date: Fri, 2 Apr 2004 16:45:29 -0500 To: "Dave Engberg" <dengberg@corestreet.com> From: Stephen Kent <kent@bbn.com> Subject: Re: Signing Untrusted SCVP? Cc: <ietf-pkix@imc.org> Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Dave, I agree that one might not want to invest as much effort and money in securing a DPD server as a DPV server. But that does not necessarily translate into removing the need for signatures on responses from such servers. If responses from a DPD server are spoofed, a client may be subject to a form of DoS attack, as it tries to make use of bogus certs formed chains intended to maximize the amount of crypto processing the client does, before realizing that the chain is bad. Or certs might be returned that conflict with certs from some other DPD server. Without signed responses it could be very hard to determine what went wrong and what servers ought to be avoided, based on bad behavior. Steve Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i32IwF7o096872; Fri, 2 Apr 2004 10:58:15 -0800 (PST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i32IwFuV096871; Fri, 2 Apr 2004 10:58:15 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mdhagsmtp01.firstdata.com (mdhagsmtp01.firstdata.com [198.184.5.21]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i32IwEDs096857 for <ietf-pkix@imc.org>; Fri, 2 Apr 2004 10:58:14 -0800 (PST) (envelope-from lynn.wheeler@firstdata.com) Subject: Re: PKI International Consortium To: Shaheen.Nasirudheen@chase.com Cc: "Anders Rundgren" <anders.rundgren@telia.com>, "PKIX list" <ietf-pkix@imc.org>, owner-ietf-pkix@mail.imc.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: <OFEE9E0185.38D1BE2D-ON87256E6A.0065EF27@firstdata.com> From: lynn.wheeler@firstdata.com Date: Fri, 2 Apr 2004 11:49:36 -0700 X-MIMETrack: Serialize by Router on MDHAGSMTP/FDMS/FDC(Release 6.0.2CF2|July 23, 2003) at 04/02/2004 01:57:21 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> sort of the fundamental issue is that the certificate design point is for offline processing .... it contains sufficient information that it is possible for the relying party to perform some operation based on relying on the certificate w/o needing recourse to any additional information. the problem is also sort of analogous to the issue of needing different shared-secrets for different security domains ... recent topic drift in sci.scrypt ... http://www.garlic.com/~lynn/2004d.html#40 RFC-2898 Appendix B lets say i have a passport certificate and i wish to do a financial transaction on a chase bank account. the passport certificate probably doesn't provide any information with regard to whether i even have a financial account with chase bank .... aka the passport certificate contains insufficient information for a relying party expecting a valid financial transaction. so for an offline certificate paradigm to work .... it just about means a unique certificate for every operational domain ... containing sufficient information that a relying party will go ahead and do whatever operation based on the contents of the certificate. now, if the relying party really wants a financial transaction executed with chase .... then there is not only the issue of the contents of a stale, static certificate designed as a solution for offline environments ... but there is the possibility that the relying party might be interested in online, timely, and possibly aggregated information (not conducive for incorporation in a stale, static certificate designed for solving problems associated with offline environments) ... in which case, the relying party might be inclined to perform a online operation with the authoritative institution for that particular kind of operation. In the case of a customer financial transaction, the relying party might be interested in performing a financial transaction with the customer's financial institution (as the authoritative agency for that kind of operation). For this type of scenario, it is then possible to claim for valuable and/or important operations (where relying parties may be interested in timely information, as opposed to stale, static information possibly contained in a certificate), that direclty contacting the authoritative agency makes the use of stale, static certificates redundant and superfluous. If the authoritative agency has registered a public key and issued a stale, static certificate .... then if the relying party is directly contacting the authoritative agency ... the substitute stale static certificate (issued for addressing the needs of offline operations) is redundant and superfluous. shaheen.nasirudheen@chase.com on 4/2/2004 8:57 am wrote: Hello everyone, I appreciate your feedback and most of the replies were referring to identrus.com . My basic concern is from a customer's point of view. If I have a digital certificate issued by a single authority that is considered trusted internationally by all financial as well as other commercial institutions, then I do not require to have a certificate for Institution -1 and another for Institution -2. Do we have something in place that takes of this issue. I would be happy to carry and protect that one certificate which is trusted by everyone. Thank you, Shaheen Nasirudheen JPMorgan ACCESS, Portal Security 978 805 1815 -- Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i32HqTgb092379; Fri, 2 Apr 2004 09:52:29 -0800 (PST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i32HqTCW092378; Fri, 2 Apr 2004 09:52:29 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from visa.com (portal3.visa.com [198.80.42.3]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i32HqTCU092368 for <ietf-pkix@imc.org>; Fri, 2 Apr 2004 09:52:29 -0800 (PST) (envelope-from aterwil@visa.com) Received: from ([10.72.86.29]) by portal3.visa.com with ESMTP ; Fri, 02 Apr 2004 09:51:03 -0800 (PST) Received: from sw720ex016.visa.com ([10.72.11.170]) by sw720ex001.visa.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 2 Apr 2004 09:51:03 -0800 content-class: urn:content-classes:message Subject: RE: PKI International Consortium Date: Fri, 2 Apr 2004 09:54:28 -0800 Message-ID: <430625553CD00E4780C17F9C42173D9D013EA66F@sw720ex016.visa.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MS-Has-Attach: X-MS-TNEF-Correlator: X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: PKI International Consortium Thread-Index: AcQY2O7t6WjyG2qsSbiFKSJOX04eSAAAfEJw From: "Terwilliger, Ann" <aterwil@visa.com> To: "Anders Rundgren" <anders.rundgren@telia.com>, "PKIX list" <ietf-pkix@imc.org>, <Shaheen.Nasirudheen@chase.com> X-OriginalArrivalTime: 02 Apr 2004 17:51:03.0092 (UTC) FILETIME=[10BCA740:01C418DB] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i32HqTCU092373 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> The Visa International PKI does issue certificates to Visa Members and their agents internationally. However, we are a closed system and these certificates are only to be used in conjunction with Visa products and services. -----Original Message----- From: Anders Rundgren [mailto:anders.rundgren@telia.com] Sent: Friday, April 02, 2004 8:28 AM To: PKIX list; Shaheen.Nasirudheen@chase.com Subject: Re: PKI International Consortium Hi Shaheen, There are several PKIs run by FIs, even on an international level. However, I have some difficulties with the phrase "certificates for the members"? Is a "member" an FI organization, FI employee or an FI customer? For the premier category I believe VISA does that for the 3D Secure network. For FI employees I don't know if there really is any big need for such as these certificates have little use except internally. Well, Identrus have indeed sold such services to a few banks. Regarding the third category, it is interesting to note that banks seem to take the lead in issuing "citizen-certificates" as a citizen=bank customer. These FA CAs are though not really international due to some basic problems like the lack of standards for expressing citizen identities in various regimes. Here the customer is really e-governments although the certificates can often be used for on-line banking as well. www.identrus.com www.bankid.com www.bankid.no Anders ----- Original Message ----- From: <Shaheen.Nasirudheen@chase.com> To: "PKIX list" <ietf-pkix@imc.org> Sent: Thursday, April 01, 2004 16:30 Subject: PKI International Consortium Hello, I would like to know if there is any international consortium of financial institutions that maintain a PKI and issues certificates for the members. If so, what are the standards followed? Any information would be helpful. Regards. Shaheen Nasirudheen JPMorgan ACCESS, Portal Security ----------------------------------- This message may contain legally privileged and/or confidential information. If you are not the intended recipient(s), or the employee or agent responsible for delivery of this message to the intended recipient(s), you are hereby notified that any dissemination, distribution or copying of this message is strictly prohibited. If you have received this message in error, please immediately notify the sender and delete this e-mail message from your computer. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i32Hlx8l092164; Fri, 2 Apr 2004 09:47:59 -0800 (PST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i32HlxGw092163; Fri, 2 Apr 2004 09:47:59 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail-dub.microsoft.com (mail-dub.microsoft.com [213.199.128.160]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i32HlvZa092152 for <ietf-pkix@imc.org>; Fri, 2 Apr 2004 09:47:58 -0800 (PST) (envelope-from stefans@microsoft.com) Received: from dub-imc-01.europe.corp.microsoft.com ([65.53.196.22]) by mail-dub.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 2 Apr 2004 18:47:32 +0100 Received: from 65.53.196.22 by dub-imc-01.europe.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 02 Apr 2004 18:47:32 +0100 Received: from EUR-MSG-03.europe.corp.microsoft.com ([65.53.192.44]) by dub-imc-01.europe.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 2 Apr 2004 18:47:32 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7195.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-9219e7d0-b3e1-43af-bb98-272ff38359b6" Subject: SMIME Capabilities in X.509 certificates. Date: Fri, 2 Apr 2004 18:47:55 +0100 Message-ID: <0C3042E92D8A714783E2C44AB9936E1DE34701@EUR-MSG-03.europe.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SMIME Capabilities in X.509 certificates. Thread-Index: AcQY2qET/MCb1qPjRV6EkQhn0Qe78Q== From: "Stefan Santesson" <stefans@microsoft.com> To: <ietf-pkix@imc.org> X-OriginalArrivalTime: 02 Apr 2004 17:47:32.0146 (UTC) FILETIME=[9300D920:01C418DA] Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> This is a multi-part message in MIME format. ------=_NextPartTM-000-9219e7d0-b3e1-43af-bb98-272ff38359b6 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C418DA.93B68833" ------_=_NextPart_001_01C418DA.93B68833 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, =20 I would like to revisit a subject that has been discussed in the passed as consideration for future work. =20 The SMIME Capabilities attribute, defined in PKCS#9 is used in CMS as a signedAttribute (RFC 2633, 2.5.2 SMIMECapabilities Attribute) to carry information about the cryptographic capabilities of an entity. However the use of this extension can also be useful to carry inside a certificate to communicate primary capabilities in situation where no other prior knowledge of the other party exist. =20 There are of course cases where it is unsuitable to include such information in certificates, e.g. where the capabilities changes over time within the validity period of the certificate, but there are without doubt situations where it is useful. =20 Microsoft has since long successfully used the PKCS#9 attribute OID to also identify a certificate extension with the same syntax of this attribute, to include this information in certificates. I would therefore suggest that PKIX consider standardizing this practice. =20 This may also be an issue for the update of RFC 2632 dependent on this work group's opinion. =20 Stefan Santesson Program Manager, Windows Security Principal Consultant, Microsoft Denmark =20 ------_=_NextPart_001_01C418DA.93B68833 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:o=3D"urn:schemas-microsoft-com:office:office" = xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" = xmlns=3D"http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3DContent-Type content=3D"text/html; = charset=3Dus-ascii"> <meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)"> <o:SmartTagType = namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" name=3D"country-region"/> <o:SmartTagType = namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" name=3D"place"/> <!--[if !mso]> <style> st1\:*{behavior:url(#default#ieooui) } </style> <![endif]--> <style> <!-- /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0cm; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman";} a:link, span.MsoHyperlink {color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {color:purple; text-decoration:underline;} span.EmailStyle17 {mso-style-type:personal-compose; font-family:Arial; color:windowtext;} @page Section1 {size:595.3pt 841.9pt; margin:3.0cm 2.0cm 3.0cm 2.0cm;} div.Section1 {page:Section1;} --> </style> </head> <body lang=3DDA link=3Dblue vlink=3Dpurple> <div class=3DSection1> <p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US = style=3D'font-size: 10.0pt;font-family:Arial'>All,<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US = style=3D'font-size: 10.0pt;font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US = style=3D'font-size: 10.0pt;font-family:Arial'>I would like to revisit a subject that has = been discussed in the passed as consideration for future = work.<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US = style=3D'font-size: 10.0pt;font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US = style=3D'font-size: 10.0pt;font-family:Arial'>The SMIME Capabilities attribute, defined in = PKCS#9 is used in CMS as a signedAttribute (RFC 2633, </span></font><span = lang=3DEN-US>2.5.2 SMIMECapabilities Attribute</span><font size=3D2 face=3DArial><span = lang=3DEN-US style=3D'font-size:10.0pt;font-family:Arial'>) to carry information = about the cryptographic capabilities of an entity.<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US = style=3D'font-size: 10.0pt;font-family:Arial'>However the use of this extension can also be = useful to carry inside a certificate to communicate primary capabilities in = situation where no other prior knowledge of the other party = exist.<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US = style=3D'font-size: 10.0pt;font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US = style=3D'font-size: 10.0pt;font-family:Arial'>There are of course cases where it is = unsuitable to include such information in certificates, e.g. where the capabilities = changes over time within the validity period of the certificate, but there are = without doubt situations where it is useful.<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US = style=3D'font-size: 10.0pt;font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US = style=3D'font-size: 10.0pt;font-family:Arial'>Microsoft has since long successfully used the = PKCS#9 attribute OID to also identify a certificate extension with the same = syntax of this attribute, to include this information in certificates. I would = therefore suggest that PKIX consider standardizing this = practice.<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US = style=3D'font-size: 10.0pt;font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US = style=3D'font-size: 10.0pt;font-family:Arial'>This may also be an issue for the update of = RFC 2632 dependent on this work group’s opinion.<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US = style=3D'font-size: 10.0pt;font-family:Arial'><o:p> </o:p></span></font></p> <div> <div> <p class=3DMsoNormal><strong><b><font size=3D3 color=3Dolive = face=3D"Times New Roman"><span lang=3DEN-US style=3D'font-size:12.0pt;color:olive'>Stefan = Santesson</span></font></b></strong><font color=3Dblack><span lang=3DEN-US = style=3D'color:black'><o:p></o:p></span></font></p> </div> <div> <p class=3DMsoNormal><font size=3D2 color=3Dolive face=3DArial><span = lang=3DEN-US style=3D'font-size:10.0pt;font-family:Arial;color:olive'>Program = Manager, Windows Security</span></font><font size=3D2 color=3Dblack face=3DArial><span = lang=3DEN-US style=3D'font-size:10.0pt;font-family:Arial;color:black'><o:p></o:p></spa= n></font></p> </div> <div> <p class=3DMsoNormal><font size=3D1 color=3Dolive face=3DArial><span = lang=3DEN-US style=3D'font-size:7.5pt;font-family:Arial;color:olive'>Principal = Consultant, Microsoft <st1:country-region w:st=3D"on"><st1:place = w:st=3D"on">Denmark</st1:place></st1:country-region></span></font><font size=3D2 color=3Dblack face=3DArial><span lang=3DEN-US = style=3D'font-size:10.0pt; font-family:Arial;color:black'><o:p></o:p></span></font></p> </div> </div> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span = lang=3DEN-US style=3D'font-size:12.0pt'><o:p> </o:p></span></font></p> </div> </body> </html> ------_=_NextPart_001_01C418DA.93B68833-- ------=_NextPartTM-000-9219e7d0-b3e1-43af-bb98-272ff38359b6-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i32HCdsP090263; Fri, 2 Apr 2004 09:12:39 -0800 (PST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i32HCdnY090262; Fri, 2 Apr 2004 09:12:39 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i32HCcHA090254 for <ietf-pkix@imc.org>; Fri, 2 Apr 2004 09:12:38 -0800 (PST) (envelope-from kent@bbn.com) Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i32HCZ7X003164; Fri, 2 Apr 2004 12:12:35 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: <p06020421bc9348a57ac5@[128.89.89.75]> In-Reply-To: <OFEA3225F9.5CD662EF-ON85256E6A.0056B270@chase.com> References: <OFEA3225F9.5CD662EF-ON85256E6A.0056B270@chase.com> Date: Fri, 2 Apr 2004 11:47:32 -0500 To: Shaheen.Nasirudheen@chase.com From: Stephen Kent <kent@bbn.com> Subject: Re: PKI International Consortium Cc: "PKIX list" <ietf-pkix@imc.org> Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> At 10:57 AM -0500 4/2/04, Shaheen.Nasirudheen@chase.com wrote: >Hello everyone, > >I appreciate your feedback and most of the replies were referring to >identrus.com . My basic concern is from a customer's point of view. If I >have a digital certificate issued by a single authority that is considered >trusted internationally by all financial as well as other commercial >institutions, then I do not require to have a certificate for Institution >-1 and another for Institution -2. Do we have something in place that takes >of this issue. I would be happy to carry and protect that one certificate >which is trusted by everyone. > >Thank you, > >Shaheen Nasirudheen >JPMorgan ACCESS, Portal Security >978 805 1815 > The notion of the one cert that is good for everything is probably never going to be a reality, fortunately. Note there there are no physical credentials that have this property. Why would you believe that digital credentials could overcome the organizational obstacles that contribute to the existence of context-limited credentials? Moreover, consider the awful consequences associated with a compromise of the private key associated with such a cert, if it existed. Steve Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i32GKElI086086; Fri, 2 Apr 2004 08:20:14 -0800 (PST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i32GKEWi086085; Fri, 2 Apr 2004 08:20:14 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from av5-2-sn4.m-sp.skanova.net (av5-2-sn4.m-sp.skanova.net [81.228.10.111]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i32GKDRt086072 for <ietf-pkix@imc.org>; Fri, 2 Apr 2004 08:20:14 -0800 (PST) (envelope-from anders.rundgren@telia.com) Received: by av5-2-sn4.m-sp.skanova.net (Postfix, from userid 502) id 9226937E8A; Fri, 2 Apr 2004 18:20:11 +0200 (CEST) Received: from smtp2-2-sn4.m-sp.skanova.net (smtp2-2-sn4.m-sp.skanova.net [81.228.10.182]) by av5-2-sn4.m-sp.skanova.net (Postfix) with ESMTP id 8149B37E49; Fri, 2 Apr 2004 18:20:11 +0200 (CEST) Received: from arport (t8o913p21.telia.com [213.64.26.141]) by smtp2-2-sn4.m-sp.skanova.net (Postfix) with SMTP id 523EF37E5C; Fri, 2 Apr 2004 18:20:10 +0200 (CEST) Message-ID: <010601c418d5$c0f997e0$0500a8c0@arport> From: "Anders Rundgren" <anders.rundgren@telia.com> To: "PKIX list" <ietf-pkix@imc.org>, <Shaheen.Nasirudheen@chase.com> References: <OFEA3225F9.5CD662EF-ON85256E6A.0056B270@chase.com> Subject: Re: PKI International Consortium Date: Fri, 2 Apr 2004 19:13:00 +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 Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Shaheen, I believe this is a *very* good idea which I have touted myself. The problem I see, is that FIs do not accept the open PKI approach which makes their offers less tasteful. That is, FIs (unlike practically all other CAs) force each relying party to: - Have a contract with each FI trust network - Install the trust network's proprietary (often licensed) verification software - Get and install a unique ID from the relying party's FI http://w1.181.telia.com/~u18116613/e-government-ID-A.Rundgren.pdf Due to this, I believe we will not get this wonderful PKI that you and I dream of but rather stay with an ocean of highly variant and incompatible "security solutions". Anders ----- Original Message ----- From: <Shaheen.Nasirudheen@chase.com> To: "PKIX list" <ietf-pkix@imc.org> Cc: "Anders Rundgren" <anders.rundgren@telia.com> Sent: Friday, April 02, 2004 17:57 Subject: Re: PKI International Consortium Hello everyone, I appreciate your feedback and most of the replies were referring to identrus.com . My basic concern is from a customer's point of view. If I have a digital certificate issued by a single authority that is considered trusted internationally by all financial as well as other commercial institutions, then I do not require to have a certificate for Institution -1 and another for Institution -2. Do we have something in place that takes of this issue. I would be happy to carry and protect that one certificate which is trusted by everyone. Thank you, Shaheen Nasirudheen JPMorgan ACCESS, Portal Security 978 805 1815 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i32G40pc085042; Fri, 2 Apr 2004 08:04:00 -0800 (PST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i32G40tO085041; Fri, 2 Apr 2004 08:04:00 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from emampe17.jpmchase.com (mailms.chase.com [170.148.48.205]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i32G3xbl085033 for <ietf-pkix@imc.org>; Fri, 2 Apr 2004 08:03:59 -0800 (PST) (envelope-from Shaheen.Nasirudheen@chase.com) Received: J.P. Morgan Chase & Co.; Fri, 2 Apr 2004 11:03:37 -0500 (EST); Message Subject: Re: PKI International Consortium To: "PKIX list" <ietf-pkix@imc.org> Cc: "Anders Rundgren" <anders.rundgren@telia.com> X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: <OFEA3225F9.5CD662EF-ON85256E6A.0056B270@chase.com> From: Shaheen.Nasirudheen@chase.com Date: Fri, 2 Apr 2004 10:57:19 -0500 X-MIMETrack: Serialize by Router on EMAMPE12/CHASE(Release 5.0.8 |June 18, 2001) at 04/02/2004 10:59:06 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Hello everyone, I appreciate your feedback and most of the replies were referring to identrus.com . My basic concern is from a customer's point of view. If I have a digital certificate issued by a single authority that is considered trusted internationally by all financial as well as other commercial institutions, then I do not require to have a certificate for Institution -1 and another for Institution -2. Do we have something in place that takes of this issue. I would be happy to carry and protect that one certificate which is trusted by everyone. Thank you, Shaheen Nasirudheen JPMorgan ACCESS, Portal Security 978 805 1815 ----------------------------------- This message may contain legally privileged and/or confidential information. If you are not the intended recipient(s), or the employee or agent responsible for delivery of this message to the intended recipient(s), you are hereby notified that any dissemination, distribution or copying of this message is strictly prohibited. If you have received this message in error, please immediately notify the sender and delete this e-mail message from your computer. "Anders Rundgren" <anders.rundgren@ To: "PKIX list" <ietf-pkix@imc.org>, Shaheen telia.com> Nasirudheen/JPMCHASE@JPMCHASE cc: 04/02/2004 11:28 Subject: Re: PKI International Consortium AM Hi Shaheen, There are several PKIs run by FIs, even on an international level. However, I have some difficulties with the phrase "certificates for the members"? Is a "member" an FI organization, FI employee or an FI customer? For the premier category I believe VISA does that for the 3D Secure network. For FI employees I don't know if there really is any big need for such as these certificates have little use except internally. Well, Identrus have indeed sold such services to a few banks. Regarding the third category, it is interesting to note that banks seem to take the lead in issuing "citizen-certificates" as a citizen=bank customer. These FA CAs are though not really international due to some basic problems like the lack of standards for expressing citizen identities in various regimes. Here the customer is really e-governments although the certificates can often be used for on-line banking as well. www.identrus.com www.bankid.com www.bankid.no Anders ----- Original Message ----- From: <Shaheen.Nasirudheen@chase.com> To: "PKIX list" <ietf-pkix@imc.org> Sent: Thursday, April 01, 2004 16:30 Subject: PKI International Consortium Hello, I would like to know if there is any international consortium of financial institutions that maintain a PKI and issues certificates for the members. If so, what are the standards followed? Any information would be helpful. Regards. Shaheen Nasirudheen JPMorgan ACCESS, Portal Security ----------------------------------- This message may contain legally privileged and/or confidential information. If you are not the intended recipient(s), or the employee or agent responsible for delivery of this message to the intended recipient(s), you are hereby notified that any dissemination, distribution or copying of this message is strictly prohibited. If you have received this message in error, please immediately notify the sender and delete this e-mail message from your computer. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i32FZRAp083266; Fri, 2 Apr 2004 07:35:27 -0800 (PST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i32FZRZH083265; Fri, 2 Apr 2004 07:35:27 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from av3-1-sn4.m-sp.skanova.net (av3-1-sn4.m-sp.skanova.net [81.228.10.114]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i32FZQKQ083259 for <ietf-pkix@imc.org>; Fri, 2 Apr 2004 07:35:27 -0800 (PST) (envelope-from anders.rundgren@telia.com) Received: by av3-1-sn4.m-sp.skanova.net (Postfix, from userid 502) id ACFA837E6D; Fri, 2 Apr 2004 17:35:23 +0200 (CEST) Received: from smtp2-2-sn4.m-sp.skanova.net (smtp2-2-sn4.m-sp.skanova.net [81.228.10.182]) by av3-1-sn4.m-sp.skanova.net (Postfix) with ESMTP id 9E10B37E5F; Fri, 2 Apr 2004 17:35:23 +0200 (CEST) Received: from arport (t8o913p21.telia.com [213.64.26.141]) by smtp2-2-sn4.m-sp.skanova.net (Postfix) with SMTP id 221A037E45; Fri, 2 Apr 2004 17:35:22 +0200 (CEST) Message-ID: <00e201c418cf$7ecc6d80$0500a8c0@arport> From: "Anders Rundgren" <anders.rundgren@telia.com> To: "PKIX list" <ietf-pkix@imc.org>, <Shaheen.Nasirudheen@chase.com> References: <OFD3D971BA.CBBF9607-ON85256E69.004E7787@chase.com> Subject: Re: PKI International Consortium Date: Fri, 2 Apr 2004 18:28:12 +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 Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Hi Shaheen, There are several PKIs run by FIs, even on an international level. However, I have some difficulties with the phrase "certificates for the members"? Is a "member" an FI organization, FI employee or an FI customer? For the premier category I believe VISA does that for the 3D Secure network. For FI employees I don't know if there really is any big need for such as these certificates have little use except internally. Well, Identrus have indeed sold such services to a few banks. Regarding the third category, it is interesting to note that banks seem to take the lead in issuing "citizen-certificates" as a citizen=bank customer. These FA CAs are though not really international due to some basic problems like the lack of standards for expressing citizen identities in various regimes. Here the customer is really e-governments although the certificates can often be used for on-line banking as well. www.identrus.com www.bankid.com www.bankid.no Anders ----- Original Message ----- From: <Shaheen.Nasirudheen@chase.com> To: "PKIX list" <ietf-pkix@imc.org> Sent: Thursday, April 01, 2004 16:30 Subject: PKI International Consortium Hello, I would like to know if there is any international consortium of financial institutions that maintain a PKI and issues certificates for the members. If so, what are the standards followed? Any information would be helpful. Regards. Shaheen Nasirudheen JPMorgan ACCESS, Portal Security ----------------------------------- This message may contain legally privileged and/or confidential information. If you are not the intended recipient(s), or the employee or agent responsible for delivery of this message to the intended recipient(s), you are hereby notified that any dissemination, distribution or copying of this message is strictly prohibited. If you have received this message in error, please immediately notify the sender and delete this e-mail message from your computer. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i32BkHnA068065; Fri, 2 Apr 2004 03:46:18 -0800 (PST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i32BkHGL068062; Fri, 2 Apr 2004 03:46:17 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from iapetus.salford.ac.uk (iapetus.salford.ac.uk [146.87.255.98]) by above.proper.com (8.12.11/8.12.8) with SMTP id i32BkGte068048 for <ietf-pkix@imc.org>; Fri, 2 Apr 2004 03:46:17 -0800 (PST) (envelope-from D.W.Chadwick@salford.ac.uk) Received: (qmail 56985 invoked by uid 1236); 2 Apr 2004 11:46:15 -0000 Received: from D.W.Chadwick@salford.ac.uk by pan.salford.ac.uk by uid 401 with qmail-scanner-1.20 (clamuko: 0.65. uvscan: v4.2.40/v4346. spamassassin: 2.61. Clear:RC:1(146.87.80.150):. Processed in 0.361687 secs); 02 Apr 2004 11:46:15 -0000 Received: from [146.87.80.150] (HELO salford.ac.uk) (146.87.80.150) by iapetus.salford.ac.uk (qpsmtpd/0.27-dev) with ESMTP; Fri, 02 Apr 2004 12:46:14 +0100 Message-ID: <406D5284.A9CCCBD4@salford.ac.uk> Date: Fri, 02 Apr 2004 12:46:12 +0100 From: "D.W.Chadwick" <D.W.Chadwick@salford.ac.uk> Organization: University of Salford X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: PKIX <ietf-pkix@imc.org> Subject: CMS 2004 Content-Type: multipart/mixed; boundary="------------ACE07760760F823563D789A0" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> This is a multi-part message in MIME format. --------------ACE07760760F823563D789A0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Dear All The CMS 2004 call for papers closes in just under a fortnight. CMS 2004 is the eighth working conference in Communications and Multimedia Security since 1995. This year it will take place in the Lake District, England. CMS 2004 is a joint working conference of IFIP TC6 and TC11. All papers will be blind reviewed by a set of distinguished referees (see below) and accepted papers will be published in the conference proceedings by Kluwer Academic Publishers. The call for papers can be downloaded from http://sec.isi.salford.ac.uk/cms2004/CallForPapers/index.html The Programme Committee comprises David Chadwick, Program Chair, University of Salford, UK Jean Bacon, University of Cambridge, UK Steve Bellovin, AT&T Research, USA Elisa Bertino, CERIAS, Purdue University, USA Howard Chivers, University of York, UK Stephen Farrell, Trinity College Dublin, Ireland Russ Housley, Vigil Security, USA Stephen Kent, BBN Technologies, USA Herbert Leitold, TU Gratz, Austria Javier Lopez, University of Malaga, Spain Chris Mitchell, Royal Holloway College, UK Ken Moody, University of Cambridge, UK Sead Muftic, Stockholm University, Sweden Sassa Otenko, University of Salford, UK Günther Pernul, University of Regensburg. Germany Bart Preneel, Katholieke Universiteit Leuven, Belgium Pierangela Samarati, University of Milan, Italy Wolfgang Schneider, Fraunhofer SIT, Germany Frank Siebenlist, Argonne National Laboratory, USA Otto Spaniol, Chairman of TC6, Aachen University, Germany Leon Strous, Chairman of TC11, De Nederlandsche Bank, Netherlands Mary Thompson, Lawrence Berkeley Laboratory, USA regards David ***************************************************************** David W. Chadwick, BSc PhD Professor of Information Systems Security IS Institute, University of Salford, Salford M5 4WT Tel: +44 161 295 5351 Fax +44 1484 532930 Mobile: +44 77 96 44 7184 Email: D.W.Chadwick@salford.ac.uk Home Page: http://www.salford.ac.uk/its024/chadwick.htm Research Web site: http://sec.isi.salford.ac.uk Entrust key validation string: MLJ9-DU5T-HV8J PGP Key ID is 0xBC238DE5 ***************************************************************** --------------ACE07760760F823563D789A0 Content-Type: text/x-vcard; charset=us-ascii; name="d.w.chadwick.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for David Chadwick Content-Disposition: attachment; filename="d.w.chadwick.vcf" begin:vcard n:Chadwick;David tel;cell:+44 77 96 44 7184 tel;fax:+44 1484 532930 tel;home:+44 1484 352238 tel;work:+44 161 295 5351 x-mozilla-html:FALSE url:http://sec.isi.salford.ac.uk org:University of Salford;IS Institute version:2.1 email;internet:d.w.chadwick@salford.ac.uk title:Professor of Information Security adr;quoted-printable:;;The Crescent=0D=0A;Salford;Greater Manchester;M5 4WT;England note;quoted-printable:Research Projects: http://sec.isi.salford.ac.uk=0D=0A=0D=0AEntrust key validation string: CJ94-LKWD-BSXB ...........=0D=0A=0D=0APGP Key ID is 0xBC238DE5 x-mozilla-cpt:;-18752 fn:David Chadwick end:vcard --------------ACE07760760F823563D789A0-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i320I8FX041852; Thu, 1 Apr 2004 16:18:08 -0800 (PST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i320I8M8041851; Thu, 1 Apr 2004 16:18:08 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i320I7NS041845 for <ietf-pkix@imc.org>; Thu, 1 Apr 2004 16:18:07 -0800 (PST) (envelope-from mmyers@fastq.com) Received: from MMyersLapTop ([65.39.77.135]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id i320IBw90903; Thu, 1 Apr 2004 17:18:11 -0700 (MST) (envelope-from mmyers@fastq.com) From: "Michael Myers" <mmyers@fastq.com> To: "Dave Engberg" <dengberg@corestreet.com>, <ietf-pkix@imc.org> Subject: RE: Signing Untrusted SCVP? Date: Thu, 1 Apr 2004 17:18:56 -0700 Message-ID: <EOEGJNFMMIBDKGFONJJDAELLDMAA.mmyers@fastq.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <DE909E05406F3340B186DA5A410B05F642A214@mongo.corestreet.com> Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Dave, Your analysis is consistent with original intent. We may have some work in front of us. Mike -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org]On Behalf Of Dave Engberg Sent: Thursday, April 01, 2004 3:43 PM To: ietf-pkix@imc.org Subject: Signing Untrusted SCVP? Section 1.1 of the SCVP draft specification has a nice justification for supporting pure DPD to avoid the security and scalability problems of DPV: SCVP can be used by clients that do much of the certificate processing themselves but simply want an untrusted server to collect information for them. ... Untrusted SCVP servers can provide clients the certification paths. They can also provide clients revocation information, such as CRLs and OCSP responses, and the client needs to validate the certification path constructed by the SCVP server. Validating the received path on the client requires a competent local validation engine, but avoids the first security concern listed in section 10: A client that trusts a server's response for validation of a certificate inherently trusts that server as much as it would trust its own validation software. This means that if an attacker compromises a trusted SCVP server, the attacker can change the validation processing for every client that relies on that server. Thus, an SCVP server must be protected at least as well as the trust anchors that the SCVP server trusts. Rather than trying to protect _every_ SCVP server to the same level as a root CA, DPD through "Untrusted SCVP" maintains end-to-end PKI security integrity between clients. Given that the spec goes to some lengths to support pure DPD by clients, why is there a requirement (section 3) that every SCVP response be digitally signed? In Untrusted mode, clients MUST ignore any signature from the SCVP server and independently verify the certificate chain and any extra CRLs, OCSP responses, etc. The extra dynamic signature around the entire package is gratuitously expensive overhead (latency, bandwidth, $20k HSM). It would make sense (to me, obviously) to make the signature optional, and possibly add a request flag indicating Untrusted mode. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i31MiK3o035510; Thu, 1 Apr 2004 14:44:20 -0800 (PST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i31MiKqk035509; Thu, 1 Apr 2004 14:44:20 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mongo.corestreet.com (mongo.corestreet.com [68.162.232.130]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i31MiJoo035492 for <ietf-pkix@imc.org>; Thu, 1 Apr 2004 14:44:20 -0800 (PST) (envelope-from dengberg@corestreet.com) X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: Signing Untrusted SCVP? Date: Thu, 1 Apr 2004 17:43:26 -0500 Message-ID: <DE909E05406F3340B186DA5A410B05F642A214@mongo.corestreet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Signing Untrusted SCVP? thread-index: AcQYOt4lw//LlfHkROGzcSxTWp9omg== From: "Dave Engberg" <dengberg@corestreet.com> To: <ietf-pkix@imc.org> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i31MiKoo035504 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Section 1.1 of the SCVP draft specification has a nice justification for supporting pure DPD to avoid the security and scalability problems of DPV: SCVP can be used by clients that do much of the certificate processing themselves but simply want an untrusted server to collect information for them. ... Untrusted SCVP servers can provide clients the certification paths. They can also provide clients revocation information, such as CRLs and OCSP responses, and the client needs to validate the certification path constructed by the SCVP server. Validating the received path on the client requires a competent local validation engine, but avoids the first security concern listed in section 10: A client that trusts a server's response for validation of a certificate inherently trusts that server as much as it would trust its own validation software. This means that if an attacker compromises a trusted SCVP server, the attacker can change the validation processing for every client that relies on that server. Thus, an SCVP server must be protected at least as well as the trust anchors that the SCVP server trusts. Rather than trying to protect _every_ SCVP server to the same level as a root CA, DPD through "Untrusted SCVP" maintains end-to-end PKI security integrity between clients. Given that the spec goes to some lengths to support pure DPD by clients, why is there a requirement (section 3) that every SCVP response be digitally signed? In Untrusted mode, clients MUST ignore any signature from the SCVP server and independently verify the certificate chain and any extra CRLs, OCSP responses, etc. The extra dynamic signature around the entire package is gratuitously expensive overhead (latency, bandwidth, $20k HSM). It would make sense (to me, obviously) to make the signature optional, and possibly add a request flag indicating Untrusted mode. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i31H62st010782; Thu, 1 Apr 2004 09:06:02 -0800 (PST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i31H62gc010781; Thu, 1 Apr 2004 09:06:02 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mtiwmhc12.worldnet.att.net (mtiwmhc12.worldnet.att.net [204.127.131.116]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i31H6141010760; Thu, 1 Apr 2004 09:06:01 -0800 (PST) (envelope-from todd.glassey@worldnet.att.net) Received: from gw (223.san-jose-06-08rs.ca.dial-access.att.net[12.72.194.223]) by worldnet.att.net (mtiwmhc12) with SMTP id <200404011705541120085274e>; Thu, 1 Apr 2004 17:05:55 +0000 Message-ID: <003701c4180b$860c0ca0$010aff0a@gw> From: "todd glassey" <todd.glassey@worldnet.att.net> To: "Russ Housley" <housley@vigilsec.com>, "Tim Polk" <tim.polk@nist.gov>, <ietf-pkix@imc.org>, "Paul Hoffman / IMC" <phoffman@imc.org> References: <5.2.0.9.2.20040329081825.049f3348@mail.binhost.com> <5.1.0.14.2.20040326160906.02f9d000@email.nist.gov> <5.1.0.14.2.20040326160906.02f9d000@email.nist.gov> <5.2.0.9.2.20040329081825.049f3348@mail.binhost.com> <5.2.0.9.2.20040329102417.01fddfc8@mail.binhost.com> <p0610040bbc8df1b47c25@[63.202.92.152]> Subject: Re: WG Last Call: SHA-224 Date: Thu, 1 Apr 2004 08:56:44 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> So then why complicate the world with another standard... why not just add to the SHA256 spec a subsection on 224 usage? and then its not a separate document at all... Todd ----- Original Message ----- From: "Paul Hoffman / IMC" <phoffman@imc.org> To: "Russ Housley" <housley@vigilsec.com>; "Tim Polk" <tim.polk@nist.gov>; <ietf-pkix@imc.org> Sent: Monday, March 29, 2004 7:41 AM Subject: Re: WG Last Call: SHA-224 > > At 10:25 AM -0500 3/29/04, Russ Housley wrote: > >Paul: > > > >>At 8:21 AM -0500 3/29/04, Russ Housley wrote: > >>>I understand that the computation expense is the same as SHA-256. > >>>However, as you point out, there are times that a shorter hash > >>>value is desirable. > >> > >>Do we agree that the only times where it is desirable is in > >>severely bandwidth-restricted environments? Or am I missing some > >>other scenario? > > > >It is also useful is you want all of the algorithms in a cipher > >suite to offer the same strength. I remember a SAAG discussion that > >this was called "impedance match," but I do not particularly like > >that term. > > This is all the more reason to put material in the document that > tells protocol designers what the design goals for SHA-224 are. Such > wording should explicitly say that SHA-224 SHOULD NOT be used with > AES-128 or other asymmetric ciphers that have greater than 112 bits > of strength. > > The reason I am hammering on this is that it is somewhat absurd to > purposely reduce the strength of one of the algorithms in a cipher > suite just so it "matches". For example, assume that someone this > year discovers a trivial method for reducing the effective strength > of TripleDES from 112 to 108 bits. Clearly, no one is going to stop > using TripleDES or a suite that uses TripleDES. But, using the logic > that prompted the creation of SHA-224, we will need a new RFC that > specifies SHA-216 by shaving off eight more bits from the SHA-256 > result. > > Instead of this progression, we should be giving protocol designers > advice that says "it is fine to use a hash algorithm that produces > more bits than are needed to 'match' the symmetric key strength". > > --Paul Hoffman, Director > --Internet Mail Consortium > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i31EmJNo099382; Thu, 1 Apr 2004 06:48:19 -0800 (PST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i31EmJ2u099381; Thu, 1 Apr 2004 06:48:19 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from emampe14.jpmchase.com (mailms.chase.com [170.148.48.205]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i31EmIeL099372 for <ietf-pkix@imc.org>; Thu, 1 Apr 2004 06:48:18 -0800 (PST) (envelope-from Shaheen.Nasirudheen@chase.com) Received: J.P. Morgan Chase & Co.; Thu, 1 Apr 2004 09:48:05 -0500 (EST); Message for <ietf-pkix@imc.org> Subject: PKI International Consortium To: PKIX list <ietf-pkix@imc.org> X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: <OFD3D971BA.CBBF9607-ON85256E69.004E7787@chase.com> From: Shaheen.Nasirudheen@chase.com Date: Thu, 1 Apr 2004 09:30:16 -0500 X-MIMETrack: Serialize by Router on EMAMPE12/CHASE(Release 5.0.8 |June 18, 2001) at 04/01/2004 09:43:35 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Hello, I would like to know if there is any international consortium of financial institutions that maintain a PKI and issues certificates for the members. If so, what are the standards followed? Any information would be helpful. Regards. Shaheen Nasirudheen JPMorgan ACCESS, Portal Security ----------------------------------- This message may contain legally privileged and/or confidential information. If you are not the intended recipient(s), or the employee or agent responsible for delivery of this message to the intended recipient(s), you are hereby notified that any dissemination, distribution or copying of this message is strictly prohibited. If you have received this message in error, please immediately notify the sender and delete this e-mail message from your computer.
- SMIME Capabilities in X.509 certificates. Stefan Santesson
- Re: SMIME Capabilities in X.509 certificates. Stephen Kent
- RE: SMIME Capabilities in X.509 certificates. Stefan Santesson
- RE: SMIME Capabilities in X.509 certificates. Stefan Santesson
- Re: SMIME Capabilities in X.509 certificates. David A. Cooper
- RE: SMIME Capabilities in X.509 certificates. Santosh Chokhani
- RE: SMIME Capabilities in X.509 certificates. Guida, Richard [JJCUS]
- RE: SMIME Capabilities in X.509 certificates. Trevor Freeman
- RE: SMIME Capabilities in X.509 certificates. Guida, Richard [JJCUS]
- RE: SMIME Capabilities in X.509 certificates. Hallam-Baker, Phillip
- RE: SMIME Capabilities in X.509 certificates. Stefan Santesson