Last Call: 'Internet X.509 Public Key Infrastructure Authority Information Access CRL Extension' to Proposed Standard

The IESG has received a request from the Public-Key Infrastructure (X.509) WG 
to consider the following document:

- 'Internet X.509 Public Key Infrastructure Authority Information Access CRL 
   Extension '
   <draft-ietf-pkix-crlaia-02.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
iesg@ietf.org or ietf@ietf.org mailing lists by 2005-08-12.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-02.txt

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 j716ZQwl083660; Sun, 31 Jul 2005 23:35: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 j716ZQji083659; Sun, 31 Jul 2005 23:35:26 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from mailbo.vtcif.telstra.com.au (mailbo.vtcif.telstra.com.au [202.12.144.19]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j716ZOfI083640 for <ietf-pkix@imc.org>; Sun, 31 Jul 2005 23:35:25 -0700 (PDT) (envelope-from James.H.Manger@team.telstra.com)
Received: from mailbi.vtcif.telstra.com.au (mailbi.vtcif.telstra.com.au [202.12.142.19]) by mailbo.vtcif.telstra.com.au (Postfix) with ESMTP id 97C4822EA4 for <ietf-pkix@imc.org>; Mon,  1 Aug 2005 16:35:22 +1000 (EST)
Received: from mail2.cdn.telstra.com.au (localhost [127.0.0.1]) by mailbi.vtcif.telstra.com.au (Postfix) with ESMTP id E59061DA83 for <ietf-pkix@imc.org>; Mon,  1 Aug 2005 16:35:21 +1000 (EST)
Received: from wsmsg2902.srv.dir.telstra.com (wsmsg2902.srv.dir.telstra.com [172.49.40.51]) by mail2.cdn.telstra.com.au (Postfix) with ESMTP id 96D0C41F6A for <ietf-pkix@imc.org>; Mon,  1 Aug 2005 16:35:21 +1000 (EST)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Subject: RE: IDP indirectCRL flag
Date: Mon, 1 Aug 2005 16:31:38 +1000
Message-ID: <73388857A695D31197EF00508B08F298179D26C4@ntmsg0131.corpmail.telstra.com.au>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: IDP indirectCRL flag
Thread-Index: AcWSmA3UDAxqa3viQe2M71LoPAo3DQAbHC3w
From: "Manger, James H" <James.H.Manger@team.telstra.com>
To: "pkix" <ietf-pkix@imc.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by above.proper.com id j716ZPfI083653
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

> When a CA wants to delegate to another entity the responsibility
> to issue revocation status information, the conditions are negotatied.

I agree.

> Among the conditions, the CRL Issuer will have to accept to work
> (under a given name) only for that single CA...
> If the CRL Isssuer does not accept, then the CRL Issuer certificate
> is not issued.

Ahhhhh.  I understand that some CRL issuers would agree to work only for a single CA.  I didn't realise you were mandating this new rule for all CRL issuers.  If you could mandate this new rule for all CRL issuers then Denis's rules could work.

The problem is that trying to mandate an additional rule for all CRL issuers over and above X.509, RFC2459 & RFC3280 (even to existing CRL issuers and to authorities not claiming compliance to RFC3280bis) is untenable.

Currently, a CA can issue a CRL just for its own certificates (without IDP) regardless of whether it issues revocation information for 0, 1 or more other CAs.  Denis's rules would forbid this (without actually saying so!) as such a CRL would be ambiguous.  A relying party could not tell if the listed certificate numbers were from the authority that issued the CRL or from any authority that issued a CRL issuer certificate to that authority.  Denis's rules also forbid a CRL issuer being certified by more 2 or more CAs, as that would also cause ambiguity.

Another way to tell how awkward Denis's rules make CRL processing is to consider a simple CA that issues its own CRLs.  It has a certificate from a parent CA with the cRLSign bit set.  It issues CRLs without IDP.  A "standard" relying party seeing this certificate and CRL would know straight away which certificates are revoked.  A relying party implementing Denis's rule would not.  It cannot tell if the CRL issuer is revoking its own certificates or acting as delegate for another CA.  This confusion might be resolved once the CRL matches a certificate, but you have already complicated the software and lost some opportunities for optimisation.

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 j6TMqeIB062836; Fri, 29 Jul 2005 15:52: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 j6TMqefM062835; Fri, 29 Jul 2005 15:52:40 -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 (rimp2.nist.gov [129.6.16.227]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6TMqd3v062827 for <ietf-pkix@imc.org>; Fri, 29 Jul 2005 15:52:39 -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.13.1/8.13.1) with ESMTP id j6TMqXic017556 for <ietf-pkix@imc.org>; Fri, 29 Jul 2005 18:52:33 -0400
Received: from [129.6.54.72] (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id j6TMq36u004608 for <ietf-pkix@imc.org>; Fri, 29 Jul 2005 18:52:03 -0400 (EDT)
Message-ID: <42EAB31B.2020705@nist.gov>
Date: Fri, 29 Jul 2005 18:52:11 -0400
From: "David A. Cooper" <david.cooper@nist.gov>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040804
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: pkix <ietf-pkix@imc.org>
Subject: draft-ietf-pkix-scvp-20.txt now available
References: <42E93CBE.5030209@nist.gov>
In-Reply-To: <42E93CBE.5030209@nist.gov>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: david.cooper@nist.gov
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <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,

Tim and I have fixed the problems with SCVP draft 19 that I mentioned 
below.  The corrected version is available at

    http://csrc.nist.gov/pki/documents/PKIX/draft-ietf-pkix-scvp-20.txt

Draft 20 now incorporates changes that were made to the document as a 
result of discussions during the March IETF meeting.

Dave

David A. Cooper wrote:

>
> All,
>
> Tim Polk and I discovered a problem with the version of SCVP that was 
> posted as draft 19.  Due to a mistake on our part, the document that 
> was posted does not include several changes that we made to the 
> document during the IETF meeting in March.  We will try put together a 
> draft 20 before next week's meeting and then post that draft to the 
> NIST Web site.  After next week's meeting, we will submit draft 20 for 
> posting on the IETF Web site.
>
> Sorry about the confusion.
>
> Dave

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 j6TCVLO0073375; Fri, 29 Jul 2005 05:31: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 j6TCVLkh073374; Fri, 29 Jul 2005 05:31:21 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from newodin.ietf.org ([132.151.6.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6TCVKUl073366 for <ietf-pkix@imc.org>; Fri, 29 Jul 2005 05:31:21 -0700 (PDT) (envelope-from apache@newodin.ietf.org)
Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1DyU1I-0005m7-D9; Fri, 29 Jul 2005 08:31:20 -0400
X-test-idtracker: no
To: IETF-Announce <ietf-announce@ietf.org>
From: The IESG <iesg-secretary@ietf.org>
Subject: Last Call: 'Internet X.509 Public Key Infrastructure Authority  Information Access CRL Extension' to Proposed Standard 
Reply-to: iesg@ietf.org
CC: <ietf-pkix@imc.org>
Message-Id: <E1DyU1I-0005m7-D9@newodin.ietf.org>
Date: Fri, 29 Jul 2005 08:31:20 -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>

The IESG has received a request from the Public-Key Infrastructure (X.509) WG 
to consider the following document:

- 'Internet X.509 Public Key Infrastructure Authority Information Access CRL 
   Extension '
   <draft-ietf-pkix-crlaia-02.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
iesg@ietf.org or ietf@ietf.org mailing lists by 2005-08-12.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-02.txt

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 j6SKFLrv050283; Thu, 28 Jul 2005 13:15: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 j6SKFLmH050282; Thu, 28 Jul 2005 13:15:21 -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 (rimp2.nist.gov [129.6.16.227]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6SKFK9m050273 for <ietf-pkix@imc.org>; Thu, 28 Jul 2005 13:15:20 -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.13.1/8.13.1) with ESMTP id j6SKFHmC001368 for <ietf-pkix@imc.org>; Thu, 28 Jul 2005 16:15:18 -0400
Received: from [129.6.54.72] (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id j6SKEn6u004743 for <ietf-pkix@imc.org>; Thu, 28 Jul 2005 16:14:49 -0400 (EDT)
Message-ID: <42E93CBE.5030209@nist.gov>
Date: Thu, 28 Jul 2005 16:14:54 -0400
From: "David A. Cooper" <david.cooper@nist.gov>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040804
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: pkix <ietf-pkix@imc.org>
Subject: Problem with draft-ietf-pkix-scvp-19.txt
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: david.cooper@nist.gov
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <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,

Tim Polk and I discovered a problem with the version of SCVP that was 
posted as draft 19.  Due to a mistake on our part, the document that was 
posted does not include several changes that we made to the document 
during the IETF meeting in March.  We will try put together a draft 20 
before next week's meeting and then post that draft to the NIST Web 
site.  After next week's meeting, we will submit draft 20 for posting on 
the IETF Web site.

Sorry about the confusion.

Dave

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 j6SHGQ2r033333; Thu, 28 Jul 2005 10:16: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 j6SHGQSV033332; Thu, 28 Jul 2005 10:16:26 -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 j6SHGOFK033322 for <ietf-pkix@imc.org>; Thu, 28 Jul 2005 10:16:25 -0700 (PDT) (envelope-from Peter.Sylvester@edelweb.fr)
Received: from champagne.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id j6SHGNi01356; Thu, 28 Jul 2005 19:16:23 +0200 (MEST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/2.4); Thu, 28 Jul 2005 19:16:23 +0200 (MET DST)
Received: from [193.51.14.5] (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id TAA14252; Thu, 28 Jul 2005 19:16:22 +0200 (MET DST)
Message-ID: <42E912E6.3030305@edelweb.fr>
Date: Thu, 28 Jul 2005 19:16:22 +0200
From: Peter Sylvester <Peter.Sylvester@edelweb.fr>
User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Peter Sylvester <Peter.Sylvester@edelweb.fr>
CC: "David A. Cooper" <david.cooper@nist.gov>, pkix <ietf-pkix@imc.org>
Subject: Re: I-D ACTION:draft-ietf-pkix-scvp-01.txt
References: <E1DvKZw-0007on-JD@newodin.ietf.org> <42DEC295.7030803@nist.gov> <42DFDB64.9050605@edelweb.fr>
In-Reply-To: <42DFDB64.9050605@edelweb.fr>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090500060802030806000007"
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <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.

--------------ms090500060802030806000007
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

I add some remark/question to my previous list of items.

- Some of them seem wrong to me.

-  4.6 says that requestRef is a Hash if CVRequest as an option.

  it is allowed to have an anonymous CVRequest just encapsulated
  in a ContentInfo. How is the hash is to be calculated in this case?

  Is it meant to hash the whole ContentInfo or something else?

- A COPY of the CVRequest does not contain
  the authenticated attributes, at least this is what seems to
  be written. Is this intended that the content-type is
  not included in this case?

--------------ms090500060802030806000007
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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOpDCC
BHIwggLfoAMCAQICBgoMz+gAPzANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G
A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs
UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNTAxMDYxMjI3MTlaFw0wNzAzMTcxMjI3MTlaMHAx
CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ
S0kxNTAzBgNVBAMMLFBldGVyIFNZTFZFU1RFUiA8UGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIu
ZnI+MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDn/izyem7Z1pUP/gpQDSzeGA/ZP4vo
VaCxcPWyssTYTAl6csAql2IIcYNVb6funaMNOY1q5oSNtlguFpOK3atQElBIMsfSh0CTuvUq
q2QDz1nHWOB96aU8G81+ZmC+iQOCAdG3qKWvMOzC0SzxKGbhTqDsjBvfYYk1Jk/Rb5TK0wID
AQABo4IBLjCCASowYgYDVR0RBFswWYEaUGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIuZnKkOzA5
MQswCQYDVQQGEwJGUjEQMA4GA1UECgwHRWRlbFdlYjEYMBYGA1UEAwwPUGV0ZXIgU1lMVkVT
VEVSMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD
VR0fBEMwQTA/oD2gO4Y5aHR0cDovL2VkZWxwa2kuZWRlbHdlYi5mci9jcmwvRWRlbFBLSS1F
ZGVsV2ViLVBlcnNHRU4uY3JsMB0GA1UdDgQWBBSSHP6djxj58tIi5VvjJbMZMXC/fDAfBgNV
HSMEGDAWgBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUA
A4IBfAANZYiEkyDqsT43U83wHLSYMGcEfmisT+WQrAAoHdlcIsnlHnufGnfmdpg5yvCQpl2U
TI7/w3LdaItoWq5oMZitqdoPW8Z+jy2pkd/DqYG1MkpEyZ0PA37Zn5yigQXAk4Nox7Lgiom8
1WDNgPesNRX7PRNa+RkQcD8MasfbHcZ2ycs1SxUxiCy6BUzhgSB8cNb2t9LVWWynvWuK1Wa5
V2ZCd3PlbKsrbWH8pafpFWUQm0S2BfKUWLDG9cje5bL7p5EpV4a8gFpbD5dq+PPJglT0Dvs9
F0EcrfL2l3JxGIkZmW7sfiUoefB9hTS9m3/TGvXcne4RYpVpEHFV5TathMuHfKAti6PhSely
LCqdPq/T9DHLJekBY0EA2yiVcKQnRZk7/pz0HImCPADOHSOWffJtc9b+Ak6HSDD1PlOSDfT+
udnrqwSAiuNN3hx1olPNxzVDu3jgiTSJFf2XJ1TnmGMT4pJmx7vkJkdE9sZvpiZwdVws37Nr
LqhH5fMZMIIEcjCCAt+gAwIBAgIGCgzP6AA/MA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT
AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV
BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA1MDEwNjEyMjcxOVoXDTA3MDMxNzEy
MjcxOVowcDELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsMD1NlcnZp
Y2UgRWRlbFBLSTE1MDMGA1UEAwwsUGV0ZXIgU1lMVkVTVEVSIDxQZXRlci5TeWx2ZXN0ZXJA
ZWRlbHdlYi5mcj4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOf+LPJ6btnWlQ/+ClAN
LN4YD9k/i+hVoLFw9bKyxNhMCXpywCqXYghxg1Vvp+6dow05jWrmhI22WC4Wk4rdq1ASUEgy
x9KHQJO69SqrZAPPWcdY4H3ppTwbzX5mYL6JA4IB0beopa8w7MLRLPEoZuFOoOyMG99hiTUm
T9FvlMrTAgMBAAGjggEuMIIBKjBiBgNVHREEWzBZgRpQZXRlci5TeWx2ZXN0ZXJAZWRlbHdl
Yi5mcqQ7MDkxCzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQDDA9QZXRl
ciBTWUxWRVNURVIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF
BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2ViLmZyL2NybC9F
ZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFJIc/p2PGPny0iLlW+Mlsxkx
cL98MB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MAkGA1UdEwQCMAAwDQYJKoZI
hvcNAQEFBQADggF8AA1liISTIOqxPjdTzfActJgwZwR+aKxP5ZCsACgd2VwiyeUee58ad+Z2
mDnK8JCmXZRMjv/Dct1oi2harmgxmK2p2g9bxn6PLamR38OpgbUySkTJnQ8DftmfnKKBBcCT
g2jHsuCKibzVYM2A96w1Ffs9E1r5GRBwPwxqx9sdxnbJyzVLFTGILLoFTOGBIHxw1va30tVZ
bKe9a4rVZrlXZkJ3c+VsqyttYfylp+kVZRCbRLYF8pRYsMb1yN7lsvunkSlXhryAWlsPl2r4
88mCVPQO+z0XQRyt8vaXcnEYiRmZbux+JSh58H2FNL2bf9Ma9dyd7hFilWkQcVXlNq2Ey4d8
oC2Lo+FJ6XIsKp0+r9P0Mcsl6QFjQQDbKJVwpCdFmTv+nPQciYI8AM4dI5Z98m1z1v4CTodI
MPU+U5IN9P652eurBICK403eHHWiU83HNUO7eOCJNIkV/ZcnVOeYYxPikmbHu+QmR0T2xm+m
JnB1XCzfs2suqEfl8xkwggW0MIIDT6ADAgECAgYJ+oiVOzEwDQYJKoZIhvcNAQEFBQAwUjEL
MAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2UgRWRlbFBL
STEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDQxMDA3MTU0MzMwWhcNMTEwODEyMTU0
MzMwWjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2Vydmlj
ZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTjCCAZwwDQYJKoZI
hvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bcrJKIlnAPn6eH8V1M
ORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5JfuDjU6Aq0RzmjqTWDe
1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WLwHLA+sIKFzA/CCRt
qeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQNHeCgbUvebvAT9Hd
UGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy4DazzXfZosKeJATH
pyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38psgnVLtPPITgOZrS
cV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+EiISL7aJHQcJRoNB
CdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4G/MIG8MDoGA1UdHwQzMDEwL6AtoCuGKWh0
dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8GA1UdEwQIMAYBAf8C
AQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNV
HQ4EFgQUnuUPwRSVSRzdWl1enK7NAW8vlHkwHwYDVR0jBBgwFoAUqNkrj9SwZ7q9SVy8M/x3
UhG5Z50wDQYJKoZIhvcNAQEFBQADggJOAFZV+1m/H+Qud9iUQJnvZR8R/adID02c2B3aOUUy
4/4dxBb4UU1kW8DTUpD57Pjuocfvdg4AfQi7zgSQ8/NUGxNU4CPxtADZVrZtmrpKCjBh1tNz
QbNbdP91KtP+Di0BpidqNwG00CC9j2EnBY88AsqKE28Rmw4eQ9/M/q/GbXsAfEsHV0IQjM7u
US+usowZwm3Mwa5oF+6gmShSc/Wz8iIURxg4lTQto3AoBsiLJelq83I4XRQ0goXYGcM8xXYj
PDioidvY5pSfT4qBR1Bx/vh+xD2evWyFbpuB99iuuewoELX8db7P74QEHhw6Bv1yxLYXGamq
Uxo60WT/UCFjVSy3C/dLrraUZA4gh7Q5G+3/Fal62Qx+1rUEC2YbogEKggonklzUXA+sUbCf
Ad5nZQ0eSszwKt8jmYoHfQ6rUMde0ZJD08n5HAot9hpl9R65j9fdPz9uTeANcRocftHfgM7Y
rQyruWuFxgMUV80fD4RC9ej5KbLyO8jtgESjOCGXeJ95kXXP8vmW73xCYkJ9Pg7Op30o43l6
PV7vej3gdmSQISY+s+J3arz+bccljJCrKHBad3918/LjJ55sRtSb7mfQGti2UcxtJAa2NmUL
d+BIv0MUuC6+k2yIIQKcLbDuuk8lLJmwWuYt1OLHEskZxOm7D7nRwe7ZNlTIZvR/VFWxlY18
k488tH9qcusIw8+7uXeHOZHyFUOHMINJZO9mq9HwGMC4v1xiPwoAJkzFtHf3D9VAholjhEFg
d28aJSs6qN15PXDgDjptAl34eoUxggKuMIICqgIBATBlMFsxCzAJBgNVBAYTAkZSMRAwDgYD
VQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNVBAMTF0VkZWxQ
S0kgRWRlbFdlYiBQZXJzR0VOAgYKDM/oAD8wCQYFKw4DAhoFAKCCAZ8wGAYJKoZIhvcNAQkD
MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUwNzI4MTcxNjIyWjAjBgkqhkiG9w0B
CQQxFgQUWvXj72ncKDdhSbRJ1pKek6J613owUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D
BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC
ASgwdAYJKwYBBAGCNxAEMWcwZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEY
MBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVy
c0dFTgIGCgzP6AA/MHYGCyqGSIb3DQEJEAILMWegZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UE
ChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJ
IEVkZWxXZWIgUGVyc0dFTgIGCgzP6AA/MA0GCSqGSIb3DQEBAQUABIGAi0n4tQNPPpYpDQAi
71JXsoHE+fmZdAix3PuqyEFzlECaS5qO40DK0IxPSXZ0X3qMcUOeqTeYofuaTRMnUL5caLxv
RMXZcVCLMyq5HyuA1wXQpqQal+k2an/LvnpJqAJdAwig0oTohLWN5KqTGDIrUGeqdIZ5dd3s
4bbX0yfqkkwAAAAAAAA=
--------------ms090500060802030806000007--

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 j6SF0IIi020216; Thu, 28 Jul 2005 08: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 j6SF0Iea020215; Thu, 28 Jul 2005 08:00:18 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from smtprelay-us1.aopn-na.com (smtprelay-us1.aopn-na.com [12.174.169.100]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6SF0HAK020188 for <ietf-pkix@imc.org>; Thu, 28 Jul 2005 08:00:17 -0700 (PDT) (envelope-from Joel.Kazin@atosorigin.com)
Received: from usarx003.arl.us.origin-it.com (usarx003.arl.us.int.atosorigin.com [172.16.146.33]) by smtprelay-us1.aopn-na.com (Postfix) with ESMTP id 6CBC45FD58; Thu, 28 Jul 2005 10:00:02 -0500 (CDT)
Received: by usarx003.arl.us.int.atosorigin.com with Internet Mail Service (5.5.2448.0) id <PPMWTQNF>; Thu, 28 Jul 2005 10:00:02 -0500
Message-ID: <5.1.0.14.0.20050728110117.00b15a00@172.16.146.192>
From: "Kazin, Joel" <Joel.Kazin@atosorigin.com>
To: Denis Pinkas <denis.pinkas@bull.net>, pkix <ietf-pkix@imc.org>
Subject: Re: Re: 3280bis: KeyUsage NR/CC bit
Date: Thu, 28 Jul 2005 10:01:33 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C59385.077C970A"
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <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_01C59385.077C970A
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

That is fine.

At 10:45 AM 7/28/2005 -0500, Denis Pinkas wrote:

Jo=EBl,=20

See below :=20

>Extract from: draft-ietf-pkix-rfc3280bis-01.txt :=20
>=20
>=AB The nonRepudiation bit is asserted when the subject public key=20
>is used to verify digital signatures, other than signatures on=20
>certificates (bit 5) and CRLs (bit 6), used to provide a =
non-repudiation=20
>service which protects against the signing entity falsely denying=20
>some action. In the case of later conflict, a reliable third party may =

>determine the authenticity of the signed data =BB.=20
>=20
>I can live with the proposed ASN.1.=20
>=20
>I would however suggest to re-use some of the key words of X.509.=20
>In the last sentence "authenticity of the signed data" may be =
misleading=20
>since it is missing the notion of time. =20
>=20
>Proposal for a compromise with X.509 2000)/Cor.3 (04/2004):=20
>=20
>" The nonRepudiation bit is asserted when the subject public key=20
>is used to verify digital signatures, other than signatures on=20
>certificates (bit 5) and CRLs (bit 6), which are intended to signal=20
>that the signer is committing to the content being signed. =20
>In the case of later conflict, this allows to provide a =
non-repudiation=20
>service which protects against the signing entity falsely denying some =

>action =BB.=20

>Perhaps the following wording is better:=20

>The contentCommitment bit is asserted when the subject public key=20
>is used to verify digital signatures, other than signatures on=20
>certificates (bit 5) and CRLs (bit 6). It is intended to signal=20
>that the signer is intending to committ to the content being signed. =20
>In the case of later conflict, this may help a non-repudiation=20
>service provider to determine if the subject's claimed repudiation is =
true=20
>or false.=20

There would need to have the first and second sentence bundled =
together,=20
which means changing:=20
 =20
" (bit 6). It is intended "=20
into=20
" (bit 6) and is intended ".=20

The end result would be:=20

The contentCommitment bit is asserted when the subject public key=20
is used to verify digital signatures, other than signatures on=20
certificates (bit 5) and CRLs (bit 6) and is intended to signal=20
that the signer is intending to committ to the content being signed. =20
In the case of later conflict, this may help a non-repudiation=20
service provider to determine if the subject's claimed repudiation is =
true=20
or false.=20

Denis=20

>=20
>=20
>Denis=20
>=20
>PS: The original text from the TC of X.509 is:=20
>=20
>b) contentCommitment: for verifying digital signatures which=20
>are intended to signal that the signer is committing to the content =
being=20
>signed.=20
>The precise level of commitment, e.g. with the intent to be bound=20
>may be signaled by additional methods, e.g. certificate policy.=20
>=20
>Since a content commitment signing is considered to be a digitally =
signed=20
>transaction, the digitalSignature bit need not be set in the =
certificate.=20
>If it is set, it does not affect the level of commitment the signer =
has=20
>endowed in the signed content.=20
>=20
>Note that it is not incorrect to refer to this keyUsage bit using the=20
>identifier nonRepudiation. However, the use this identifier has been=20
>deprecated. Regardless of the identifier used, the semantics of this=20
>bit are as specified in this standard.=20
>=20
>=20
>Joel S. Kazin CPA, CISA, CISSP, CISM=20
>Senior Consultant=20
>Atos Origin=20
>40 Old Sleepy Hollow Road=20
>Pleasantville, New York 10570-3802=20
>USA=20
>Phone  +1 914-769-8780=20
>Mobile  +1 914-564-1484=20
>email    joel.kazin@atosorigin.com=20
>www.atosorigin.com <http://www.atosorigin.com/>
<http://www.atosorigin.com/ <http://www.atosorigin.com/> >=20

Joel S. Kazin CPA, CISA, CISSP, CISM
Senior Consultant
Atos Origin
40 Old Sleepy Hollow Road
Pleasantville, New York 10570-3802
USA
Phone +1 914-769-8780
Mobile +1 914-564-1484
email joel.kazin@atosorigin.com
www.atosorigin.com <http://www.atosorigin.com/>=20

------_=_NextPart_001_01C59385.077C970A
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>

<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
That is fine.<br><br>
At 10:45 AM 7/28/2005 -0500, Denis Pinkas wrote:<br><br>
<blockquote type=3Dcite class=3Dcite cite><font size=3D2>Jo=EBl,</font> =

See below : 
&gt;Extract from: draft-ietf-pkix-rfc3280bis-01.txt : =
 
&gt; 
&gt;=AB The nonRepudiation bit is asserted when the =
subject public key 
&gt;is used to verify digital signatures, other than =
signatures on 
&gt;certificates (bit 5) and CRLs (bit 6), used to =
provide a non-repudiation 
&gt;service which protects against the signing entity =
falsely denying 
&gt;some action. In the case of later conflict, a =
reliable third party may 
&gt;determine the authenticity of the signed data =BB. =
 
&gt; 
&gt;I can live with the proposed ASN.1. 
&gt; 
&gt;I would however suggest to re-use some of the key =
words of X.509. 
&gt;In the last sentence &quot;authenticity of the =
signed data&quot; may be misleading 
&gt;since it is missing the notion of time.&nbsp; =
 
&gt; 
&gt;Proposal for a compromise with X.509 2000)/Cor.3 =
(04/2004): 
&gt; 
&gt;&quot; The nonRepudiation bit is asserted when the =
subject public key 
&gt;is used to verify digital signatures, other than =
signatures on 
&gt;certificates (bit 5) and CRLs (bit 6), which are =
intended to signal 
&gt;that the signer is committing to the content being =
signed.&nbsp; 
&gt;In the case of later conflict, this allows to =
provide a non-repudiation 
&gt;service which protects against the signing entity =
falsely denying some 
&gt;action =BB. 
 
&gt;Perhaps the following wording is better: =
 
&gt;The contentCommitment bit is asserted when the =
subject public key 
&gt;is used to verify digital signatures, other than =
signatures on 
&gt;certificates (bit 5) and CRLs (bit 6). It is =
intended to signal 
&gt;that the signer is intending to committ to the =
content being signed.&nbsp; 
&gt;In the case of later conflict, this may help a =
non-repudiation 
&gt;service provider to determine if the subject's =
claimed repudiation is true 
&gt;or false. 
There would need to have the first and second sentence =
bundled together, 
which means changing: 
&nbsp; 
&quot; (bit 6). It is intended &quot; 
into 
&quot; (bit 6) and is intended &quot;. 
The end result would be: 
The contentCommitment bit is asserted when the subject =
public key 
is used to verify digital signatures, other than =
signatures on 
certificates (bit 5) and CRLs (bit 6) and is intended to =
signal 
that the signer is intending to committ to the content =
being signed.&nbsp; 
In the case of later conflict, this may help a =
non-repudiation 
service provider to determine if the subject's claimed =
repudiation is true 
or false. 
Denis 
&gt; 
&gt; 
&gt;Denis 
&gt; 
&gt;PS: The original text from the TC of X.509 is: =
 
&gt; 
&gt;b) contentCommitment: for verifying digital =
signatures which 
&gt;are intended to signal that the signer is committing =
to the content being 
&gt;signed. 
&gt;The precise level of commitment, e.g. with the =
intent to be bound 
&gt;may be signaled by additional methods, e.g. =
certificate policy. 
&gt; 
&gt;Since a content commitment signing is considered to =
be a digitally signed 
&gt;transaction, the digitalSignature bit need not be =
set in the certificate. 
&gt;If it is set, it does not affect the level of =
commitment the signer has 
&gt;endowed in the signed content. 
&gt; 
&gt;Note that it is not incorrect to refer to this =
keyUsage bit using the 
&gt;identifier nonRepudiation. However, the use this =
identifier has been 
&gt;deprecated. Regardless of the identifier used, the =
semantics of this 
&gt;bit are as specified in this standard. 
&gt; 
&gt; 
&gt;Joel S. Kazin CPA, CISA, CISSP, CISM 
&gt;Senior Consultant 
&gt;Atos Origin 
&gt;40 Old Sleepy Hollow Road 
&gt;Pleasantville, New York 10570-3802 
&gt;USA 
&gt;Phone&nbsp; +1 914-769-8780 
&gt;Mobile&nbsp; +1 914-564-1484 
&gt;email&nbsp;&nbsp;&nbsp; =
joel.kazin@atosorigin.com 
&gt;<a href=3D"http://www.atosorigin.com/" =
eudora=3D"autourl">www.atosorigin.com</a> &lt;<a =
href=3D"http://www.atosorigin.com/">http://www.atosorigin.com/</a>&gt; =
</blockquote>
<x-sigsep></x-sigsep>
 
Joel S. Kazin CPA, CISA, CISSP, CISM 
Senior Consultant 
Atos Origin 
40 Old Sleepy Hollow Road 
Pleasantville, New York 10570-3802 
USA 
Phone&nbsp; +1 914-769-8780 
Mobile&nbsp; +1 914-564-1484 
email<x-tab>&nbsp;&nbsp;&nbsp;</x-tab> joel.kazin@atosorigin.com 
<a href=3D"http://www.atosorigin.com/" =
eudora=3D"autourl">www.atosorigin.com 
</a></html>

------_=_NextPart_001_01C59385.077C970A--

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 j6SEiigq018951; Thu, 28 Jul 2005 07:44: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 j6SEiiFR018950; Thu, 28 Jul 2005 07:44:44 -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 j6SEihXn018940 for <ietf-pkix@imc.org>; Thu, 28 Jul 2005 07:44:43 -0700 (PDT) (envelope-from denis.pinkas@bull.net)
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id RAA27110; Thu, 28 Jul 2005 17:00:44 +0200
Received: from frcls4013 ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with SMTP id 2005072816460027:1018 ; Thu, 28 Jul 2005 16:46:00 +0200 
Date: Thu, 28 Jul 2005 16:45:58 +0100
From: "Denis Pinkas" <denis.pinkas@bull.net>
To: "pkix" <ietf-pkix@imc.org>, "Kazin, Joel" <Joel.Kazin@atosorigin.com>
Subject: Re: Re: 3280bis: KeyUsage NR/CC bit
X-mailer: Foxmail 5.0 [-fr-]
Mime-Version: 1.0
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 28/07/2005 16:46:00, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 28/07/2005 16:46:02, Serialize complete at 28/07/2005 16:46:02
Message-ID: <OF766F116B.78FB1E3C-ONC125704C.00511DBC@frcl.bull.fr>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by above.proper.com id j6SEiiXn018945
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

Joël,

See below :

>Extract from: draft-ietf-pkix-rfc3280bis-01.txt : 
>
>« The nonRepudiation bit is asserted when the subject public key 
>is used to verify digital signatures, other than signatures on 
>certificates (bit 5) and CRLs (bit 6), used to provide a non-repudiation 
>service which protects against the signing entity falsely denying 
>some action. In the case of later conflict, a reliable third party may 
>determine the authenticity of the signed data ». 
>
>I can live with the proposed ASN.1. 
>
>I would however suggest to re-use some of the key words of X.509. 
>In the last sentence "authenticity of the signed data" may be misleading 
>since it is missing the notion of time.  
>
>Proposal for a compromise with X.509 2000)/Cor.3 (04/2004): 
>
>" The nonRepudiation bit is asserted when the subject public key 
>is used to verify digital signatures, other than signatures on 
>certificates (bit 5) and CRLs (bit 6), which are intended to signal 
>that the signer is committing to the content being signed.  
>In the case of later conflict, this allows to provide a non-repudiation 
>service which protects against the signing entity falsely denying some
>action ». 

>Perhaps the following wording is better:

>The contentCommitment bit is asserted when the subject public key 
>is used to verify digital signatures, other than signatures on 
>certificates (bit 5) and CRLs (bit 6). It is intended to signal 
>that the signer is intending to committ to the content being signed.  
>In the case of later conflict, this may help a non-repudiation 
>service provider to determine if the subject's claimed repudiation is true
>or false.

There would need to have the first and second sentence bundled together, 
which means changing:

" (bit 6). It is intended " 
into 
" (bit 6) and is intended ".

The end result would be:

The contentCommitment bit is asserted when the subject public key 
is used to verify digital signatures, other than signatures on 
certificates (bit 5) and CRLs (bit 6) and is intended to signal 
that the signer is intending to committ to the content being signed.  
In the case of later conflict, this may help a non-repudiation 
service provider to determine if the subject's claimed repudiation is true
or false.

Denis

>
>
>Denis 
>
>PS: The original text from the TC of X.509 is: 
>
>b) contentCommitment: for verifying digital signatures which 
>are intended to signal that the signer is committing to the content being
>signed. 
>The precise level of commitment, e.g. with the intent to be bound 
>may be signaled by additional methods, e.g. certificate policy. 
>
>Since a content commitment signing is considered to be a digitally signed 
>transaction, the digitalSignature bit need not be set in the certificate. 
>If it is set, it does not affect the level of commitment the signer has 
>endowed in the signed content. 
>
>Note that it is not incorrect to refer to this keyUsage bit using the 
>identifier nonRepudiation. However, the use this identifier has been 
>deprecated. Regardless of the identifier used, the semantics of this 
>bit are as specified in this standard. 
>
>
>Joel S. Kazin CPA, CISA, CISSP, CISM
>Senior Consultant
>Atos Origin
>40 Old Sleepy Hollow Road
>Pleasantville, New York 10570-3802
>USA
>Phone  +1 914-769-8780
>Mobile  +1 914-564-1484
>email    joel.kazin@atosorigin.com
>www.atosorigin.com <http://www.atosorigin.com/> 

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 j6SDJFtY099571; Thu, 28 Jul 2005 06:19: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 j6SDJF8P099570; Thu, 28 Jul 2005 06:19:15 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from smtprelay-us1.aopn-na.com (smtprelay-us1.aopn-na.com [12.174.169.100]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6SDJBpL099509 for <ietf-pkix@imc.org>; Thu, 28 Jul 2005 06:19:12 -0700 (PDT) (envelope-from Joel.Kazin@atosorigin.com)
Received: from usarx003.arl.us.origin-it.com (usarx003.arl.us.int.atosorigin.com [172.16.146.33]) by smtprelay-us1.aopn-na.com (Postfix) with ESMTP id 4180C5FDBE; Thu, 28 Jul 2005 08:18:56 -0500 (CDT)
Received: by usarx003.arl.us.int.atosorigin.com with Internet Mail Service (5.5.2448.0) id <PPMWT3AK>; Thu, 28 Jul 2005 08:18:55 -0500
Message-ID: <5.1.0.14.0.20050728091356.00aba940@172.16.146.192>
From: "Kazin, Joel" <Joel.Kazin@atosorigin.com>
To: Denis Pinkas <denis.pinkas@bull.net>, pkix <ietf-pkix@imc.org>
Subject: Re: 3280bis: KeyUsage NR/CC bit
Date: Thu, 28 Jul 2005 08:20:30 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C59376.E7BAAEC4"
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <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_01C59376.E7BAAEC4
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

At 05:10 AM 7/28/2005 -0500, Denis Pinkas wrote:

Extract from: draft-ietf-pkix-rfc3280bis-01.txt :=20

=AB The nonRepudiation bit is asserted when the subject public key=20
is used to verify digital signatures, other than signatures on=20
certificates (bit 5) and CRLs (bit 6), used to provide a =
non-repudiation=20
service which protects against the signing entity falsely denying=20
some action. In the case of later conflict, a reliable third party may=20
determine the authenticity of the signed data =BB.=20

I can live with the proposed ASN.1.=20

I would however suggest to re-use some of the key words of X.509.=20
In the last sentence "authenticity of the signed data" may be =
misleading=20
since it is missing the notion of time. =20

Proposal for a compromise with X.509 2000)/Cor.3 (04/2004):=20

" The nonRepudiation bit is asserted when the subject public key=20
is used to verify digital signatures, other than signatures on=20
certificates (bit 5) and CRLs (bit 6), which are intended to signal=20
that the signer is committing to the content being signed. =20
In the case of later conflict, this allows to provide a non-repudiation =

service which protects against the signing entity falsely denying some
action =BB.=20

Perhaps the following wording is better:

The contentCommitment bit is asserted when the subject public key=20
is used to verify digital signatures, other than signatures on=20
certificates (bit 5) and CRLs (bit 6). It is intended to signal=20
that the signer is intending to committ to the content being signed. =20
In the case of later conflict, this may help a non-repudiation=20
service provider to determine if the subject's claimed repudiation is =
true
or false.

Denis=20

PS: The original text from the TC of X.509 is:=20

b) contentCommitment: for verifying digital signatures which=20
are intended to signal that the signer is committing to the content =
being
signed.=20
The precise level of commitment, e.g. with the intent to be bound=20
may be signaled by additional methods, e.g. certificate policy.=20

Since a content commitment signing is considered to be a digitally =
signed=20
transaction, the digitalSignature bit need not be set in the =
certificate.=20
If it is set, it does not affect the level of commitment the signer has =

endowed in the signed content.=20

Note that it is not incorrect to refer to this keyUsage bit using the=20
identifier nonRepudiation. However, the use this identifier has been=20
deprecated. Regardless of the identifier used, the semantics of this=20
bit are as specified in this standard.=20

Joel S. Kazin CPA, CISA, CISSP, CISM
Senior Consultant
Atos Origin
40 Old Sleepy Hollow Road
Pleasantville, New York 10570-3802
USA
Phone +1 914-769-8780
Mobile +1 914-564-1484
email joel.kazin@atosorigin.com
www.atosorigin.com <http://www.atosorigin.com/>=20

------_=_NextPart_001_01C59376.E7BAAEC4
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>

<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
At 05:10 AM 7/28/2005 -0500, Denis Pinkas wrote: 
 
<blockquote type=3Dcite class=3Dcite cite>Extract from:
draft-ietf-pkix-rfc3280bis-01.txt : 
=AB The nonRepudiation bit is asserted when the subject =
public
key 
is used to verify digital signatures, other than =
signatures
on 
certificates (bit 5) and CRLs (bit 6), used to provide a
non-repudiation 
service which protects against the signing entity =
falsely
denying 
some action. In the case of later conflict, a reliable =
third
party may 
determine the authenticity of the signed data =
=BB.
 
I can live with the proposed ASN.1. 
I would however suggest to re-use some of the key words =
of X.509. 
In the last sentence &quot;authenticity of the signed =
data&quot; may be misleading 
since it is missing the notion of time.&nbsp; 
 
Proposal for a compromise with X.509 2000)/Cor.3 =
(04/2004): 
 
&quot; The nonRepudiation bit is asserted when the =
subject public key 
is used to verify digital signatures, other than =
signatures on 
certificates (bit 5) and CRLs (bit 6), which are =
intended to signal 
that the signer is committing to the content being =
signed.&nbsp; 
In the case of later conflict, this allows to provide a =
non-repudiation 
service which protects against the signing entity =
falsely denying some action =BB. </blockquote> 
Perhaps the following wording is better: 
The contentCommitment bit is asserted when the subject =
public key 
is used to verify digital signatures, other than signatures on 
certificates (bit 5) and CRLs (bit 6). It is intended to signal 
that the signer is intending to committ to the content being =
signed.&nbsp; 
In the case of later conflict, this may help a non-repudiation 
service provider to determine if the subject's claimed repudiation is =
true or false. 
 
<blockquote type=3Dcite class=3Dcite cite>Denis 
PS: The original text from the TC of X.509 is: =
 
b) contentCommitment: for verifying digital signatures =
which 
are intended to signal that the signer is committing to =
the content being signed. 
The precise level of commitment, e.g. with the intent to =
be bound 
may be signaled by additional methods, e.g. certificate =
policy. 
Since a content commitment signing is considered to be a =
digitally signed 
transaction, the digitalSignature bit need not be set in =
the certificate. 
If it is set, it does not affect the level of commitment =
the signer has 
endowed in the signed content. 
Note that it is not incorrect to refer to this keyUsage =
bit using the 
identifier nonRepudiation. However, the use this =
identifier has been 
deprecated. Regardless of the identifier used, the =
semantics of this 
bit are as specified in this standard. =
</blockquote>
<x-sigsep></x-sigsep>
 
Joel S. Kazin CPA, CISA, CISSP, CISM 
Senior Consultant 
Atos Origin 
40 Old Sleepy Hollow Road 
Pleasantville, New York 10570-3802 
USA 
Phone&nbsp; +1 914-769-8780 
Mobile&nbsp; +1 914-564-1484 
email<x-tab>&nbsp;&nbsp;&nbsp;</x-tab> joel.kazin@atosorigin.com 
<a href=3D"http://www.atosorigin.com/" =
eudora=3D"autourl">www.atosorigin.com 
</a></html>

------_=_NextPart_001_01C59376.E7BAAEC4--

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 j6SCNFdR079629; Thu, 28 Jul 2005 05:23: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 j6SCNFaM079628; Thu, 28 Jul 2005 05:23:15 -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 (rimp2.nist.gov [129.6.16.227]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6SCNEhN079619 for <ietf-pkix@imc.org>; Thu, 28 Jul 2005 05:23:14 -0700 (PDT) (envelope-from wpolk@nist.gov)
Received: from real2.localdomain ([192.168.2.11]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id j6SCNA9X028081 for <ietf-pkix@imc.org>; Thu, 28 Jul 2005 08:23:10 -0400
Received: from real2.localdomain (real2.localdomain [127.0.0.1]) by real2.localdomain (8.12.8/8.12.8) with ESMTP id j6SCNA9h006127 for <ietf-pkix@imc.org>; Thu, 28 Jul 2005 08:23:10 -0400
Received: (from apache@localhost) by real2.localdomain (8.12.8/8.12.8/Submit) id j6SCNADG006125 for ietf-pkix@imc.org; Thu, 28 Jul 2005 08:23:10 -0400
Received: from pool-138-88-15-110.res.east.verizon.net (pool-138-88-15-110.res.east.verizon.net [138.88.15.110])  by webmail.nist.gov (IMP) with HTTP  for <wpolk@localhost>; Thu, 28 Jul 2005 08:23:10 -0400
Message-ID: <1122553390.42e8ce2e4b03b@webmail.nist.gov>
Date: Thu, 28 Jul 2005 08:23:10 -0400
From: wpolk@nist.gov
To: ietf-pkix@imc.org
Subject: tentative PKIX agenda
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.15.110
X-NIST-MailScanner: Found to be clean
X-NIST-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>

Folks,

Here is the tentative agenda for the PKIX meeting.  I believe I have honored all 
requests for time.  If I missed your request, please send me another message.  
We always expand to meet consume the time allowed, but I can probably work in 
another presentation.

Thanks,

Tim

------------------------------------------

PKIX WG (pkix-wg)

WEDNESDAY, August 2, 2005 1400-1600
======================================

CHAIRS: Stephen Kent <kent@bbn.com>, Tim Polk <tim.polk@nist.gov>

AGENDA:

1. WG Status and Direction

1.1 Document Status Review [Tim Polk (NIST)]

        The working group has a number of Internet-Drafts at various
        stages in the IETF process. (10 min.)

2. PKIX WG Specifications

2.1 3280bis Status
         Tim Polk (NIST)
    http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-01.txt

       A new draft has been submitted with relatively minor enhancements.
       Several open issues remain to be resolved.  In particular, questions
       involving name ambiguity have been raised, particularly as they
       impact CRL validation.
       (10 min.)

2.2  3280bis Open Issues
        Denis Pinkas
         (no draft)

       This presentation will focus on the open issues currently under
       discussion with respect to 3280bis. (10 min.)

2.3   Simple Certificate Validation Protocol (SCVP)
        Tim Polk (NIST)
          http://www.ietf.org/internet-drafts/draft-ietf-pkix-scvp-19.txt

       IPR issues have been resolved since the last IETF meeting, but the
       core specification has not changed significantly since the -18 draft.
       The draft meets the requirements specified in RFC 3379, but consensus
       has not been demonstrated for several issues raised on the list.
       (10 min.)

2.4  SCVP Open Issues
        Denis Pinkas
         (no draft)

       This presentation will focus on the open issues currently under
       discussion with respect to SCVP. (10 min.)

2.5  SRV RR Issues
         Stefan Santesson (Microsoft)
         (no draft)

       A new requirement for an SRV RR othername has been identified.  The
       presenter will explain the requirement and proposed approach for
       satisfying the requirement.
       (10 min.)

3. Related Specifications & Liasion Presentations

       Time allowing, liasion presentations will be accomodated to ensure the
       PKIX WG is aware of related specifications currently progressing as
       individual drafts.

     3.1 CMS Advanced Electronic Signatures (CAdES)
         Denis Pinkas (on behalf of ETSI TC ESI)
           (no draft)

       This document is based on RFC 3126 and is aligned with a re-issue of
       ETSI TS 101 733.
       (10 min.)

     3.2 XKMS
         Stephen Farrell (on behalf of W3C)
           (no draft)

       This presentation will provide an update on the progression of the
       XKMS specifiation within W3C.
       (5 min.)

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 j6SCNCW0079601; Thu, 28 Jul 2005 05:23: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 j6SCNCA9079600; Thu, 28 Jul 2005 05:23:12 -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 (rimp2.nist.gov [129.6.16.227]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6SCNBUg079586 for <ietf-pkix@imc.org>; Thu, 28 Jul 2005 05:23:11 -0700 (PDT) (envelope-from wpolk@nist.gov)
Received: from real2.localdomain ([192.168.2.11]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id j6SCN9St004607 for <ietf-pkix@imc.org>; Thu, 28 Jul 2005 08:23:09 -0400
Received: from real2.localdomain (real2.localdomain [127.0.0.1]) by real2.localdomain (8.12.8/8.12.8) with ESMTP id j6SCN99h006121 for <ietf-pkix@imc.org>; Thu, 28 Jul 2005 08:23:09 -0400
Received: (from apache@localhost) by real2.localdomain (8.12.8/8.12.8/Submit) id j6SCN9i0006119 for ietf-pkix@imc.org; Thu, 28 Jul 2005 08:23:09 -0400
Received: from pool-138-88-15-110.res.east.verizon.net (pool-138-88-15-110.res.east.verizon.net [138.88.15.110])  by webmail.nist.gov (IMP) with HTTP  for <wpolk@localhost>; Thu, 28 Jul 2005 08:23:09 -0400
Message-ID: <1122553389.42e8ce2d21807@webmail.nist.gov>
Date: Thu, 28 Jul 2005 08:23:09 -0400
From: wpolk@nist.gov
To: ietf-pkix@imc.org
Subject: tentative PKIX agenda
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.15.110
X-NIST-MailScanner: Found to be clean
X-NIST-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>

Folks,

Here is the tentative agenda for the PKIX meeting.  I believe I have honored all 
requests for time.  If I missed your request, please send me another message.  
We always expand to meet consume the time allowed, but I can probably work in 
another presentation.

Thanks,

Tim

------------------------------------------

PKIX WG (pkix-wg)

WEDNESDAY, August 2, 2005 1400-1600
======================================

CHAIRS: Stephen Kent <kent@bbn.com>, Tim Polk <tim.polk@nist.gov>

AGENDA:

1. WG Status and Direction

1.1 Document Status Review [Tim Polk (NIST)]

        The working group has a number of Internet-Drafts at various
        stages in the IETF process. (10 min.)

2. PKIX WG Specifications

2.1 3280bis Status
         Tim Polk (NIST)
    http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-01.txt

       A new draft has been submitted with relatively minor enhancements.
       Several open issues remain to be resolved.  In particular, questions
       involving name ambiguity have been raised, particularly as they
       impact CRL validation.
       (10 min.)

2.2  3280bis Open Issues
        Denis Pinkas
         (no draft)

       This presentation will focus on the open issues currently under
       discussion with respect to 3280bis. (10 min.)

2.3   Simple Certificate Validation Protocol (SCVP)
        Tim Polk (NIST)
          http://www.ietf.org/internet-drafts/draft-ietf-pkix-scvp-19.txt

       IPR issues have been resolved since the last IETF meeting, but the
       core specification has not changed significantly since the -18 draft.
       The draft meets the requirements specified in RFC 3379, but consensus
       has not been demonstrated for several issues raised on the list.
       (10 min.)

2.4  SCVP Open Issues
        Denis Pinkas
         (no draft)

       This presentation will focus on the open issues currently under
       discussion with respect to SCVP. (10 min.)

2.5  SRV RR Issues
         Stefan Santesson (Microsoft)
         (no draft)

       A new requirement for an SRV RR othername has been identified.  The
       presenter will explain the requirement and proposed approach for
       satisfying the requirement.
       (10 min.)

3. Related Specifications & Liasion Presentations

       Time allowing, liasion presentations will be accomodated to ensure the
       PKIX WG is aware of related specifications currently progressing as
       individual drafts.

     3.1 CMS Advanced Electronic Signatures (CAdES)
         Denis Pinkas (on behalf of ETSI TC ESI)
           (no draft)

       This document is based on RFC 3126 and is aligned with a re-issue of
       ETSI TS 101 733.
       (10 min.)

     3.2 XKMS
         Stephen Farrell (on behalf of W3C)
           (no draft)

       This presentation will provide an update on the progression of the
       XKMS specifiation within W3C.
       (5 min.)

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 j6S9CWCc009728; Thu, 28 Jul 2005 02:12: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 j6S9CV49009716; Thu, 28 Jul 2005 02:12:31 -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 j6S9CSTp009682 for <ietf-pkix@imc.org>; Thu, 28 Jul 2005 02:12:28 -0700 (PDT) (envelope-from denis.pinkas@bull.net)
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id LAA19816; Thu, 28 Jul 2005 11:28:24 +0200
Received: from frcls4013 ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with SMTP id 2005072811134100:874 ; Thu, 28 Jul 2005 11:13:41 +0200 
Date: Thu, 28 Jul 2005 11:13:38 +0100
From: "Denis Pinkas" <denis.pinkas@bull.net>
To: "Stephen Farrell" <stephen.farrell@cs.tcd.ie>
Cc: "pkix" <ietf-pkix@imc.org>
Subject: Re: Re: IDP indirectCRL flag
X-mailer: Foxmail 5.0 [-fr-]
Mime-Version: 1.0
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 28/07/2005 11:13:41, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 28/07/2005 11:13:42, Serialize complete at 28/07/2005 11:13:42
Message-ID: <OFE63F563A.9888328E-ONC125704C.0032B102@frcl.bull.fr>
Content-Transfer-Encoding: 7bit
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>

Stephen,

>Denis,

>> This procedural rule should be mentioned in the main body of the document.

>That seems to go against the mitigate/supress approach you're advocating
>in other messages to the list.

Not at all.

>> However we are back with the vocabulary issue about "indirect CRLs" and 
>> "delegated CRLs".
>
>IMO a sufficient set of technical concerns have been raised that
>this isn't desirable for 3280bis.
>
>And, given that it seems that no-one else wants this distinction, (at
>least for now, at least as currently presented), is it really
>worthwhile prolonging the discussion when the outcome is almost
>inevitable?

The IETF meeting is now very close. 
Let us have some face to face discussions there.

Denis

>Stephen.

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 j6S98sSq008184; Thu, 28 Jul 2005 02:08: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 j6S98stj008183; Thu, 28 Jul 2005 02:08:54 -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 j6S98q59008136 for <ietf-pkix@imc.org>; Thu, 28 Jul 2005 02:08:53 -0700 (PDT) (envelope-from denis.pinkas@bull.net)
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id LAA09300 for <ietf-pkix@imc.org>; Thu, 28 Jul 2005 11:24:54 +0200
Received: from frcls4013 ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with SMTP id 2005072811101122:871 ; Thu, 28 Jul 2005 11:10:11 +0200 
Date: Thu, 28 Jul 2005 11:10:08 +0100
From: "Denis Pinkas" <denis.pinkas@bull.net>
To: "pkix" <ietf-pkix@imc.org>
Subject: 3280bis: KeyUsage NR/CC bit
X-mailer: Foxmail 5.0 [-fr-]
Mime-Version: 1.0
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 28/07/2005 11:10:11, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 28/07/2005 11:10:11, Serialize complete at 28/07/2005 11:10:11
Message-ID: <OFF9C85756.80892C24-ONC125704C.00325F03@frcl.bull.fr>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by above.proper.com id j6S98r59008177
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

Extract from: draft-ietf-pkix-rfc3280bis-01.txt :

« The nonRepudiation bit is asserted when the subject public key 
is used to verify digital signatures, other than signatures on 
certificates (bit 5) and CRLs (bit 6), used to provide a non-repudiation 
service which protects against the signing entity falsely denying 
some action. In the case of later conflict, a reliable third party may 
determine the authenticity of the signed data ».

I can live with the proposed ASN.1.

I would however suggest to re-use some of the key words of X.509.
In the last sentence "authenticity of the signed data" may be misleading 
since it is missing the notion of time.  

Proposal for a compromise with X.509 2000)/Cor.3 (04/2004): 

" The nonRepudiation bit is asserted when the subject public key 
is used to verify digital signatures, other than signatures on 
certificates (bit 5) and CRLs (bit 6), which are intended to signal 
that the signer is committing to the content being signed.  
In the case of later conflict, this allows to provide a non-repudiation 
service which protects against the signing entity falsely denying some action ».

Denis

PS: The original text from the TC of X.509 is:

b) contentCommitment: for verifying digital signatures which 
are intended to signal that the signer is committing to the content being signed. 
The precise level of commitment, e.g. with the intent to be bound 
may be signaled by additional methods, e.g. certificate policy.

Since a content commitment signing is considered to be a digitally signed 
transaction, the digitalSignature bit need not be set in the certificate. 
If it is set, it does not affect the level of commitment the signer has 
endowed in the signed content.

Note that it is not incorrect to refer to this keyUsage bit using the 
identifier nonRepudiation. However, the use this identifier has been 
deprecated. Regardless of the identifier used, the semantics of this 
bit are as specified in this standard.

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 j6S8lNus098862; Thu, 28 Jul 2005 01:47: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 j6S8lNpL098861; Thu, 28 Jul 2005 01:47:23 -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 j6S8lLqp098795 for <ietf-pkix@imc.org>; Thu, 28 Jul 2005 01:47:22 -0700 (PDT) (envelope-from denis.pinkas@bull.net)
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id LAA12902; Thu, 28 Jul 2005 11:03:08 +0200
Received: from frcls4013 ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with SMTP id 2005072810482493:855 ; Thu, 28 Jul 2005 10:48:24 +0200 
Date: Thu, 28 Jul 2005 10:48:22 +0100
From: "Denis Pinkas" <denis.pinkas@bull.net>
To: "Tim Polk" <wpolk@nist.gov>, "Stephen Kent" <kent@bbn.com>
Cc: "pkix" <ietf-pkix@imc.org>
Subject: PKIX Agenda ?
X-mailer: Foxmail 5.0 [-fr-]
Mime-Version: 1.0
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 28/07/2005 10:48:25, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 28/07/2005 10:48:27, Serialize complete at 28/07/2005 10:48:27
Message-ID: <OFA679B127.A39EF5A5-ONC125704C.003060D5@frcl.bull.fr>
Content-Transfer-Encoding: 7bit
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>

Tim,

Would it be possible that you post the agenda of the meeting.
It has not been posted to the mailing list and is not available at :

http://www.ietf.org/meetings/wg_agenda_63.html

Thanks,

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 j6RHpoID029541; Wed, 27 Jul 2005 10:51: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 j6RHpogp029540; Wed, 27 Jul 2005 10:51:50 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from host15.websitesource.com (host15.websitesource.com [209.239.32.38]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6RHpnsO029533 for <ietf-pkix@imc.org>; Wed, 27 Jul 2005 10:51:49 -0700 (PDT) (envelope-from chokhani@orionsec.com)
Received: from wchokhani3 (ASQ2-127-116.usae.bah.com [156.80.127.116]) by host15.websitesource.com (8.12.10/8.12.10) with ESMTP id j6RHplBW007188 for <ietf-pkix@imc.org>; Wed, 27 Jul 2005 13:51:49 -0400
From: "Santosh Chokhani" <chokhani@orionsec.com>
To: "'pkix'" <ietf-pkix@imc.org>
Subject: RE: IDP indirectCRL flag
Date: Wed, 27 Jul 2005 13:51:41 -0400
Message-ID: <007101c592d3$dbeffca0$747f509c@hq.orionsec.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0072_01C592B2.54DE5CA0"
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.2900.2180
In-Reply-To: <5.1.0.14.0.20050727122819.00af79d8@172.16.146.192>
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <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_0072_01C592B2.54DE5CA0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

This e-mail thread is mixing many themes and is causing confusion.  We =
are
discussing the following largely independent topics.
=20
1.  Name collisions for direct and indirect CRL issuance
=20
2.  Denis's proposal for extending/enhancing/changing the standard for
another class of indirect CRL.  This should be done via another =
extension.
=20
3.  Gustafson's concern about SCL.  This can be accommodated by existing
mechanisms.  Denis's mechanism is not required.  Having said that it can =
be
accommodated, practically it will not work since MSFT clients require =
that
the certificate and CRL be signed using the same key -- so the question =
of
indirect CRL does not even arise.

-----Original Message-----
From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] =
On
Behalf Of Kazin, Joel
Sent: Wednesday, July 27, 2005 12:44 PM
To: DE Gustafson; Aisenberg, Michael
Cc: Stephen Farrell; Denis Pinkas; pkix
Subject: Re: IDP indirectCRL flag

At 10:30 AM 7/27/2005 -0500, DE Gustafson wrote:

Hi All,

Like many (or few?) I've been devoting some of my copious free-time to
listening in on this debate.  My sense is that Denis may be on to =
something
but his ability to make progress on (at a minimum) completely defining a
"problem at hand" has not moved ahead smartly.  None will fault him for =
lack
of effort :-)

FWIW, real networks are beginning to see the operational problems that
indirect-CRLs could help solve.  For example, an Enterprise runs a CA =
system
that pushes out CRLs at high frequency (every couple of hours).  People =
have
been convinced that "more frequent CRL updates" is vitally important to
stronger/higher assurance security.  However, unexpected failures can
clearly gum up the works for some applications (e.g., smart card logon)
because, sooner or later, the CA is not able to push out a CRL on it's
appointed schedule, impacting secure applications.  In this case, =
sometime
after the CA goes offline all certificate-based computer and network =
logons
will fail (creating a variation of the dreaded one-fail/all fail =
scenario).
This condition will persist until a new CRL is issued and fetched by all
clients.  Newly appearing client logic that continues to use expired =
(but
not "too expired") CRLs sounds like a dubious approach/workaround but =
it's
existence may be giving a signal that this isn't the last time someone =
will
suggest a little standards-rework is needed in this area.  Clearly, the =
CA
(actually the configured CRL serving systems) will have to work their =
way
through a peak workload starting shortly after the CA goes back online.

Yes, has happen at least once.  Some CA's, Microsoft 2003, allow an
emergency CRL or delta CRL to be signed which simply extends the =
expiration
of the last available CRL or delta.  Of course this presumes that you =
still
have the ability to use the CA's private signing key to sign the =
emergency
CRL. There is a recent fix by Microsoft that allows one to issue a Group
Policy Object which will allow Windows Logon even though the latest
available CRL and delta have expired. It just ignores the fact that the =
CRL
and delta hve expired and performs all the other checks.

If your using OCSP or SCVP you might say the certificate is good even =
though
you really know only that it wasn't on the last or any prior CRL or =
deltas
and your last CRL has expired. That probably violates the respective =
RFC's.
No, I don't want to restart the past threads on good, bad, not known.=20

In good theory, it would be nice to deploy a separate server (with =
separate
CRL-signing key) that could issue CRLs on behalf of the CA.  Better yet,
multiple servers (for redundancy), each with it's own signing key and =
each
able to issue a CRL that lists all certificates revoked by the CA.  This
would allow new CRLs to be published even though the CA might be down =
long
enough to miss a periodic CRL update event.  Likely there's at least one
application for all the different permutations, combinations, =
corner-cases,
etc. that might be supported by the current draft.

Has anyone fully considered how these capabilities will be used in =
practice
and identified any glitches (real or imagined) in a typical vendor's =
ability
to create truly more robust solutions?  Has that work been assigned,
implementor feedback fetched and processed, etc.?

More to the point, can someone articulate the apparent philosophical
disagreement over the basic requirements for any solution that this =
group
might embrace.  That is, Denis seems to be saying that CRL-Issuer Names, =
per
se, will never be crypto-pure enough with respect to their ability to =
point
to (identify) a particular CRL-issuer/signing key?  If that's what he's
saying, is that a real (undodgeable) technical issue (i.e., it never =
goes
away and is increasing problematic over time)?

Regards,

--dg

Aisenberg, Michael wrote:

Whatever RFC-based legacy arguments can be concocted here, the gravamen =
of
the utility of certs in a real world applied environment depends in no =
small
measure on the reliability (immediacy) of the CRL.  If we ever want to
achieve truly interoperable federated authentication regiemes usable, =
say in
Defense and NatSec environments talking to commercial environments, then =
we
had better figure out how to persuade RPs of the integrity of the CRL
process.

 -----Original Message-----
From:   Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie]
Sent:   Wed Jul 27 07:14:51 2005
To:     Denis Pinkas
Cc:     pkix
Subject:        Re: IDP indirectCRL flag

Denis,

> This procedural rule should be mentioned in the main body of the =
document.

That seems to go against the mitigate/supress approach you're advocating
in other messages to the list.

> However we are back with the vocabulary issue about "indirect CRLs" =
and
> "delegated CRLs".

IMO a sufficient set of technical concerns have been raised that
this isn't desirable for 3280bis.

And, given that it seems that no-one else wants this distinction, (at
least for now, at least as currently presented), is it really
worthwhile prolonging the discussion when the outcome is almost
inevitable?

Stephen.

Joel S. Kazin CPA, CISA, CISSP, CISM
Senior Consultant
Atos Origin
40 Old Sleepy Hollow Road
Pleasantville, New York 10570-3802
USA
Phone +1 914-769-8780
Mobile +1 914-564-1484
email joel.kazin@atosorigin.com
www.atosorigin.com <http://www.atosorigin.com/>=20

------=_NextPart_000_0072_01C592B2.54DE5CA0
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.2900.2668" name=3DGENERATOR></HEAD>
<BODY>
<DIV><STRONG><FONT face=3DArial color=3D#008000 size=3D2><SPAN=20
class=3D079144717-27072005>This e-mail thread is mixing many themes and =
is causing=20
confusion.&nbsp; We are discussing the following largely independent=20
topics.</SPAN></FONT></STRONG></DIV>
<DIV><STRONG><FONT face=3DArial color=3D#008000 size=3D2><SPAN=20
class=3D079144717-27072005></SPAN></FONT></STRONG>&nbsp;</DIV>
<DIV><STRONG><FONT face=3DArial color=3D#008000 size=3D2><SPAN=20
class=3D079144717-27072005>1.&nbsp; Name collisions for direct and =
indirect CRL=20
issuance</SPAN></FONT></STRONG></DIV>
<DIV><STRONG><FONT face=3DArial color=3D#008000 size=3D2><SPAN=20
class=3D079144717-27072005></SPAN></FONT></STRONG>&nbsp;</DIV>
<DIV><STRONG><FONT face=3DArial color=3D#008000 size=3D2><SPAN=20
class=3D079144717-27072005>2.&nbsp; Denis's proposal for=20
extending/enhancing/changing the standard for another class of indirect=20
CRL.&nbsp; This should be done via another=20
extension.</SPAN></FONT></STRONG></DIV>
<DIV><STRONG><FONT face=3DArial color=3D#008000 size=3D2><SPAN=20
class=3D079144717-27072005></SPAN></FONT></STRONG>&nbsp;</DIV>
<DIV><STRONG><FONT face=3DArial color=3D#008000 size=3D2><SPAN=20
class=3D079144717-27072005>3.&nbsp; Gustafson's concern about SCL.&nbsp; =
This can=20
be accommodated by existing mechanisms.&nbsp; Denis's mechanism is not=20
required.&nbsp; Having said that it can be accommodated, practically it =
will not=20
work since MSFT clients require that the certificate and CRL be signed =
using the=20
same key -- so the question of indirect CRL does not even=20
arise.</SPAN></FONT></STRONG></DIV>
<BLOCKQUOTE dir=3Dltr style=3D"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>=20
  owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] =
<B>On=20
  Behalf Of </B>Kazin, Joel<BR><B>Sent:</B> Wednesday, July 27, 2005 =
12:44=20
  PM<BR><B>To:</B> DE Gustafson; Aisenberg, Michael<BR><B>Cc:</B> =
Stephen=20
  Farrell; Denis Pinkas; pkix<BR><B>Subject:</B> Re: IDP indirectCRL=20
  flag<BR><BR></FONT></DIV>At 10:30 AM 7/27/2005 -0500, DE Gustafson =
wrote:<BR>
  <BLOCKQUOTE class=3Dcite cite=3D"" type=3D"cite"><TT>Hi =
All,<BR><BR>Like many (or=20
    few?) I've been devoting some of my copious free-time to listening =
in on=20
    this debate.&nbsp; My sense is that Denis may be on to something but =
his=20
    ability to make progress on (at a minimum) completely defining a =
"problem at=20
    hand" has not moved ahead smartly.&nbsp; None will fault him for =
lack of=20
    effort :-)<BR><BR>FWIW, real networks are beginning to see the =
operational=20
    problems that indirect-CRLs could help solve.&nbsp; For example, an=20
    Enterprise runs a CA system that pushes out CRLs at high frequency =
(every=20
    couple of hours).&nbsp; People have been convinced that "more =
frequent CRL=20
    updates" is vitally important to stronger/higher assurance =
security.&nbsp;=20
    However, unexpected failures can clearly gum up the works for some=20
    applications (e.g., smart card logon) because, sooner or later, the =
CA is=20
    not able to push out a CRL on it's appointed schedule, impacting =
secure=20
    applications.&nbsp; In this case, sometime after the CA goes offline =
all=20
    certificate-based computer and network logons will fail (creating a=20
    variation of the dreaded one-fail/all fail scenario).&nbsp; This =
condition=20
    will persist until a new CRL is issued and fetched by all =
clients.&nbsp;=20
    Newly appearing client logic that continues to use expired (but not =
"too=20
    expired") CRLs sounds like a dubious approach/workaround but it's =
existence=20
    may be giving a signal that this isn't the last time someone will =
suggest a=20
    little standards-rework is needed in this area.&nbsp; Clearly, the =
CA=20
    (actually the configured CRL serving systems) will have to work =
their way=20
    through a peak workload starting shortly after the CA goes back=20
  online.</TT></BLOCKQUOTE><BR>Yes, has happen at least once.&nbsp; Some =
CA's,=20
  Microsoft 2003, allow an emergency CRL or delta CRL to be signed which =
simply=20
  extends the expiration of the last available CRL or delta.&nbsp; Of =
course=20
  this presumes that you still have the ability to use the CA's private =
signing=20
  key to sign the emergency CRL. There is a recent fix by Microsoft that =
allows=20
  one to issue a Group Policy Object which will allow Windows Logon even =
though=20
  the latest available CRL and delta have expired. It just ignores the =
fact that=20
  the CRL and delta hve expired and performs all the other =
checks.<BR><BR>If=20
  your using OCSP or SCVP you might say the certificate is good even =
though you=20
  really know only that it wasn't on the last or any prior CRL or deltas =
and=20
  your last CRL has expired. That probably violates the respective =
RFC's. No, I=20
  don't want to restart the past threads on good, bad, not known. =
<BR><BR><BR>
  <BLOCKQUOTE class=3Dcite cite=3D"" type=3D"cite"><TT>In good theory, =
it would be=20
    nice to deploy a separate server (with separate CRL-signing key) =
that could=20
    issue CRLs on behalf of the CA.&nbsp; Better yet, multiple servers =
(for=20
    redundancy), each with it's own signing key and each able to issue a =
CRL=20
    that lists all certificates revoked by the CA.&nbsp; This would =
allow new=20
    CRLs to be published even though the CA might be down long enough to =
miss a=20
    periodic CRL update event.&nbsp; Likely there's at least one =
application for=20
    all the different permutations, combinations, corner-cases, etc. =
that might=20
    be supported by the current draft.<BR><BR>Has anyone fully =
considered how=20
    these capabilities will be used in practice and identified any =
glitches=20
    (real or imagined) in a typical vendor's ability to create truly =
more robust=20
    solutions?&nbsp; Has that work been assigned, implementor feedback =
fetched=20
    and processed, etc.?<BR><BR>More to the point, can someone =
articulate the=20
    apparent philosophical disagreement over the basic requirements for =
any=20
    solution that this group might embrace.&nbsp; That is, Denis seems =
to be=20
    saying that CRL-Issuer Names, per se, will never be crypto-pure =
enough with=20
    respect to their ability to point to (identify) a particular=20
    CRL-issuer/signing key?&nbsp; If that's what he's saying, is that a =
real=20
    (undodgeable) technical issue (i.e., it never goes away and is =
increasing=20
    problematic over=20
    =
time)?<BR><BR>Regards,<BR><BR>--dg<BR><BR><BR></TT><BR><BR>Aisenberg,=20
    Michael wrote:<BR>
    <BLOCKQUOTE class=3Dcite cite=3D"" type=3D"cite"><BR><FONT =
size=3D2>Whatever=20
      RFC-based legacy arguments can be concocted here, the gravamen of =
the=20
      utility of certs in a real world applied environment depends in no =
small=20
      measure on the reliability (immediacy) of the CRL.&nbsp; If we =
ever want=20
      to achieve truly interoperable federated authentication regiemes =
usable,=20
      say in Defense and NatSec environments talking to commercial =
environments,=20
      then we had better figure out how to persuade RPs of the integrity =
of the=20
      CRL process.<BR><BR>&nbsp;-----Original =
Message-----<BR>From:&nbsp;&nbsp;=20
      Stephen Farrell [<A=20
      =
href=3D"mailto:stephen.farrell@cs.tcd.ie">mailto:stephen.farrell@cs.tcd.i=
e</A>]<BR>Sent:&nbsp;&nbsp;=20
      Wed Jul 27 07:14:51 2005<BR>To:&nbsp;&nbsp;&nbsp;&nbsp; Denis=20
      Pinkas<BR>Cc:&nbsp;&nbsp;&nbsp;&nbsp;=20
      pkix<BR>Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Re: IDP =

      indirectCRL flag<BR><BR><BR><BR><BR>Denis,<BR><BR>&gt; This =
procedural=20
      rule should be mentioned in the main body of the =
document.<BR><BR>That=20
      seems to go against the mitigate/supress approach you're =
advocating<BR>in=20
      other messages to the list.<BR><BR>&gt; However we are back with =
the=20
      vocabulary issue about "indirect CRLs" and<BR>&gt; "delegated=20
      CRLs".<BR><BR>IMO a sufficient set of technical concerns have been =
raised=20
      that<BR>this isn't desirable for 3280bis.<BR><BR>And, given that =
it seems=20
      that no-one else wants this distinction, (at<BR>least for now, at =
least as=20
      currently presented), is it really<BR>worthwhile prolonging the =
discussion=20
      when the outcome is=20
    =
almost<BR>inevitable?<BR><BR>Stephen.<BR><BR><BR></BLOCKQUOTE><X-SIGSEP>
    <P></X-SIGSEP><BR>Joel S. Kazin CPA, CISA, CISSP, CISM<BR>Senior=20
    Consultant<BR>Atos Origin<BR>40 Old Sleepy Hollow =
Road<BR>Pleasantville, New=20
    York 10570-3802<BR>USA<BR>Phone&nbsp; +1 =
914-769-8780<BR>Mobile&nbsp; +1=20
    914-564-1484<BR>email<X-TAB>&nbsp;&nbsp;&nbsp;</X-TAB>=20
    joel.kazin@atosorigin.com<BR><A href=3D"http://www.atosorigin.com/"=20
    =
eudora=3D"autourl">www.atosorigin.com<BR></A></FONT></P></BLOCKQUOTE></BL=
OCKQUOTE></BODY></HTML>

------=_NextPart_000_0072_01C592B2.54DE5CA0--

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 j6RGgaNT023255; Wed, 27 Jul 2005 09:42: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 j6RGgaVW023254; Wed, 27 Jul 2005 09:42:36 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from smtprelay-us1.aopn-na.com (smtprelay-us1.aopn-na.com [12.174.169.100]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6RGgZa5023242 for <ietf-pkix@imc.org>; Wed, 27 Jul 2005 09:42:35 -0700 (PDT) (envelope-from Joel.Kazin@atosorigin.com)
Received: from usarx003.arl.us.origin-it.com (usarx003.arl.us.int.atosorigin.com [172.16.146.33]) by smtprelay-us1.aopn-na.com (Postfix) with ESMTP id C1E6B5FD24; Wed, 27 Jul 2005 11:42:05 -0500 (CDT)
Received: by usarx003.arl.us.int.atosorigin.com with Internet Mail Service (5.5.2448.0) id <PPMWS094>; Wed, 27 Jul 2005 11:42:05 -0500
Message-ID: <5.1.0.14.0.20050727122819.00af79d8@172.16.146.192>
From: "Kazin, Joel" <Joel.Kazin@atosorigin.com>
To: DE Gustafson <degustafson@comcast.net>, "Aisenberg, Michael" <maisenberg@verisign.com>
Cc: Stephen Farrell <stephen.farrell@cs.tcd.ie>, Denis Pinkas <denis.pinkas@bull.net>, pkix <ietf-pkix@imc.org>
Subject: Re: IDP indirectCRL flag
Date: Wed, 27 Jul 2005 11:43:38 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C592CA.1E9EB014"
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <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_01C592CA.1E9EB014
Content-Type: text/plain;
	charset="iso-8859-1"

At 10:30 AM 7/27/2005 -0500, DE Gustafson wrote:

Hi All,

Like many (or few?) I've been devoting some of my copious free-time to
listening in on this debate.  My sense is that Denis may be on to something
but his ability to make progress on (at a minimum) completely defining a
"problem at hand" has not moved ahead smartly.  None will fault him for lack
of effort :-)

FWIW, real networks are beginning to see the operational problems that
indirect-CRLs could help solve.  For example, an Enterprise runs a CA system
that pushes out CRLs at high frequency (every couple of hours).  People have
been convinced that "more frequent CRL updates" is vitally important to
stronger/higher assurance security.  However, unexpected failures can
clearly gum up the works for some applications (e.g., smart card logon)
because, sooner or later, the CA is not able to push out a CRL on it's
appointed schedule, impacting secure applications.  In this case, sometime
after the CA goes offline all certificate-based computer and network logons
will fail (creating a variation of the dreaded one-fail/all fail scenario).
This condition will persist until a new CRL is issued and fetched by all
clients.  Newly appearing client logic that continues to use expired (but
not "too expired") CRLs sounds like a dubious approach/workaround but it's
existence may be giving a signal that this isn't the last time someone will
suggest a little standards-rework is needed in this area.  Clearly, the CA
(actually the configured CRL serving systems) will have to work their way
through a peak workload starting shortly after the CA goes back online.

Yes, has happen at least once.  Some CA's, Microsoft 2003, allow an
emergency CRL or delta CRL to be signed which simply extends the expiration
of the last available CRL or delta.  Of course this presumes that you still
have the ability to use the CA's private signing key to sign the emergency
CRL. There is a recent fix by Microsoft that allows one to issue a Group
Policy Object which will allow Windows Logon even though the latest
available CRL and delta have expired. It just ignores the fact that the CRL
and delta hve expired and performs all the other checks.

If your using OCSP or SCVP you might say the certificate is good even though
you really know only that it wasn't on the last or any prior CRL or deltas
and your last CRL has expired. That probably violates the respective RFC's.
No, I don't want to restart the past threads on good, bad, not known. 

In good theory, it would be nice to deploy a separate server (with separate
CRL-signing key) that could issue CRLs on behalf of the CA.  Better yet,
multiple servers (for redundancy), each with it's own signing key and each
able to issue a CRL that lists all certificates revoked by the CA.  This
would allow new CRLs to be published even though the CA might be down long
enough to miss a periodic CRL update event.  Likely there's at least one
application for all the different permutations, combinations, corner-cases,
etc. that might be supported by the current draft.

Has anyone fully considered how these capabilities will be used in practice
and identified any glitches (real or imagined) in a typical vendor's ability
to create truly more robust solutions?  Has that work been assigned,
implementor feedback fetched and processed, etc.?

More to the point, can someone articulate the apparent philosophical
disagreement over the basic requirements for any solution that this group
might embrace.  That is, Denis seems to be saying that CRL-Issuer Names, per
se, will never be crypto-pure enough with respect to their ability to point
to (identify) a particular CRL-issuer/signing key?  If that's what he's
saying, is that a real (undodgeable) technical issue (i.e., it never goes
away and is increasing problematic over time)?

Regards,

--dg

Aisenberg, Michael wrote:

Whatever RFC-based legacy arguments can be concocted here, the gravamen of
the utility of certs in a real world applied environment depends in no small
measure on the reliability (immediacy) of the CRL.  If we ever want to
achieve truly interoperable federated authentication regiemes usable, say in
Defense and NatSec environments talking to commercial environments, then we
had better figure out how to persuade RPs of the integrity of the CRL
process.

 -----Original Message-----
From:   Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie
<mailto:stephen.farrell@cs.tcd.ie> ]
Sent:   Wed Jul 27 07:14:51 2005
To:     Denis Pinkas
Cc:     pkix
Subject:        Re: IDP indirectCRL flag

Denis,

> This procedural rule should be mentioned in the main body of the document.

That seems to go against the mitigate/supress approach you're advocating
in other messages to the list.

> However we are back with the vocabulary issue about "indirect CRLs" and
> "delegated CRLs".

IMO a sufficient set of technical concerns have been raised that
this isn't desirable for 3280bis.

And, given that it seems that no-one else wants this distinction, (at
least for now, at least as currently presented), is it really
worthwhile prolonging the discussion when the outcome is almost
inevitable?

Stephen.

Joel S. Kazin CPA, CISA, CISSP, CISM
Senior Consultant
Atos Origin
40 Old Sleepy Hollow Road
Pleasantville, New York 10570-3802
USA
Phone +1 914-769-8780
Mobile +1 914-564-1484
email joel.kazin@atosorigin.com
www.atosorigin.com <http://www.atosorigin.com/>

------_=_NextPart_001_01C592CA.1E9EB014
Content-Type: text/html;
	charset="iso-8859-1"

<html>

<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
At 10:30 AM 7/27/2005 -0500, DE Gustafson wrote:<br>
<blockquote type=cite class=cite cite><tt>Hi All,<br><br>
Like many (or few?) I've been devoting some of my copious free-time to
listening in on this debate.&nbsp; My sense is that Denis may be on to
something but his ability to make progress on (at a minimum) completely
defining a &quot;problem at hand&quot; has not moved ahead smartly.&nbsp;
None will fault him for lack of effort :-)<br><br>
FWIW, real networks are beginning to see the operational problems that
indirect-CRLs could help solve.&nbsp; For example, an Enterprise runs a
CA system that pushes out CRLs at high frequency (every couple of
hours).&nbsp; People have been convinced that &quot;more frequent CRL
updates&quot; is vitally important to stronger/higher assurance
security.&nbsp; However, unexpected failures can clearly gum up the works
for some applications (e.g., smart card logon) because, sooner or later,
the CA is not able to push out a CRL on it's appointed schedule,
impacting secure applications.&nbsp; In this case, sometime after the CA
goes offline all certificate-based computer and network logons will fail
(creating a variation of the dreaded one-fail/all fail scenario).&nbsp;
This condition will persist until a new CRL is issued and fetched by all
clients.&nbsp; Newly appearing client logic that continues to use expired
(but not &quot;too expired&quot;) CRLs sounds like a dubious
approach/workaround but it's existence may be giving a signal that this
isn't the last time someone will suggest a little standards-rework is
needed in this area.&nbsp; Clearly, the CA (actually the configured CRL
serving systems) will have to work their way through a peak workload
starting shortly after the CA goes back online.</tt></blockquote><br>
Yes, has happen at least once.&nbsp; Some CA's, Microsoft 2003, allow an
emergency CRL or delta CRL to be signed which simply extends the
expiration of the last available CRL or delta.&nbsp; Of course this
presumes that you still have the ability to use the CA's private signing
key to sign the emergency CRL. There is a recent fix by Microsoft that
allows one to issue a Group Policy Object which will allow Windows Logon
even though the latest available CRL and delta have expired. It just
ignores the fact that the CRL and delta hve expired and performs all the
other checks.<br><br>
If your using OCSP or SCVP you might say the certificate is good even
though you really know only that it wasn't on the last or any prior CRL
or deltas and your last CRL has expired. That probably violates the
respective RFC's. No, I don't want to restart the past threads on good,
bad, not known. <br><br>
<br>
<blockquote type=cite class=cite cite><tt>In good theory, it would be
nice to deploy a separate server (with separate CRL-signing key) that
could issue CRLs on behalf of the CA.&nbsp; Better yet, multiple servers
(for redundancy), each with it's own signing key and each able to issue a
CRL that lists all certificates revoked by the CA.&nbsp; This would allow
new CRLs to be published even though the CA might be down long enough to
miss a periodic CRL update event.&nbsp; Likely there's at least one
application for all the different permutations, combinations,
corner-cases, etc. that might be supported by the current 
draft.<br><br>
Has anyone fully considered how these capabilities will be used in
practice and identified any glitches (real or imagined) in a typical
vendor's ability to create truly more robust solutions?&nbsp; Has that
work been assigned, implementor feedback fetched and processed,
etc.?<br><br>
More to the point, can someone articulate the apparent philosophical
disagreement over the basic requirements for any solution that this group
might embrace.&nbsp; That is, Denis seems to be saying that CRL-Issuer
Names, per se, will never be crypto-pure enough with respect to their
ability to point to (identify) a particular CRL-issuer/signing key?&nbsp;
If that's what he's saying, is that a real (undodgeable) technical issue
(i.e., it never goes away and is increasing problematic over
time)?<br><br>
Regards,<br><br>
--dg<br><br>
<br>
</tt><br><br>
Aisenberg, Michael wrote:<br>
<blockquote type=cite class=cite cite><br>
<font size=2>Whatever RFC-based legacy arguments can be concocted here,
the gravamen of the utility of certs in a real world applied environment
depends in no small measure on the reliability (immediacy) of the
CRL.&nbsp; If we ever want to achieve truly interoperable federated
authentication regiemes usable, say in Defense and NatSec environments
talking to commercial environments, then we had better figure out how to
persuade RPs of the integrity of the CRL process.<br><br>
&nbsp;-----Original Message-----<br>
From:&nbsp;&nbsp; Stephen Farrell
[<a href="mailto:stephen.farrell@cs.tcd.ie">mailto:stephen.farrell@cs.tcd.ie</a>]<br>
Sent:&nbsp;&nbsp; Wed Jul 27 07:14:51 2005<br>
To:&nbsp;&nbsp;&nbsp;&nbsp; Denis Pinkas<br>
Cc:&nbsp;&nbsp;&nbsp;&nbsp; pkix<br>
Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Re: IDP indirectCRL
flag<br><br>
<br><br>
<br>
Denis,<br><br>
&gt; This procedural rule should be mentioned in the main body of the
document.<br><br>
That seems to go against the mitigate/supress approach you're
advocating<br>
in other messages to the list.<br><br>
&gt; However we are back with the vocabulary issue about &quot;indirect
CRLs&quot; and<br>
&gt; &quot;delegated CRLs&quot;.<br><br>
IMO a sufficient set of technical concerns have been raised that<br>
this isn't desirable for 3280bis.<br><br>
And, given that it seems that no-one else wants this distinction,
(at<br>
least for now, at least as currently presented), is it really<br>
worthwhile prolonging the discussion when the outcome is almost<br>
inevitable?<br><br>
Stephen.<br><br>
<br>
</blockquote>
<x-sigsep><p></x-sigsep>
<br>
Joel S. Kazin CPA, CISA, CISSP, CISM<br>
Senior Consultant<br>
Atos Origin<br>
40 Old Sleepy Hollow Road<br>
Pleasantville, New York 10570-3802<br>
USA<br>
Phone&nbsp; +1 914-769-8780<br>
Mobile&nbsp; +1 914-564-1484<br>
email<x-tab>&nbsp;&nbsp;&nbsp;</x-tab> joel.kazin@atosorigin.com<br>
<a href="http://www.atosorigin.com/" eudora="autourl">www.atosorigin.com<br>
</a></font></html>

------_=_NextPart_001_01C592CA.1E9EB014--

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 j6RFUwoM016366; Wed, 27 Jul 2005 08:30: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 j6RFUwo7016365; Wed, 27 Jul 2005 08:30:58 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6RFUve5016352 for <ietf-pkix@imc.org>; Wed, 27 Jul 2005 08:30:57 -0700 (PDT) (envelope-from degustafson@comcast.net)
Received: from [138.220.83.132] (dhcp-0-138-220-83-132.worldbank.org[138.220.83.132]) by comcast.net (sccrmhc13) with ESMTP id <20050727153049013005vmose>; Wed, 27 Jul 2005 15:30:50 +0000
Message-ID: <42E7A8A8.1080706@comcast.net>
Date: Wed, 27 Jul 2005 11:30:48 -0400
From: DE Gustafson <degustafson@comcast.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax;nscd1)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Aisenberg, Michael" <maisenberg@verisign.com>
CC: Stephen Farrell <stephen.farrell@cs.tcd.ie>, Denis Pinkas <denis.pinkas@bull.net>, pkix <ietf-pkix@imc.org>
Subject: Re: IDP indirectCRL flag
References: <53E097910379674FAF542ACC384CB82188D2DB@dul1wnexmb02.vcorp.ad.vrsn.com>
In-Reply-To: <53E097910379674FAF542ACC384CB82188D2DB@dul1wnexmb02.vcorp.ad.vrsn.com>
Content-Type: multipart/alternative; boundary="------------050203060008070802090201"
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <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.
--------------050203060008070802090201
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

  Hi All,

Like many (or few?) I've been devoting some of my copious free-time to 
listening in on this debate.  My sense is that Denis may be on to 
something but his ability to make progress on (at a minimum) completely 
defining a "problem at hand" has not moved ahead smartly.  None will 
fault him for lack of effort :-)

FWIW, real networks are beginning to see the operational problems that 
indirect-CRLs could help solve.  For example, an Enterprise runs a CA 
system that pushes out CRLs at high frequency (every couple of hours).  
People have been convinced that "more frequent CRL updates" is vitally 
important to stronger/higher assurance security.  However, unexpected 
failures can clearly gum up the works for some applications (e.g., smart 
card logon) because, sooner or later, the CA is not able to push out a 
CRL on it's appointed schedule, impacting secure applications.  In this 
case, sometime after the CA goes offline all certificate-based computer 
and network logons will fail (creating a variation of the dreaded 
one-fail/all fail scenario).  This condition will persist until a new 
CRL is issued and fetched by all clients.  Newly appearing client logic 
that continues to use expired (but not "too expired") CRLs sounds like a 
dubious approach/workaround but it's existence may be giving a signal 
that this isn't the last time someone will suggest a little 
standards-rework is needed in this area.  Clearly, the CA (actually the 
configured CRL serving systems) will have to work their way through a 
peak workload starting shortly after the CA goes back online.

In good theory, it would be nice to deploy a separate server (with 
separate CRL-signing key) that could issue CRLs on behalf of the CA.  
Better yet, multiple servers (for redundancy), each with it's own 
signing key and each able to issue a CRL that lists all certificates 
revoked by the CA.  This would allow new CRLs to be published even 
though the CA might be down long enough to miss a periodic CRL update 
event.  Likely there's at least one application for all the different 
permutations, combinations, corner-cases, etc. that might be supported 
by the current draft.

Has anyone fully considered how these capabilities will be used in 
practice and identified any glitches (real or imagined) in a typical 
vendor's ability to create truly more robust solutions?  Has that work 
been assigned, implementor feedback fetched and processed, etc.?

More to the point, can someone articulate the apparent philosophical 
disagreement over the basic requirements for any solution that this 
group might embrace.  That is, Denis seems to be saying that CRL-Issuer 
Names, per se, will never be crypto-pure enough with respect to their 
ability to point to (identify) a particular CRL-issuer/signing key?  If 
that's what he's saying, is that a real (undodgeable) technical issue 
(i.e., it never goes away and is increasing problematic over time)?

Regards,

--dg

Aisenberg, Michael wrote:

> Whatever RFC-based legacy arguments can be concocted here, the 
> gravamen of the utility of certs in a real world applied environment 
> depends in no small measure on the reliability (immediacy) of the 
> CRL.  If we ever want to achieve truly interoperable federated 
> authentication regiemes usable, say in Defense and NatSec environments 
> talking to commercial environments, then we had better figure out how 
> to persuade RPs of the integrity of the CRL process.
>
>  -----Original Message-----
> From:   Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie]
> Sent:   Wed Jul 27 07:14:51 2005
> To:     Denis Pinkas
> Cc:     pkix
> Subject:        Re: IDP indirectCRL flag
>
>
>
>
> Denis,
>
> > This procedural rule should be mentioned in the main body of the 
> document.
>
> That seems to go against the mitigate/supress approach you're advocating
> in other messages to the list.
>
> > However we are back with the vocabulary issue about "indirect CRLs" and
> > "delegated CRLs".
>
> IMO a sufficient set of technical concerns have been raised that
> this isn't desirable for 3280bis.
>
> And, given that it seems that no-one else wants this distinction, (at
> least for now, at least as currently presented), is it really
> worthwhile prolonging the discussion when the outcome is almost
> inevitable?
>
> Stephen.
>
>
>

--------------050203060008070802090201
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<tt> Hi All,<br>
<br>
Like many (or few?) I've been devoting some of my copious free-time to
listening in on this debate.&nbsp; My sense is that Denis may be on to
something but his ability to make progress on (at a minimum) completely
defining a "problem at hand" has not moved ahead smartly.&nbsp; None will
fault him for lack of effort :-)<br>
<br>
FWIW, real networks are beginning to see the operational problems that
indirect-CRLs
could help solve.&nbsp; For example, an Enterprise runs a CA system that
pushes out CRLs at high frequency (every couple of hours).&nbsp; People have
been convinced that "more frequent CRL updates" is vitally important to
stronger/higher assurance security.&nbsp; However, unexpected failures can
clearly gum up the works for some applications (e.g., smart card logon)
because, sooner or later, the CA is not able to push out a CRL on it's
appointed schedule, impacting secure applications.&nbsp; In this
case, sometime after the CA goes offline all certificate-based computer
and
network logons will fail (creating a variation of the dreaded
one-fail/all fail
scenario).&nbsp; This condition will persist until
a new CRL is issued and fetched by all clients.&nbsp; Newly appearing client
logic that continues to use expired (but not
"too expired") CRLs sounds like a dubious approach/workaround
but it's existence may be giving a signal that this isn't the
last time someone will suggest a little standards-rework is needed in
this area.&nbsp;
Clearly, the CA (actually the configured CRL serving systems) will have
to work their way through a peak workload starting shortly after the
CA goes back online.<br>
<br>
In good theory, it would be nice to deploy a separate server (with
separate
CRL-signing key) that could issue CRLs on behalf of the CA.&nbsp; Better
yet, multiple servers (for redundancy), each with it's own signing key
and each able to issue a CRL that lists all certificates revoked by the
CA.&nbsp; This would allow new CRLs to be published even though the CA might
be down long enough to miss a periodic CRL update event.&nbsp; Likely
there's at least one application for all the different permutations,
combinations, corner-cases, etc. that might be supported by the current
draft.<br>
<br>
Has anyone fully considered how these capabilities will be used in
practice and identified any glitches (real or imagined) in a typical
vendor's ability to create truly more robust solutions?&nbsp; Has that work
been assigned, implementor feedback fetched and processed, etc.?<br>
<br>
More to the point, can someone articulate the apparent philosophical
disagreement over the basic requirements for any solution that this
group might embrace.&nbsp; That is, Denis seems to be saying that CRL-Issuer
Names, per se, will never be crypto-pure enough with respect to their
ability to point to (identify) a particular CRL-issuer/signing key?&nbsp; If
that's what he's saying, is that a real (undodgeable) technical issue
(i.e., it never goes away and is increasing problematic over time)?<br>
<br>
Regards,<br>
<br>
--dg<br>
<br>
<br>
</tt><br>
<br>
Aisenberg, Michael wrote:<br>
<blockquote
 cite="mid53E097910379674FAF542ACC384CB82188D2DB@dul1wnexmb02.vcorp.ad.vrsn.com"
 type="cite">
  <title>Re: IDP indirectCRL flag</title>
<!-- Converted from text/plain format -->
  <p><font size="2">Whatever RFC-based legacy arguments can be
concocted here, the gravamen of the utility of certs in a real world
applied environment depends in no small measure on the reliability
(immediacy) of the CRL.&nbsp; If we ever want to achieve truly interoperable
federated authentication regiemes usable, say in Defense and NatSec
environments talking to commercial environments, then we had better
figure out how to persuade RPs of the integrity of the CRL process.<br>
  <br>
&nbsp;-----Original Message-----<br>
From: &nbsp; Stephen Farrell [<a href="mailto:stephen.farrell@cs.tcd.ie">mailto:stephen.farrell@cs.tcd.ie</a>]<br>
Sent:&nbsp;&nbsp; Wed Jul 27 07:14:51 2005<br>
To:&nbsp;&nbsp;&nbsp;&nbsp; Denis Pinkas<br>
Cc:&nbsp;&nbsp;&nbsp;&nbsp; pkix<br>
Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Re: IDP indirectCRL flag<br>
  <br>
  <br>
  <br>
  <br>
Denis,<br>
  <br>
&gt; This procedural rule should be mentioned in the main body of the
document.<br>
  <br>
That seems to go against the mitigate/supress approach you're advocating<br>
in other messages to the list.<br>
  <br>
&gt; However we are back with the vocabulary issue about "indirect
CRLs" and<br>
&gt; "delegated CRLs".<br>
  <br>
IMO a sufficient set of technical concerns have been raised that<br>
this isn't desirable for 3280bis.<br>
  <br>
And, given that it seems that no-one else wants this distinction, (at<br>
least for now, at least as currently presented), is it really<br>
worthwhile prolonging the discussion when the outcome is almost<br>
inevitable?<br>
  <br>
Stephen.<br>
  <br>
  <br>
  <br>
  </font>
  </p>
</blockquote>
</body>
</html>

--------------050203060008070802090201--

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 j6RDFAEP092176; Wed, 27 Jul 2005 06:15: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 j6RDFAWU092175; Wed, 27 Jul 2005 06:15:10 -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.9) with ESMTP id j6RDF8EW092130 for <ietf-pkix@imc.org>; Wed, 27 Jul 2005 06:15:09 -0700 (PDT) (envelope-from todd.glassey@worldnet.att.net)
Received: from gw (223.san-jose-01-03rs.ca.dial-access.att.net[12.72.192.223]) by worldnet.att.net (mtiwmhc11) with SMTP id <2005072713145011100o6ktne>; Wed, 27 Jul 2005 13:15:02 +0000
Message-ID: <021101c592ad$333cfe80$78c1480c@gw>
Reply-To: "todd glassey" <todd.glassey@att.net>
From: "todd glassey" <todd.glassey@worldnet.att.net>
To: "Aisenberg, Michael" <maisenberg@verisign.com>, "Stephen Farrell" <stephen.farrell@cs.tcd.ie>, "Denis Pinkas" <denis.pinkas@bull.net>
Cc: "pkix" <ietf-pkix@imc.org>
References: <53E097910379674FAF542ACC384CB82188D2DB@dul1wnexmb02.vcorp.ad.vrsn.com>
Subject: Re: IDP indirectCRL flag
Date: Wed, 27 Jul 2005 06:14:49 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_020C_01C59272.7E91D260"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1506
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <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_020C_01C59272.7E91D260
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Re: IDP indirectCRL flagThe key to this is a predefined practice model =
for its use. That means a fully defined process with a narrative and =
possibly swim-lane type audit diagrams. This is NOT a joke - if you want =
the Insurance Industry Auditors to buy off on the use model then you =
have to create it. The problem with PKIX is that this is really an IRTF =
effort  - PKIX needs end-use processes and models for the core IP's its =
created already.

Todd Glassey
  ----- Original Message -----=20
  From: Aisenberg, Michael=20
  To: Stephen Farrell ; Denis Pinkas=20
  Cc: pkix=20
  Sent: Wednesday, July 27, 2005 5:00 AM
  Subject: Re: IDP indirectCRL flag

  Whatever RFC-based legacy arguments can be concocted here, the =
gravamen of the utility of certs in a real world applied environment =
depends in no small measure on the reliability (immediacy) of the CRL.  =
If we ever want to achieve truly interoperable federated authentication =
regiemes usable, say in Defense and NatSec environments talking to =
commercial environments, then we had better figure out how to persuade =
RPs of the integrity of the CRL process.

   -----Original Message-----
  From:   Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie]
  Sent:   Wed Jul 27 07:14:51 2005
  To:     Denis Pinkas
  Cc:     pkix
  Subject:        Re: IDP indirectCRL flag

  Denis,

  > This procedural rule should be mentioned in the main body of the =
document.

  That seems to go against the mitigate/supress approach you're =
advocating
  in other messages to the list.

  > However we are back with the vocabulary issue about "indirect CRLs" =
and
  > "delegated CRLs".

  IMO a sufficient set of technical concerns have been raised that
  this isn't desirable for 3280bis.

  And, given that it seems that no-one else wants this distinction, (at
  least for now, at least as currently presented), is it really
  worthwhile prolonging the discussion when the outcome is almost
  inevitable?

  Stephen.

------=_NextPart_000_020C_01C59272.7E91D260
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: IDP indirectCRL flag</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1505" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>The key to this is a predefined =
practice model for=20
its use. That means a fully defined process with a narrative and =
possibly=20
swim-lane type audit diagrams. This is NOT a joke - if you want the =
Insurance=20
Industry Auditors to buy off on the use model then you have to create =
it. The=20
problem with PKIX is that this is really an IRTF effort&nbsp; - PKIX =
needs=20
end-use processes and models for the core IP's its created =
already.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Todd Glassey</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">From:=20
 <A title=3Dmaisenberg@verisign.com=20
 href=3D"mailto:maisenberg@verisign.com">Aisenberg, Michael</A> </DIV>
 <DIV style=3D"FONT: 10pt arial">To: <A =
title=3Dstephen.farrell@cs.tcd.ie=20
 href=3D"mailto:stephen.farrell@cs.tcd.ie">Stephen Farrell</A> ; <A=20
 title=3Ddenis.pinkas@bull.net =
href=3D"mailto:denis.pinkas@bull.net">Denis=20
 Pinkas</A> </DIV>
 <DIV style=3D"FONT: 10pt arial">Cc: <A =
title=3Dietf-pkix@imc.org=20
 href=3D"mailto:ietf-pkix@imc.org">pkix</A> </DIV>
 <DIV style=3D"FONT: 10pt arial">Sent: Wednesday, July 27, 2005 =
5:00=20
 AM</DIV>
 <DIV style=3D"FONT: 10pt arial">Subject: Re: IDP indirectCRL =
flag</DIV>
 <DIV> </DIV>
 Whatever RFC-based legacy arguments can be concocted =
here, the=20
 gravamen of the utility of certs in a real world applied environment =
depends=20
 in no small measure on the reliability (immediacy) of the CRL.&nbsp; =
If we=20
 ever want to achieve truly interoperable federated authentication =
regiemes=20
 usable, say in Defense and NatSec environments talking to commercial=20
 environments, then we had better figure out how to persuade RPs of the =

  integrity of the CRL process.<BR><BR>&nbsp;-----Original =
Message-----<BR>From:=20
  &nbsp; Stephen Farrell [<A=20
  =
href=3D"mailto:stephen.farrell@cs.tcd.ie">mailto:stephen.farrell@cs.tcd.i=
e</A>]<BR>Sent:&nbsp;&nbsp;=20
  Wed Jul 27 07:14:51 2005<BR>To:&nbsp;&nbsp;&nbsp;&nbsp; Denis=20
  Pinkas<BR>Cc:&nbsp;&nbsp;&nbsp;&nbsp;=20
  pkix<BR>Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Re: IDP =
indirectCRL=20
  flag<BR><BR><BR><BR><BR>Denis,<BR><BR>&gt; This procedural rule should =
be=20
  mentioned in the main body of the document.<BR><BR>That seems to go =
against=20
  the mitigate/supress approach you're advocating<BR>in other messages =
to the=20
  list.<BR><BR>&gt; However we are back with the vocabulary issue about=20
  "indirect CRLs" and<BR>&gt; "delegated CRLs".<BR><BR>IMO a sufficient =
set of=20
  technical concerns have been raised that<BR>this isn't desirable for=20
  3280bis.<BR><BR>And, given that it seems that no-one else wants this=20
  distinction, (at<BR>least for now, at least as currently presented), =
is it=20
  really<BR>worthwhile prolonging the discussion when the outcome is=20
  =
almost<BR>inevitable?<BR><BR>Stephen.<BR><BR><BR><BR></FONT></P></BLOCKQU=
OTE></BODY></HTML>

------=_NextPart_000_020C_01C59272.7E91D260--

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 j6RC1MZB066114; Wed, 27 Jul 2005 05:01: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 j6RC1M0i066113; Wed, 27 Jul 2005 05:01:22 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from peregrine.verisign.com (peregrine.verisign.com [216.168.239.74]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6RC1Lhw066076 for <ietf-pkix@imc.org>; Wed, 27 Jul 2005 05:01:21 -0700 (PDT) (envelope-from maisenberg@verisign.com)
Received: from dul1wnexcn02.vcorp.ad.vrsn.com (dul1wnexcn02.vcorp.ad.vrsn.com [10.170.12.139]) by peregrine.verisign.com (8.13.1/8.12.11) with ESMTP id j6RCOGKb012224; Wed, 27 Jul 2005 08:24:16 -0400
Received: from dul1wnexmb02.vcorp.ad.vrsn.com ([10.170.12.135]) by dul1wnexcn02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 27 Jul 2005 08:00:26 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C592A2.C5F58D5E"
Subject: Re: IDP indirectCRL flag
Date: Wed, 27 Jul 2005 08:00:25 -0400
Message-ID: <53E097910379674FAF542ACC384CB82188D2DB@dul1wnexmb02.vcorp.ad.vrsn.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: IDP indirectCRL flag
Thread-Index: AcWSnGhX1+pnohSbSC2LaNyq0fpPCwABl2iZ
From: "Aisenberg, Michael" <maisenberg@verisign.com>
To: "Stephen Farrell" <stephen.farrell@cs.tcd.ie>, "Denis Pinkas" <denis.pinkas@bull.net>
Cc: "pkix" <ietf-pkix@imc.org>
X-OriginalArrivalTime: 27 Jul 2005 12:00:26.0107 (UTC) FILETIME=[C6693CB0:01C592A2]
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <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_001_01C592A2.C5F58D5E
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

Whatever RFC-based legacy arguments can be concocted here, the gravamen =
of the utility of certs in a real world applied environment depends in =
no small measure on the reliability (immediacy) of the CRL.  If we ever =
want to achieve truly interoperable federated authentication regiemes =
usable, say in Defense and NatSec environments talking to commercial =
environments, then we had better figure out how to persuade RPs of the =
integrity of the CRL process.

 -----Original Message-----
From: 	Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie]
Sent:	Wed Jul 27 07:14:51 2005
To:	Denis Pinkas
Cc:	pkix
Subject:	Re: IDP indirectCRL flag

Denis,

> This procedural rule should be mentioned in the main body of the =
document.

That seems to go against the mitigate/supress approach you're advocating
in other messages to the list.

> However we are back with the vocabulary issue about "indirect CRLs" =
and=20
> "delegated CRLs".

IMO a sufficient set of technical concerns have been raised that
this isn't desirable for 3280bis.

And, given that it seems that no-one else wants this distinction, (at
least for now, at least as currently presented), is it really
worthwhile prolonging the discussion when the outcome is almost
inevitable?

Stephen.

------_=_NextPart_001_01C592A2.C5F58D5E
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<TITLE>Re: IDP indirectCRL flag</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>Whatever RFC-based legacy arguments can be concocted =
here, the gravamen of the utility of certs in a real world applied =
environment depends in no small measure on the reliability (immediacy) =
of the CRL.&nbsp; If we ever want to achieve truly interoperable =
federated authentication regiemes usable, say in Defense and NatSec =
environments talking to commercial environments, then we had better =
figure out how to persuade RPs of the integrity of the CRL process.<BR>
<BR>
&nbsp;-----Original Message-----<BR>
From: &nbsp; Stephen Farrell [<A =
HREF=3D"mailto:stephen.farrell@cs.tcd.ie">mailto:stephen.farrell@cs.tcd.i=
e</A>]<BR>
Sent:&nbsp;&nbsp; Wed Jul 27 07:14:51 2005<BR>
To:&nbsp;&nbsp;&nbsp;&nbsp; Denis Pinkas<BR>
Cc:&nbsp;&nbsp;&nbsp;&nbsp; pkix<BR>
Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Re: IDP indirectCRL =
flag<BR>
<BR>
<BR>
<BR>
<BR>
Denis,<BR>
<BR>
&gt; This procedural rule should be mentioned in the main body of the =
document.<BR>
<BR>
That seems to go against the mitigate/supress approach you're =
advocating<BR>
in other messages to the list.<BR>
<BR>
&gt; However we are back with the vocabulary issue about &quot;indirect =
CRLs&quot; and<BR>
&gt; &quot;delegated CRLs&quot;.<BR>
<BR>
IMO a sufficient set of technical concerns have been raised that<BR>
this isn't desirable for 3280bis.<BR>
<BR>
And, given that it seems that no-one else wants this distinction, =
(at<BR>
least for now, at least as currently presented), is it really<BR>
worthwhile prolonging the discussion when the outcome is almost<BR>
inevitable?<BR>
<BR>
Stephen.<BR>
<BR>
<BR>
<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C592A2.C5F58D5E--

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 j6RAE4Y5029091; Wed, 27 Jul 2005 03:14: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 j6RAE40C029090; Wed, 27 Jul 2005 03:14:04 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from smtp.cs.tcd.ie (relay.cs.tcd.ie [134.226.32.56]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6RAE3Zc029076 for <ietf-pkix@imc.org>; Wed, 27 Jul 2005 03:14:04 -0700 (PDT) (envelope-from stephen.farrell@cs.tcd.ie)
Received: from smtp.cs.tcd.ie (localhost [127.0.0.1]) by relay.cs.tcd.ie (Postfix) with ESMTP id B3A625E9F; Wed, 27 Jul 2005 11:14:02 +0100 (IST)
Received: from [127.0.0.1] (sfarrel2.dsg.cs.tcd.ie [134.226.36.26]) by smtp.cs.tcd.ie (Postfix) with ESMTP id 9124F2FD4; Wed, 27 Jul 2005 11:14:02 +0100 (IST)
Message-ID: <42E75FB1.6010109@cs.tcd.ie>
Date: Wed, 27 Jul 2005 11:19:29 +0100
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Denis Pinkas <denis.pinkas@bull.net>
Cc: pkix <ietf-pkix@imc.org>
Subject: Re: IDP indirectCRL flag
References: <OF74C22075.47ABB9FF-ONC125704B.003413A8@frcl.bull.fr>
In-Reply-To: <OF74C22075.47ABB9FF-ONC125704B.003413A8@frcl.bull.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>

Denis,

> This procedural rule should be mentioned in the main body of the document.

That seems to go against the mitigate/supress approach you're advocating
in other messages to the list.

> However we are back with the vocabulary issue about "indirect CRLs" and 
> "delegated CRLs".

IMO a sufficient set of technical concerns have been raised that
this isn't desirable for 3280bis.

And, given that it seems that no-one else wants this distinction, (at
least for now, at least as currently presented), is it really
worthwhile prolonging the discussion when the outcome is almost
inevitable?

Stephen.

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 j6RA61Op026286; Wed, 27 Jul 2005 03:06: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 j6RA60uF026285; Wed, 27 Jul 2005 03:06:01 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from osprey.verisign.com (osprey.verisign.com [216.168.239.75]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6RA5xrP026277 for <ietf-pkix@imc.org>; Wed, 27 Jul 2005 03:05:59 -0700 (PDT) (envelope-from maisenberg@verisign.com)
Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.1/8.12.11) with ESMTP id j6RATZvZ010946; Wed, 27 Jul 2005 06:29:36 -0400
Received: from dul1wnexmb02.vcorp.ad.vrsn.com ([10.170.12.135]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 27 Jul 2005 06:05:56 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C59292.C7BB35FE"
Subject: RE: IDP indirectCRL flag
Date: Wed, 27 Jul 2005 06:05:56 -0400
Message-ID: <53E097910379674FAF542ACC384CB82188D2D8@dul1wnexmb02.vcorp.ad.vrsn.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: IDP indirectCRL flag
Thread-Index: AcWR846zfM7Dp63lRJigXiYa9EUdlAAR75awABXerAU=
From: "Aisenberg, Michael" <maisenberg@verisign.com>
To: "Manger, James H" <James.H.Manger@team.telstra.com>, "pkix" <ietf-pkix@imc.org>
X-OriginalArrivalTime: 27 Jul 2005 10:05:56.0871 (UTC) FILETIME=[C8070170:01C59292]
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <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_001_01C59292.C7BB35FE
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

Secure Electronic Commerce. Ford & Baum. 2d ed.  Chp. 5

 -----Original Message-----
From: 	Manger, James H [mailto:James.H.Manger@team.telstra.com]
Sent:	Wed Jul 27 04:47:36 2005
To:	pkix
Subject:	RE: IDP indirectCRL flag

>> Perhaps your rules could work if a CRL issuer is not itself a CA
>> and it only handles certificates from a single CA.
>> However, a relying party cannot know (and must not assume)
>> that this is the case for the CRL issuer.

> True, but if the CRL IDP is NOT present, then it would mean
> that this CRL Isssuer MAY not work for multiples CAs.
> So there is no problem.

Wrong.
A CRL without IDP does NOT mean the *CRL issuer* always works for a =
single CA.  It means the scope of this specific CRL is a single CA.  The =
same CRL issuer may issue other CRLs (with IDP.indirectCRL=3Dtrue) =
covering multiple CAs.  So there is a problem with Denis's rules.

The example Denis has been asking for:

Cert 1:  { #=3D100, issuer=3DAlice, crl-dp.cRLIssuer=3DFred }

CRL 2:  { issuer=3DFred, no IDP, revokedCertificates {} }

A relying party verifying cert 1 and possessing CRL 2 would accept the =
cert according to Denis's rules, falsely ASSUMING Fred only works for =
Alice.

In fact, Fred also issues his own certs (eg cert 3) and works for Bert =
(see cert 4).

Cert 3:  { #=3D48, issuer=3DFred }
Cert 4:  { #=3D37, issuer=3DBert, crl-dp.cRLIssuer=3DFred }

CRL 5:  { issuer=3DFred, IDP.indirectCRL=3Dtrue, revokedCertificates {
            { #=3D100, extn { critical=3Dtrue, =
certificateIssuer=3DAlice} } }

CRL 5 shows cert 1 is revoked, while cert 3 & 4 are not revoked.

P.S. To Stefan:
Fred's and Alice's DNs are both matched from cert & CRL to determine =
that cert 1 is revoked.  However, only Fred's (not Bert's) DN is matched =
to determine that cert 3 is not revoked.  Indirect CRLs can fail if only =
one DN is ambiguous.
Perhaps a useful rule would be that at least 1 entry with a =
certificateIssuer entry must be present in a CRL for every CA within =
that CRL's scope (other that the CRL issuer).  If no certificates from a =
CA have been revoked a dummy entry with certificate number -1 (which is =
unlikely to ever correspond to a real certificate) could be included.  A =
relying party verifying a certificate with a CRL-DP.cRLIssuer field =
could require the 2 DN matches before accepting a CRL.

CRL 6:  { issuer=3DFred, IDP.indirectCRL=3Dtrue, revokedCertificates {
            { #=3D100, extn { critical=3Dtrue, =
certificateIssuer=3DAlice},
            { #=3D-1, extn { critical=3Dtrue, certificateIssuer=3DBert} =
} }

------_=_NextPart_001_01C59292.C7BB35FE
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<TITLE>RE: IDP indirectCRL flag</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

Secure Electronic Commerce. Ford &amp; Baum. 2d =
ed.&nbsp; Chp. 5 
 
&nbsp;-----Original Message----- 
From: &nbsp; Manger, James H [<A =
HREF=3D"mailto:James.H.Manger@team.telstra.com">mailto:James.H.Manger@tea=
m.telstra.com</A>] 
Sent:&nbsp;&nbsp; Wed Jul 27 04:47:36 2005 
To:&nbsp;&nbsp;&nbsp;&nbsp; pkix 
Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; RE: IDP indirectCRL =
flag 
 
 
&gt;&gt; Perhaps your rules could work if a CRL issuer is not itself a =
CA 
&gt;&gt; and it only handles certificates from a single CA. 
&gt;&gt; However, a relying party cannot know (and must not assume) 
&gt;&gt; that this is the case for the CRL issuer. 
 
&gt; True, but if the CRL IDP is NOT present, then it would mean 
&gt; that this CRL Isssuer MAY not work for multiples CAs. 
&gt; So there is no problem. 
 
Wrong. 
A CRL without IDP does NOT mean the *CRL issuer* always works for a =
single CA.&nbsp; It means the scope of this specific CRL is a single =
CA.&nbsp; The same CRL issuer may issue other CRLs (with =
IDP.indirectCRL=3Dtrue) covering multiple CAs.&nbsp; So there is a =
problem with Denis's rules. 
 
 
The example Denis has been asking for: 
 
Cert 1:&nbsp; { #=3D100, issuer=3DAlice, crl-dp.cRLIssuer=3DFred } 
 
CRL 2:&nbsp; { issuer=3DFred, no IDP, revokedCertificates {} } 
 
A relying party verifying cert 1 and possessing CRL 2 would accept the =
cert according to Denis's rules, falsely ASSUMING Fred only works for =
Alice. 
 
In fact, Fred also issues his own certs (eg cert 3) and works for Bert =
(see cert 4). 
 
Cert 3:&nbsp; { #=3D48, issuer=3DFred } 
Cert 4:&nbsp; { #=3D37, issuer=3DBert, crl-dp.cRLIssuer=3DFred } 
 
CRL 5:&nbsp; { issuer=3DFred, IDP.indirectCRL=3Dtrue, =
revokedCertificates { 
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; { =
#=3D100, extn { critical=3Dtrue, certificateIssuer=3DAlice} } } 
 
CRL 5 shows cert 1 is revoked, while cert 3 &amp; 4 are not revoked. 
 
 
P.S. To Stefan: 
Fred's and Alice's DNs are both matched from cert &amp; CRL to determine =
that cert 1 is revoked.&nbsp; However, only Fred's (not Bert's) DN is =
matched to determine that cert 3 is not revoked.&nbsp; Indirect CRLs can =
fail if only one DN is ambiguous. 
Perhaps a useful rule would be that at least 1 entry with a =
certificateIssuer entry must be present in a CRL for every CA within =
that CRL's scope (other that the CRL issuer).&nbsp; If no certificates =
from a CA have been revoked a dummy entry with certificate number -1 =
(which is unlikely to ever correspond to a real certificate) could be =
included.&nbsp; A relying party verifying a certificate with a =
CRL-DP.cRLIssuer field could require the 2 DN matches before accepting a =
CRL. 
 
CRL 6:&nbsp; { issuer=3DFred, IDP.indirectCRL=3Dtrue, =
revokedCertificates { 
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; { =
#=3D100, extn { critical=3Dtrue, certificateIssuer=3DAlice}, 
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; { =
#=3D-1, extn { critical=3Dtrue, certificateIssuer=3DBert} } }

</BODY>
</HTML>
------_=_NextPart_001_01C59292.C7BB35FE--

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 j6R9RbLb012168; Wed, 27 Jul 2005 02:27: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 j6R9RbdX012167; Wed, 27 Jul 2005 02:27:37 -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 j6R9RZus012115 for <ietf-pkix@imc.org>; Wed, 27 Jul 2005 02:27:36 -0700 (PDT) (envelope-from denis.pinkas@bull.net)
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id LAA15440; Wed, 27 Jul 2005 11:43:33 +0200
Received: from frcls4013 ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with SMTP id 2005072711284903:514 ; Wed, 27 Jul 2005 11:28:49 +0200 
Date: Wed, 27 Jul 2005 11:28:48 +0100
From: "Denis Pinkas" <denis.pinkas@bull.net>
To: "pkix" <ietf-pkix@imc.org>, "Manger, James H" <James.H.Manger@team.telstra.com>
Subject: Re: RE: IDP indirectCRL flag
X-mailer: Foxmail 5.0 [-fr-]
Mime-Version: 1.0
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 27/07/2005 11:28:49, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 27/07/2005 11:28:50, Serialize complete at 27/07/2005 11:28:50
Message-ID: <OF74C22075.47ABB9FF-ONC125704B.003413A8@frcl.bull.fr>
Content-Transfer-Encoding: 7bit
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>

James,

>>> Perhaps your rules could work if a CRL issuer is not itself a CA
>>> and it only handles certificates from a single CA.
>>> However, a relying party cannot know (and must not assume)
>>> that this is the case for the CRL issuer.

>> True, but if the CRL IDP is NOT present, then it would mean
>> that this CRL Isssuer MAY not work for multiples CAs.
>> So there is no problem.

>Wrong.
>A CRL without IDP does NOT mean the *CRL issuer* always works for a single CA.  
> It means the scope of this specific CRL is a single CA.  

Security is basically made of a good use cryptography *and* of procedural rules.

When a CA wants to delegate to another entity the responsibilty to issue revocation status 
information, the conditions are negotatied. Among the conditions, the CRL Issuer will  
have to accept to work (under a given name) only for that single CA. If the CRL Issuer 
accepts then the CRL Issuer is "nominated" and a CRL Issuer certificate is issued by the CA. 
If the CRL Isssuer does not accept, then the CRL Issuer certificate is not issued.

> The same CRL issuer may issue other CRLs (with IDP.indirectCRL=true) 
> covering multiple CAs.  So there is a problem with Denis's rules.

Let us see.

>The example Denis has been asking for:

>Cert 1:  { #=100, issuer=Alice, crl-dp.cRLIssuer=Fred }

>CRL 2:  { issuer=Fred, no IDP, revokedCertificates {} }

This is not sufficient. There is also the b) (2) condition, which is:

          (2)  A CRL Issuer certificate issued by the same CA that has 
               issued the target certificate MUST be found.  That 
               certificate MUST have the cRLSign bit set, and MUST 
               include in its subject field the same DN as the one 
               of the DNs present in the crLIssuer field and MUST be 
               within its validity period.

>A relying party verifying cert 1 and possessing CRL 2 would accept the cert 
> according to Denis's rules, falsely ASSUMING Fred only works for Alice.

The CRL Issuer certificate, under the procedural rules mentioned  above, AND
the fact that the CRL does NOT include an IDP extension demonstrates that 
Fred only works for Alice. 

The current text describes the relying party point of view, so procedural rules 
that apply to CAs and CRL Issuers are not to be mentioned in such a section.

This procedural rule should be mentioned in the main body of the document.
However we are back with the vocabulary issue about "indirect CRLs" and 
"delegated CRLs".

Denis

>In fact, Fred also issues his own certs (eg cert 3) and works for Bert (see cert 4).
>
>Cert 3:  { #=48, issuer=Fred }
>Cert 4:  { #=37, issuer=Bert, crl-dp.cRLIssuer=Fred }
>
>CRL 5:  { issuer=Fred, IDP.indirectCRL=true, revokedCertificates {
>            { #=100, extn { critical=true, certificateIssuer=Alice} } }
>
>CRL 5 shows cert 1 is revoked, while cert 3 & 4 are not revoked.
>
>
>P.S. To Stefan:
>Fred's and Alice's DNs are both matched from cert & CRL to determine that cert 1 is revoked.  However, only Fred's (not Bert's) DN is matched to determine that cert 3 is not revoked.  Indirect CRLs can fail if only one DN is ambiguous.
>Perhaps a useful rule would be that at least 1 entry with a certificateIssuer entry must be present in a CRL for every CA within that CRL's scope (other that the CRL issuer).  If no certificates from a CA have been revoked a dummy entry with certificate number -1 (which is unlikely to ever correspond to a real certificate) could be included.  A relying party verifying a certificate with a CRL-DP.cRLIssuer field could require the 2 DN matches before accepting a CRL.
>
>CRL 6:  { issuer=Fred, IDP.indirectCRL=true, revokedCertificates {
>            { #=100, extn { critical=true, certificateIssuer=Alice},
>            { #=-1, extn { critical=true, certificateIssuer=Bert} } }

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 j6R7Pcj6068105; Wed, 27 Jul 2005 00:25: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 j6R7Pcsg068104; Wed, 27 Jul 2005 00:25:38 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from mailao.vtcif.telstra.com.au (mailao.vtcif.telstra.com.au [202.12.144.17]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6R7PbE9068080 for <ietf-pkix@imc.org>; Wed, 27 Jul 2005 00:25:37 -0700 (PDT) (envelope-from James.H.Manger@team.telstra.com)
Received: from mailbi.vtcif.telstra.com.au (mailbi.vtcif.telstra.com.au [202.12.142.19]) by mailao.vtcif.telstra.com.au (Postfix) with ESMTP id 3355322FC2 for <ietf-pkix@imc.org>; Wed, 27 Jul 2005 17:25:30 +1000 (EST)
Received: from mail.cdn.telstra.com.au (localhost [127.0.0.1]) by mailbi.vtcif.telstra.com.au (Postfix) with ESMTP id C32A11DA81 for <ietf-pkix@imc.org>; Wed, 27 Jul 2005 17:25:29 +1000 (EST)
Received: from wsmsg2902.srv.dir.telstra.com (wsmsg2902.srv.dir.telstra.com [172.49.40.51]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id RAA25049 for <ietf-pkix@imc.org>; Wed, 27 Jul 2005 17:25:29 +1000 (EST)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Subject: RE: IDP indirectCRL flag
Date: Wed, 27 Jul 2005 17:21:48 +1000
Message-ID: <73388857A695D31197EF00508B08F29817965217@ntmsg0131.corpmail.telstra.com.au>
Thread-Topic: IDP indirectCRL flag
Thread-Index: AcWR846zfM7Dp63lRJigXiYa9EUdlAAR75aw
From: "Manger, James H" <James.H.Manger@team.telstra.com>
To: "pkix" <ietf-pkix@imc.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by above.proper.com id j6R7PcE9068095
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

>> Perhaps your rules could work if a CRL issuer is not itself a CA
>> and it only handles certificates from a single CA.
>> However, a relying party cannot know (and must not assume)
>> that this is the case for the CRL issuer.

> True, but if the CRL IDP is NOT present, then it would mean
> that this CRL Isssuer MAY not work for multiples CAs.
> So there is no problem.

Wrong.
A CRL without IDP does NOT mean the *CRL issuer* always works for a single CA.  It means the scope of this specific CRL is a single CA.  The same CRL issuer may issue other CRLs (with IDP.indirectCRL=true) covering multiple CAs.  So there is a problem with Denis's rules.

The example Denis has been asking for:

Cert 1:  { #=100, issuer=Alice, crl-dp.cRLIssuer=Fred }

CRL 2:  { issuer=Fred, no IDP, revokedCertificates {} }

A relying party verifying cert 1 and possessing CRL 2 would accept the cert according to Denis's rules, falsely ASSUMING Fred only works for Alice.

In fact, Fred also issues his own certs (eg cert 3) and works for Bert (see cert 4).

Cert 3:  { #=48, issuer=Fred }
Cert 4:  { #=37, issuer=Bert, crl-dp.cRLIssuer=Fred }

CRL 5:  { issuer=Fred, IDP.indirectCRL=true, revokedCertificates {
            { #=100, extn { critical=true, certificateIssuer=Alice} } }

CRL 5 shows cert 1 is revoked, while cert 3 & 4 are not revoked.

P.S. To Stefan:
Fred's and Alice's DNs are both matched from cert & CRL to determine that cert 1 is revoked.  However, only Fred's (not Bert's) DN is matched to determine that cert 3 is not revoked.  Indirect CRLs can fail if only one DN is ambiguous.
Perhaps a useful rule would be that at least 1 entry with a certificateIssuer entry must be present in a CRL for every CA within that CRL's scope (other that the CRL issuer).  If no certificates from a CA have been revoked a dummy entry with certificate number -1 (which is unlikely to ever correspond to a real certificate) could be included.  A relying party verifying a certificate with a CRL-DP.cRLIssuer field could require the 2 DN matches before accepting a CRL.

CRL 6:  { issuer=Fred, IDP.indirectCRL=true, revokedCertificates {
            { #=100, extn { critical=true, certificateIssuer=Alice},
            { #=-1, extn { critical=true, certificateIssuer=Bert} } }

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 j6QG5GNH041946; Tue, 26 Jul 2005 09:05: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 j6QG5Gwm041945; Tue, 26 Jul 2005 09:05:16 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from host15.websitesource.com (host15.websitesource.com [209.239.32.38]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6QG5Gre041938 for <ietf-pkix@imc.org>; Tue, 26 Jul 2005 09:05:16 -0700 (PDT) (envelope-from chokhani@orionsec.com)
Received: from wchokhani3 (static-70-21-114-242.res.east.verizon.net [70.21.114.242]) by host15.websitesource.com (8.12.10/8.12.10) with ESMTP id j6QG5EBW003642 for <ietf-pkix@imc.org>; Tue, 26 Jul 2005 12:05:16 -0400
From: "Santosh Chokhani" <chokhani@orionsec.com>
To: "'pkix'" <ietf-pkix@imc.org>
Subject: RE: RE: RE: Re: Correction to be done to <draft-pinkas-pkix-conf-crl-validation-01.txt>
Date: Tue, 26 Jul 2005 12:05:08 -0400
Message-ID: <002201c591fb$cf34f3e0$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: <OF47A3971A.FB3DB303-ONC125704A.004DFAE1@frcl.bull.fr>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
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>

Denis,

Delegated single CRL issuer is a new mechanism and can not fit the current
X.509 or 3280.

You are welcome to help build new extensions if PKIX and X.509 groups are
interested in.

-----Original Message-----
From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On
Behalf Of Denis Pinkas
Sent: Tuesday, July 26, 2005 11:12 AM
To: Stefan Santesson; Sharon Boeyen; David A. Cooper; Santosh Chokhani
Cc: pkix
Subject: Re: RE: RE: Re: Correction to be done to
<draft-pinkas-pkix-conf-crl-validation-01.txt>

>Denis,

>Make it simple?

>In your simple case the CRL would not contain the name of the 
>certificate issuer anywhere!

Yes, but this is NOT needed from a security point of view.

>Disregarding any increased security vulnerability due to decreased name 
>matching between cert and CRL, it would require change to existing code 
>to handle this new special case, introducing detection and special 
>handling of "delegated CRL".

If you take a look at my I-D, what you call "existing code" is still being
supported.

My proposal is to add a (more simple) piece of code that would avoid
implementers to 
implement the existing algorithm that is more complex, since it is
applicable when 
many non-mandatory-to-support extensions are present.

Denis

>That is NOT called making things simple. That is creating problems.

>
>Stefan Santesson
>Program Manager, Standards Liaison
>Windows Security

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 j6QG2cxP041666; Tue, 26 Jul 2005 09: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 j6QG2cjN041665; Tue, 26 Jul 2005 09:02:38 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from host15.websitesource.com (host15.websitesource.com [209.239.32.38]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6QG2bbe041654 for <ietf-pkix@imc.org>; Tue, 26 Jul 2005 09:02:37 -0700 (PDT) (envelope-from chokhani@orionsec.com)
Received: from wchokhani3 (static-70-21-114-242.res.east.verizon.net [70.21.114.242]) by host15.websitesource.com (8.12.10/8.12.10) with ESMTP id j6QG2aBW029218 for <ietf-pkix@imc.org>; Tue, 26 Jul 2005 12:02:38 -0400
From: "Santosh Chokhani" <chokhani@orionsec.com>
To: "'pkix'" <ietf-pkix@imc.org>
Subject: RE: RE: Correction to be done to <draft-pinkas-pkix-conf-crl-validation-01.txt>
Date: Tue, 26 Jul 2005 12:02:30 -0400
Message-ID: <002101c591fb$70b0a210$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
In-Reply-To: <OF4024B45D.BB042776-ONC125704A.004D705B@frcl.bull.fr>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Importance: Normal
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j6QG2cbe041660
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <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,

See responses in-line under [Santosh;]

-----Original Message-----
From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On
Behalf Of Denis Pinkas
Sent: Tuesday, July 26, 2005 11:06 AM
To: Santosh Chokhani; 'pkix'
Subject: Re: RE: Correction to be done to
<draft-pinkas-pkix-conf-crl-validation-01.txt>

Santosh,

>All of the CRL and Indirect CRL related changes Dennis has proposed are 
>not required, change the standard, make the standard less secure, 
>and/or do not solve the issue of name collisions.

There is no demonstration of any of the above two assertions: "make the
standard less secure, and/or do not solve the issue of name collisions".

[Santosh: As I responded to the previous posting and as I have responded to
other postings, your posting are changing the standard.  There is nothing
wrong with that per se.  But, folks need to agree to break backward
compatibility and change the standard.]

See another remark below.

>-----Original Message-----
>From: owner-ietf-pkix@mail.imc.org 
>[mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stephen Farrell
>Sent: Friday, July 22, 2005 11:07 AM
>To: Denis Pinkas
>Cc: Santosh Chokhani; David A. Cooper; Stefan Santesson; pkix
>Subject: Re: Correction to be done to 
><draft-pinkas-pkix-conf-crl-validation-01.txt>
>
>Denis,
>
>> The point is not simply a vocabulary problem, but that that it is 
>> possible *for a RP* to support CRLs issued by CRL Issuers that are 
>> not CAs, without the need to support the indirectCRL boolean and the 
>> certificate issuer CRL entry extension and this makes the algorithm 
>> simpler, easier to implement, faster, etc ...
>
>I think this'd be a bad idea. Aside from anything else, it assumes that 
>some relationships between certificate and CRL issuers won't change 
>over time. Those do change and if this were adopted the RP's wouldn't 
>have a way to easily see that.

If they change, then the IDP extension is used and the problem is solved.
But in the simple case I am looking at, the point is to have one CRL Issuer 
servicing only one CA.

Denis

>Stephen.

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 j6QG0KM4041442; Tue, 26 Jul 2005 09:00: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 j6QG0KwL041441; Tue, 26 Jul 2005 09:00:20 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from host15.websitesource.com (host15.websitesource.com [209.239.32.38]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6QG0K5g041435 for <ietf-pkix@imc.org>; Tue, 26 Jul 2005 09:00:20 -0700 (PDT) (envelope-from chokhani@orionsec.com)
Received: from wchokhani3 (static-70-21-114-242.res.east.verizon.net [70.21.114.242]) by host15.websitesource.com (8.12.10/8.12.10) with ESMTP id j6QG0IBW023017 for <ietf-pkix@imc.org>; Tue, 26 Jul 2005 12:00:20 -0400
From: "Santosh Chokhani" <chokhani@orionsec.com>
To: "'pkix'" <ietf-pkix@imc.org>
Subject: RE: RE: IDP indirectCRL flag
Date: Tue, 26 Jul 2005 12:00:12 -0400
Message-ID: <001e01c591fb$1e6c25b0$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
In-Reply-To: <OF9E8450E9.9D3242D0-ONC125704A.004DC77A@frcl.bull.fr>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Importance: Normal
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j6QG0K5g041436
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <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,

See responses in-line under [Santosh:].  Text not deemed cogent may be
redacted.

-----Original Message-----
From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On
Behalf Of Denis Pinkas
Sent: Tuesday, July 26, 2005 11:10 AM
To: Santosh Chokhani; 'pkix'
Subject: Re: RE: IDP indirectCRL flag

>James Manger and Denis,
>
>Can you explain me why we would want to change the standard and impose 
>these additional constraints for indirect CRL?

A this time of the discussion, I would say that the most complex case of
indirect CRLs 
(i.e. the CRL MAY contain revocation status information from more than one
CA) will 
need to have some sentences "polished".

[Santosh: The text in 3280 biz seems ok.]

The CRL general algorithm will need to be made secure to correctly support
CRL name 
collisions and also to clarify how it is made sure that the CRL is signed by
the "right" entity 
(this applies to the simplest case where the CA itself is signing the CRL).

[Santosh: We have gone over this again and again.  This is not an ICRL issue
alone.  It impacts the direct CRL also.  The authors are leaning towards
requiring the same TA and adding text to Security Considerations.  While not
the best solution, this is something we can live with.]

The current algorithm would also need to support the case of a cache that
contains :

 a) "old" but still usable CRLs,

 b) more than one CRL valid at time t.  

[Santosh: These are relying party detail and the standard should provide
some leeway in using thisUpdate and nextUpdate and associated grace period.
I would rather the standard provides some flexibility and guidance in
security considerations as opposed to mandate something.]

Having said that, I wonder that due to the number of extensions that MUST be
supported, 
the current algorithm, when handling indirect CRLs, will be widely deployed.

[If you want to propose a single delegated CRL, this must be done via a new
extension or show how existing implementations can stay compliant with it.
If you choose the new extension approach, it may also need to be vetted
through X.509]

On another end, I have identified a case that would allow a much simpler
implementation 
and would promote the separation between the CA and the CRL Isssuer. This
will apply only 
when the CRL Issuer serves one CA.

[Santosh: See the comment above]

We might call that case "delegated CRL" and that case could coexist with the
more complex 
case of "indirect CRLs".

See below additional responses to James. 

>-----Original Message-----
>From: owner-ietf-pkix@mail.imc.org 
>[mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Manger, James H
>Sent: Sunday, July 24, 2005 9:43 PM
>To: pkix
>Subject: RE: IDP indirectCRL flag
>
>Denis,
>
>Perhaps your rules could work if a CRL issuer is not itself a CA and it 
>only handles certificates from a single CA.  However, a relying party 
>cannot know (and must not assume) that this is the case for the CRL 
>issuer.

True, but if the CRL IDP is NOT present, then it would mean that this CRL
Isssuer 
MAY not work for multiples CAs. So there is no problem.

[Santosh: If the CRL may contain revocation status of certificates not
issued by the CRL issuer, there must be an IDP or a new extension defined
(most likely critical)]

>A certificate with a CRL-DP.cRLIssuer field tells the RP that the named 
>CRL issuer handles certificates from at least the issuer of this 
>certificate.

True.

>It gives no information about how many other CAs (if any) the CRL 
>issuer may also handle, nor whether the CRL issuer is also a CA itself.

Yes, but that information is not necessary.

> A
>CRL-DP.cRLIssuer field tells the RP that some CRLs from the named CRL 
>issuer should cover this certificate, but it does not tell the RP that 
>all CRLs do.

Well in the simple case where the CRL is complete, the algorithm I have
presented applies.

If there is a CRL splitting then the algorithm would be more complicated.

>P.S. A CRL issuer may as well use the same name as the CA if it is only 
>ever going to issue revocation info for that CA's certificates.  That 
>is, the CA delegates CRL issuance to a separate key, not to a separate 
>name.  This avoids CRL-DP.cRLIssuer, IDP.indirectCRL & 
>CRL-ENTRY.certificateIssuer fields completely.

I wonder if the current algorithm in RFC 3280 handles that case explicitly.
My I-D handles the two cases.

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 j6QENZp3031983; Tue, 26 Jul 2005 07:23: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 j6QENZ0V031982; Tue, 26 Jul 2005 07:23:35 -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 j6QENYj7031973 for <ietf-pkix@imc.org>; Tue, 26 Jul 2005 07:23:34 -0700 (PDT) (envelope-from denis.pinkas@bull.net)
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA50406; Tue, 26 Jul 2005 16:39:31 +0200
Received: from frcls4013 ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with SMTP id 2005072616244628:278 ; Tue, 26 Jul 2005 16:24:46 +0200 
Date: Tue, 26 Jul 2005 16:24:47 +0100
From: "Denis Pinkas" <denis.pinkas@bull.net>
To: "Stefan Santesson" <stefans@microsoft.com>, "pkix" <ietf-pkix@imc.org>
Cc: "David A. Cooper" <david.cooper@nist.gov>
Subject: Re: Updated position on indirect CRL path restrictions
X-mailer: Foxmail 5.0 [-fr-]
Mime-Version: 1.0
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 26/07/2005 16:24:46, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 26/07/2005 16:24:47, Serialize complete at 26/07/2005 16:24:47
Message-ID: <OF10B8BB72.E2597332-ONC125704A.004F2C16@frcl.bull.fr>
Content-Transfer-Encoding: 7bit
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>

Stefan,

See below.

>All,

>I would like to change my position on the issue of indirect CRL path
>restrictions.

>I do no longer propose any further restrictions other than those
>originally proposed in RFC 3280bis.

>The cause of this is that I realized that I, and I think also the
>discussion on this list, have made an omission in the assessment of the
>name collision threat of indirect CRLs.

>In the name matching between a certificate and an indirect CRL there is
>not only a name matching of the CRL Issuer name between the CRL issuer
>field in the CDP extension of the certificate against the Issuer name of
>the CRL, there is also a name matching of the certificate issuer name
>between the certificate issuer CRL entry extension in the CRL and the
>issuer field of the validated certificate.

>So for a successful CRL replacement, there need to be both a CRL issuer
>name collision AND a CA name collision at the same time + a URL
>collision of the storage location of the CRL (even though specification
>of a URL is optional and may not be present, it is highly likely to be
>present in indirect CRLs).

It would seem that your remark is correct. Howver until I see the writing of a text 
which tells exactly how the two names are verified, I will hold my position: 
the current text is far from crystal clear and even if the probability becomes low 
it is not equal to zero.

There is also an exception: when a CA issues a CRL for itself and other CAs 
using a CRL signing key different from the certificate signing key.

In such a case it must be made sure that the "same certification path" is being used. 

I would also like to change my position :
"same trust anchor" does not even MITIGATE the risk, 
however the "same certification path" SUPPRESSES it in any case. 

If we had no other solution at hand, then we would have to live with it and place 
a warning in the security considerations section. However this is unnecessary 
since there is a secure solution at hand: "same certification path".

Denis

>More clearly:

>If CA A use CRL issuer A, there must be another colliding CA A' using a
>colliding CRL issuer A' (both names must collide at the same time) for a
>successful replacement to take place.

>This is a highly unlikely event, especially given the rarity of indirect
>CRL use in the first place.
>Forcing the certificate and the CRL to be validated from the same root
>should thus be sufficient to mitigate any realistic threats.

>However, I'm still for a recommendation that paths SHOULD be closely
>related and pointing out that conformant implementations MAY choose to
>apply restrictions on deviating paths for reasons of local policy and/or
>efficiency.

>Stefan Santesson
>Program Manager, Standards Liaison
>Windows Security
> 
>
>

Regards,

Denis Pinkas

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 j6QEBtMJ030960; Tue, 26 Jul 2005 07:11: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 j6QEBtNj030959; Tue, 26 Jul 2005 07:11:55 -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 j6QEBsF4030952 for <ietf-pkix@imc.org>; Tue, 26 Jul 2005 07:11:54 -0700 (PDT) (envelope-from denis.pinkas@bull.net)
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA27512; Tue, 26 Jul 2005 16:27:51 +0200
Received: from frcls4013 ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with SMTP id 2005072616130540:269 ; Tue, 26 Jul 2005 16:13:05 +0200 
Date: Tue, 26 Jul 2005 16:13:07 +0100
From: "Denis Pinkas" <denis.pinkas@bull.net>
To: "Stefan Santesson" <stefans@microsoft.com>, "pkix" <ietf-pkix@imc.org>, "Manger, James H" <James.H.Manger@team.telstra.com>
Subject: Re: RE: RE: draft-pinkas-pkix-conf-crl-validation-02.txt is available
X-mailer: Foxmail 5.0 [-fr-]
Mime-Version: 1.0
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 26/07/2005 16:13:05, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 26/07/2005 16:13:07, Serialize complete at 26/07/2005 16:13:07
Message-ID: <OF5C339A5B.458E3D78-ONC125704A.004E1A4E@frcl.bull.fr>
Content-Transfer-Encoding: 7bit
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>

Stefan,

>> However from a RP point of view, in the case the CRL contains
>> certificates from a single CA, if this field is present *but no test is made on it*,
>> would you be able to provide an example where the algorithm would give 
>> the wrong result  ?

>Yes,

Great ! Let us see.

>Consider a CA that provides partitioned CRLs where each CRL only covers
>a limited number of the issued certificates. This could be partitioned
>by issuing key, serial number range, certificate policy or anything
>(except reason code).

The simple case applies when the CRL IDP extension is NOT supported by the RP. 
Partitioned CRLs mandate the presence of the CRL IDP extension.

Thank you for trying.

Denis

>I now rename one of the CRLs that does NOT cover my revoked certificate
>and manage to replace it with the one that would indicate that my
>certificate is revoked.
>
>Since you don't check the IDP you will miss the fact that the CRL has
>been renamed and replaced and you will accept my certificate as valid.
>
>So you have now completely changed the trust model to force the RP to
>trust the directory to provide the correct partitioned CRL. This is a
>severe security flaw.
>
>
>Stefan Santesson
>Program Manager, Standards Liaison
>Windows Security
> 
>
>> -----Original Message-----
>> From: owner-ietf-pkix@mail.imc.org
>[mailto:owner-ietf-pkix@mail.imc.org]
>> On Behalf Of Denis Pinkas
>> Sent: den 22 juli 2005 08:30
>> To: pkix; Manger, James H
>> Subject: Re: RE: draft-pinkas-pkix-conf-crl-validation-02.txt is
>available
>> 
>> 
>> James,
>> 
>> >Denis,
>> 
>> >By ignoring the IDP.indirectCRL flag your rules can give the wrong
>result
>> >by accepting a CRL that does not apply to a given certificate.
>> 
>> If the CRL issuer is only "working" on behalf of a single CA, I do not
>> think so.
>> Otherwise, would you provide an example where the result would be
>wrong ?
>> 
>> >Consider a certificate that has a CRL-DP extension with a cRLIssuer
>field
>> >and consider a CRL without an IDP extension from that cRLIssuer.
>> 
>> >Your rules say that the CRL covers the certificate (ie would list the
>> certificate
>> >if it was revoked), but it does not cover it.  The CRL (without IDP)
>only
>> covers
>> >certificates issued by the authority that issued the CRL.
>> 
>> Here are some extracts from 3280bis :
>> 
>> Page 51:
>> 
>>    CRL issuers issue CRLs.  The CRL issuer is either the CA or an
>entity
>>    that has been authorized by the CA to issue CRLs.
>> 
>> Page 62:
>> 
>>    If the distributionPoint field is absent, the CRL MUST contain
>>    entries for all revoked unexpired certificates issued by the CRL
>>    issuer, if any, within the scope of the CRL.
>> 
>> Your comment applies since the only case where a CRL issuer
>> may issue certificates is when it is also a CA.
>> 
>> This sentence then mandates CRL Issuers to support the
>distributionPoint
>> field present.
>> 
>> However from a RP point of view, in the case the CRL contains
>certificates
>> from a single CA, if this field is present *but no test is made on
>it*,
>> would you
>> be able to provide an example where the algorithm would give the wrong
>> result  ?
>> 
>> >Only when IDP.indirectCRL is true must the CRL issuer "ensure that
>> >the CRL is complete in that it contains all revocation entries ...
>from
>> all
>> >authorities that identify this CRL in their certificates" [X.509,
>8.6.2.2
>> IDP extension].
>> 
>> The word 'issuer' is missing. The exact sentence is:
>> 
>> If indirectCRL is true, [..] it is the responsibility of the CRL
>issuer to
>> ensure that
>> the CRL is complete in that it contains all revocation entries [...]
>from
>> all authorities
>> that identify this CRL *issuer* in their certificates.
>> 
>> 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 j6QEAkvF030862; Tue, 26 Jul 2005 07:10: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 j6QEAksL030861; Tue, 26 Jul 2005 07:10:46 -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 j6QEAi5N030850 for <ietf-pkix@imc.org>; Tue, 26 Jul 2005 07:10:45 -0700 (PDT) (envelope-from denis.pinkas@bull.net)
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA14150; Tue, 26 Jul 2005 16:26:31 +0200
Received: from frcls4013 ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with SMTP id 2005072616114476:265 ; Tue, 26 Jul 2005 16:11:44 +0200 
Date: Tue, 26 Jul 2005 16:11:46 +0100
From: "Denis Pinkas" <denis.pinkas@bull.net>
To: "Stefan Santesson" <stefans@microsoft.com>, "Sharon Boeyen" <sharon.boeyen@entrust.com>, "David A. Cooper" <david.cooper@nist.gov>, "Santosh Chokhani" <chokhani@orionsec.com>
Cc: "pkix" <ietf-pkix@imc.org>
Subject: Re: RE: RE: Re: Correction to be done to <draft-pinkas-pkix-conf-crl-validation-01.txt>
X-mailer: Foxmail 5.0 [-fr-]
Mime-Version: 1.0
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 26/07/2005 16:11:45, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 26/07/2005 16:11:47, Serialize complete at 26/07/2005 16:11:47
Message-ID: <OF47A3971A.FB3DB303-ONC125704A.004DFAE1@frcl.bull.fr>
Content-Transfer-Encoding: 7bit
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>

>Denis,

>Make it simple?

>In your simple case the CRL would not contain the name of the
>certificate issuer anywhere!

Yes, but this is NOT needed from a security point of view.

>Disregarding any increased security vulnerability due to decreased name
>matching between cert and CRL, it would require change to existing code
>to handle this new special case, introducing detection and special
>handling of "delegated CRL".

If you take a look at my I-D, what you call "existing code" is still being supported.

My proposal is to add a (more simple) piece of code that would avoid implementers to 
implement the existing algorithm that is more complex, since it is applicable when 
many non-mandatory-to-support extensions are present.

Denis

>That is NOT called making things simple. That is creating problems.

>
>Stefan Santesson
>Program Manager, Standards Liaison
>Windows Security

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 j6QE8RdX030673; Tue, 26 Jul 2005 07:08: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 j6QE8RUM030672; Tue, 26 Jul 2005 07:08:27 -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 j6QE8QYQ030643 for <ietf-pkix@imc.org>; Tue, 26 Jul 2005 07:08:26 -0700 (PDT) (envelope-from denis.pinkas@bull.net)
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA42710; Tue, 26 Jul 2005 16:24:19 +0200
Received: from frcls4013 ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with SMTP id 2005072616093337:263 ; Tue, 26 Jul 2005 16:09:33 +0200 
Date: Tue, 26 Jul 2005 16:09:34 +0100
From: "Denis Pinkas" <denis.pinkas@bull.net>
To: "Santosh Chokhani" <chokhani@orionsec.com>, "'pkix'" <ietf-pkix@imc.org>
Subject: Re: RE: IDP indirectCRL flag
X-mailer: Foxmail 5.0 [-fr-]
Mime-Version: 1.0
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 26/07/2005 16:09:33, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 26/07/2005 16:09:35, Serialize complete at 26/07/2005 16:09:35
Message-ID: <OF9E8450E9.9D3242D0-ONC125704A.004DC77A@frcl.bull.fr>
Content-Transfer-Encoding: 7bit
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>

>James Manger and Denis,
>
>Can you explain me why we would want to change the standard and impose these
>additional constraints for indirect CRL?

A this time of the discussion, I would say that the most complex case of indirect CRLs 
(i.e. the CRL MAY contain revocation status information from more than one CA) will 
need to have some sentences "polished".

The CRL general algorithm will need to be made secure to correctly support CRL name 
collisions and also to clarify how it is made sure that the CRL is signed by the "right" entity 
(this applies to the simplest case where the CA itself is signing the CRL).

The current algorithm would also need to support the case of a cache that contains :

 a) "old" but still usable CRLs,

 b) more than one CRL valid at time t.  

Having said that, I wonder that due to the number of extensions that MUST be supported, 
the current algorithm, when handling indirect CRLs, will be widely deployed.

On another end, I have identified a case that would allow a much simpler implementation 
and would promote the separation between the CA and the CRL Isssuer. This will apply only 
when the CRL Issuer serves one CA.

We might call that case "delegated CRL" and that case could coexist with the more complex 
case of "indirect CRLs".

See below additional responses to James. 

>-----Original Message-----
>From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On
>Behalf Of Manger, James H
>Sent: Sunday, July 24, 2005 9:43 PM
>To: pkix
>Subject: RE: IDP indirectCRL flag
>
>Denis,
>
>Perhaps your rules could work if a CRL issuer is not itself a CA and it only
>handles certificates from a single CA.  However, a relying party cannot know
>(and must not assume) that this is the case for the CRL issuer.

True, but if the CRL IDP is NOT present, then it would mean that this CRL Isssuer 
MAY not work for multiples CAs. So there is no problem.

>A certificate with a CRL-DP.cRLIssuer field tells the RP that the named CRL
>issuer handles certificates from at least the issuer of this certificate.

True.

>It gives no information about how many other CAs (if any) the CRL issuer may
>also handle, nor whether the CRL issuer is also a CA itself.  

Yes, but that information is not necessary.

> A
>CRL-DP.cRLIssuer field tells the RP that some CRLs from the named CRL issuer
>should cover this certificate, but it does not tell the RP that all CRLs do.

Well in the simple case where the CRL is complete, the algorithm I have presented applies.

If there is a CRL splitting then the algorithm would be more complicated.

>P.S. A CRL issuer may as well use the same name as the CA if it is only ever
>going to issue revocation info for that CA's certificates.  That is, the CA
>delegates CRL issuance to a separate key, not to a separate name.  This
>avoids CRL-DP.cRLIssuer, IDP.indirectCRL & CRL-ENTRY.certificateIssuer
>fields completely.

I wonder if the current algorithm in RFC 3280 handles that case explicitly.
My I-D handles the two cases.

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 j6QE4iRl030405; Tue, 26 Jul 2005 07:04: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 j6QE4iI2030404; Tue, 26 Jul 2005 07:04:44 -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 j6QE4hcU030395 for <ietf-pkix@imc.org>; Tue, 26 Jul 2005 07:04:43 -0700 (PDT) (envelope-from denis.pinkas@bull.net)
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA33656; Tue, 26 Jul 2005 16:20:35 +0200
Received: from frcls4013 ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with SMTP id 2005072616055032:258 ; Tue, 26 Jul 2005 16:05:50 +0200 
Date: Tue, 26 Jul 2005 16:05:51 +0100
From: "Denis Pinkas" <denis.pinkas@bull.net>
To: "Santosh Chokhani" <chokhani@orionsec.com>, "'pkix'" <ietf-pkix@imc.org>
Subject: Re: RE: Correction to be done to <draft-pinkas-pkix-conf-crl-validation-01.txt>
X-mailer: Foxmail 5.0 [-fr-]
Mime-Version: 1.0
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 26/07/2005 16:05:50, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 26/07/2005 16:05:51, Serialize complete at 26/07/2005 16:05:51
Message-ID: <OF4024B45D.BB042776-ONC125704A.004D705B@frcl.bull.fr>
Content-Transfer-Encoding: 7bit
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>

Santosh,

>All of the CRL and Indirect CRL related changes Dennis has proposed are not
>required, change the standard, make the standard less secure, and/or do not
>solve the issue of name collisions.

There is no demonstration of any of the above two assertions:
"make the standard less secure, and/or do not solve the issue of name collisions".

See another remark below.

>-----Original Message-----
>From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On
>Behalf Of Stephen Farrell
>Sent: Friday, July 22, 2005 11:07 AM
>To: Denis Pinkas
>Cc: Santosh Chokhani; David A. Cooper; Stefan Santesson; pkix
>Subject: Re: Correction to be done to
><draft-pinkas-pkix-conf-crl-validation-01.txt>
>
>Denis,
>
>> The point is not simply a vocabulary problem, but that that it is
>> possible *for a RP* to support CRLs issued by CRL Issuers that 
>> are not CAs, without the need to support the indirectCRL boolean 
>> and the certificate issuer CRL entry extension and this makes the 
>> algorithm simpler, easier to implement, faster, etc ...
>
>I think this'd be a bad idea. Aside from anything else, it assumes that some
>relationships between certificate and CRL issuers won't change over time.
>Those do change and if this were adopted the RP's wouldn't have a way to
>easily see that.

If they change, then the IDP extension is used and the problem is solved.
But in the simple case I am looking at, the point is to have one CRL Issuer 
servicing only one CA.

Denis

>Stephen.

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 j6QE2rDd030242; Tue, 26 Jul 2005 07:02: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 j6QE2rVf030241; Tue, 26 Jul 2005 07:02:53 -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 j6QE2pPo030234 for <ietf-pkix@imc.org>; Tue, 26 Jul 2005 07:02:52 -0700 (PDT) (envelope-from denis.pinkas@bull.net)
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA50056; Tue, 26 Jul 2005 16:18:49 +0200
Received: from frcls4013 ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with SMTP id 2005072616040394:255 ; Tue, 26 Jul 2005 16:04:03 +0200 
Date: Tue, 26 Jul 2005 16:04:05 +0100
From: "Denis Pinkas" <denis.pinkas@bull.net>
To: "Tim Polk" <tim.polk@nist.gov>, "ietf-pkix@imc.org" <ietf-pkix@imc.org>
Subject: Re: RE: How ambiguous are names in actuality?
X-mailer: Foxmail 5.0 [-fr-]
Mime-Version: 1.0
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 26/07/2005 16:04:04, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 26/07/2005 16:04:05, Serialize complete at 26/07/2005 16:04:05
Message-ID: <OF85159FB2.833ABCD3-ONC125704A.004D46D4@frcl.bull.fr>
Content-Transfer-Encoding: 7bit
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>

>Denis,

>Santosh's presentation was at the Washington IETF in November 2004.  Due to 
>time constraints, he had to abbreviate his presentation, but the complete 
>set of slides were included in the meeting proceedings.  The slides can be 
>found at:

>http://www1.ietf.org/proceedings_new/04nov/slides/pkix-4/sld1.htm

I have read these slides. However there is a major difference betwen slides 
and text in an I-D. There has been a request for text for both approches 
to be placed in an I-D. I made the effort to write it.

Should I understand that you do not support the promulgation of 
Santosh's approach ?

Denis

>Tim
>
>At 12:01 PM 7/18/2005 -0400, Santosh Chokhani wrote:
>
>>Denis,
>>
>>Solution was presented at the IETF.  I do not intend to draft an I-D unless
>>the WG chairs and AD intend to support its promulgation.
>>
>>-----Original Message-----
>>From: Denis Pinkas [mailto:denis.pinkas@bull.net]
>>Sent: Monday, July 18, 2005 12:56 PM
>>To: Santosh Chokhani; ietf-pkix@imc.org
>>Subject: Re: How ambiguous are names in actuality?
>>
>>
>>Santosh,
>>
>> >To me the basic problem with Tim's posting is that it is a band aid
>> >solution to a problem that has a very simple solution.
>>
>>The problem raised is much wider that the CRL problem where the solution
>>fits in two lines of text:
>>
>>"The full certification path that has been used to validate the target
>>   certificate MUST also be used to validate the CRL issuer certificate".
>>
>>As far as I remember I have not seen a description of your solution posted
>>in:
>>http://www.ietf.org/internet-drafts/draft-santosh-pkix-...-00.txt
>>
>>Denis
>>
>> >When we look at the issue as an abstract graph theory problem and want
>> >a clean and simple solution to make sure that the correct CRL is
>> >fetched, the solution I have proposed solves the problem.
>> >
>> >Any thing else we do, is simply rationalization to support one or more
>> >unarticulated motives.
>> >
>> >-----Original Message-----
>> >From: owner-ietf-pkix@mail.imc.org
>> >[mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Denis Pinkas
>> >Sent: Monday, July 18, 2005 5:13 AM
>> >To: Tim Polk; ietf-pkix@imc.org
>> >Subject: Re: How ambiguous are names in actuality?
>> >
>> >
>> >
>> >Tim,
>> >
>> >My views are quite different. You are looking for a solution to
>> >MITIGATE the risk, whereas there exists a solution to SUPPRESS the
>> >risk, as it is explained below.
>> >The changes you propose, like "same trust anchor", do not suppress the
>>risk.
>> >
>> >
>> >You mention that the problem of name collisions exists both for two
>> >leaf certificates and for CRL certificates. This is correct. While the
>> >problem for CRL certificates arises
>> >only *during* the path verification algorithm, this is not the case for
>>leaf
>> >certificates.
>> >
>> >For a leaf certificate that has been verified to be valid, the output
>> >of the algorithm is a sequence of certificates up to a given trust
>> >anchor. The major issue is what
>> >to do with it, and this is NOT mentioned within RFC 3280.
>> >
>> >Leaf certificates may be used in two contexts:
>> >
>> >   a) access control or end-entity authentication,
>> >   b) non repudiation.
>> >
>> >These two cases are different and are explored below.
>> >
>> >ACCESS CONTROL OR END-ENTITY AUTHENTICATION
>> >
>> >There are two phases when a public key certificate is used for an
>> >access control service :
>> >
>> >- Phase 1 : the owner of the protected object must fill-in the ACL
>> >correctly,
>> >- Phase 2 : during an access, the sequence of certificates that has
>> >been validated
>> >                must be checked against the content of the ACL.
>> >
>> >The real issue is that nowhere in RFC 3280 it is said what the content
>> >of the ACL should be. Because of this lack of information, some
>> >implementations of "relying party software"
>> >may be subject to problems related to name collisions, while some others
>> >will not.
>> >
>> >There is no clear indication in RFC 3280 to tell how the owner of the
>> >protected object will make sure that it is pointing to the right
>> >certificate BEFORE using that certificate
>> >for access control purposes.
>> >
>> >The point is that the owner of the protected object SHALL enter the
>> >full certification path in the ACL. If it does not have the full path,
>> >then it SHALL construct it according to
>> >the validation policy that is appropriate for his application and SHOULD
>> >make sure
>> >that it is not revoked. It will thus use the full certification path and
>>may
>> >check either
>> >automatically using some local rules or may check using his brain that the
>> >full certification
>> >path is correct.
>> >
>> >Note that if the ACL would only contain the DN of the leaf certificate,
>> >then the access control mechanism would be subject to name collisions,
>> >
>> >When the ACL contains both the DN of the leaf certificate and all the
>> >DNs from the upper CA up to a trust anchor identified by its DN (i.e.
>> >the DN of the trust anchor is also taken,
>> >since there may be more than one trust anchor in a given validation
>>policy),
>> >then the
>> >access control mechanism can never be subject to name collisions.
>> >
>> >Since a validation policy may include more than one trust anchor, it
>> >means that it SHALL not be allowed to define a validation policy that
>> >uses two trust anchors with the same DN.
>> >
>> >This means that during phase 1, the owner of the protected object must
>> >fill-in the ACL with all the DNs from the certification path, including
>> >the DN from the trust anchor
>> >(of course a hash of it may be used instead) and that during phase 2, the
>> >whole certification path
>> >must be used and compared with the content of the ACL.
>> >
>> >This solution fully *suppresses* the risk in any case.
>> >
>> >Of course, in some contexts, some shortcuts may be taken (e.g. when
>> >there exists a single trust anchor in the validation policy) or when it
>> >may be known that name collisions
>> >may never happen (e.g. because all the CAs apply a given naming policy) but
>> >this is not
>> >the general case.
>> >
>> >The solution explained above is also much simpler than adding name
>> >constrains that could be anyway defeated.
>> >
>> >NON REPUDIATION
>> >
>> >With non repudiation, only the whole sequence of DN extracted from the
>> >certification path is meaningful. A DN like CN= "John William" does not
>> >make sense unless at the same time
>> >all the upper DNs from the CAs are used or displayed. So if someone wants
>>to
>> >know
>> >without any ambiguity who a signer is, it SHALL use of the sequence of DN
>>up
>> >to
>> >a trust anchor of the signature policy.
>> >
>> >Since a signature policy may include more than one trust anchor, it
>> >means that it SHALL NOT be allowed to define a signature policy that
>> >uses two trust anchors with the same DN.
>> >
>> >COLLISIONS BETWEEN CRL ISSUER NAMES
>> >
>> >For CRLs, I have already mentioned the additional sentence that shall
>> >be added to RFC 3280. It is copied again below  :
>> >
>> >"The full certification path that has been used to validate the target
>> >certificate MUST also be used to validate the CRL issuer certificate ".
>> >
>> >
>> >REPLY TO YOUR CONCLUSIONS
>> >
>> >As a reply to your conclusions: using path length constrains does not
>> >solve the issue. Adding other constrains does not solve the issue
>> >either. Using name constraints would
>> >introduce an order of magnitude of complexity and would not be effective in
>> >the general case.
>> >Using certification policies and path length constrains might help, but
>> >still do not solve
>> >the problem in the general case.
>> >
>> >
>> >Denis
>> >
>> >
>> >>Ambiguity has recently become a hot topic on this list.  This is a
>> >>really
>> >>complicated issue, and I have personally had a great deal of trouble
>> >>sorting out the real level of risk.  Some of the proposed changes would
>> >>greatly impact current software, and these changes should only be
>> >>contemplated if the risk is merits such change.
>> >>
>> >>So, I have spent a lot of time, off and on, thinking about ambiguity.
>> >>I
>> >>can't claim to have sorted it all out, but I have convinced myself that
>>one
>> >
>> >>minor change is absolutely required, and that the current suite of
>> >>mechanisms can virtually eliminate ambiguity in real PKIs.
>> >>
>> >>My thinking is appended to this message;  I apologize for its length,
>> >>but
>> >>to paraphrase Mark Twain, I simply don't have time to make this short and
>> >>concise.  I have attempted to define ambiguity, characterize the ways
>> >>ambiguity can enter into a PKI, and describe the set of mechanisms that
>> >>mitigate this risk.
>> >>
>> >>Thanks,
>> >>
>> >>Tim Polk
>> >>
>> >>----------------------------------------------------------------------
>> >>-
>> >>---------------------------------------------------------
>> >>
>> >>              How ambiguous are names in actuality, and how important
>> >> is it?
>> >>
>> >>I believe that X.509 expected assignment of unambiguous names based on
>> >>a
>> >>hierarchical system of naming authorities.  Whether you agree with that
>> >>premise, it is safe to say that the global X.500 directory and its
>> >>corresponding system of naming authorities do not exist. So, it may not be
>>
>> >>safe to assume that there are no name collisions whatsoever in all the DNs
>>
>> >>that appear in certificates and CRLs!  I am sure such collisions exist
>> >>somewhere (although I haven't encountered any examples).  The real
>>question
>> >
>> >>here is "What security risk does this situation present, and are the
>> >>current mechanisms adequate to address this risk?"
>> >>
>> >>Let's recognize that the goal for PKIX is not to have globally
>> >>unambiguous
>> >>names, but to be able to obtain a trustworthy public key to establish a
>> >>security service. Ambiguity in names is a problem when it causes the
>> >>relying party to trust the wrong public key.
>> >>
>> >>There are two ways ambiguous names could cause problems.  First, I
>> >>could
>> >>accept public keys from two certificates as representing the same person
>> >>based on the same subject name.  If these two certificates are bound to
>> >>different individuals I may provide a service to the wrong party (or
>> >>disclose confidential data, etc., etc.)  Second, I could accept a CRL to
>> >>validate a particular certificate, based on the same issuer name in the
>> >>certificate and CRL.  If the certificate and CRL were not actually issued
>> >>by the same CA, then the relying party may obtain incorrect certificate
>> >status.
>> >>
>> >>Note that both of these problems are in the context of path
>> >>validation.
>> >>If
>> >>a name collision exists, but only one of the objects (e.g., certificate or
>>
>> >>CRL) validates for a given relying party, then there is no actual
>>ambiguity
>> >
>> >>from that relying party's point of view.
>> >>
>> >>That is, assume two certificates exist with the same subject name but
>> >>are
>> >>bound to different people.  If Alice can only validate one of those
>> >>certificates, there is no ambiguity in Alice's world.   Similarly, if Bob
>> >>can only validate one of those certificates, there is no ambiguity in
>>Bob's
>> >
>> >>world.   (It does not matter if Bob and Alice are validating the same
>> >>certificate, or different ones!)   Similarly, if two CAs have the same
>> >>issuer name, but Alice can only validate one, she can't accept the
>> >>wrong
>> >>CRL.  Ditto for Bob.
>> >>
>> >>So, ambiguity is a concern only in the context of path validation for
>> >>a given relying party. This means that the mechanisms that are
>> >>employed in path validation are relevant to when names are, and are
>> >>not, ambiguous. I'd
>> >
>> >>also like to point out that path validation is always performed in the
>> >>context of a particular trust anchor.  (A relying party may accept paths
>> >>that begin with multiple trust anchors, but each specific path has a
>>single
>> >
>> >>trust anchor.)  Seems irrelevant at the moment, but I will get back to
>> >>it!
>> >>
>> >>Definition 1:  a Name N is unambiguous for a trust anchor T if and
>> >>only
>> >>if
>> >>all certificates that validate for T and have the subject N refer to the
>> >>same entity.
>> >>
>> >>Now, let's think about where name collisions can occur in the first
>> >>place.
>> >>There seems to be consensus that a single CA will not issue two
>> >>certificates to two different entities with the same subject name.  So, if
>>
>> >>a single CA issues two certificates to "O=Microsoft, cn=John Wilson" they
>> >>better relate to the same guy.  Similarly if a particular CA issues two
>> >>certificates to "c=US, O=U.S. Government, OU=NIST, CN=CA1" then the
>>subject
>> >
>> >>of both certificates must be the same CA.
>> >>
>> >>So, we are only worried about the case where two different CAs are
>> >>trusted
>> >>with respect to a trust anchor T and issue certificates to different
>> >>subjects but use the same name.  So, when can name collisions occur
>>between
>> >
>> >>CAs?  Or, better yet, under what conditions can we be sure name
>> >>collisions
>> >>won't occur?  Let's start with user certificates.
>> >>
>> >>In general, each CA that issues user certificates does so for a
>> >>particular
>> >>name space.  That is, all names assigned to users will be in a particular
>> >>Directory Information Tree (DIT).   The CA will either work with a naming
>> >>authority that it considers authoritative or may assume that function
>> >>itself.   For example, the NIST CA only issues user certificates in the
>> >>"C=US, O=U.S. Government, OU=NIST" DIT.   The NIST CA has been designated
>> >>as our naming authority as well, so it keeps track of the names it
>> >>assigns.  Similarly, the CA that supports NASA only issues certificates
>>for
>> >
>> >>the name space "C=US,  O=U.S. Government, OU=NASA" DIT.
>> >>
>> >>These name spaces are disjoint, so name collisions cannot occur
>> >>involving
>> >>user certificates generated by the NASA and NIST CAs.  In fact, consider a
>>
>> >>PKI with trust anchor T and CAs C(1), C(2), ., C(n) issuing for name
>>spaces
>> >
>> >>P(1), P(2), ., P(n).  If spaces P(1), P(2), ., P(n) are pairwise
>> >>disjoint,
>> >>name collisions cannot occur involving user certificates generated by
>>C(1),
>> >
>> >>C(2), ., C(n).
>> >>
>> >>Case 1:  Consider a PKI with trust anchor T, and CAs C1, C2, and C3.
>> >>C1,
>> >>C2, and C3 issue end user certificates in the DITs N1, N2, and N3
>> >>respectively.  If N1, N2, and N3 are pairwise disjoint, then the user
>>names
>> >
>> >>are unambiguous with respect to T.
>> >>
>> >>In more complex PKIs, we may encounter situations where CAs issue user
>> >>certificates for name spaces that overlap.  For example, in the U.S
>> >>DoD's hierarchical PKI, CAs all issue certificates in the DIT "C=US,
>> >>O=U.S. Government, OU=DOD".  Users routinely receive three
>> >>certificates from two different CAs, so all the DoD CAs rely on a
>> >>common naming authority to ensure that certificates with the same DNs
>> >>are issued to the same person.
>> >>
>> >>Case 2: Consider a PKI with trust anchor T, and CAs C1, C2, and C3.
>> >>C1,
>> >>C2, and C3 issue end user certificates in the DITs N1, N2, and N3
>> >>respectively.  N1 and N2 overlap, but N3 is disjoint from N1 and N2.   If
>> >>CA1 and CA2 recognize the same naming authority, then the user names in
>>the
>> >
>> >>PKI are unambiguous with respect to T.
>> >>
>> >>That is, if all the CAs either: (1) issue certificates in disjoint
>> >>name spaces, or (2) issue certificates in shared name spaces based on
>> >>a common naming authority, names will be unambiguous!
>> >>
>> >>Of course, CAs may issue CA certificates as well.  In this case, the
>> >>CA does not assign the names, but rather uses the established name.
>> >>This is trickier, since the name spaces for CA certificates overlaps
>> >>but no naming authority exists.  It is still the responsibility of
>> >>each CA to ensure that
>> >
>> >>there are no name collisions in CA certificates it issues!  This is
>> >>not
>> >>generally a problem, since we require names to be meaningful.  A CA should
>>
>> >>never issue a certificate to a CA with the DN "C=US, O=Coca Cola" unless
>> >>the subject CA is associated with that company.  Similarly, if a CA issues
>>
>> >>certificates in the DIT "C=US, O=Coca Cola" then it must be associated
>>with
>> >
>> >>the company!
>> >>
>> >>Of course, a rogue CA may masquerade under the wrong name, or issue
>> >>certificates in a DIT it clearly has no right to use, but no decent CA
>> >>will
>> >
>> >>cross certify with it.  Since we are interested in ambiguity with
>> >>respect
>> >>to a trust anchor, the behavior of a rogue CA is irrelevant.  Without
>>cross
>> >
>> >>certification, no paths involving the rogue CA can be constructed.
>> >>(Note
>> >>that users installing the rogue as a trust anchor is out of scope here!)
>> >>
>> >>However, authority for a name space is not always crystal clear.
>> >>Without a
>> >>central naming authority, there is no clear title for a particular DIT.
>>We
>> >
>> >>rely on heuristics that work nicely for large entities like Coca-Cola
>> >>but
>> >>may fail for smaller organizations.  For example, there may be a number of
>>
>> >>companies with variants on a particular name.  If the name space assumed
>>by
>> >
>> >>an organization asserts "Orion" rather than "Orion Security" or "Orion
>> >>Space Sciences", the name may be ambiguous without being blatantly
>> >>false.  Each entity could reasonably assign user names in the "C=US,
>> >>O=Orion" DIT.   If each organization established their CA with the name
>> >>"C=US, O=Orion, CN=CA1" things could get really ugly.
>> >>
>> >>A trust anchor T may cross certify with two different CAs - say the
>> >>ones
>> >>from NIST and NASA.  Each of those CAs may have a relationship with an
>> >>"Orion".  If each of them cross certifies with the Orion they know and
>> >>love, we have an immediate name collision for a CA named "C=US, O=Orion,
>> >>CN=CA1", and potentially name collisions for "C=US, O=Orion, CN=John
>> >>Wilson", etc., etc.  Each CA has played by the rules, but names have just
>> >>become ambiguous with respect to T.  This might be avoided if T is
>>involved
>> >
>> >>in the policy decisions leading up to cross certification - but that
>> >>is
>> >>often NOT the case.
>> >>
>> >>Fortunately, we need not depend on policy alone.   Beyond the
>> >>procedural/policy issues, there are some important mechanisms that
>> >>help
>> >>us
>> >>with name space control.  Most significant are path length constraints and
>>
>> >>name constraints.  When trust anchor T issued those CA certificates, it
>> >>probably wasn't expecting to accept transitive trust from those CAs, and
>>it
>> >
>> >>certainly didn't expect to accept the NIST or NASA CA as authoritative
>> >>for
>> >>the "C=US, O=Orion" DIT.
>> >>
>> >>I listed path length constraints first because this mechanism provides
>> >>the
>> >>simplest and most widely available of our technical controls. Both NASA
>>and
>> >
>> >>NIST use a single CA, rather than a mesh or hierarchy.  If the trust
>> >>anchor
>> >
>> >>does not wish to leverage other cross certifications performed by NASA
>> >>or
>> >>NIST, it simply asserts a path length constraint of zero!  If T asserted
>> >>this constraint for at least one of the NIST or NASA CAs, then the name
>> >>"C=US, O=Orion, CN=John Wilson" is unambiguous. While this control was not
>>
>> >>designed exclusively for name space control, it does have the effect of
>> >>prevenmting subsequent CAs from introducing unexpected name spaces.
>> >>
>> >>Unfortunately, this does not solve our problem for "C=US, O=Orion,
>> >>CN=CA1".   This name remains ambiguous.  Even with a path length
>> >>constraints of zero, a relying party can validate a CRL from either
>> >>Orion CA.
>> >>
>> >>Name constraints is a more appealing technical mechanism, if less
>> >>consistently available.  T can explicitly designate the name spaces it
>> >>wishes to recognize in the cross certificate issued to NIST (or NASA).
>> >>By asserting a permitted subtree of "C=US, O=U.S. Government, OU=NIST"
>> >>with a SkipCerts of zero, certificates in the Orion name space are
>> >>immediately eliminated.  This includes the offending CA certificate,
>> >>so the "wrong" CRL
>> >
>> >>no longer validates.
>> >>
>> >>Case 3: Consider a PKI with trust anchor T, and CAs C1, C2, and C3.
>> >>C1,
>> >>C2, and C3 issue end user certificates in the DITs N1, N2, and N3
>> >respectively.
>> >>
>> >>N1 and N2 are disjoint, but  N3 overlaps with N1 or N2.  C3 does not
>> >>recognize the same naming authority as C1 or C2.   If name constraints
>> >>permitted subtrees P3 is imposed in all cross certificates issued to
>> >>C3,
>> >>where N1, N2, and P3 are pairwise disjoint, then names are unambiguous
>>with
>> >
>> >>respect to T.  (Names that could have collided are excluded from C3's
>> >>DIT.)
>> >>
>> >>Conclusion/Proposal
>> >>
>> >>Ambiguity in names is a relatively minor risk with respect to a given
>> >>trust
>> >>anchor.  Ambiguity does not occur because of the actions of a single CA;
>> >>rather it requires a combination of actions by different CAs within the
>> >>infrastructure.  If all CA certificates accurately reflect the trust
>> >>relationships between the CAs by incorporating appropriate path length and
>>
>> >>name constraints, these risks are greatly reduced if not eliminated.
>> >>
>> >>The risk of ambiguous names can be mitigated with a relatively simple
>> >>modification in 3280bis, and the addition of some security
>> >>considerations.  Most importantly, 32890bis should be modified to
>> >>ensure that certificate and CRL validation are always performed with
>> >>respect to the same trust anchor.  Security considerations should be
>> >>added to highlight the risk of issuing CA certificates without
>> >>appropriate constraints, and to caution application developers that
>> >>trust anchor information should be considered when accepting
>> >>certificates.
>> >>
>> >>The changes that I believe should be implemented are as follows:
>> >>
>> >>  (1) Modify section 6.3.3 to state that CRL validation MUST use the
>> >>same
>> >>trust anchor T specified in the corresponding certification path.
>> >>
>> >>(2) Add security considerations that indicate applications that accept
>> >>multiple trust anchors should consider the trust anchor in access
>> >>control decisions to ensure that names are unambiguous.
>> >>
>> >>(3) Add security considerations that explain the importance of
>> >>consistent
>> >>use of path length and name constraints in preventing name ambiguity.
>> >>
>> >>
>> >
>> >Regards,
>> >
>> >Denis Pinkas
>> >
>> >
>> >

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 j6QDwJiT029852; Tue, 26 Jul 2005 06: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 j6QDwJ7c029851; Tue, 26 Jul 2005 06: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 j6QDwGmv029835 for <ietf-pkix@imc.org>; Tue, 26 Jul 2005 06:58:17 -0700 (PDT) (envelope-from denis.pinkas@bull.net)
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA20160; Tue, 26 Jul 2005 16:14:08 +0200
Received: from frcls4013 ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with SMTP id 2005072615592281:253 ; Tue, 26 Jul 2005 15:59:22 +0200 
Date: Tue, 26 Jul 2005 15:59:24 +0100
From: "Denis Pinkas" <denis.pinkas@bull.net>
To: "Tim Polk" <tim.polk@nist.gov>, "ietf-pkix@imc.org" <ietf-pkix@imc.org>
Cc: "kent@bbn.com" <kent@bbn.com>
Subject: Re: Re: How ambiguous are names in actuality?
X-mailer: Foxmail 5.0 [-fr-]
Mime-Version: 1.0
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 26/07/2005 15:59:22, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 26/07/2005 15:59:25, Serialize complete at 26/07/2005 15:59:25
Message-ID: <OF83738A41.1455FABA-ONC125704A.004CD8FE@frcl.bull.fr>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by above.proper.com id j6QDwImv029846
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <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,

>When I started in this field, I was taught that security should always be 
>*commensurate with risk*.  

When I started this field, I was told that 100 % security does not exist, 
but this was not a rational for purposely building insecure algorithms or designs.

:-)

> It is always possible to add new controls, but 
>it is not always appropriate.  That is why I started with a lot of thinking 
>about the problem, and the actual level of risk faced by PKI users.

>I did not see anything in your message below that indicates that my 
>analysis of the risk is incorrect.  

We do agree that there is a risk of name collisions, but whereas you are looking 
for solutions to MITIGATE the risk, I have presented solutions to SUPPRESS the risk.

> I explained in detail why I believe 
>name ambiguity would only occur in rather unlikely niche cases.  Do you 
>disagree with my analysis, and if so why?

The risk is similar as having two (different) files on an hard disk that bear purposely 
or by accident the same name. The hard disk is equivalent to a trust anchor, 
while every file is equivalent to the name of a certificate owner.

Checks between cannot be limited to simple DN comparisons unless it is known 
which CA is trusted to issue that name. My response goes in details about this.

>In my opinion, the current mechanisms provide sufficient security to 
>address the risk.  You have proposed rather major changes to the CRL 
>validation algorithm.  

The topic of "name ambuiguity" or of "name collisions" is not strictly related 
to the CRL validation algorithm. On one aspect only it relates to it.

> I have proposed changes as well, but mainly advocate 
>using existing mechanisms as designed.  My change can also be implemented 
>through configuration (i.e., by accepting only a single trust 
>anchor.)  

The "single trust anchor" is insecure in the general case, and does not even had anything.

> Your proposal would have a significant impact on all our running 
>code; IMHO this is inappropriate unless the changes significantly reduce 
>the risks faced by PKI relying parties.

It does not simply REDUCE the risk: it SUPRESSES the risk.

>(BTW, I also agree with Steve's observation that the discussion of ACLs 
>below significantly expands the scope of 3280bis.  A separate BCP on the 
>topic would certainly be of value, but for the purposes of 3280bis we 
>should restrict this discussion to path validation.)

Well, it could also be placed in an informative annex. 
At this time, I wonder it is really a BCP (Best Current Practice).
It would rather be a BCR (Best Current Recommendation).

:-)

Denis 

>Thanks,
>
>Tim Polk
>
>At 10:13 AM 7/18/2005 +0100, Denis Pinkas wrote:
>>Tim,
>>
>>My views are quite different. You are looking for a solution to MITIGATE 
>>the risk,
>>whereas there exists a solution to SUPPRESS the risk, as it is explained 
>>below.
>>The changes you propose, like same trust anchor, do not suppress the risk.
>>
>>You mention that the problem of name collisions exists both for two leaf 
>>certificates
>>and for CRL certificates. This is correct. While the problem for CRL 
>>certificates arises
>>only *during* the path verification algorithm, this is not the case for 
>>leaf certificates.
>>
>>For a leaf certificate that has been verified to be valid, the output of 
>>the algorithm
>>is a sequence of certificates up to a given trust anchor. The major issue 
>>is what
>>to do with it, and this is NOT mentioned within RFC 3280.
>>
>>Leaf certificates may be used in two contexts:
>>
>>    a) access control or end-entity authentication,
>>    b) non repudiation.
>>
>>These two cases are different and are explored below.
>>
>>ACCESS CONTROL OR END-ENTITY AUTHENTICATION
>>
>>There are two phases when a public key certificate is used for an access 
>>control service :
>>
>>- Phase 1 : the owner of the protected object must fill-in the ACL correctly,
>>- Phase 2 : during an access, the sequence of certificates that has been 
>>validated
>>                 must be checked against the content of the ACL.
>>
>>The real issue is that nowhere in RFC 3280 it is said what the content of 
>>the ACL should be.
>>Because of this lack of information, some implementations of relying 
>>party software
>>may be subject to problems related to name collisions, while some others 
>>will not.
>>
>>There is no clear indication in RFC 3280 to tell how the owner of the 
>>protected object
>>will make sure that it is pointing to the right certificate BEFORE using 
>>that certificate
>>for access control purposes.
>>
>>The point is that the owner of the protected object SHALL enter the full 
>>certification path
>>in the ACL. If it does not have the full path, then it SHALL construct it 
>>according to
>>the validation policy that is appropriate for his application and SHOULD 
>>make sure
>>that it is not revoked. It will thus use the full certification path and 
>>may check either
>>automatically using some local rules or may check using his brain that the 
>>full certification
>>path is correct.
>>
>>Note that if the ACL would only contain the DN of the leaf certificate, 
>>then the access control
>>mechanism would be subject to name collisions,
>>
>>When the ACL contains both the DN of the leaf certificate and all the DNs 
>>from the upper CA
>>up to a trust anchor identified by its DN (i.e. the DN of the trust anchor 
>>is also taken,
>>since there may be more than one trust anchor in a given validation 
>>policy), then the
>>access control mechanism can never be subject to name collisions.
>>
>>Since a validation policy may include more than one trust anchor, it means 
>>that it
>>SHALL not be allowed to define a validation policy that uses two trust 
>>anchors with the same DN.
>>
>>This means that during phase 1, the owner of the protected object must 
>>fill-in the ACL
>>with all the DNs from the certification path, including the DN from the 
>>trust anchor
>>(of course a hash of it may be used instead) and that during phase 2, the 
>>whole certification path
>>must be used and compared with the content of the ACL.
>>
>>This solution fully *suppresses* the risk in any case.
>>
>>Of course, in some contexts, some shortcuts may be taken (e.g. when there 
>>exists a single
>>trust anchor in the validation policy) or when it may be known that name 
>>collisions
>>may never happen (e.g. because all the CAs apply a given naming policy) 
>>but this is not
>>the general case.
>>
>>The solution explained above is also much simpler than adding name constrains
>>that could be anyway defeated.
>>
>>NON REPUDIATION
>>
>>With non repudiation, only the whole sequence of DN extracted from the 
>>certification path
>>is meaningful. A DN like CN= John William does not make sense unless at 
>>the same time
>>all the upper DNs from the CAs are used or displayed. So if someone wants 
>>to know
>>without any ambiguity who a signer is, it SHALL use of the sequence of DN 
>>up to
>>a trust anchor of the signature policy.
>>
>>Since a signature policy may include more than one trust anchor, it means 
>>that it SHALL NOT
>>be allowed to define a signature policy that uses two trust anchors with 
>>the same DN.
>>
>>COLLISIONS BETWEEN CRL ISSUER NAMES
>>
>>For CRLs, I have already mentioned the additional sentence that shall be 
>>added to RFC 3280.
>>It is copied again below  :
>>
>>The full certification path that has been used to validate the target 
>>certificate MUST also be
>>used to validate the CRL issuer certificate .
>>
>>
>>REPLY TO YOUR CONCLUSIONS
>>
>>As a reply to your conclusions: using path length constrains does not 
>>solve the issue.
>>Adding other constrains does not solve the issue either. Using name 
>>constraints would
>>introduce an order of magnitude of complexity and would not be effective 
>>in the general case.
>>Using certification policies and path length constrains might help, but 
>>still do not solve
>>the problem in the general case.
>>
>>
>>Denis
>>
>>
>> >Ambiguity has recently become a hot topic on this list.  This is a really
>> >complicated issue, and I have personally had a great deal of trouble
>> >sorting out the real level of risk.  Some of the proposed changes would
>> >greatly impact current software, and these changes should only be
>> >contemplated if the risk is merits such change.
>> >
>> >So, I have spent a lot of time, off and on, thinking about ambiguity.  I
>> >can't claim to have sorted it all out, but I have convinced myself that one
>> >minor change is absolutely required, and that the current suite of
>> >mechanisms can virtually eliminate ambiguity in real PKIs.
>> >
>> >My thinking is appended to this message;  I apologize for its length, but
>> >to paraphrase Mark Twain, I simply don't have time to make this short and
>> >concise.  I have attempted to define ambiguity, characterize the ways
>> >ambiguity can enter into a PKI, and describe the set of mechanisms that
>> >mitigate this risk.
>> >
>> >Thanks,
>> >
>> >Tim Polk
>> >
>> >------------------------------------------------------------------------- 
>> -------------------------------------------------------
>> >
>> >              How ambiguous are names in actuality, and how important is it?
>> >
>> >I believe that X.509 expected assignment of unambiguous names based on a
>> >hierarchical system of naming authorities.  Whether you agree with that
>> >premise, it is safe to say that the global X.500 directory and its
>> >corresponding system of naming authorities do not exist. So, it may not be
>> >safe to assume that there are no name collisions whatsoever in all the DNs
>> >that appear in certificates and CRLs!  I am sure such collisions exist
>> >somewhere (although I havent encountered any examples).  The real question
>> >here is What security risk does this situation present, and are the
>> >current mechanisms adequate to address this risk?
>> >
>> >Lets recognize that the goal for PKIX is not to have globally unambiguous
>> >names, but to be able to obtain a trustworthy public key to establish a
>> >security service. Ambiguity in names is a problem when it causes the
>> >relying party to trust the wrong public key.
>> >
>> >There are two ways ambiguous names could cause problems.  First, I could
>> >accept public keys from two certificates as representing the same person
>> >based on the same subject name.  If these two certificates are bound to
>> >different individuals I may provide a service to the wrong party (or
>> >disclose confidential data, etc., etc.)  Second, I could accept a CRL to
>> >validate a particular certificate, based on the same issuer name in the
>> >certificate and CRL.  If the certificate and CRL were not actually issued
>> >by the same CA, then the relying party may obtain incorrect certificate 
>> status.
>> >
>> >Note that both of these problems are in the context of path validation.  If
>> >a name collision exists, but only one of the objects (e.g., certificate or
>> >CRL) validates for a given relying party, then there is no actual ambiguity
>> >from that relying partys point of view.
>> >
>> >That is, assume two certificates exist with the same subject name but are
>> >bound to different people.  If Alice can only validate one of those
>> >certificates, there is no ambiguity in Alices world.   Similarly, if Bob
>> >can only validate one of those certificates, there is no ambiguity in Bobs
>> >world.   (It does not matter if Bob and Alice are validating the same
>> >certificate, or different ones!)   Similarly, if two CAs have the same
>> >issuer name, but Alice can only validate one, she cant accept the wrong
>> >CRL.  Ditto for Bob.
>> >
>> >So, ambiguity is a concern only in the context of path validation for a
>> >given relying party. This means that the mechanisms that are employed in
>> >path validation are relevant to when names are, and are not, ambiguous. Id
>> >also like to point out that path validation is always performed in the
>> >context of a particular trust anchor.  (A relying party may accept paths
>> >that begin with multiple trust anchors, but each specific path has a single
>> >trust anchor.)  Seems irrelevant at the moment, but I will get back to it!
>> >
>> >Definition 1:  a Name N is unambiguous for a trust anchor T if and only if
>> >all certificates that validate for T and have the subject N refer to the
>> >same entity.
>> >
>> >Now, lets think about where name collisions can occur in the first place.
>> >There seems to be consensus that a single CA will not issue two
>> >certificates to two different entities with the same subject name.  So, if
>> >a single CA issues two certificates to O=Microsoft, cn=John Wilson they
>> >better relate to the same guy.  Similarly if a particular CA issues two
>> >certificates to c=US, O=U.S. Government, OU=NIST, CN=CA1 then the subject
>> >of both certificates must be the same CA.
>> >
>> >So, we are only worried about the case where two different CAs are trusted
>> >with respect to a trust anchor T and issue certificates to different
>> >subjects but use the same name.  So, when can name collisions occur between
>> >CAs?  Or, better yet, under what conditions can we be sure name collisions
>> >wont occur?  Lets start with user certificates.
>> >
>> >In general, each CA that issues user certificates does so for a particular
>> >name space.  That is, all names assigned to users will be in a particular
>> >Directory Information Tree (DIT).   The CA will either work with a naming
>> >authority that it considers authoritative or may assume that function
>> >itself.   For example, the NIST CA only issues user certificates in the
>> >C=US, O=U.S. Government, OU=NIST DIT.   The NIST CA has been designated
>> >as our naming authority as well, so it keeps track of the names it
>> >assigns.  Similarly, the CA that supports NASA only issues certificates for
>> >the name space C=US,  O=U.S. Government, OU=NASA DIT.
>> >
>> >These name spaces are disjoint, so name collisions cannot occur involving
>> >user certificates generated by the NASA and NIST CAs.  In fact, consider a
>> >PKI with trust anchor T and CAs C(1), C(2), , C(n) issuing for name spaces
>> >P(1), P(2), , P(n).  If spaces P(1), P(2), , P(n) are pairwise disjoint,
>> >name collisions cannot occur involving user certificates generated by C(1),
>> >C(2), , C(n).
>> >
>> >Case 1:  Consider a PKI with trust anchor T, and CAs C1, C2, and C3.  C1,
>> >C2, and C3 issue end user certificates in the DITs N1, N2, and N3
>> >respectively.  If N1, N2, and N3 are pairwise disjoint, then the user names
>> >are unambiguous with respect to T.
>> >
>> >In more complex PKIs, we may encounter situations where CAs issue user
>> >certificates for name spaces that overlap.  For example, in the U.S DoDs
>> >hierarchical PKI, CAs all issue certificates in the DIT C=US, O=U.S.
>> >Government, OU=DOD.  Users routinely receive three certificates from two
>> >different CAs, so all the DoD CAs rely on a common naming authority to
>> >ensure that certificates with the same DNs are issued to the same person.
>> >
>> >Case 2: Consider a PKI with trust anchor T, and CAs C1, C2, and C3.  C1,
>> >C2, and C3 issue end user certificates in the DITs N1, N2, and N3
>> >respectively.  N1 and N2 overlap, but N3 is disjoint from N1 and N2.   If
>> >CA1 and CA2 recognize the same naming authority, then the user names in the
>> >PKI are unambiguous with respect to T.
>> >
>> >That is, if all the CAs either: (1) issue certificates in disjoint name
>> >spaces, or (2) issue certificates in shared name spaces based on a common
>> >naming authority, names will be unambiguous!
>> >
>> >Of course, CAs may issue CA certificates as well.  In this case, the CA
>> >does not assign the names, but rather uses the established name.  This is
>> >trickier, since the name spaces for CA certificates overlaps but no naming
>> >authority exists.  It is still the responsibility of each CA to ensure that
>> >there are no name collisions in CA certificates it issues!  This is not
>> >generally a problem, since we require names to be meaningful.  A CA should
>> >never issue a certificate to a CA with the DN C=US, O=Coca Cola unless
>> >the subject CA is associated with that company.  Similarly, if a CA issues
>> >certificates in the DIT C=US, O=Coca Cola then it must be associated with
>> >the company!
>> >
>> >Of course, a rogue CA may masquerade under the wrong name, or issue
>> >certificates in a DIT it clearly has no right to use, but no decent CA will
>> >cross certify with it.  Since we are interested in ambiguity with respect
>> >to a trust anchor, the behavior of a rogue CA is irrelevant.  Without cross
>> >certification, no paths involving the rogue CA can be constructed.  (Note
>> >that users installing the rogue as a trust anchor is out of scope here!)
>> >
>> >However, authority for a name space is not always crystal clear.  Without a
>> >central naming authority, there is no clear title for a particular DIT.  We
>> >rely on heuristics that work nicely for large entities like Coca-Cola but
>> >may fail for smaller organizations.  For example, there may be a number of
>> >companies with variants on a particular name.  If the name space assumed by
>> >an organization asserts Orion rather than Orion Security or Orion
>> >Space Sciences, the name may be ambiguous without being blatantly
>> >false.  Each entity could reasonably assign user names in the C=US,
>> >O=Orion DIT.   If each organization established their CA with the name
>> >C=US, O=Orion, CN=CA1 things could get really ugly.
>> >
>> >A trust anchor T may cross certify with two different CAs  say the ones
>> >from NIST and NASA.  Each of those CAs may have a relationship with an
>> >Orion.  If each of them cross certifies with the Orion they know and
>> >love, we have an immediate name collision for a CA named C=US, O=Orion,
>> >CN=CA1, and potentially name collisions for C=US, O=Orion, CN=John
>> >Wilson, etc., etc.  Each CA has played by the rules, but names have just
>> >become ambiguous with respect to T.  This might be avoided if T is involved
>> >in the policy decisions leading up to cross certification  but that is
>> >often NOT the case.
>> >
>> >Fortunately, we need not depend on policy alone.   Beyond the
>> >procedural/policy issues, there are some important mechanisms that help us
>> >with name space control.  Most significant are path length constraints and
>> >name constraints.  When trust anchor T issued those CA certificates, it
>> >probably wasnt expecting to accept transitive trust from those CAs, and it
>> >certainly didnt expect to accept the NIST or NASA CA as authoritative for
>> >the C=US, O=Orion DIT.
>> >
>> >I listed path length constraints first because this mechanism provides the
>> >simplest and most widely available of our technical controls. Both NASA and
>> >NIST use a single CA, rather than a mesh or hierarchy.  If the trust anchor
>> >does not wish to leverage other cross certifications performed by NASA or
>> >NIST, it simply asserts a path length constraint of zero!  If T asserted
>> >this constraint for at least one of the NIST or NASA CAs, then the name
>> >C=US, O=Orion, CN=John Wilson is unambiguous. While this control was not
>> >designed exclusively for name space control, it does have the effect of
>> >prevenmting subsequent CAs from introducing unexpected name spaces.
>> >
>> >Unfortunately, this does not solve our problem for C=US, O=Orion,
>> >CN=CA1.   This name remains ambiguous.  Even with a path length
>> >constraints of zero, a relying party can validate a CRL from either 
>> Orion CA.
>> >
>> >Name constraints is a more appealing technical mechanism, if less
>> >consistently available.  T can explicitly designate the name spaces it
>> >wishes to recognize in the cross certificate issued to NIST (or NASA).  By
>> >asserting a permitted subtree of C=US, O=U.S. Government, OU=NIST with a
>> >SkipCerts of zero, certificates in the Orion name space are immediately
>> >eliminated.  This includes the offending CA certificate, so the wrong CRL
>> >no longer validates.
>> >
>> >Case 3: Consider a PKI with trust anchor T, and CAs C1, C2, and C3.  C1,
>> >C2, and C3 issue end user certificates in the DITs N1, N2, and N3 
>> respectively.
>> >
>> >N1 and N2 are disjoint, but  N3 overlaps with N1 or N2.  C3 does not
>> >recognize the same naming authority as C1 or C2.   If name constraints
>> >permitted subtrees P3 is imposed in all cross certificates issued to C3,
>> >where N1, N2, and P3 are pairwise disjoint, then names are unambiguous with
>> >respect to T.  (Names that could have collided are excluded from C3s DIT.)
>> >
>> >Conclusion/Proposal
>> >
>> >Ambiguity in names is a relatively minor risk with respect to a given trust
>> >anchor.  Ambiguity does not occur because of the actions of a single CA;
>> >rather it requires a combination of actions by different CAs within the
>> >infrastructure.  If all CA certificates accurately reflect the trust
>> >relationships between the CAs by incorporating appropriate path length and
>> >name constraints, these risks are greatly reduced if not eliminated.
>> >
>> >The risk of ambiguous names can be mitigated with a relatively simple
>> >modification in 3280bis, and the addition of some security
>> >considerations.  Most importantly, 32890bis should be modified to ensure
>> >that certificate and CRL validation are always performed with respect to
>> >the same trust anchor.  Security considerations should be added to
>> >highlight the risk of issuing CA certificates without appropriate
>> >constraints, and to caution application developers that trust anchor
>> >information should be considered when accepting certificates.
>> >
>> >The changes that I believe should be implemented are as follows:
>> >
>> >  (1) Modify section 6.3.3 to state that CRL validation MUST use the same
>> >trust anchor T specified in the corresponding certification path.
>> >
>> >(2) Add security considerations that indicate applications that accept
>> >multiple trust anchors should consider the trust anchor in access control
>> >decisions to ensure that names are unambiguous.
>> >
>> >(3) Add security considerations that explain the importance of consistent
>> >use of path length and name constraints in preventing name ambiguity.
>> >
>> >
>>
>>Regards,
>>
>>Denis Pinkas

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 j6Q1rY7C001025; Mon, 25 Jul 2005 18:53: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 j6Q1rY5P001024; Mon, 25 Jul 2005 18:53:34 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from mailbo.ntcif.telstra.com.au (mailbo.ntcif.telstra.com.au [202.12.233.19]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6Q1rWjT001014 for <ietf-pkix@imc.org>; Mon, 25 Jul 2005 18:53:33 -0700 (PDT) (envelope-from James.H.Manger@team.telstra.com)
Received: from mailai.ntcif.telstra.com.au (mailai.ntcif.telstra.com.au [202.12.162.17]) by mailbo.ntcif.telstra.com.au (Postfix) with ESMTP id 4569A142CE for <ietf-pkix@imc.org>; Tue, 26 Jul 2005 11:53:31 +1000 (EST)
Received: from mail.cdn.telstra.com.au (localhost [127.0.0.1]) by mailai.ntcif.telstra.com.au (Postfix) with ESMTP id 9FDB1FF83 for <ietf-pkix@imc.org>; Tue, 26 Jul 2005 11:53:30 +1000 (EST)
Received: from wsmsg2902.srv.dir.telstra.com (wsmsg2902.srv.dir.telstra.com [172.49.40.51]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id LAA17133 for <ietf-pkix@imc.org>; Tue, 26 Jul 2005 11:53:29 +1000 (EST)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Subject: RE: IDP indirectCRL flag
Date: Tue, 26 Jul 2005 11:49:26 +1000
Message-ID: <73388857A695D31197EF00508B08F298178E312D@ntmsg0131.corpmail.telstra.com.au>
Thread-Topic: IDP indirectCRL flag
Thread-Index: AcWRHDXbIvNZU8mZRdeAL8Vtg/jqzAAZw5PQ
From: "Manger, James H" <James.H.Manger@team.telstra.com>
To: "pkix" <ietf-pkix@imc.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by above.proper.com id j6Q1rXjT001019
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

> Can you explain me why we would want to change the standard
> and impose these additional constraints for indirect CRL?

I don't want to.
I was trying to point out to Denis that even if his rules worked under one assumption ("CRL for 1 CA"), there was no way to tell if that assumption held in any instance.  Consequently, you must not make that assumption so you must not use Denis's rules.

-----Original Message-----
From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] 
Sent: Monday, 25 July 2005 10:09 PM
To: 'pkix'
Subject: RE: IDP indirectCRL flag

James Manger and Denis,

Can you explain me why we would want to change the standard and impose these
additional constraints for indirect CRL?

-----Original Message-----
From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On
Behalf Of Manger, James H
Sent: Sunday, July 24, 2005 9:43 PM
To: pkix
Subject: RE: IDP indirectCRL flag

Denis,

Perhaps your rules could work if a CRL issuer is not itself a CA and it only
handles certificates from a single CA.  However, a relying party cannot know
(and must not assume) that this is the case for the CRL issuer.

A certificate with a CRL-DP.cRLIssuer field tells the RP that the named CRL
issuer handles certificates from at least the issuer of this certificate.
It gives no information about how many other CAs (if any) the CRL issuer may
also handle, nor whether the CRL issuer is also a CA itself.  A
CRL-DP.cRLIssuer field tells the RP that some CRLs from the named CRL issuer
should cover this certificate, but it does not tell the RP that all CRLs do.

P.S. A CRL issuer may as well use the same name as the CA if it is only ever
going to issue revocation info for that CA's certificates.  That is, the CA
delegates CRL issuance to a separate key, not to a separate name.  This
avoids CRL-DP.cRLIssuer, IDP.indirectCRL & CRL-ENTRY.certificateIssuer
fields completely.

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 j6PDdhpd016127; Mon, 25 Jul 2005 06:39: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 j6PDdhEe016126; Mon, 25 Jul 2005 06:39:43 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from SMTP.Lamicro.com (66-163-8-251.ip.tor.radiant.net [66.163.8.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6PDdfOZ016107 for <ietf-pkix@imc.org>; Mon, 25 Jul 2005 06:39:42 -0700 (PDT) (envelope-from thierry.moreau@connotech.com)
Received: from Spooler by SMTP.Lamicro.com (Mercury/32 v4.01b) ID MO00A4A3; 25 Jul 2005 09:41:23 -0400
Received: from spooler by Lamicro.com (Mercury/32 v4.01b); 25 Jul 2005 09:41:16 -0400
Received: from connotech.com (209.71.204.122) by SMTP.Lamicro.com (Mercury/32 v4.01b) with ESMTP ID MG00A4A1; 25 Jul 2005 09:41:05 -0400
Message-ID: <42E4F2AA.8060409@connotech.com>
Date: Mon, 25 Jul 2005 10:09:46 -0400
From: Thierry Moreau <thierry.moreau@connotech.com>
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.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: A non-critical self-signed certificate extension for trust anchr renewal ...
References: <42D6F608.7000704@connotech.com> <p0623090dbf06f69a3e36@[128.89.89.106]>
In-Reply-To: <p0623090dbf06f69a3e36@[128.89.89.106]>
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>

Dear Stephen:

Thanks for your comments on draft-moreau-pkix-takrem-00.txt. Your points 
are well-taken. See in-line below.

I expect to work on a -01 draft after the Paris meeting, once the -00 is 
accepted as an Internet draft (there is a ban period for -00 draft 
acceptance before and during a meeting).

Stephen Kent wrote:

> 
> Thierry,
> 
> A few of comments on your I-D:
> 
>     - the notion of including the hash of the next public key to be used 
> by a CA (TA) as an extension in a cert is an old one, developed by the 
> SET folks. I believe they have a patent on the technique. While they 
> used a simple one-way hash for this purpose, use of a MASH and the salt 
> may not be enough of a difference to not be covered by the patent.
> 
Thanks for this indication of a possible significant prior art document. 
Do you have any further pointers that can assist my search for an exact 
reference.

>     - you allow for the hash to be of the next cert, not just the next 
> public key. Although the text does not seem to say so explicitly, I 
> assume this feature makes sense only for scheduled rollover, where the 
> complete cert contents, including the validity interval, can be computed 
> in advance.
> 
Yes, with qualification. Yes, it makes sense for "scheduled rollover, 
where the complete cert contents, including the validity interval, can 
be computed in advance" -- this should be more clearly stated in the 
draft. The qualification is the following ones 1) the initial 
certificates are optional, and 2) the can optionally be superseded in 
the renewal message.

>     - some discussion of when it is appropriate to include a sequence of 
> future key/cert hash values in an initial cert is needed. it would seem 
> sufficient to do this one key/cert at a time in general, allowing later 
> keys to be generated in the future, adn thus not ave to be stored 
> security for long periods.
> 
Security-wise, the chaining that you suggest implies long-term security 
(i.e. the chain is no stronger than its weakest link). For sake of 
simplicity, I thought the extension usage limited to root keys (i.e. not 
for public keys that are routinely certified) and to root key 
distribution thay relies on out-of-band integrity assurance (i.e. 
initial distribution). This is subject to discussion.

>     - the lack of a syntax for the renewal message is a worrisome 
> omission. it's OK to defer to another document the means of transporting 
> the message, but the syntax for the message should probably be defined 
> here.
> 
Point well taken. I intended to include a sample syntax in the -00 
revision, but at last I was not sure the details were polished enough 
for submission.

>     - section 4.1 is a bit confusing and needs to be reworded, and 4.2 
> has some exposition problems as well. if one MAY rely on the digest 
> values in the extension beyond the expiration date of the cert, then you 
> need to explain why this is a reasonable behavior and under what 
> circumstances it is likely to be necessary.
> 
I'm referring to the expiration of the initial security certificate. The 
digests of future keys are intended to be used after expiry of this 
first certificate. It is reasonable because the digest cryptography 
(i.e. an unknown hash function instance and this hash function itself) 
is stronger than the initial public key cryptography. Also, the relying 
system configuration continued integrity is somehow independent on the 
reasonableness of the behavior. The behavior is necessary for renewal of 
  trust anchor keys.

>     - there are numerous odd textual conventions in the document, e.g., 
> double square brackets (i.e., "[[") when the phrase "issuer of an 
> initial self-signed certificate" appears.
> 
Indeed.

>     - the security considerations  section is a mix of appropriate 
> guidance relevant to this extension, and extraneous guidance not 
> specvific to this context.
> 
I should try to remove the extraneous guidance.

> 
> Steve
> 
> 

Regards,

-- 

- Thierry Moreau

CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, Qc
Canada   H2M 2A1

Tel.: (514)385-5691
Fax:  (514)385-5900

web site: http://www.connotech.com
e-mail: thierry.moreau@connotech.com

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 j6PDSJpY011026; Mon, 25 Jul 2005 06:28: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 j6PDSJHZ011025; Mon, 25 Jul 2005 06:28:19 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from sottmxsecs3.entrust.com (sottmxsecs3.entrust.com [216.191.252.14]) by above.proper.com (8.12.11/8.12.9) with SMTP id j6PDSHwW010981 for <ietf-pkix@imc.org>; Mon, 25 Jul 2005 06:28:18 -0700 (PDT) (envelope-from sharon.boeyen@entrust.com)
Received: (qmail 2530 invoked from network); 25 Jul 2005 13:28:06 -0000
Received: from sharon.boeyen@entrust.com by sottmxsecs3.entrust.com with EntrustECS-Server-7.3.1;25 Jul 2005 13:28:06 -0000
Received: from sottmxs00.entrust.com (10.4.61.22) by sottmxsecs3.entrust.com with SMTP; 25 Jul 2005 13:28:05 -0000
Received: by sottmxs00.entrust.com with Internet Mail Service (5.5.2657.72) id <PHK77DJY>; Mon, 25 Jul 2005 09:28:06 -0400
Message-ID: <7A3E1242FA9989439AD1F9B2D71C287F03A0345C@sottmxs05.entrust.com>
From: Sharon Boeyen <sharon.boeyen@entrust.com>
To: "'Santosh Chokhani'" <chokhani@orionsec.com>, "'pkix'" <ietf-pkix@imc.org>
Subject: RE: RE: Re: Correction to be done to <draft-pinkas-pkix-conf-crl- validation-01.txt>
Date: Mon, 25 Jul 2005 09:27:58 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5911C.5742821A"
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <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_01C5911C.5742821A
Content-Type: text/plain

Santosh, I agree with you. I would also like to restate that 3280 is a
profile of X.509. Denis is proposing changes that would cause a huge
divergence and that can only be bad for the industry. An indirect CRL is one
that is issued by some entity other than that which issued the certificate.
The CRL must be tagged as such and the RP must have a way to know they have
the right revocation status info for the certificate in question. X.509 and
RFC 3280 both cover this just fine in my opinion. 

Cheers,
Sharon

-----Original Message-----
From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On
Behalf Of Santosh Chokhani
Sent: Friday, July 22, 2005 5:58 PM
To: 'pkix'
Subject: RE: RE: Re: Correction to be done to
<draft-pinkas-pkix-conf-crl-validation-01.txt>

Denis,

X.509 and 3280 are clear and do not need all these cases your e-mail
contains.  An indirect CRL bit must be asserted if a CRL is supposed to
cover certificates issued by one or more CAs other than the CRL Issuer.

-----Original Message-----
From: Denis Pinkas [mailto:denis.pinkas@bull.net] 
Sent: Friday, July 22, 2005 11:38 AM
To: Sharon Boeyen; David A. Cooper; Santosh Chokhani
Cc: 'pkix'
Subject: Re: RE: Re: Correction to be done to
<draft-pinkas-pkix-conf-crl-validation-01.txt>

>Denis, I'm sorry but I really am not following your thought processes
>at all.

Sharon,

First, I appreciate the time you spent digging into the past. 

Please forget about the vocabulary for a while, otherwise 
you will not follow my "thought process" that I will try to explain..

If you take the case of a simple scheme where a CRL Issuer accepts 
to issue revocation status information from only one CA, then from 
a RP point of view the certificate issuer CRL entry extension is not 
needed. By implication the indirect CRL boolean that signals the 
presence of that extension is not needed either. 

Now, we can come back to the vocabulary issue:  since the indirectCRL 
boolean is not needed, I would not call that kind of CRL an indirect CRL.

Using the rules that I have described in
<draft-pinkas-pkix-conf-crl-validation-02.txt>, 
in sections 6.3.3.1 and 6.3.3.2, I believe it is possible to securely
support that 
simple scheme, ... unless I made an error in them, but until now nobody as
yet 
demonstrated a case where these rules, *from a RP point of view*, would be
insufficient.

So why make things complicated, when they can be simple ?

>X.509 does include a definition for indirect CRLs. RFC 3280 is a
>profile of X.509 not a replacement for it. Therefore there is no need 
>to redefine terms in 3280 that are defined in 509. There is no harm in 
>clarifying terms in 3280 if the group so chooses but a profile should 
>not alter the intent of a definition.
>
>I take your point that the 509 definition says "authorities" instead of
>"authority or authorities". I have taken the time (a lot of it!!!) to 
>dig through my files to track the history of that definition as I was 
>the editor of X.509 at the time it was added. (Sometimes I am happy 
>that I'm such a packrat).
>
>The definition that has been quoted by David from X.509 was added as an
>outcome of the April 1999 meeting in Orlando Florida. It was part of 
>the resolution of Canadian comment number 24 submitted to that meeting 
>against the X.509 PDAM. The relevant part of the disposition of that 
>comment was recorded as "Accepted with a few minor modifications to the 
>proposed text. Also a definition for indirect CRL will be added." I was 
>the author of the Canadian comment submitted to that meeting and I was 
>also the editor that created the definition that is now in X.509 as a 
>result of that comment disposition. Let me assure you that with both 
>hats on it WAS my intention that any CRL that included revocation 
>notices for certificates that were issued by any authority other than 
>that which issued the CRL is an indirect CRL.

On my side, my understanding was as I explained. Only when the CRL covers 
certificates from more than one CA, are both the certificate issuer CRL
entry extension 
needed and the indirectCRL boolean needed. In RFC 3280 the requirements for 
these two fields are in two consecutive sentences within the same short
paragraph 
so why I believe(d) they come together.

I hope that this allows at least you to understand my thought process, even
if 
you have a different opinion.

Denis

> I will be happy to submit a defect report to X.509 to change
>"authorities" to "authority or authorities". As the editor and the 
>submitter of the ballot comment that drove the discussion to add the 
>definition in the first place I will happily admit I made an error in 
>using the term "authorities" in that definition.
>
>Cheers,
>Sharon
>
>-----Original Message-----
>From: owner-ietf-pkix@mail.imc.org
>[mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Denis Pinkas
>Sent: Thursday, July 21, 2005 10:34 AM
>To: David A. Cooper; Santosh Chokhani
>Cc: 'pkix'
>Subject: Re: Re: Correction to be done to 
><draft-pinkas-pkix-conf-crl-validation-01.txt>
>
>
>
>David,
>
>>Santosh Chokhani wrote:
>>
>>>Denis,
>>>
>>>A sentence in 3280 may be ambiguous. The definition and State
>>>Machines
>>>are not at odds. Also, if you point to the specific location of the 
>>>sentence in 3280, I will be happy to determine if this is being taken 
>>>out of context or not.
>
>>Santosh,
>
>>Denis is referring to the final sentence in the following paragraph:
>
>>      CRL issuers issue CRLs.  The CRL issuer is either the CA or an
entity
>>      that has been authorized by the CA to issue CRLS.  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.
>
>>I believe the problem is that Denis is interpreting this sentence as a
>>definition when it is not one.  Here is the definition of indirect CRL 
>>in X.509:
>
>You mean that RFC 3280 contains no formal definition of what an 
>Indirect CRL is.
>
>A good practice for RFCs would be to follow ISO editing rules where 
>there MUST be a separate section for formal definitions.  :-)
>
>However the extracted sentence is the earliest use of the wording
>"indirect CRL" in the document saying what an indirect CRL is. It is 
>not explained later on.
>
>The definition from X.509 you mention is thus not an RFC 3280
>definition.
>
>>      indirect CRL (iCRL):  A revocation list that at least contains
>>revocation information
>>      about certificates issued by authorities other than that which
>>issued this CRL.
>
>The X.509 definition is NOT :
>
>indirect CRL (iCRL):  A revocation list that at least contains
>revocation information about certificates issued by *an authority* 
>other than that which issued this CRL.
>
>The X.509 definition is NOT either:
>
>indirect CRL (iCRL):  A revocation list that at least contains
>revocation information about certificates issued by *one or more* 
>authorities other than that which issued
>this CRL.
>  
>>In order to help avoid this confusion in 3280bis, I have removed the
>>sentence "Whenever ...." from 3280bis draft -01 and have added the 
>>following paragraph:
>>
>>      If the scope of the CRL includes one or more certificates issued by
>>      an entity other than the CRL issuer, then it is an indirect CRL.
>
>Arhh!  Once again: "certificates issued by .. CRL issuer".
>
>>      The
>>      scope of an indirect CRL may be limited to certificates issued by a
>>      single CA or may include certificates issued by multiple CAs.
>
>This would have been true if the X.509 definition had been written
>differently.
>
>>      If the
>>      issuer of the indirect CRL is a CA, then the scope of the indirect
>>      CRL MAY include certificates issued by the issuer of the CRL.
>
>This is ruled out by the current quoted sentence.
>
>>I believe that this text is fully consistent with the X.509 definition
>>of indirect CRL
>
>Sorry, it is not.
>
>> as well as the descriptions of the indirectCRL flag and
>>the certificateIssuer CRL entry extension in both X.509 and RFC 3280
>>and
>>the algorithm in section 6.3.3 of RFC 3280.
>
>Page 59 is stating:
>
>   "The CRL issuer MUST assert the indirectCRL boolean, if the scope of
>   the CRL includes certificates issued by authorities other than the
>   CRL issuer.  The authority responsible for each entry is indicated by
>   the certificate issuer CRL entry extension (section 5.3.4)".
>
>It is clear that this flag is present when there are certificate issuer
>CRL entry extensions.
>
>Thus, in the simplest case, where a CA designates another entity to
>issue revocation status information for some of its certificates, the 
>certificate issuer CRL entry extension
>is not needed, neither the indirectCRL boolean.
>
>The way to fix the problem is simple: either adopt (but add "may") the
>definition of X.509 or make it clearer by saying:
>
>indirect CRL (iCRL):  A revocation list that at least *may* contain
>revocation information about certificates issued by more than one CA.
>
>and add for clarification:
>
>delegatedCRL (dCRL):  A revocation list issued by a CRL Issuer that
>received and accepted a delegation for issuing revocation status 
>information from a single CA, that contains
>revocation information about certificates issued by that single CA.
>
>See processing details for these two cases in
><draft-pinkas-pkix-conf-crl-validation-02.txt>
>that is now available.
>
>The benefits are:
>
> 1) a very simple CRL processing when the CRL contains revocation
>information
>    about certificates from a single CA.
>
> 2) a (much) more complex CRL processing when the CRL contains revocation 
>    information about certificates from more than one CA, including the
>(seldom ?)
>    case where the CRL issuer is also a CA.
>
>Denis
>
>>Dave

------_=_NextPart_001_01C5911C.5742821A
Content-Type: text/html
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=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2658.2">
<TITLE>RE: RE: Re: Correction to be done to =
&lt;draft-pinkas-pkix-conf-crl-validation-01.txt&gt;</TITLE>
</HEAD>
<BODY>

Santosh, I agree with you. I would also like to =
restate that 3280 is a profile of X.509. Denis is proposing changes =
that would cause a huge divergence and that can only be bad for the =
industry. An indirect CRL is one that is issued by some entity other =
than that which issued the certificate. The CRL must be tagged as such =
and the RP must have a way to know they have the right revocation =
status info for the certificate in question. X.509 and RFC 3280 both =
cover this just fine in my opinion.

<P><FONT SIZE=3D2>Cheers,</FONT>
<BR><FONT SIZE=3D2>Sharon</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: owner-ietf-pkix@mail.imc.org [<A =
HREF=3D"mailto:owner-ietf-pkix@mail.imc.org">mailto:owner-ietf-pkix@mail=
.imc.org</A>] On Behalf Of Santosh Chokhani</FONT>
<BR><FONT SIZE=3D2>Sent: Friday, July 22, 2005 5:58 PM</FONT>
<BR><FONT SIZE=3D2>To: 'pkix'</FONT>
<BR><FONT SIZE=3D2>Subject: RE: RE: Re: Correction to be done to =
&lt;draft-pinkas-pkix-conf-crl-validation-01.txt&gt;</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>Denis,</FONT>
</P>

<P><FONT SIZE=3D2>X.509 and 3280 are clear and do not need all these =
cases your e-mail contains.&nbsp; An indirect CRL bit must be asserted =
if a CRL is supposed to cover certificates issued by one or more CAs =
other than the CRL Issuer.</FONT></P>

-----Original Message-----
 From: Denis Pinkas [<A =
HREF=3D"mailto:denis.pinkas@bull.net">mailto:denis.pinkas@bull.net</A>] =

 Sent: Friday, July 22, 2005 11:38 AM
 To: Sharon Boeyen; David A. Cooper; Santosh =
Chokhani
 Cc: 'pkix'
 Subject: Re: RE: Re: Correction to be done to =
&lt;draft-pinkas-pkix-conf-crl-validation-01.txt&gt;

<P><FONT SIZE=3D2>&gt;Denis, I'm sorry but I really am not following =
your thought processes</FONT>
<BR><FONT SIZE=3D2>&gt;at all.</FONT>
</P>

<P><FONT SIZE=3D2>Sharon,</FONT>
</P>

First, I appreciate the time you spent digging into =
the past.

<P><FONT SIZE=3D2>Please forget about the vocabulary for a while, =
otherwise </FONT>
<BR><FONT SIZE=3D2>you will not follow my &quot;thought process&quot; =
that I will try to explain..</FONT>
</P>

If you take the case of a simple scheme where a CRL =
Issuer accepts 
 to issue revocation status information from only one =
CA, then from 
 a RP point of view the certificate issuer CRL entry =
extension is not 
 needed. By implication the indirect CRL boolean that =
signals the 
 presence of that extension is not needed either. =

<P><FONT SIZE=3D2>Now, we can come back to the vocabulary issue:&nbsp; =
since the indirectCRL </FONT>
<BR><FONT SIZE=3D2>boolean is not needed, I would not call that kind of =
CRL an indirect CRL.</FONT>
</P>

Using the rules that I have described in =
&lt;draft-pinkas-pkix-conf-crl-validation-02.txt&gt;, 
 in sections 6.3.3.1 and 6.3.3.2, I believe it is =
possible to securely support that 
 simple scheme, ... unless I made an error in them, =
but until now nobody as yet 
 demonstrated a case where these rules, *from a RP =
point of view*, would be insufficient.

<P><FONT SIZE=3D2>So why make things complicated, when they can be =
simple ?</FONT>
</P>

&gt;X.509 does include a definition for indirect =
CRLs. RFC 3280 is a
 &gt;profile of X.509 not a replacement for it. =
Therefore there is no need 
 &gt;to redefine terms in 3280 that are defined in =
509. There is no harm in 
 &gt;clarifying terms in 3280 if the group so chooses =
but a profile should 
 &gt;not alter the intent of a definition.
 &gt;
 &gt;I take your point that the 509 definition says =
&quot;authorities&quot; instead of
 &gt;&quot;authority or authorities&quot;. I have =
taken the time (a lot of it!!!) to 
 &gt;dig through my files to track the history of =
that definition as I was 
 &gt;the editor of X.509 at the time it was added. =
(Sometimes I am happy 
 &gt;that I'm such a packrat).
 &gt;
 &gt;The definition that has been quoted by David =
from X.509 was added as an
 &gt;outcome of the April 1999 meeting in Orlando =
Florida. It was part of 
 &gt;the resolution of Canadian comment number 24 =
submitted to that meeting 
 &gt;against the X.509 PDAM. The relevant part of the =
disposition of that 
 &gt;comment was recorded as &quot;Accepted with a =
few minor modifications to the 
 &gt;proposed text. Also a definition for indirect =
CRL will be added.&quot; I was 
 &gt;the author of the Canadian comment submitted to =
that meeting and I was 
 &gt;also the editor that created the definition that =
is now in X.509 as a 
 &gt;result of that comment disposition. Let me =
assure you that with both 
 &gt;hats on it WAS my intention that any CRL that =
included revocation 
 &gt;notices for certificates that were issued by any =
authority other than 
 &gt;that which issued the CRL is an indirect =
CRL.

On my side, my understanding was as I explained. Only =
when the CRL covers 
 certificates from more than one CA, are both the =
certificate issuer CRL entry extension 
 needed and the indirectCRL boolean needed. In RFC =
3280 the requirements for 
 these two fields are in two consecutive sentences =
within the same short paragraph 
 so why I believe(d) they come together.

<P><FONT SIZE=3D2>I hope that this allows at least you to understand my =
thought process, even if </FONT>
<BR><FONT SIZE=3D2>you have a different opinion.</FONT>
</P>

<P><FONT SIZE=3D2>Denis</FONT>
</P>

&gt; I will be happy to submit a defect report to =
X.509 to change
 &gt;&quot;authorities&quot; to &quot;authority or =
authorities&quot;. As the editor and the 
 &gt;submitter of the ballot comment that drove the =
discussion to add the 
 &gt;definition in the first place I will happily =
admit I made an error in 
 &gt;using the term &quot;authorities&quot; in that =
definition.
 &gt;
 &gt;Cheers,
 &gt;Sharon
 &gt;
 &gt;-----Original Message-----
 &gt;From: owner-ietf-pkix@mail.imc.org
 &gt;[<A =
HREF=3D"mailto:owner-ietf-pkix@mail.imc.org">mailto:owner-ietf-pkix@mail=
.imc.org</A>] On Behalf Of Denis Pinkas
 &gt;Sent: Thursday, July 21, 2005 10:34 AM
 &gt;To: David A. Cooper; Santosh Chokhani
 &gt;Cc: 'pkix'
 &gt;Subject: Re: Re: Correction to be done to =

 &gt;&lt;draft-pinkas-pkix-conf-crl-validation-01.txt&gt;=

&gt;
 &gt;
 &gt;
 &gt;David,
 &gt;
 &gt;&gt;Santosh Chokhani wrote:
 &gt;&gt;
 &gt;&gt;&gt;Denis,
 &gt;&gt;&gt;
 &gt;&gt;&gt;A sentence in 3280 may be ambiguous. The =
definition and State
 &gt;&gt;&gt;Machines
 &gt;&gt;&gt;are not at odds. Also, if you point to =
the specific location of the 
 &gt;&gt;&gt;sentence in 3280, I will be happy to =
determine if this is being taken 
 &gt;&gt;&gt;out of context or not.
 &gt;
 &gt;&gt;Santosh,
 &gt;
 &gt;&gt;Denis is referring to the final sentence in =
the following paragraph:
 &gt;
 &gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CRL issuers =
issue CRLs.&nbsp; The CRL issuer is either the CA or an
 entity
 &gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; that has been =
authorized by the CA to issue CRLS.&nbsp; CAs publish CRLs
 &gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; to provide =
status information about the certificates they issued.
 &gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; However, a CA =
may delegate this responsibility to another trusted
 &gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
authority.&nbsp; Whenever the CRL issuer is not the CA that issued =
the
 &gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; certificates, =
the CRL is referred to as an indirect CRL.
 &gt;
 &gt;&gt;I believe the problem is that Denis is =
interpreting this sentence as a
 &gt;&gt;definition when it is not one.&nbsp; Here is =
the definition of indirect CRL 
 &gt;&gt;in X.509:
 &gt;
 &gt;You mean that RFC 3280 contains no formal =
definition of what an 
 &gt;Indirect CRL is.
 &gt;
 &gt;A good practice for RFCs would be to follow ISO =
editing rules where 
 &gt;there MUST be a separate section for formal =
definitions.&nbsp; :-)
 &gt;
 &gt;However the extracted sentence is the earliest =
use of the wording
 &gt;&quot;indirect CRL&quot; in the document saying =
what an indirect CRL is. It is 
 &gt;not explained later on.
 &gt;
 &gt;The definition from X.509 you mention is thus =
not an RFC 3280
 &gt;definition.
 &gt;
 &gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; indirect CRL =
(iCRL):&nbsp; A revocation list that at least contains
 &gt;&gt;revocation information
 &gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; about =
certificates issued by authorities other than that which
 &gt;&gt;issued this CRL.
 &gt;
 &gt;The X.509 definition is NOT :
 &gt;
 &gt;indirect CRL (iCRL):&nbsp; A revocation list =
that at least contains
 &gt;revocation information about certificates issued =
by *an authority* 
 &gt;other than that which issued this CRL.
 &gt;
 &gt;The X.509 definition is NOT either:
 &gt;
 &gt;indirect CRL (iCRL):&nbsp; A revocation list =
that at least contains
 &gt;revocation information about certificates issued =
by *one or more* 
 &gt;authorities other than that which issued
 &gt;this CRL.
 &gt;&nbsp; 
 &gt;&gt;In order to help avoid this confusion in =
3280bis, I have removed the
 &gt;&gt;sentence &quot;Whenever ....&quot; from =
3280bis draft -01 and have added the 
 &gt;&gt;following paragraph:
 &gt;&gt;
 &gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; If the scope =
of the CRL includes one or more certificates issued by
 &gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; an entity =
other than the CRL issuer, then it is an indirect CRL.
 &gt;
 &gt;Arhh!&nbsp; Once again: &quot;certificates =
issued by .. CRL issuer&quot;.
 &gt;
 &gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The
 &gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; scope of an =
indirect CRL may be limited to certificates issued by a
 &gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; single CA or =
may include certificates issued by multiple CAs.
 &gt;
 &gt;This would have been true if the X.509 =
definition had been written
 &gt;differently.
 &gt;
 &gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; If the
 &gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; issuer of the =
indirect CRL is a CA, then the scope of the indirect
 &gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CRL MAY =
include certificates issued by the issuer of the CRL.
 &gt;
 &gt;This is ruled out by the current quoted =
sentence.
 &gt;
 &gt;&gt;I believe that this text is fully consistent =
with the X.509 definition
 &gt;&gt;of indirect CRL
 &gt;
 &gt;Sorry, it is not.
 &gt;
 &gt;&gt; as well as the descriptions of the =
indirectCRL flag and
 &gt;&gt;the certificateIssuer CRL entry extension in =
both X.509 and RFC 3280
 &gt;&gt;and
 &gt;&gt;the algorithm in section 6.3.3 of RFC =
3280.
 &gt;
 &gt;Page 59 is stating:
 &gt;
 &gt;&nbsp;&nbsp; &quot;The CRL issuer MUST assert =
the indirectCRL boolean, if the scope of
 &gt;&nbsp;&nbsp; the CRL includes certificates =
issued by authorities other than the
 &gt;&nbsp;&nbsp; CRL issuer.&nbsp; The authority =
responsible for each entry is indicated by
 &gt;&nbsp;&nbsp; the certificate issuer CRL entry =
extension (section 5.3.4)&quot;.
 &gt;
 &gt;It is clear that this flag is present when there =
are certificate issuer
 &gt;CRL entry extensions.
 &gt;
 &gt;Thus, in the simplest case, where a CA =
designates another entity to
 &gt;issue revocation status information for some of =
its certificates, the 
 &gt;certificate issuer CRL entry extension
 &gt;is not needed, neither the indirectCRL =
boolean.
 &gt;
 &gt;The way to fix the problem is simple: either =
adopt (but add &quot;may&quot;) the
 &gt;definition of X.509 or make it clearer by =
saying:
 &gt;
 &gt;indirect CRL (iCRL):&nbsp; A revocation list =
that at least *may* contain
 &gt;revocation information about certificates issued =
by more than one CA.
 &gt;
 &gt;and add for clarification:
 &gt;
 &gt;delegatedCRL (dCRL):&nbsp; A revocation list =
issued by a CRL Issuer that
 &gt;received and accepted a delegation for issuing =
revocation status 
 &gt;information from a single CA, that =
contains
 &gt;revocation information about certificates issued =
by that single CA.
 &gt;
 &gt;See processing details for these two cases =
in
 &gt;&lt;draft-pinkas-pkix-conf-crl-validation-02.txt&gt;=

<BR><FONT SIZE=3D2>&gt;that is now available.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;The benefits are:</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; 1) a very simple CRL processing when the CRL =
contains revocation</FONT>
<BR><FONT SIZE=3D2>&gt;information</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; about certificates from a =
single CA.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; 2) a (much) more complex CRL processing when =
the CRL contains revocation </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; information about =
certificates from more than one CA, including the</FONT>
<BR><FONT SIZE=3D2>&gt;(seldom ?)</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; case where the CRL issuer is =
also a CA.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;Denis</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;Dave</FONT>
</P>
<BR>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C5911C.5742821A--

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 j6PCWAAR090814; Mon, 25 Jul 2005 05:32: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 j6PCWAKj090813; Mon, 25 Jul 2005 05:32:10 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6PCW9lT090763 for <ietf-pkix@imc.org>; Mon, 25 Jul 2005 05:32:09 -0700 (PDT) (envelope-from Francis.Dupont@enst-bretagne.fr)
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j6PCVqs24597; Mon, 25 Jul 2005 14:31:52 +0200
Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j6PCVqeN072615; Mon, 25 Jul 2005 14:31:52 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr)
Message-Id: <200507251231.j6PCVqeN072615@givry.rennes.enst-bretagne.fr>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: Mouna Skouri <mskouri@yahoo.fr>
cc: ietf-pkix@imc.org
Subject: Re: SCVP implementation 
In-reply-to: Your message of Sat, 16 Jul 2005 00:10:43 +0200. <20050715221044.87864.qmail@web26601.mail.ukl.yahoo.com> 
Date: Mon, 25 Jul 2005 14:31:52 +0200
X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <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 your previous mail you wrote:

   Does anyone know if there is any implementation of SCVP?

=> I have an old one:
 + open source (same licence than OpenSSL)
 + applications using it
 + tested on FreeBSD 4.x and Linux Mandrake (local RH clone)
 - pretty old (> 6 months)
 - based on a previous temporary I-D
 - use OpenSSL 0.9.7x (no real policy stuff for instance)
 - install documentation (*needed*) both hairy and in French
I'll be at the next IETF (perhaps not at the PKIX session because
of agenda conflicts).

Regards

Francis.Dupont@enst-bretagne.fr

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 j6PC8pGp081656; Mon, 25 Jul 2005 05: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 j6PC8pcw081654; Mon, 25 Jul 2005 05:08:51 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from host15.websitesource.com (host15.websitesource.com [209.239.32.38]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6PC8oxD081640 for <ietf-pkix@imc.org>; Mon, 25 Jul 2005 05:08:50 -0700 (PDT) (envelope-from chokhani@orionsec.com)
Received: from wchokhani3 (pcp09271453pcs.arlngt01.va.comcast.net [69.143.129.49]) by host15.websitesource.com (8.12.10/8.12.10) with ESMTP id j6PC8lV6027088 for <ietf-pkix@imc.org>; Mon, 25 Jul 2005 08:08:49 -0400
From: "Santosh Chokhani" <chokhani@orionsec.com>
To: "'pkix'" <ietf-pkix@imc.org>
Subject: RE: IDP indirectCRL flag
Date: Mon, 25 Jul 2005 08:08:39 -0400
Message-ID: <004901c59111$9bb09640$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.2900.2180
In-reply-to: <73388857A695D31197EF00508B08F2981786488B@ntmsg0131.corpmail.telstra.com.au>
Importance: Normal
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j6PC8pxD081649
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

James Manger and Denis,

Can you explain me why we would want to change the standard and impose these
additional constraints for indirect CRL?

-----Original Message-----
From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On
Behalf Of Manger, James H
Sent: Sunday, July 24, 2005 9:43 PM
To: pkix
Subject: RE: IDP indirectCRL flag

Denis,

Perhaps your rules could work if a CRL issuer is not itself a CA and it only
handles certificates from a single CA.  However, a relying party cannot know
(and must not assume) that this is the case for the CRL issuer.

A certificate with a CRL-DP.cRLIssuer field tells the RP that the named CRL
issuer handles certificates from at least the issuer of this certificate.
It gives no information about how many other CAs (if any) the CRL issuer may
also handle, nor whether the CRL issuer is also a CA itself.  A
CRL-DP.cRLIssuer field tells the RP that some CRLs from the named CRL issuer
should cover this certificate, but it does not tell the RP that all CRLs do.

P.S. A CRL issuer may as well use the same name as the CA if it is only ever
going to issue revocation info for that CA's certificates.  That is, the CA
delegates CRL issuance to a separate key, not to a separate name.  This
avoids CRL-DP.cRLIssuer, IDP.indirectCRL & CRL-ENTRY.certificateIssuer
fields completely.

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 j6P1lGC2084337; Sun, 24 Jul 2005 18:47: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 j6P1lGDk084336; Sun, 24 Jul 2005 18:47:16 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from mailbo.vtcif.telstra.com.au (mailbo.vtcif.telstra.com.au [202.12.144.19]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6P1lEJ5084329 for <ietf-pkix@imc.org>; Sun, 24 Jul 2005 18:47:15 -0700 (PDT) (envelope-from James.H.Manger@team.telstra.com)
Received: from mailai.vtcif.telstra.com.au (mailai.vtcif.telstra.com.au [202.12.142.17]) by mailbo.vtcif.telstra.com.au (Postfix) with ESMTP id 3851228F65 for <ietf-pkix@imc.org>; Mon, 25 Jul 2005 11:46:50 +1000 (EST)
Received: from mail2.cdn.telstra.com.au (localhost [127.0.0.1]) by mailai.vtcif.telstra.com.au (Postfix) with ESMTP id B891C1DA84 for <ietf-pkix@imc.org>; Mon, 25 Jul 2005 11:46:49 +1000 (EST)
Received: from wsmsg2902.srv.dir.telstra.com (wsmsg2902.srv.dir.telstra.com [172.49.40.51]) by mail2.cdn.telstra.com.au (Postfix) with ESMTP id 4716C41EF3 for <ietf-pkix@imc.org>; Mon, 25 Jul 2005 11:46:49 +1000 (EST)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Subject: RE: IDP indirectCRL flag
Date: Mon, 25 Jul 2005 11:43:02 +1000
Message-ID: <73388857A695D31197EF00508B08F2981786488B@ntmsg0131.corpmail.telstra.com.au>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: IDP indirectCRL flag
Thread-Index: AcWOAMGfO1zobKO0R76z+h7EPd2VuwAUanEgAJc+iqA=
From: "Manger, James H" <James.H.Manger@team.telstra.com>
To: "pkix" <ietf-pkix@imc.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by above.proper.com id j6P1lFJ5084330
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <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,

Perhaps your rules could work if a CRL issuer is not itself a CA and it only handles certificates from a single CA.  However, a relying party cannot know (and must not assume) that this is the case for the CRL issuer.

A certificate with a CRL-DP.cRLIssuer field tells the RP that the named CRL issuer handles certificates from at least the issuer of this certificate.  It gives no information about how many other CAs (if any) the CRL issuer may also handle, nor whether the CRL issuer is also a CA itself.  A CRL-DP.cRLIssuer field tells the RP that some CRLs from the named CRL issuer should cover this certificate, but it does not tell the RP that all CRLs do.

P.S. A CRL issuer may as well use the same name as the CA if it is only ever going to issue revocation info for that CA's certificates.  That is, the CA delegates CRL issuance to a separate key, not to a separate name.  This avoids CRL-DP.cRLIssuer, IDP.indirectCRL & CRL-ENTRY.certificateIssuer fields completely.

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 j6MM98NR088246; Fri, 22 Jul 2005 15:09: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 j6MM98Sa088245; Fri, 22 Jul 2005 15:09:08 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from host15.websitesource.com (host15.websitesource.com [209.239.32.38]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6MM975a088238 for <ietf-pkix@imc.org>; Fri, 22 Jul 2005 15:09:07 -0700 (PDT) (envelope-from chokhani@orionsec.com)
Received: from wchokhani3 (pcp09271453pcs.arlngt01.va.comcast.net [69.143.129.49]) by host15.websitesource.com (8.12.10/8.12.10) with ESMTP id j6MM95V6017753 for <ietf-pkix@imc.org>; Fri, 22 Jul 2005 18:09:07 -0400
From: "Santosh Chokhani" <chokhani@orionsec.com>
To: "'pkix'" <ietf-pkix@imc.org>
Subject: RE: Correction to be done to <draft-pinkas-pkix-conf-crl-validation-01.txt>
Date: Fri, 22 Jul 2005 18:08:58 -0400
Message-ID: <005a01c58f09$f93a43b0$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.2900.2180
In-Reply-To: <42E10BA2.7010700@cs.tcd.ie>
Importance: Normal
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j6MM975a088239
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <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 of the CRL and Indirect CRL related changes Dennis has proposed are not
required, change the standard, make the standard less secure, and/or do not
solve the issue of name collisions.

-----Original Message-----
From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On
Behalf Of Stephen Farrell
Sent: Friday, July 22, 2005 11:07 AM
To: Denis Pinkas
Cc: Santosh Chokhani; David A. Cooper; Stefan Santesson; pkix
Subject: Re: Correction to be done to
<draft-pinkas-pkix-conf-crl-validation-01.txt>

Denis,

> The point is not simply a vocabulary problem, but that that it is
> possible *for a RP* to support CRLs issued by CRL Issuers that 
> are not CAs, without the need to support the indirectCRL boolean 
> and the certificate issuer CRL entry extension and this makes the 
> algorithm simpler, easier to implement, faster, etc ...

I think this'd be a bad idea. Aside from anything else, it assumes that some
relationships between certificate and CRL issuers won't change over time.
Those do change and if this were adopted the RP's wouldn't have a way to
easily see that.

Stephen.

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 j6MLwFdC087432; Fri, 22 Jul 2005 14:58: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 j6MLwF0T087431; Fri, 22 Jul 2005 14:58:15 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from host15.websitesource.com (host15.websitesource.com [209.239.32.38]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6MLwEwh087412 for <ietf-pkix@imc.org>; Fri, 22 Jul 2005 14:58:15 -0700 (PDT) (envelope-from chokhani@orionsec.com)
Received: from wchokhani3 (pcp09271453pcs.arlngt01.va.comcast.net [69.143.129.49]) by host15.websitesource.com (8.12.10/8.12.10) with ESMTP id j6MLwCV6001480 for <ietf-pkix@imc.org>; Fri, 22 Jul 2005 17:58:13 -0400
From: "Santosh Chokhani" <chokhani@orionsec.com>
To: "'pkix'" <ietf-pkix@imc.org>
Subject: RE: RE: Re: Correction to be done to <draft-pinkas-pkix-conf-crl-validation-01.txt>
Date: Fri, 22 Jul 2005 17:58:06 -0400
Message-ID: <004901c58f08$73d02ba0$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.2900.2180
In-Reply-To: <OFCD36C8D2.3317C595-ONC1257046.00505330@frcl.bull.fr>
Importance: Normal
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j6MLwFwh087425
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <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,

X.509 and 3280 are clear and do not need all these cases your e-mail
contains.  An indirect CRL bit must be asserted if a CRL is supposed to
cover certificates issued by one or more CAs other than the CRL Issuer.

-----Original Message-----
From: Denis Pinkas [mailto:denis.pinkas@bull.net] 
Sent: Friday, July 22, 2005 11:38 AM
To: Sharon Boeyen; David A. Cooper; Santosh Chokhani
Cc: 'pkix'
Subject: Re: RE: Re: Correction to be done to
<draft-pinkas-pkix-conf-crl-validation-01.txt>

>Denis, I'm sorry but I really am not following your thought processes 
>at all.

Sharon,

First, I appreciate the time you spent digging into the past. 

Please forget about the vocabulary for a while, otherwise 
you will not follow my "thought process" that I will try to explain..

If you take the case of a simple scheme where a CRL Issuer accepts 
to issue revocation status information from only one CA, then from 
a RP point of view the certificate issuer CRL entry extension is not 
needed. By implication the indirect CRL boolean that signals the 
presence of that extension is not needed either. 

Now, we can come back to the vocabulary issue:  since the indirectCRL 
boolean is not needed, I would not call that kind of CRL an indirect CRL.

Using the rules that I have described in
<draft-pinkas-pkix-conf-crl-validation-02.txt>, 
in sections 6.3.3.1 and 6.3.3.2, I believe it is possible to securely
support that 
simple scheme, ... unless I made an error in them, but until now nobody as
yet 
demonstrated a case where these rules, *from a RP point of view*, would be
insufficient.

So why make things complicated, when they can be simple ?

>X.509 does include a definition for indirect CRLs. RFC 3280 is a 
>profile of X.509 not a replacement for it. Therefore there is no need 
>to redefine terms in 3280 that are defined in 509. There is no harm in 
>clarifying terms in 3280 if the group so chooses but a profile should 
>not alter the intent of a definition.
>
>I take your point that the 509 definition says "authorities" instead of 
>"authority or authorities". I have taken the time (a lot of it!!!) to 
>dig through my files to track the history of that definition as I was 
>the editor of X.509 at the time it was added. (Sometimes I am happy 
>that I'm such a packrat).
>
>The definition that has been quoted by David from X.509 was added as an 
>outcome of the April 1999 meeting in Orlando Florida. It was part of 
>the resolution of Canadian comment number 24 submitted to that meeting 
>against the X.509 PDAM. The relevant part of the disposition of that 
>comment was recorded as "Accepted with a few minor modifications to the 
>proposed text. Also a definition for indirect CRL will be added." I was 
>the author of the Canadian comment submitted to that meeting and I was 
>also the editor that created the definition that is now in X.509 as a 
>result of that comment disposition. Let me assure you that with both 
>hats on it WAS my intention that any CRL that included revocation 
>notices for certificates that were issued by any authority other than 
>that which issued the CRL is an indirect CRL.

On my side, my understanding was as I explained. Only when the CRL covers 
certificates from more than one CA, are both the certificate issuer CRL
entry extension 
needed and the indirectCRL boolean needed. In RFC 3280 the requirements for 
these two fields are in two consecutive sentences within the same short
paragraph 
so why I believe(d) they come together.

I hope that this allows at least you to understand my thought process, even
if 
you have a different opinion.

Denis

> I will be happy to submit a defect report to X.509 to change 
>"authorities" to "authority or authorities". As the editor and the 
>submitter of the ballot comment that drove the discussion to add the 
>definition in the first place I will happily admit I made an error in 
>using the term "authorities" in that definition.
>
>Cheers,
>Sharon
>
>-----Original Message-----
>From: owner-ietf-pkix@mail.imc.org 
>[mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Denis Pinkas
>Sent: Thursday, July 21, 2005 10:34 AM
>To: David A. Cooper; Santosh Chokhani
>Cc: 'pkix'
>Subject: Re: Re: Correction to be done to 
><draft-pinkas-pkix-conf-crl-validation-01.txt>
>
>
>
>David,
>
>>Santosh Chokhani wrote:
>>
>>>Denis,
>>>
>>>A sentence in 3280 may be ambiguous. The definition and State 
>>>Machines
>>>are not at odds. Also, if you point to the specific location of the 
>>>sentence in 3280, I will be happy to determine if this is being taken 
>>>out of context or not.
>
>>Santosh,
>
>>Denis is referring to the final sentence in the following paragraph:
>
>>      CRL issuers issue CRLs.  The CRL issuer is either the CA or an
entity
>>      that has been authorized by the CA to issue CRLS.  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.
>
>>I believe the problem is that Denis is interpreting this sentence as a 
>>definition when it is not one.  Here is the definition of indirect CRL 
>>in X.509:
>
>You mean that RFC 3280 contains no formal definition of what an
>Indirect CRL is. 
>
>A good practice for RFCs would be to follow ISO editing rules where
>there MUST be a separate section for formal definitions.  :-)
>
>However the extracted sentence is the earliest use of the wording 
>"indirect CRL" in the document saying what an indirect CRL is. It is 
>not explained later on.
>
>The definition from X.509 you mention is thus not an RFC 3280 
>definition.
>
>>      indirect CRL (iCRL):  A revocation list that at least contains 
>>revocation information
>>      about certificates issued by authorities other than that which
>>issued this CRL.
>
>The X.509 definition is NOT :
>
>indirect CRL (iCRL):  A revocation list that at least contains 
>revocation information about certificates issued by *an authority* 
>other than that which issued this CRL.
>
>The X.509 definition is NOT either:
>
>indirect CRL (iCRL):  A revocation list that at least contains 
>revocation information about certificates issued by *one or more* 
>authorities other than that which issued
>this CRL.
>  
>>In order to help avoid this confusion in 3280bis, I have removed the 
>>sentence "Whenever ...." from 3280bis draft -01 and have added the 
>>following paragraph:
>>
>>      If the scope of the CRL includes one or more certificates issued by
>>      an entity other than the CRL issuer, then it is an indirect CRL.
>
>Arhh!  Once again: "certificates issued by .. CRL issuer".
>
>>      The
>>      scope of an indirect CRL may be limited to certificates issued by a
>>      single CA or may include certificates issued by multiple CAs.
>
>This would have been true if the X.509 definition had been written 
>differently.
>
>>      If the
>>      issuer of the indirect CRL is a CA, then the scope of the indirect
>>      CRL MAY include certificates issued by the issuer of the CRL.
>
>This is ruled out by the current quoted sentence.
>
>>I believe that this text is fully consistent with the X.509 definition 
>>of indirect CRL
>
>Sorry, it is not.
>
>> as well as the descriptions of the indirectCRL flag and
>>the certificateIssuer CRL entry extension in both X.509 and RFC 3280 
>>and
>>the algorithm in section 6.3.3 of RFC 3280.
>
>Page 59 is stating:
>
>   "The CRL issuer MUST assert the indirectCRL boolean, if the scope of
>   the CRL includes certificates issued by authorities other than the
>   CRL issuer.  The authority responsible for each entry is indicated by
>   the certificate issuer CRL entry extension (section 5.3.4)".
>
>It is clear that this flag is present when there are certificate issuer 
>CRL entry extensions.
>
>Thus, in the simplest case, where a CA designates another entity to 
>issue revocation status information for some of its certificates, the 
>certificate issuer CRL entry extension
>is not needed, neither the indirectCRL boolean.
>
>The way to fix the problem is simple: either adopt (but add "may") the 
>definition of X.509 or make it clearer by saying:
>
>indirect CRL (iCRL):  A revocation list that at least *may* contain 
>revocation information about certificates issued by more than one CA.
>
>and add for clarification:
>
>delegatedCRL (dCRL):  A revocation list issued by a CRL Issuer that 
>received and accepted a delegation for issuing revocation status 
>information from a single CA, that contains
>revocation information about certificates issued by that single CA.
>
>See processing details for these two cases in 
><draft-pinkas-pkix-conf-crl-validation-02.txt>
>that is now available.
>
>The benefits are:
>
> 1) a very simple CRL processing when the CRL contains revocation 
>information
>    about certificates from a single CA.
>
> 2) a (much) more complex CRL processing when the CRL contains revocation 
>    information about certificates from more than one CA, including the 
>(seldom ?)
>    case where the CRL issuer is also a CA.
>
>Denis
>
>>Dave

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 j6MLB5MG084062; Fri, 22 Jul 2005 14: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 j6MLB5tB084061; Fri, 22 Jul 2005 14:11:05 -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 (rimp2.nist.gov [129.6.16.227]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6MLB3Aq084054 for <ietf-pkix@imc.org>; Fri, 22 Jul 2005 14:11:04 -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.13.1/8.13.1) with ESMTP id j6MLAm6t019679; Fri, 22 Jul 2005 17:10:49 -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 j6MLAa6v007620; Fri, 22 Jul 2005 17:10:40 -0400 (EDT)
Message-Id: <5.1.0.14.2.20050722131432.038d9508@email.nist.gov>
X-Sender: wpolk@email.nist.gov
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 22 Jul 2005 16:56:50 -0400
To: "Denis Pinkas" <denis.pinkas@bull.net>, "ietf-pkix@imc.org" <ietf-pkix@imc.org>
From: Tim Polk <tim.polk@nist.gov>
Subject: Re: How ambiguous are names in actuality?
Cc: kent@bbn.com
In-Reply-To: <OFE12E6CDC.2B167B87-ONC1257042.002D204F@frcl.bull.fr>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: tim.polk@nist.gov
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j6MLB4Aq084056
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <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,

When I started in this field, I was taught that security should always be 
*commensurate with risk*.  It is always possible to add new controls, but 
it is not always appropriate.  That is why I started with a lot of thinking 
about the problem, and the actual level of risk faced by PKI users.

I did not see anything in your message below that indicates that my 
analysis of the risk is incorrect.  I explained in detail why I believe 
name ambiguity would only occur in rather unlikely niche cases.  Do you 
disagree with my analysis, and if so why?

In my opinion, the current mechanisms provide sufficient security to 
address the risk.  You have proposed rather major changes to the CRL 
validation algorithm.  I have proposed changes as well, but mainly advocate 
using existing mechanisms as designed.  My change can also be implemented 
through configuration (i.e., by accepting only a single trust 
anchor.)  Your proposal would have a significant impact on all our running 
code; IMHO this is inappropriate unless the changes significantly reduce 
the risks faced by PKI relying parties.

(BTW, I also agree with Steve's observation that the discussion of ACLs 
below significantly expands the scope of 3280bis.  A separate BCP on the 
topic would certainly be of value, but for the purposes of 3280bis we 
should restrict this discussion to path validation.)

Thanks,

Tim Polk

At 10:13 AM 7/18/2005 +0100, Denis Pinkas wrote:
>Tim,
>
>My views are quite different. You are looking for a solution to MITIGATE 
>the risk,
>whereas there exists a solution to SUPPRESS the risk, as it is explained 
>below.
>The changes you propose, like same trust anchor, do not suppress the risk.
>
>You mention that the problem of name collisions exists both for two leaf 
>certificates
>and for CRL certificates. This is correct. While the problem for CRL 
>certificates arises
>only *during* the path verification algorithm, this is not the case for 
>leaf certificates.
>
>For a leaf certificate that has been verified to be valid, the output of 
>the algorithm
>is a sequence of certificates up to a given trust anchor. The major issue 
>is what
>to do with it, and this is NOT mentioned within RFC 3280.
>
>Leaf certificates may be used in two contexts:
>
>    a) access control or end-entity authentication,
>    b) non repudiation.
>
>These two cases are different and are explored below.
>
>ACCESS CONTROL OR END-ENTITY AUTHENTICATION
>
>There are two phases when a public key certificate is used for an access 
>control service :
>
>- Phase 1 : the owner of the protected object must fill-in the ACL correctly,
>- Phase 2 : during an access, the sequence of certificates that has been 
>validated
>                 must be checked against the content of the ACL.
>
>The real issue is that nowhere in RFC 3280 it is said what the content of 
>the ACL should be.
>Because of this lack of information, some implementations of relying 
>party software
>may be subject to problems related to name collisions, while some others 
>will not.
>
>There is no clear indication in RFC 3280 to tell how the owner of the 
>protected object
>will make sure that it is pointing to the right certificate BEFORE using 
>that certificate
>for access control purposes.
>
>The point is that the owner of the protected object SHALL enter the full 
>certification path
>in the ACL. If it does not have the full path, then it SHALL construct it 
>according to
>the validation policy that is appropriate for his application and SHOULD 
>make sure
>that it is not revoked. It will thus use the full certification path and 
>may check either
>automatically using some local rules or may check using his brain that the 
>full certification
>path is correct.
>
>Note that if the ACL would only contain the DN of the leaf certificate, 
>then the access control
>mechanism would be subject to name collisions,
>
>When the ACL contains both the DN of the leaf certificate and all the DNs 
>from the upper CA
>up to a trust anchor identified by its DN (i.e. the DN of the trust anchor 
>is also taken,
>since there may be more than one trust anchor in a given validation 
>policy), then the
>access control mechanism can never be subject to name collisions.
>
>Since a validation policy may include more than one trust anchor, it means 
>that it
>SHALL not be allowed to define a validation policy that uses two trust 
>anchors with the same DN.
>
>This means that during phase 1, the owner of the protected object must 
>fill-in the ACL
>with all the DNs from the certification path, including the DN from the 
>trust anchor
>(of course a hash of it may be used instead) and that during phase 2, the 
>whole certification path
>must be used and compared with the content of the ACL.
>
>This solution fully *suppresses* the risk in any case.
>
>Of course, in some contexts, some shortcuts may be taken (e.g. when there 
>exists a single
>trust anchor in the validation policy) or when it may be known that name 
>collisions
>may never happen (e.g. because all the CAs apply a given naming policy) 
>but this is not
>the general case.
>
>The solution explained above is also much simpler than adding name constrains
>that could be anyway defeated.
>
>NON REPUDIATION
>
>With non repudiation, only the whole sequence of DN extracted from the 
>certification path
>is meaningful. A DN like CN= John William does not make sense unless at 
>the same time
>all the upper DNs from the CAs are used or displayed. So if someone wants 
>to know
>without any ambiguity who a signer is, it SHALL use of the sequence of DN 
>up to
>a trust anchor of the signature policy.
>
>Since a signature policy may include more than one trust anchor, it means 
>that it SHALL NOT
>be allowed to define a signature policy that uses two trust anchors with 
>the same DN.
>
>COLLISIONS BETWEEN CRL ISSUER NAMES
>
>For CRLs, I have already mentioned the additional sentence that shall be 
>added to RFC 3280.
>It is copied again below  :
>
>The full certification path that has been used to validate the target 
>certificate MUST also be
>used to validate the CRL issuer certificate .
>
>
>REPLY TO YOUR CONCLUSIONS
>
>As a reply to your conclusions: using path length constrains does not 
>solve the issue.
>Adding other constrains does not solve the issue either. Using name 
>constraints would
>introduce an order of magnitude of complexity and would not be effective 
>in the general case.
>Using certification policies and path length constrains might help, but 
>still do not solve
>the problem in the general case.
>
>
>Denis
>
>
> >Ambiguity has recently become a hot topic on this list.  This is a really
> >complicated issue, and I have personally had a great deal of trouble
> >sorting out the real level of risk.  Some of the proposed changes would
> >greatly impact current software, and these changes should only be
> >contemplated if the risk is merits such change.
> >
> >So, I have spent a lot of time, off and on, thinking about ambiguity.  I
> >can't claim to have sorted it all out, but I have convinced myself that one
> >minor change is absolutely required, and that the current suite of
> >mechanisms can virtually eliminate ambiguity in real PKIs.
> >
> >My thinking is appended to this message;  I apologize for its length, but
> >to paraphrase Mark Twain, I simply don't have time to make this short and
> >concise.  I have attempted to define ambiguity, characterize the ways
> >ambiguity can enter into a PKI, and describe the set of mechanisms that
> >mitigate this risk.
> >
> >Thanks,
> >
> >Tim Polk
> >
> >------------------------------------------------------------------------- 
> -------------------------------------------------------
> >
> >              How ambiguous are names in actuality, and how important is it?
> >
> >I believe that X.509 expected assignment of unambiguous names based on a
> >hierarchical system of naming authorities.  Whether you agree with that
> >premise, it is safe to say that the global X.500 directory and its
> >corresponding system of naming authorities do not exist. So, it may not be
> >safe to assume that there are no name collisions whatsoever in all the DNs
> >that appear in certificates and CRLs!  I am sure such collisions exist
> >somewhere (although I havent encountered any examples).  The real question
> >here is What security risk does this situation present, and are the
> >current mechanisms adequate to address this risk?
> >
> >Lets recognize that the goal for PKIX is not to have globally unambiguous
> >names, but to be able to obtain a trustworthy public key to establish a
> >security service. Ambiguity in names is a problem when it causes the
> >relying party to trust the wrong public key.
> >
> >There are two ways ambiguous names could cause problems.  First, I could
> >accept public keys from two certificates as representing the same person
> >based on the same subject name.  If these two certificates are bound to
> >different individuals I may provide a service to the wrong party (or
> >disclose confidential data, etc., etc.)  Second, I could accept a CRL to
> >validate a particular certificate, based on the same issuer name in the
> >certificate and CRL.  If the certificate and CRL were not actually issued
> >by the same CA, then the relying party may obtain incorrect certificate 
> status.
> >
> >Note that both of these problems are in the context of path validation.  If
> >a name collision exists, but only one of the objects (e.g., certificate or
> >CRL) validates for a given relying party, then there is no actual ambiguity
> >from that relying partys point of view.
> >
> >That is, assume two certificates exist with the same subject name but are
> >bound to different people.  If Alice can only validate one of those
> >certificates, there is no ambiguity in Alices world.   Similarly, if Bob
> >can only validate one of those certificates, there is no ambiguity in Bobs
> >world.   (It does not matter if Bob and Alice are validating the same
> >certificate, or different ones!)   Similarly, if two CAs have the same
> >issuer name, but Alice can only validate one, she cant accept the wrong
> >CRL.  Ditto for Bob.
> >
> >So, ambiguity is a concern only in the context of path validation for a
> >given relying party. This means that the mechanisms that are employed in
> >path validation are relevant to when names are, and are not, ambiguous. Id
> >also like to point out that path validation is always performed in the
> >context of a particular trust anchor.  (A relying party may accept paths
> >that begin with multiple trust anchors, but each specific path has a single
> >trust anchor.)  Seems irrelevant at the moment, but I will get back to it!
> >
> >Definition 1:  a Name N is unambiguous for a trust anchor T if and only if
> >all certificates that validate for T and have the subject N refer to the
> >same entity.
> >
> >Now, lets think about where name collisions can occur in the first place.
> >There seems to be consensus that a single CA will not issue two
> >certificates to two different entities with the same subject name.  So, if
> >a single CA issues two certificates to O=Microsoft, cn=John Wilson they
> >better relate to the same guy.  Similarly if a particular CA issues two
> >certificates to c=US, O=U.S. Government, OU=NIST, CN=CA1 then the subject
> >of both certificates must be the same CA.
> >
> >So, we are only worried about the case where two different CAs are trusted
> >with respect to a trust anchor T and issue certificates to different
> >subjects but use the same name.  So, when can name collisions occur between
> >CAs?  Or, better yet, under what conditions can we be sure name collisions
> >wont occur?  Lets start with user certificates.
> >
> >In general, each CA that issues user certificates does so for a particular
> >name space.  That is, all names assigned to users will be in a particular
> >Directory Information Tree (DIT).   The CA will either work with a naming
> >authority that it considers authoritative or may assume that function
> >itself.   For example, the NIST CA only issues user certificates in the
> >C=US, O=U.S. Government, OU=NIST DIT.   The NIST CA has been designated
> >as our naming authority as well, so it keeps track of the names it
> >assigns.  Similarly, the CA that supports NASA only issues certificates for
> >the name space C=US,  O=U.S. Government, OU=NASA DIT.
> >
> >These name spaces are disjoint, so name collisions cannot occur involving
> >user certificates generated by the NASA and NIST CAs.  In fact, consider a
> >PKI with trust anchor T and CAs C(1), C(2), , C(n) issuing for name spaces
> >P(1), P(2), , P(n).  If spaces P(1), P(2), , P(n) are pairwise disjoint,
> >name collisions cannot occur involving user certificates generated by C(1),
> >C(2), , C(n).
> >
> >Case 1:  Consider a PKI with trust anchor T, and CAs C1, C2, and C3.  C1,
> >C2, and C3 issue end user certificates in the DITs N1, N2, and N3
> >respectively.  If N1, N2, and N3 are pairwise disjoint, then the user names
> >are unambiguous with respect to T.
> >
> >In more complex PKIs, we may encounter situations where CAs issue user
> >certificates for name spaces that overlap.  For example, in the U.S DoDs
> >hierarchical PKI, CAs all issue certificates in the DIT C=US, O=U.S.
> >Government, OU=DOD.  Users routinely receive three certificates from two
> >different CAs, so all the DoD CAs rely on a common naming authority to
> >ensure that certificates with the same DNs are issued to the same person.
> >
> >Case 2: Consider a PKI with trust anchor T, and CAs C1, C2, and C3.  C1,
> >C2, and C3 issue end user certificates in the DITs N1, N2, and N3
> >respectively.  N1 and N2 overlap, but N3 is disjoint from N1 and N2.   If
> >CA1 and CA2 recognize the same naming authority, then the user names in the
> >PKI are unambiguous with respect to T.
> >
> >That is, if all the CAs either: (1) issue certificates in disjoint name
> >spaces, or (2) issue certificates in shared name spaces based on a common
> >naming authority, names will be unambiguous!
> >
> >Of course, CAs may issue CA certificates as well.  In this case, the CA
> >does not assign the names, but rather uses the established name.  This is
> >trickier, since the name spaces for CA certificates overlaps but no naming
> >authority exists.  It is still the responsibility of each CA to ensure that
> >there are no name collisions in CA certificates it issues!  This is not
> >generally a problem, since we require names to be meaningful.  A CA should
> >never issue a certificate to a CA with the DN C=US, O=Coca Cola unless
> >the subject CA is associated with that company.  Similarly, if a CA issues
> >certificates in the DIT C=US, O=Coca Cola then it must be associated with
> >the company!
> >
> >Of course, a rogue CA may masquerade under the wrong name, or issue
> >certificates in a DIT it clearly has no right to use, but no decent CA will
> >cross certify with it.  Since we are interested in ambiguity with respect
> >to a trust anchor, the behavior of a rogue CA is irrelevant.  Without cross
> >certification, no paths involving the rogue CA can be constructed.  (Note
> >that users installing the rogue as a trust anchor is out of scope here!)
> >
> >However, authority for a name space is not always crystal clear.  Without a
> >central naming authority, there is no clear title for a particular DIT.  We
> >rely on heuristics that work nicely for large entities like Coca-Cola but
> >may fail for smaller organizations.  For example, there may be a number of
> >companies with variants on a particular name.  If the name space assumed by
> >an organization asserts Orion rather than Orion Security or Orion
> >Space Sciences, the name may be ambiguous without being blatantly
> >false.  Each entity could reasonably assign user names in the C=US,
> >O=Orion DIT.   If each organization established their CA with the name
> >C=US, O=Orion, CN=CA1 things could get really ugly.
> >
> >A trust anchor T may cross certify with two different CAs  say the ones
> >from NIST and NASA.  Each of those CAs may have a relationship with an
> >Orion.  If each of them cross certifies with the Orion they know and
> >love, we have an immediate name collision for a CA named C=US, O=Orion,
> >CN=CA1, and potentially name collisions for C=US, O=Orion, CN=John
> >Wilson, etc., etc.  Each CA has played by the rules, but names have just
> >become ambiguous with respect to T.  This might be avoided if T is involved
> >in the policy decisions leading up to cross certification  but that is
> >often NOT the case.
> >
> >Fortunately, we need not depend on policy alone.   Beyond the
> >procedural/policy issues, there are some important mechanisms that help us
> >with name space control.  Most significant are path length constraints and
> >name constraints.  When trust anchor T issued those CA certificates, it
> >probably wasnt expecting to accept transitive trust from those CAs, and it
> >certainly didnt expect to accept the NIST or NASA CA as authoritative for
> >the C=US, O=Orion DIT.
> >
> >I listed path length constraints first because this mechanism provides the
> >simplest and most widely available of our technical controls. Both NASA and
> >NIST use a single CA, rather than a mesh or hierarchy.  If the trust anchor
> >does not wish to leverage other cross certifications performed by NASA or
> >NIST, it simply asserts a path length constraint of zero!  If T asserted
> >this constraint for at least one of the NIST or NASA CAs, then the name
> >C=US, O=Orion, CN=John Wilson is unambiguous. While this control was not
> >designed exclusively for name space control, it does have the effect of
> >prevenmting subsequent CAs from introducing unexpected name spaces.
> >
> >Unfortunately, this does not solve our problem for C=US, O=Orion,
> >CN=CA1.   This name remains ambiguous.  Even with a path length
> >constraints of zero, a relying party can validate a CRL from either 
> Orion CA.
> >
> >Name constraints is a more appealing technical mechanism, if less
> >consistently available.  T can explicitly designate the name spaces it
> >wishes to recognize in the cross certificate issued to NIST (or NASA).  By
> >asserting a permitted subtree of C=US, O=U.S. Government, OU=NIST with a
> >SkipCerts of zero, certificates in the Orion name space are immediately
> >eliminated.  This includes the offending CA certificate, so the wrong CRL
> >no longer validates.
> >
> >Case 3: Consider a PKI with trust anchor T, and CAs C1, C2, and C3.  C1,
> >C2, and C3 issue end user certificates in the DITs N1, N2, and N3 
> respectively.
> >
> >N1 and N2 are disjoint, but  N3 overlaps with N1 or N2.  C3 does not
> >recognize the same naming authority as C1 or C2.   If name constraints
> >permitted subtrees P3 is imposed in all cross certificates issued to C3,
> >where N1, N2, and P3 are pairwise disjoint, then names are unambiguous with
> >respect to T.  (Names that could have collided are excluded from C3s DIT.)
> >
> >Conclusion/Proposal
> >
> >Ambiguity in names is a relatively minor risk with respect to a given trust
> >anchor.  Ambiguity does not occur because of the actions of a single CA;
> >rather it requires a combination of actions by different CAs within the
> >infrastructure.  If all CA certificates accurately reflect the trust
> >relationships between the CAs by incorporating appropriate path length and
> >name constraints, these risks are greatly reduced if not eliminated.
> >
> >The risk of ambiguous names can be mitigated with a relatively simple
> >modification in 3280bis, and the addition of some security
> >considerations.  Most importantly, 32890bis should be modified to ensure
> >that certificate and CRL validation are always performed with respect to
> >the same trust anchor.  Security considerations should be added to
> >highlight the risk of issuing CA certificates without appropriate
> >constraints, and to caution application developers that trust anchor
> >information should be considered when accepting certificates.
> >
> >The changes that I believe should be implemented are as follows:
> >
> >  (1) Modify section 6.3.3 to state that CRL validation MUST use the same
> >trust anchor T specified in the corresponding certification path.
> >
> >(2) Add security considerations that indicate applications that accept
> >multiple trust anchors should consider the trust anchor in access control
> >decisions to ensure that names are unambiguous.
> >
> >(3) Add security considerations that explain the importance of consistent
> >use of path length and name constraints in preventing name ambiguity.
> >
> >
>
>Regards,
>
>Denis Pinkas

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 j6MKDpvq079724; Fri, 22 Jul 2005 13:13: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 j6MKDpwF079723; Fri, 22 Jul 2005 13:13:51 -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.9) with ESMTP id j6MKDo2L079702 for <ietf-pkix@imc.org>; Fri, 22 Jul 2005 13:13:50 -0700 (PDT) (envelope-from kent@bbn.com)
Received: from [128.89.89.106] (dhcp89-089-106.bbn.com [128.89.89.106]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j6MKDgDd019597; Fri, 22 Jul 2005 16:13:43 -0400 (EDT)
Mime-Version: 1.0
Message-Id: <p0623090dbf06f69a3e36@[128.89.89.106]>
In-Reply-To: <42D6F608.7000704@connotech.com>
References: <42D6F608.7000704@connotech.com>
Date: Fri, 22 Jul 2005 16:14:02 -0400
To: Thierry Moreau <thierry.moreau@connotech.com>
From: Stephen Kent <kent@bbn.com>
Subject: Re: A non-critical self-signed certificate extension for trust anchr renewal ...
Cc: ietf-pkix@imc.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41
X-Virus-Status: Clean
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

Thierry,

A few of comments on your I-D:

	- the notion of including the hash of the next public key to 
be used by a CA (TA) as an extension in a cert is an old one, 
developed by the SET folks. I believe they have a patent on the 
technique. While they used a simple one-way hash for this purpose, 
use of a MASH and the salt may not be enough of a difference to not 
be covered by the patent.

	- you allow for the hash to be of the next cert, not just the 
next public key. Although the text does not seem to say so 
explicitly, I assume this feature makes sense only for scheduled 
rollover, where the complete cert contents, including the validity 
interval, can be computed in advance.

	- some discussion of when it is appropriate to include a 
sequence of future key/cert hash values in an initial cert is needed. 
it would seem sufficient to do this one key/cert at a time in 
general, allowing later keys to be generated in the future, adn thus 
not ave to be stored security for long periods.

	- the lack of a syntax for the renewal message is a worrisome 
omission. it's OK to defer to another document the means of 
transporting the message, but the syntax for the message should 
probably be defined here.

	- section 4.1 is a bit confusing and needs to be reworded, 
and 4.2 has some exposition problems as well. if one MAY rely on the 
digest values in the extension beyond the expiration date of the 
cert, then you need to explain why this is a reasonable behavior and 
under what circumstances it is likely to be necessary.

	- there are numerous odd textual conventions in the document, 
e.g., double square brackets (i.e., "[[") when the phrase "issuer of 
an initial self-signed certificate" appears.

	- the security considerations  section is a mix of 
appropriate guidance relevant to this extension, and extraneous 
guidance not specvific to this context.

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 j6MIUTEt069479; Fri, 22 Jul 2005 11:30: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 j6MIUTsq069478; Fri, 22 Jul 2005 11:30:29 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from mail-eur1.microsoft.com (mail-eur1.microsoft.com [213.199.128.139]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6MIUS6A069454 for <ietf-pkix@imc.org>; Fri, 22 Jul 2005 11:30:28 -0700 (PDT) (envelope-from stefans@microsoft.com)
Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Jul 2005 19:30:22 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: Updated position on indirect CRL path restrictions
Date: Fri, 22 Jul 2005 19:30:20 +0100
Message-ID: <BF9309599A71984CAC5BAC5ECA62994402DC9A9D@EUR-MSG-11.europe.corp.microsoft.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Updated position on indirect CRL path restrictions
Thread-Index: AcWO62pibvw8q6U8RHGS76eGlRhrmA==
From: "Stefan Santesson" <stefans@microsoft.com>
To: "pkix" <ietf-pkix@imc.org>
Cc: "David A. Cooper" <david.cooper@nist.gov>
X-OriginalArrivalTime: 22 Jul 2005 18:30:22.0557 (UTC) FILETIME=[6BB770D0:01C58EEB]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j6MIUT6A069473
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <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 would like to change my position on the issue of indirect CRL path
restrictions.

I do no longer propose any further restrictions other than those
originally proposed in RFC 3280bis.

The cause of this is that I realized that I, and I think also the
discussion on this list, have made an omission in the assessment of the
name collision threat of indirect CRLs.

In the name matching between a certificate and an indirect CRL there is
not only a name matching of the CRL Issuer name between the CRL issuer
field in the CDP extension of the certificate against the Issuer name of
the CRL, there is also a name matching of the certificate issuer name
between the certificate issuer CRL entry extension in the CRL and the
issuer field of the validated certificate.

So for a successful CRL replacement, there need to be both a CRL issuer
name collision AND a CA name collision at the same time + a URL
collision of the storage location of the CRL (even though specification
of a URL is optional and may not be present, it is highly likely to be
present in indirect CRLs).

More clearly:

If CA A use CRL issuer A, there must be another colliding CA A' using a
colliding CRL issuer A' (both names must collide at the same time) for a
successful replacement to take place.

This is a highly unlikely event, especially given the rarity of indirect
CRL use in the first place.
Forcing the certificate and the CRL to be validated from the same root
should thus be sufficient to mitigate any realistic threats.

However, I'm still for a recommendation that paths SHOULD be closely
related and pointing out that conformant implementations MAY choose to
apply restrictions on deviating paths for reasons of local policy and/or
efficiency.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

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 j6MHf1vC065769; Fri, 22 Jul 2005 10:41: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 j6MHf1rF065768; Fri, 22 Jul 2005 10:41: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 (rimp2.nist.gov [129.6.16.227]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6MHexgo065759 for <ietf-pkix@imc.org>; Fri, 22 Jul 2005 10:41:00 -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.13.1/8.13.1) with ESMTP id j6MHekMC012286; Fri, 22 Jul 2005 13:40:48 -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 j6MHed6v000185; Fri, 22 Jul 2005 13:40:39 -0400 (EDT)
Message-Id: <5.1.0.14.2.20050722133311.0394dd98@email.nist.gov>
X-Sender: wpolk@email.nist.gov
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 22 Jul 2005 13:43:02 -0400
To: <ietf-pkix@imc.org>, Denis Pinkas <Denis.Pinkas@bull.net>
From: Tim Polk <tim.polk@nist.gov>
Subject: RE: How ambiguous are names in actuality?
In-Reply-To: <002001c58bb2$02528850$cbb011ac@hq.orionsec.com>
References: <OF246C1757.86E679D9-ONC1257042.00578433@frcl.bull.fr>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-NIST-MailScanner: Found to be clean
X-NIST-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>

Denis,

Santosh's presentation was at the Washington IETF in November 2004.  Due to 
time constraints, he had to abbreviate his presentation, but the complete 
set of slides were included in the meeting proceedings.  The slides can be 
found at:

http://www1.ietf.org/proceedings_new/04nov/slides/pkix-4/sld1.htm

Tim

At 12:01 PM 7/18/2005 -0400, Santosh Chokhani wrote:

>Denis,
>
>Solution was presented at the IETF.  I do not intend to draft an I-D unless
>the WG chairs and AD intend to support its promulgation.
>
>-----Original Message-----
>From: Denis Pinkas [mailto:denis.pinkas@bull.net]
>Sent: Monday, July 18, 2005 12:56 PM
>To: Santosh Chokhani; ietf-pkix@imc.org
>Subject: Re: How ambiguous are names in actuality?
>
>
>Santosh,
>
> >To me the basic problem with Tim's posting is that it is a band aid
> >solution to a problem that has a very simple solution.
>
>The problem raised is much wider that the CRL problem where the solution
>fits in two lines of text:
>
>"The full certification path that has been used to validate the target
>   certificate MUST also be used to validate the CRL issuer certificate".
>
>As far as I remember I have not seen a description of your solution posted
>in:
>http://www.ietf.org/internet-drafts/draft-santosh-pkix-...-00.txt
>
>Denis
>
> >When we look at the issue as an abstract graph theory problem and want
> >a clean and simple solution to make sure that the correct CRL is
> >fetched, the solution I have proposed solves the problem.
> >
> >Any thing else we do, is simply rationalization to support one or more
> >unarticulated motives.
> >
> >-----Original Message-----
> >From: owner-ietf-pkix@mail.imc.org
> >[mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Denis Pinkas
> >Sent: Monday, July 18, 2005 5:13 AM
> >To: Tim Polk; ietf-pkix@imc.org
> >Subject: Re: How ambiguous are names in actuality?
> >
> >
> >
> >Tim,
> >
> >My views are quite different. You are looking for a solution to
> >MITIGATE the risk, whereas there exists a solution to SUPPRESS the
> >risk, as it is explained below.
> >The changes you propose, like "same trust anchor", do not suppress the
>risk.
> >
> >
> >You mention that the problem of name collisions exists both for two
> >leaf certificates and for CRL certificates. This is correct. While the
> >problem for CRL certificates arises
> >only *during* the path verification algorithm, this is not the case for
>leaf
> >certificates.
> >
> >For a leaf certificate that has been verified to be valid, the output
> >of the algorithm is a sequence of certificates up to a given trust
> >anchor. The major issue is what
> >to do with it, and this is NOT mentioned within RFC 3280.
> >
> >Leaf certificates may be used in two contexts:
> >
> >   a) access control or end-entity authentication,
> >   b) non repudiation.
> >
> >These two cases are different and are explored below.
> >
> >ACCESS CONTROL OR END-ENTITY AUTHENTICATION
> >
> >There are two phases when a public key certificate is used for an
> >access control service :
> >
> >- Phase 1 : the owner of the protected object must fill-in the ACL
> >correctly,
> >- Phase 2 : during an access, the sequence of certificates that has
> >been validated
> >                must be checked against the content of the ACL.
> >
> >The real issue is that nowhere in RFC 3280 it is said what the content
> >of the ACL should be. Because of this lack of information, some
> >implementations of "relying party software"
> >may be subject to problems related to name collisions, while some others
> >will not.
> >
> >There is no clear indication in RFC 3280 to tell how the owner of the
> >protected object will make sure that it is pointing to the right
> >certificate BEFORE using that certificate
> >for access control purposes.
> >
> >The point is that the owner of the protected object SHALL enter the
> >full certification path in the ACL. If it does not have the full path,
> >then it SHALL construct it according to
> >the validation policy that is appropriate for his application and SHOULD
> >make sure
> >that it is not revoked. It will thus use the full certification path and
>may
> >check either
> >automatically using some local rules or may check using his brain that the
> >full certification
> >path is correct.
> >
> >Note that if the ACL would only contain the DN of the leaf certificate,
> >then the access control mechanism would be subject to name collisions,
> >
> >When the ACL contains both the DN of the leaf certificate and all the
> >DNs from the upper CA up to a trust anchor identified by its DN (i.e.
> >the DN of the trust anchor is also taken,
> >since there may be more than one trust anchor in a given validation
>policy),
> >then the
> >access control mechanism can never be subject to name collisions.
> >
> >Since a validation policy may include more than one trust anchor, it
> >means that it SHALL not be allowed to define a validation policy that
> >uses two trust anchors with the same DN.
> >
> >This means that during phase 1, the owner of the protected object must
> >fill-in the ACL with all the DNs from the certification path, including
> >the DN from the trust anchor
> >(of course a hash of it may be used instead) and that during phase 2, the
> >whole certification path
> >must be used and compared with the content of the ACL.
> >
> >This solution fully *suppresses* the risk in any case.
> >
> >Of course, in some contexts, some shortcuts may be taken (e.g. when
> >there exists a single trust anchor in the validation policy) or when it
> >may be known that name collisions
> >may never happen (e.g. because all the CAs apply a given naming policy) but
> >this is not
> >the general case.
> >
> >The solution explained above is also much simpler than adding name
> >constrains that could be anyway defeated.
> >
> >NON REPUDIATION
> >
> >With non repudiation, only the whole sequence of DN extracted from the
> >certification path is meaningful. A DN like CN= "John William" does not
> >make sense unless at the same time
> >all the upper DNs from the CAs are used or displayed. So if someone wants
>to
> >know
> >without any ambiguity who a signer is, it SHALL use of the sequence of DN
>up
> >to
> >a trust anchor of the signature policy.
> >
> >Since a signature policy may include more than one trust anchor, it
> >means that it SHALL NOT be allowed to define a signature policy that
> >uses two trust anchors with the same DN.
> >
> >COLLISIONS BETWEEN CRL ISSUER NAMES
> >
> >For CRLs, I have already mentioned the additional sentence that shall
> >be added to RFC 3280. It is copied again below  :
> >
> >"The full certification path that has been used to validate the target
> >certificate MUST also be used to validate the CRL issuer certificate ".
> >
> >
> >REPLY TO YOUR CONCLUSIONS
> >
> >As a reply to your conclusions: using path length constrains does not
> >solve the issue. Adding other constrains does not solve the issue
> >either. Using name constraints would
> >introduce an order of magnitude of complexity and would not be effective in
> >the general case.
> >Using certification policies and path length constrains might help, but
> >still do not solve
> >the problem in the general case.
> >
> >
> >Denis
> >
> >
> >>Ambiguity has recently become a hot topic on this list.  This is a
> >>really
> >>complicated issue, and I have personally had a great deal of trouble
> >>sorting out the real level of risk.  Some of the proposed changes would
> >>greatly impact current software, and these changes should only be
> >>contemplated if the risk is merits such change.
> >>
> >>So, I have spent a lot of time, off and on, thinking about ambiguity.
> >>I
> >>can't claim to have sorted it all out, but I have convinced myself that
>one
> >
> >>minor change is absolutely required, and that the current suite of
> >>mechanisms can virtually eliminate ambiguity in real PKIs.
> >>
> >>My thinking is appended to this message;  I apologize for its length,
> >>but
> >>to paraphrase Mark Twain, I simply don't have time to make this short and
> >>concise.  I have attempted to define ambiguity, characterize the ways
> >>ambiguity can enter into a PKI, and describe the set of mechanisms that
> >>mitigate this risk.
> >>
> >>Thanks,
> >>
> >>Tim Polk
> >>
> >>----------------------------------------------------------------------
> >>-
> >>---------------------------------------------------------
> >>
> >>              How ambiguous are names in actuality, and how important
> >> is it?
> >>
> >>I believe that X.509 expected assignment of unambiguous names based on
> >>a
> >>hierarchical system of naming authorities.  Whether you agree with that
> >>premise, it is safe to say that the global X.500 directory and its
> >>corresponding system of naming authorities do not exist. So, it may not be
>
> >>safe to assume that there are no name collisions whatsoever in all the DNs
>
> >>that appear in certificates and CRLs!  I am sure such collisions exist
> >>somewhere (although I haven't encountered any examples).  The real
>question
> >
> >>here is "What security risk does this situation present, and are the
> >>current mechanisms adequate to address this risk?"
> >>
> >>Let's recognize that the goal for PKIX is not to have globally
> >>unambiguous
> >>names, but to be able to obtain a trustworthy public key to establish a
> >>security service. Ambiguity in names is a problem when it causes the
> >>relying party to trust the wrong public key.
> >>
> >>There are two ways ambiguous names could cause problems.  First, I
> >>could
> >>accept public keys from two certificates as representing the same person
> >>based on the same subject name.  If these two certificates are bound to
> >>different individuals I may provide a service to the wrong party (or
> >>disclose confidential data, etc., etc.)  Second, I could accept a CRL to
> >>validate a particular certificate, based on the same issuer name in the
> >>certificate and CRL.  If the certificate and CRL were not actually issued
> >>by the same CA, then the relying party may obtain incorrect certificate
> >status.
> >>
> >>Note that both of these problems are in the context of path
> >>validation.
> >>If
> >>a name collision exists, but only one of the objects (e.g., certificate or
>
> >>CRL) validates for a given relying party, then there is no actual
>ambiguity
> >
> >>from that relying party's point of view.
> >>
> >>That is, assume two certificates exist with the same subject name but
> >>are
> >>bound to different people.  If Alice can only validate one of those
> >>certificates, there is no ambiguity in Alice's world.   Similarly, if Bob
> >>can only validate one of those certificates, there is no ambiguity in
>Bob's
> >
> >>world.   (It does not matter if Bob and Alice are validating the same
> >>certificate, or different ones!)   Similarly, if two CAs have the same
> >>issuer name, but Alice can only validate one, she can't accept the
> >>wrong
> >>CRL.  Ditto for Bob.
> >>
> >>So, ambiguity is a concern only in the context of path validation for
> >>a given relying party. This means that the mechanisms that are
> >>employed in path validation are relevant to when names are, and are
> >>not, ambiguous. I'd
> >
> >>also like to point out that path validation is always performed in the
> >>context of a particular trust anchor.  (A relying party may accept paths
> >>that begin with multiple trust anchors, but each specific path has a
>single
> >
> >>trust anchor.)  Seems irrelevant at the moment, but I will get back to
> >>it!
> >>
> >>Definition 1:  a Name N is unambiguous for a trust anchor T if and
> >>only
> >>if
> >>all certificates that validate for T and have the subject N refer to the
> >>same entity.
> >>
> >>Now, let's think about where name collisions can occur in the first
> >>place.
> >>There seems to be consensus that a single CA will not issue two
> >>certificates to two different entities with the same subject name.  So, if
>
> >>a single CA issues two certificates to "O=Microsoft, cn=John Wilson" they
> >>better relate to the same guy.  Similarly if a particular CA issues two
> >>certificates to "c=US, O=U.S. Government, OU=NIST, CN=CA1" then the
>subject
> >
> >>of both certificates must be the same CA.
> >>
> >>So, we are only worried about the case where two different CAs are
> >>trusted
> >>with respect to a trust anchor T and issue certificates to different
> >>subjects but use the same name.  So, when can name collisions occur
>between
> >
> >>CAs?  Or, better yet, under what conditions can we be sure name
> >>collisions
> >>won't occur?  Let's start with user certificates.
> >>
> >>In general, each CA that issues user certificates does so for a
> >>particular
> >>name space.  That is, all names assigned to users will be in a particular
> >>Directory Information Tree (DIT).   The CA will either work with a naming
> >>authority that it considers authoritative or may assume that function
> >>itself.   For example, the NIST CA only issues user certificates in the
> >>"C=US, O=U.S. Government, OU=NIST" DIT.   The NIST CA has been designated
> >>as our naming authority as well, so it keeps track of the names it
> >>assigns.  Similarly, the CA that supports NASA only issues certificates
>for
> >
> >>the name space "C=US,  O=U.S. Government, OU=NASA" DIT.
> >>
> >>These name spaces are disjoint, so name collisions cannot occur
> >>involving
> >>user certificates generated by the NASA and NIST CAs.  In fact, consider a
>
> >>PKI with trust anchor T and CAs C(1), C(2), ., C(n) issuing for name
>spaces
> >
> >>P(1), P(2), ., P(n).  If spaces P(1), P(2), ., P(n) are pairwise
> >>disjoint,
> >>name collisions cannot occur involving user certificates generated by
>C(1),
> >
> >>C(2), ., C(n).
> >>
> >>Case 1:  Consider a PKI with trust anchor T, and CAs C1, C2, and C3.
> >>C1,
> >>C2, and C3 issue end user certificates in the DITs N1, N2, and N3
> >>respectively.  If N1, N2, and N3 are pairwise disjoint, then the user
>names
> >
> >>are unambiguous with respect to T.
> >>
> >>In more complex PKIs, we may encounter situations where CAs issue user
> >>certificates for name spaces that overlap.  For example, in the U.S
> >>DoD's hierarchical PKI, CAs all issue certificates in the DIT "C=US,
> >>O=U.S. Government, OU=DOD".  Users routinely receive three
> >>certificates from two different CAs, so all the DoD CAs rely on a
> >>common naming authority to ensure that certificates with the same DNs
> >>are issued to the same person.
> >>
> >>Case 2: Consider a PKI with trust anchor T, and CAs C1, C2, and C3.
> >>C1,
> >>C2, and C3 issue end user certificates in the DITs N1, N2, and N3
> >>respectively.  N1 and N2 overlap, but N3 is disjoint from N1 and N2.   If
> >>CA1 and CA2 recognize the same naming authority, then the user names in
>the
> >
> >>PKI are unambiguous with respect to T.
> >>
> >>That is, if all the CAs either: (1) issue certificates in disjoint
> >>name spaces, or (2) issue certificates in shared name spaces based on
> >>a common naming authority, names will be unambiguous!
> >>
> >>Of course, CAs may issue CA certificates as well.  In this case, the
> >>CA does not assign the names, but rather uses the established name.
> >>This is trickier, since the name spaces for CA certificates overlaps
> >>but no naming authority exists.  It is still the responsibility of
> >>each CA to ensure that
> >
> >>there are no name collisions in CA certificates it issues!  This is
> >>not
> >>generally a problem, since we require names to be meaningful.  A CA should
>
> >>never issue a certificate to a CA with the DN "C=US, O=Coca Cola" unless
> >>the subject CA is associated with that company.  Similarly, if a CA issues
>
> >>certificates in the DIT "C=US, O=Coca Cola" then it must be associated
>with
> >
> >>the company!
> >>
> >>Of course, a rogue CA may masquerade under the wrong name, or issue
> >>certificates in a DIT it clearly has no right to use, but no decent CA
> >>will
> >
> >>cross certify with it.  Since we are interested in ambiguity with
> >>respect
> >>to a trust anchor, the behavior of a rogue CA is irrelevant.  Without
>cross
> >
> >>certification, no paths involving the rogue CA can be constructed.
> >>(Note
> >>that users installing the rogue as a trust anchor is out of scope here!)
> >>
> >>However, authority for a name space is not always crystal clear.
> >>Without a
> >>central naming authority, there is no clear title for a particular DIT.
>We
> >
> >>rely on heuristics that work nicely for large entities like Coca-Cola
> >>but
> >>may fail for smaller organizations.  For example, there may be a number of
>
> >>companies with variants on a particular name.  If the name space assumed
>by
> >
> >>an organization asserts "Orion" rather than "Orion Security" or "Orion
> >>Space Sciences", the name may be ambiguous without being blatantly
> >>false.  Each entity could reasonably assign user names in the "C=US,
> >>O=Orion" DIT.   If each organization established their CA with the name
> >>"C=US, O=Orion, CN=CA1" things could get really ugly.
> >>
> >>A trust anchor T may cross certify with two different CAs - say the
> >>ones
> >>from NIST and NASA.  Each of those CAs may have a relationship with an
> >>"Orion".  If each of them cross certifies with the Orion they know and
> >>love, we have an immediate name collision for a CA named "C=US, O=Orion,
> >>CN=CA1", and potentially name collisions for "C=US, O=Orion, CN=John
> >>Wilson", etc., etc.  Each CA has played by the rules, but names have just
> >>become ambiguous with respect to T.  This might be avoided if T is
>involved
> >
> >>in the policy decisions leading up to cross certification - but that
> >>is
> >>often NOT the case.
> >>
> >>Fortunately, we need not depend on policy alone.   Beyond the
> >>procedural/policy issues, there are some important mechanisms that
> >>help
> >>us
> >>with name space control.  Most significant are path length constraints and
>
> >>name constraints.  When trust anchor T issued those CA certificates, it
> >>probably wasn't expecting to accept transitive trust from those CAs, and
>it
> >
> >>certainly didn't expect to accept the NIST or NASA CA as authoritative
> >>for
> >>the "C=US, O=Orion" DIT.
> >>
> >>I listed path length constraints first because this mechanism provides
> >>the
> >>simplest and most widely available of our technical controls. Both NASA
>and
> >
> >>NIST use a single CA, rather than a mesh or hierarchy.  If the trust
> >>anchor
> >
> >>does not wish to leverage other cross certifications performed by NASA
> >>or
> >>NIST, it simply asserts a path length constraint of zero!  If T asserted
> >>this constraint for at least one of the NIST or NASA CAs, then the name
> >>"C=US, O=Orion, CN=John Wilson" is unambiguous. While this control was not
>
> >>designed exclusively for name space control, it does have the effect of
> >>prevenmting subsequent CAs from introducing unexpected name spaces.
> >>
> >>Unfortunately, this does not solve our problem for "C=US, O=Orion,
> >>CN=CA1".   This name remains ambiguous.  Even with a path length
> >>constraints of zero, a relying party can validate a CRL from either
> >>Orion CA.
> >>
> >>Name constraints is a more appealing technical mechanism, if less
> >>consistently available.  T can explicitly designate the name spaces it
> >>wishes to recognize in the cross certificate issued to NIST (or NASA).
> >>By asserting a permitted subtree of "C=US, O=U.S. Government, OU=NIST"
> >>with a SkipCerts of zero, certificates in the Orion name space are
> >>immediately eliminated.  This includes the offending CA certificate,
> >>so the "wrong" CRL
> >
> >>no longer validates.
> >>
> >>Case 3: Consider a PKI with trust anchor T, and CAs C1, C2, and C3.
> >>C1,
> >>C2, and C3 issue end user certificates in the DITs N1, N2, and N3
> >respectively.
> >>
> >>N1 and N2 are disjoint, but  N3 overlaps with N1 or N2.  C3 does not
> >>recognize the same naming authority as C1 or C2.   If name constraints
> >>permitted subtrees P3 is imposed in all cross certificates issued to
> >>C3,
> >>where N1, N2, and P3 are pairwise disjoint, then names are unambiguous
>with
> >
> >>respect to T.  (Names that could have collided are excluded from C3's
> >>DIT.)
> >>
> >>Conclusion/Proposal
> >>
> >>Ambiguity in names is a relatively minor risk with respect to a given
> >>trust
> >>anchor.  Ambiguity does not occur because of the actions of a single CA;
> >>rather it requires a combination of actions by different CAs within the
> >>infrastructure.  If all CA certificates accurately reflect the trust
> >>relationships between the CAs by incorporating appropriate path length and
>
> >>name constraints, these risks are greatly reduced if not eliminated.
> >>
> >>The risk of ambiguous names can be mitigated with a relatively simple
> >>modification in 3280bis, and the addition of some security
> >>considerations.  Most importantly, 32890bis should be modified to
> >>ensure that certificate and CRL validation are always performed with
> >>respect to the same trust anchor.  Security considerations should be
> >>added to highlight the risk of issuing CA certificates without
> >>appropriate constraints, and to caution application developers that
> >>trust anchor information should be considered when accepting
> >>certificates.
> >>
> >>The changes that I believe should be implemented are as follows:
> >>
> >>  (1) Modify section 6.3.3 to state that CRL validation MUST use the
> >>same
> >>trust anchor T specified in the corresponding certification path.
> >>
> >>(2) Add security considerations that indicate applications that accept
> >>multiple trust anchors should consider the trust anchor in access
> >>control decisions to ensure that names are unambiguous.
> >>
> >>(3) Add security considerations that explain the importance of
> >>consistent
> >>use of path length and name constraints in preventing name ambiguity.
> >>
> >>
> >
> >Regards,
> >
> >Denis Pinkas
> >
> >
> >

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 j6MHJULc063424; Fri, 22 Jul 2005 10:19: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 j6MHJU0Q063423; Fri, 22 Jul 2005 10:19:30 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from mail-eur1.microsoft.com (mail-eur1.microsoft.com [213.199.128.139]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6MHJTLc063412 for <ietf-pkix@imc.org>; Fri, 22 Jul 2005 10:19:29 -0700 (PDT) (envelope-from stefans@microsoft.com)
Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Jul 2005 18:19:23 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: RE: Re: Correction to be done to <draft-pinkas-pkix-conf-crl-validation-01.txt>
Date: Fri, 22 Jul 2005 18:19:23 +0100
Message-ID: <BF9309599A71984CAC5BAC5ECA62994402DC9A6D@EUR-MSG-11.europe.corp.microsoft.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: RE: Re: Correction to be done to <draft-pinkas-pkix-conf-crl-validation-01.txt>
Thread-Index: AcWO0iDDNBwRPfY9QWy8w4MsHUwSAgADFVZg
From: "Stefan Santesson" <stefans@microsoft.com>
To: "Denis Pinkas" <denis.pinkas@bull.net>, "Sharon Boeyen" <sharon.boeyen@entrust.com>, "David A. Cooper" <david.cooper@nist.gov>, "Santosh Chokhani" <chokhani@orionsec.com>
Cc: "pkix" <ietf-pkix@imc.org>
X-OriginalArrivalTime: 22 Jul 2005 17:19:23.0853 (UTC) FILETIME=[8154C7D0:01C58EE1]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j6MHJULc063418
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <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,

Make it simple?

In your simple case the CRL would not contain the name of the
certificate issuer anywhere!

Disregarding any increased security vulnerability due to decreased name
matching between cert and CRL, it would require change to existing code
to handle this new special case, introducing detection and special
handling of "delegated CRL".

That is NOT called making things simple. That is creating problems.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> -----Original Message-----
> From: owner-ietf-pkix@mail.imc.org
[mailto:owner-ietf-pkix@mail.imc.org]
> On Behalf Of Denis Pinkas
> Sent: den 22 juli 2005 08:38
> To: Sharon Boeyen; David A. Cooper; Santosh Chokhani
> Cc: 'pkix'
> Subject: Re: RE: Re: Correction to be done to
<draft-pinkas-pkix-conf-crl-
> validation-01.txt>
> 
> 
> 
> >Denis, I'm sorry but I really am not following your thought processes
at
> >all.
> 
> Sharon,
> 
> First, I appreciate the time you spent digging into the past.
> 
> Please forget about the vocabulary for a while, otherwise
> you will not follow my "thought process" that I will try to explain..
> 
> If you take the case of a simple scheme where a CRL Issuer accepts
> to issue revocation status information from only one CA, then from
> a RP point of view the certificate issuer CRL entry extension is not
> needed. By implication the indirect CRL boolean that signals the
> presence of that extension is not needed either.
> 
> Now, we can come back to the vocabulary issue:  since the indirectCRL
> boolean is not needed, I would not call that kind of CRL an indirect
CRL.
> 
> Using the rules that I have described in <draft-pinkas-pkix-conf-crl-
> validation-02.txt>,
> in sections 6.3.3.1 and 6.3.3.2, I believe it is possible to securely
> support that
> simple scheme, ... unless I made an error in them, but until now
nobody as
> yet
> demonstrated a case where these rules, *from a RP point of view*,
would be
> insufficient.
> 
> So why make things complicated, when they can be simple ?
> 
> >X.509 does include a definition for indirect CRLs. RFC 3280 is a
profile
> of
> >X.509 not a replacement for it. Therefore there is no need to
redefine
> terms
> >in 3280 that are defined in 509. There is no harm in clarifying terms
in
> >3280 if the group so chooses but a profile should not alter the
intent of
> a
> >definition.
> >
> >I take your point that the 509 definition says "authorities" instead
of
> >"authority or authorities". I have taken the time (a lot of it!!!) to
dig
> >through my files to track the history of that definition as I was the
> editor
> >of X.509 at the time it was added. (Sometimes I am happy that I'm
such a
> >packrat).
> >
> >The definition that has been quoted by David from X.509 was added as
an
> >outcome of the April 1999 meeting in Orlando Florida. It was part of
the
> >resolution of Canadian comment number 24 submitted to that meeting
> against
> >the X.509 PDAM. The relevant part of the disposition of that comment
was
> >recorded as "Accepted with a few minor modifications to the proposed
> text.
> >Also a definition for indirect CRL will be added." I was the author
of
> the
> >Canadian comment submitted to that meeting and I was also the editor
that
> >created the definition that is now in X.509 as a result of that
comment
> >disposition. Let me assure you that with both hats on it WAS my
intention
> >that any CRL that included revocation notices for certificates that
were
> >issued by any authority other than that which issued the CRL is an
> indirect
> >CRL.
> 
> On my side, my understanding was as I explained. Only when the CRL
covers
> certificates from more than one CA, are both the certificate issuer
CRL
> entry extension
> needed and the indirectCRL boolean needed. In RFC 3280 the
requirements
> for
> these two fields are in two consecutive sentences within the same
short
> paragraph
> so why I believe(d) they come together.
> 
> I hope that this allows at least you to understand my thought process,
> even if
> you have a different opinion.
> 
> Denis
> 
> > I will be happy to submit a defect report to X.509 to change
> >"authorities" to "authority or authorities". As the editor and the
> submitter
> >of the ballot comment that drove the discussion to add the definition
in
> the
> >first place I will happily admit I made an error in using the term
> >"authorities" in that definition.
> >
> >Cheers,
> >Sharon
> >
> >-----Original Message-----
> >From: owner-ietf-pkix@mail.imc.org
[mailto:owner-ietf-pkix@mail.imc.org]
> On
> >Behalf Of Denis Pinkas
> >Sent: Thursday, July 21, 2005 10:34 AM
> >To: David A. Cooper; Santosh Chokhani
> >Cc: 'pkix'
> >Subject: Re: Re: Correction to be done to
> ><draft-pinkas-pkix-conf-crl-validation-01.txt>
> >
> >
> >
> >David,
> >
> >>Santosh Chokhani wrote:
> >>
> >>>Denis,
> >>>
> >>>A sentence in 3280 may be ambiguous. The definition and State
Machines
> >>>are not at odds. Also, if you point to the specific location of the
> >>>sentence in 3280, I will be happy to determine if this is being
taken
> >>>out of context or not.
> >
> >>Santosh,
> >
> >>Denis is referring to the final sentence in the following paragraph:
> >
> >>      CRL issuers issue CRLs.  The CRL issuer is either the CA or an
> entity
> >>      that has been authorized by the CA to issue CRLS.  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.
> >
> >>I believe the problem is that Denis is interpreting this sentence as
a
> >>definition when it is not one.  Here is the definition of indirect
CRL
> >>in X.509:
> >
> >You mean that RFC 3280 contains no formal definition of what an
> >Indirect CRL is.
> >
> >A good practice for RFCs would be to follow ISO editing rules where
> >there MUST be a separate section for formal definitions.  :-)
> >
> >However the extracted sentence is the earliest use of the wording
> "indirect
> >CRL"
> >in the document saying what an indirect CRL is. It is not explained
later
> >on.
> >
> >The definition from X.509 you mention is thus not an RFC 3280
definition.
> >
> >>      indirect CRL (iCRL):  A revocation list that at least contains
> >>revocation information
> >>      about certificates issued by authorities other than that which
> >>issued this CRL.
> >
> >The X.509 definition is NOT :
> >
> >indirect CRL (iCRL):  A revocation list that at least contains
revocation
> >information
> >about certificates issued by *an authority* other than that which
issued
> >this CRL.
> >
> >The X.509 definition is NOT either:
> >
> >indirect CRL (iCRL):  A revocation list that at least contains
revocation
> >information
> >about certificates issued by *one or more* authorities other than
that
> which
> >issued
> >this CRL.
> >
> >>In order to help avoid this confusion in 3280bis, I have removed the
> >>sentence "Whenever ...." from 3280bis draft -01 and have added the
> >>following paragraph:
> >>
> >>      If the scope of the CRL includes one or more certificates
issued
> by
> >>      an entity other than the CRL issuer, then it is an indirect
CRL.
> >
> >Arhh!  Once again: "certificates issued by .. CRL issuer".
> >
> >>      The
> >>      scope of an indirect CRL may be limited to certificates issued
by
> a
> >>      single CA or may include certificates issued by multiple CAs.
> >
> >This would have been true if the X.509 definition had been written
> >differently.
> >
> >>      If the
> >>      issuer of the indirect CRL is a CA, then the scope of the
indirect
> >>      CRL MAY include certificates issued by the issuer of the CRL.
> >
> >This is ruled out by the current quoted sentence.
> >
> >>I believe that this text is fully consistent with the X.509
definition
> >>of indirect CRL
> >
> >Sorry, it is not.
> >
> >> as well as the descriptions of the indirectCRL flag and
> >>the certificateIssuer CRL entry extension in both X.509 and RFC 3280
and
> >>the algorithm in section 6.3.3 of RFC 3280.
> >
> >Page 59 is stating:
> >
> >   "The CRL issuer MUST assert the indirectCRL boolean, if the scope
of
> >   the CRL includes certificates issued by authorities other than the
> >   CRL issuer.  The authority responsible for each entry is indicated
by
> >   the certificate issuer CRL entry extension (section 5.3.4)".
> >
> >It is clear that this flag is present when there are certificate
issuer
> CRL
> >entry extensions.
> >
> >Thus, in the simplest case, where a CA designates another entity to
issue
> >revocation
> >status information for some of its certificates, the certificate
issuer
> CRL
> >entry extension
> >is not needed, neither the indirectCRL boolean.
> >
> >The way to fix the problem is simple: either adopt (but add "may")
the
> >definition of X.509
> >or make it clearer by saying:
> >
> >indirect CRL (iCRL):  A revocation list that at least *may* contain
> >revocation information
> >about certificates issued by more than one CA.
> >
> >and add for clarification:
> >
> >delegatedCRL (dCRL):  A revocation list issued by a CRL Issuer that
> received
> >and accepted
> >a delegation for issuing revocation status information from a single
CA,
> >that contains
> >revocation information about certificates issued by that single CA.
> >
> >See processing details for these two cases in
> ><draft-pinkas-pkix-conf-crl-validation-02.txt>
> >that is now available.
> >
> >The benefits are:
> >
> > 1) a very simple CRL processing when the CRL contains revocation
> >information
> >    about certificates from a single CA.
> >
> > 2) a (much) more complex CRL processing when the CRL contains
revocation
> >    information about certificates from more than one CA, including
the
> >(seldom ?)
> >    case where the CRL issuer is also a CA.
> >
> >Denis
> >
> >>Dave
> 
> 

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 j6MGpFN4060617; Fri, 22 Jul 2005 09:51: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 j6MGpFLi060616; Fri, 22 Jul 2005 09:51:15 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from mail-eur1.microsoft.com (mail-eur1.microsoft.com [213.199.128.139]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6MGpDq1060601 for <ietf-pkix@imc.org>; Fri, 22 Jul 2005 09:51:13 -0700 (PDT) (envelope-from stefans@microsoft.com)
Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Jul 2005 17:51:08 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: RE: draft-pinkas-pkix-conf-crl-validation-02.txt is available
Date: Fri, 22 Jul 2005 17:51:04 +0100
Message-ID: <BF9309599A71984CAC5BAC5ECA62994402DC9A41@EUR-MSG-11.europe.corp.microsoft.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: RE: draft-pinkas-pkix-conf-crl-validation-02.txt is available
Thread-Index: AcWO0GeUYB6+QKeFR7ik5opYtFX1sgACw5qw
From: "Stefan Santesson" <stefans@microsoft.com>
To: "Denis Pinkas" <denis.pinkas@bull.net>, "pkix" <ietf-pkix@imc.org>, "Manger, James H" <James.H.Manger@team.telstra.com>
X-OriginalArrivalTime: 22 Jul 2005 16:51:08.0069 (UTC) FILETIME=[8E90AD50:01C58EDD]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j6MGpEq1060607
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

> However from a RP point of view, in the case the CRL contains
certificates
> from a single CA, if this field is present *but no test is made on
it*,
> would you
> be able to provide an example where the algorithm would give the wrong
> result  ?

Yes,

Consider a CA that provides partitioned CRLs where each CRL only covers
a limited number of the issued certificates. This could be partitioned
by issuing key, serial number range, certificate policy or anything
(except reason code).

I now rename one of the CRLs that does NOT cover my revoked certificate
and manage to replace it with the one that would indicate that my
certificate is revoked.

Since you don't check the IDP you will miss the fact that the CRL has
been renamed and replaced and you will accept my certificate as valid.

So you have now completely changed the trust model to force the RP to
trust the directory to provide the correct partitioned CRL. This is a
severe security flaw.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> -----Original Message-----
> From: owner-ietf-pkix@mail.imc.org
[mailto:owner-ietf-pkix@mail.imc.org]
> On Behalf Of Denis Pinkas
> Sent: den 22 juli 2005 08:30
> To: pkix; Manger, James H
> Subject: Re: RE: draft-pinkas-pkix-conf-crl-validation-02.txt is
available
> 
> 
> James,
> 
> >Denis,
> 
> >By ignoring the IDP.indirectCRL flag your rules can give the wrong
result
> >by accepting a CRL that does not apply to a given certificate.
> 
> If the CRL issuer is only "working" on behalf of a single CA, I do not
> think so.
> Otherwise, would you provide an example where the result would be
wrong ?
> 
> >Consider a certificate that has a CRL-DP extension with a cRLIssuer
field
> >and consider a CRL without an IDP extension from that cRLIssuer.
> 
> >Your rules say that the CRL covers the certificate (ie would list the
> certificate
> >if it was revoked), but it does not cover it.  The CRL (without IDP)
only
> covers
> >certificates issued by the authority that issued the CRL.
> 
> Here are some extracts from 3280bis :
> 
> Page 51:
> 
>    CRL issuers issue CRLs.  The CRL issuer is either the CA or an
entity
>    that has been authorized by the CA to issue CRLs.
> 
> Page 62:
> 
>    If the distributionPoint field is absent, the CRL MUST contain
>    entries for all revoked unexpired certificates issued by the CRL
>    issuer, if any, within the scope of the CRL.
> 
> Your comment applies since the only case where a CRL issuer
> may issue certificates is when it is also a CA.
> 
> This sentence then mandates CRL Issuers to support the
distributionPoint
> field present.
> 
> However from a RP point of view, in the case the CRL contains
certificates
> from a single CA, if this field is present *but no test is made on
it*,
> would you
> be able to provide an example where the algorithm would give the wrong
> result  ?
> 
> >Only when IDP.indirectCRL is true must the CRL issuer "ensure that
> >the CRL is complete in that it contains all revocation entries ...
from
> all
> >authorities that identify this CRL in their certificates" [X.509,
8.6.2.2
> IDP extension].
> 
> The word 'issuer' is missing. The exact sentence is:
> 
> If indirectCRL is true, [..] it is the responsibility of the CRL
issuer to
> ensure that
> the CRL is complete in that it contains all revocation entries [...]
from
> all authorities
> that identify this CRL *issuer* in their certificates.
> 
> 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 j6MGVJx4058102; Fri, 22 Jul 2005 09:31: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 j6MGVJP0058101; Fri, 22 Jul 2005 09:31:19 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from mail-eur1.microsoft.com (mail-eur1.microsoft.com [213.199.128.139]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6MGVH5f058080 for <ietf-pkix@imc.org>; Fri, 22 Jul 2005 09:31:17 -0700 (PDT) (envelope-from stefans@microsoft.com)
Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Jul 2005 17:31:11 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: RE: Re: Correction to be done to <draft-pinkas-pkix-conf-crl-validation-01.txt>
Date: Fri, 22 Jul 2005 17:31:06 +0100
Message-ID: <BF9309599A71984CAC5BAC5ECA62994402DC9A31@EUR-MSG-11.europe.corp.microsoft.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: RE: Re: Correction to be done to <draft-pinkas-pkix-conf-crl-validation-01.txt>
Thread-Index: AcWOy5olOTke9whIR5+EPrpMo6zlvQABubkQ
From: "Stefan Santesson" <stefans@microsoft.com>
To: "Denis Pinkas" <denis.pinkas@bull.net>, "Santosh Chokhani" <chokhani@orionsec.com>, "David A. Cooper" <david.cooper@nist.gov>
Cc: "pkix" <ietf-pkix@imc.org>
X-OriginalArrivalTime: 22 Jul 2005 16:31:11.0787 (UTC) FILETIME=[C58687B0:01C58EDA]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j6MGVI5f058095
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <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,

Your proposal is NOT simpler, NOT easier to implement and impose a
severe change of semantics which would require a new extension OID for
the IDP extension.

That's why I have a hard time taking this as a serious proposal.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> -----Original Message-----
> From: Denis Pinkas [mailto:denis.pinkas@bull.net]
> Sent: den 22 juli 2005 08:44
> To: Santosh Chokhani; David A. Cooper; Stefan Santesson
> Cc: pkix
> Subject: Re: RE: Re: Correction to be done to
<draft-pinkas-pkix-conf-crl-
> validation-01.txt>
> 
> Stefan,
> 
> >Denis,
> 
> >Quote:
> >"Thus, in the simplest case, where a CA designates another entity to
> >issue revocation status information for some of its certificates, the
> >certificate issuer CRL entry extension is not needed, neither the
> >indirectCRL boolean."
> 
> >I can't believe you are serious about this!
> >You are just trying to drive us mad, right?
> 
> >How much more "indirect" can it be?
> 
> Everything is a matter of wording. I would not call it "indirect".
> See my explanations to Sharon.
> 
> If a name was needed for it, I would call it "delegated CRL"
> 
> Page 7:
> 
> CRL issuer: an optional system to which a CA delegates the
>                  publication of certificate revocation lists.
> 
> "Problems" with CRLs arise only when CRLs contain revocation
> status information about certificates from several CAs.
> 
> The point is not simply a vocabulary problem, but that that it is
> possible *for a RP* to support CRLs issued by CRL Issuers that
> are not CAs, without the need to support the indirectCRL boolean
> and the certificate issuer CRL entry extension and this makes the
> algorithm simpler, easier to implement, faster, etc ...
> 
> Denis
> 
> >/Stefan
> >
> >
> >> -----Original Message-----
> >> From: owner-ietf-pkix@mail.imc.org
> >[mailto:owner-ietf-pkix@mail.imc.org]
> >> On Behalf Of Denis Pinkas
> >> Sent: den 21 juli 2005 07:34
> >> To: David A. Cooper; Santosh Chokhani
> >> Cc: 'pkix'
> >> Subject: Re: Re: Correction to be done to
<draft-pinkas-pkix-conf-crl-
> >> validation-01.txt>
> >>
> >>
> >> David,
> >>
> >> >Santosh Chokhani wrote:
> >> >
> >> >>Denis,
> >> >>
> >> >>A sentence in 3280 may be ambiguous. The definition and State
> >Machines
> >> are
> >> >>not at odds. Also, if you point to the specific location of the
> >sentence
> >> in
> >> >>3280, I will be happy to determine if this is being taken out of
> >context
> >> or
> >> >>not.
> >>
> >> >Santosh,
> >>
> >> >Denis is referring to the final sentence in the following
paragraph:
> >>
> >> >      CRL issuers issue CRLs.  The CRL issuer is either the CA or
an
> >> entity
> >> >      that has been authorized by the CA to issue CRLS.  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.
> >>
> >> >I believe the problem is that Denis is interpreting this sentence
as
> >a
> >> >definition when it is not one.  Here is the definition of indirect
> >CRL
> >> >in X.509:
> >>
> >> You mean that RFC 3280 contains no formal definition of what an
> >> Indirect CRL is.
> >>
> >> A good practice for RFCs would be to follow ISO editing rules where
> >> there MUST be a separate section for formal definitions.  :-)
> >>
> >> However the extracted sentence is the earliest use of the wording
> >> "indirect CRL"
> >> in the document saying what an indirect CRL is. It is not explained
> >later
> >> on.
> >>
> >> The definition from X.509 you mention is thus not an RFC 3280
> >definition.
> >>
> >> >      indirect CRL (iCRL):  A revocation list that at least
contains
> >> >revocation information
> >> >      about certificates issued by authorities other than that
which
> >> >issued this CRL.
> >>
> >> The X.509 definition is NOT :
> >>
> >> indirect CRL (iCRL):  A revocation list that at least contains
> >revocation
> >> information
> >> about certificates issued by *an authority* other than that which
> >issued
> >> this CRL.
> >>
> >> The X.509 definition is NOT either:
> >>
> >> indirect CRL (iCRL):  A revocation list that at least contains
> >revocation
> >> information
> >> about certificates issued by *one or more* authorities other than
that
> >> which issued
> >> this CRL.
> >>
> >> >In order to help avoid this confusion in 3280bis, I have removed
the
> >> >sentence "Whenever ...." from 3280bis draft -01 and have added the
> >> >following paragraph:
> >> >
> >> >      If the scope of the CRL includes one or more certificates
> >issued by
> >> >      an entity other than the CRL issuer, then it is an indirect
> >CRL.
> >>
> >> Arhh!  Once again: "certificates issued by .. CRL issuer".
> >>
> >> >      The
> >> >      scope of an indirect CRL may be limited to certificates
issued
> >by a
> >> >      single CA or may include certificates issued by multiple
CAs.
> >>
> >> This would have been true if the X.509 definition had been written
> >> differently.
> >>
> >> >      If the
> >> >      issuer of the indirect CRL is a CA, then the scope of the
> >indirect
> >> >      CRL MAY include certificates issued by the issuer of the
CRL.
> >>
> >> This is ruled out by the current quoted sentence.
> >>
> >> >I believe that this text is fully consistent with the X.509
> >definition
> >> >of indirect CRL
> >>
> >> Sorry, it is not.
> >>
> >> > as well as the descriptions of the indirectCRL flag and
> >> >the certificateIssuer CRL entry extension in both X.509 and RFC
3280
> >and
> >> >the algorithm in section 6.3.3 of RFC 3280.
> >>
> >> Page 59 is stating:
> >>
> >>    "The CRL issuer MUST assert the indirectCRL boolean, if the
scope
> >of
> >>    the CRL includes certificates issued by authorities other than
the
> >>    CRL issuer.  The authority responsible for each entry is
indicated
> >by
> >>    the certificate issuer CRL entry extension (section 5.3.4)".
> >>
> >> It is clear that this flag is present when there are certificate
> >issuer
> >> CRL entry extensions.
> >>
> >> Thus, in the simplest case, where a CA designates another entity to
> >issue
> >> revocation
> >> status information for some of its certificates, the certificate
> >issuer
> >> CRL entry extension
> >> is not needed, neither the indirectCRL boolean.
> >>
> >> The way to fix the problem is simple: either adopt (but add "may")
the
> >> definition of X.509
> >> or make it clearer by saying:
> >>
> >> indirect CRL (iCRL):  A revocation list that at least *may* contain
> >> revocation information
> >> about certificates issued by more than one CA.
> >>
> >> and add for clarification:
> >>
> >> delegatedCRL (dCRL):  A revocation list issued by a CRL Issuer that
> >> received and accepted
> >> a delegation for issuing revocation status information from a
single
> >CA,
> >> that contains
> >> revocation information about certificates issued by that single CA.
> >>
> >> See processing details for these two cases in
> ><draft-pinkas-pkix-conf-crl-
> >> validation-02.txt>
> >> that is now available.
> >>
> >> The benefits are:
> >>
> >>  1) a very simple CRL processing when the CRL contains revocation
> >> information
> >>     about certificates from a single CA.
> >>
> >>  2) a (much) more complex CRL processing when the CRL contains
> >revocation
> >>     information about certificates from more than one CA, including
> >the
> >> (seldom ?)
> >>     case where the CRL issuer is also a CA.
> >>
> >> Denis
> >>
> >> >Dave
> 
> 

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 j6MF1gYW049209; Fri, 22 Jul 2005 08:01: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 j6MF1gmQ049208; Fri, 22 Jul 2005 08:01:42 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from smtp.cs.tcd.ie (relay.cs.tcd.ie [134.226.32.56]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6MF1eij049200 for <ietf-pkix@imc.org>; Fri, 22 Jul 2005 08:01:41 -0700 (PDT) (envelope-from stephen.farrell@cs.tcd.ie)
Received: from smtp.cs.tcd.ie (localhost [127.0.0.1]) by relay.cs.tcd.ie (Postfix) with ESMTP id B5F424D5E; Fri, 22 Jul 2005 16:01:39 +0100 (IST)
Received: from [127.0.0.1] (sfarrel2.dsg.cs.tcd.ie [134.226.36.26]) by smtp.cs.tcd.ie (Postfix) with ESMTP id 8D2D0307E; Fri, 22 Jul 2005 16:01:39 +0100 (IST)
Message-ID: <42E10BA2.7010700@cs.tcd.ie>
Date: Fri, 22 Jul 2005 16:07:14 +0100
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Denis Pinkas <denis.pinkas@bull.net>
Cc: Santosh Chokhani <chokhani@orionsec.com>, "David A. Cooper" <david.cooper@nist.gov>, Stefan Santesson <stefans@microsoft.com>, pkix <ietf-pkix@imc.org>
Subject: Re: Correction to be done to <draft-pinkas-pkix-conf-crl-validation-01.txt>
References: <OF7C322960.781ADF98-ONC1257046.0050E35A@frcl.bull.fr>
In-Reply-To: <OF7C322960.781ADF98-ONC1257046.0050E35A@frcl.bull.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>

Denis,

> The point is not simply a vocabulary problem, but that that it is 
> possible *for a RP* to support CRLs issued by CRL Issuers that 
> are not CAs, without the need to support the indirectCRL boolean 
> and the certificate issuer CRL entry extension and this makes the 
> algorithm simpler, easier to implement, faster, etc ...

I think this'd be a bad idea. Aside from anything else, it
assumes that some relationships between certificate and
CRL issuers won't change over time. Those do change and if
this were adopted the RP's wouldn't have a way to easily
see that.

Stephen.

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 j6MEgbxa047386; Fri, 22 Jul 2005 07: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 j6MEgbZo047385; Fri, 22 Jul 2005 07:42:37 -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 j6MEgaIR047354 for <ietf-pkix@imc.org>; Fri, 22 Jul 2005 07:42:36 -0700 (PDT) (envelope-from denis.pinkas@bull.net)
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA23166; Fri, 22 Jul 2005 16:58:23 +0200
Received: from frcls4013 ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with SMTP id 2005072216433081:1342 ; Fri, 22 Jul 2005 16:43:30 +0200 
Date: Fri, 22 Jul 2005 16:43:40 +0100
From: "Denis Pinkas" <denis.pinkas@bull.net>
To: "Santosh Chokhani" <chokhani@orionsec.com>, "David A. Cooper" <david.cooper@nist.gov>, "Stefan Santesson" <stefans@microsoft.com>
Cc: "pkix" <ietf-pkix@imc.org>
Subject: Re: RE: Re: Correction to be done to <draft-pinkas-pkix-conf-crl-validation-01.txt>
X-mailer: Foxmail 5.0 [-fr-]
Mime-Version: 1.0
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 22/07/2005 16:43:31, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 22/07/2005 16:43:32, Serialize complete at 22/07/2005 16:43:32
Message-ID: <OF7C322960.781ADF98-ONC1257046.0050E35A@frcl.bull.fr>
Content-Transfer-Encoding: 7bit
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>

Stefan,

>Denis,

>Quote:
>"Thus, in the simplest case, where a CA designates another entity to
>issue revocation status information for some of its certificates, the
>certificate issuer CRL entry extension is not needed, neither the
>indirectCRL boolean."

>I can't believe you are serious about this!
>You are just trying to drive us mad, right?

>How much more "indirect" can it be?

Everything is a matter of wording. I would not call it "indirect". 
See my explanations to Sharon.

If a name was needed for it, I would call it "delegated CRL" 

Page 7:

CRL issuer: an optional system to which a CA delegates the
                 publication of certificate revocation lists.

"Problems" with CRLs arise only when CRLs contain revocation 
status information about certificates from several CAs.

The point is not simply a vocabulary problem, but that that it is 
possible *for a RP* to support CRLs issued by CRL Issuers that 
are not CAs, without the need to support the indirectCRL boolean 
and the certificate issuer CRL entry extension and this makes the 
algorithm simpler, easier to implement, faster, etc ...

Denis 

>/Stefan
> 
>
>> -----Original Message-----
>> From: owner-ietf-pkix@mail.imc.org
>[mailto:owner-ietf-pkix@mail.imc.org]
>> On Behalf Of Denis Pinkas
>> Sent: den 21 juli 2005 07:34
>> To: David A. Cooper; Santosh Chokhani
>> Cc: 'pkix'
>> Subject: Re: Re: Correction to be done to <draft-pinkas-pkix-conf-crl-
>> validation-01.txt>
>> 
>> 
>> David,
>> 
>> >Santosh Chokhani wrote:
>> >
>> >>Denis,
>> >>
>> >>A sentence in 3280 may be ambiguous. The definition and State
>Machines
>> are
>> >>not at odds. Also, if you point to the specific location of the
>sentence
>> in
>> >>3280, I will be happy to determine if this is being taken out of
>context
>> or
>> >>not.
>> 
>> >Santosh,
>> 
>> >Denis is referring to the final sentence in the following paragraph:
>> 
>> >      CRL issuers issue CRLs.  The CRL issuer is either the CA or an
>> entity
>> >      that has been authorized by the CA to issue CRLS.  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.
>> 
>> >I believe the problem is that Denis is interpreting this sentence as
>a
>> >definition when it is not one.  Here is the definition of indirect
>CRL
>> >in X.509:
>> 
>> You mean that RFC 3280 contains no formal definition of what an
>> Indirect CRL is.
>> 
>> A good practice for RFCs would be to follow ISO editing rules where
>> there MUST be a separate section for formal definitions.  :-)
>> 
>> However the extracted sentence is the earliest use of the wording
>> "indirect CRL"
>> in the document saying what an indirect CRL is. It is not explained
>later
>> on.
>> 
>> The definition from X.509 you mention is thus not an RFC 3280
>definition.
>> 
>> >      indirect CRL (iCRL):  A revocation list that at least contains
>> >revocation information
>> >      about certificates issued by authorities other than that which
>> >issued this CRL.
>> 
>> The X.509 definition is NOT :
>> 
>> indirect CRL (iCRL):  A revocation list that at least contains
>revocation
>> information
>> about certificates issued by *an authority* other than that which
>issued
>> this CRL.
>> 
>> The X.509 definition is NOT either:
>> 
>> indirect CRL (iCRL):  A revocation list that at least contains
>revocation
>> information
>> about certificates issued by *one or more* authorities other than that
>> which issued
>> this CRL.
>> 
>> >In order to help avoid this confusion in 3280bis, I have removed the
>> >sentence "Whenever ...." from 3280bis draft -01 and have added the
>> >following paragraph:
>> >
>> >      If the scope of the CRL includes one or more certificates
>issued by
>> >      an entity other than the CRL issuer, then it is an indirect
>CRL.
>> 
>> Arhh!  Once again: "certificates issued by .. CRL issuer".
>> 
>> >      The
>> >      scope of an indirect CRL may be limited to certificates issued
>by a
>> >      single CA or may include certificates issued by multiple CAs.
>> 
>> This would have been true if the X.509 definition had been written
>> differently.
>> 
>> >      If the
>> >      issuer of the indirect CRL is a CA, then the scope of the
>indirect
>> >      CRL MAY include certificates issued by the issuer of the CRL.
>> 
>> This is ruled out by the current quoted sentence.
>> 
>> >I believe that this text is fully consistent with the X.509
>definition
>> >of indirect CRL
>> 
>> Sorry, it is not.
>> 
>> > as well as the descriptions of the indirectCRL flag and
>> >the certificateIssuer CRL entry extension in both X.509 and RFC 3280
>and
>> >the algorithm in section 6.3.3 of RFC 3280.
>> 
>> Page 59 is stating:
>> 
>>    "The CRL issuer MUST assert the indirectCRL boolean, if the scope
>of
>>    the CRL includes certificates issued by authorities other than the
>>    CRL issuer.  The authority responsible for each entry is indicated
>by
>>    the certificate issuer CRL entry extension (section 5.3.4)".
>> 
>> It is clear that this flag is present when there are certificate
>issuer
>> CRL entry extensions.
>> 
>> Thus, in the simplest case, where a CA designates another entity to
>issue
>> revocation
>> status information for some of its certificates, the certificate
>issuer
>> CRL entry extension
>> is not needed, neither the indirectCRL boolean.
>> 
>> The way to fix the problem is simple: either adopt (but add "may") the
>> definition of X.509
>> or make it clearer by saying:
>> 
>> indirect CRL (iCRL):  A revocation list that at least *may* contain
>> revocation information
>> about certificates issued by more than one CA.
>> 
>> and add for clarification:
>> 
>> delegatedCRL (dCRL):  A revocation list issued by a CRL Issuer that
>> received and accepted
>> a delegation for issuing revocation status information from a single
>CA,
>> that contains
>> revocation information about certificates issued by that single CA.
>> 
>> See processing details for these two cases in
><draft-pinkas-pkix-conf-crl-
>> validation-02.txt>
>> that is now available.
>> 
>> The benefits are:
>> 
>>  1) a very simple CRL processing when the CRL contains revocation
>> information
>>     about certificates from a single CA.
>> 
>>  2) a (much) more complex CRL processing when the CRL contains
>revocation
>>     information about certificates from more than one CA, including
>the
>> (seldom ?)
>>     case where the CRL issuer is also a CA.
>> 
>> Denis
>> 
>> >Dave

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 j6MEaeq9046772; Fri, 22 Jul 2005 07:36: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 j6MEaeri046771; Fri, 22 Jul 2005 07:36: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 j6MEacuh046761 for <ietf-pkix@imc.org>; Fri, 22 Jul 2005 07:36:38 -0700 (PDT) (envelope-from denis.pinkas@bull.net)
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA43060; Fri, 22 Jul 2005 16:52:12 +0200
Received: from frcls4013 ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with SMTP id 2005072216372172:1336 ; Fri, 22 Jul 2005 16:37:21 +0200 
Date: Fri, 22 Jul 2005 16:37:31 +0100
From: "Denis Pinkas" <denis.pinkas@bull.net>
To: "Sharon Boeyen" <sharon.boeyen@entrust.com>, "David A. Cooper" <david.cooper@nist.gov>, "Santosh Chokhani" <chokhani@orionsec.com>
Cc: "'pkix'" <ietf-pkix@imc.org>
Subject: Re: RE: Re: Correction to be done to <draft-pinkas-pkix-conf-crl-validation-01.txt>
X-mailer: Foxmail 5.0 [-fr-]
Mime-Version: 1.0
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 22/07/2005 16:37:21, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 22/07/2005 16:37:23, Serialize complete at 22/07/2005 16:37:23
Message-ID: <OFCD36C8D2.3317C595-ONC1257046.00505330@frcl.bull.fr>
Content-Transfer-Encoding: 7bit
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>

>Denis, I'm sorry but I really am not following your thought processes at
>all. 

Sharon,

First, I appreciate the time you spent digging into the past. 

Please forget about the vocabulary for a while, otherwise 
you will not follow my "thought process" that I will try to explain..

If you take the case of a simple scheme where a CRL Issuer accepts 
to issue revocation status information from only one CA, then from 
a RP point of view the certificate issuer CRL entry extension is not 
needed. By implication the indirect CRL boolean that signals the 
presence of that extension is not needed either. 

Now, we can come back to the vocabulary issue:  since the indirectCRL 
boolean is not needed, I would not call that kind of CRL an indirect CRL.

Using the rules that I have described in <draft-pinkas-pkix-conf-crl-validation-02.txt>, 
in sections 6.3.3.1 and 6.3.3.2, I believe it is possible to securely support that 
simple scheme, ... unless I made an error in them, but until now nobody as yet 
demonstrated a case where these rules, *from a RP point of view*, would be insufficient.

So why make things complicated, when they can be simple ?

>X.509 does include a definition for indirect CRLs. RFC 3280 is a profile of
>X.509 not a replacement for it. Therefore there is no need to redefine terms
>in 3280 that are defined in 509. There is no harm in clarifying terms in
>3280 if the group so chooses but a profile should not alter the intent of a
>definition. 
>
>I take your point that the 509 definition says "authorities" instead of
>"authority or authorities". I have taken the time (a lot of it!!!) to dig
>through my files to track the history of that definition as I was the editor
>of X.509 at the time it was added. (Sometimes I am happy that I'm such a
>packrat).
>
>The definition that has been quoted by David from X.509 was added as an
>outcome of the April 1999 meeting in Orlando Florida. It was part of the
>resolution of Canadian comment number 24 submitted to that meeting against
>the X.509 PDAM. The relevant part of the disposition of that comment was
>recorded as "Accepted with a few minor modifications to the proposed text.
>Also a definition for indirect CRL will be added." I was the author of the
>Canadian comment submitted to that meeting and I was also the editor that
>created the definition that is now in X.509 as a result of that comment
>disposition. Let me assure you that with both hats on it WAS my intention
>that any CRL that included revocation notices for certificates that were
>issued by any authority other than that which issued the CRL is an indirect
>CRL. 

On my side, my understanding was as I explained. Only when the CRL covers 
certificates from more than one CA, are both the certificate issuer CRL entry extension 
needed and the indirectCRL boolean needed. In RFC 3280 the requirements for 
these two fields are in two consecutive sentences within the same short paragraph 
so why I believe(d) they come together.

I hope that this allows at least you to understand my thought process, even if 
you have a different opinion.

Denis

> I will be happy to submit a defect report to X.509 to change
>"authorities" to "authority or authorities". As the editor and the submitter
>of the ballot comment that drove the discussion to add the definition in the
>first place I will happily admit I made an error in using the term
>"authorities" in that definition. 
>
>Cheers,
>Sharon
>
>-----Original Message-----
>From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On
>Behalf Of Denis Pinkas
>Sent: Thursday, July 21, 2005 10:34 AM
>To: David A. Cooper; Santosh Chokhani
>Cc: 'pkix'
>Subject: Re: Re: Correction to be done to
><draft-pinkas-pkix-conf-crl-validation-01.txt>
>
>
>
>David,
>
>>Santosh Chokhani wrote:
>>
>>>Denis,
>>>
>>>A sentence in 3280 may be ambiguous. The definition and State Machines 
>>>are not at odds. Also, if you point to the specific location of the 
>>>sentence in 3280, I will be happy to determine if this is being taken 
>>>out of context or not.
>
>>Santosh,
>
>>Denis is referring to the final sentence in the following paragraph:
>
>>      CRL issuers issue CRLs.  The CRL issuer is either the CA or an entity
>>      that has been authorized by the CA to issue CRLS.  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.
>
>>I believe the problem is that Denis is interpreting this sentence as a
>>definition when it is not one.  Here is the definition of indirect CRL 
>>in X.509:
>
>You mean that RFC 3280 contains no formal definition of what an 
>Indirect CRL is. 
>
>A good practice for RFCs would be to follow ISO editing rules where 
>there MUST be a separate section for formal definitions.  :-)
>
>However the extracted sentence is the earliest use of the wording "indirect
>CRL" 
>in the document saying what an indirect CRL is. It is not explained later
>on.
>
>The definition from X.509 you mention is thus not an RFC 3280 definition.
>
>>      indirect CRL (iCRL):  A revocation list that at least contains
>>revocation information
>>      about certificates issued by authorities other than that which 
>>issued this CRL.
>
>The X.509 definition is NOT :
>
>indirect CRL (iCRL):  A revocation list that at least contains revocation
>information 
>about certificates issued by *an authority* other than that which issued
>this CRL.
>
>The X.509 definition is NOT either:
>
>indirect CRL (iCRL):  A revocation list that at least contains revocation
>information 
>about certificates issued by *one or more* authorities other than that which
>issued 
>this CRL.
>  
>>In order to help avoid this confusion in 3280bis, I have removed the
>>sentence "Whenever ...." from 3280bis draft -01 and have added the 
>>following paragraph:
>>
>>      If the scope of the CRL includes one or more certificates issued by
>>      an entity other than the CRL issuer, then it is an indirect CRL.
>
>Arhh!  Once again: "certificates issued by .. CRL issuer". 
>
>>      The
>>      scope of an indirect CRL may be limited to certificates issued by a
>>      single CA or may include certificates issued by multiple CAs.
>
>This would have been true if the X.509 definition had been written
>differently.
>
>>      If the
>>      issuer of the indirect CRL is a CA, then the scope of the indirect
>>      CRL MAY include certificates issued by the issuer of the CRL.
>
>This is ruled out by the current quoted sentence. 
>
>>I believe that this text is fully consistent with the X.509 definition
>>of indirect CRL 
>
>Sorry, it is not.
>
>> as well as the descriptions of the indirectCRL flag and
>>the certificateIssuer CRL entry extension in both X.509 and RFC 3280 and 
>>the algorithm in section 6.3.3 of RFC 3280.
>
>Page 59 is stating:
>
>   "The CRL issuer MUST assert the indirectCRL boolean, if the scope of
>   the CRL includes certificates issued by authorities other than the
>   CRL issuer.  The authority responsible for each entry is indicated by
>   the certificate issuer CRL entry extension (section 5.3.4)".
>
>It is clear that this flag is present when there are certificate issuer CRL
>entry extensions.
>
>Thus, in the simplest case, where a CA designates another entity to issue
>revocation 
>status information for some of its certificates, the certificate issuer CRL
>entry extension 
>is not needed, neither the indirectCRL boolean.
>
>The way to fix the problem is simple: either adopt (but add "may") the
>definition of X.509 
>or make it clearer by saying:
>
>indirect CRL (iCRL):  A revocation list that at least *may* contain
>revocation information 
>about certificates issued by more than one CA.
>
>and add for clarification:
>
>delegatedCRL (dCRL):  A revocation list issued by a CRL Issuer that received
>and accepted 
>a delegation for issuing revocation status information from a single CA,
>that contains 
>revocation information about certificates issued by that single CA.
>
>See processing details for these two cases in
><draft-pinkas-pkix-conf-crl-validation-02.txt> 
>that is now available.
>
>The benefits are:
>
> 1) a very simple CRL processing when the CRL contains revocation
>information 
>    about certificates from a single CA. 
>
> 2) a (much) more complex CRL processing when the CRL contains revocation 
>    information about certificates from more than one CA, including the
>(seldom ?)
>    case where the CRL issuer is also a CA.
>
>Denis
>
>>Dave

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 j6MESvJK046129; Fri, 22 Jul 2005 07:28: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 j6MESvdn046128; Fri, 22 Jul 2005 07:28:57 -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 j6MESuv1046118 for <ietf-pkix@imc.org>; Fri, 22 Jul 2005 07:28:56 -0700 (PDT) (envelope-from denis.pinkas@bull.net)
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA23234; Fri, 22 Jul 2005 16:44:52 +0200
Received: from frcls4013 ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with SMTP id 2005072216295974:1333 ; Fri, 22 Jul 2005 16:29:59 +0200 
Date: Fri, 22 Jul 2005 16:30:09 +0100
From: "Denis Pinkas" <denis.pinkas@bull.net>
To: "pkix" <ietf-pkix@imc.org>, "Manger, James H" <James.H.Manger@team.telstra.com>
Subject: Re: RE: draft-pinkas-pkix-conf-crl-validation-02.txt is available
X-mailer: Foxmail 5.0 [-fr-]
Mime-Version: 1.0
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 22/07/2005 16:29:59, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 22/07/2005 16:30:01, Serialize complete at 22/07/2005 16:30:01
Message-ID: <OFFA55B34B.D52D20BC-ONC1257046.004FA688@frcl.bull.fr>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by above.proper.com id j6MESvv1046123
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

James,

>Denis,

>By ignoring the IDP.indirectCRL flag your rules can give the wrong result 
>by accepting a CRL that does not apply to a given certificate.

If the CRL issuer is only "working" on behalf of a single CA, I do not think so.
Otherwise, would you provide an example where the result would be wrong ?

>Consider a certificate that has a CRL-DP extension with a cRLIssuer field 
>and consider a CRL without an IDP extension from that cRLIssuer.  

>Your rules say that the CRL covers the certificate (ie would list the certificate 
>if it was revoked), but it does not cover it.  The CRL (without IDP) only covers 
>certificates issued by the authority that issued the CRL.

Here are some extracts from 3280bis :

Page 51:

   CRL issuers issue CRLs.  The CRL issuer is either the CA or an entity
   that has been authorized by the CA to issue CRLs.  

Page 62:

   If the distributionPoint field is absent, the CRL MUST contain
   entries for all revoked unexpired certificates issued by the CRL
   issuer, if any, within the scope of the CRL.

Your comment applies since the only case where a CRL issuer 
may issue certificates is when it is also a CA.

This sentence then mandates CRL Issuers to support the distributionPoint 
field present.

However from a RP point of view, in the case the CRL contains certificates 
from a single CA, if this field is present *but no test is made on it*, would you 
be able to provide an example where the algorithm would give the wrong result  ?

>Only when IDP.indirectCRL is true must the CRL issuer "ensure that 
>the CRL is complete in that it contains all revocation entries ... from all 
>authorities that identify this CRL in their certificates" [X.509, 8.6.2.2 IDP extension].

The word 'issuer' is missing. The exact sentence is:

If indirectCRL is true, [..] it is the responsibility of the CRL issuer to ensure that 
the CRL is complete in that it contains all revocation entries [] from all authorities 
that identify this CRL *issuer* in their certificates.

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 j6MDgWrk040920; Fri, 22 Jul 2005 06:42: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 j6MDgWZ8040919; Fri, 22 Jul 2005 06:42:32 -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 j6MDgUST040864 for <ietf-pkix@imc.org>; Fri, 22 Jul 2005 06:42:31 -0700 (PDT) (envelope-from stefans@microsoft.com)
Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Jul 2005 14:42:25 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: I-D ACTION:draft-ietf-pkix-rfc3280bis-01.txt
Date: Fri, 22 Jul 2005 14:42:24 +0100
Message-ID: <BF9309599A71984CAC5BAC5ECA62994402DC994C@EUR-MSG-11.europe.corp.microsoft.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: I-D ACTION:draft-ietf-pkix-rfc3280bis-01.txt
Thread-Index: AcWOvHEmDa+1rDssTcOi93stX4uySwABnFlA
From: "Stefan Santesson" <stefans@microsoft.com>
To: "David A. Cooper" <david.cooper@nist.gov>
Cc: "pkix" <ietf-pkix@imc.org>
X-OriginalArrivalTime: 22 Jul 2005 13:42:25.0479 (UTC) FILETIME=[31C68D70:01C58EC3]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j6MDgVST040911
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <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,

Just note though that the "if" was not the only typo in this sentence.
The word "bit" after "MAY" should be "be".

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> -----Original Message-----
> From: David A. Cooper [mailto:david.cooper@nist.gov]
> Sent: den 22 juli 2005 05:54
> To: Stefan Santesson
> Cc: pkix
> Subject: Re: I-D ACTION:draft-ietf-pkix-rfc3280bis-01.txt
> 
> Stefan,
> 
> Thanks for pointing this out.  Yes, the first "if" should be deleted.
> 
> I also discovered a typo in section 7.5, where I wrote "convertion"
> instead of "conversion".
> 
> Both of these will be fixed in the next draft.
> 
> Dave
> 
> Stefan Santesson wrote:
> 
> >David,
> >
> >The following sentence in the new first section of key usage,
following
> >the bit definitions, seems to have typos in its construction:
> >
> >                                                     " However, if
the
> >   digitalSignature and/or nonRepudiation bits MAY bit set in
addition
> >   to the keyCertSign and/or cRLSign bits if the subject public key
is
> >   to be used to verify signatures on certificates and/or CRLs as
well
> >   as other objects."
> >
> >I guess the intended wording is:
> >
> >                                                        " However,
the
> >   digitalSignature and/or nonRepudiation bits MAY be set in addition
> >   to the keyCertSign and/or cRLSign bits if the subject public key
is
> >   to be used to verify signatures on certificates and/or CRLs as
well
> >   as other objects."
> >
> >

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 j6MCroEv021899; Fri, 22 Jul 2005 05:53: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 j6MCroZ1021898; Fri, 22 Jul 2005 05:53:50 -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 (rimp2.nist.gov [129.6.16.227]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6MCrnO9021887 for <ietf-pkix@imc.org>; Fri, 22 Jul 2005 05:53:49 -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.13.1/8.13.1) with ESMTP id j6MCrhlr005104; Fri, 22 Jul 2005 08:53:44 -0400
Received: from [129.6.54.72] (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id j6MCqh6u012370; Fri, 22 Jul 2005 08:52:43 -0400 (EDT)
Message-ID: <42E0EC69.3040409@nist.gov>
Date: Fri, 22 Jul 2005 08:54:01 -0400
From: "David A. Cooper" <david.cooper@nist.gov>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040804
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Stefan Santesson <stefans@microsoft.com>
CC: pkix <ietf-pkix@imc.org>
Subject: Re: I-D ACTION:draft-ietf-pkix-rfc3280bis-01.txt
References: <BF9309599A71984CAC5BAC5ECA62994402DC9763@EUR-MSG-11.europe.corp.microsoft.com>
In-Reply-To: <BF9309599A71984CAC5BAC5ECA62994402DC9763@EUR-MSG-11.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-NIST-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,

Thanks for pointing this out.  Yes, the first "if" should be deleted.

I also discovered a typo in section 7.5, where I wrote "convertion" 
instead of "conversion".

Both of these will be fixed in the next draft.

Dave

Stefan Santesson wrote:

>David,
>
>The following sentence in the new first section of key usage, following
>the bit definitions, seems to have typos in its construction:
>
>                                                     " However, if the
>   digitalSignature and/or nonRepudiation bits MAY bit set in addition
>   to the keyCertSign and/or cRLSign bits if the subject public key is
>   to be used to verify signatures on certificates and/or CRLs as well
>   as other objects."
>
>I guess the intended wording is:
>
>                                                        " However, the
>   digitalSignature and/or nonRepudiation bits MAY be set in addition
>   to the keyCertSign and/or cRLSign bits if the subject public key is
>   to be used to verify signatures on certificates and/or CRLs as well
>   as other objects."
>  
>

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 j6M4aagp039341; Thu, 21 Jul 2005 21: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 j6M4aaHM039340; Thu, 21 Jul 2005 21:36:36 -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 j6M4aYWK039330 for <ietf-pkix@imc.org>; Thu, 21 Jul 2005 21:36:35 -0700 (PDT) (envelope-from stefans@microsoft.com)
Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Jul 2005 05:36:29 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: I-D ACTION:draft-ietf-pkix-rfc3280bis-01.txt
Date: Fri, 22 Jul 2005 05:36:28 +0100
Message-ID: <BF9309599A71984CAC5BAC5ECA62994402DC9763@EUR-MSG-11.europe.corp.microsoft.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: I-D ACTION:draft-ietf-pkix-rfc3280bis-01.txt
Thread-Index: AcWNec+/RbMPKF8kTPK3hjWCYETuWAA9tkPA
From: "Stefan Santesson" <stefans@microsoft.com>
To: "David A. Cooper" <david.cooper@nist.gov>, "pkix" <ietf-pkix@imc.org>
X-OriginalArrivalTime: 22 Jul 2005 04:36:29.0313 (UTC) FILETIME=[ED944710:01C58E76]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j6M4aZWK039334
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <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,

The following sentence in the new first section of key usage, following
the bit definitions, seems to have typos in its construction:

                                                     " However, if the
   digitalSignature and/or nonRepudiation bits MAY bit set in addition
   to the keyCertSign and/or cRLSign bits if the subject public key is
   to be used to verify signatures on certificates and/or CRLs as well
   as other objects."

I guess the intended wording is:

                                                        " However, the
   digitalSignature and/or nonRepudiation bits MAY be set in addition
   to the keyCertSign and/or cRLSign bits if the subject public key is
   to be used to verify signatures on certificates and/or CRLs as well
   as other objects."

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> -----Original Message-----
> From: owner-ietf-pkix@mail.imc.org
[mailto:owner-ietf-pkix@mail.imc.org]
> On Behalf Of David A. Cooper
> Sent: den 20 juli 2005 14:31
> To: pkix
> Subject: Re: I-D ACTION:draft-ietf-pkix-rfc3280bis-01.txt
> 
> 
> Internet-Drafts@ietf.org wrote:
> 
> >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
> >                          Certificate and Certificate Revocation List
> (CRL) Profile
> >	Author(s)	: D. Cooper, et al.
> >	Filename	: draft-ietf-pkix-rfc3280bis-01.txt
> >	Pages		: 138
> >	Date		: 2005-7-20
> >
> >A URL for this Internet-Draft is:
> >http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-01.txt
> >
> >
> 
> I have posted two "diff" files on the NIST Web site: one showing the
> differences between 3280bis-00 and 3280bis-01 and one showing the
> differences between RFC 3280 and 3280bis-01.  They are available at:
> 
> 
> http://csrc.nist.gov/pki/documents/PKIX/draft3280bis-00todraft3280bis-
> 01_diff.html
> 
> and
> 
> 
>
http://csrc.nist.gov/pki/documents/PKIX/rfc3280todraft3280bis-01_diff.ht
ml
> 
> 
> While I would encourage people to review the "diff" files to see what
> changes have been made, here is a list summarizing some of the changes
> that were made between draft -00 and draft -01:
> 
> 1) The descriptions of some of the keyUsage bits have been changed
based
> on discussions on the PKIX mail list.
> 
> 2) Section 4.2.1.9 has been modified to clarify that while conforming
CA
> certificates MUST include a basicConstraints extension, applications
MAY
> use certificates that do not include the basicConstraints extension as
> intermediate certificates if the certificates are version 1 or 2.
> 
> 3) The rules for specifying name constraints for URIs have been
changed
> back to the rules that were in RFC 3280.
> 
> 4) In order to align with draft-zeilenga-ldap-x509-01.txt, all example
> LDAP URIs (in the cRLDistributionPoints, authorityInfoAccess, and
> subjectInfoAccess extensions) specify the ";binary" option.
> 
> 5) Sections 5 and 5.2.5 have been modified to clarify the meaning of
an
> indirect CRL.
> 
> 6) Section 6.1 includes a new paragraph that explains that the path
> validation algorithm is not intended to verify that certificates and
> CRLs are issued in conformance with the PKIX profile.
> 
> 7) The sample certificates in appendix C have been changed.
> 
> 
> Dave

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 j6M1Mc9q019895; Thu, 21 Jul 2005 18:22: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 j6M1Mc5R019894; Thu, 21 Jul 2005 18:22:38 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from mailbo.vtcif.telstra.com.au (mailbo.vtcif.telstra.com.au [202.12.144.19]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6M1MaJm019888 for <ietf-pkix@imc.org>; Thu, 21 Jul 2005 18:22:37 -0700 (PDT) (envelope-from James.H.Manger@team.telstra.com)
Received: from mailbi.vtcif.telstra.com.au (mailbi.vtcif.telstra.com.au [202.12.142.19]) by mailbo.vtcif.telstra.com.au (Postfix) with ESMTP id 988AE259A4 for <ietf-pkix@imc.org>; Fri, 22 Jul 2005 11:22:32 +1000 (EST)
Received: from mail.cdn.telstra.com.au (localhost [127.0.0.1]) by mailbi.vtcif.telstra.com.au (Postfix) with ESMTP id A38281DAA8 for <ietf-pkix@imc.org>; Fri, 22 Jul 2005 11:22:24 +1000 (EST)
Received: from wsmsg2902.srv.dir.telstra.com (wsmsg2902.srv.dir.telstra.com [172.49.40.51]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id LAA28730 for <ietf-pkix@imc.org>; Fri, 22 Jul 2005 11:22:24 +1000 (EST)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Subject: RE: draft-pinkas-pkix-conf-crl-validation-02.txt is available
Date: Fri, 22 Jul 2005 11:18:39 +1000
Message-ID: <73388857A695D31197EF00508B08F29817863EA5@ntmsg0131.corpmail.telstra.com.au>
Thread-Topic: draft-pinkas-pkix-conf-crl-validation-02.txt is available
Thread-Index: AcWOAMGfO1zobKO0R76z+h7EPd2VuwAUanEg
From: "Manger, James H" <James.H.Manger@team.telstra.com>
To: "pkix" <ietf-pkix@imc.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by above.proper.com id j6M1MbJm019889
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <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,
By ignoring the IDP.indirectCRL flag your rules can give the wrong result by accepting a CRL that does not apply to a given certificate.

Consider a certificate that has a CRL-DP extension with a cRLIssuer field and consider a CRL without an IDP extension from that cRLIssuer.  Your rules say that the CRL covers the certificate (ie would list the certificate if it was revoked), but it does not cover it.  The CRL (without IDP) only covers certificates issued by the authority that issued the CRL.

Only when IDP.indirectCRL is true must the CRL issuer "ensure that the CRL is complete in that it contains all revocation entries ... from all authorities that identify this CRL in their certificates" [X.509, 8.6.2.2 IDP extension].

-----Original Message-----
From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] 
Sent: Friday, 22 July 2005 12:27 AM
To: pkix
Subject: draft-pinkas-pkix-conf-crl-validation-02.txt is available

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 j6LM06SB005164; Thu, 21 Jul 2005 15:00: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 j6LM06Ix005163; Thu, 21 Jul 2005 15:00:06 -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 j6LM04Xc005149 for <ietf-pkix@imc.org>; Thu, 21 Jul 2005 15:00:04 -0700 (PDT) (envelope-from stefans@microsoft.com)
Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Jul 2005 22:59:58 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C58E3F.890D47F4"
Subject: RE: Re: Correction to be done to <draft-pinkas-pkix-conf-crl-validation-01.txt>
Date: Thu, 21 Jul 2005 22:59:56 +0100
Message-ID: <BF9309599A71984CAC5BAC5ECA62994402DC974B@EUR-MSG-11.europe.corp.microsoft.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Re: Correction to be done to <draft-pinkas-pkix-conf-crl-validation-01.txt>
Thread-Index: AcWOKyWIB9J6m5ETTs6oQ/6tvR0HAgAE2NWw
From: "Stefan Santesson" <stefans@microsoft.com>
To: "Sharon Boeyen" <sharon.boeyen@entrust.com>, "Denis Pinkas" <denis.pinkas@bull.net>, "David A. Cooper" <david.cooper@nist.gov>, "Santosh Chokhani" <chokhani@orionsec.com>
Cc: "pkix" <ietf-pkix@imc.org>
X-OriginalArrivalTime: 21 Jul 2005 21:59:58.0775 (UTC) FILETIME=[89504470:01C58E3F]
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <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_001_01C58E3F.890D47F4
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Sharon,

=20

I agree.

=20

There is an interesting twist to this if we were to follow Denis
interpretation of X.509:

=20

indirect CRL (iCRL):  A revocation list that at least contains
revocation information about certificates issued by authorities other
than that which issued this CRL.

=20

This would then mean that EVEN if a CRL contains revocation information
from 2 CAs it might still not be indirect. Not of one of the CAs was
also the CRL issuer. Then we would only have 1 "authority" other than
the issuing authority.

=20

Pretty interesting interpretation isn't it?

=20

Stefan Santesson=20
Program Manager, Standards Liaison=20
Windows Security=20
 =20

________________________________

From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org]
On Behalf Of Sharon Boeyen
Sent: den 21 juli 2005 11:43
To: 'Denis Pinkas'; David A. Cooper; Santosh Chokhani
Cc: 'pkix'
Subject: RE: Re: Correction to be done to
<draft-pinkas-pkix-conf-crl-validation-01.txt>

=20

Denis, I'm sorry but I really am not following your thought processes at
all.=20

X.509 does include a definition for indirect CRLs. RFC 3280 is a profile
of X.509 not a replacement for it. Therefore there is no need to
redefine terms in 3280 that are defined in 509. There is no harm in
clarifying terms in 3280 if the group so chooses but a profile should
not alter the intent of a definition.=20

I take your point that the 509 definition says "authorities" instead of
"authority or authorities". I have taken the time (a lot of it!!!) to
dig through my files to track the history of that definition as I was
the editor of X.509 at the time it was added. (Sometimes I am happy that
I'm such a packrat).

The definition that has been quoted by David from X.509 was added as an
outcome of the April 1999 meeting in Orlando Florida. It was part of the
resolution of Canadian comment number 24 submitted to that meeting
against the X.509 PDAM. The relevant part of the disposition of that
comment was recorded as "Accepted with a few minor modifications to the
proposed text. Also a definition for indirect CRL will be added." I was
the author of the Canadian comment submitted to that meeting and I was
also the editor that created the definition that is now in X.509 as a
result of that comment disposition. Let me assure you that with both
hats on it WAS my intention that any CRL that included revocation
notices for certificates that were issued by any authority other than
that which issued the CRL is an indirect CRL. I will be happy to submit
a defect report to X.509 to change "authorities" to "authority or
authorities". As the editor and the submitter of the ballot comment that
drove the discussion to add the definition in the first place I will
happily admit I made an error in using the term "authorities" in that
definition.=20

Cheers,=20
Sharon=20

-----Original Message-----=20
From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org]
On Behalf Of Denis Pinkas=20
Sent: Thursday, July 21, 2005 10:34 AM=20
To: David A. Cooper; Santosh Chokhani=20
Cc: 'pkix'=20
Subject: Re: Re: Correction to be done to
<draft-pinkas-pkix-conf-crl-validation-01.txt>=20

=20

David,=20

>Santosh Chokhani wrote:=20
>=20
>>Denis,=20
>>=20
>>A sentence in 3280 may be ambiguous. The definition and State Machines

>>are not at odds. Also, if you point to the specific location of the=20
>>sentence in 3280, I will be happy to determine if this is being taken=20
>>out of context or not.=20

>Santosh,=20

>Denis is referring to the final sentence in the following paragraph:=20

>      CRL issuers issue CRLs.  The CRL issuer is either the CA or an
entity=20
>      that has been authorized by the CA to issue CRLS.  CAs publish
CRLs=20
>      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.=20

>I believe the problem is that Denis is interpreting this sentence as a=20
>definition when it is not one.  Here is the definition of indirect CRL=20
>in X.509:=20

You mean that RFC 3280 contains no formal definition of what an=20
Indirect CRL is.=20

A good practice for RFCs would be to follow ISO editing rules where=20
there MUST be a separate section for formal definitions.  :-)=20

However the extracted sentence is the earliest use of the wording
"indirect CRL"=20
in the document saying what an indirect CRL is. It is not explained
later on.=20

The definition from X.509 you mention is thus not an RFC 3280
definition.=20

>      indirect CRL (iCRL):  A revocation list that at least contains=20
>revocation information=20
>      about certificates issued by authorities other than that which=20
>issued this CRL.=20

The X.509 definition is NOT :=20

indirect CRL (iCRL):  A revocation list that at least contains
revocation information=20
about certificates issued by *an authority* other than that which issued
this CRL.=20

The X.509 definition is NOT either:=20

indirect CRL (iCRL):  A revocation list that at least contains
revocation information=20
about certificates issued by *one or more* authorities other than that
which issued=20
this CRL.=20
 =20
>In order to help avoid this confusion in 3280bis, I have removed the=20
>sentence "Whenever ...." from 3280bis draft -01 and have added the=20
>following paragraph:=20
>=20
>      If the scope of the CRL includes one or more certificates issued
by=20
>      an entity other than the CRL issuer, then it is an indirect CRL.=20

Arhh!  Once again: "certificates issued by .. CRL issuer".=20

>      The=20
>      scope of an indirect CRL may be limited to certificates issued by
a=20
>      single CA or may include certificates issued by multiple CAs.=20

This would have been true if the X.509 definition had been written
differently.=20

>      If the=20
>      issuer of the indirect CRL is a CA, then the scope of the
indirect=20
>      CRL MAY include certificates issued by the issuer of the CRL.=20

This is ruled out by the current quoted sentence.=20

>I believe that this text is fully consistent with the X.509 definition=20
>of indirect CRL=20

Sorry, it is not.=20

> as well as the descriptions of the indirectCRL flag and=20
>the certificateIssuer CRL entry extension in both X.509 and RFC 3280
and=20
>the algorithm in section 6.3.3 of RFC 3280.=20

Page 59 is stating:=20

   "The CRL issuer MUST assert the indirectCRL boolean, if the scope of=20
   the CRL includes certificates issued by authorities other than the=20
   CRL issuer.  The authority responsible for each entry is indicated by

   the certificate issuer CRL entry extension (section 5.3.4)".=20

It is clear that this flag is present when there are certificate issuer
CRL entry extensions.=20

Thus, in the simplest case, where a CA designates another entity to
issue revocation=20
status information for some of its certificates, the certificate issuer
CRL entry extension=20
is not needed, neither the indirectCRL boolean.=20

The way to fix the problem is simple: either adopt (but add "may") the
definition of X.509=20
or make it clearer by saying:=20

indirect CRL (iCRL):  A revocation list that at least *may* contain
revocation information=20
about certificates issued by more than one CA.=20

and add for clarification:=20

delegatedCRL (dCRL):  A revocation list issued by a CRL Issuer that
received and accepted=20
a delegation for issuing revocation status information from a single CA,
that contains=20
revocation information about certificates issued by that single CA.=20

See processing details for these two cases in
<draft-pinkas-pkix-conf-crl-validation-02.txt>=20
that is now available.=20

The benefits are:=20

 1) a very simple CRL processing when the CRL contains revocation
information=20
    about certificates from a single CA.=20

 2) a (much) more complex CRL processing when the CRL contains
revocation=20
    information about certificates from more than one CA, including the
(seldom ?)=20
    case where the CRL issuer is also a CA.=20

Denis=20

>Dave=20

=20

------_=_NextPart_001_01C58E3F.890D47F4
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
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)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<title>RE: Re: Correction to be done to
&lt;draft-pinkas-pkix-conf-crl-validation-01.txt&gt;</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: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:blue;
	text-decoration:underline;}
p
	{mso-margin-top-alt:auto;
	margin-right:0cm;
	mso-margin-bottom-alt:auto;
	margin-left:0cm;
	font-size:12.0pt;
	font-family:"Times New Roman";}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@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=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'>Sharon,<o:p></o:p></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'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>I =
agree.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p>=
</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>There is an =
interesting
twist to this if we were to follow Denis interpretation of =
X.509:<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p>=
</span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
lang=3DEN-US style=3D'font-size:10.0pt;font-family:"Courier =
New"'>indirect CRL
(iCRL):&nbsp; A revocation list that at least contains revocation =
information
about certificates issued by authorities other than that which issued =
this CRL.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-US
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p>=
</span></font></p>

This would then =
mean that
EVEN if a CRL contains revocation information from 2 CAs it might still =
not be
indirect. Not of one of the CAs was also the CRL issuer. Then we would =
only
have 1 &#8220;authority&#8221; other than the issuing =
authority.<o:p></o:p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p>=
</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Pretty =
interesting
interpretation isn&#8217;t it?<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p>=
</span></font></p>

<div>

<p><b><font size=3D2 color=3Dolive face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial;color:olive;font-weight:bold'>Stefan =
Santesson</span></font></b><font
color=3Dnavy><span lang=3DEN-GB style=3D'color:navy'> <br>
</span></font><font size=3D2 color=3Dolive face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:olive'>Program =
Manager,
Standards Liaison</span></font><font color=3Dnavy><span lang=3DEN-GB
style=3D'color:navy'> <br>
</span></font><font size=3D2 color=3Dolive face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:olive'>Windows =
Security</span></font><font
color=3Dnavy><span lang=3DEN-GB style=3D'color:navy'> <br>
</span></font><font color=3Dnavy face=3DArial><span lang=3DEN-GB =
style=3D'font-family:
Arial;color:navy'>&nbsp;</span></font><font color=3Dnavy><span =
lang=3DEN-GB
style=3D'color:navy'> </span></font><span =
lang=3DEN-GB><o:p></o:p></span></p>

</div>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0cm 0cm =
0cm 4.0pt'>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
face=3D"Times New Roman"><span lang=3DEN-US style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1>

</span></font></div>

From:</spa=
n>
owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] =
On Behalf Of Sharon Boeyen 
Sent: den 21 juli 2005 =
11:43 
To: 'Denis Pinkas'; David =
A.
Cooper; Santosh Chokhani 
Cc: 'pkix' 
Subject: RE: Re: =
Correction to be
done to =
&lt;draft-pinkas-pkix-conf-crl-validation-01.txt&gt;<o:p></o:p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

Denis,
I'm sorry but I really am not following your thought processes at all. =
<o:p></o:p>

X.509
does include a definition for indirect CRLs. RFC 3280 is a profile of =
X.509 not
a replacement for it. Therefore there is no need to redefine terms in =
3280 that
are defined in 509. There is no harm in clarifying terms in 3280 if the =
group
so chooses but a profile should not alter the intent of a definition. =
<o:p></o:p>

I take
your point that the 509 definition says &quot;authorities&quot; instead =
of
&quot;authority or authorities&quot;. I have taken the time (a lot of =
it!!!) to
dig through my files to track the history of that definition as I was =
the
editor of X.509 at the time it was added. (Sometimes I am happy that I'm =
such a
packrat).<o:p></o:p>

The
definition that has been quoted by David from X.509 was added as an =
outcome of
the April 1999 meeting in Orlando Florida. It was part of the resolution =
of
Canadian comment number 24 submitted to that meeting against the X.509 =
PDAM.
The relevant part of the disposition of that comment was recorded as
&quot;Accepted with a few minor modifications to the proposed text. Also =
a
definition for indirect CRL will be added.&quot; I was the author of the
Canadian comment submitted to that meeting and I was also the editor =
that
created the definition that is now in X.509 as a result of that comment
disposition. Let me assure you that with both hats on it WAS my =
intention that
any CRL that included revocation notices for certificates that were =
issued by
any authority other than that which issued the CRL is an indirect CRL. I =
will
be happy to submit a defect report to X.509 to change =
&quot;authorities&quot;
to &quot;authority or authorities&quot;. As the editor and the submitter =
of the
ballot comment that drove the discussion to add the definition in the =
first
place I will happily admit I made an error in using the term
&quot;authorities&quot; in that definition. =
<o:p></o:p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>Cheers,</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>Sharon</span></font> =
<o:p></o:p></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: =
owner-ietf-pkix@mail.imc.org
[<a =
href=3D"mailto:owner-ietf-pkix@mail.imc.org">mailto:owner-ietf-pkix@mail.=
imc.org</a>]
On Behalf Of Denis Pinkas</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>Sent: Thursday, July 21, =
2005 10:34
AM</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>To: David A. Cooper; =
Santosh
Chokhani</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>Cc: 'pkix'</span></font> =
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>Subject: Re: Re: =
Correction to be
done to =
&lt;draft-pinkas-pkix-conf-crl-validation-01.txt&gt;</span></font> =
<o:p></o:p></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'><o:p>&nbsp;</o:p></span></font></p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>David,</span></font>
<o:p></o:p></p>

&gt;Santosh
Chokhani wrote: 
&gt; 
&gt;&gt;Denis, 
&gt;&gt; =
 
&gt;&gt;A sentence in =
3280 may be
ambiguous. The definition and State Machines 
&gt;&gt;are not at odds. =
Also, if
you point to the specific location of the 
&gt;&gt;sentence in =
3280, I will be
happy to determine if this is being taken 
&gt;&gt;out of context =
or not.
<o:p></o:p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>&gt;Santosh,</span></font>
<o:p></o:p></p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>&gt;Denis
is referring to the final sentence in the following =
paragraph:</span></font> <o:p></o:p></p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
CRL issuers issue CRLs.&nbsp; The CRL issuer is either the CA or an =
entity</span></font>
<br>
<font size=3D2><span =
style=3D'font-size:10.0pt'>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
that has been authorized by the CA to issue CRLS.&nbsp; CAs publish =
CRLs</span></font>
<br>
<font size=3D2><span =
style=3D'font-size:10.0pt'>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
to provide status information about the certificates they =
issued.</span></font>
<br>
<font size=3D2><span =
style=3D'font-size:10.0pt'>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
However, a CA may delegate this responsibility to another =
trusted</span></font>
<br>
<font size=3D2><span =
style=3D'font-size:10.0pt'>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
authority.&nbsp; Whenever the CRL issuer is not the CA that issued =
the</span></font>
<br>
<font size=3D2><span =
style=3D'font-size:10.0pt'>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
certificates, the CRL is referred to as an indirect CRL.</span></font> =
<o:p></o:p></p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>&gt;I
believe the problem is that Denis is interpreting this sentence as =
a</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;definition when it =
is not
one.&nbsp; Here is the definition of indirect CRL </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;in =
X.509:</span></font> <o:p></o:p></p>

You mean
that RFC 3280 contains no formal definition of what an =
 
Indirect CRL is. =
<o:p></o:p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>A good
practice for RFCs would be to follow ISO editing rules where =
</span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>there MUST be a separate =
section
for formal definitions.&nbsp; :-)</span></font> <o:p></o:p></p>

However
the extracted sentence is the earliest use of the wording &quot;indirect
CRL&quot; 
in the document saying =
what an
indirect CRL is. It is not explained later on. =
<o:p></o:p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>The
definition from X.509 you mention is thus not an RFC 3280 =
definition.</span></font>
<o:p></o:p></p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
indirect CRL (iCRL):&nbsp; A revocation list that at least =
contains</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;revocation =
information</span></font>
<br>
<font size=3D2><span =
style=3D'font-size:10.0pt'>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
about certificates issued by authorities other than that which =
</span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;issued this =
CRL.</span></font> <o:p></o:p></p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>The X.509
definition is NOT :</span></font> <o:p></o:p></p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>indirect
CRL (iCRL):&nbsp; A revocation list that at least contains revocation
information </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>about certificates =
issued by *an
authority* other than that which issued this CRL.</span></font> =
<o:p></o:p></p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>The X.509
definition is NOT either:</span></font> <o:p></o:p></p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>indirect
CRL (iCRL):&nbsp; A revocation list that at least contains revocation
information </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>about certificates =
issued by *one
or more* authorities other than that which issued </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>this CRL.</span></font> =
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&nbsp; =
</span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;In order to help =
avoid this
confusion in 3280bis, I have removed the</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;sentence =
&quot;Whenever
....&quot; from 3280bis draft -01 and have added the </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;following =
paragraph:</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;</span></font> <br>
<font size=3D2><span =
style=3D'font-size:10.0pt'>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
If the scope of the CRL includes one or more certificates issued =
by</span></font>
<br>
<font size=3D2><span =
style=3D'font-size:10.0pt'>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
an entity other than the CRL issuer, then it is an indirect =
CRL.</span></font> <o:p></o:p></p>

Arhh!&nbsp;
Once again: &quot;certificates issued by .. CRL issuer&quot;. =
<o:p></o:p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
The</span></font> <br>
<font size=3D2><span =
style=3D'font-size:10.0pt'>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
scope of an indirect CRL may be limited to certificates issued by =
a</span></font>
<br>
<font size=3D2><span =
style=3D'font-size:10.0pt'>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
single CA or may include certificates issued by multiple =
CAs.</span></font> <o:p></o:p></p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>This
would have been true if the X.509 definition had been written =
differently.</span></font>
<o:p></o:p></p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
If the</span></font> <br>
<font size=3D2><span =
style=3D'font-size:10.0pt'>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
issuer of the indirect CRL is a CA, then the scope of the =
indirect</span></font>
<br>
<font size=3D2><span =
style=3D'font-size:10.0pt'>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
CRL MAY include certificates issued by the issuer of the =
CRL.</span></font> <o:p></o:p></p>

This is
ruled out by the current quoted sentence. <o:p></o:p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>&gt;I
believe that this text is fully consistent with the X.509 =
definition</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;of indirect CRL =
</span></font><o:p></o:p></p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>Sorry, it
is not.</span></font> <o:p></o:p></p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>&gt; as
well as the descriptions of the indirectCRL flag and</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;the =
certificateIssuer CRL entry
extension in both X.509 and RFC 3280 and </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;the algorithm in =
section 6.3.3
of RFC 3280.</span></font> <o:p></o:p></p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>Page 59
is stating:</span></font> <o:p></o:p></p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp;
&quot;The CRL issuer MUST assert the indirectCRL boolean, if the scope =
of</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&nbsp;&nbsp; the CRL =
includes
certificates issued by authorities other than the</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&nbsp;&nbsp; CRL =
issuer.&nbsp; The
authority responsible for each entry is indicated by</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&nbsp;&nbsp; the =
certificate issuer
CRL entry extension (section 5.3.4)&quot;.</span></font> <o:p></o:p></p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>It is
clear that this flag is present when there are certificate issuer CRL =
entry
extensions.</span></font> <o:p></o:p></p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>Thus, in
the simplest case, where a CA designates another entity to issue =
revocation </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>status information for =
some of its
certificates, the certificate issuer CRL entry extension =
</span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>is not needed, neither =
the
indirectCRL boolean.</span></font> <o:p></o:p></p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>The way
to fix the problem is simple: either adopt (but add &quot;may&quot;) the
definition of X.509 </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>or make it clearer by =
saying:</span></font>
<o:p></o:p></p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>indirect
CRL (iCRL):&nbsp; A revocation list that at least *may* contain =
revocation
information </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>about certificates =
issued by more
than one CA.</span></font> <o:p></o:p></p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>and add
for clarification:</span></font> <o:p></o:p></p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>delegatedCRL
(dCRL):&nbsp; A revocation list issued by a CRL Issuer that received and
accepted </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>a delegation for issuing =
revocation
status information from a single CA, that contains </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>revocation information =
about
certificates issued by that single CA.</span></font> <o:p></o:p></p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>See
processing details for these two cases in
&lt;draft-pinkas-pkix-conf-crl-validation-02.txt&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>that is now =
available.</span></font>
<o:p></o:p></p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>The
benefits are:</span></font> <o:p></o:p></p>

&nbsp;1)
a very simple CRL processing when the CRL contains revocation =
information 
&nbsp;&nbsp;&nbsp; about
certificates from a single CA. <o:p></o:p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>&nbsp;2)
a (much) more complex CRL processing when the CRL contains revocation =
</span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&nbsp;&nbsp;&nbsp; =
information
about certificates from more than one CA, including the (seldom =
?)</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&nbsp;&nbsp;&nbsp; case =
where the
CRL issuer is also a CA.</span></font> <o:p></o:p></p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>Denis</span></font>
<o:p></o:p></p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>&gt;Dave</span></font>
<o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

</div>

</div>

</body>

</html>

------_=_NextPart_001_01C58E3F.890D47F4--

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 j6LLrudj004568; Thu, 21 Jul 2005 14:53: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 j6LLruRd004567; Thu, 21 Jul 2005 14:53:56 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from host15.websitesource.com (host15.websitesource.com [209.239.32.38]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6LLrt0E004559 for <ietf-pkix@imc.org>; Thu, 21 Jul 2005 14:53:56 -0700 (PDT) (envelope-from chokhani@orionsec.com)
Received: from wchokhani3 (pcp09271453pcs.arlngt01.va.comcast.net [69.143.129.49]) by host15.websitesource.com (8.12.10/8.12.10) with ESMTP id j6LLrroO009052 for <ietf-pkix@imc.org>; Thu, 21 Jul 2005 17:53:55 -0400
From: "Santosh Chokhani" <chokhani@orionsec.com>
To: "'pkix'" <ietf-pkix@imc.org>
Subject: RE: draft-pinkas-pkix-conf-crl-validation-02.txt is available
Date: Thu, 21 Jul 2005 17:53:47 -0400
Message-ID: <006401c58e3e$af583fc0$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.2900.2180
In-Reply-To: <OF11081D33.03FD428A-ONC1257045.0049E783@frcl.bull.fr>
Importance: Normal
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j6LLru0E004562
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <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,

I would not have time to read things other than those that are tied to 3280.

-----Original Message-----
From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On
Behalf Of Denis Pinkas
Sent: Thursday, July 21, 2005 10:27 AM
To: pkix
Subject: draft-pinkas-pkix-conf-crl-validation-02.txt is available

<draft-pinkas-pkix-conf-crl-validation-02.txt> is now available at:
http://www.ietf.org/internet-drafts/draft-pinkas-pkix-conf-crl-validation-02
.txt

There is a common section for any kind of CRL.
 See section 6.3.3.1  CRL Processing start for all applications

Note that "old CRLs" may be selected in that phase and this may be quite
useful, 
if it can be found that the target certificate was already revoked some time
ago. Note also that more than one CRL may be found in the local cache. 
The current algorithm does not support these cases because it is making 
incorrect-different-others assumptions.

Then the document makes a clear distinction between three kinds of
processing 
where the complexity goes from simple to complex:

1 - What conformant applications shall support. This covers CRLs that
contain certificates 
    from a single CA. The CRL may be issued by the CA or by a CRL issuer
(that is not a CA) 
    designated by a CA.  

    See section 6.3.3.2  CRL Processing for conforming applications.

2 - If an application supports Certificate Issuer CRL entry extensions, then
this section applies.
    This covers CRLs that *may* contain certificates from more than one CA.

    See section 6.3.3.3. CRL Processing for applications supporting 
    Certificate Issuer CRL entry extensions.

3 - If an application supports delta-CRLs. I have left the details for David
Copper 
    who is much more expert than I am on that topic.

    See the nearly empty section 6.3.3.4. CRL Processing for applications
supporting delta CRLs.

Note : Santosh, please read section 6.3.3.3. and you will see that it is
possible 
          to go backwards looking for Certificate Issuer CRL entry
extensions.

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 j6LLinPh004131; Thu, 21 Jul 2005 14:44: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 j6LLinAc004130; Thu, 21 Jul 2005 14:44:49 -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 j6LLilmG004096 for <ietf-pkix@imc.org>; Thu, 21 Jul 2005 14:44:48 -0700 (PDT) (envelope-from stefans@microsoft.com)
Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Jul 2005 22:44:42 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: draft-pinkas-pkix-conf-crl-validation-02.txt is available
Date: Thu, 21 Jul 2005 22:44:40 +0100
Message-ID: <BF9309599A71984CAC5BAC5ECA62994402DC9749@EUR-MSG-11.europe.corp.microsoft.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: draft-pinkas-pkix-conf-crl-validation-02.txt is available
Thread-Index: AcWN/vE7O2+/VMAbREmcZaKkwGlXlQAPQjgg
From: "Stefan Santesson" <stefans@microsoft.com>
To: "Denis Pinkas" <denis.pinkas@bull.net>, "pkix" <ietf-pkix@imc.org>
X-OriginalArrivalTime: 21 Jul 2005 21:44:42.0008 (UTC) FILETIME=[66E0B980:01C58E3D]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j6LLimmG004125
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

Making a comparison between this draft and RFC 3280bis I noticed that
this draft has the same problem as previous drafts.

This draft contains a complete rewrite of RFC 3280 section 6.3 and as
such almost none of the changes are supported by any explanation or
motivation provided in the draft.

Current text in RFC 3280, which the current editorial process works
from, is a result of a long consensus process. To adopt a complete
rewrite would require a very long and painful process of making sure
that no new problems are introduced. In fact many such problems can
easily be located and there may be many more.

I suggest once again that the RFC 3280bis editorial process disregard
from this draft and that PKIX chairs instead ask the author to come up
with a specific list of numbered issues, each accompanied by proposed
resolutions and appropriate motivation.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> -----Original Message-----
> From: owner-ietf-pkix@mail.imc.org
[mailto:owner-ietf-pkix@mail.imc.org]
> On Behalf Of Denis Pinkas
> Sent: den 21 juli 2005 07:27
> To: pkix
> Subject: draft-pinkas-pkix-conf-crl-validation-02.txt is available
> 
> 
> <draft-pinkas-pkix-conf-crl-validation-02.txt> is now available at:
>
http://www.ietf.org/internet-drafts/draft-pinkas-pkix-conf-crl-validatio
n-
> 02.txt
> 
> There is a common section for any kind of CRL.
>  See section 6.3.3.1  CRL Processing start for all applications
> 
> Note that "old CRLs" may be selected in that phase and this may be
quite
> useful,
> if it can be found that the target certificate was already revoked
some
> time ago.
> Note also that more than one CRL may be found in the local cache.
> The current algorithm does not support these cases because it is
making
> incorrect-different-others assumptions.
> 
> Then the document makes a clear distinction between three kinds of
> processing
> where the complexity goes from simple to complex:
> 
> 1 - What conformant applications shall support. This covers CRLs that
> contain certificates
>     from a single CA. The CRL may be issued by the CA or by a CRL
issuer
> (that is not a CA)
>     designated by a CA.
> 
>     See section 6.3.3.2  CRL Processing for conforming applications.
> 
> 2 - If an application supports Certificate Issuer CRL entry
extensions,
> then this section applies.
>     This covers CRLs that *may* contain certificates from more than
one
> CA.
> 
>     See section 6.3.3.3. CRL Processing for applications supporting
>     Certificate Issuer CRL entry extensions.
> 
> 3 - If an application supports delta-CRLs. I have left the details for
> David Copper
>     who is much more expert than I am on that topic.
> 
>     See the nearly empty section 6.3.3.4. CRL Processing for
applications
> supporting delta CRLs.
> 
> Note : Santosh, please read section 6.3.3.3. and you will see that it
is
> possible
>           to go backwards looking for Certificate Issuer CRL entry
> extensions.
> 
> 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 j6LLO9ZB002872; Thu, 21 Jul 2005 14:24:09 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6LLO9hQ002871; Thu, 21 Jul 2005 14:24:09 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from mail-eur1.microsoft.com (mail-eur1.microsoft.com [213.199.128.139]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6LLO8RE002864 for <ietf-pkix@imc.org>; Thu, 21 Jul 2005 14:24:08 -0700 (PDT) (envelope-from stefans@microsoft.com)
Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Jul 2005 22:24:01 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: Re: Correction to be done to <draft-pinkas-pkix-conf-crl-validation-01.txt>
Date: Thu, 21 Jul 2005 22:24:00 +0100
Message-ID: <BF9309599A71984CAC5BAC5ECA62994402DC9748@EUR-MSG-11.europe.corp.microsoft.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Re: Correction to be done to <draft-pinkas-pkix-conf-crl-validation-01.txt>
Thread-Index: AcWN/xJ56PBzwFCYQGSss4UazpwChQAOs85Q
From: "Stefan Santesson" <stefans@microsoft.com>
To: "Denis Pinkas" <denis.pinkas@bull.net>, "David A. Cooper" <david.cooper@nist.gov>, "Santosh Chokhani" <chokhani@orionsec.com>
Cc: "pkix" <ietf-pkix@imc.org>
X-OriginalArrivalTime: 21 Jul 2005 21:24:01.0960 (UTC) FILETIME=[83C06A80:01C58E3A]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j6LLO9RE002866
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <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,

Quote:
"Thus, in the simplest case, where a CA designates another entity to
issue revocation status information for some of its certificates, the
certificate issuer CRL entry extension is not needed, neither the
indirectCRL boolean."

I can't believe you are serious about this!
You are just trying to drive us mad, right?

How much more "indirect" can it be?

/Stefan

> -----Original Message-----
> From: owner-ietf-pkix@mail.imc.org
[mailto:owner-ietf-pkix@mail.imc.org]
> On Behalf Of Denis Pinkas
> Sent: den 21 juli 2005 07:34
> To: David A. Cooper; Santosh Chokhani
> Cc: 'pkix'
> Subject: Re: Re: Correction to be done to <draft-pinkas-pkix-conf-crl-
> validation-01.txt>
> 
> 
> David,
> 
> >Santosh Chokhani wrote:
> >
> >>Denis,
> >>
> >>A sentence in 3280 may be ambiguous. The definition and State
Machines
> are
> >>not at odds. Also, if you point to the specific location of the
sentence
> in
> >>3280, I will be happy to determine if this is being taken out of
context
> or
> >>not.
> 
> >Santosh,
> 
> >Denis is referring to the final sentence in the following paragraph:
> 
> >      CRL issuers issue CRLs.  The CRL issuer is either the CA or an
> entity
> >      that has been authorized by the CA to issue CRLS.  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.
> 
> >I believe the problem is that Denis is interpreting this sentence as
a
> >definition when it is not one.  Here is the definition of indirect
CRL
> >in X.509:
> 
> You mean that RFC 3280 contains no formal definition of what an
> Indirect CRL is.
> 
> A good practice for RFCs would be to follow ISO editing rules where
> there MUST be a separate section for formal definitions.  :-)
> 
> However the extracted sentence is the earliest use of the wording
> "indirect CRL"
> in the document saying what an indirect CRL is. It is not explained
later
> on.
> 
> The definition from X.509 you mention is thus not an RFC 3280
definition.
> 
> >      indirect CRL (iCRL):  A revocation list that at least contains
> >revocation information
> >      about certificates issued by authorities other than that which
> >issued this CRL.
> 
> The X.509 definition is NOT :
> 
> indirect CRL (iCRL):  A revocation list that at least contains
revocation
> information
> about certificates issued by *an authority* other than that which
issued
> this CRL.
> 
> The X.509 definition is NOT either:
> 
> indirect CRL (iCRL):  A revocation list that at least contains
revocation
> information
> about certificates issued by *one or more* authorities other than that
> which issued
> this CRL.
> 
> >In order to help avoid this confusion in 3280bis, I have removed the
> >sentence "Whenever ...." from 3280bis draft -01 and have added the
> >following paragraph:
> >
> >      If the scope of the CRL includes one or more certificates
issued by
> >      an entity other than the CRL issuer, then it is an indirect
CRL.
> 
> Arhh!  Once again: "certificates issued by .. CRL issuer".
> 
> >      The
> >      scope of an indirect CRL may be limited to certificates issued
by a
> >      single CA or may include certificates issued by multiple CAs.
> 
> This would have been true if the X.509 definition had been written
> differently.
> 
> >      If the
> >      issuer of the indirect CRL is a CA, then the scope of the
indirect
> >      CRL MAY include certificates issued by the issuer of the CRL.
> 
> This is ruled out by the current quoted sentence.
> 
> >I believe that this text is fully consistent with the X.509
definition
> >of indirect CRL
> 
> Sorry, it is not.
> 
> > as well as the descriptions of the indirectCRL flag and
> >the certificateIssuer CRL entry extension in both X.509 and RFC 3280
and
> >the algorithm in section 6.3.3 of RFC 3280.
> 
> Page 59 is stating:
> 
>    "The CRL issuer MUST assert the indirectCRL boolean, if the scope
of
>    the CRL includes certificates issued by authorities other than the
>    CRL issuer.  The authority responsible for each entry is indicated
by
>    the certificate issuer CRL entry extension (section 5.3.4)".
> 
> It is clear that this flag is present when there are certificate
issuer
> CRL entry extensions.
> 
> Thus, in the simplest case, where a CA designates another entity to
issue
> revocation
> status information for some of its certificates, the certificate
issuer
> CRL entry extension
> is not needed, neither the indirectCRL boolean.
> 
> The way to fix the problem is simple: either adopt (but add "may") the
> definition of X.509
> or make it clearer by saying:
> 
> indirect CRL (iCRL):  A revocation list that at least *may* contain
> revocation information
> about certificates issued by more than one CA.
> 
> and add for clarification:
> 
> delegatedCRL (dCRL):  A revocation list issued by a CRL Issuer that
> received and accepted
> a delegation for issuing revocation status information from a single
CA,
> that contains
> revocation information about certificates issued by that single CA.
> 
> See processing details for these two cases in
<draft-pinkas-pkix-conf-crl-
> validation-02.txt>
> that is now available.
> 
> The benefits are:
> 
>  1) a very simple CRL processing when the CRL contains revocation
> information
>     about certificates from a single CA.
> 
>  2) a (much) more complex CRL processing when the CRL contains
revocation
>     information about certificates from more than one CA, including
the
> (seldom ?)
>     case where the CRL issuer is also a CA.
> 
> Denis
> 
> >Dave
> 
> 

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 j6LIguqV088944; Thu, 21 Jul 2005 11:42: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 j6LIgu7G088943; Thu, 21 Jul 2005 11:42:56 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from sottmxsecs3.entrust.com (sottmxsecs3.entrust.com [216.191.252.14]) by above.proper.com (8.12.11/8.12.9) with SMTP id j6LIgtGR088936 for <ietf-pkix@imc.org>; Thu, 21 Jul 2005 11:42:55 -0700 (PDT) (envelope-from sharon.boeyen@entrust.com)
Received: (qmail 6648 invoked from network); 21 Jul 2005 18:42:47 -0000
Received: from sharon.boeyen@entrust.com by sottmxsecs3.entrust.com with EntrustECS-Server-7.3.1;21 Jul 2005 18:42:47 -0000
Received: from sottmxs00.entrust.com (10.4.61.22) by sottmxsecs3.entrust.com with SMTP; 21 Jul 2005 18:42:46 -0000
Received: by sottmxs00.entrust.com with Internet Mail Service (5.5.2657.72) id <PHK7PFL1>; Thu, 21 Jul 2005 14:42:48 -0400
Message-ID: <7A3E1242FA9989439AD1F9B2D71C287F03A0345B@sottmxs05.entrust.com>
From: Sharon Boeyen <sharon.boeyen@entrust.com>
To: "'Denis Pinkas'" <denis.pinkas@bull.net>, "David A. Cooper" <david.cooper@nist.gov>, Santosh Chokhani <chokhani@orionsec.com>
Cc: "'pkix'" <ietf-pkix@imc.org>
Subject: RE: Re: Correction to be done to <draft-pinkas-pkix-conf-crl-vali dation-01.txt>
Date: Thu, 21 Jul 2005 14:42:43 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C58E23.FAA1F49B"
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <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_01C58E23.FAA1F49B
Content-Type: text/plain

Denis, I'm sorry but I really am not following your thought processes at
all. 

X.509 does include a definition for indirect CRLs. RFC 3280 is a profile of
X.509 not a replacement for it. Therefore there is no need to redefine terms
in 3280 that are defined in 509. There is no harm in clarifying terms in
3280 if the group so chooses but a profile should not alter the intent of a
definition. 

I take your point that the 509 definition says "authorities" instead of
"authority or authorities". I have taken the time (a lot of it!!!) to dig
through my files to track the history of that definition as I was the editor
of X.509 at the time it was added. (Sometimes I am happy that I'm such a
packrat).

The definition that has been quoted by David from X.509 was added as an
outcome of the April 1999 meeting in Orlando Florida. It was part of the
resolution of Canadian comment number 24 submitted to that meeting against
the X.509 PDAM. The relevant part of the disposition of that comment was
recorded as "Accepted with a few minor modifications to the proposed text.
Also a definition for indirect CRL will be added." I was the author of the
Canadian comment submitted to that meeting and I was also the editor that
created the definition that is now in X.509 as a result of that comment
disposition. Let me assure you that with both hats on it WAS my intention
that any CRL that included revocation notices for certificates that were
issued by any authority other than that which issued the CRL is an indirect
CRL. I will be happy to submit a defect report to X.509 to change
"authorities" to "authority or authorities". As the editor and the submitter
of the ballot comment that drove the discussion to add the definition in the
first place I will happily admit I made an error in using the term
"authorities" in that definition. 

Cheers,
Sharon

-----Original Message-----
From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On
Behalf Of Denis Pinkas
Sent: Thursday, July 21, 2005 10:34 AM
To: David A. Cooper; Santosh Chokhani
Cc: 'pkix'
Subject: Re: Re: Correction to be done to
<draft-pinkas-pkix-conf-crl-validation-01.txt>

David,

>Santosh Chokhani wrote:
>
>>Denis,
>>
>>A sentence in 3280 may be ambiguous. The definition and State Machines 
>>are not at odds. Also, if you point to the specific location of the 
>>sentence in 3280, I will be happy to determine if this is being taken 
>>out of context or not.

>Santosh,

>Denis is referring to the final sentence in the following paragraph:

>      CRL issuers issue CRLs.  The CRL issuer is either the CA or an entity
>      that has been authorized by the CA to issue CRLS.  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.

>I believe the problem is that Denis is interpreting this sentence as a
>definition when it is not one.  Here is the definition of indirect CRL 
>in X.509:

You mean that RFC 3280 contains no formal definition of what an 
Indirect CRL is. 

A good practice for RFCs would be to follow ISO editing rules where 
there MUST be a separate section for formal definitions.  :-)

However the extracted sentence is the earliest use of the wording "indirect
CRL" 
in the document saying what an indirect CRL is. It is not explained later
on.

The definition from X.509 you mention is thus not an RFC 3280 definition.

>      indirect CRL (iCRL):  A revocation list that at least contains
>revocation information
>      about certificates issued by authorities other than that which 
>issued this CRL.

The X.509 definition is NOT :

indirect CRL (iCRL):  A revocation list that at least contains revocation
information 
about certificates issued by *an authority* other than that which issued
this CRL.

The X.509 definition is NOT either:

indirect CRL (iCRL):  A revocation list that at least contains revocation
information 
about certificates issued by *one or more* authorities other than that which
issued 
this CRL.

>In order to help avoid this confusion in 3280bis, I have removed the
>sentence "Whenever ...." from 3280bis draft -01 and have added the 
>following paragraph:
>
>      If the scope of the CRL includes one or more certificates issued by
>      an entity other than the CRL issuer, then it is an indirect CRL.

Arhh!  Once again: "certificates issued by .. CRL issuer". 

>      The
>      scope of an indirect CRL may be limited to certificates issued by a
>      single CA or may include certificates issued by multiple CAs.

This would have been true if the X.509 definition had been written
differently.

>      If the
>      issuer of the indirect CRL is a CA, then the scope of the indirect
>      CRL MAY include certificates issued by the issuer of the CRL.

This is ruled out by the current quoted sentence. 

>I believe that this text is fully consistent with the X.509 definition
>of indirect CRL 

Sorry, it is not.

> as well as the descriptions of the indirectCRL flag and
>the certificateIssuer CRL entry extension in both X.509 and RFC 3280 and 
>the algorithm in section 6.3.3 of RFC 3280.

Page 59 is stating:

   "The CRL issuer MUST assert the indirectCRL boolean, if the scope of
   the CRL includes certificates issued by authorities other than the
   CRL issuer.  The authority responsible for each entry is indicated by
   the certificate issuer CRL entry extension (section 5.3.4)".

It is clear that this flag is present when there are certificate issuer CRL
entry extensions.

Thus, in the simplest case, where a CA designates another entity to issue
revocation 
status information for some of its certificates, the certificate issuer CRL
entry extension 
is not needed, neither the indirectCRL boolean.

The way to fix the problem is simple: either adopt (but add "may") the
definition of X.509 
or make it clearer by saying:

indirect CRL (iCRL):  A revocation list that at least *may* contain
revocation information 
about certificates issued by more than one CA.

and add for clarification:

delegatedCRL (dCRL):  A revocation list issued by a CRL Issuer that received
and accepted 
a delegation for issuing revocation status information from a single CA,
that contains 
revocation information about certificates issued by that single CA.

See processing details for these two cases in
<draft-pinkas-pkix-conf-crl-validation-02.txt> 
that is now available.

The benefits are:

 1) a very simple CRL processing when the CRL contains revocation
information 
    about certificates from a single CA. 

 2) a (much) more complex CRL processing when the CRL contains revocation 
    information about certificates from more than one CA, including the
(seldom ?)
    case where the CRL issuer is also a CA.

Denis

>Dave

------_=_NextPart_001_01C58E23.FAA1F49B
Content-Type: text/html
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=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2658.2">
<TITLE>RE: Re: Correction to be done to =
&lt;draft-pinkas-pkix-conf-crl-validation-01.txt&gt;</TITLE>
</HEAD>
<BODY>

Denis, I'm sorry but I really am not following your =
thought processes at all.

X.509 does include a definition for indirect CRLs. =
RFC 3280 is a profile of X.509 not a replacement for it. Therefore =
there is no need to redefine terms in 3280 that are defined in 509. =
There is no harm in clarifying terms in 3280 if the group so chooses =
but a profile should not alter the intent of a definition.

I take your point that the 509 definition says =
&quot;authorities&quot; instead of &quot;authority or =
authorities&quot;. I have taken the time (a lot of it!!!) to dig =
through my files to track the history of that definition as I was the =
editor of X.509 at the time it was added. (Sometimes I am happy that =
I'm such a packrat).

The definition that has been quoted by David from =
X.509 was added as an outcome of the April 1999 meeting in Orlando =
Florida. It was part of the resolution of Canadian comment number 24 =
submitted to that meeting against the X.509 PDAM. The relevant part of =
the disposition of that comment was recorded as &quot;Accepted with a =
few minor modifications to the proposed text. Also a definition for =
indirect CRL will be added.&quot; I was the author of the Canadian =
comment submitted to that meeting and I was also the editor that =
created the definition that is now in X.509 as a result of that comment =
disposition. Let me assure you that with both hats on it WAS my =
intention that any CRL that included revocation notices for =
certificates that were issued by any authority other than that which =
issued the CRL is an indirect CRL. I will be happy to submit a defect =
report to X.509 to change &quot;authorities&quot; to &quot;authority or =
authorities&quot;. As the editor and the submitter of the ballot =
comment that drove the discussion to add the definition in the first =
place I will happily admit I made an error in using the term =
&quot;authorities&quot; in that definition.

<P><FONT SIZE=3D2>Cheers,</FONT>
<BR><FONT SIZE=3D2>Sharon</FONT>
</P>

-----Original Message-----
 From: owner-ietf-pkix@mail.imc.org [<A =
HREF=3D"mailto:owner-ietf-pkix@mail.imc.org">mailto:owner-ietf-pkix@mail=
.imc.org</A>] On Behalf Of Denis Pinkas
 Sent: Thursday, July 21, 2005 10:34 AM
 To: David A. Cooper; Santosh Chokhani
 Cc: 'pkix'
 Subject: Re: Re: Correction to be done to =
&lt;draft-pinkas-pkix-conf-crl-validation-01.txt&gt;

<P><FONT SIZE=3D2>David,</FONT>
</P>

&gt;Santosh Chokhani wrote:
 &gt;
 &gt;&gt;Denis,
 &gt;&gt;
 &gt;&gt;A sentence in 3280 may be ambiguous. The =
definition and State Machines 
 &gt;&gt;are not at odds. Also, if you point to the =
specific location of the 
 &gt;&gt;sentence in 3280, I will be happy to =
determine if this is being taken 
 &gt;&gt;out of context or not.

<P><FONT SIZE=3D2>&gt;Santosh,</FONT>
</P>

<P><FONT SIZE=3D2>&gt;Denis is referring to the final sentence in the =
following paragraph:</FONT>
</P>

<P><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CRL issuers issue =
CRLs.&nbsp; The CRL issuer is either the CA or an entity</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; that has been =
authorized by the CA to issue CRLS.&nbsp; CAs publish CRLs</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; to provide status =
information about the certificates they issued.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; However, a CA may =
delegate this responsibility to another trusted</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; authority.&nbsp; =
Whenever the CRL issuer is not the CA that issued the</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; certificates, the =
CRL is referred to as an indirect CRL.</FONT>
</P>

<P><FONT SIZE=3D2>&gt;I believe the problem is that Denis is =
interpreting this sentence as a</FONT>
<BR><FONT SIZE=3D2>&gt;definition when it is not one.&nbsp; Here is the =
definition of indirect CRL </FONT>
<BR><FONT SIZE=3D2>&gt;in X.509:</FONT>
</P>

You mean that RFC 3280 contains no formal definition =
of what an 
 Indirect CRL is.

<P><FONT SIZE=3D2>A good practice for RFCs would be to follow ISO =
editing rules where </FONT>
<BR><FONT SIZE=3D2>there MUST be a separate section for formal =
definitions.&nbsp; :-)</FONT>
</P>

However the extracted sentence is the earliest use of =
the wording &quot;indirect CRL&quot; 
 in the document saying what an indirect CRL is. It =
is not explained later on.

<P><FONT SIZE=3D2>The definition from X.509 you mention is thus not an =
RFC 3280 definition.</FONT>
</P>

<P><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; indirect CRL =
(iCRL):&nbsp; A revocation list that at least contains</FONT>
<BR><FONT SIZE=3D2>&gt;revocation information</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; about =
certificates issued by authorities other than that which </FONT>
<BR><FONT SIZE=3D2>&gt;issued this CRL.</FONT>
</P>

<P><FONT SIZE=3D2>The X.509 definition is NOT :</FONT>
</P>

<P><FONT SIZE=3D2>indirect CRL (iCRL):&nbsp; A revocation list that at =
least contains revocation information </FONT>
<BR><FONT SIZE=3D2>about certificates issued by *an authority* other =
than that which issued this CRL.</FONT>
</P>

<P><FONT SIZE=3D2>The X.509 definition is NOT either:</FONT>
</P>

<P><FONT SIZE=3D2>indirect CRL (iCRL):&nbsp; A revocation list that at =
least contains revocation information </FONT>
<BR><FONT SIZE=3D2>about certificates issued by *one or more* =
authorities other than that which issued </FONT>
<BR><FONT SIZE=3D2>this CRL.</FONT>
<BR><FONT SIZE=3D2>&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt;In order to help avoid this confusion in =
3280bis, I have removed the</FONT>
<BR><FONT SIZE=3D2>&gt;sentence &quot;Whenever ....&quot; from 3280bis =
draft -01 and have added the </FONT>
<BR><FONT SIZE=3D2>&gt;following paragraph:</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; If the scope of =
the CRL includes one or more certificates issued by</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; an entity other =
than the CRL issuer, then it is an indirect CRL.</FONT>
</P>

Arhh!&nbsp; Once again: &quot;certificates issued by =
.. CRL issuer&quot;.

<P><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; scope of an =
indirect CRL may be limited to certificates issued by a</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; single CA or may =
include certificates issued by multiple CAs.</FONT>
</P>

<P><FONT SIZE=3D2>This would have been true if the X.509 definition had =
been written differently.</FONT>
</P>

<P><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; If the</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; issuer of the =
indirect CRL is a CA, then the scope of the indirect</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CRL MAY include =
certificates issued by the issuer of the CRL.</FONT>
</P>

This is ruled out by the current quoted sentence. =

<P><FONT SIZE=3D2>&gt;I believe that this text is fully consistent with =
the X.509 definition</FONT>
<BR><FONT SIZE=3D2>&gt;of indirect CRL </FONT>
</P>

<P><FONT SIZE=3D2>Sorry, it is not.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; as well as the descriptions of the indirectCRL =
flag and</FONT>
<BR><FONT SIZE=3D2>&gt;the certificateIssuer CRL entry extension in =
both X.509 and RFC 3280 and </FONT>
<BR><FONT SIZE=3D2>&gt;the algorithm in section 6.3.3 of RFC =
3280.</FONT>
</P>

<P><FONT SIZE=3D2>Page 59 is stating:</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; &quot;The CRL issuer MUST assert the =
indirectCRL boolean, if the scope of</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; the CRL includes certificates issued by =
authorities other than the</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; CRL issuer.&nbsp; The authority =
responsible for each entry is indicated by</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; the certificate issuer CRL entry =
extension (section 5.3.4)&quot;.</FONT>
</P>

<P><FONT SIZE=3D2>It is clear that this flag is present when there are =
certificate issuer CRL entry extensions.</FONT>
</P>

<P><FONT SIZE=3D2>Thus, in the simplest case, where a CA designates =
another entity to issue revocation </FONT>
<BR><FONT SIZE=3D2>status information for some of its certificates, the =
certificate issuer CRL entry extension </FONT>
<BR><FONT SIZE=3D2>is not needed, neither the indirectCRL =
boolean.</FONT>
</P>

<P><FONT SIZE=3D2>The way to fix the problem is simple: either adopt =
(but add &quot;may&quot;) the definition of X.509 </FONT>
<BR><FONT SIZE=3D2>or make it clearer by saying:</FONT>
</P>

<P><FONT SIZE=3D2>indirect CRL (iCRL):&nbsp; A revocation list that at =
least *may* contain revocation information </FONT>
<BR><FONT SIZE=3D2>about certificates issued by more than one =
CA.</FONT>
</P>

<P><FONT SIZE=3D2>and add for clarification:</FONT>
</P>

<P><FONT SIZE=3D2>delegatedCRL (dCRL):&nbsp; A revocation list issued =
by a CRL Issuer that received and accepted </FONT>
<BR><FONT SIZE=3D2>a delegation for issuing revocation status =
information from a single CA, that contains </FONT>
<BR><FONT SIZE=3D2>revocation information about certificates issued by =
that single CA.</FONT>
</P>

<P><FONT SIZE=3D2>See processing details for these two cases in =
&lt;draft-pinkas-pkix-conf-crl-validation-02.txt&gt; </FONT>
<BR><FONT SIZE=3D2>that is now available.</FONT>
</P>

<P><FONT SIZE=3D2>The benefits are:</FONT>
</P>

&nbsp;1) a very simple CRL processing when the CRL =
contains revocation information 
 &nbsp;&nbsp;&nbsp; about certificates from a single =
CA.

<P><FONT SIZE=3D2>&nbsp;2) a (much) more complex CRL processing when =
the CRL contains revocation </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; information about certificates =
from more than one CA, including the (seldom ?)</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; case where the CRL issuer is also =
a CA.</FONT>
</P>

<P><FONT SIZE=3D2>Denis</FONT>
</P>

<P><FONT SIZE=3D2>&gt;Dave</FONT>
</P>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C58E23.FAA1F49B--

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 j6LHdLxO082396; Thu, 21 Jul 2005 10:39: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 j6LHdLjs082395; Thu, 21 Jul 2005 10:39:21 -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 j6LHdK3e082380 for <ietf-pkix@imc.org>; Thu, 21 Jul 2005 10:39:20 -0700 (PDT) (envelope-from Peter.Sylvester@edelweb.fr)
Received: from champagne.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id j6LHdCi05438; Thu, 21 Jul 2005 19:39:12 +0200 (MEST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/2.4); Thu, 21 Jul 2005 19:39:12 +0200 (MET DST)
Received: from [193.51.14.5] (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id TAA08187; Thu, 21 Jul 2005 19:39:11 +0200 (MET DST)
Message-ID: <42DFDB64.9050605@edelweb.fr>
Date: Thu, 21 Jul 2005 19:29:08 +0200
From: Peter Sylvester <Peter.Sylvester@edelweb.fr>
User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "David A. Cooper" <david.cooper@nist.gov>
CC: pkix <ietf-pkix@imc.org>
Subject: Re: I-D ACTION:draft-ietf-pkix-scvp-01.txt
References: <E1DvKZw-0007on-JD@newodin.ietf.org> <42DEC295.7030803@nist.gov>
In-Reply-To: <42DEC295.7030803@nist.gov>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030009020806020608070208"
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <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.

--------------ms030009020806020608070208
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

It would be nice to see what remarks of make 3 months ago have been
taken into account, and which have not.

Anyway, so far, as I see, two months ago the discussion stopped
because some questions remained unanswered:

1 - The text still does not allow to include all elements that have
  been used in the decision making, as required by the requirement
  text.
  What problems do the authors see to add an SCVP reponse similar
  as an OCSP response. It is unacceptable to require an extension
  for this, since relaying and loop chaceking is already a supported
  feature.

2 - Russ Housley has not responded to the remark that an additional
  encapsulation of data types inside octet strings needs
  another invocation of a parsers.

3 - IMO, the ResponseFlags structure should be replaced by a bitstring
  with 4 named bits and an appropriate default value.

4-  The MUST concerning that an empty SEQUENCE of a responseflag
  MUST be omitted has not justification, is useless, and adds another
  rather irrelevant test case.

5 -  The ASN1 syntax should not use obsolete ASN.1 features.

6 - I think it has been said before that the ValidationAlgorithm should
  rather be a sequence of validation features, e.g. a new test  that
  is added globally an independantly from  any other algorithm
  requires that for all known algorithm, e.g. the name algorithm
  the parameters need to be repeated.

7 - specifying anKeyUsage as NULL and not just as an empty sequence
  requires two additional octets in the encoding, something that seems
  to be an important concern if I look at the response flag definition
  and the default handling.

8 - The usage of requesterRef for loop control is inconsistent with
  the definition of requesterRef which is named as of local relevance
  of the initial client and any intermediate server, thus it doesn' make
  sense to check for HIS own identifier.
  Since an initial client doesn't necessarily know whether a request is
  relayed, a relaying server cannot have one single requesterRef, since
  the client can accidentally use this one.
  at least the loop control should take into account the FIRST element
  in the requesterRef sequence.

  Since servers are required to encode the dns name of the server
  I don't think that a requester reference like this is the appropriate way
  to do loop control, and instead the requesterNames should be used.
  The dns name is not good anyway, since a server may relay to itself
  with a different backend policy, or just to a different URL on the same
  host. In the current text relaying implies uniqueness at the DNS level,
  a restriction that is not available at the transport level.

9 - The text about the BER encoding of the data structures does not
  say anything about the encoding of a CMS security envelope.
  Can one use XER encoding of a CMS envelope?

  I think the intent is to send ALWAYS a ContentInfo, which is either
  one of the SMIME types and which inside must have one encapsulated
  type defined in the doc, thus one does not send the raw CVRequest
  etc.

10 - There are three occurences of so called examples of CMS encapsulations
  which are not really examples, since they only differ in the content-type.
  Is there any reason why a ValPolRequest cannot benefit from CMS
  security encapsulations, and why does a ValPolResponse cannot alos
  be just authenticated in any way?

  It seems to me that both the citations of SignedData and AuthenticatedData
  should be either omitted or all of them folded into a single paragraph 
about
  'Data presentation and security envelopes' or actually all that could go
  into some  extension of 4.13 which seems to apply to ALL responses.

11 - 4.13 is inconsistent with the permitted use of TLS, which is 
mentioned in
  the security section, and in 3.2.5.2

12 - Using BER as an encoding rule is somewhat problematic when you want
  to refer to the HASH of the encoded request. It requires that the original
  encodings are kept in all cases.

Peter

--------------ms030009020806020608070208
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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOpDCC
BHIwggLfoAMCAQICBgoMz+gAPzANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G
A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs
UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNTAxMDYxMjI3MTlaFw0wNzAzMTcxMjI3MTlaMHAx
CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ
S0kxNTAzBgNVBAMMLFBldGVyIFNZTFZFU1RFUiA8UGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIu
ZnI+MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDn/izyem7Z1pUP/gpQDSzeGA/ZP4vo
VaCxcPWyssTYTAl6csAql2IIcYNVb6funaMNOY1q5oSNtlguFpOK3atQElBIMsfSh0CTuvUq
q2QDz1nHWOB96aU8G81+ZmC+iQOCAdG3qKWvMOzC0SzxKGbhTqDsjBvfYYk1Jk/Rb5TK0wID
AQABo4IBLjCCASowYgYDVR0RBFswWYEaUGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIuZnKkOzA5
MQswCQYDVQQGEwJGUjEQMA4GA1UECgwHRWRlbFdlYjEYMBYGA1UEAwwPUGV0ZXIgU1lMVkVT
VEVSMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD
VR0fBEMwQTA/oD2gO4Y5aHR0cDovL2VkZWxwa2kuZWRlbHdlYi5mci9jcmwvRWRlbFBLSS1F
ZGVsV2ViLVBlcnNHRU4uY3JsMB0GA1UdDgQWBBSSHP6djxj58tIi5VvjJbMZMXC/fDAfBgNV
HSMEGDAWgBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUA
A4IBfAANZYiEkyDqsT43U83wHLSYMGcEfmisT+WQrAAoHdlcIsnlHnufGnfmdpg5yvCQpl2U
TI7/w3LdaItoWq5oMZitqdoPW8Z+jy2pkd/DqYG1MkpEyZ0PA37Zn5yigQXAk4Nox7Lgiom8
1WDNgPesNRX7PRNa+RkQcD8MasfbHcZ2ycs1SxUxiCy6BUzhgSB8cNb2t9LVWWynvWuK1Wa5
V2ZCd3PlbKsrbWH8pafpFWUQm0S2BfKUWLDG9cje5bL7p5EpV4a8gFpbD5dq+PPJglT0Dvs9
F0EcrfL2l3JxGIkZmW7sfiUoefB9hTS9m3/TGvXcne4RYpVpEHFV5TathMuHfKAti6PhSely
LCqdPq/T9DHLJekBY0EA2yiVcKQnRZk7/pz0HImCPADOHSOWffJtc9b+Ak6HSDD1PlOSDfT+
udnrqwSAiuNN3hx1olPNxzVDu3jgiTSJFf2XJ1TnmGMT4pJmx7vkJkdE9sZvpiZwdVws37Nr
LqhH5fMZMIIEcjCCAt+gAwIBAgIGCgzP6AA/MA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT
AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV
BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA1MDEwNjEyMjcxOVoXDTA3MDMxNzEy
MjcxOVowcDELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsMD1NlcnZp
Y2UgRWRlbFBLSTE1MDMGA1UEAwwsUGV0ZXIgU1lMVkVTVEVSIDxQZXRlci5TeWx2ZXN0ZXJA
ZWRlbHdlYi5mcj4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOf+LPJ6btnWlQ/+ClAN
LN4YD9k/i+hVoLFw9bKyxNhMCXpywCqXYghxg1Vvp+6dow05jWrmhI22WC4Wk4rdq1ASUEgy
x9KHQJO69SqrZAPPWcdY4H3ppTwbzX5mYL6JA4IB0beopa8w7MLRLPEoZuFOoOyMG99hiTUm
T9FvlMrTAgMBAAGjggEuMIIBKjBiBgNVHREEWzBZgRpQZXRlci5TeWx2ZXN0ZXJAZWRlbHdl
Yi5mcqQ7MDkxCzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQDDA9QZXRl
ciBTWUxWRVNURVIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF
BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2ViLmZyL2NybC9F
ZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFJIc/p2PGPny0iLlW+Mlsxkx
cL98MB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MAkGA1UdEwQCMAAwDQYJKoZI
hvcNAQEFBQADggF8AA1liISTIOqxPjdTzfActJgwZwR+aKxP5ZCsACgd2VwiyeUee58ad+Z2
mDnK8JCmXZRMjv/Dct1oi2harmgxmK2p2g9bxn6PLamR38OpgbUySkTJnQ8DftmfnKKBBcCT
g2jHsuCKibzVYM2A96w1Ffs9E1r5GRBwPwxqx9sdxnbJyzVLFTGILLoFTOGBIHxw1va30tVZ
bKe9a4rVZrlXZkJ3c+VsqyttYfylp+kVZRCbRLYF8pRYsMb1yN7lsvunkSlXhryAWlsPl2r4
88mCVPQO+z0XQRyt8vaXcnEYiRmZbux+JSh58H2FNL2bf9Ma9dyd7hFilWkQcVXlNq2Ey4d8
oC2Lo+FJ6XIsKp0+r9P0Mcsl6QFjQQDbKJVwpCdFmTv+nPQciYI8AM4dI5Z98m1z1v4CTodI
MPU+U5IN9P652eurBICK403eHHWiU83HNUO7eOCJNIkV/ZcnVOeYYxPikmbHu+QmR0T2xm+m
JnB1XCzfs2suqEfl8xkwggW0MIIDT6ADAgECAgYJ+oiVOzEwDQYJKoZIhvcNAQEFBQAwUjEL
MAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2UgRWRlbFBL
STEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDQxMDA3MTU0MzMwWhcNMTEwODEyMTU0
MzMwWjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2Vydmlj
ZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTjCCAZwwDQYJKoZI
hvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bcrJKIlnAPn6eH8V1M
ORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5JfuDjU6Aq0RzmjqTWDe
1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WLwHLA+sIKFzA/CCRt
qeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQNHeCgbUvebvAT9Hd
UGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy4DazzXfZosKeJATH
pyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38psgnVLtPPITgOZrS
cV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+EiISL7aJHQcJRoNB
CdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4G/MIG8MDoGA1UdHwQzMDEwL6AtoCuGKWh0
dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8GA1UdEwQIMAYBAf8C
AQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNV
HQ4EFgQUnuUPwRSVSRzdWl1enK7NAW8vlHkwHwYDVR0jBBgwFoAUqNkrj9SwZ7q9SVy8M/x3
UhG5Z50wDQYJKoZIhvcNAQEFBQADggJOAFZV+1m/H+Qud9iUQJnvZR8R/adID02c2B3aOUUy
4/4dxBb4UU1kW8DTUpD57Pjuocfvdg4AfQi7zgSQ8/NUGxNU4CPxtADZVrZtmrpKCjBh1tNz
QbNbdP91KtP+Di0BpidqNwG00CC9j2EnBY88AsqKE28Rmw4eQ9/M/q/GbXsAfEsHV0IQjM7u
US+usowZwm3Mwa5oF+6gmShSc/Wz8iIURxg4lTQto3AoBsiLJelq83I4XRQ0goXYGcM8xXYj
PDioidvY5pSfT4qBR1Bx/vh+xD2evWyFbpuB99iuuewoELX8db7P74QEHhw6Bv1yxLYXGamq
Uxo60WT/UCFjVSy3C/dLrraUZA4gh7Q5G+3/Fal62Qx+1rUEC2YbogEKggonklzUXA+sUbCf
Ad5nZQ0eSszwKt8jmYoHfQ6rUMde0ZJD08n5HAot9hpl9R65j9fdPz9uTeANcRocftHfgM7Y
rQyruWuFxgMUV80fD4RC9ej5KbLyO8jtgESjOCGXeJ95kXXP8vmW73xCYkJ9Pg7Op30o43l6
PV7vej3gdmSQISY+s+J3arz+bccljJCrKHBad3918/LjJ55sRtSb7mfQGti2UcxtJAa2NmUL
d+BIv0MUuC6+k2yIIQKcLbDuuk8lLJmwWuYt1OLHEskZxOm7D7nRwe7ZNlTIZvR/VFWxlY18
k488tH9qcusIw8+7uXeHOZHyFUOHMINJZO9mq9HwGMC4v1xiPwoAJkzFtHf3D9VAholjhEFg
d28aJSs6qN15PXDgDjptAl34eoUxggKuMIICqgIBATBlMFsxCzAJBgNVBAYTAkZSMRAwDgYD
VQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNVBAMTF0VkZWxQ
S0kgRWRlbFdlYiBQZXJzR0VOAgYKDM/oAD8wCQYFKw4DAhoFAKCCAZ8wGAYJKoZIhvcNAQkD
MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUwNzIxMTcyOTA4WjAjBgkqhkiG9w0B
CQQxFgQU0TFQ3wvdszw+s/4nR29CcTMzg0owUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D
BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC
ASgwdAYJKwYBBAGCNxAEMWcwZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEY
MBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVy
c0dFTgIGCgzP6AA/MHYGCyqGSIb3DQEJEAILMWegZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UE
ChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJ
IEVkZWxXZWIgUGVyc0dFTgIGCgzP6AA/MA0GCSqGSIb3DQEBAQUABIGAC8tffLYTJYUEoQp0
uZpKJFqCtOQlwotI3z8j/aY8h7dnFsB+vk/yII0f3SFcPy3pk4hQ9IsoGt2Pv9cF8BRH/TX8
OYMaSkqn3KSdpa4KJlQtk0xVhjB6KanjFCQs8+4AWSQdOBBZap70+7WXlEpHetIs7v+UC1s7
fq7cpcVDNUwAAAAAAAA=
--------------ms030009020806020608070208--

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 j6LDXANK057204; Thu, 21 Jul 2005 06:33: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 j6LDXA0p057203; Thu, 21 Jul 2005 06:33:10 -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 j6LDX9Hr057151 for <ietf-pkix@imc.org>; Thu, 21 Jul 2005 06:33:09 -0700 (PDT) (envelope-from denis.pinkas@bull.net)
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id PAA26652; Thu, 21 Jul 2005 15:48:54 +0200
Received: from frcls4013 ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with SMTP id 2005072115340052:944 ; Thu, 21 Jul 2005 15:34:00 +0200 
Date: Thu, 21 Jul 2005 15:34:10 +0100
From: "Denis Pinkas" <denis.pinkas@bull.net>
To: "David A. Cooper" <david.cooper@nist.gov>, "Santosh Chokhani" <chokhani@orionsec.com>
Cc: "'pkix'" <ietf-pkix@imc.org>
Subject: Re: Re: Correction to be done to <draft-pinkas-pkix-conf-crl-validation-01.txt>
X-mailer: Foxmail 5.0 [-fr-]
Mime-Version: 1.0
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 21/07/2005 15:34:00, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 21/07/2005 15:34:03, Serialize complete at 21/07/2005 15:34:03
Message-ID: <OFD37E3673.1FFAFE3D-ONC1257045.004A865A@frcl.bull.fr>
Content-Transfer-Encoding: 7bit
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>

David,

>Santosh Chokhani wrote:
>
>>Denis,
>>
>>A sentence in 3280 may be ambiguous. The definition and State Machines are
>>not at odds. Also, if you point to the specific location of the sentence in
>>3280, I will be happy to determine if this is being taken out of context or
>>not.

>Santosh,

>Denis is referring to the final sentence in the following paragraph:

>      CRL issuers issue CRLs.  The CRL issuer is either the CA or an entity
>      that has been authorized by the CA to issue CRLS.  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.

>I believe the problem is that Denis is interpreting this sentence as a 
>definition when it is not one.  Here is the definition of indirect CRL 
>in X.509:

You mean that RFC 3280 contains no formal definition of what an 
Indirect CRL is. 

A good practice for RFCs would be to follow ISO editing rules where 
there MUST be a separate section for formal definitions.  :-)

However the extracted sentence is the earliest use of the wording "indirect CRL" 
in the document saying what an indirect CRL is. It is not explained later on.

The definition from X.509 you mention is thus not an RFC 3280 definition.

>      indirect CRL (iCRL):  A revocation list that at least contains 
>revocation information
>      about certificates issued by authorities other than that which 
>issued this CRL.

The X.509 definition is NOT :

indirect CRL (iCRL):  A revocation list that at least contains revocation information 
about certificates issued by *an authority* other than that which issued this CRL.

The X.509 definition is NOT either:

indirect CRL (iCRL):  A revocation list that at least contains revocation information 
about certificates issued by *one or more* authorities other than that which issued 
this CRL.

>In order to help avoid this confusion in 3280bis, I have removed the 
>sentence "Whenever ...." from 3280bis draft -01 and have added the 
>following paragraph:
>
>      If the scope of the CRL includes one or more certificates issued by
>      an entity other than the CRL issuer, then it is an indirect CRL. 

Arhh!  Once again: "certificates issued by .. CRL issuer". 

>      The
>      scope of an indirect CRL may be limited to certificates issued by a
>      single CA or may include certificates issued by multiple CAs.  

This would have been true if the X.509 definition had been written differently.

>      If the
>      issuer of the indirect CRL is a CA, then the scope of the indirect
>      CRL MAY include certificates issued by the issuer of the CRL.

This is ruled out by the current quoted sentence. 

>I believe that this text is fully consistent with the X.509 definition 
>of indirect CRL 

Sorry, it is not.

> as well as the descriptions of the indirectCRL flag and 
>the certificateIssuer CRL entry extension in both X.509 and RFC 3280 and 
>the algorithm in section 6.3.3 of RFC 3280.

Page 59 is stating:

   "The CRL issuer MUST assert the indirectCRL boolean, if the scope of
   the CRL includes certificates issued by authorities other than the
   CRL issuer.  The authority responsible for each entry is indicated by
   the certificate issuer CRL entry extension (section 5.3.4)".

It is clear that this flag is present when there are certificate issuer CRL entry extensions.

Thus, in the simplest case, where a CA designates another entity to issue revocation 
status information for some of its certificates, the certificate issuer CRL entry extension 
is not needed, neither the indirectCRL boolean.

The way to fix the problem is simple: either adopt (but add "may") the definition of X.509 
or make it clearer by saying:

indirect CRL (iCRL):  A revocation list that at least *may* contain revocation information 
about certificates issued by more than one CA.

and add for clarification:

delegatedCRL (dCRL):  A revocation list issued by a CRL Issuer that received and accepted 
a delegation for issuing revocation status information from a single CA, that contains 
revocation information about certificates issued by that single CA.

See processing details for these two cases in <draft-pinkas-pkix-conf-crl-validation-02.txt> 
that is now available.

The benefits are:

 1) a very simple CRL processing when the CRL contains revocation information 
    about certificates from a single CA. 

 2) a (much) more complex CRL processing when the CRL contains revocation 
    information about certificates from more than one CA, including the (seldom ?)
    case where the CRL issuer is also a CA.

Denis

>Dave

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 j6LDRnaL055113; Thu, 21 Jul 2005 06:27: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 j6LDRncU055112; Thu, 21 Jul 2005 06:27:49 -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 j6LDRlv9055064 for <ietf-pkix@imc.org>; Thu, 21 Jul 2005 06:27:47 -0700 (PDT) (envelope-from denis.pinkas@bull.net)
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id PAA27402; Thu, 21 Jul 2005 15:43:42 +0200
Received: from frcls4013 ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with SMTP id 2005072115284949:943 ; Thu, 21 Jul 2005 15:28:49 +0200 
Date: Thu, 21 Jul 2005 15:28:59 +0100
From: "Denis Pinkas" <denis.pinkas@bull.net>
To: "'pkix'" <ietf-pkix@imc.org>, "Santosh Chokhani" <chokhani@orionsec.com>
Subject: Re: RE: 3280bis: CRL validation: what is wrong and/or missing in section 6.3
X-mailer: Foxmail 5.0 [-fr-]
Mime-Version: 1.0
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 21/07/2005 15:28:49, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 21/07/2005 15:28:51, Serialize complete at 21/07/2005 15:28:51
Message-ID: <OFC38EE938.C3EC3A75-ONC1257045.004A0CDB@frcl.bull.fr>
Content-Transfer-Encoding: 7bit
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>

Santosh,

It does no make sense to have a complex model that is even not described 
in an I-D, wheras the solution stands in two lines.

But you are probably right on one point : I also wonder if the WG chairs 
and AD intend to support the promulgation of this model.

>Stefan,

>The algorithm is trying to be faithful to the standard.  If the standard can
>be profiled and constrained further, so can the algorithm.  That is trivial.
>I am proposing an approach and not simply a point solution.

>That said, I would at least add to your profile, the indirect CRL being the
>trust anchor itself or a certificate issued by the trust anchor that is used
>to build the certificate certification path.

"the indirect CRL being the trust anchor itself" would completely change 
the model since you would add local trust conditions for CRLs, in addition 
to the trust conditions for the certificates.

"certificate issued by the trust anchor that is used to build the certificate 
certification path" would be another case of trust conditions: 
beware, you are entering the zillion cases zone.

Denis

>-----Original Message-----
>From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On
>Behalf Of Stefan Santesson
>Sent: Monday, July 18, 2005 1:22 PM
>To: Santosh Chokhani; pkix
>Subject: RE: 3280bis: CRL validation: what is wrong and/or missing in
>section 6.3
>
>
>
>Santosh,
>
>I'm not concerned with direct CRLs here since they are issued by the target
>CA. Having said that, I do of course agree that one must not accept an
>alternate path to a direct CRL even if CRL issuer name match the name of the
>issuing CA.
>
>Within this thread I'm only concerned with indirect CRLs and for those I
>currently think we should be more restrictive than your algorithm suggests.
>
>
>Stefan Santesson
>Program Manager, Standards Liaison
>Windows Security
> 
>
>> -----Original Message-----
>> From: owner-ietf-pkix@mail.imc.org
>[mailto:owner-ietf-pkix@mail.imc.org]
>> On Behalf Of Santosh Chokhani
>> Sent: den 18 juli 2005 09:11
>> To: 'pkix'
>> Subject: RE: 3280bis: CRL validation: what is wrong and/or missing in 
>> section 6.3
>> 
>> 
>> Stefan,
>> 
>> One more time: the solution is air-tight for direct CRL.
>> 
>> For indirect CRL, we can tighten the solution by further profiling or 
>> restricting the standard. So, we can do what we want.
>> 
>> -----Original Message-----
>> From: Stefan Santesson [mailto:stefans@microsoft.com]
>> Sent: Monday, July 18, 2005 12:05 PM
>> To: Santosh Chokhani; pkix
>> Subject: RE: 3280bis: CRL validation: what is wrong and/or missing in 
>> section 6.3
>> 
>> 
>> When I last reviewed your algorithm it required the CRL issuer cert to
>be
>> issued by any CA in the target cert path. My current thinking is to be 
>> even more restrictive.
>> 
>> Either to require the CRL issuer cert to be issued explicitly by the 
>> target CA or maybe also by its parent CA, but not by any CA further up 
>> in the path.
>> 
>> 
>> Stefan Santesson
>> Program Manager, Standards Liaison
>> Windows Security
>> 
>> 
>> > -----Original Message-----
>> > From: owner-ietf-pkix@mail.imc.org
>> [mailto:owner-ietf-pkix@mail.imc.org]
>> > On Behalf Of Santosh Chokhani
>> > Sent: den 13 juli 2005 04:50
>> > To: 'pkix'
>> > Subject: RE: 3280bis: CRL validation: what is wrong and/or missing
>in
>> > section 6.3
>> >
>> >
>> > Stefan,
>> >
>> > How is this different from my proposal for matching the two
>> certification
>> > path?
>> >
>> > Also, this will not overly constrain indirect CRL issuer.
>> >
>> > -----Original Message-----
>> > From: owner-ietf-pkix@mail.imc.org
>> [mailto:owner-ietf-pkix@mail.imc.org]
>> > On
>> > Behalf Of Stefan Santesson
>> > Sent: Wednesday, July 13, 2005 6:32 AM
>> > To: David A. Cooper; Denis Pinkas
>> > Cc: pkix
>> > Subject: RE: 3280bis: CRL validation: what is wrong and/or missing
>in
>> > section 6.3
>> >
>> >
>> >
>> > David,
>> >
>> > I agree with your comments.
>> >
>> > However on the following:
>> >
>> > > Even though X.509 requires that names be unambiguous, there does
>> seem
>> > to
>> > > be consensus within the PKIX WG that 3280bis should impose some 
>> > > restrictions of the certification path used to validate a CRL in
>> order
>> > > to address the concern that a name collision might occur despite
>> > X.509's
>> > > prohibition.  However, at the moment, WG consensus seems to be in
>> > favor
>> > > of only requiring that the certification path for the CRL use the
>> same
>> > > trust anchor as the certification path for the corresponding CRL.
>> > There
>> > > is language about this in the security considerations section.  In
>> > order
>> > > for 3280bis to be even more restrictive, it would need to be shown
>> > that
>> > > there is WG consensus in favor of imposing such restrictions.
>> >
>> > I would like to add my vote to be more restrictive than just
>> terminating
>> > at
>> > the same root.
>> >
>> > I think the path processing complexity would be much simpler if the
>> CRL
>> > issuer certificate had to be issued by the CA that issued the target 
>> > certificate (the target CA). It would also eliminate potential name 
>> > collision problems.
>> >
>> > Perhaps we need to also consider allowing the parent of the target
>CA
>> to
>> > issue the CRL issuer cert but I see no reason to allow the CRL
>issuer
>> cert
>> > to be issued by a CA that is not in the target cert path or by a CA
>> higher
>> > in the target cert path.
>> >
>> >
>> > Stefan Santesson
>> > Program Manager, Standards Liaison
>> > Windows Security
>> >
>> >
>> > > -----Original Message-----
>> > > From: owner-ietf-pkix@mail.imc.org
>> > [mailto:owner-ietf-pkix@mail.imc.org]
>> > > On Behalf Of David A. Cooper
>> > > Sent: den 11 juli 2005 19:42
>> > > To: Denis Pinkas
>> > > Cc: pkix
>> > > Subject: Re: 3280bis: CRL validation: what is wrong and/or missing
>> in
>> > > section 6.3
>> > >
>> > >
>> > > Denis Pinkas wrote:
>> > >
>> > > >
>> > > > 3280bis: CRL validation: what is wrong and/or missing in section
>> > 6.3.
>> > > >
>> > > > 1. The very first sentence states:
>> > > >
>> > > > " This section describes the steps necessary to determine if a
>> > > >   certificate is revoked or on hold status when CRLs are the
>> > revocation
>> > > >   mechanism used by the certificate issuer".
>> > > >
>> > > > a) This section should describe the steps necessary to determine
>> > > >   if the revocation status of the certification path* is :
>> REVOKED,
>> > > >   NOT_REVOKED or UNKNOWN, instead of simply determine if the
>> > > >   *target certificate* is REVOKED. So the sentence is incorrect.
>> > >
>> > > The algorithm in section 6.3 is used to determine the status of a 
>> > > particular certificate, not a certification path, so the text is 
>> > > correct.  However, as part of certification path validation,
>section
>> > > 6.1.3, step (a)(3) states that, for each certificate in the path,
>> one
>> > > must verify that the certificate is not revoked or on hold, and it 
>> > > indicates that if status is determined using CRLs that section 6.3 
>> > > indicates how the status can be determined.
>> > >
>> > > > b) The current text mentions the return of the "on hold" status.
>> > > >   However since CRLreason is not mentioned as an output
>parameter
>> > > >   of the algorithm, this may not be the case (the only algorithm
>> > > >   output is currently the revocation status of the certificate).
>> > >
>> > > The variable cert_status is output from the algorithm.  In section
>> > 6.3.3
>> > > steps (i) and (j), the value of cert_status is set to the value
>from
>> > the
>> > > reason code CRL entry extension if the certificate is found to be 
>> > > revoked and the reason code extension is present.
>> > >
>> > > > 2. The text states: " Conforming implementations that support
>CRLs
>> > > > are not required to implement this algorithm, but they MUST be 
>> > > > functionally equivalent to the external behavior resulting from
>> this
>> > > > procedure".
>> > >
>> > > If you believe that this sentence and some of text quoted below
>need
>> > to
>> > > be more precisely worded, please provide text for consideration.
>> > >
>> > > > This sentence is incorrect since the algorithm would mandate the 
>> > > > support of many certificate extensions, CRL extensions and CRL
>> entry
>> > > > extensions that conforming relying party applications are NOT 
>> > > > REQUIRED to support. The current algorithm has many errors in it 
>> > > > cannot be easily simplified, if less than "all options" are 
>> > > > supported by a relying party.
>> > > >
>> > > > 3. The text states: "This algorithm assumes that all of the
>needed
>> > > > CRLs are available in a local cache".
>> > > >
>> > > > This sentence is incorrect, because it may happen that the
>"right"
>> > > > or a "current" CRL is  unavailable and thus absent; in such a
>case
>> > > > the algorithm terminates with "UNDETERMINED" or "UNKNOWN".
>> > >
>> > > I don't understand what you mean by incorrect, the sentence states
>> an
>> > > assumption, not a fact.
>> > >
>> > > > 4. The text states:
>> > > >
>> > > > "This algorithm begins by assuming the certificate is not
>> revoked."
>> > > >
>> > > > This sentence is incorrect, the algorithm should begin by
>assuming
>> > > > the status of the certificate is "UNDETERMINED" or "UNKNOWN".
>> > >
>> > > cert_status is initialized to UNREVOKED.  If the status cannot be 
>> > > determined, cert_status gets changed to UNDETERMINED as the final
>> > step.
>> > >
>> > > > 5. The text states, [omitting what is relevant to delta CRLs]
>> > > >
>> > > > "(a)  Update the local CRL cache by obtaining a complete CRL [ ]
>:
>> > > >
>> > > >         (1)  If the current time is after the value of the CRL
>> next
>> > > >         update field, then do one of the following :
>> > > >
>> > > >            (i) [ ].
>> > > >
>> > > >            (ii)  Update the local CRL cache with a current
>> complete
>> > > >            CRL, verify that the current time is before the next
>> > update
>> > > >            value in the new CRL, [ ]".
>> > > >
>> > > > This is incorrect. If the "current" CRL cannot be found, then it
>> is
>> > > > still possible to use an older CRL to demonstrate that the
>> > certificate
>> > > > was REVOKED. Of course, when using an older CRL it is not
>possible
>> > > > to demonstrate that the certificate was NOT_REVOKED.
>> > >
>> > > Section 6.3 states "Further, if the next update time of a CRL has 
>> > > passed, the algorithm assumes a mechanism to fetch a current CRL
>and
>> > > place it in the local CRL cache."  So, while the scenario you
>> describe
>> > > could happen, section 6.3 states that the algorithm does not
>address
>> > > this scenario.
>> > >
>> > > > 6. The current algorithm cannot make sure that an emergency CRL
>(
>> > > > i.e. the latest captured CRL) will be used if more than one
>> "valid"
>> > > > CRLs are found in the local cache.
>> > >
>> > > True.  As long as untrusted mechanisms are used to distribute
>CRLs,
>> > the
>> > > relying party cannot ensure that it has the latest CRL.
>> > >
>> > > > 7. The text states:
>> > > >
>> > > >   (f)  Obtain and validate the certification path for the
>complete
>> > CRL
>> > > >   issuer.  If a key usage extension is present in the CRL
>issuer's
>> > > >   certificate, verify that the cRLSign bit is set.
>> > > >
>> > > >   (g)  Validate the signature on the complete CRL using the
>public
>> > key
>> > > >   validated in step (f).
>> > > >
>> > > > The text is unclear about what is meant by :" validate the
>> > certification
>> > > > path for the complete CRL issuer". In order to solve the problem
>> of
>> > > > identical CRL Issuer names or identical CA names, it is needed
>to
>> > say
>> > > > that the certification path that has been used to validate the
>> > target
>> > > > certificate MUST also be used.
>> > >
>> > > Would you like for step (f) to say that the validation should be 
>> > > performed as specified in section 6.1 and/or section 6.2?
>> > >
>> > > Even though X.509 requires that names be unambiguous, there does
>> seem
>> > to
>> > > be consensus within the PKIX WG that 3280bis should impose some 
>> > > restrictions of the certification path used to validate a CRL in
>> order
>> > > to address the concern that a name collision might occur despite
>> > X.509's
>> > > prohibition.  However, at the moment, WG consensus seems to be in
>> > favor
>> > > of only requiring that the certification path for the CRL use the
>> same
>> > > trust anchor as the certification path for the corresponding CRL.
>> > There
>> > > is language about this in the security considerations section.  In
>> > order
>> > > for 3280bis to be even more restrictive, it would need to be shown
>> > that
>> > > there is WG consensus in favor of imposing such restrictions.
>> > >
>> > > > 8. There is no handling of the Certificate Issuer CRL entry
>> > extension,
>> > > > when present, which may lead to incorrect results.
>> > >
>> > > Section 6.3.3, steps (i) and (j) refer to section 5.3.4, which
>> > indicates
>> > > how to process this extension.

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 j6LDQEiZ054536; Thu, 21 Jul 2005 06:26: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 j6LDQEt8054535; Thu, 21 Jul 2005 06:26:14 -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 j6LDQCuo054485 for <ietf-pkix@imc.org>; Thu, 21 Jul 2005 06:26:13 -0700 (PDT) (envelope-from denis.pinkas@bull.net)
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id PAA42752 for <ietf-pkix@imc.org>; Thu, 21 Jul 2005 15:42:06 +0200
Received: from frcls4013 ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with SMTP id 2005072115271393:941 ; Thu, 21 Jul 2005 15:27:13 +0200 
Date: Thu, 21 Jul 2005 15:27:24 +0100
From: "Denis Pinkas" <denis.pinkas@bull.net>
To: "pkix" <ietf-pkix@imc.org>
Subject: draft-pinkas-pkix-conf-crl-validation-02.txt is available
X-mailer: Foxmail 5.0 [-fr-]
Mime-Version: 1.0
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 21/07/2005 15:27:13, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 21/07/2005 15:27:15, Serialize complete at 21/07/2005 15:27:15
Message-ID: <OF11081D33.03FD428A-ONC1257045.0049E783@frcl.bull.fr>
Content-Transfer-Encoding: 7bit
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>

<draft-pinkas-pkix-conf-crl-validation-02.txt> is now available at:
http://www.ietf.org/internet-drafts/draft-pinkas-pkix-conf-crl-validation-02.txt

There is a common section for any kind of CRL.
 See section 6.3.3.1  CRL Processing start for all applications

Note that "old CRLs" may be selected in that phase and this may be quite useful, 
if it can be found that the target certificate was already revoked some time ago.
Note also that more than one CRL may be found in the local cache. 
The current algorithm does not support these cases because it is making 
incorrect-different-others assumptions.

Then the document makes a clear distinction between three kinds of processing 
where the complexity goes from simple to complex:

1 - What conformant applications shall support. This covers CRLs that contain certificates 
    from a single CA. The CRL may be issued by the CA or by a CRL issuer (that is not a CA) 
    designated by a CA.  

    See section 6.3.3.2  CRL Processing for conforming applications.

2 - If an application supports Certificate Issuer CRL entry extensions, then this section applies.
    This covers CRLs that *may* contain certificates from more than one CA.

    See section 6.3.3.3. CRL Processing for applications supporting 
    Certificate Issuer CRL entry extensions.

3 - If an application supports delta-CRLs. I have left the details for David Copper 
    who is much more expert than I am on that topic.

    See the nearly empty section 6.3.3.4. CRL Processing for applications supporting delta CRLs.

Note : Santosh, please read section 6.3.3.3. and you will see that it is possible 
          to go backwards looking for Certificate Issuer CRL entry extensions.

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 j6KLUNji022176; Wed, 20 Jul 2005 14:30: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 j6KLUNvl022175; Wed, 20 Jul 2005 14:30:23 -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 (rimp2.nist.gov [129.6.16.227]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6KLUM8S022161 for <ietf-pkix@imc.org>; Wed, 20 Jul 2005 14:30:23 -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.13.1/8.13.1) with ESMTP id j6KLUKcj016348 for <ietf-pkix@imc.org>; Wed, 20 Jul 2005 17:30:20 -0400
Received: from [129.6.54.72] (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id j6KLTm6u012446 for <ietf-pkix@imc.org>; Wed, 20 Jul 2005 17:29:48 -0400 (EDT)
Message-ID: <42DEC295.7030803@nist.gov>
Date: Wed, 20 Jul 2005 17:31:01 -0400
From: "David A. Cooper" <david.cooper@nist.gov>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040804
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: pkix <ietf-pkix@imc.org>
Subject: Re: I-D ACTION:draft-ietf-pkix-rfc3280bis-01.txt
References: <E1DvKZw-0007on-JD@newodin.ietf.org>
In-Reply-To: <E1DvKZw-0007on-JD@newodin.ietf.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: david.cooper@nist.gov
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

Internet-Drafts@ietf.org wrote:

>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 
>                          Certificate and Certificate Revocation List (CRL) Profile
>	Author(s)	: D. Cooper, et al.
>	Filename	: draft-ietf-pkix-rfc3280bis-01.txt
>	Pages		: 138
>	Date		: 2005-7-20
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-01.txt
>  
>

I have posted two "diff" files on the NIST Web site: one showing the 
differences between 3280bis-00 and 3280bis-01 and one showing the 
differences between RFC 3280 and 3280bis-01.  They are available at:

http://csrc.nist.gov/pki/documents/PKIX/draft3280bis-00todraft3280bis-01_diff.html

and

http://csrc.nist.gov/pki/documents/PKIX/rfc3280todraft3280bis-01_diff.html

While I would encourage people to review the "diff" files to see what 
changes have been made, here is a list summarizing some of the changes 
that were made between draft -00 and draft -01:

1) The descriptions of some of the keyUsage bits have been changed based 
on discussions on the PKIX mail list.

2) Section 4.2.1.9 has been modified to clarify that while conforming CA 
certificates MUST include a basicConstraints extension, applications MAY 
use certificates that do not include the basicConstraints extension as 
intermediate certificates if the certificates are version 1 or 2.

3) The rules for specifying name constraints for URIs have been changed 
back to the rules that were in RFC 3280.

4) In order to align with draft-zeilenga-ldap-x509-01.txt, all example 
LDAP URIs (in the cRLDistributionPoints, authorityInfoAccess, and 
subjectInfoAccess extensions) specify the ";binary" option.

5) Sections 5 and 5.2.5 have been modified to clarify the meaning of an 
indirect CRL.

6) Section 6.1 includes a new paragraph that explains that the path 
validation algorithm is not intended to verify that certificates and 
CRLs are issued in conformance with the PKIX profile.

7) The sample certificates in appendix C have been changed.

Dave

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 j6KJo6hD012122; Wed, 20 Jul 2005 12:50: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 j6KJo6Na012121; Wed, 20 Jul 2005 12:50:06 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from newodin.ietf.org ([132.151.6.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6KJo4Xx012106 for <ietf-pkix@imc.org>; Wed, 20 Jul 2005 12:50:05 -0700 (PDT) (envelope-from mlee@newodin.ietf.org)
Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1DvKZw-0007on-JD; Wed, 20 Jul 2005 15:50:04 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
Cc: ietf-pkix@imc.org
From: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-pkix-rfc3280bis-01.txt 
Message-Id: <E1DvKZw-0007on-JD@newodin.ietf.org>
Date: Wed, 20 Jul 2005 15:50:04 -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 
                          Certificate and Certificate Revocation List (CRL) Profile
	Author(s)	: D. Cooper, et al.
	Filename	: draft-ietf-pkix-rfc3280bis-01.txt
	Pages		: 138
	Date		: 2005-7-20

This memo profiles the X.509 v3 certificate and X.509 v2 Certificate
   Revocation List (CRL) for use in the Internet.  An overview of this
   approach and model are provided as an introduction.  The X.509 v3
   certificate format is described in detail, with additional
   information regarding the format and semantics of Internet name
   forms.  Standard certificate extensions are described and two
   Internet-specific extensions are defined.  A set of required
   certificate extensions is specified.  The X.509 v2 CRL format is
   described in detail, and required extensions are defined.  An
   algorithm for X.509 certification path validation is described.  An
   ASN.1 module and examples are provided in the appendices.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-01.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-rfc3280bis-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-rfc3280bis-01.txt".

NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2005-7-20150758.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-rfc3280bis-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-rfc3280bis-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2005-7-20150758.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 j6KJo5Ib012114; Wed, 20 Jul 2005 12:50: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 j6KJo5Ng012113; Wed, 20 Jul 2005 12:50:05 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from newodin.ietf.org ([132.151.6.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6KJo4de012107 for <ietf-pkix@imc.org>; Wed, 20 Jul 2005 12:50:05 -0700 (PDT) (envelope-from mlee@newodin.ietf.org)
Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1DvKZw-0007os-KF; Wed, 20 Jul 2005 15:50:04 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
Cc: ietf-pkix@imc.org
From: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-pkix-scvp-19.txt 
Message-Id: <E1DvKZw-0007os-KF@newodin.ietf.org>
Date: Wed, 20 Jul 2005 15:50:04 -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-19.txt
	Pages		: 77
	Date		: 2005-7-20

SCVP allows a client to delegate certificate path construction and
   certificate path validation to a server.  The path construction or
   validation (e.g. making sure that none of the certificates in the
   path are revoked) is performed according to a validation policy,
   which contains one or more trust anchors.  It allows simplification
   of client implementations and use of a set of predefined validation
   policies.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-scvp-19.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-19.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-19.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:	<2005-7-20151042.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-scvp-19.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-scvp-19.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2005-7-20151042.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 j6JE2mNY093843; Tue, 19 Jul 2005 07:02: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 j6JE2mEe093842; Tue, 19 Jul 2005 07:02:48 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from SMTP.Lamicro.com (66-163-8-251.ip.tor.radiant.net [66.163.8.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6JE2kIp093835 for <ietf-pkix@imc.org>; Tue, 19 Jul 2005 07:02:47 -0700 (PDT) (envelope-from thierry.moreau@connotech.com)
Received: from Spooler by SMTP.Lamicro.com (Mercury/32 v4.01b) ID MO004B95; 19 Jul 2005 10:04:45 -0400
Received: from spooler by Lamicro.com (Mercury/32 v4.01b); 19 Jul 2005 10:04:34 -0400
Received: from connotech.com (209.71.204.108) by SMTP.Lamicro.com (Mercury/32 v4.01b) with ESMTP ID MG004B94; 19 Jul 2005 10:04:17 -0400
Message-ID: <42DD0EFE.6000301@connotech.com>
Date: Tue, 19 Jul 2005 10:32:30 -0400
From: Thierry Moreau <thierry.moreau@connotech.com>
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jean-Marc Desperrier <jmdesp@free.fr>
CC: ietf-pkix@imc.org
Subject: Re: A non-critical self-signed certificate extension for trust anchr renewal ...
References: <42D6F608.7000704@connotech.com> <42DCD23C.6060209@free.fr>
In-Reply-To: <42DCD23C.6060209@free.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>

Jean-Marc Desperrier wrote:
> 
>  [...]
> 
> I see two gains in your proposition :
> - a smaller message (but probably not very relevant)
> - the ability to still be able to update a key after it is compromised
> 
> The second point may look very useful, but in real life good procedures
> should enable to keep the trust anchor private key at about the same
> level of security as the future trust anchor key in your mechanism.
> 

For the period of use of the current trust anchor key, future trust 
anchor keys need not even be stored in any computing device. Perhaps a 
not-used key is a little easier to protect than a production key! It 
unlikely that "real life good procedures" offer the same level of 
protection for both. Obviously, there is a value judgment about 
"adequate" level of protection. We offer a mechanism to raise the 
achievable level of protection for future trust anchor keys.

Also, by providing an opportunity to automate the trust anchor key 
renewal operation, we facilitate shorter cryptoperiods for trust anchor 
keys (e.g. NIST SP800-57, "Recommendation for Key Management", part 1, 
section 8.1.5.1.1.1 "Distribution of a Trust Anchor's Public Key in a PKI").

Regards.

-- 

- Thierry Moreau

CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, Qc
Canada   H2M 2A1

Tel.: (514)385-5691
Fax:  (514)385-5900

web site: http://www.connotech.com
e-mail: thierry.moreau@connotech.com

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 j6JBl1bb045038; Tue, 19 Jul 2005 04:47: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 j6JBl1QD045037; Tue, 19 Jul 2005 04:47:01 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from afir ([12.16.56.39]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6JBl0gn044996 for <ietf-pkix@imc.org>; Tue, 19 Jul 2005 04:47:00 -0700 (PDT) (envelope-from Internet-Drafts@ietf.org)
Received: from mail pickup service by afir with Microsoft SMTPSVC; Tue, 19 Jul 2005 07:47:54 -0400
Received: from mail64.messagelabs.com ([216.82.255.51]) by afir with Microsoft SMTPSVC(5.0.2195.6713); Mon, 18 Jul 2005 16:07:14 -0400
X-VirusChecked: Checked
X-Env-Sender: i-d-announce-bounces@ietf.org
X-Msg-Ref: server-9.tower-64.messagelabs.com!1121717152!41688272!1
X-StarScan-Version: 5.4.15; banners=-,-,anspach.com
X-Originating-IP: [132.151.6.71]
X-SpamReason: No, hits=0.3 required=7.0 tests=MIME_BOUND_NEXTPART, NO_REAL_NAME
Received: (qmail 22117 invoked from network); 18 Jul 2005 20:05:53 -0000
Received: from megatron.ietf.org (132.151.6.71) by server-9.tower-64.messagelabs.com with SMTP; 18 Jul 2005 20:05:53 -0000
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dubdd-0008Fb-Ei; Mon, 18 Jul 2005 15:50:53 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dubct-0007vh-DF for i-d-announce@megatron.ietf.org; Mon, 18 Jul 2005 15:50:08 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10381 for <i-d-announce@ietf.org>; Mon, 18 Jul 2005 15:50:04 -0400 (EDT)
Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Duc6J-0006XH-3H for i-d-announce@ietf.org; Mon, 18 Jul 2005 16:20:32 -0400
Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1Dubco-0002Hk-2y; Mon, 18 Jul 2005 15:50:02 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: <E1Dubco-0002Hk-2y@newodin.ietf.org>
Date: Mon, 18 Jul 2005 15:50:02 -0400
X-Spam-Score: 0.4 (/)
X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b
Cc: ietf-pkix@imc.org
Subject: I-D ACTION:draft-ietf-pkix-lightweight-ocsp-profile-02.txt 
X-BeenThere: i-d-announce@ietf.org
X-Mailman-Version: 2.1.5
Reply-To: internet-drafts@ietf.org
List-Id: i-d-announce.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/i-d-announce>, <mailto:i-d-announce-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:i-d-announce@ietf.org>
List-Help: <mailto:i-d-announce-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/i-d-announce>, <mailto:i-d-announce-request@ietf.org?subject=subscribe>
X-OriginalArrivalTime: 18 Jul 2005 20:07:14.0671 (UTC) FILETIME=[4A5AA7F0:01C58BD4]
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <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		: Lightweight OCSP Profile  for High Volume Environments
	Author(s)	: R. Hurst, A. Deacon
	Filename	: draft-ietf-pkix-lightweight-ocsp-profile-02.txt
	Pages		: 20
	Date		: 2005-7-18

This specification defines a profile of the Online Certificate 
   Status Protocol (OCSP) that addresses the scalability issues 
   inherent when using OCSP in large scale (high volume) PKI 
   environments and/or PKI environments that require a lightweight 
   solution to minimize bandwidth and client side processing.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-lightweight-ocsp-profile-02.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-lightweight-ocsp-profile-02.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-lightweight-ocsp-profile-02.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.

______________________________________________________________________
This e-mail has been scanned by MCI Managed Email Content Service, using Skeptic(tm) technology powered by MessageLabs. For more information on MCI's Managed Email Content Service, visit http://www.mci.com.
______________________________________________________________________
--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: <2005-7-18153914.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-lightweight-ocsp-profile-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-lightweight-ocsp-profile-02.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2005-7-18153914.I-D@ietf.org>

--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www1.ietf.org/mailman/listinfo/i-d-announce

--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 j6JBLKPS036189; Tue, 19 Jul 2005 04:21: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 j6JBLKZZ036188; Tue, 19 Jul 2005 04:21:20 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from IP0fCard1 (host2.ewrrn.hyatthsia.com [12.161.245.2] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6JBLJhe036175 for <ietf-pkix@imc.org>; Tue, 19 Jul 2005 04:21:20 -0700 (PDT) (envelope-from chokhani@orionsec.com)
Received: from wchokhani3 (globalsuite.gtcorp.com [127.0.0.1]) by IP0fCard1 (8.11.6/8.11.6) with ESMTP id j6JBLGB03190 for <ietf-pkix@imc.org>; Tue, 19 Jul 2005 07:21:16 -0400
From: "Santosh Chokhani" <chokhani@orionsec.com>
To: "'pkix'" <ietf-pkix@imc.org>
Subject: RE: Correction to be done to <draft-pinkas-pkix-conf-crl-validation-01.txt>
Date: Tue, 19 Jul 2005 07:21:10 -0400
Message-ID: <004901c58c53$fa8dfa30$cbb011ac@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
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
In-Reply-To: <42DC2FD3.2000200@nist.gov>
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 Cooper,

Thanks.  The new definition is clearer and the State Machine is accurate.

I would replace the last "MAY" with "MAY also".  Thus, the text would
become:

      If the scope of the CRL includes one or more certificates issued by
      an entity other than the CRL issuer, then it is an indirect CRL.  The
      scope of an indirect CRL may be limited to certificates issued by a
      single CA or may include certificates issued by multiple CAs.  If the
      issuer of the indirect CRL is a CA, then the scope of the indirect
      CRL MAY also include certificates issued by the issuer of the CRL.

-----Original Message-----
From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On
Behalf Of David A. Cooper
Sent: Monday, July 18, 2005 6:40 PM
To: Santosh Chokhani
Cc: 'pkix'
Subject: Re: Correction to be done to
<draft-pinkas-pkix-conf-crl-validation-01.txt>

Santosh Chokhani wrote:

>Denis,
>
>A sentence in 3280 may be ambiguous. The definition and State Machines 
>are not at odds. Also, if you point to the specific location of the 
>sentence in 3280, I will be happy to determine if this is being taken 
>out of context or not.
>  
>

Santosh,

Denis is referring to the final sentence in the following paragraph:

      CRL issuers issue CRLs.  The CRL issuer is either the CA or an entity
      that has been authorized by the CA to issue CRLS.  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.

I believe the problem is that Denis is interpreting this sentence as a 
definition when it is not one.  Here is the definition of indirect CRL 
in X.509:

      indirect CRL (iCRL):  A revocation list that at least contains 
revocation information
      about certificates issued by authorities other than that which 
issued this CRL.

In order to help avoid this confusion in 3280bis, I have removed the 
sentence "Whenever ...." from 3280bis draft -01 and have added the 
following paragraph:

      If the scope of the CRL includes one or more certificates issued by
      an entity other than the CRL issuer, then it is an indirect CRL.  The
      scope of an indirect CRL may be limited to certificates issued by a
      single CA or may include certificates issued by multiple CAs.  If the
      issuer of the indirect CRL is a CA, then the scope of the indirect
      CRL MAY include certificates issued by the issuer of the CRL.

I believe that this text is fully consistent with the X.509 definition 
of indirect CRL as well as the descriptions of the indirectCRL flag and 
the certificateIssuer CRL entry extension in both X.509 and RFC 3280 and 
the algorithm in section 6.3.3 of RFC 3280.

Dave

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 j6JADsJL010223; Tue, 19 Jul 2005 03:13: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 j6JADsa7010222; Tue, 19 Jul 2005 03:13:54 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from smtp-ft3.fr.colt.net (smtp-ft3.fr.colt.net [213.41.78.206]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6JADqWS010207 for <ietf-pkix@imc.org>; Tue, 19 Jul 2005 03:13:53 -0700 (PDT) (envelope-from jmdesp@free.fr)
Received: from [10.0.0.81] (host.104.92.68.195.rev.coltfrance.com [195.68.92.104]) by smtp-ft3.fr.colt.net with ESMTP id j6JADpF23543 for <ietf-pkix@imc.org>; Tue, 19 Jul 2005 12:13:51 +0200
Message-ID: <42DCD23C.6060209@free.fr>
Date: Tue, 19 Jul 2005 12:13:16 +0200
From: Jean-Marc Desperrier <jmdesp@free.fr>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; fr-FR; rv:1.8b2) Gecko/20050527
MIME-Version: 1.0
To: ietf-pkix@imc.org
Subject: Re: A non-critical self-signed certificate extension for trust anchr renewal ...
References: <42D6F608.7000704@connotech.com>
In-Reply-To: <42D6F608.7000704@connotech.com>
Content-Type: text/plain; charset=ISO-8859-1; 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>

Thierry Moreau wrote:

> Here is a new trust anchor renewal scheme explained in an Internet 
> draft document draft-moreau-pkix-takrem-00.txt (submitted today, also 
> available at http://www.connotech.com/draft-moreau-pkix-takrem-00.txt).
>
> See also http://www.connotech.com/takrem.pdf for a more tutorial 
> explanation.

Sorry about the empty message yesterday.

My comment was about what justifies defining a new trust anchor key
distribution in addition to the one already defined in RFC 2510 §2.4
(also B5 and §3.3.13).

I see two gains in your proposition :
- a smaller message (but probably not very relevant)
- the ability to still be able to update a key after it is compromised

The second point may look very useful, but in real life good procedures
should enable to keep the trust anchor private key at about the same
level of security as the future trust anchor key in your mechanism.

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 j6IMdvGn052452; Mon, 18 Jul 2005 15:39: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 j6IMdvJO052451; Mon, 18 Jul 2005 15:39:57 -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 (rimp2.nist.gov [129.6.16.227]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6IMdu8C052445 for <ietf-pkix@imc.org>; Mon, 18 Jul 2005 15:39:56 -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.13.1/8.13.1) with ESMTP id j6IMdqXF017067; Mon, 18 Jul 2005 18:39:52 -0400
Received: from [129.6.54.72] (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id j6IMdC6u020505; Mon, 18 Jul 2005 18:39:12 -0400 (EDT)
Message-ID: <42DC2FD3.2000200@nist.gov>
Date: Mon, 18 Jul 2005 18:40:19 -0400
From: "David A. Cooper" <david.cooper@nist.gov>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040804
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Santosh Chokhani <chokhani@orionsec.com>
CC: "'pkix'" <ietf-pkix@imc.org>
Subject: Re: Correction to be done to <draft-pinkas-pkix-conf-crl-validation-01.txt>
References: <002101c58bb2$33a07340$cbb011ac@hq.orionsec.com>
In-Reply-To: <002101c58bb2$33a07340$cbb011ac@hq.orionsec.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: david.cooper@nist.gov
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <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:

>Denis,
>
>A sentence in 3280 may be ambiguous. The definition and State Machines are
>not at odds. Also, if you point to the specific location of the sentence in
>3280, I will be happy to determine if this is being taken out of context or
>not.
>  
>

Santosh,

Denis is referring to the final sentence in the following paragraph:

      CRL issuers issue CRLs.  The CRL issuer is either the CA or an entity
      that has been authorized by the CA to issue CRLS.  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.

I believe the problem is that Denis is interpreting this sentence as a 
definition when it is not one.  Here is the definition of indirect CRL 
in X.509:

      indirect CRL (iCRL):  A revocation list that at least contains 
revocation information
      about certificates issued by authorities other than that which 
issued this CRL.

In order to help avoid this confusion in 3280bis, I have removed the 
sentence "Whenever ...." from 3280bis draft -01 and have added the 
following paragraph:

      If the scope of the CRL includes one or more certificates issued by
      an entity other than the CRL issuer, then it is an indirect CRL.  The
      scope of an indirect CRL may be limited to certificates issued by a
      single CA or may include certificates issued by multiple CAs.  If the
      issuer of the indirect CRL is a CA, then the scope of the indirect
      CRL MAY include certificates issued by the issuer of the CRL.

I believe that this text is fully consistent with the X.509 definition 
of indirect CRL as well as the descriptions of the indirectCRL flag and 
the certificateIssuer CRL entry extension in both X.509 and RFC 3280 and 
the algorithm in section 6.3.3 of RFC 3280.

Dave

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 j6ILEIWW045811; Mon, 18 Jul 2005 14:14: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 j6ILEIAi045810; Mon, 18 Jul 2005 14:14:18 -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.9) with ESMTP id j6ILEH2Y045801 for <ietf-pkix@imc.org>; Mon, 18 Jul 2005 14:14:17 -0700 (PDT) (envelope-from kent@bbn.com)
Received: from [128.89.89.106] (dhcp89-089-106.bbn.com [128.89.89.106]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j6ILDd2o016426; Mon, 18 Jul 2005 17:13:40 -0400 (EDT)
Mime-Version: 1.0
Message-Id: <p06230915bf01ca726959@[128.89.89.106]>
In-Reply-To: <OFE12E6CDC.2B167B87-ONC1257042.002D204F@frcl.bull.fr>
References: <OFE12E6CDC.2B167B87-ONC1257042.002D204F@frcl.bull.fr>
Date: Mon, 18 Jul 2005 17:13:08 -0400
To: "Denis Pinkas" <denis.pinkas@bull.net>
From: Stephen Kent <kent@bbn.com>
Subject: Re: How ambiguous are names in actuality?
Cc: "ietf-pkix@imc.org" <ietf-pkix@imc.org>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41
X-Virus-Status: Clean
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <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,

I appreciate your comments on subtle issues associated with name 
collisions, and how these issues differ for ACL or end entity 
authentication use vs. non-repudiation use.

I don't think 3280 or its successor should be providing detailed 
guidance for application developers re use of certs. But but another 
document, maybe a BCP, would be a good lace to do this. One could 
discuss in more detail the question of what constitutes a safe ACL 
entry or a suitable name to display for a received e-mail message, 
etc. Similar example could be provided for NR application contexts. 
One can even include a discussion of how the X.509 folks added issuer 
and subject UIDs to version 2 of the spec to address problems of name 
collisions in directory access controls, where the collisions arose 
due to name reuse over time, another source of name ambiguity.

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 j6IKmLrp042254; Mon, 18 Jul 2005 13:48: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 j6IKmLcu042253; Mon, 18 Jul 2005 13:48:21 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from IP0fCard1 (host2.ewrrn.hyatthsia.com [12.161.245.2] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6IKmKSQ042247 for <ietf-pkix@imc.org>; Mon, 18 Jul 2005 13:48:20 -0700 (PDT) (envelope-from chokhani@orionsec.com)
Received: from wchokhani3 (globalsuite.gtcorp.com [127.0.0.1]) by IP0fCard1 (8.11.6/8.11.6) with ESMTP id j6IKm9B23694 for <ietf-pkix@imc.org>; Mon, 18 Jul 2005 16:48:09 -0400
From: "Santosh Chokhani" <chokhani@orionsec.com>
To: "'pkix'" <ietf-pkix@imc.org>
Subject: RE: 3280bis: CRL validation: what is wrong and/or missing in section 6.3
Date: Mon, 18 Jul 2005 16:48:16 -0400
Message-ID: <003701c58bda$06088440$cbb011ac@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.2900.2180
Importance: Normal
In-Reply-To: <BF9309599A71984CAC5BAC5ECA62994402D80771@EUR-MSG-11.europe.corp.microsoft.com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j6IKmLSQ042248
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <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,

The algorithm is trying to be faithful to the standard.  If the standard can
be profiled and constrained further, so can the algorithm.  That is trivial.
I am proposing an approach and not simply a point solution.

That said, I would at least add to your profile, the indirect CRL being the
trust anchor itself or a certificate issued by the trust anchor that is used
to build the certificate certification path.

-----Original Message-----
From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On
Behalf Of Stefan Santesson
Sent: Monday, July 18, 2005 1:22 PM
To: Santosh Chokhani; pkix
Subject: RE: 3280bis: CRL validation: what is wrong and/or missing in
section 6.3

Santosh,

I'm not concerned with direct CRLs here since they are issued by the target
CA. Having said that, I do of course agree that one must not accept an
alternate path to a direct CRL even if CRL issuer name match the name of the
issuing CA.

Within this thread I'm only concerned with indirect CRLs and for those I
currently think we should be more restrictive than your algorithm suggests.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> -----Original Message-----
> From: owner-ietf-pkix@mail.imc.org
[mailto:owner-ietf-pkix@mail.imc.org]
> On Behalf Of Santosh Chokhani
> Sent: den 18 juli 2005 09:11
> To: 'pkix'
> Subject: RE: 3280bis: CRL validation: what is wrong and/or missing in 
> section 6.3
> 
> 
> Stefan,
> 
> One more time: the solution is air-tight for direct CRL.
> 
> For indirect CRL, we can tighten the solution by further profiling or 
> restricting the standard. So, we can do what we want.
> 
> -----Original Message-----
> From: Stefan Santesson [mailto:stefans@microsoft.com]
> Sent: Monday, July 18, 2005 12:05 PM
> To: Santosh Chokhani; pkix
> Subject: RE: 3280bis: CRL validation: what is wrong and/or missing in 
> section 6.3
> 
> 
> When I last reviewed your algorithm it required the CRL issuer cert to
be
> issued by any CA in the target cert path. My current thinking is to be 
> even more restrictive.
> 
> Either to require the CRL issuer cert to be issued explicitly by the 
> target CA or maybe also by its parent CA, but not by any CA further up 
> in the path.
> 
> 
> Stefan Santesson
> Program Manager, Standards Liaison
> Windows Security
> 
> 
> > -----Original Message-----
> > From: owner-ietf-pkix@mail.imc.org
> [mailto:owner-ietf-pkix@mail.imc.org]
> > On Behalf Of Santosh Chokhani
> > Sent: den 13 juli 2005 04:50
> > To: 'pkix'
> > Subject: RE: 3280bis: CRL validation: what is wrong and/or missing
in
> > section 6.3
> >
> >
> > Stefan,
> >
> > How is this different from my proposal for matching the two
> certification
> > path?
> >
> > Also, this will not overly constrain indirect CRL issuer.
> >
> > -----Original Message-----
> > From: owner-ietf-pkix@mail.imc.org
> [mailto:owner-ietf-pkix@mail.imc.org]
> > On
> > Behalf Of Stefan Santesson
> > Sent: Wednesday, July 13, 2005 6:32 AM
> > To: David A. Cooper; Denis Pinkas
> > Cc: pkix
> > Subject: RE: 3280bis: CRL validation: what is wrong and/or missing
in
> > section 6.3
> >
> >
> >
> > David,
> >
> > I agree with your comments.
> >
> > However on the following:
> >
> > > Even though X.509 requires that names be unambiguous, there does
> seem
> > to
> > > be consensus within the PKIX WG that 3280bis should impose some 
> > > restrictions of the certification path used to validate a CRL in
> order
> > > to address the concern that a name collision might occur despite
> > X.509's
> > > prohibition.  However, at the moment, WG consensus seems to be in
> > favor
> > > of only requiring that the certification path for the CRL use the
> same
> > > trust anchor as the certification path for the corresponding CRL.
> > There
> > > is language about this in the security considerations section.  In
> > order
> > > for 3280bis to be even more restrictive, it would need to be shown
> > that
> > > there is WG consensus in favor of imposing such restrictions.
> >
> > I would like to add my vote to be more restrictive than just
> terminating
> > at
> > the same root.
> >
> > I think the path processing complexity would be much simpler if the
> CRL
> > issuer certificate had to be issued by the CA that issued the target 
> > certificate (the target CA). It would also eliminate potential name 
> > collision problems.
> >
> > Perhaps we need to also consider allowing the parent of the target
CA
> to
> > issue the CRL issuer cert but I see no reason to allow the CRL
issuer
> cert
> > to be issued by a CA that is not in the target cert path or by a CA
> higher
> > in the target cert path.
> >
> >
> > Stefan Santesson
> > Program Manager, Standards Liaison
> > Windows Security
> >
> >
> > > -----Original Message-----
> > > From: owner-ietf-pkix@mail.imc.org
> > [mailto:owner-ietf-pkix@mail.imc.org]
> > > On Behalf Of David A. Cooper
> > > Sent: den 11 juli 2005 19:42
> > > To: Denis Pinkas
> > > Cc: pkix
> > > Subject: Re: 3280bis: CRL validation: what is wrong and/or missing
> in
> > > section 6.3
> > >
> > >
> > > Denis Pinkas wrote:
> > >
> > > >
> > > > 3280bis: CRL validation: what is wrong and/or missing in section
> > 6.3.
> > > >
> > > > 1. The very first sentence states:
> > > >
> > > > " This section describes the steps necessary to determine if a
> > > >   certificate is revoked or on hold status when CRLs are the
> > revocation
> > > >   mechanism used by the certificate issuer".
> > > >
> > > > a) This section should describe the steps necessary to determine
> > > >   if the revocation status of the certification path* is :
> REVOKED,
> > > >   NOT_REVOKED or UNKNOWN, instead of simply determine if the
> > > >   *target certificate* is REVOKED. So the sentence is incorrect.
> > >
> > > The algorithm in section 6.3 is used to determine the status of a 
> > > particular certificate, not a certification path, so the text is 
> > > correct.  However, as part of certification path validation,
section
> > > 6.1.3, step (a)(3) states that, for each certificate in the path,
> one
> > > must verify that the certificate is not revoked or on hold, and it 
> > > indicates that if status is determined using CRLs that section 6.3 
> > > indicates how the status can be determined.
> > >
> > > > b) The current text mentions the return of the "on hold" status.
> > > >   However since CRLreason is not mentioned as an output
parameter
> > > >   of the algorithm, this may not be the case (the only algorithm
> > > >   output is currently the revocation status of the certificate).
> > >
> > > The variable cert_status is output from the algorithm.  In section
> > 6.3.3
> > > steps (i) and (j), the value of cert_status is set to the value
from
> > the
> > > reason code CRL entry extension if the certificate is found to be 
> > > revoked and the reason code extension is present.
> > >
> > > > 2. The text states: " Conforming implementations that support
CRLs
> > > > are not required to implement this algorithm, but they MUST be 
> > > > functionally equivalent to the external behavior resulting from
> this
> > > > procedure".
> > >
> > > If you believe that this sentence and some of text quoted below
need
> > to
> > > be more precisely worded, please provide text for consideration.
> > >
> > > > This sentence is incorrect since the algorithm would mandate the 
> > > > support of many certificate extensions, CRL extensions and CRL
> entry
> > > > extensions that conforming relying party applications are NOT 
> > > > REQUIRED to support. The current algorithm has many errors in it 
> > > > cannot be easily simplified, if less than "all options" are 
> > > > supported by a relying party.
> > > >
> > > > 3. The text states: "This algorithm assumes that all of the
needed
> > > > CRLs are available in a local cache".
> > > >
> > > > This sentence is incorrect, because it may happen that the
"right"
> > > > or a "current" CRL is  unavailable and thus absent; in such a
case
> > > > the algorithm terminates with "UNDETERMINED" or "UNKNOWN".
> > >
> > > I don't understand what you mean by incorrect, the sentence states
> an
> > > assumption, not a fact.
> > >
> > > > 4. The text states:
> > > >
> > > > "This algorithm begins by assuming the certificate is not
> revoked."
> > > >
> > > > This sentence is incorrect, the algorithm should begin by
assuming
> > > > the status of the certificate is "UNDETERMINED" or "UNKNOWN".
> > >
> > > cert_status is initialized to UNREVOKED.  If the status cannot be 
> > > determined, cert_status gets changed to UNDETERMINED as the final
> > step.
> > >
> > > > 5. The text states, [omitting what is relevant to delta CRLs]
> > > >
> > > > "(a)  Update the local CRL cache by obtaining a complete CRL [ ]
:
> > > >
> > > >         (1)  If the current time is after the value of the CRL
> next
> > > >         update field, then do one of the following :
> > > >
> > > >            (i) [ ].
> > > >
> > > >            (ii)  Update the local CRL cache with a current
> complete
> > > >            CRL, verify that the current time is before the next
> > update
> > > >            value in the new CRL, [ ]".
> > > >
> > > > This is incorrect. If the "current" CRL cannot be found, then it
> is
> > > > still possible to use an older CRL to demonstrate that the
> > certificate
> > > > was REVOKED. Of course, when using an older CRL it is not
possible
> > > > to demonstrate that the certificate was NOT_REVOKED.
> > >
> > > Section 6.3 states "Further, if the next update time of a CRL has 
> > > passed, the algorithm assumes a mechanism to fetch a current CRL
and
> > > place it in the local CRL cache."  So, while the scenario you
> describe
> > > could happen, section 6.3 states that the algorithm does not
address
> > > this scenario.
> > >
> > > > 6. The current algorithm cannot make sure that an emergency CRL
(
> > > > i.e. the latest captured CRL) will be used if more than one
> "valid"
> > > > CRLs are found in the local cache.
> > >
> > > True.  As long as untrusted mechanisms are used to distribute
CRLs,
> > the
> > > relying party cannot ensure that it has the latest CRL.
> > >
> > > > 7. The text states:
> > > >
> > > >   (f)  Obtain and validate the certification path for the
complete
> > CRL
> > > >   issuer.  If a key usage extension is present in the CRL
issuer's
> > > >   certificate, verify that the cRLSign bit is set.
> > > >
> > > >   (g)  Validate the signature on the complete CRL using the
public
> > key
> > > >   validated in step (f).
> > > >
> > > > The text is unclear about what is meant by :" validate the
> > certification
> > > > path for the complete CRL issuer". In order to solve the problem
> of
> > > > identical CRL Issuer names or identical CA names, it is needed
to
> > say
> > > > that the certification path that has been used to validate the
> > target
> > > > certificate MUST also be used.
> > >
> > > Would you like for step (f) to say that the validation should be 
> > > performed as specified in section 6.1 and/or section 6.2?
> > >
> > > Even though X.509 requires that names be unambiguous, there does
> seem
> > to
> > > be consensus within the PKIX WG that 3280bis should impose some 
> > > restrictions of the certification path used to validate a CRL in
> order
> > > to address the concern that a name collision might occur despite
> > X.509's
> > > prohibition.  However, at the moment, WG consensus seems to be in
> > favor
> > > of only requiring that the certification path for the CRL use the
> same
> > > trust anchor as the certification path for the corresponding CRL.
> > There
> > > is language about this in the security considerations section.  In
> > order
> > > for 3280bis to be even more restrictive, it would need to be shown
> > that
> > > there is WG consensus in favor of imposing such restrictions.
> > >
> > > > 8. There is no handling of the Certificate Issuer CRL entry
> > extension,
> > > > when present, which may lead to incorrect results.
> > >
> > > Section 6.3.3, steps (i) and (j) refer to section 5.3.4, which
> > indicates
> > > how to process this extension.
> >
> 
> 

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 j6IJo2Zf037239; Mon, 18 Jul 2005 12:50: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 j6IJo25k037238; Mon, 18 Jul 2005 12:50:02 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from newodin.ietf.org ([132.151.6.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6IJo2tH037224 for <ietf-pkix@imc.org>; Mon, 18 Jul 2005 12:50:02 -0700 (PDT) (envelope-from mlee@newodin.ietf.org)
Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1Dubco-0002Hk-2y; Mon, 18 Jul 2005 15:50:02 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
Cc: ietf-pkix@imc.org
From: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-pkix-lightweight-ocsp-profile-02.txt 
Message-Id: <E1Dubco-0002Hk-2y@newodin.ietf.org>
Date: Mon, 18 Jul 2005 15:50:02 -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		: Lightweight OCSP Profile  for High Volume Environments
	Author(s)	: R. Hurst, A. Deacon
	Filename	: draft-ietf-pkix-lightweight-ocsp-profile-02.txt
	Pages		: 20
	Date		: 2005-7-18

This specification defines a profile of the Online Certificate 
   Status Protocol (OCSP) that addresses the scalability issues 
   inherent when using OCSP in large scale (high volume) PKI 
   environments and/or PKI environments that require a lightweight 
   solution to minimize bandwidth and client side processing.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-lightweight-ocsp-profile-02.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-lightweight-ocsp-profile-02.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-lightweight-ocsp-profile-02.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:	<2005-7-18153914.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-lightweight-ocsp-profile-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-lightweight-ocsp-profile-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2005-7-18153914.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 j6IHb2da023589; Mon, 18 Jul 2005 10:37: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 j6IHb2mb023588; Mon, 18 Jul 2005 10:37:02 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from smtp-ft3.fr.colt.net (smtp-ft3.fr.colt.net [213.41.78.206]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6IHb1kj023581 for <ietf-pkix@imc.org>; Mon, 18 Jul 2005 10:37:01 -0700 (PDT) (envelope-from jmdesp@free.fr)
Received: from [10.0.0.81] (host.104.92.68.195.rev.coltfrance.com [195.68.92.104]) by smtp-ft3.fr.colt.net with ESMTP id j6IHb0F25390 for <ietf-pkix@imc.org>; Mon, 18 Jul 2005 19:37:00 +0200
Message-ID: <42DBE8BC.8030706@free.fr>
Date: Mon, 18 Jul 2005 19:37:00 +0200
From: Jean-Marc Desperrier <jmdesp@free.fr>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; fr-FR; rv:1.8b2) Gecko/20050527
MIME-Version: 1.0
To: ietf-pkix@imc.org
Subject: Re: How ambiguous are names in actuality?
References: <002001c58bb2$02528850$cbb011ac@hq.orionsec.com>
In-Reply-To: <002001c58bb2$02528850$cbb011ac@hq.orionsec.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>

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 j6IHLh0r021086; Mon, 18 Jul 2005 10:21: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 j6IHLhFE021085; Mon, 18 Jul 2005 10:21:43 -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 j6IHLgPa021032 for <ietf-pkix@imc.org>; Mon, 18 Jul 2005 10:21:42 -0700 (PDT) (envelope-from stefans@microsoft.com)
Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Jul 2005 18:21:36 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: 3280bis: CRL validation: what is wrong and/or missing in section 6.3
Date: Mon, 18 Jul 2005 18:21:34 +0100
Message-ID: <BF9309599A71984CAC5BAC5ECA62994402D80771@EUR-MSG-11.europe.corp.microsoft.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: 3280bis: CRL validation: what is wrong and/or missing in section 6.3
Thread-Index: AcWLuFyXQ6y4jXHaQ7CnlzWUXYbl8wAAzZ0A
From: "Stefan Santesson" <stefans@microsoft.com>
To: "Santosh Chokhani" <chokhani@orionsec.com>, "pkix" <ietf-pkix@imc.org>
X-OriginalArrivalTime: 18 Jul 2005 17:21:36.0723 (UTC) FILETIME=[26E02230:01C58BBD]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j6IHLhPa021077
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <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'm not concerned with direct CRLs here since they are issued by the
target CA. Having said that, I do of course agree that one must not
accept an alternate path to a direct CRL even if CRL issuer name match
the name of the issuing CA.

Within this thread I'm only concerned with indirect CRLs and for those I
currently think we should be more restrictive than your algorithm
suggests.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> -----Original Message-----
> From: owner-ietf-pkix@mail.imc.org
[mailto:owner-ietf-pkix@mail.imc.org]
> On Behalf Of Santosh Chokhani
> Sent: den 18 juli 2005 09:11
> To: 'pkix'
> Subject: RE: 3280bis: CRL validation: what is wrong and/or missing in
> section 6.3
> 
> 
> Stefan,
> 
> One more time: the solution is air-tight for direct CRL.
> 
> For indirect CRL, we can tighten the solution by further profiling or
> restricting the standard. So, we can do what we want.
> 
> -----Original Message-----
> From: Stefan Santesson [mailto:stefans@microsoft.com]
> Sent: Monday, July 18, 2005 12:05 PM
> To: Santosh Chokhani; pkix
> Subject: RE: 3280bis: CRL validation: what is wrong and/or missing in
> section 6.3
> 
> 
> When I last reviewed your algorithm it required the CRL issuer cert to
be
> issued by any CA in the target cert path. My current thinking is to be
> even
> more restrictive.
> 
> Either to require the CRL issuer cert to be issued explicitly by the
> target
> CA or maybe also by its parent CA, but not by any CA further up in the
> path.
> 
> 
> Stefan Santesson
> Program Manager, Standards Liaison
> Windows Security
> 
> 
> > -----Original Message-----
> > From: owner-ietf-pkix@mail.imc.org
> [mailto:owner-ietf-pkix@mail.imc.org]
> > On Behalf Of Santosh Chokhani
> > Sent: den 13 juli 2005 04:50
> > To: 'pkix'
> > Subject: RE: 3280bis: CRL validation: what is wrong and/or missing
in
> > section 6.3
> >
> >
> > Stefan,
> >
> > How is this different from my proposal for matching the two
> certification
> > path?
> >
> > Also, this will not overly constrain indirect CRL issuer.
> >
> > -----Original Message-----
> > From: owner-ietf-pkix@mail.imc.org
> [mailto:owner-ietf-pkix@mail.imc.org]
> > On
> > Behalf Of Stefan Santesson
> > Sent: Wednesday, July 13, 2005 6:32 AM
> > To: David A. Cooper; Denis Pinkas
> > Cc: pkix
> > Subject: RE: 3280bis: CRL validation: what is wrong and/or missing
in
> > section 6.3
> >
> >
> >
> > David,
> >
> > I agree with your comments.
> >
> > However on the following:
> >
> > > Even though X.509 requires that names be unambiguous, there does
> seem
> > to
> > > be consensus within the PKIX WG that 3280bis should impose some
> > > restrictions of the certification path used to validate a CRL in
> order
> > > to address the concern that a name collision might occur despite
> > X.509's
> > > prohibition.  However, at the moment, WG consensus seems to be in
> > favor
> > > of only requiring that the certification path for the CRL use the
> same
> > > trust anchor as the certification path for the corresponding CRL.
> > There
> > > is language about this in the security considerations section.  In
> > order
> > > for 3280bis to be even more restrictive, it would need to be shown
> > that
> > > there is WG consensus in favor of imposing such restrictions.
> >
> > I would like to add my vote to be more restrictive than just
> terminating
> > at
> > the same root.
> >
> > I think the path processing complexity would be much simpler if the
> CRL
> > issuer certificate had to be issued by the CA that issued the target
> > certificate (the target CA). It would also eliminate potential name
> > collision problems.
> >
> > Perhaps we need to also consider allowing the parent of the target
CA
> to
> > issue the CRL issuer cert but I see no reason to allow the CRL
issuer
> cert
> > to be issued by a CA that is not in the target cert path or by a CA
> higher
> > in the target cert path.
> >
> >
> > Stefan Santesson
> > Program Manager, Standards Liaison
> > Windows Security
> >
> >
> > > -----Original Message-----
> > > From: owner-ietf-pkix@mail.imc.org
> > [mailto:owner-ietf-pkix@mail.imc.org]
> > > On Behalf Of David A. Cooper
> > > Sent: den 11 juli 2005 19:42
> > > To: Denis Pinkas
> > > Cc: pkix
> > > Subject: Re: 3280bis: CRL validation: what is wrong and/or missing
> in
> > > section 6.3
> > >
> > >
> > > Denis Pinkas wrote:
> > >
> > > >
> > > > 3280bis: CRL validation: what is wrong and/or missing in section
> > 6.3.
> > > >
> > > > 1. The very first sentence states:
> > > >
> > > > " This section describes the steps necessary to determine if a
> > > >   certificate is revoked or on hold status when CRLs are the
> > revocation
> > > >   mechanism used by the certificate issuer".
> > > >
> > > > a) This section should describe the steps necessary to determine
> > > >   if the revocation status of the certification path* is :
> REVOKED,
> > > >   NOT_REVOKED or UNKNOWN, instead of simply determine if the
> > > >   *target certificate* is REVOKED. So the sentence is incorrect.
> > >
> > > The algorithm in section 6.3 is used to determine the status of a
> > > particular certificate, not a certification path, so the text is
> > > correct.  However, as part of certification path validation,
section
> > > 6.1.3, step (a)(3) states that, for each certificate in the path,
> one
> > > must verify that the certificate is not revoked or on hold, and it
> > > indicates that if status is determined using CRLs that section 6.3
> > > indicates how the status can be determined.
> > >
> > > > b) The current text mentions the return of the "on hold" status.
> > > >   However since CRLreason is not mentioned as an output
parameter
> > > >   of the algorithm, this may not be the case (the only algorithm
> > > >   output is currently the revocation status of the certificate).
> > >
> > > The variable cert_status is output from the algorithm.  In section
> > 6.3.3
> > > steps (i) and (j), the value of cert_status is set to the value
from
> > the
> > > reason code CRL entry extension if the certificate is found to be
> > > revoked and the reason code extension is present.
> > >
> > > > 2. The text states: " Conforming implementations that support
CRLs
> > > > are not required to implement this algorithm, but they MUST be
> > > > functionally equivalent to the external behavior resulting from
> this
> > > > procedure".
> > >
> > > If you believe that this sentence and some of text quoted below
need
> > to
> > > be more precisely worded, please provide text for consideration.
> > >
> > > > This sentence is incorrect since the algorithm would mandate the
> > > > support of many certificate extensions, CRL extensions and CRL
> entry
> > > > extensions that conforming relying party applications are NOT
> > > > REQUIRED to support. The current algorithm has many errors in it
> > > > cannot be easily simplified, if less than "all options" are
> > > > supported by a relying party.
> > > >
> > > > 3. The text states: "This algorithm assumes that all of the
needed
> > > > CRLs are available in a local cache".
> > > >
> > > > This sentence is incorrect, because it may happen that the
"right"
> > > > or a "current" CRL is  unavailable and thus absent; in such a
case
> > > > the algorithm terminates with "UNDETERMINED" or "UNKNOWN".
> > >
> > > I don't understand what you mean by incorrect, the sentence states
> an
> > > assumption, not a fact.
> > >
> > > > 4. The text states:
> > > >
> > > > "This algorithm begins by assuming the certificate is not
> revoked."
> > > >
> > > > This sentence is incorrect, the algorithm should begin by
assuming
> > > > the status of the certificate is "UNDETERMINED" or "UNKNOWN".
> > >
> > > cert_status is initialized to UNREVOKED.  If the status cannot be
> > > determined, cert_status gets changed to UNDETERMINED as the final
> > step.
> > >
> > > > 5. The text states, [omitting what is relevant to delta CRLs]
> > > >
> > > > "(a)  Update the local CRL cache by obtaining a complete CRL [ ]
:
> > > >
> > > >         (1)  If the current time is after the value of the CRL
> next
> > > >         update field, then do one of the following :
> > > >
> > > >            (i) [ ].
> > > >
> > > >            (ii)  Update the local CRL cache with a current
> complete
> > > >            CRL, verify that the current time is before the next
> > update
> > > >            value in the new CRL, [ ]".
> > > >
> > > > This is incorrect. If the "current" CRL cannot be found, then it
> is
> > > > still possible to use an older CRL to demonstrate that the
> > certificate
> > > > was REVOKED. Of course, when using an older CRL it is not
possible
> > > > to demonstrate that the certificate was NOT_REVOKED.
> > >
> > > Section 6.3 states "Further, if the next update time of a CRL has
> > > passed, the algorithm assumes a mechanism to fetch a current CRL
and
> > > place it in the local CRL cache."  So, while the scenario you
> describe
> > > could happen, section 6.3 states that the algorithm does not
address
> > > this scenario.
> > >
> > > > 6. The current algorithm cannot make sure that an emergency CRL
(
> > > > i.e. the latest captured CRL) will be used if more than one
> "valid"
> > > > CRLs are found in the local cache.
> > >
> > > True.  As long as untrusted mechanisms are used to distribute
CRLs,
> > the
> > > relying party cannot ensure that it has the latest CRL.
> > >
> > > > 7. The text states:
> > > >
> > > >   (f)  Obtain and validate the certification path for the
complete
> > CRL
> > > >   issuer.  If a key usage extension is present in the CRL
issuer's
> > > >   certificate, verify that the cRLSign bit is set.
> > > >
> > > >   (g)  Validate the signature on the complete CRL using the
public
> > key
> > > >   validated in step (f).
> > > >
> > > > The text is unclear about what is meant by :" validate the
> > certification
> > > > path for the complete CRL issuer". In order to solve the problem
> of
> > > > identical CRL Issuer names or identical CA names, it is needed
to
> > say
> > > > that the certification path that has been used to validate the
> > target
> > > > certificate MUST also be used.
> > >
> > > Would you like for step (f) to say that the validation should be
> > > performed as specified in section 6.1 and/or section 6.2?
> > >
> > > Even though X.509 requires that names be unambiguous, there does
> seem
> > to
> > > be consensus within the PKIX WG that 3280bis should impose some
> > > restrictions of the certification path used to validate a CRL in
> order
> > > to address the concern that a name collision might occur despite
> > X.509's
> > > prohibition.  However, at the moment, WG consensus seems to be in
> > favor
> > > of only requiring that the certification path for the CRL use the
> same
> > > trust anchor as the certification path for the corresponding CRL.
> > There
> > > is language about this in the security considerations section.  In
> > order
> > > for 3280bis to be even more restrictive, it would need to be shown
> > that
> > > there is WG consensus in favor of imposing such restrictions.
> > >
> > > > 8. There is no handling of the Certificate Issuer CRL entry
> > extension,
> > > > when present, which may lead to incorrect results.
> > >
> > > Section 6.3.3, steps (i) and (j) refer to section 5.3.4, which
> > indicates
> > > how to process this extension.
> >
> 
> 

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 j6IH9ISZ018241; Mon, 18 Jul 2005 10:09: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 j6IH9IcX018240; Mon, 18 Jul 2005 10:09:18 -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.9) with ESMTP id j6IH9GYL018222 for <ietf-pkix@imc.org>; Mon, 18 Jul 2005 10:09:17 -0700 (PDT) (envelope-from jmdesp@free.fr)
Received: from [10.0.0.81] (host.104.92.68.195.rev.coltfrance.com [195.68.92.104]) by smtp-ft4.fr.colt.net with ESMTP id j6IH90922082 for <ietf-pkix@imc.org>; Mon, 18 Jul 2005 19:09:05 +0200
Message-ID: <42DBE22B.10900@free.fr>
Date: Mon, 18 Jul 2005 19:08:59 +0200
From: Jean-Marc Desperrier <jmdesp@free.fr>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; fr-FR; rv:1.8b2) Gecko/20050527
MIME-Version: 1.0
To: ietf-pkix@imc.org
Subject: Re: A non-critical self-signed certificate extension for trust anchr renewal ...
References: <42D6F608.7000704@connotech.com>
In-Reply-To: <42D6F608.7000704@connotech.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>

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 j6IGlQ7k015395; Mon, 18 Jul 2005 09:47: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 j6IGlQWq015393; Mon, 18 Jul 2005 09:47:26 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from mail-eur1.microsoft.com (mail-eur1.microsoft.com [213.199.128.139]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6IGlOjh015361; Mon, 18 Jul 2005 09:47:25 -0700 (PDT) (envelope-from stefans@microsoft.com)
Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Jul 2005 17:47:19 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: CMS Advanced Electronic Signatures (CAdES)
Date: Mon, 18 Jul 2005 17:46:46 +0100
Message-ID: <BF9309599A71984CAC5BAC5ECA62994402D80751@EUR-MSG-11.europe.corp.microsoft.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: CMS Advanced Electronic Signatures (CAdES)
Thread-Index: AcWHsoxvFYIa8xWKTwqMMwN0VjnlrgD4vCggAAdeL3AAAHJeQAAAzVZA
From: "Stefan Santesson" <stefans@microsoft.com>
To: <turners@ieca.com>, "S-MIME / IETF" <ietf-smime@imc.org>
Cc: "pkix" <ietf-pkix@imc.org>
X-OriginalArrivalTime: 18 Jul 2005 16:47:19.0183 (UTC) FILETIME=[5C7C71F0:01C58BB8]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j6IGlPjh015380
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <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 may matter for the motivation of individuals to take part in a review
process.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> -----Original Message-----
> From: owner-ietf-smime@mail.imc.org
[mailto:owner-ietf-smime@mail.imc.org]
> On Behalf Of Turner, Sean P.
> Sent: den 18 juli 2005 09:24
> To: Stefan Santesson; 'S-MIME / IETF'
> Cc: 'pkix'
> Subject: RE: CMS Advanced Electronic Signatures (CAdES)
> 
> 
> It's intended to be informational so I'm not sure how relevant how
> deployed
> it is an issue.
> 
> spt
> 
> -----Original Message-----
> From: Stefan Santesson [mailto:stefans@microsoft.com]
> Sent: Monday, July 18, 2005 12:10 PM
> To: turners@ieca.com; S-MIME / IETF
> Cc: pkix
> Subject: RE: CMS Advanced Electronic Signatures (CAdES)
> 
> A question that is relevant to this is any information on to what
extent
> this standard is actually deployed.
> 
> Stefan Santesson
> Program Manager, Standards Liaison
> Windows Security
> 
> 
> > -----Original Message-----
> > From: owner-ietf-smime@mail.imc.org
> [mailto:owner-ietf-smime@mail.imc.org]
> > On Behalf Of Turner, Sean P.
> > Sent: den 18 juli 2005 05:39
> > To: 'S-MIME / IETF'
> > Cc: 'pkix'
> > Subject: RE: CMS Advanced Electronic Signatures (CAdES)
> >
> >
> > The question at hand is someone in the working group willing to
review
> > this ID?
> >
> > spt
> >
> > -----Original Message-----
> > From: owner-ietf-pkix@mail.imc.org
> [mailto:owner-ietf-pkix@mail.imc.org]
> > On
> > Behalf Of Denis Pinkas
> > Sent: Wednesday, July 13, 2005 9:20 AM
> > To: S-MIME / IETF
> > Cc: pkix
> > Subject: CMS Advanced Electronic Signatures (CAdES)
> >
> >
> > To the S-MIME list,
> >
> >
> > Copy: the PKIX list.
> >
> > RFC 3126 has been issued in September 2001 and its title is:
> >
> > "Electronic Signature Format for long term electronic signatures"
> >
> > The contents of this Informational RFC is technically equivalent to
> ETSI
> > TS
> > 101 733 V.1.2.2.
> >
> > In the mean time, ETSI TC ESI has revised this Technical Standard
(TS)
> and
> > is going to publish a new version of it with a new title :
> >
> > CMS Advanced Electronic Signatures (CAdES), in order to be the
> "brother"
> > of
> > XML Advanced Electronic Signatures (XAdES), published as ETSI TS 101
> 903.
> >
> > In order to make this document widely available, ETSI has produced
an
> > equivalent of the revised TS using the format of a RFC.
> >
> > This document is temporarily available (by a kind hosting from Paul
> > Offman)
> > from:
> >
> > <http://www.imc.org/ietf-smime/TEMP-draft-pinkas-smime-cades-00.txt>
> >
> > until is is officially posted in the IETF repository.
> >
> > The major changes are mentioned section  J :
> >
> >    "The title of the document has changed to be aligned with the
title
> >    of XAdES, the vocabulary used within the present document has
been
> >    aligned with the vocabulary used in XAdES,
> >
> >    In the previous version of TS 101 733 (i.e. version 1.5.1)
> >    sigPolicyHash was mandatory.  Implementations requiring to be
> >    backward compatible with version 1.5.1 and previous versions
> >    of the current document MUST include SigPolicyHash.
> >
> >    The OIDs from the ASN.1 modules have changed for the following
> >    reasons:
> >
> >     - the OIDs of the ASN.1 modules of RFC 2560 and RFC 3161 have
been
> >       included.
> >
> >     - since RFC 2459 and RFC 3369 has been obsoleted by RFC 3280 and
> >       RFC 3852 respectively, there was the need to refer to the OIDs
> >       of the ASN.1 modules of RFC 3280 and RFC 3852, instead of the
> >       OIDs of the ASN.1 modules of RFC 2459 and RFC 3369.
> >
> >     - the other change is related to the field sigPolicyHash from
> >       SignaturePolicyId (see clause 5.8.1). That field was mandatory
> >       and is now optional."
> >
> > It is proposed to progress this document within the S-MIME WG as an
> > Informational Standard.
> >
> > 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 j6IGOu5I012561; Mon, 18 Jul 2005 09:24: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 j6IGOttp012559; Mon, 18 Jul 2005 09:24:56 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from smtp007.bizmail.sc5.yahoo.com (smtp007.bizmail.sc5.yahoo.com [66.163.170.10]) by above.proper.com (8.12.11/8.12.9) with SMTP id j6IGOsmt012547 for <ietf-pkix@imc.org>; Mon, 18 Jul 2005 09:24:54 -0700 (PDT) (envelope-from turners@ieca.com)
Message-Id: <200507181624.j6IGOsmt012547@above.proper.com>
Received: (qmail 81269 invoked from network); 18 Jul 2005 16:24:54 -0000
Received: from unknown (HELO Wylie) (turners@ieca.com@70.18.233.116 with login) by smtp007.bizmail.sc5.yahoo.com with SMTP; 18 Jul 2005 16:24:54 -0000
Reply-To: <turners@ieca.com>
From: "Turner, Sean P." <turners@ieca.com>
To: "'Stefan Santesson'" <stefans@microsoft.com>, "'S-MIME / IETF'" <ietf-smime@imc.org>
Cc: "'pkix'" <ietf-pkix@imc.org>
Subject: RE: CMS Advanced Electronic Signatures (CAdES)
Date: Mon, 18 Jul 2005 12:24:23 -0400
Organization: IECA, Inc.
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
In-Reply-To: <BF9309599A71984CAC5BAC5ECA62994402D8071F@EUR-MSG-11.europe.corp.microsoft.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Thread-Index: AcWHsoxvFYIa8xWKTwqMMwN0VjnlrgD4vCggAAdeL3AAAHJeQA==
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <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's intended to be informational so I'm not sure how relevant how deployed
it is an issue.

spt

-----Original Message-----
From: Stefan Santesson [mailto:stefans@microsoft.com] 
Sent: Monday, July 18, 2005 12:10 PM
To: turners@ieca.com; S-MIME / IETF
Cc: pkix
Subject: RE: CMS Advanced Electronic Signatures (CAdES)

A question that is relevant to this is any information on to what extent
this standard is actually deployed.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> -----Original Message-----
> From: owner-ietf-smime@mail.imc.org
[mailto:owner-ietf-smime@mail.imc.org]
> On Behalf Of Turner, Sean P.
> Sent: den 18 juli 2005 05:39
> To: 'S-MIME / IETF'
> Cc: 'pkix'
> Subject: RE: CMS Advanced Electronic Signatures (CAdES)
> 
> 
> The question at hand is someone in the working group willing to review 
> this ID?
> 
> spt
> 
> -----Original Message-----
> From: owner-ietf-pkix@mail.imc.org
[mailto:owner-ietf-pkix@mail.imc.org]
> On
> Behalf Of Denis Pinkas
> Sent: Wednesday, July 13, 2005 9:20 AM
> To: S-MIME / IETF
> Cc: pkix
> Subject: CMS Advanced Electronic Signatures (CAdES)
> 
> 
> To the S-MIME list,
> 
> 
> Copy: the PKIX list.
> 
> RFC 3126 has been issued in September 2001 and its title is:
> 
> "Electronic Signature Format for long term electronic signatures"
> 
> The contents of this Informational RFC is technically equivalent to
ETSI
> TS
> 101 733 V.1.2.2.
> 
> In the mean time, ETSI TC ESI has revised this Technical Standard (TS)
and
> is going to publish a new version of it with a new title :
> 
> CMS Advanced Electronic Signatures (CAdES), in order to be the
"brother"
> of
> XML Advanced Electronic Signatures (XAdES), published as ETSI TS 101
903.
> 
> In order to make this document widely available, ETSI has produced an 
> equivalent of the revised TS using the format of a RFC.
> 
> This document is temporarily available (by a kind hosting from Paul
> Offman)
> from:
> 
> <http://www.imc.org/ietf-smime/TEMP-draft-pinkas-smime-cades-00.txt>
> 
> until is is officially posted in the IETF repository.
> 
> The major changes are mentioned section  J :
> 
>    "The title of the document has changed to be aligned with the title
>    of XAdES, the vocabulary used within the present document has been
>    aligned with the vocabulary used in XAdES,
> 
>    In the previous version of TS 101 733 (i.e. version 1.5.1)
>    sigPolicyHash was mandatory.  Implementations requiring to be
>    backward compatible with version 1.5.1 and previous versions
>    of the current document MUST include SigPolicyHash.
> 
>    The OIDs from the ASN.1 modules have changed for the following
>    reasons:
> 
>     - the OIDs of the ASN.1 modules of RFC 2560 and RFC 3161 have been
>       included.
> 
>     - since RFC 2459 and RFC 3369 has been obsoleted by RFC 3280 and
>       RFC 3852 respectively, there was the need to refer to the OIDs
>       of the ASN.1 modules of RFC 3280 and RFC 3852, instead of the
>       OIDs of the ASN.1 modules of RFC 2459 and RFC 3369.
> 
>     - the other change is related to the field sigPolicyHash from
>       SignaturePolicyId (see clause 5.8.1). That field was mandatory
>       and is now optional."
> 
> It is proposed to progress this document within the S-MIME WG as an 
> Informational Standard.
> 
> 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 j6IGBAke010859; Mon, 18 Jul 2005 09:11: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 j6IGBAht010858; Mon, 18 Jul 2005 09:11:10 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from IP0fCard1 (host2.ewrrn.hyatthsia.com [12.161.245.2] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6IGB9Yo010851 for <ietf-pkix@imc.org>; Mon, 18 Jul 2005 09:11:09 -0700 (PDT) (envelope-from chokhani@orionsec.com)
Received: from wchokhani3 (globalsuite.gtcorp.com [127.0.0.1]) by IP0fCard1 (8.11.6/8.11.6) with ESMTP id j6IGAwB07995 for <ietf-pkix@imc.org>; Mon, 18 Jul 2005 12:10:58 -0400
From: "Santosh Chokhani" <chokhani@orionsec.com>
To: "'pkix'" <ietf-pkix@imc.org>
Subject: RE: 3280bis: CRL validation: what is wrong and/or missing in section 6.3
Date: Mon, 18 Jul 2005 12:11:04 -0400
Message-ID: <002201c58bb3$4ce378b0$cbb011ac@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.2900.2180
Importance: Normal
In-Reply-To: <BF9309599A71984CAC5BAC5ECA62994402D80711@EUR-MSG-11.europe.corp.microsoft.com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j6IGBAYo010853
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <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,

One more time: the solution is air-tight for direct CRL.

For indirect CRL, we can tighten the solution by further profiling or
restricting the standard. So, we can do what we want. 

-----Original Message-----
From: Stefan Santesson [mailto:stefans@microsoft.com] 
Sent: Monday, July 18, 2005 12:05 PM
To: Santosh Chokhani; pkix
Subject: RE: 3280bis: CRL validation: what is wrong and/or missing in
section 6.3

When I last reviewed your algorithm it required the CRL issuer cert to be
issued by any CA in the target cert path. My current thinking is to be even
more restrictive.

Either to require the CRL issuer cert to be issued explicitly by the target
CA or maybe also by its parent CA, but not by any CA further up in the path.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> -----Original Message-----
> From: owner-ietf-pkix@mail.imc.org
[mailto:owner-ietf-pkix@mail.imc.org]
> On Behalf Of Santosh Chokhani
> Sent: den 13 juli 2005 04:50
> To: 'pkix'
> Subject: RE: 3280bis: CRL validation: what is wrong and/or missing in 
> section 6.3
> 
> 
> Stefan,
> 
> How is this different from my proposal for matching the two
certification
> path?
> 
> Also, this will not overly constrain indirect CRL issuer.
> 
> -----Original Message-----
> From: owner-ietf-pkix@mail.imc.org
[mailto:owner-ietf-pkix@mail.imc.org]
> On
> Behalf Of Stefan Santesson
> Sent: Wednesday, July 13, 2005 6:32 AM
> To: David A. Cooper; Denis Pinkas
> Cc: pkix
> Subject: RE: 3280bis: CRL validation: what is wrong and/or missing in 
> section 6.3
> 
> 
> 
> David,
> 
> I agree with your comments.
> 
> However on the following:
> 
> > Even though X.509 requires that names be unambiguous, there does
seem
> to
> > be consensus within the PKIX WG that 3280bis should impose some 
> > restrictions of the certification path used to validate a CRL in
order
> > to address the concern that a name collision might occur despite
> X.509's
> > prohibition.  However, at the moment, WG consensus seems to be in
> favor
> > of only requiring that the certification path for the CRL use the
same
> > trust anchor as the certification path for the corresponding CRL.
> There
> > is language about this in the security considerations section.  In
> order
> > for 3280bis to be even more restrictive, it would need to be shown
> that
> > there is WG consensus in favor of imposing such restrictions.
> 
> I would like to add my vote to be more restrictive than just
terminating
> at
> the same root.
> 
> I think the path processing complexity would be much simpler if the
CRL
> issuer certificate had to be issued by the CA that issued the target 
> certificate (the target CA). It would also eliminate potential name 
> collision problems.
> 
> Perhaps we need to also consider allowing the parent of the target CA
to
> issue the CRL issuer cert but I see no reason to allow the CRL issuer
cert
> to be issued by a CA that is not in the target cert path or by a CA
higher
> in the target cert path.
> 
> 
> Stefan Santesson
> Program Manager, Standards Liaison
> Windows Security
> 
> 
> > -----Original Message-----
> > From: owner-ietf-pkix@mail.imc.org
> [mailto:owner-ietf-pkix@mail.imc.org]
> > On Behalf Of David A. Cooper
> > Sent: den 11 juli 2005 19:42
> > To: Denis Pinkas
> > Cc: pkix
> > Subject: Re: 3280bis: CRL validation: what is wrong and/or missing
in
> > section 6.3
> >
> >
> > Denis Pinkas wrote:
> >
> > >
> > > 3280bis: CRL validation: what is wrong and/or missing in section
> 6.3.
> > >
> > > 1. The very first sentence states:
> > >
> > > " This section describes the steps necessary to determine if a
> > >   certificate is revoked or on hold status when CRLs are the
> revocation
> > >   mechanism used by the certificate issuer".
> > >
> > > a) This section should describe the steps necessary to determine
> > >   if the revocation status of the certification path* is :
REVOKED,
> > >   NOT_REVOKED or UNKNOWN, instead of simply determine if the
> > >   *target certificate* is REVOKED. So the sentence is incorrect.
> >
> > The algorithm in section 6.3 is used to determine the status of a 
> > particular certificate, not a certification path, so the text is 
> > correct.  However, as part of certification path validation, section 
> > 6.1.3, step (a)(3) states that, for each certificate in the path,
one
> > must verify that the certificate is not revoked or on hold, and it 
> > indicates that if status is determined using CRLs that section 6.3 
> > indicates how the status can be determined.
> >
> > > b) The current text mentions the return of the "on hold" status.
> > >   However since CRLreason is not mentioned as an output parameter
> > >   of the algorithm, this may not be the case (the only algorithm
> > >   output is currently the revocation status of the certificate).
> >
> > The variable cert_status is output from the algorithm.  In section
> 6.3.3
> > steps (i) and (j), the value of cert_status is set to the value from
> the
> > reason code CRL entry extension if the certificate is found to be 
> > revoked and the reason code extension is present.
> >
> > > 2. The text states: " Conforming implementations that support CRLs 
> > > are not required to implement this algorithm, but they MUST be 
> > > functionally equivalent to the external behavior resulting from
this
> > > procedure".
> >
> > If you believe that this sentence and some of text quoted below need
> to
> > be more precisely worded, please provide text for consideration.
> >
> > > This sentence is incorrect since the algorithm would mandate the 
> > > support of many certificate extensions, CRL extensions and CRL
entry
> > > extensions that conforming relying party applications are NOT 
> > > REQUIRED to support. The current algorithm has many errors in it 
> > > cannot be easily simplified, if less than "all options" are 
> > > supported by a relying party.
> > >
> > > 3. The text states: "This algorithm assumes that all of the needed 
> > > CRLs are available in a local cache".
> > >
> > > This sentence is incorrect, because it may happen that the "right" 
> > > or a "current" CRL is  unavailable and thus absent; in such a case 
> > > the algorithm terminates with "UNDETERMINED" or "UNKNOWN".
> >
> > I don't understand what you mean by incorrect, the sentence states
an
> > assumption, not a fact.
> >
> > > 4. The text states:
> > >
> > > "This algorithm begins by assuming the certificate is not
revoked."
> > >
> > > This sentence is incorrect, the algorithm should begin by assuming 
> > > the status of the certificate is "UNDETERMINED" or "UNKNOWN".
> >
> > cert_status is initialized to UNREVOKED.  If the status cannot be 
> > determined, cert_status gets changed to UNDETERMINED as the final
> step.
> >
> > > 5. The text states, [omitting what is relevant to delta CRLs]
> > >
> > > "(a)  Update the local CRL cache by obtaining a complete CRL [ ] :
> > >
> > >         (1)  If the current time is after the value of the CRL
next
> > >         update field, then do one of the following :
> > >
> > >            (i) [ ].
> > >
> > >            (ii)  Update the local CRL cache with a current
complete
> > >            CRL, verify that the current time is before the next
> update
> > >            value in the new CRL, [ ]".
> > >
> > > This is incorrect. If the "current" CRL cannot be found, then it
is
> > > still possible to use an older CRL to demonstrate that the
> certificate
> > > was REVOKED. Of course, when using an older CRL it is not possible 
> > > to demonstrate that the certificate was NOT_REVOKED.
> >
> > Section 6.3 states "Further, if the next update time of a CRL has 
> > passed, the algorithm assumes a mechanism to fetch a current CRL and 
> > place it in the local CRL cache."  So, while the scenario you
describe
> > could happen, section 6.3 states that the algorithm does not address 
> > this scenario.
> >
> > > 6. The current algorithm cannot make sure that an emergency CRL ( 
> > > i.e. the latest captured CRL) will be used if more than one
"valid"
> > > CRLs are found in the local cache.
> >
> > True.  As long as untrusted mechanisms are used to distribute CRLs,
> the
> > relying party cannot ensure that it has the latest CRL.
> >
> > > 7. The text states:
> > >
> > >   (f)  Obtain and validate the certification path for the complete
> CRL
> > >   issuer.  If a key usage extension is present in the CRL issuer's
> > >   certificate, verify that the cRLSign bit is set.
> > >
> > >   (g)  Validate the signature on the complete CRL using the public
> key
> > >   validated in step (f).
> > >
> > > The text is unclear about what is meant by :" validate the
> certification
> > > path for the complete CRL issuer". In order to solve the problem
of
> > > identical CRL Issuer names or identical CA names, it is needed to
> say
> > > that the certification path that has been used to validate the
> target
> > > certificate MUST also be used.
> >
> > Would you like for step (f) to say that the validation should be 
> > performed as specified in section 6.1 and/or section 6.2?
> >
> > Even though X.509 requires that names be unambiguous, there does
seem
> to
> > be consensus within the PKIX WG that 3280bis should impose some 
> > restrictions of the certification path used to validate a CRL in
order
> > to address the concern that a name collision might occur despite
> X.509's
> > prohibition.  However, at the moment, WG consensus seems to be in
> favor
> > of only requiring that the certification path for the CRL use the
same
> > trust anchor as the certification path for the corresponding CRL.
> There
> > is language about this in the security considerations section.  In
> order
> > for 3280bis to be even more restrictive, it would need to be shown
> that
> > there is WG consensus in favor of imposing such restrictions.
> >
> > > 8. There is no handling of the Certificate Issuer CRL entry
> extension,
> > > when present, which may lead to incorrect results.
> >
> > Section 6.3.3, steps (i) and (j) refer to section 5.3.4, which
> indicates
> > how to process this extension.
> 

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 j6IGB0Yt010812; Mon, 18 Jul 2005 09:11: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 j6IGB0ds010811; Mon, 18 Jul 2005 09:11:00 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from mail-eur1.microsoft.com (mail-eur1.microsoft.com [213.199.128.139]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6IGAwiZ010752; Mon, 18 Jul 2005 09:10:58 -0700 (PDT) (envelope-from stefans@microsoft.com)
Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Jul 2005 17:10:52 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: CMS Advanced Electronic Signatures (CAdES)
Date: Mon, 18 Jul 2005 17:10:23 +0100
Message-ID: <BF9309599A71984CAC5BAC5ECA62994402D8071F@EUR-MSG-11.europe.corp.microsoft.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: CMS Advanced Electronic Signatures (CAdES)
Thread-Index: AcWHsoxvFYIa8xWKTwqMMwN0VjnlrgD4vCggAAdeL3A=
From: "Stefan Santesson" <stefans@microsoft.com>
To: <turners@ieca.com>, "S-MIME / IETF" <ietf-smime@imc.org>
Cc: "pkix" <ietf-pkix@imc.org>
X-OriginalArrivalTime: 18 Jul 2005 16:10:52.0098 (UTC) FILETIME=[44E1C220:01C58BB3]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j6IGAxiZ010789
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <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 question that is relevant to this is any information on to what extent
this standard is actually deployed.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> -----Original Message-----
> From: owner-ietf-smime@mail.imc.org
[mailto:owner-ietf-smime@mail.imc.org]
> On Behalf Of Turner, Sean P.
> Sent: den 18 juli 2005 05:39
> To: 'S-MIME / IETF'
> Cc: 'pkix'
> Subject: RE: CMS Advanced Electronic Signatures (CAdES)
> 
> 
> The question at hand is someone in the working group willing to review
> this
> ID?
> 
> spt
> 
> -----Original Message-----
> From: owner-ietf-pkix@mail.imc.org
[mailto:owner-ietf-pkix@mail.imc.org]
> On
> Behalf Of Denis Pinkas
> Sent: Wednesday, July 13, 2005 9:20 AM
> To: S-MIME / IETF
> Cc: pkix
> Subject: CMS Advanced Electronic Signatures (CAdES)
> 
> 
> To the S-MIME list,
> 
> 
> Copy: the PKIX list.
> 
> RFC 3126 has been issued in September 2001 and its title is:
> 
> "Electronic Signature Format for long term electronic signatures"
> 
> The contents of this Informational RFC is technically equivalent to
ETSI
> TS
> 101 733 V.1.2.2.
> 
> In the mean time, ETSI TC ESI has revised this Technical Standard (TS)
and
> is going to publish a new version of it with a new title :
> 
> CMS Advanced Electronic Signatures (CAdES), in order to be the
"brother"
> of
> XML Advanced Electronic Signatures (XAdES), published as ETSI TS 101
903.
> 
> In order to make this document widely available, ETSI has produced an
> equivalent of the revised TS using the format of a RFC.
> 
> This document is temporarily available (by a kind hosting from Paul
> Offman)
> from:
> 
> <http://www.imc.org/ietf-smime/TEMP-draft-pinkas-smime-cades-00.txt>
> 
> until is is officially posted in the IETF repository.
> 
> The major changes are mentioned section  J :
> 
>    "The title of the document has changed to be aligned with the title
>    of XAdES, the vocabulary used within the present document has been
>    aligned with the vocabulary used in XAdES,
> 
>    In the previous version of TS 101 733 (i.e. version 1.5.1)
>    sigPolicyHash was mandatory.  Implementations requiring to be
>    backward compatible with version 1.5.1 and previous versions
>    of the current document MUST include SigPolicyHash.
> 
>    The OIDs from the ASN.1 modules have changed for the following
>    reasons:
> 
>     - the OIDs of the ASN.1 modules of RFC 2560 and RFC 3161 have been
>       included.
> 
>     - since RFC 2459 and RFC 3369 has been obsoleted by RFC 3280 and
>       RFC 3852 respectively, there was the need to refer to the OIDs
>       of the ASN.1 modules of RFC 3280 and RFC 3852, instead of the
>       OIDs of the ASN.1 modules of RFC 2459 and RFC 3369.
> 
>     - the other change is related to the field sigPolicyHash from
>       SignaturePolicyId (see clause 5.8.1). That field was mandatory
>       and is now optional."
> 
> It is proposed to progress this document within the S-MIME WG as an
> Informational Standard.
> 
> 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 j6IG5v7E010268; Mon, 18 Jul 2005 09:05: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 j6IG5vq7010267; Mon, 18 Jul 2005 09:05:57 -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 j6IG5umX010244 for <ietf-pkix@imc.org>; Mon, 18 Jul 2005 09:05:56 -0700 (PDT) (envelope-from stefans@microsoft.com)
Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Jul 2005 17:05:50 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: 3280bis: CRL validation: what is wrong and/or missing in section 6.3
Date: Mon, 18 Jul 2005 17:05:20 +0100
Message-ID: <BF9309599A71984CAC5BAC5ECA62994402D80711@EUR-MSG-11.europe.corp.microsoft.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: 3280bis: CRL validation: what is wrong and/or missing in section 6.3
Thread-Index: AcWHp92E/T6cujWrSz+rjb4XYMad8QECeJgw
From: "Stefan Santesson" <stefans@microsoft.com>
To: "Santosh Chokhani" <chokhani@orionsec.com>, "pkix" <ietf-pkix@imc.org>
X-OriginalArrivalTime: 18 Jul 2005 16:05:50.0134 (UTC) FILETIME=[90E5B560:01C58BB2]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j6IG5vmX010262
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

When I last reviewed your algorithm it required the CRL issuer cert to
be issued by any CA in the target cert path. My current thinking is to
be even more restrictive.

Either to require the CRL issuer cert to be issued explicitly by the
target CA or maybe also by its parent CA, but not by any CA further up
in the path.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> -----Original Message-----
> From: owner-ietf-pkix@mail.imc.org
[mailto:owner-ietf-pkix@mail.imc.org]
> On Behalf Of Santosh Chokhani
> Sent: den 13 juli 2005 04:50
> To: 'pkix'
> Subject: RE: 3280bis: CRL validation: what is wrong and/or missing in
> section 6.3
> 
> 
> Stefan,
> 
> How is this different from my proposal for matching the two
certification
> path?
> 
> Also, this will not overly constrain indirect CRL issuer.
> 
> -----Original Message-----
> From: owner-ietf-pkix@mail.imc.org
[mailto:owner-ietf-pkix@mail.imc.org]
> On
> Behalf Of Stefan Santesson
> Sent: Wednesday, July 13, 2005 6:32 AM
> To: David A. Cooper; Denis Pinkas
> Cc: pkix
> Subject: RE: 3280bis: CRL validation: what is wrong and/or missing in
> section 6.3
> 
> 
> 
> David,
> 
> I agree with your comments.
> 
> However on the following:
> 
> > Even though X.509 requires that names be unambiguous, there does
seem
> to
> > be consensus within the PKIX WG that 3280bis should impose some
> > restrictions of the certification path used to validate a CRL in
order
> > to address the concern that a name collision might occur despite
> X.509's
> > prohibition.  However, at the moment, WG consensus seems to be in
> favor
> > of only requiring that the certification path for the CRL use the
same
> > trust anchor as the certification path for the corresponding CRL.
> There
> > is language about this in the security considerations section.  In
> order
> > for 3280bis to be even more restrictive, it would need to be shown
> that
> > there is WG consensus in favor of imposing such restrictions.
> 
> I would like to add my vote to be more restrictive than just
terminating
> at
> the same root.
> 
> I think the path processing complexity would be much simpler if the
CRL
> issuer certificate had to be issued by the CA that issued the target
> certificate (the target CA). It would also eliminate potential name
> collision problems.
> 
> Perhaps we need to also consider allowing the parent of the target CA
to
> issue the CRL issuer cert but I see no reason to allow the CRL issuer
cert
> to be issued by a CA that is not in the target cert path or by a CA
higher
> in the target cert path.
> 
> 
> Stefan Santesson
> Program Manager, Standards Liaison
> Windows Security
> 
> 
> > -----Original Message-----
> > From: owner-ietf-pkix@mail.imc.org
> [mailto:owner-ietf-pkix@mail.imc.org]
> > On Behalf Of David A. Cooper
> > Sent: den 11 juli 2005 19:42
> > To: Denis Pinkas
> > Cc: pkix
> > Subject: Re: 3280bis: CRL validation: what is wrong and/or missing
in
> > section 6.3
> >
> >
> > Denis Pinkas wrote:
> >
> > >
> > > 3280bis: CRL validation: what is wrong and/or missing in section
> 6.3.
> > >
> > > 1. The very first sentence states:
> > >
> > > " This section describes the steps necessary to determine if a
> > >   certificate is revoked or on hold status when CRLs are the
> revocation
> > >   mechanism used by the certificate issuer".
> > >
> > > a) This section should describe the steps necessary to determine
> > >   if the revocation status of the certification path* is :
REVOKED,
> > >   NOT_REVOKED or UNKNOWN, instead of simply determine if the
> > >   *target certificate* is REVOKED. So the sentence is incorrect.
> >
> > The algorithm in section 6.3 is used to determine the status of a
> > particular certificate, not a certification path, so the text is
> > correct.  However, as part of certification path validation, section
> > 6.1.3, step (a)(3) states that, for each certificate in the path,
one
> > must verify that the certificate is not revoked or on hold, and it
> > indicates that if status is determined using CRLs that section 6.3
> > indicates how the status can be determined.
> >
> > > b) The current text mentions the return of the "on hold" status.
> > >   However since CRLreason is not mentioned as an output parameter
> > >   of the algorithm, this may not be the case (the only algorithm
> > >   output is currently the revocation status of the certificate).
> >
> > The variable cert_status is output from the algorithm.  In section
> 6.3.3
> > steps (i) and (j), the value of cert_status is set to the value from
> the
> > reason code CRL entry extension if the certificate is found to be
> > revoked and the reason code extension is present.
> >
> > > 2. The text states: " Conforming implementations that support CRLs
> > > are not required to implement this algorithm, but they MUST be
> > > functionally equivalent to the external behavior resulting from
this
> > > procedure".
> >
> > If you believe that this sentence and some of text quoted below need
> to
> > be more precisely worded, please provide text for consideration.
> >
> > > This sentence is incorrect since the algorithm would mandate the
> > > support of many certificate extensions, CRL extensions and CRL
entry
> > > extensions that conforming relying party applications are NOT
> > > REQUIRED to support. The current algorithm has many errors in it
> > > cannot be easily simplified, if less than "all options" are
> > > supported by a relying party.
> > >
> > > 3. The text states: "This algorithm assumes that all of the needed
> > > CRLs are available in a local cache".
> > >
> > > This sentence is incorrect, because it may happen that the "right"
> > > or a "current" CRL is  unavailable and thus absent; in such a case
> > > the algorithm terminates with "UNDETERMINED" or "UNKNOWN".
> >
> > I don't understand what you mean by incorrect, the sentence states
an
> > assumption, not a fact.
> >
> > > 4. The text states:
> > >
> > > "This algorithm begins by assuming the certificate is not
revoked."
> > >
> > > This sentence is incorrect, the algorithm should begin by assuming
> > > the status of the certificate is "UNDETERMINED" or "UNKNOWN".
> >
> > cert_status is initialized to UNREVOKED.  If the status cannot be
> > determined, cert_status gets changed to UNDETERMINED as the final
> step.
> >
> > > 5. The text states, [omitting what is relevant to delta CRLs]
> > >
> > > "(a)  Update the local CRL cache by obtaining a complete CRL [ ] :
> > >
> > >         (1)  If the current time is after the value of the CRL
next
> > >         update field, then do one of the following :
> > >
> > >            (i) [ ].
> > >
> > >            (ii)  Update the local CRL cache with a current
complete
> > >            CRL, verify that the current time is before the next
> update
> > >            value in the new CRL, [ ]".
> > >
> > > This is incorrect. If the "current" CRL cannot be found, then it
is
> > > still possible to use an older CRL to demonstrate that the
> certificate
> > > was REVOKED. Of course, when using an older CRL it is not possible
> > > to demonstrate that the certificate was NOT_REVOKED.
> >
> > Section 6.3 states "Further, if the next update time of a CRL has
> > passed, the algorithm assumes a mechanism to fetch a current CRL and
> > place it in the local CRL cache."  So, while the scenario you
describe
> > could happen, section 6.3 states that the algorithm does not address
> > this scenario.
> >
> > > 6. The current algorithm cannot make sure that an emergency CRL (
> > > i.e. the latest captured CRL) will be used if more than one
"valid"
> > > CRLs are found in the local cache.
> >
> > True.  As long as untrusted mechanisms are used to distribute CRLs,
> the
> > relying party cannot ensure that it has the latest CRL.
> >
> > > 7. The text states:
> > >
> > >   (f)  Obtain and validate the certification path for the complete
> CRL
> > >   issuer.  If a key usage extension is present in the CRL issuer's
> > >   certificate, verify that the cRLSign bit is set.
> > >
> > >   (g)  Validate the signature on the complete CRL using the public
> key
> > >   validated in step (f).
> > >
> > > The text is unclear about what is meant by :" validate the
> certification
> > > path for the complete CRL issuer". In order to solve the problem
of
> > > identical CRL Issuer names or identical CA names, it is needed to
> say
> > > that the certification path that has been used to validate the
> target
> > > certificate MUST also be used.
> >
> > Would you like for step (f) to say that the validation should be
> > performed as specified in section 6.1 and/or section 6.2?
> >
> > Even though X.509 requires that names be unambiguous, there does
seem
> to
> > be consensus within the PKIX WG that 3280bis should impose some
> > restrictions of the certification path used to validate a CRL in
order
> > to address the concern that a name collision might occur despite
> X.509's
> > prohibition.  However, at the moment, WG consensus seems to be in
> favor
> > of only requiring that the certification path for the CRL use the
same
> > trust anchor as the certification path for the corresponding CRL.
> There
> > is language about this in the security considerations section.  In
> order
> > for 3280bis to be even more restrictive, it would need to be shown
> that
> > there is WG consensus in favor of imposing such restrictions.
> >
> > > 8. There is no handling of the Certificate Issuer CRL entry
> extension,
> > > when present, which may lead to incorrect results.
> >
> > Section 6.3.3, steps (i) and (j) refer to section 5.3.4, which
> indicates
> > how to process this extension.
> 

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 j6IG3Hio009930; Mon, 18 Jul 2005 09: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 j6IG3HS9009929; Mon, 18 Jul 2005 09:03:17 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from IP0fCard1 (host2.ewrrn.hyatthsia.com [12.161.245.2] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6IG3GEd009923 for <ietf-pkix@imc.org>; Mon, 18 Jul 2005 09:03:17 -0700 (PDT) (envelope-from chokhani@orionsec.com)
Received: from wchokhani3 (globalsuite.gtcorp.com [127.0.0.1]) by IP0fCard1 (8.11.6/8.11.6) with ESMTP id j6IG36B07832 for <ietf-pkix@imc.org>; Mon, 18 Jul 2005 12:03:06 -0400
From: "Santosh Chokhani" <chokhani@orionsec.com>
To: "'pkix'" <ietf-pkix@imc.org>
Subject: RE: Correction to be done to <draft-pinkas-pkix-conf-crl-validation-01.txt>
Date: Mon, 18 Jul 2005 12:03:12 -0400
Message-ID: <002101c58bb2$33a07340$cbb011ac@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.2900.2180
Importance: Normal
In-Reply-To: <OF3EA3B5F0.4F56956D-ONC1257042.0057A281@frcl.bull.fr>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j6IG3HEd009924
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <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,

A sentence in 3280 may be ambiguous. The definition and State Machines are
not at odds. Also, if you point to the specific location of the sentence in
3280, I will be happy to determine if this is being taken out of context or
not.

-----Original Message-----
From: Denis Pinkas [mailto:denis.pinkas@bull.net] 
Sent: Monday, July 18, 2005 12:57 PM
To: 'pkix'; Santosh Chokhani
Subject: Re: Correction to be done to
<draft-pinkas-pkix-conf-crl-validation-01.txt>

>Denis,

>The specific sentence in 3280 may need to be revised or may have been 
>taken out of context.

Thank you for finally acknowledging the fact that the current definition of 
an "indirect CRL" is incompatible with your "State Machine".

There are several ways to correct the problem. Among them :

1) keep the State Machine and change the definition of an indirect CRL.
2) take draft-pinkas-pkix-conf-crl-validation-02.txt (it is not yet
published) 
    and change the definition of an indirect CRL.

Now you see the common point: in both cases the proposal is to change 
the definition of an indirect CRL, but the reason for changing it are quite
different.

You want to change it so that your State Machine keeps working, whereas 
I want to change it to make the case where a CA designates its own CRL
issuer easy and simple to implement. That case may be handled without the 
need to support both the IDP extension and the certificate issuer CRL entry 
extension.

This may definitively encourage implementers to implement the case where 
the CA designates its own CRL issuer.

The case where a CRL issuer serves more than one CA is less likely to
happen.

In addition, note that when an indirect CRL may contain serial numbers from 
certificates issued by more than one CA, then it is possible to go
backwards. 
It is of course also possible to go onwards as you mentioned, but this is
NOT 
mandatory.

Denis 

>A CRL issuer asserts indirect CRL flag when the CRL is supposed to 
>cover certificates not issued by the CRL issuer.  Note that there may 
>not be any entries for other CAs since none of their certificates may 
>be revoked.
>
>But, the CRL issuer can cover the certificates issued by the CRL issuer 
>(if it is a CA) in that indirect CRL.
>
>The State Machine is correct.
>
>-----Original Message-----
>From: owner-ietf-pkix@mail.imc.org 
>[mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Denis Pinkas
>Sent: Monday, July 18, 2005 6:05 AM
>To: 'pkix'; Santosh Chokhani
>Subject: Re: Correction to be done to 
><draft-pinkas-pkix-conf-crl-validation-01.txt>
>
>
>
>Santosh,
>
>>My apologies to the list for typo.
>>
>>In the last paragraph, "CRL issuer" was meant to say "certificate
>>issuer". It is corrected below.
>>
>>-----Original Message-----
>>From: Santosh Chokhani [mailto:chokhani@orionsec.com]
>>Sent: Friday, July 15, 2005 1:09 PM
>>To: 'pkix'
>>Subject: RE: Correction to be done to 
>><draft-pinkas-pkix-conf-crl-validation-01.txt>
>
>
>>Denis,
>
>>The indirect CRL state machine is as follows:
>
>>	initial value of certificate_issuer_state = issuer field in the CRL
>>(1)
>
>The current sentence of RFC 3280 is : "Whenever the CRL issuer is not 
>the CA
>
>that issued the certificates, the CRL is referred to as an indirect 
>CRL".
>
>This means that when a CRL is an indirect CRL, then none of the 
>certificates
>
>that are present in the CRL can be issued under the name that is 
>present
>in the issuer name of the CRL.
>
>So unless the definition of an indirect CRL is modified, the 
>certificate issuer name cannot default to the issuer name of the CRL.
>
>So the "state machine" you propose is not correct.
>
>Stefan said:
>
>"Finally I do not worry too much about deployed products concerning 
>indirect CRLs since this is an almost non used feature as far as I 
>know."
>
>It is time to fix the issue so that cases where the various cases where 
>CA
>is not the issuer of the CRL can be undertsood and implemented.
>
>Some are simpler than others.
>
>Your message triggered another look to my I-D on that topic and I 
>noticed
>that a case was forgotten in <draft-pinkas-pkix-conf-crl-validation-02.txt>
>:
>a CRL could contain the same serial number, but from different CAs.
>
>This is now handled in <draft-pinkas-pkix-conf-crl-validation-02.txt>
>that has been posted before the dead line for submissions, but is 
>not yet available.
>
>
>Denis
>	
>>	certificate_issuer  = value in the CRL entry extension and if the 
>>extension is absent, certificate_issuer = certificate_issuer_state (2)
>>
>>	certificate_issuer_state = certificate_issuer
>>
>>It is secure, standard compliant and provides for interoperability.  
>>It is probably too complex in comparison to doing nothing and yet to 
>>be defined Denis's algorithms on a variety of CRL processing matters.
>>
>>If the indirect CRL issuer is not a CA, the first revoked certificate 
>>entry will contain a certificate issuer field.  There are numerous 
>>other situations when first revoked certificate entry will contain a 
>>certificate issuer field, but this is of no interest to a relying 
>>party that wants to write a secure, interoperable, simple (i.e., not 
>>complex) CRL processing logic.
>>
>>-----Original Message-----
>>From: owner-ietf-pkix@mail.imc.org 
>>[mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Denis Pinkas
>>Sent: Friday, July 15, 2005 4:24 AM
>>To: pkix
>>Subject: Correction to be done to 
>><draft-pinkas-pkix-conf-crl-validation-01.txt>
>>
>>
>>
>>
>>A correction needs to be done to
>><draft-pinkas-pkix-conf-crl-validation-01.txt>.
>>
>>As explained in a previous e-mail, the certificate issuer name cannot 
>>default to the name of the CRL issuer, hence the following text 
>>extracted from section 6.3.3.3 is incorrect :
>>
>>        (ii) check if there exists a previous CRL entry
>>             and if that CRL entry contains a Certificate
>>             Issuer CRL entry extension and go back to (1).
>>
>>                If there is no previous CRL entry, then
>>                check if the name of the issuer of the CRL
>>                matches the name of the issuer field of the
>>                target certificate.
>>
>>                 - If it does, then set the cert_revoc_status
>>                   variable to REVOKED and if the CRL entry
>>                   extension " reasonCode " is present in
>>                   that CRL entry, then set the revoc_reason
>>                   variable to the value contained in that CRL
>>                   entry extension and the algorithm
>>                   terminates.
>>
>>                 - If it does, then set the cert_revoc_status
>>                   variable to NOT_REVOKED and the algorithm
>>                   terminates.
>>
>>It would need to be corrected (and greatly simplified)
>>in the following way:
>>
>>          (ii) If there is no previous CRL entry, then
>>               this is an error in the structure of the CRL
>>               and the algorithm terminates.
>>
>>               Otherwise, check if that CRL entry contains
>>               a Certificate Issuer CRL entry extension and
>>               go back to (1).
>>
>>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 j6IG1veU009789; Mon, 18 Jul 2005 09:01: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 j6IG1vlC009788; Mon, 18 Jul 2005 09:01:57 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from IP0fCard1 (host2.ewrrn.hyatthsia.com [12.161.245.2] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6IG1vC2009775 for <ietf-pkix@imc.org>; Mon, 18 Jul 2005 09:01:57 -0700 (PDT) (envelope-from chokhani@orionsec.com)
Received: from wchokhani3 (globalsuite.gtcorp.com [127.0.0.1]) by IP0fCard1 (8.11.6/8.11.6) with ESMTP id j6IG1hB07783 for <ietf-pkix@imc.org>; Mon, 18 Jul 2005 12:01:44 -0400
From: "Santosh Chokhani" <chokhani@orionsec.com>
To: <ietf-pkix@imc.org>
Subject: RE: How ambiguous are names in actuality?
Date: Mon, 18 Jul 2005 12:01:50 -0400
Message-ID: <002001c58bb2$02528850$cbb011ac@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.2900.2180
Importance: Normal
In-Reply-To: <OF246C1757.86E679D9-ONC1257042.00578433@frcl.bull.fr>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j6IG1vC2009782
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <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,

Solution was presented at the IETF.  I do not intend to draft an I-D unless
the WG chairs and AD intend to support its promulgation.

-----Original Message-----
From: Denis Pinkas [mailto:denis.pinkas@bull.net] 
Sent: Monday, July 18, 2005 12:56 PM
To: Santosh Chokhani; ietf-pkix@imc.org
Subject: Re: How ambiguous are names in actuality?

Santosh,

>To me the basic problem with Tim's posting is that it is a band aid 
>solution to a problem that has a very simple solution.

The problem raised is much wider that the CRL problem where the solution 
fits in two lines of text:

"The full certification path that has been used to validate the target
  certificate MUST also be used to validate the CRL issuer certificate". 

As far as I remember I have not seen a description of your solution posted
in: 
http://www.ietf.org/internet-drafts/draft-santosh-pkix-...-00.txt

Denis

>When we look at the issue as an abstract graph theory problem and want 
>a clean and simple solution to make sure that the correct CRL is 
>fetched, the solution I have proposed solves the problem.
>
>Any thing else we do, is simply rationalization to support one or more 
>unarticulated motives.
>
>-----Original Message-----
>From: owner-ietf-pkix@mail.imc.org 
>[mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Denis Pinkas
>Sent: Monday, July 18, 2005 5:13 AM
>To: Tim Polk; ietf-pkix@imc.org
>Subject: Re: How ambiguous are names in actuality?
>
>
>
>Tim,
>
>My views are quite different. You are looking for a solution to 
>MITIGATE the risk, whereas there exists a solution to SUPPRESS the 
>risk, as it is explained below.
>The changes you propose, like "same trust anchor", do not suppress the
risk.
>
>
>You mention that the problem of name collisions exists both for two 
>leaf certificates and for CRL certificates. This is correct. While the 
>problem for CRL certificates arises
>only *during* the path verification algorithm, this is not the case for
leaf
>certificates.
>
>For a leaf certificate that has been verified to be valid, the output 
>of the algorithm is a sequence of certificates up to a given trust 
>anchor. The major issue is what
>to do with it, and this is NOT mentioned within RFC 3280.
>
>Leaf certificates may be used in two contexts:
>
>   a) access control or end-entity authentication,
>   b) non repudiation.
>
>These two cases are different and are explored below.
>
>ACCESS CONTROL OR END-ENTITY AUTHENTICATION
>
>There are two phases when a public key certificate is used for an 
>access control service :
>
>- Phase 1 : the owner of the protected object must fill-in the ACL 
>correctly,
>- Phase 2 : during an access, the sequence of certificates that has 
>been validated
>                must be checked against the content of the ACL.
>
>The real issue is that nowhere in RFC 3280 it is said what the content 
>of the ACL should be. Because of this lack of information, some 
>implementations of "relying party software"
>may be subject to problems related to name collisions, while some others
>will not. 
>
>There is no clear indication in RFC 3280 to tell how the owner of the 
>protected object will make sure that it is pointing to the right 
>certificate BEFORE using that certificate
>for access control purposes. 
>
>The point is that the owner of the protected object SHALL enter the 
>full certification path in the ACL. If it does not have the full path, 
>then it SHALL construct it according to
>the validation policy that is appropriate for his application and SHOULD
>make sure 
>that it is not revoked. It will thus use the full certification path and
may
>check either 
>automatically using some local rules or may check using his brain that the
>full certification 
>path is correct.
>
>Note that if the ACL would only contain the DN of the leaf certificate, 
>then the access control mechanism would be subject to name collisions,
>
>When the ACL contains both the DN of the leaf certificate and all the 
>DNs from the upper CA up to a trust anchor identified by its DN (i.e. 
>the DN of the trust anchor is also taken,
>since there may be more than one trust anchor in a given validation
policy),
>then the 
>access control mechanism can never be subject to name collisions.
>
>Since a validation policy may include more than one trust anchor, it 
>means that it SHALL not be allowed to define a validation policy that 
>uses two trust anchors with the same DN.
>
>This means that during phase 1, the owner of the protected object must 
>fill-in the ACL with all the DNs from the certification path, including 
>the DN from the trust anchor
>(of course a hash of it may be used instead) and that during phase 2, the
>whole certification path 
>must be used and compared with the content of the ACL.
>
>This solution fully *suppresses* the risk in any case.
>
>Of course, in some contexts, some shortcuts may be taken (e.g. when 
>there exists a single trust anchor in the validation policy) or when it 
>may be known that name collisions
>may never happen (e.g. because all the CAs apply a given naming policy) but
>this is not 
>the general case. 
>
>The solution explained above is also much simpler than adding name 
>constrains that could be anyway defeated.
>
>NON REPUDIATION
>
>With non repudiation, only the whole sequence of DN extracted from the 
>certification path is meaningful. A DN like CN= "John William" does not 
>make sense unless at the same time
>all the upper DNs from the CAs are used or displayed. So if someone wants
to
>know 
>without any ambiguity who a signer is, it SHALL use of the sequence of DN
up
>to 
>a trust anchor of the signature policy. 
>
>Since a signature policy may include more than one trust anchor, it 
>means that it SHALL NOT be allowed to define a signature policy that 
>uses two trust anchors with the same DN.
>
>COLLISIONS BETWEEN CRL ISSUER NAMES
>
>For CRLs, I have already mentioned the additional sentence that shall 
>be added to RFC 3280. It is copied again below  :
>
>"The full certification path that has been used to validate the target 
>certificate MUST also be used to validate the CRL issuer certificate ".
>
>
>REPLY TO YOUR CONCLUSIONS
>
>As a reply to your conclusions: using path length constrains does not 
>solve the issue. Adding other constrains does not solve the issue 
>either. Using name constraints would
>introduce an order of magnitude of complexity and would not be effective in
>the general case. 
>Using certification policies and path length constrains might help, but
>still do not solve 
>the problem in the general case.
>
>
>Denis
>
>
>>Ambiguity has recently become a hot topic on this list.  This is a
>>really
>>complicated issue, and I have personally had a great deal of trouble 
>>sorting out the real level of risk.  Some of the proposed changes would 
>>greatly impact current software, and these changes should only be 
>>contemplated if the risk is merits such change.
>>
>>So, I have spent a lot of time, off and on, thinking about ambiguity.
>>I
>>can't claim to have sorted it all out, but I have convinced myself that
one
>
>>minor change is absolutely required, and that the current suite of
>>mechanisms can virtually eliminate ambiguity in real PKIs.
>>
>>My thinking is appended to this message;  I apologize for its length,
>>but
>>to paraphrase Mark Twain, I simply don't have time to make this short and 
>>concise.  I have attempted to define ambiguity, characterize the ways 
>>ambiguity can enter into a PKI, and describe the set of mechanisms that 
>>mitigate this risk.
>>
>>Thanks,
>>
>>Tim Polk
>>
>>----------------------------------------------------------------------
>>-
>>---------------------------------------------------------
>>
>>              How ambiguous are names in actuality, and how important
>> is it?
>>
>>I believe that X.509 expected assignment of unambiguous names based on
>>a
>>hierarchical system of naming authorities.  Whether you agree with that 
>>premise, it is safe to say that the global X.500 directory and its 
>>corresponding system of naming authorities do not exist. So, it may not be

>>safe to assume that there are no name collisions whatsoever in all the DNs

>>that appear in certificates and CRLs!  I am sure such collisions exist 
>>somewhere (although I haven't encountered any examples).  The real
question
>
>>here is "What security risk does this situation present, and are the
>>current mechanisms adequate to address this risk?"
>>
>>Let's recognize that the goal for PKIX is not to have globally
>>unambiguous
>>names, but to be able to obtain a trustworthy public key to establish a 
>>security service. Ambiguity in names is a problem when it causes the 
>>relying party to trust the wrong public key.
>>
>>There are two ways ambiguous names could cause problems.  First, I
>>could
>>accept public keys from two certificates as representing the same person 
>>based on the same subject name.  If these two certificates are bound to 
>>different individuals I may provide a service to the wrong party (or 
>>disclose confidential data, etc., etc.)  Second, I could accept a CRL to 
>>validate a particular certificate, based on the same issuer name in the 
>>certificate and CRL.  If the certificate and CRL were not actually issued 
>>by the same CA, then the relying party may obtain incorrect certificate
>status.
>>
>>Note that both of these problems are in the context of path 
>>validation.
>>If
>>a name collision exists, but only one of the objects (e.g., certificate or

>>CRL) validates for a given relying party, then there is no actual
ambiguity
>
>>from that relying party's point of view.
>>
>>That is, assume two certificates exist with the same subject name but
>>are
>>bound to different people.  If Alice can only validate one of those 
>>certificates, there is no ambiguity in Alice's world.   Similarly, if Bob 
>>can only validate one of those certificates, there is no ambiguity in
Bob's
>
>>world.   (It does not matter if Bob and Alice are validating the same 
>>certificate, or different ones!)   Similarly, if two CAs have the same 
>>issuer name, but Alice can only validate one, she can't accept the 
>>wrong
>>CRL.  Ditto for Bob.
>>
>>So, ambiguity is a concern only in the context of path validation for 
>>a given relying party. This means that the mechanisms that are 
>>employed in path validation are relevant to when names are, and are 
>>not, ambiguous. I'd
>
>>also like to point out that path validation is always performed in the
>>context of a particular trust anchor.  (A relying party may accept paths 
>>that begin with multiple trust anchors, but each specific path has a
single
>
>>trust anchor.)  Seems irrelevant at the moment, but I will get back to 
>>it!
>>
>>Definition 1:  a Name N is unambiguous for a trust anchor T if and 
>>only
>>if
>>all certificates that validate for T and have the subject N refer to the 
>>same entity.
>>
>>Now, let's think about where name collisions can occur in the first
>>place.
>>There seems to be consensus that a single CA will not issue two 
>>certificates to two different entities with the same subject name.  So, if

>>a single CA issues two certificates to "O=Microsoft, cn=John Wilson" they 
>>better relate to the same guy.  Similarly if a particular CA issues two 
>>certificates to "c=US, O=U.S. Government, OU=NIST, CN=CA1" then the
subject
>
>>of both certificates must be the same CA.
>>
>>So, we are only worried about the case where two different CAs are
>>trusted
>>with respect to a trust anchor T and issue certificates to different 
>>subjects but use the same name.  So, when can name collisions occur
between
>
>>CAs?  Or, better yet, under what conditions can we be sure name 
>>collisions
>>won't occur?  Let's start with user certificates.
>>
>>In general, each CA that issues user certificates does so for a
>>particular
>>name space.  That is, all names assigned to users will be in a particular 
>>Directory Information Tree (DIT).   The CA will either work with a naming 
>>authority that it considers authoritative or may assume that function 
>>itself.   For example, the NIST CA only issues user certificates in the 
>>"C=US, O=U.S. Government, OU=NIST" DIT.   The NIST CA has been designated 
>>as our naming authority as well, so it keeps track of the names it 
>>assigns.  Similarly, the CA that supports NASA only issues certificates
for
>
>>the name space "C=US,  O=U.S. Government, OU=NASA" DIT.
>>
>>These name spaces are disjoint, so name collisions cannot occur
>>involving
>>user certificates generated by the NASA and NIST CAs.  In fact, consider a

>>PKI with trust anchor T and CAs C(1), C(2), ., C(n) issuing for name
spaces
>
>>P(1), P(2), ., P(n).  If spaces P(1), P(2), ., P(n) are pairwise 
>>disjoint,
>>name collisions cannot occur involving user certificates generated by
C(1),
>
>>C(2), ., C(n).
>>
>>Case 1:  Consider a PKI with trust anchor T, and CAs C1, C2, and C3.
>>C1,
>>C2, and C3 issue end user certificates in the DITs N1, N2, and N3 
>>respectively.  If N1, N2, and N3 are pairwise disjoint, then the user
names
>
>>are unambiguous with respect to T.
>>
>>In more complex PKIs, we may encounter situations where CAs issue user 
>>certificates for name spaces that overlap.  For example, in the U.S 
>>DoD's hierarchical PKI, CAs all issue certificates in the DIT "C=US, 
>>O=U.S. Government, OU=DOD".  Users routinely receive three 
>>certificates from two different CAs, so all the DoD CAs rely on a 
>>common naming authority to ensure that certificates with the same DNs 
>>are issued to the same person.
>>
>>Case 2: Consider a PKI with trust anchor T, and CAs C1, C2, and C3.
>>C1,
>>C2, and C3 issue end user certificates in the DITs N1, N2, and N3 
>>respectively.  N1 and N2 overlap, but N3 is disjoint from N1 and N2.   If 
>>CA1 and CA2 recognize the same naming authority, then the user names in
the
>
>>PKI are unambiguous with respect to T.
>>
>>That is, if all the CAs either: (1) issue certificates in disjoint 
>>name spaces, or (2) issue certificates in shared name spaces based on 
>>a common naming authority, names will be unambiguous!
>>
>>Of course, CAs may issue CA certificates as well.  In this case, the 
>>CA does not assign the names, but rather uses the established name.  
>>This is trickier, since the name spaces for CA certificates overlaps 
>>but no naming authority exists.  It is still the responsibility of 
>>each CA to ensure that
>
>>there are no name collisions in CA certificates it issues!  This is 
>>not
>>generally a problem, since we require names to be meaningful.  A CA should

>>never issue a certificate to a CA with the DN "C=US, O=Coca Cola" unless 
>>the subject CA is associated with that company.  Similarly, if a CA issues

>>certificates in the DIT "C=US, O=Coca Cola" then it must be associated
with
>
>>the company!
>>
>>Of course, a rogue CA may masquerade under the wrong name, or issue 
>>certificates in a DIT it clearly has no right to use, but no decent CA 
>>will
>
>>cross certify with it.  Since we are interested in ambiguity with 
>>respect
>>to a trust anchor, the behavior of a rogue CA is irrelevant.  Without
cross
>
>>certification, no paths involving the rogue CA can be constructed.  
>>(Note
>>that users installing the rogue as a trust anchor is out of scope here!)
>>
>>However, authority for a name space is not always crystal clear.
>>Without a
>>central naming authority, there is no clear title for a particular DIT.
We
>
>>rely on heuristics that work nicely for large entities like Coca-Cola 
>>but
>>may fail for smaller organizations.  For example, there may be a number of

>>companies with variants on a particular name.  If the name space assumed
by
>
>>an organization asserts "Orion" rather than "Orion Security" or "Orion
>>Space Sciences", the name may be ambiguous without being blatantly 
>>false.  Each entity could reasonably assign user names in the "C=US, 
>>O=Orion" DIT.   If each organization established their CA with the name 
>>"C=US, O=Orion, CN=CA1" things could get really ugly.
>>
>>A trust anchor T may cross certify with two different CAs - say the
>>ones
>>from NIST and NASA.  Each of those CAs may have a relationship with an 
>>"Orion".  If each of them cross certifies with the Orion they know and 
>>love, we have an immediate name collision for a CA named "C=US, O=Orion, 
>>CN=CA1", and potentially name collisions for "C=US, O=Orion, CN=John 
>>Wilson", etc., etc.  Each CA has played by the rules, but names have just 
>>become ambiguous with respect to T.  This might be avoided if T is
involved
>
>>in the policy decisions leading up to cross certification - but that 
>>is
>>often NOT the case.
>>
>>Fortunately, we need not depend on policy alone.   Beyond the 
>>procedural/policy issues, there are some important mechanisms that 
>>help
>>us
>>with name space control.  Most significant are path length constraints and

>>name constraints.  When trust anchor T issued those CA certificates, it 
>>probably wasn't expecting to accept transitive trust from those CAs, and
it
>
>>certainly didn't expect to accept the NIST or NASA CA as authoritative 
>>for
>>the "C=US, O=Orion" DIT.
>>
>>I listed path length constraints first because this mechanism provides
>>the
>>simplest and most widely available of our technical controls. Both NASA
and
>
>>NIST use a single CA, rather than a mesh or hierarchy.  If the trust 
>>anchor
>
>>does not wish to leverage other cross certifications performed by NASA 
>>or
>>NIST, it simply asserts a path length constraint of zero!  If T asserted 
>>this constraint for at least one of the NIST or NASA CAs, then the name 
>>"C=US, O=Orion, CN=John Wilson" is unambiguous. While this control was not

>>designed exclusively for name space control, it does have the effect of 
>>prevenmting subsequent CAs from introducing unexpected name spaces.
>>
>>Unfortunately, this does not solve our problem for "C=US, O=Orion, 
>>CN=CA1".   This name remains ambiguous.  Even with a path length 
>>constraints of zero, a relying party can validate a CRL from either
>>Orion CA.
>>
>>Name constraints is a more appealing technical mechanism, if less 
>>consistently available.  T can explicitly designate the name spaces it 
>>wishes to recognize in the cross certificate issued to NIST (or NASA).  
>>By asserting a permitted subtree of "C=US, O=U.S. Government, OU=NIST" 
>>with a SkipCerts of zero, certificates in the Orion name space are 
>>immediately eliminated.  This includes the offending CA certificate, 
>>so the "wrong" CRL
>
>>no longer validates.
>>
>>Case 3: Consider a PKI with trust anchor T, and CAs C1, C2, and C3.
>>C1,
>>C2, and C3 issue end user certificates in the DITs N1, N2, and N3
>respectively.
>>
>>N1 and N2 are disjoint, but  N3 overlaps with N1 or N2.  C3 does not 
>>recognize the same naming authority as C1 or C2.   If name constraints 
>>permitted subtrees P3 is imposed in all cross certificates issued to
>>C3,
>>where N1, N2, and P3 are pairwise disjoint, then names are unambiguous
with
>
>>respect to T.  (Names that could have collided are excluded from C3's 
>>DIT.)
>>
>>Conclusion/Proposal
>>
>>Ambiguity in names is a relatively minor risk with respect to a given
>>trust
>>anchor.  Ambiguity does not occur because of the actions of a single CA; 
>>rather it requires a combination of actions by different CAs within the 
>>infrastructure.  If all CA certificates accurately reflect the trust 
>>relationships between the CAs by incorporating appropriate path length and

>>name constraints, these risks are greatly reduced if not eliminated.
>>
>>The risk of ambiguous names can be mitigated with a relatively simple 
>>modification in 3280bis, and the addition of some security 
>>considerations.  Most importantly, 32890bis should be modified to 
>>ensure that certificate and CRL validation are always performed with 
>>respect to the same trust anchor.  Security considerations should be 
>>added to highlight the risk of issuing CA certificates without 
>>appropriate constraints, and to caution application developers that 
>>trust anchor information should be considered when accepting 
>>certificates.
>>
>>The changes that I believe should be implemented are as follows:
>>
>>  (1) Modify section 6.3.3 to state that CRL validation MUST use the
>>same
>>trust anchor T specified in the corresponding certification path.
>>
>>(2) Add security considerations that indicate applications that accept 
>>multiple trust anchors should consider the trust anchor in access 
>>control decisions to ensure that names are unambiguous.
>>
>>(3) Add security considerations that explain the importance of
>>consistent
>>use of path length and name constraints in preventing name ambiguity.
>>
>>
>
>Regards,
>
>Denis Pinkas
>
>
>

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 j6IFuIP0008779; Mon, 18 Jul 2005 08:56: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 j6IFuIjR008778; Mon, 18 Jul 2005 08:56:18 -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 j6IFuHws008746 for <ietf-pkix@imc.org>; Mon, 18 Jul 2005 08:56:17 -0700 (PDT) (envelope-from denis.pinkas@bull.net)
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id SAA23380; Mon, 18 Jul 2005 18:12:09 +0200
Received: from frcls4013 ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with SMTP id 2005071817571229:1235 ; Mon, 18 Jul 2005 17:57:12 +0200 
Date: Mon, 18 Jul 2005 17:57:28 +0100
From: "Denis Pinkas" <denis.pinkas@bull.net>
To: "'pkix'" <ietf-pkix@imc.org>, "Santosh Chokhani" <chokhani@orionsec.com>
Subject: Re: Correction to be done to <draft-pinkas-pkix-conf-crl-validation-01.txt>
X-mailer: Foxmail 5.0 [-fr-]
Mime-Version: 1.0
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 18/07/2005 17:57:12, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 18/07/2005 17:57:13, Serialize complete at 18/07/2005 17:57:13
Message-ID: <OF3EA3B5F0.4F56956D-ONC1257042.0057A281@frcl.bull.fr>
Content-Transfer-Encoding: 7bit
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>

>Denis,

>The specific sentence in 3280 may need to be revised or may have been taken
>out of context.

Thank you for finally acknowledging the fact that the current definition of 
an "indirect CRL" is incompatible with your "State Machine".

There are several ways to correct the problem. Among them :

1) keep the State Machine and change the definition of an indirect CRL.
2) take draft-pinkas-pkix-conf-crl-validation-02.txt (it is not yet published) 
    and change the definition of an indirect CRL.

Now you see the common point: in both cases the proposal is to change 
the definition of an indirect CRL, but the reason for changing it are quite different.

You want to change it so that your State Machine keeps working, whereas 
I want to change it to make the case where a CA designates its own CRL issuer
easy and simple to implement. That case may be handled without the 
need to support both the IDP extension and the certificate issuer CRL entry 
extension.

This may definitively encourage implementers to implement the case where 
the CA designates its own CRL issuer.

The case where a CRL issuer serves more than one CA is less likely to happen.

In addition, note that when an indirect CRL may contain serial numbers from 
certificates issued by more than one CA, then it is possible to go backwards. 
It is of course also possible to go onwards as you mentioned, but this is NOT 
mandatory.

Denis 

>A CRL issuer asserts indirect CRL flag when the CRL is supposed to cover
>certificates not issued by the CRL issuer.  Note that there may not be any
>entries for other CAs since none of their certificates may be revoked.
>
>But, the CRL issuer can cover the certificates issued by the CRL issuer (if
>it is a CA) in that indirect CRL.
>
>The State Machine is correct.
>
>-----Original Message-----
>From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On
>Behalf Of Denis Pinkas
>Sent: Monday, July 18, 2005 6:05 AM
>To: 'pkix'; Santosh Chokhani
>Subject: Re: Correction to be done to
><draft-pinkas-pkix-conf-crl-validation-01.txt>
>
>
>
>Santosh,
>
>>My apologies to the list for typo.
>>
>>In the last paragraph, "CRL issuer" was meant to say "certificate 
>>issuer". It is corrected below.
>>
>>-----Original Message-----
>>From: Santosh Chokhani [mailto:chokhani@orionsec.com]
>>Sent: Friday, July 15, 2005 1:09 PM
>>To: 'pkix'
>>Subject: RE: Correction to be done to
>><draft-pinkas-pkix-conf-crl-validation-01.txt>
>
>
>>Denis,
>
>>The indirect CRL state machine is as follows:
>
>>	initial value of certificate_issuer_state = issuer field in the CRL
>>(1)
>
>The current sentence of RFC 3280 is : "Whenever the CRL issuer is not the CA
>
>that issued the certificates, the CRL is referred to as an indirect CRL".
>
>This means that when a CRL is an indirect CRL, then none of the certificates
>
>that are present in the CRL can be issued under the name that is present 
>in the issuer name of the CRL.
>
>So unless the definition of an indirect CRL is modified, the certificate
>issuer name
>cannot default to the issuer name of the CRL.
>
>So the "state machine" you propose is not correct.
>
>Stefan said:
>
>"Finally I do not worry too much about deployed products concerning
>indirect CRLs since this is an almost non used feature as far as I know."
>
>It is time to fix the issue so that cases where the various cases where CA 
>is not the issuer of the CRL can be undertsood and implemented.
>
>Some are simpler than others.
>
>Your message triggered another look to my I-D on that topic and I noticed 
>that a case was forgotten in <draft-pinkas-pkix-conf-crl-validation-02.txt>
>:
>a CRL could contain the same serial number, but from different CAs.
>
>This is now handled in <draft-pinkas-pkix-conf-crl-validation-02.txt> 
>that has been posted before the dead line for submissions, but is 
>not yet available.
>
>
>Denis
>	
>>	certificate_issuer  = value in the CRL entry extension and if the
>>extension is absent, certificate_issuer = certificate_issuer_state (2)
>>
>>	certificate_issuer_state = certificate_issuer
>>
>>It is secure, standard compliant and provides for interoperability.  It is
>>probably too complex in comparison to doing nothing and yet to be defined
>>Denis's algorithms on a variety of CRL processing matters.
>>
>>If the indirect CRL issuer is not a CA, the first revoked certificate entry
>>will contain a certificate issuer field.  There are numerous other
>>situations when first revoked certificate entry will contain a certificate
>>issuer field, but this is of no interest to a relying party that wants to
>>write a secure, interoperable, simple (i.e., not complex) CRL processing
>>logic.
>>
>>-----Original Message-----
>>From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On
>>Behalf Of Denis Pinkas
>>Sent: Friday, July 15, 2005 4:24 AM
>>To: pkix
>>Subject: Correction to be done to
>><draft-pinkas-pkix-conf-crl-validation-01.txt>
>>
>>
>>
>>
>>A correction needs to be done to 
>><draft-pinkas-pkix-conf-crl-validation-01.txt>.
>>
>>As explained in a previous e-mail, the certificate issuer name cannot
>>default to the name of the CRL issuer, hence the following text 
>>extracted from section 6.3.3.3 is incorrect :
>>
>>        (ii) check if there exists a previous CRL entry
>>             and if that CRL entry contains a Certificate
>>             Issuer CRL entry extension and go back to (1).
>>
>>                If there is no previous CRL entry, then
>>                check if the name of the issuer of the CRL
>>                matches the name of the issuer field of the
>>                target certificate.
>>
>>                 - If it does, then set the cert_revoc_status
>>                   variable to REVOKED and if the CRL entry
>>                   extension " reasonCode " is present in
>>                   that CRL entry, then set the revoc_reason
>>                   variable to the value contained in that CRL
>>                   entry extension and the algorithm
>>                   terminates.
>>
>>                 - If it does, then set the cert_revoc_status
>>                   variable to NOT_REVOKED and the algorithm
>>                   terminates.
>>
>>It would need to be corrected (and greatly simplified)
>>in the following way:
>>
>>          (ii) If there is no previous CRL entry, then
>>               this is an error in the structure of the CRL
>>               and the algorithm terminates.
>>
>>               Otherwise, check if that CRL entry contains
>>               a Certificate Issuer CRL entry extension and
>>               go back to (1).
>>
>>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 j6IFtEWN008621; Mon, 18 Jul 2005 08:55: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 j6IFtEgp008620; Mon, 18 Jul 2005 08:55:14 -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 j6IFtCw4008598 for <ietf-pkix@imc.org>; Mon, 18 Jul 2005 08:55:13 -0700 (PDT) (envelope-from denis.pinkas@bull.net)
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id SAA56586; Mon, 18 Jul 2005 18:10:52 +0200
Received: from frcls4013 ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with SMTP id 2005071817555460:1234 ; Mon, 18 Jul 2005 17:55:54 +0200 
Date: Mon, 18 Jul 2005 17:56:10 +0100
From: "Denis Pinkas" <denis.pinkas@bull.net>
To: "Santosh Chokhani" <chokhani@orionsec.com>, "ietf-pkix@imc.org" <ietf-pkix@imc.org>
Subject: Re: How ambiguous are names in actuality?
X-mailer: Foxmail 5.0 [-fr-]
Mime-Version: 1.0
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 18/07/2005 17:55:54, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 18/07/2005 17:55:56, Serialize complete at 18/07/2005 17:55:56
Message-ID: <OF246C1757.86E679D9-ONC1257042.00578433@frcl.bull.fr>
Content-Transfer-Encoding: 7bit
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>

Santosh,

>To me the basic problem with Tim's posting is that it is a band aid solution
>to a problem that has a very simple solution.

The problem raised is much wider that the CRL problem where the solution 
fits in two lines of text:

"The full certification path that has been used to validate the target
  certificate MUST also be used to validate the CRL issuer certificate". 

As far as I remember I have not seen a description of your solution posted in: 
http://www.ietf.org/internet-drafts/draft-santosh-pkix-...-00.txt

Denis

>When we look at the issue as an abstract graph theory problem and want a
>clean and simple solution to make sure that the correct CRL is fetched, the
>solution I have proposed solves the problem.
>
>Any thing else we do, is simply rationalization to support one or more
>unarticulated motives.
>
>-----Original Message-----
>From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On
>Behalf Of Denis Pinkas
>Sent: Monday, July 18, 2005 5:13 AM
>To: Tim Polk; ietf-pkix@imc.org
>Subject: Re: How ambiguous are names in actuality?
>
>
>
>Tim,
>
>My views are quite different. You are looking for a solution to MITIGATE the
>risk, 
>whereas there exists a solution to SUPPRESS the risk, as it is explained
>below. 
>The changes you propose, like "same trust anchor", do not suppress the risk.
>
>
>You mention that the problem of name collisions exists both for two leaf
>certificates 
>and for CRL certificates. This is correct. While the problem for CRL
>certificates arises 
>only *during* the path verification algorithm, this is not the case for leaf
>certificates.
>
>For a leaf certificate that has been verified to be valid, the output of the
>algorithm 
>is a sequence of certificates up to a given trust anchor. The major issue is
>what 
>to do with it, and this is NOT mentioned within RFC 3280.
>
>Leaf certificates may be used in two contexts:
>
>   a) access control or end-entity authentication,
>   b) non repudiation.
>
>These two cases are different and are explored below.
>
>ACCESS CONTROL OR END-ENTITY AUTHENTICATION
>
>There are two phases when a public key certificate is used for an access
>control service : 
>
>- Phase 1 : the owner of the protected object must fill-in the ACL
>correctly,
>- Phase 2 : during an access, the sequence of certificates that has been
>validated 
>                must be checked against the content of the ACL.
>
>The real issue is that nowhere in RFC 3280 it is said what the content of
>the ACL should be. 
>Because of this lack of information, some implementations of "relying party
>software" 
>may be subject to problems related to name collisions, while some others
>will not. 
>
>There is no clear indication in RFC 3280 to tell how the owner of the
>protected object 
>will make sure that it is pointing to the right certificate BEFORE using
>that certificate 
>for access control purposes. 
>
>The point is that the owner of the protected object SHALL enter the full
>certification path 
>in the ACL. If it does not have the full path, then it SHALL construct it
>according to 
>the validation policy that is appropriate for his application and SHOULD
>make sure 
>that it is not revoked. It will thus use the full certification path and may
>check either 
>automatically using some local rules or may check using his brain that the
>full certification 
>path is correct.
>
>Note that if the ACL would only contain the DN of the leaf certificate, then
>the access control 
>mechanism would be subject to name collisions,
>
>When the ACL contains both the DN of the leaf certificate and all the DNs
>from the upper CA 
>up to a trust anchor identified by its DN (i.e. the DN of the trust anchor
>is also taken, 
>since there may be more than one trust anchor in a given validation policy),
>then the 
>access control mechanism can never be subject to name collisions.
>
>Since a validation policy may include more than one trust anchor, it means
>that it 
>SHALL not be allowed to define a validation policy that uses two trust
>anchors with the same DN.
>
>This means that during phase 1, the owner of the protected object must
>fill-in the ACL 
>with all the DNs from the certification path, including the DN from the
>trust anchor 
>(of course a hash of it may be used instead) and that during phase 2, the
>whole certification path 
>must be used and compared with the content of the ACL.
>
>This solution fully *suppresses* the risk in any case.
>
>Of course, in some contexts, some shortcuts may be taken (e.g. when there
>exists a single 
>trust anchor in the validation policy) or when it may be known that name
>collisions 
>may never happen (e.g. because all the CAs apply a given naming policy) but
>this is not 
>the general case. 
>
>The solution explained above is also much simpler than adding name
>constrains 
>that could be anyway defeated.
>
>NON REPUDIATION
>
>With non repudiation, only the whole sequence of DN extracted from the
>certification path 
>is meaningful. A DN like CN= "John William" does not make sense unless at
>the same time 
>all the upper DNs from the CAs are used or displayed. So if someone wants to
>know 
>without any ambiguity who a signer is, it SHALL use of the sequence of DN up
>to 
>a trust anchor of the signature policy. 
>
>Since a signature policy may include more than one trust anchor, it means
>that it SHALL NOT 
>be allowed to define a signature policy that uses two trust anchors with the
>same DN.
>
>COLLISIONS BETWEEN CRL ISSUER NAMES
>
>For CRLs, I have already mentioned the additional sentence that shall be
>added to RFC 3280. It is copied again below  :
>
>"The full certification path that has been used to validate the target
>certificate MUST also be 
>used to validate the CRL issuer certificate ".
>
>
>REPLY TO YOUR CONCLUSIONS
>
>As a reply to your conclusions: using path length constrains does not solve
>the issue. 
>Adding other constrains does not solve the issue either. Using name
>constraints would 
>introduce an order of magnitude of complexity and would not be effective in
>the general case. 
>Using certification policies and path length constrains might help, but
>still do not solve 
>the problem in the general case.
>
>
>Denis
>
>
>>Ambiguity has recently become a hot topic on this list.  This is a 
>>really
>>complicated issue, and I have personally had a great deal of trouble 
>>sorting out the real level of risk.  Some of the proposed changes would 
>>greatly impact current software, and these changes should only be 
>>contemplated if the risk is merits such change.
>>
>>So, I have spent a lot of time, off and on, thinking about ambiguity.  
>>I
>>can't claim to have sorted it all out, but I have convinced myself that one
>
>>minor change is absolutely required, and that the current suite of 
>>mechanisms can virtually eliminate ambiguity in real PKIs.
>>
>>My thinking is appended to this message;  I apologize for its length, 
>>but
>>to paraphrase Mark Twain, I simply don't have time to make this short and 
>>concise.  I have attempted to define ambiguity, characterize the ways 
>>ambiguity can enter into a PKI, and describe the set of mechanisms that 
>>mitigate this risk.
>>
>>Thanks,
>>
>>Tim Polk
>>
>>-----------------------------------------------------------------------
>>---------------------------------------------------------
>>
>>              How ambiguous are names in actuality, and how important 
>> is it?
>>
>>I believe that X.509 expected assignment of unambiguous names based on 
>>a
>>hierarchical system of naming authorities.  Whether you agree with that 
>>premise, it is safe to say that the global X.500 directory and its 
>>corresponding system of naming authorities do not exist. So, it may not be 
>>safe to assume that there are no name collisions whatsoever in all the DNs 
>>that appear in certificates and CRLs!  I am sure such collisions exist 
>>somewhere (although I haven't encountered any examples).  The real question
>
>>here is "What security risk does this situation present, and are the 
>>current mechanisms adequate to address this risk?"
>>
>>Let's recognize that the goal for PKIX is not to have globally 
>>unambiguous
>>names, but to be able to obtain a trustworthy public key to establish a 
>>security service. Ambiguity in names is a problem when it causes the 
>>relying party to trust the wrong public key.
>>
>>There are two ways ambiguous names could cause problems.  First, I 
>>could
>>accept public keys from two certificates as representing the same person 
>>based on the same subject name.  If these two certificates are bound to 
>>different individuals I may provide a service to the wrong party (or 
>>disclose confidential data, etc., etc.)  Second, I could accept a CRL to 
>>validate a particular certificate, based on the same issuer name in the 
>>certificate and CRL.  If the certificate and CRL were not actually issued 
>>by the same CA, then the relying party may obtain incorrect certificate
>status.
>>
>>Note that both of these problems are in the context of path validation.  
>>If
>>a name collision exists, but only one of the objects (e.g., certificate or 
>>CRL) validates for a given relying party, then there is no actual ambiguity
>
>>from that relying party's point of view.
>>
>>That is, assume two certificates exist with the same subject name but 
>>are
>>bound to different people.  If Alice can only validate one of those 
>>certificates, there is no ambiguity in Alice's world.   Similarly, if Bob 
>>can only validate one of those certificates, there is no ambiguity in Bob's
>
>>world.   (It does not matter if Bob and Alice are validating the same 
>>certificate, or different ones!)   Similarly, if two CAs have the same 
>>issuer name, but Alice can only validate one, she can't accept the wrong 
>>CRL.  Ditto for Bob.
>>
>>So, ambiguity is a concern only in the context of path validation for a
>>given relying party. This means that the mechanisms that are employed in 
>>path validation are relevant to when names are, and are not, ambiguous. I'd
>
>>also like to point out that path validation is always performed in the 
>>context of a particular trust anchor.  (A relying party may accept paths 
>>that begin with multiple trust anchors, but each specific path has a single
>
>>trust anchor.)  Seems irrelevant at the moment, but I will get back to it!
>>
>>Definition 1:  a Name N is unambiguous for a trust anchor T if and only 
>>if
>>all certificates that validate for T and have the subject N refer to the 
>>same entity.
>>
>>Now, let's think about where name collisions can occur in the first 
>>place.
>>There seems to be consensus that a single CA will not issue two 
>>certificates to two different entities with the same subject name.  So, if 
>>a single CA issues two certificates to "O=Microsoft, cn=John Wilson" they 
>>better relate to the same guy.  Similarly if a particular CA issues two 
>>certificates to "c=US, O=U.S. Government, OU=NIST, CN=CA1" then the subject
>
>>of both certificates must be the same CA.
>>
>>So, we are only worried about the case where two different CAs are 
>>trusted
>>with respect to a trust anchor T and issue certificates to different 
>>subjects but use the same name.  So, when can name collisions occur between
>
>>CAs?  Or, better yet, under what conditions can we be sure name collisions 
>>won't occur?  Let's start with user certificates.
>>
>>In general, each CA that issues user certificates does so for a 
>>particular
>>name space.  That is, all names assigned to users will be in a particular 
>>Directory Information Tree (DIT).   The CA will either work with a naming 
>>authority that it considers authoritative or may assume that function 
>>itself.   For example, the NIST CA only issues user certificates in the 
>>"C=US, O=U.S. Government, OU=NIST" DIT.   The NIST CA has been designated 
>>as our naming authority as well, so it keeps track of the names it 
>>assigns.  Similarly, the CA that supports NASA only issues certificates for
>
>>the name space "C=US,  O=U.S. Government, OU=NASA" DIT.
>>
>>These name spaces are disjoint, so name collisions cannot occur 
>>involving
>>user certificates generated by the NASA and NIST CAs.  In fact, consider a 
>>PKI with trust anchor T and CAs C(1), C(2), ., C(n) issuing for name spaces
>
>>P(1), P(2), ., P(n).  If spaces P(1), P(2), ., P(n) are pairwise disjoint, 
>>name collisions cannot occur involving user certificates generated by C(1),
>
>>C(2), ., C(n).
>>
>>Case 1:  Consider a PKI with trust anchor T, and CAs C1, C2, and C3.  
>>C1,
>>C2, and C3 issue end user certificates in the DITs N1, N2, and N3 
>>respectively.  If N1, N2, and N3 are pairwise disjoint, then the user names
>
>>are unambiguous with respect to T.
>>
>>In more complex PKIs, we may encounter situations where CAs issue user
>>certificates for name spaces that overlap.  For example, in the U.S DoD's 
>>hierarchical PKI, CAs all issue certificates in the DIT "C=US, O=U.S. 
>>Government, OU=DOD".  Users routinely receive three certificates from two 
>>different CAs, so all the DoD CAs rely on a common naming authority to 
>>ensure that certificates with the same DNs are issued to the same person.
>>
>>Case 2: Consider a PKI with trust anchor T, and CAs C1, C2, and C3.  
>>C1,
>>C2, and C3 issue end user certificates in the DITs N1, N2, and N3 
>>respectively.  N1 and N2 overlap, but N3 is disjoint from N1 and N2.   If 
>>CA1 and CA2 recognize the same naming authority, then the user names in the
>
>>PKI are unambiguous with respect to T.
>>
>>That is, if all the CAs either: (1) issue certificates in disjoint name
>>spaces, or (2) issue certificates in shared name spaces based on a common 
>>naming authority, names will be unambiguous!
>>
>>Of course, CAs may issue CA certificates as well.  In this case, the CA
>>does not assign the names, but rather uses the established name.  This is 
>>trickier, since the name spaces for CA certificates overlaps but no naming 
>>authority exists.  It is still the responsibility of each CA to ensure that
>
>>there are no name collisions in CA certificates it issues!  This is not 
>>generally a problem, since we require names to be meaningful.  A CA should 
>>never issue a certificate to a CA with the DN "C=US, O=Coca Cola" unless 
>>the subject CA is associated with that company.  Similarly, if a CA issues 
>>certificates in the DIT "C=US, O=Coca Cola" then it must be associated with
>
>>the company!
>>
>>Of course, a rogue CA may masquerade under the wrong name, or issue
>>certificates in a DIT it clearly has no right to use, but no decent CA will
>
>>cross certify with it.  Since we are interested in ambiguity with respect 
>>to a trust anchor, the behavior of a rogue CA is irrelevant.  Without cross
>
>>certification, no paths involving the rogue CA can be constructed.  (Note 
>>that users installing the rogue as a trust anchor is out of scope here!)
>>
>>However, authority for a name space is not always crystal clear.  
>>Without a
>>central naming authority, there is no clear title for a particular DIT.  We
>
>>rely on heuristics that work nicely for large entities like Coca-Cola but 
>>may fail for smaller organizations.  For example, there may be a number of 
>>companies with variants on a particular name.  If the name space assumed by
>
>>an organization asserts "Orion" rather than "Orion Security" or "Orion 
>>Space Sciences", the name may be ambiguous without being blatantly 
>>false.  Each entity could reasonably assign user names in the "C=US, 
>>O=Orion" DIT.   If each organization established their CA with the name 
>>"C=US, O=Orion, CN=CA1" things could get really ugly.
>>
>>A trust anchor T may cross certify with two different CAs - say the 
>>ones
>>from NIST and NASA.  Each of those CAs may have a relationship with an 
>>"Orion".  If each of them cross certifies with the Orion they know and 
>>love, we have an immediate name collision for a CA named "C=US, O=Orion, 
>>CN=CA1", and potentially name collisions for "C=US, O=Orion, CN=John 
>>Wilson", etc., etc.  Each CA has played by the rules, but names have just 
>>become ambiguous with respect to T.  This might be avoided if T is involved
>
>>in the policy decisions leading up to cross certification - but that is 
>>often NOT the case.
>>
>>Fortunately, we need not depend on policy alone.   Beyond the 
>>procedural/policy issues, there are some important mechanisms that help 
>>us
>>with name space control.  Most significant are path length constraints and 
>>name constraints.  When trust anchor T issued those CA certificates, it 
>>probably wasn't expecting to accept transitive trust from those CAs, and it
>
>>certainly didn't expect to accept the NIST or NASA CA as authoritative for 
>>the "C=US, O=Orion" DIT.
>>
>>I listed path length constraints first because this mechanism provides 
>>the
>>simplest and most widely available of our technical controls. Both NASA and
>
>>NIST use a single CA, rather than a mesh or hierarchy.  If the trust anchor
>
>>does not wish to leverage other cross certifications performed by NASA or 
>>NIST, it simply asserts a path length constraint of zero!  If T asserted 
>>this constraint for at least one of the NIST or NASA CAs, then the name 
>>"C=US, O=Orion, CN=John Wilson" is unambiguous. While this control was not 
>>designed exclusively for name space control, it does have the effect of 
>>prevenmting subsequent CAs from introducing unexpected name spaces.
>>
>>Unfortunately, this does not solve our problem for "C=US, O=Orion, 
>>CN=CA1".   This name remains ambiguous.  Even with a path length 
>>constraints of zero, a relying party can validate a CRL from either 
>>Orion CA.
>>
>>Name constraints is a more appealing technical mechanism, if less
>>consistently available.  T can explicitly designate the name spaces it 
>>wishes to recognize in the cross certificate issued to NIST (or NASA).  By 
>>asserting a permitted subtree of "C=US, O=U.S. Government, OU=NIST" with a 
>>SkipCerts of zero, certificates in the Orion name space are immediately 
>>eliminated.  This includes the offending CA certificate, so the "wrong" CRL
>
>>no longer validates.
>>
>>Case 3: Consider a PKI with trust anchor T, and CAs C1, C2, and C3.  
>>C1,
>>C2, and C3 issue end user certificates in the DITs N1, N2, and N3
>respectively.
>>
>>N1 and N2 are disjoint, but  N3 overlaps with N1 or N2.  C3 does not 
>>recognize the same naming authority as C1 or C2.   If name constraints 
>>permitted subtrees P3 is imposed in all cross certificates issued to 
>>C3,
>>where N1, N2, and P3 are pairwise disjoint, then names are unambiguous with
>
>>respect to T.  (Names that could have collided are excluded from C3's DIT.)
>>
>>Conclusion/Proposal
>>
>>Ambiguity in names is a relatively minor risk with respect to a given 
>>trust
>>anchor.  Ambiguity does not occur because of the actions of a single CA; 
>>rather it requires a combination of actions by different CAs within the 
>>infrastructure.  If all CA certificates accurately reflect the trust 
>>relationships between the CAs by incorporating appropriate path length and 
>>name constraints, these risks are greatly reduced if not eliminated.
>>
>>The risk of ambiguous names can be mitigated with a relatively simple
>>modification in 3280bis, and the addition of some security 
>>considerations.  Most importantly, 32890bis should be modified to ensure 
>>that certificate and CRL validation are always performed with respect to 
>>the same trust anchor.  Security considerations should be added to 
>>highlight the risk of issuing CA certificates without appropriate 
>>constraints, and to caution application developers that trust anchor 
>>information should be considered when accepting certificates.
>>
>>The changes that I believe should be implemented are as follows:
>>
>>  (1) Modify section 6.3.3 to state that CRL validation MUST use the 
>>same
>>trust anchor T specified in the corresponding certification path.
>>
>>(2) Add security considerations that indicate applications that accept
>>multiple trust anchors should consider the trust anchor in access control 
>>decisions to ensure that names are unambiguous.
>>
>>(3) Add security considerations that explain the importance of 
>>consistent
>>use of path length and name constraints in preventing name ambiguity.
>>
>>
>
>Regards,
>
>Denis Pinkas
>
>
>

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 j6IDx6jf094417; Mon, 18 Jul 2005 06:59: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 j6IDx6Vl094416; Mon, 18 Jul 2005 06:59:06 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from IP0fCard1 (host2.ewrrn.hyatthsia.com [12.161.245.2] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6IDx5Y3094407 for <ietf-pkix@imc.org>; Mon, 18 Jul 2005 06:59:05 -0700 (PDT) (envelope-from chokhani@orionsec.com)
Received: from wchokhani3 (globalsuite.gtcorp.com [127.0.0.1]) by IP0fCard1 (8.11.6/8.11.6) with ESMTP id j6IDwpB03953 for <ietf-pkix@imc.org>; Mon, 18 Jul 2005 09:58:52 -0400
From: "Santosh Chokhani" <chokhani@orionsec.com>
To: <ietf-pkix@imc.org>
Subject: RE: How ambiguous are names in actuality?
Date: Mon, 18 Jul 2005 09:58:58 -0400
Message-ID: <00c401c58ba0$d8863730$cbb011ac@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.2900.2180
In-Reply-To: <OFE12E6CDC.2B167B87-ONC1257042.002D204F@frcl.bull.fr>
Importance: Normal
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j6IDx5Y3094411
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

To me the basic problem with Tim's posting is that it is a band aid solution
to a problem that has a very simple solution.

When we look at the issue as an abstract graph theory problem and want a
clean and simple solution to make sure that the correct CRL is fetched, the
solution I have proposed solves the problem.

Any thing else we do, is simply rationalization to support one or more
unarticulated motives.

-----Original Message-----
From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On
Behalf Of Denis Pinkas
Sent: Monday, July 18, 2005 5:13 AM
To: Tim Polk; ietf-pkix@imc.org
Subject: Re: How ambiguous are names in actuality?

Tim,

My views are quite different. You are looking for a solution to MITIGATE the
risk, 
whereas there exists a solution to SUPPRESS the risk, as it is explained
below. 
The changes you propose, like "same trust anchor", do not suppress the risk.

You mention that the problem of name collisions exists both for two leaf
certificates 
and for CRL certificates. This is correct. While the problem for CRL
certificates arises 
only *during* the path verification algorithm, this is not the case for leaf
certificates.

For a leaf certificate that has been verified to be valid, the output of the
algorithm 
is a sequence of certificates up to a given trust anchor. The major issue is
what 
to do with it, and this is NOT mentioned within RFC 3280.

Leaf certificates may be used in two contexts:

   a) access control or end-entity authentication,
   b) non repudiation.

These two cases are different and are explored below.

ACCESS CONTROL OR END-ENTITY AUTHENTICATION

There are two phases when a public key certificate is used for an access
control service : 

- Phase 1 : the owner of the protected object must fill-in the ACL
correctly,
- Phase 2 : during an access, the sequence of certificates that has been
validated 
                must be checked against the content of the ACL.

The real issue is that nowhere in RFC 3280 it is said what the content of
the ACL should be. 
Because of this lack of information, some implementations of "relying party
software" 
may be subject to problems related to name collisions, while some others
will not. 

There is no clear indication in RFC 3280 to tell how the owner of the
protected object 
will make sure that it is pointing to the right certificate BEFORE using
that certificate 
for access control purposes. 

The point is that the owner of the protected object SHALL enter the full
certification path 
in the ACL. If it does not have the full path, then it SHALL construct it
according to 
the validation policy that is appropriate for his application and SHOULD
make sure 
that it is not revoked. It will thus use the full certification path and may
check either 
automatically using some local rules or may check using his brain that the
full certification 
path is correct.

Note that if the ACL would only contain the DN of the leaf certificate, then
the access control 
mechanism would be subject to name collisions,

When the ACL contains both the DN of the leaf certificate and all the DNs
from the upper CA 
up to a trust anchor identified by its DN (i.e. the DN of the trust anchor
is also taken, 
since there may be more than one trust anchor in a given validation policy),
then the 
access control mechanism can never be subject to name collisions.

Since a validation policy may include more than one trust anchor, it means
that it 
SHALL not be allowed to define a validation policy that uses two trust
anchors with the same DN.

This means that during phase 1, the owner of the protected object must
fill-in the ACL 
with all the DNs from the certification path, including the DN from the
trust anchor 
(of course a hash of it may be used instead) and that during phase 2, the
whole certification path 
must be used and compared with the content of the ACL.

This solution fully *suppresses* the risk in any case.

Of course, in some contexts, some shortcuts may be taken (e.g. when there
exists a single 
trust anchor in the validation policy) or when it may be known that name
collisions 
may never happen (e.g. because all the CAs apply a given naming policy) but
this is not 
the general case. 

The solution explained above is also much simpler than adding name
constrains 
that could be anyway defeated.

NON REPUDIATION

With non repudiation, only the whole sequence of DN extracted from the
certification path 
is meaningful. A DN like CN= "John William" does not make sense unless at
the same time 
all the upper DNs from the CAs are used or displayed. So if someone wants to
know 
without any ambiguity who a signer is, it SHALL use of the sequence of DN up
to 
a trust anchor of the signature policy. 

Since a signature policy may include more than one trust anchor, it means
that it SHALL NOT 
be allowed to define a signature policy that uses two trust anchors with the
same DN.

COLLISIONS BETWEEN CRL ISSUER NAMES

For CRLs, I have already mentioned the additional sentence that shall be
added to RFC 3280. It is copied again below  :

"The full certification path that has been used to validate the target
certificate MUST also be 
used to validate the CRL issuer certificate ".

REPLY TO YOUR CONCLUSIONS

As a reply to your conclusions: using path length constrains does not solve
the issue. 
Adding other constrains does not solve the issue either. Using name
constraints would 
introduce an order of magnitude of complexity and would not be effective in
the general case. 
Using certification policies and path length constrains might help, but
still do not solve 
the problem in the general case.

Denis

>Ambiguity has recently become a hot topic on this list.  This is a 
>really
>complicated issue, and I have personally had a great deal of trouble 
>sorting out the real level of risk.  Some of the proposed changes would 
>greatly impact current software, and these changes should only be 
>contemplated if the risk is merits such change.
>
>So, I have spent a lot of time, off and on, thinking about ambiguity.  
>I
>can't claim to have sorted it all out, but I have convinced myself that one

>minor change is absolutely required, and that the current suite of 
>mechanisms can virtually eliminate ambiguity in real PKIs.
>
>My thinking is appended to this message;  I apologize for its length, 
>but
>to paraphrase Mark Twain, I simply don't have time to make this short and 
>concise.  I have attempted to define ambiguity, characterize the ways 
>ambiguity can enter into a PKI, and describe the set of mechanisms that 
>mitigate this risk.
>
>Thanks,
>
>Tim Polk
>
>-----------------------------------------------------------------------
>---------------------------------------------------------
>
>              How ambiguous are names in actuality, and how important 
> is it?
>
>I believe that X.509 expected assignment of unambiguous names based on 
>a
>hierarchical system of naming authorities.  Whether you agree with that 
>premise, it is safe to say that the global X.500 directory and its 
>corresponding system of naming authorities do not exist. So, it may not be 
>safe to assume that there are no name collisions whatsoever in all the DNs 
>that appear in certificates and CRLs!  I am sure such collisions exist 
>somewhere (although I haven't encountered any examples).  The real question

>here is "What security risk does this situation present, and are the 
>current mechanisms adequate to address this risk?"
>
>Let's recognize that the goal for PKIX is not to have globally 
>unambiguous
>names, but to be able to obtain a trustworthy public key to establish a 
>security service. Ambiguity in names is a problem when it causes the 
>relying party to trust the wrong public key.
>
>There are two ways ambiguous names could cause problems.  First, I 
>could
>accept public keys from two certificates as representing the same person 
>based on the same subject name.  If these two certificates are bound to 
>different individuals I may provide a service to the wrong party (or 
>disclose confidential data, etc., etc.)  Second, I could accept a CRL to 
>validate a particular certificate, based on the same issuer name in the 
>certificate and CRL.  If the certificate and CRL were not actually issued 
>by the same CA, then the relying party may obtain incorrect certificate
status.
>
>Note that both of these problems are in the context of path validation.  
>If
>a name collision exists, but only one of the objects (e.g., certificate or 
>CRL) validates for a given relying party, then there is no actual ambiguity

>from that relying party's point of view.
>
>That is, assume two certificates exist with the same subject name but 
>are
>bound to different people.  If Alice can only validate one of those 
>certificates, there is no ambiguity in Alice's world.   Similarly, if Bob 
>can only validate one of those certificates, there is no ambiguity in Bob's

>world.   (It does not matter if Bob and Alice are validating the same 
>certificate, or different ones!)   Similarly, if two CAs have the same 
>issuer name, but Alice can only validate one, she can't accept the wrong 
>CRL.  Ditto for Bob.
>
>So, ambiguity is a concern only in the context of path validation for a
>given relying party. This means that the mechanisms that are employed in 
>path validation are relevant to when names are, and are not, ambiguous. I'd

>also like to point out that path validation is always performed in the 
>context of a particular trust anchor.  (A relying party may accept paths 
>that begin with multiple trust anchors, but each specific path has a single

>trust anchor.)  Seems irrelevant at the moment, but I will get back to it!
>
>Definition 1:  a Name N is unambiguous for a trust anchor T if and only 
>if
>all certificates that validate for T and have the subject N refer to the 
>same entity.
>
>Now, let's think about where name collisions can occur in the first 
>place.
>There seems to be consensus that a single CA will not issue two 
>certificates to two different entities with the same subject name.  So, if 
>a single CA issues two certificates to "O=Microsoft, cn=John Wilson" they 
>better relate to the same guy.  Similarly if a particular CA issues two 
>certificates to "c=US, O=U.S. Government, OU=NIST, CN=CA1" then the subject

>of both certificates must be the same CA.
>
>So, we are only worried about the case where two different CAs are 
>trusted
>with respect to a trust anchor T and issue certificates to different 
>subjects but use the same name.  So, when can name collisions occur between

>CAs?  Or, better yet, under what conditions can we be sure name collisions 
>won't occur?  Let's start with user certificates.
>
>In general, each CA that issues user certificates does so for a 
>particular
>name space.  That is, all names assigned to users will be in a particular 
>Directory Information Tree (DIT).   The CA will either work with a naming 
>authority that it considers authoritative or may assume that function 
>itself.   For example, the NIST CA only issues user certificates in the 
>"C=US, O=U.S. Government, OU=NIST" DIT.   The NIST CA has been designated 
>as our naming authority as well, so it keeps track of the names it 
>assigns.  Similarly, the CA that supports NASA only issues certificates for

>the name space "C=US,  O=U.S. Government, OU=NASA" DIT.
>
>These name spaces are disjoint, so name collisions cannot occur 
>involving
>user certificates generated by the NASA and NIST CAs.  In fact, consider a 
>PKI with trust anchor T and CAs C(1), C(2), ., C(n) issuing for name spaces

>P(1), P(2), ., P(n).  If spaces P(1), P(2), ., P(n) are pairwise disjoint, 
>name collisions cannot occur involving user certificates generated by C(1),

>C(2), ., C(n).
>
>Case 1:  Consider a PKI with trust anchor T, and CAs C1, C2, and C3.  
>C1,
>C2, and C3 issue end user certificates in the DITs N1, N2, and N3 
>respectively.  If N1, N2, and N3 are pairwise disjoint, then the user names

>are unambiguous with respect to T.
>
>In more complex PKIs, we may encounter situations where CAs issue user
>certificates for name spaces that overlap.  For example, in the U.S DoD's 
>hierarchical PKI, CAs all issue certificates in the DIT "C=US, O=U.S. 
>Government, OU=DOD".  Users routinely receive three certificates from two 
>different CAs, so all the DoD CAs rely on a common naming authority to 
>ensure that certificates with the same DNs are issued to the same person.
>
>Case 2: Consider a PKI with trust anchor T, and CAs C1, C2, and C3.  
>C1,
>C2, and C3 issue end user certificates in the DITs N1, N2, and N3 
>respectively.  N1 and N2 overlap, but N3 is disjoint from N1 and N2.   If 
>CA1 and CA2 recognize the same naming authority, then the user names in the

>PKI are unambiguous with respect to T.
>
>That is, if all the CAs either: (1) issue certificates in disjoint name
>spaces, or (2) issue certificates in shared name spaces based on a common 
>naming authority, names will be unambiguous!
>
>Of course, CAs may issue CA certificates as well.  In this case, the CA
>does not assign the names, but rather uses the established name.  This is 
>trickier, since the name spaces for CA certificates overlaps but no naming 
>authority exists.  It is still the responsibility of each CA to ensure that

>there are no name collisions in CA certificates it issues!  This is not 
>generally a problem, since we require names to be meaningful.  A CA should 
>never issue a certificate to a CA with the DN "C=US, O=Coca Cola" unless 
>the subject CA is associated with that company.  Similarly, if a CA issues 
>certificates in the DIT "C=US, O=Coca Cola" then it must be associated with

>the company!
>
>Of course, a rogue CA may masquerade under the wrong name, or issue
>certificates in a DIT it clearly has no right to use, but no decent CA will

>cross certify with it.  Since we are interested in ambiguity with respect 
>to a trust anchor, the behavior of a rogue CA is irrelevant.  Without cross

>certification, no paths involving the rogue CA can be constructed.  (Note 
>that users installing the rogue as a trust anchor is out of scope here!)
>
>However, authority for a name space is not always crystal clear.  
>Without a
>central naming authority, there is no clear title for a particular DIT.  We

>rely on heuristics that work nicely for large entities like Coca-Cola but 
>may fail for smaller organizations.  For example, there may be a number of 
>companies with variants on a particular name.  If the name space assumed by

>an organization asserts "Orion" rather than "Orion Security" or "Orion 
>Space Sciences", the name may be ambiguous without being blatantly 
>false.  Each entity could reasonably assign user names in the "C=US, 
>O=Orion" DIT.   If each organization established their CA with the name 
>"C=US, O=Orion, CN=CA1" things could get really ugly.
>
>A trust anchor T may cross certify with two different CAs - say the 
>ones
>from NIST and NASA.  Each of those CAs may have a relationship with an 
>"Orion".  If each of them cross certifies with the Orion they know and 
>love, we have an immediate name collision for a CA named "C=US, O=Orion, 
>CN=CA1", and potentially name collisions for "C=US, O=Orion, CN=John 
>Wilson", etc., etc.  Each CA has played by the rules, but names have just 
>become ambiguous with respect to T.  This might be avoided if T is involved

>in the policy decisions leading up to cross certification - but that is 
>often NOT the case.
>
>Fortunately, we need not depend on policy alone.   Beyond the 
>procedural/policy issues, there are some important mechanisms that help 
>us
>with name space control.  Most significant are path length constraints and 
>name constraints.  When trust anchor T issued those CA certificates, it 
>probably wasn't expecting to accept transitive trust from those CAs, and it

>certainly didn't expect to accept the NIST or NASA CA as authoritative for 
>the "C=US, O=Orion" DIT.
>
>I listed path length constraints first because this mechanism provides 
>the
>simplest and most widely available of our technical controls. Both NASA and

>NIST use a single CA, rather than a mesh or hierarchy.  If the trust anchor

>does not wish to leverage other cross certifications performed by NASA or 
>NIST, it simply asserts a path length constraint of zero!  If T asserted 
>this constraint for at least one of the NIST or NASA CAs, then the name 
>"C=US, O=Orion, CN=John Wilson" is unambiguous. While this control was not 
>designed exclusively for name space control, it does have the effect of 
>prevenmting subsequent CAs from introducing unexpected name spaces.
>
>Unfortunately, this does not solve our problem for "C=US, O=Orion, 
>CN=CA1".   This name remains ambiguous.  Even with a path length 
>constraints of zero, a relying party can validate a CRL from either 
>Orion CA.
>
>Name constraints is a more appealing technical mechanism, if less
>consistently available.  T can explicitly designate the name spaces it 
>wishes to recognize in the cross certificate issued to NIST (or NASA).  By 
>asserting a permitted subtree of "C=US, O=U.S. Government, OU=NIST" with a 
>SkipCerts of zero, certificates in the Orion name space are immediately 
>eliminated.  This includes the offending CA certificate, so the "wrong" CRL

>no longer validates.
>
>Case 3: Consider a PKI with trust anchor T, and CAs C1, C2, and C3.  
>C1,
>C2, and C3 issue end user certificates in the DITs N1, N2, and N3
respectively.
>
>N1 and N2 are disjoint, but  N3 overlaps with N1 or N2.  C3 does not 
>recognize the same naming authority as C1 or C2.   If name constraints 
>permitted subtrees P3 is imposed in all cross certificates issued to 
>C3,
>where N1, N2, and P3 are pairwise disjoint, then names are unambiguous with

>respect to T.  (Names that could have collided are excluded from C3's DIT.)
>
>Conclusion/Proposal
>
>Ambiguity in names is a relatively minor risk with respect to a given 
>trust
>anchor.  Ambiguity does not occur because of the actions of a single CA; 
>rather it requires a combination of actions by different CAs within the 
>infrastructure.  If all CA certificates accurately reflect the trust 
>relationships between the CAs by incorporating appropriate path length and 
>name constraints, these risks are greatly reduced if not eliminated.
>
>The risk of ambiguous names can be mitigated with a relatively simple
>modification in 3280bis, and the addition of some security 
>considerations.  Most importantly, 32890bis should be modified to ensure 
>that certificate and CRL validation are always performed with respect to 
>the same trust anchor.  Security considerations should be added to 
>highlight the risk of issuing CA certificates without appropriate 
>constraints, and to caution application developers that trust anchor 
>information should be considered when accepting certificates.
>
>The changes that I believe should be implemented are as follows:
>
>  (1) Modify section 6.3.3 to state that CRL validation MUST use the 
>same
>trust anchor T specified in the corresponding certification path.
>
>(2) Add security considerations that indicate applications that accept
>multiple trust anchors should consider the trust anchor in access control 
>decisions to ensure that names are unambiguous.
>
>(3) Add security considerations that explain the importance of 
>consistent
>use of path length and name constraints in preventing name ambiguity.
>
>

Regards,

Denis Pinkas

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 j6IDbbJC089497; Mon, 18 Jul 2005 06:37: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 j6IDbbZP089496; Mon, 18 Jul 2005 06:37:37 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from IP0fCard1 (host2.ewrrn.hyatthsia.com [12.161.245.2] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6IDbbRh089484 for <ietf-pkix@imc.org>; Mon, 18 Jul 2005 06:37:37 -0700 (PDT) (envelope-from chokhani@orionsec.com)
Received: from wchokhani3 (globalsuite.gtcorp.com [127.0.0.1]) by IP0fCard1 (8.11.6/8.11.6) with ESMTP id j6IDbPB01864 for <ietf-pkix@imc.org>; Mon, 18 Jul 2005 09:37:26 -0400
From: "Santosh Chokhani" <chokhani@orionsec.com>
To: "'pkix'" <ietf-pkix@imc.org>
Subject: RE: Correction to be done to <draft-pinkas-pkix-conf-crl-validation-01.txt>
Date: Mon, 18 Jul 2005 09:37:32 -0400
Message-ID: <008d01c58b9d$da17b400$cbb011ac@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.2900.2180
In-Reply-To: <OF5192C628.37FF80EA-ONC1257042.0031E272@frcl.bull.fr>
Importance: Normal
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j6IDbbRh089490
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <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,

The specific sentence in 3280 may need to be revised or may have been taken
out of context.

A CRL issuer asserts indirect CRL flag when the CRL is supposed to cover
certificates not issued by the CRL issuer.  Note that there may not be any
entries for other CAs since none of their certificates may be revoked.

But, the CRL issuer can cover the certificates issued by the CRL issuer (if
it is a CA) in that indirect CRL.

The State Machine is correct.

-----Original Message-----
From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On
Behalf Of Denis Pinkas
Sent: Monday, July 18, 2005 6:05 AM
To: 'pkix'; Santosh Chokhani
Subject: Re: Correction to be done to
<draft-pinkas-pkix-conf-crl-validation-01.txt>

Santosh,

>My apologies to the list for typo.
>
>In the last paragraph, "CRL issuer" was meant to say "certificate 
>issuer". It is corrected below.
>
>-----Original Message-----
>From: Santosh Chokhani [mailto:chokhani@orionsec.com]
>Sent: Friday, July 15, 2005 1:09 PM
>To: 'pkix'
>Subject: RE: Correction to be done to
><draft-pinkas-pkix-conf-crl-validation-01.txt>

>Denis,

>The indirect CRL state machine is as follows:

>	initial value of certificate_issuer_state = issuer field in the CRL
>(1)

The current sentence of RFC 3280 is : "Whenever the CRL issuer is not the CA

that issued the certificates, the CRL is referred to as an indirect CRL".

This means that when a CRL is an indirect CRL, then none of the certificates

that are present in the CRL can be issued under the name that is present 
in the issuer name of the CRL.

So unless the definition of an indirect CRL is modified, the certificate
issuer name
cannot default to the issuer name of the CRL.

So the "state machine" you propose is not correct.

Stefan said:

"Finally I do not worry too much about deployed products concerning
indirect CRLs since this is an almost non used feature as far as I know."

It is time to fix the issue so that cases where the various cases where CA 
is not the issuer of the CRL can be undertsood and implemented.

Some are simpler than others.

Your message triggered another look to my I-D on that topic and I noticed 
that a case was forgotten in <draft-pinkas-pkix-conf-crl-validation-02.txt>
:
a CRL could contain the same serial number, but from different CAs.

This is now handled in <draft-pinkas-pkix-conf-crl-validation-02.txt> 
that has been posted before the dead line for submissions, but is 
not yet available.

Denis

>	certificate_issuer  = value in the CRL entry extension and if the
>extension is absent, certificate_issuer = certificate_issuer_state (2)
>
>	certificate_issuer_state = certificate_issuer
>
>It is secure, standard compliant and provides for interoperability.  It is
>probably too complex in comparison to doing nothing and yet to be defined
>Denis's algorithms on a variety of CRL processing matters.
>
>If the indirect CRL issuer is not a CA, the first revoked certificate entry
>will contain a certificate issuer field.  There are numerous other
>situations when first revoked certificate entry will contain a certificate
>issuer field, but this is of no interest to a relying party that wants to
>write a secure, interoperable, simple (i.e., not complex) CRL processing
>logic.
>
>-----Original Message-----
>From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On
>Behalf Of Denis Pinkas
>Sent: Friday, July 15, 2005 4:24 AM
>To: pkix
>Subject: Correction to be done to
><draft-pinkas-pkix-conf-crl-validation-01.txt>
>
>
>
>
>A correction needs to be done to 
><draft-pinkas-pkix-conf-crl-validation-01.txt>.
>
>As explained in a previous e-mail, the certificate issuer name cannot
>default to the name of the CRL issuer, hence the following text 
>extracted from section 6.3.3.3 is incorrect :
>
>        (ii) check if there exists a previous CRL entry
>             and if that CRL entry contains a Certificate
>             Issuer CRL entry extension and go back to (1).
>
>                If there is no previous CRL entry, then
>                check if the name of the issuer of the CRL
>                matches the name of the issuer field of the
>                target certificate.
>
>                 - If it does, then set the cert_revoc_status
>                   variable to REVOKED and if the CRL entry
>                   extension " reasonCode " is present in
>                   that CRL entry, then set the revoc_reason
>                   variable to the value contained in that CRL
>                   entry extension and the algorithm
>                   terminates.
>
>                 - If it does, then set the cert_revoc_status
>                   variable to NOT_REVOKED and the algorithm
>                   terminates.
>
>It would need to be corrected (and greatly simplified)
>in the following way:
>
>          (ii) If there is no previous CRL entry, then
>               this is an error in the structure of the CRL
>               and the algorithm terminates.
>
>               Otherwise, check if that CRL entry contains
>               a Certificate Issuer CRL entry extension and
>               go back to (1).
>
>Denis
>
>
>
>
>

Regards,

Denis Pinkas

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 j6ICdoih067218; Mon, 18 Jul 2005 05:39: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 j6ICdod2067215; Mon, 18 Jul 2005 05:39:50 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from smtp004.bizmail.sc5.yahoo.com (smtp004.bizmail.sc5.yahoo.com [66.163.175.81]) by above.proper.com (8.12.11/8.12.9) with SMTP id j6ICdnC4067198 for <ietf-pkix@imc.org>; Mon, 18 Jul 2005 05:39:49 -0700 (PDT) (envelope-from turners@ieca.com)
Message-Id: <200507181239.j6ICdnC4067198@above.proper.com>
Received: (qmail 83123 invoked from network); 18 Jul 2005 12:39:49 -0000
Received: from unknown (HELO Wylie) (turners@ieca.com@70.18.233.116 with login) by smtp004.bizmail.sc5.yahoo.com with SMTP; 18 Jul 2005 12:39:49 -0000
Reply-To: <turners@ieca.com>
From: "Turner, Sean P." <turners@ieca.com>
To: "'S-MIME / IETF'" <ietf-smime@imc.org>
Cc: "'pkix'" <ietf-pkix@imc.org>
Subject: RE: CMS Advanced Electronic Signatures (CAdES)
Date: Mon, 18 Jul 2005 08:39:18 -0400
Organization: IECA, Inc.
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
In-Reply-To: <42D514F9.8050700@bull.net>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Thread-Index: AcWHsoxvFYIa8xWKTwqMMwN0VjnlrgD4vCgg
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <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 question at hand is someone in the working group willing to review this
ID?

spt

-----Original Message-----
From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On
Behalf Of Denis Pinkas
Sent: Wednesday, July 13, 2005 9:20 AM
To: S-MIME / IETF
Cc: pkix
Subject: CMS Advanced Electronic Signatures (CAdES)

To the S-MIME list,

Copy: the PKIX list.

RFC 3126 has been issued in September 2001 and its title is:

"Electronic Signature Format for long term electronic signatures"

The contents of this Informational RFC is technically equivalent to ETSI TS
101 733 V.1.2.2.

In the mean time, ETSI TC ESI has revised this Technical Standard (TS) and
is going to publish a new version of it with a new title :

CMS Advanced Electronic Signatures (CAdES), in order to be the "brother" of
XML Advanced Electronic Signatures (XAdES), published as ETSI TS 101 903.

In order to make this document widely available, ETSI has produced an
equivalent of the revised TS using the format of a RFC.

This document is temporarily available (by a kind hosting from Paul Offman)
from:

<http://www.imc.org/ietf-smime/TEMP-draft-pinkas-smime-cades-00.txt>

until is is officially posted in the IETF repository.

The major changes are mentioned section  J :

   "The title of the document has changed to be aligned with the title
   of XAdES, the vocabulary used within the present document has been
   aligned with the vocabulary used in XAdES,

   In the previous version of TS 101 733 (i.e. version 1.5.1)
   sigPolicyHash was mandatory.  Implementations requiring to be
   backward compatible with version 1.5.1 and previous versions
   of the current document MUST include SigPolicyHash.

   The OIDs from the ASN.1 modules have changed for the following
   reasons:

    - the OIDs of the ASN.1 modules of RFC 2560 and RFC 3161 have been
      included.

    - since RFC 2459 and RFC 3369 has been obsoleted by RFC 3280 and
      RFC 3852 respectively, there was the need to refer to the OIDs
      of the ASN.1 modules of RFC 3280 and RFC 3852, instead of the
      OIDs of the ASN.1 modules of RFC 2459 and RFC 3369.

    - the other change is related to the field sigPolicyHash from
      SignaturePolicyId (see clause 5.8.1). That field was mandatory
      and is now optional."

It is proposed to progress this document within the S-MIME WG as an
Informational Standard.

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 j6I941nt089053; Mon, 18 Jul 2005 02:04: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 j6I941qY089052; Mon, 18 Jul 2005 02:04:01 -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 j6I93x65089014 for <ietf-pkix@imc.org>; Mon, 18 Jul 2005 02:04:00 -0700 (PDT) (envelope-from denis.pinkas@bull.net)
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id LAA09860; Mon, 18 Jul 2005 11:19:51 +0200
Received: from frcls4013 ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with SMTP id 2005071811045233:1021 ; Mon, 18 Jul 2005 11:04:52 +0200 
Date: Mon, 18 Jul 2005 11:05:08 +0100
From: "Denis Pinkas" <denis.pinkas@bull.net>
To: "'pkix'" <ietf-pkix@imc.org>, "Santosh Chokhani" <chokhani@orionsec.com>
Subject: Re: Correction to be done to <draft-pinkas-pkix-conf-crl-validation-01.txt>
X-mailer: Foxmail 5.0 [-fr-]
Mime-Version: 1.0
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 18/07/2005 11:04:52, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 18/07/2005 11:04:55, Serialize complete at 18/07/2005 11:04:55
Message-ID: <OF5192C628.37FF80EA-ONC1257042.0031E272@frcl.bull.fr>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by above.proper.com id j6I94165089044
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <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,

>My apologies to the list for typo.
>
>In the last paragraph, "CRL issuer" was meant to say "certificate issuer".
>It is corrected below.
>
>-----Original Message-----
>From: Santosh Chokhani [mailto:chokhani@orionsec.com] 
>Sent: Friday, July 15, 2005 1:09 PM
>To: 'pkix'
>Subject: RE: Correction to be done to
><draft-pinkas-pkix-conf-crl-validation-01.txt>

>Denis,

>The indirect CRL state machine is as follows:

>	initial value of certificate_issuer_state = issuer field in the CRL
>(1)

The current sentence of RFC 3280 is : Whenever the CRL issuer is not the CA 
that issued the certificates, the CRL is referred to as an indirect CRL.

This means that when a CRL is an indirect CRL, then none of the certificates 
that are present in the CRL can be issued under the name that is present 
in the issuer name of the CRL.

So unless the definition of an indirect CRL is modified, the certificate issuer name
cannot default to the issuer name of the CRL.

So the "state machine" you propose is not correct.

Stefan said:

"Finally I do not worry too much about deployed products concerning
indirect CRLs since this is an almost non used feature as far as I know."

It is time to fix the issue so that cases where the various cases where CA 
is not the issuer of the CRL can be undertsood and implemented.

Some are simpler than others.

Your message triggered another look to my I-D on that topic and I noticed 
that a case was forgotten in <draft-pinkas-pkix-conf-crl-validation-02.txt> :
a CRL could contain the same serial number, but from different CAs.

This is now handled in <draft-pinkas-pkix-conf-crl-validation-02.txt> 
that has been posted before the dead line for submissions, but is 
not yet available.

Denis

>	certificate_issuer  = value in the CRL entry extension and if the
>extension is absent, certificate_issuer = certificate_issuer_state (2)
>
>	certificate_issuer_state = certificate_issuer
>
>It is secure, standard compliant and provides for interoperability.  It is
>probably too complex in comparison to doing nothing and yet to be defined
>Denis's algorithms on a variety of CRL processing matters.
>
>If the indirect CRL issuer is not a CA, the first revoked certificate entry
>will contain a certificate issuer field.  There are numerous other
>situations when first revoked certificate entry will contain a certificate
>issuer field, but this is of no interest to a relying party that wants to
>write a secure, interoperable, simple (i.e., not complex) CRL processing
>logic.
>
>-----Original Message-----
>From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On
>Behalf Of Denis Pinkas
>Sent: Friday, July 15, 2005 4:24 AM
>To: pkix
>Subject: Correction to be done to
><draft-pinkas-pkix-conf-crl-validation-01.txt>
>
>
>
>
>A correction needs to be done to 
><draft-pinkas-pkix-conf-crl-validation-01.txt>.
>
>As explained in a previous e-mail, the certificate issuer name cannot
>default to the name of the CRL issuer, hence the following text 
>extracted from section 6.3.3.3 is incorrect :
>
>        (ii) check if there exists a previous CRL entry
>             and if that CRL entry contains a Certificate
>             Issuer CRL entry extension and go back to (1).
>
>                If there is no previous CRL entry, then
>                check if the name of the issuer of the CRL
>                matches the name of the issuer field of the
>                target certificate.
>
>                 - If it does, then set the cert_revoc_status
>                   variable to REVOKED and if the CRL entry
>                   extension " reasonCode " is present in
>                   that CRL entry, then set the revoc_reason
>                   variable to the value contained in that CRL
>                   entry extension and the algorithm
>                   terminates.
>
>                 - If it does, then set the cert_revoc_status
>                   variable to NOT_REVOKED and the algorithm
>                   terminates.
>
>It would need to be corrected (and greatly simplified)
>in the following way:
>
>          (ii) If there is no previous CRL entry, then
>               this is an error in the structure of the CRL
>               and the algorithm terminates.
>
>               Otherwise, check if that CRL entry contains
>               a Certificate Issuer CRL entry extension and
>               go back to (1).
>
>Denis
>
>
>
>
>

Regards,

Denis Pinkas

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 j6I8Eu9b070770; Mon, 18 Jul 2005 01:14: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 j6I8EuPE070769; Mon, 18 Jul 2005 01:14:56 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from pc-p1-informatica.net (69.Red-213-97-128.pooles.rima-tde.net [213.97.128.69]) by above.proper.com (8.12.11/8.12.9) with SMTP id j6I8EsZ5070714 for <ietf-pkix@imc.org>; Mon, 18 Jul 2005 01:14:55 -0700 (PDT) (envelope-from wpolk@nist.gov)
Date: Mon, 18 Jul 2005 09:13:59 +0000
To: "Ietf-pkix" <ietf-pkix@imc.org>
From: "Wpolk" <wpolk@nist.gov>
Subject: Re:
Message-ID: <wncdruodsamiizqayjr@imc.org>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="--------qqojvudmjiscefcwpatx"
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

----------qqojvudmjiscefcwpatx
Content-Type: text/plain; charset="UTF-8"; format="flowed"

+----------------------------------------------------+

Panda GateDefender has detected malicious content (Virus) in the following file: [MP3.cpl]
W32/Bagle.AH.worm

The file has been deleted to protect the network.
07/18/2005 08:07 +0100

www.pandasoftware.com

+----------------------------------------------------+

----------qqojvudmjiscefcwpatx
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: 7bit

<html><body>
>Lovely animals<br><br>

<br>
</body></html>

----------qqojvudmjiscefcwpatx--

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 j6I8C4lK069556; Mon, 18 Jul 2005 01:12: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 j6I8C4Zg069555; Mon, 18 Jul 2005 01:12:04 -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 j6I8C29X069521 for <ietf-pkix@imc.org>; Mon, 18 Jul 2005 01:12:03 -0700 (PDT) (envelope-from denis.pinkas@bull.net)
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id KAA51498; Mon, 18 Jul 2005 10:27:50 +0200
Received: from frcls4013 ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with SMTP id 2005071810125386:989 ; Mon, 18 Jul 2005 10:12:53 +0200 
Date: Mon, 18 Jul 2005 10:13:10 +0100
From: "Denis Pinkas" <denis.pinkas@bull.net>
To: "Tim Polk" <tim.polk@nist.gov>, "ietf-pkix@imc.org" <ietf-pkix@imc.org>
Subject: Re: How ambiguous are names in actuality?
X-mailer: Foxmail 5.0 [-fr-]
Mime-Version: 1.0
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 18/07/2005 10:12:53, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 18/07/2005 10:12:55, Serialize complete at 18/07/2005 10:12:55
Message-ID: <OFE12E6CDC.2B167B87-ONC1257042.002D204F@frcl.bull.fr>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by above.proper.com id j6I8C49X069547
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

Tim,

My views are quite different. You are looking for a solution to MITIGATE the risk, 
whereas there exists a solution to SUPPRESS the risk, as it is explained below. 
The changes you propose, like same trust anchor, do not suppress the risk. 

You mention that the problem of name collisions exists both for two leaf certificates 
and for CRL certificates. This is correct. While the problem for CRL certificates arises 
only *during* the path verification algorithm, this is not the case for leaf certificates.

For a leaf certificate that has been verified to be valid, the output of the algorithm 
is a sequence of certificates up to a given trust anchor. The major issue is what 
to do with it, and this is NOT mentioned within RFC 3280.

Leaf certificates may be used in two contexts:

   a) access control or end-entity authentication,
   b) non repudiation.

These two cases are different and are explored below.

ACCESS CONTROL OR END-ENTITY AUTHENTICATION

There are two phases when a public key certificate is used for an access control service : 

- Phase 1 : the owner of the protected object must fill-in the ACL correctly,
- Phase 2 : during an access, the sequence of certificates that has been validated 
                must be checked against the content of the ACL.

The real issue is that nowhere in RFC 3280 it is said what the content of the ACL should be. 
Because of this lack of information, some implementations of relying party software 
may be subject to problems related to name collisions, while some others will not. 

There is no clear indication in RFC 3280 to tell how the owner of the protected object 
will make sure that it is pointing to the right certificate BEFORE using that certificate 
for access control purposes. 

The point is that the owner of the protected object SHALL enter the full certification path 
in the ACL. If it does not have the full path, then it SHALL construct it according to 
the validation policy that is appropriate for his application and SHOULD make sure 
that it is not revoked. It will thus use the full certification path and may check either 
automatically using some local rules or may check using his brain that the full certification 
path is correct.

Note that if the ACL would only contain the DN of the leaf certificate, then the access control 
mechanism would be subject to name collisions,

When the ACL contains both the DN of the leaf certificate and all the DNs from the upper CA 
up to a trust anchor identified by its DN (i.e. the DN of the trust anchor is also taken, 
since there may be more than one trust anchor in a given validation policy), then the 
access control mechanism can never be subject to name collisions.

Since a validation policy may include more than one trust anchor, it means that it 
SHALL not be allowed to define a validation policy that uses two trust anchors with the same DN.

This means that during phase 1, the owner of the protected object must fill-in the ACL 
with all the DNs from the certification path, including the DN from the trust anchor 
(of course a hash of it may be used instead) and that during phase 2, the whole certification path 
must be used and compared with the content of the ACL.

This solution fully *suppresses* the risk in any case.

Of course, in some contexts, some shortcuts may be taken (e.g. when there exists a single 
trust anchor in the validation policy) or when it may be known that name collisions 
may never happen (e.g. because all the CAs apply a given naming policy) but this is not 
the general case. 

The solution explained above is also much simpler than adding name constrains 
that could be anyway defeated.

NON REPUDIATION

With non repudiation, only the whole sequence of DN extracted from the certification path 
is meaningful. A DN like CN= John William does not make sense unless at the same time 
all the upper DNs from the CAs are used or displayed. So if someone wants to know 
without any ambiguity who a signer is, it SHALL use of the sequence of DN up to 
a trust anchor of the signature policy. 

Since a signature policy may include more than one trust anchor, it means that it SHALL NOT 
be allowed to define a signature policy that uses two trust anchors with the same DN.

COLLISIONS BETWEEN CRL ISSUER NAMES

For CRLs, I have already mentioned the additional sentence that shall be added to RFC 3280.
It is copied again below  :

The full certification path that has been used to validate the target certificate MUST also be 
used to validate the CRL issuer certificate .

REPLY TO YOUR CONCLUSIONS

As a reply to your conclusions: using path length constrains does not solve the issue. 
Adding other constrains does not solve the issue either. Using name constraints would 
introduce an order of magnitude of complexity and would not be effective in the general case. 
Using certification policies and path length constrains might help, but still do not solve 
the problem in the general case.

Denis

>Ambiguity has recently become a hot topic on this list.  This is a really 
>complicated issue, and I have personally had a great deal of trouble 
>sorting out the real level of risk.  Some of the proposed changes would 
>greatly impact current software, and these changes should only be 
>contemplated if the risk is merits such change.
>
>So, I have spent a lot of time, off and on, thinking about ambiguity.  I 
>can't claim to have sorted it all out, but I have convinced myself that one 
>minor change is absolutely required, and that the current suite of 
>mechanisms can virtually eliminate ambiguity in real PKIs.
>
>My thinking is appended to this message;  I apologize for its length, but 
>to paraphrase Mark Twain, I simply don't have time to make this short and 
>concise.  I have attempted to define ambiguity, characterize the ways 
>ambiguity can enter into a PKI, and describe the set of mechanisms that 
>mitigate this risk.
>
>Thanks,
>
>Tim Polk
>
>--------------------------------------------------------------------------------------------------------------------------------
>
>              How ambiguous are names in actuality, and how important is it?
>
>I believe that X.509 expected assignment of unambiguous names based on a 
>hierarchical system of naming authorities.  Whether you agree with that 
>premise, it is safe to say that the global X.500 directory and its 
>corresponding system of naming authorities do not exist. So, it may not be 
>safe to assume that there are no name collisions whatsoever in all the DNs 
>that appear in certificates and CRLs!  I am sure such collisions exist 
>somewhere (although I havent encountered any examples).  The real question 
>here is What security risk does this situation present, and are the 
>current mechanisms adequate to address this risk?
>
>Lets recognize that the goal for PKIX is not to have globally unambiguous 
>names, but to be able to obtain a trustworthy public key to establish a 
>security service. Ambiguity in names is a problem when it causes the 
>relying party to trust the wrong public key.
>
>There are two ways ambiguous names could cause problems.  First, I could 
>accept public keys from two certificates as representing the same person 
>based on the same subject name.  If these two certificates are bound to 
>different individuals I may provide a service to the wrong party (or 
>disclose confidential data, etc., etc.)  Second, I could accept a CRL to 
>validate a particular certificate, based on the same issuer name in the 
>certificate and CRL.  If the certificate and CRL were not actually issued 
>by the same CA, then the relying party may obtain incorrect certificate status.
>
>Note that both of these problems are in the context of path validation.  If 
>a name collision exists, but only one of the objects (e.g., certificate or 
>CRL) validates for a given relying party, then there is no actual ambiguity 
>from that relying partys point of view.
>
>That is, assume two certificates exist with the same subject name but are 
>bound to different people.  If Alice can only validate one of those 
>certificates, there is no ambiguity in Alices world.   Similarly, if Bob 
>can only validate one of those certificates, there is no ambiguity in Bobs 
>world.   (It does not matter if Bob and Alice are validating the same 
>certificate, or different ones!)   Similarly, if two CAs have the same 
>issuer name, but Alice can only validate one, she cant accept the wrong 
>CRL.  Ditto for Bob.
>
>So, ambiguity is a concern only in the context of path validation for a 
>given relying party. This means that the mechanisms that are employed in 
>path validation are relevant to when names are, and are not, ambiguous. Id 
>also like to point out that path validation is always performed in the 
>context of a particular trust anchor.  (A relying party may accept paths 
>that begin with multiple trust anchors, but each specific path has a single 
>trust anchor.)  Seems irrelevant at the moment, but I will get back to it!
>
>Definition 1:  a Name N is unambiguous for a trust anchor T if and only if 
>all certificates that validate for T and have the subject N refer to the 
>same entity.
>
>Now, lets think about where name collisions can occur in the first place. 
>There seems to be consensus that a single CA will not issue two 
>certificates to two different entities with the same subject name.  So, if 
>a single CA issues two certificates to O=Microsoft, cn=John Wilson they 
>better relate to the same guy.  Similarly if a particular CA issues two 
>certificates to c=US, O=U.S. Government, OU=NIST, CN=CA1 then the subject 
>of both certificates must be the same CA.
>
>So, we are only worried about the case where two different CAs are trusted 
>with respect to a trust anchor T and issue certificates to different 
>subjects but use the same name.  So, when can name collisions occur between 
>CAs?  Or, better yet, under what conditions can we be sure name collisions 
>wont occur?  Lets start with user certificates.
>
>In general, each CA that issues user certificates does so for a particular 
>name space.  That is, all names assigned to users will be in a particular 
>Directory Information Tree (DIT).   The CA will either work with a naming 
>authority that it considers authoritative or may assume that function 
>itself.   For example, the NIST CA only issues user certificates in the 
>C=US, O=U.S. Government, OU=NIST DIT.   The NIST CA has been designated 
>as our naming authority as well, so it keeps track of the names it 
>assigns.  Similarly, the CA that supports NASA only issues certificates for 
>the name space C=US,  O=U.S. Government, OU=NASA DIT.
>
>These name spaces are disjoint, so name collisions cannot occur involving 
>user certificates generated by the NASA and NIST CAs.  In fact, consider a 
>PKI with trust anchor T and CAs C(1), C(2), , C(n) issuing for name spaces 
>P(1), P(2), , P(n).  If spaces P(1), P(2), , P(n) are pairwise disjoint, 
>name collisions cannot occur involving user certificates generated by C(1), 
>C(2), , C(n).
>
>Case 1:  Consider a PKI with trust anchor T, and CAs C1, C2, and C3.  C1, 
>C2, and C3 issue end user certificates in the DITs N1, N2, and N3 
>respectively.  If N1, N2, and N3 are pairwise disjoint, then the user names 
>are unambiguous with respect to T.
>
>In more complex PKIs, we may encounter situations where CAs issue user 
>certificates for name spaces that overlap.  For example, in the U.S DoDs 
>hierarchical PKI, CAs all issue certificates in the DIT C=US, O=U.S. 
>Government, OU=DOD.  Users routinely receive three certificates from two 
>different CAs, so all the DoD CAs rely on a common naming authority to 
>ensure that certificates with the same DNs are issued to the same person.
>
>Case 2: Consider a PKI with trust anchor T, and CAs C1, C2, and C3.  C1, 
>C2, and C3 issue end user certificates in the DITs N1, N2, and N3 
>respectively.  N1 and N2 overlap, but N3 is disjoint from N1 and N2.   If 
>CA1 and CA2 recognize the same naming authority, then the user names in the 
>PKI are unambiguous with respect to T.
>
>That is, if all the CAs either: (1) issue certificates in disjoint name 
>spaces, or (2) issue certificates in shared name spaces based on a common 
>naming authority, names will be unambiguous!
>
>Of course, CAs may issue CA certificates as well.  In this case, the CA 
>does not assign the names, but rather uses the established name.  This is 
>trickier, since the name spaces for CA certificates overlaps but no naming 
>authority exists.  It is still the responsibility of each CA to ensure that 
>there are no name collisions in CA certificates it issues!  This is not 
>generally a problem, since we require names to be meaningful.  A CA should 
>never issue a certificate to a CA with the DN C=US, O=Coca Cola unless 
>the subject CA is associated with that company.  Similarly, if a CA issues 
>certificates in the DIT C=US, O=Coca Cola then it must be associated with 
>the company!
>
>Of course, a rogue CA may masquerade under the wrong name, or issue 
>certificates in a DIT it clearly has no right to use, but no decent CA will 
>cross certify with it.  Since we are interested in ambiguity with respect 
>to a trust anchor, the behavior of a rogue CA is irrelevant.  Without cross 
>certification, no paths involving the rogue CA can be constructed.  (Note 
>that users installing the rogue as a trust anchor is out of scope here!)
>
>However, authority for a name space is not always crystal clear.  Without a 
>central naming authority, there is no clear title for a particular DIT.  We 
>rely on heuristics that work nicely for large entities like Coca-Cola but 
>may fail for smaller organizations.  For example, there may be a number of 
>companies with variants on a particular name.  If the name space assumed by 
>an organization asserts Orion rather than Orion Security or Orion 
>Space Sciences, the name may be ambiguous without being blatantly 
>false.  Each entity could reasonably assign user names in the C=US, 
>O=Orion DIT.   If each organization established their CA with the name 
>C=US, O=Orion, CN=CA1 things could get really ugly.
>
>A trust anchor T may cross certify with two different CAs  say the ones 
>from NIST and NASA.  Each of those CAs may have a relationship with an 
>Orion.  If each of them cross certifies with the Orion they know and 
>love, we have an immediate name collision for a CA named C=US, O=Orion, 
>CN=CA1, and potentially name collisions for C=US, O=Orion, CN=John 
>Wilson, etc., etc.  Each CA has played by the rules, but names have just 
>become ambiguous with respect to T.  This might be avoided if T is involved 
>in the policy decisions leading up to cross certification  but that is 
>often NOT the case.
>
>Fortunately, we need not depend on policy alone.   Beyond the 
>procedural/policy issues, there are some important mechanisms that help us 
>with name space control.  Most significant are path length constraints and 
>name constraints.  When trust anchor T issued those CA certificates, it 
>probably wasnt expecting to accept transitive trust from those CAs, and it 
>certainly didnt expect to accept the NIST or NASA CA as authoritative for 
>the C=US, O=Orion DIT.
>
>I listed path length constraints first because this mechanism provides the 
>simplest and most widely available of our technical controls. Both NASA and 
>NIST use a single CA, rather than a mesh or hierarchy.  If the trust anchor 
>does not wish to leverage other cross certifications performed by NASA or 
>NIST, it simply asserts a path length constraint of zero!  If T asserted 
>this constraint for at least one of the NIST or NASA CAs, then the name 
>C=US, O=Orion, CN=John Wilson is unambiguous. While this control was not 
>designed exclusively for name space control, it does have the effect of 
>prevenmting subsequent CAs from introducing unexpected name spaces.
>
>Unfortunately, this does not solve our problem for C=US, O=Orion, 
>CN=CA1.   This name remains ambiguous.  Even with a path length 
>constraints of zero, a relying party can validate a CRL from either Orion CA.
>
>Name constraints is a more appealing technical mechanism, if less 
>consistently available.  T can explicitly designate the name spaces it 
>wishes to recognize in the cross certificate issued to NIST (or NASA).  By 
>asserting a permitted subtree of C=US, O=U.S. Government, OU=NIST with a 
>SkipCerts of zero, certificates in the Orion name space are immediately 
>eliminated.  This includes the offending CA certificate, so the wrong CRL 
>no longer validates.
>
>Case 3: Consider a PKI with trust anchor T, and CAs C1, C2, and C3.  C1, 
>C2, and C3 issue end user certificates in the DITs N1, N2, and N3 respectively.
>
>N1 and N2 are disjoint, but  N3 overlaps with N1 or N2.  C3 does not 
>recognize the same naming authority as C1 or C2.   If name constraints 
>permitted subtrees P3 is imposed in all cross certificates issued to C3, 
>where N1, N2, and P3 are pairwise disjoint, then names are unambiguous with 
>respect to T.  (Names that could have collided are excluded from C3s DIT.)
>
>Conclusion/Proposal
>
>Ambiguity in names is a relatively minor risk with respect to a given trust 
>anchor.  Ambiguity does not occur because of the actions of a single CA; 
>rather it requires a combination of actions by different CAs within the 
>infrastructure.  If all CA certificates accurately reflect the trust 
>relationships between the CAs by incorporating appropriate path length and 
>name constraints, these risks are greatly reduced if not eliminated.
>
>The risk of ambiguous names can be mitigated with a relatively simple 
>modification in 3280bis, and the addition of some security 
>considerations.  Most importantly, 32890bis should be modified to ensure 
>that certificate and CRL validation are always performed with respect to 
>the same trust anchor.  Security considerations should be added to 
>highlight the risk of issuing CA certificates without appropriate 
>constraints, and to caution application developers that trust anchor 
>information should be considered when accepting certificates.
>
>The changes that I believe should be implemented are as follows:
>
>  (1) Modify section 6.3.3 to state that CRL validation MUST use the same 
>trust anchor T specified in the corresponding certification path.
>
>(2) Add security considerations that indicate applications that accept 
>multiple trust anchors should consider the trust anchor in access control 
>decisions to ensure that names are unambiguous.
>
>(3) Add security considerations that explain the importance of consistent 
>use of path length and name constraints in preventing name ambiguity.
>
>

Regards,

Denis Pinkas

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 j6HNvmnC054423; Sun, 17 Jul 2005 16:57: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 j6HNvmtP054422; Sun, 17 Jul 2005 16:57:48 -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.9) with ESMTP id j6HNvmEX054407 for <ietf-pkix@imc.org>; Sun, 17 Jul 2005 16:57:48 -0700 (PDT) (envelope-from ambarish@malpani.biz)
Received: from ambhome ([192.168.25.128]) by ns.malpani.biz (8.12.11/8.12.9) with ESMTP id j6HNvbvZ023037; Sun, 17 Jul 2005 16:57:41 -0700
Message-Id: <200507172357.j6HNvbvZ023037@ns.malpani.biz>
From: "Ambarish Malpani" <ambarish@malpani.biz>
To: "'Mouna Skouri'" <mskouri@yahoo.fr>, <ietf-pkix@imc.org>
Subject: RE: SCVP implementation
Date: Sun, 17 Jul 2005 16:57:33 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0047_01C58AF0.A406CB60"
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Thread-Index: AcWJkD/i5PqccJisSi+bStETqcRJzgBmoytQ
In-Reply-To: <20050715221044.87864.qmail@web26601.mail.ukl.yahoo.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>

This is a multi-part message in MIME format.

------=_NextPart_000_0047_01C58AF0.A406CB60
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

=20

Hi Mouna,

    I belive Tumbleweed and CoreStreet have implementations. There is =
also a
possibility that

Asertia does (I am not sure).

=20

None of the implementations are open source AFAIK.

=20

Regards,

Ambarish

=20

  _____ =20

From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] =
On
Behalf Of Mouna Skouri
Sent: Friday, July 15, 2005 3:11 PM
To: ietf-pkix@imc.org
Subject: SCVP implementation

=20

Hi,

=20

Does anyone know if there is any implementation of SCVP?

Thanks,
Mouna

  _____ =20

Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! =
Messenger
T=E9l=E9chargez
<http://us.rd.yahoo.com/messenger/mail_taglines/default/*http:/fr.messeng=
er.
yahoo.com> le ici !=20

------=_NextPart_000_0047_01C58AF0.A406CB60
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<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:0in;
	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
	{mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman";}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
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'><o:p>&nbsp;</o:p></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'>Hi =
Mouna,<o:p></o:p></span></font></p>

=A0=A0=A0 I belive Tumbleweed and =
CoreStreet
have implementations. There is also a possibility =
that<o:p></o:p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Asertia does (I am not =
sure).<o:p></o:p></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'><o:p>&nbsp;</o:p></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'>None of the implementations are =
open
source AFAIK.<o:p></o:p></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'><o:p>&nbsp;</o:p></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'>Regards,<o:p></o:p></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'>Ambarish<o:p></o:p></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'><o:p>&nbsp;</o:p></span></font></p>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in =
0in 4.0pt'>

<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>Mouna Skouri<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Friday, July 15, =
2005 3:11
PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> ietf-pkix@imc.org<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> SCVP =
implementation</span></font><o:p></o:p></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>Hi,<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>Does anyone know if there is&nbsp;any implementation of =
SCVP?<br>
<br>
Thanks,<br>
Mouna<o:p></o:p></span></font></p>

</div>

</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=3D1 width=3D"100%" align=3Dcenter>

</span></font></div>

Appel audio =
GRATUIT
partout dans le monde avec le nouveau Yahoo! Messenger 
<a
href=3D"http://us.rd.yahoo.com/messenger/mail_taglines/default/*http:/fr.=
messenger.yahoo.com">T=E9l=E9chargez
le ici !</a> <o:p></o:p>

</div>

</div>

</body>

</html>

------=_NextPart_000_0047_01C58AF0.A406CB60--

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 j6GEULJj050159; Sat, 16 Jul 2005 07:30: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 j6GEUL7g050158; Sat, 16 Jul 2005 07:30:21 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.144]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6GEUJBo050138 for <ietf-pkix@imc.org>; Sat, 16 Jul 2005 07:30:20 -0700 (PDT) (envelope-from tgindin@us.ibm.com)
Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e4.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j6GEUEhh015372 for <ietf-pkix@imc.org>; Sat, 16 Jul 2005 10:30:14 -0400
Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay04.pok.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j6GEUAMD126566 for <ietf-pkix@imc.org>; Sat, 16 Jul 2005 10:30:14 -0400
Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j6GEUAYF018522 for <ietf-pkix@imc.org>; Sat, 16 Jul 2005 10:30:10 -0400
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.56.228.115]) by d01av01.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j6GEU9hD018518; Sat, 16 Jul 2005 10:30:10 -0400
In-Reply-To: <42D68FA5.1050409@nist.gov>
To: "David A. Cooper" <david.cooper@nist.gov>, sharon.boeyen@entrust.com
Cc: ietf-pkix@imc.org, Valery Smyslov <svan@synartra.com>
MIME-Version: 1.0
Subject: Re: issuerAltName and path construction - null issuer names
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
From: Tom Gindin <tgindin@us.ibm.com>
Message-ID: <OFA5B1AA84.B23233EB-ON8525703E.0063D5CD-85257040.004FA4A1@us.ibm.com>
Date: Sat, 16 Jul 2005 10:30:07 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 6.53IBM1 HF14|April 18, 2005) at 07/16/2005 10:30:09, Serialize complete at 07/16/2005 10:30:09
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 j6GEUKBo050144
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <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 think it's simpler to point out that while RFC 3280 section 
4.1.2.6 permits the subject to be omitted ("The subject name MAY be 
carried in the subject field and/or the subjectAltName extension"), 
section 4.1.2.4 does not permit the issuer to be omitted ("The issuer 
field MUST contain a non-empty distinguished name (DN).").  Section 
4.1.2.6 also requires that the subject DN not be empty if the subject is 
either a CA or a CRL issuer.  X.509 section 8.3.2.2 does point in the 
opposite direction, allowing null issuer names if the issuer alternative 
name is critical.
        Thus, part of Valery's premise is not relevant for PKIX - the 
issuer name must not contain a null sequence.  It is relevant to X.509, 
though.  The text you cite is unambiguous, but I don't see anything which 
revoked the note to X.509 8.3.2.2 permitting null issuer DN's if the 
alternative name is critical, and for a CA (although not for a CRL) a null 
issuer name is worthless if you can't match it against the subject of the 
issuing certificate.  This could be cleaned up, in conformance to the 
apparent intent of the FPDAM, by restricting the note to 8.3.2.2 to CRL 
issuers.

                Tom Gindin

"David A. Cooper" <david.cooper@nist.gov>
Sent by: owner-ietf-pkix@mail.imc.org
07/14/2005 12:15 PM

        To:     Valery Smyslov <svan@synartra.com>
        cc:     ietf-pkix@imc.org
        Subject:        Re: issuerAltName and path construction

Valery Smyslov wrote: 
Hi,

I have probably very simple question. If certificate contains
both non-null issuer and issuerAltName extension, should
the latter take part in path construction, or not? It is clear from 
RFC3280 anf X.509 that in case certificate contains no isuuer
(null sequence), issuerAltName must be used instead for path building, 
but it is unclear what should be done if both are present and populated.

In other words, when RP tries to find an issuer for given certificate
containing both non-null issuer and issuerAltName extension, should
he/she check that not only issuer field in the certificate matches
subject field in issuer certificate, but also issuerAltName matches
subjectAltName in issuer certificate?

Or, should it be done only when issuerAltName is marked critical,
and RP is free to ignore issuerAltName completly when it is
marked non-critical?

Valery,

Is the question about path construction or path validation?

For path construction, you are free to use whatever means you want to try 
to build a certification path.

For path validation, as I read X.509 and RFC 3280, the issuerAltName and 
subjectAltName should NEVER be used (except checking the subjectAltName 
against name constraints).

In X.509, perhaps the clearest language on this subject appears in the 
FPDAM Enhancements to Public-Key and Attribute Certificates (
ftp://ftp.bull.com/pub/OSIdirectory/Orlando2004Output/6N12793CertificateEnhancementDAM.pdf
):
7 Public-keys and public-key certificates
Add the following at the beginning of the paragraph that currently begins 
with ?A certification path logically
forms an unbroken chain ??.
The issuer and subject fields of each certificate are used, in part, to 
identify a valid path.  For each pair of adjacent certificates in a valid 
certification path, the value of the subject field in one certificate 
shall match the value of the issuer field in the subsequent certificate. 
In addition, the value of the issuer field in the first certificate shall 
match the DN of the trust anchor.  Only the names in these fields are used 
when checking validity of a certification path.  Names in certificate 
extensions are not used for this purpose.
I could not find any text in the 4th edition of X.509 that is this clear, 
but the path validation algorithm in clause 10 simply imposes the 
requirement:
a) Check that the signature verifies, that dates are valid, that the 
certificate subject and certificate issuer names chain correctly, and that 
the certificate has not been revoked.
I believe that this text was intended to mean that only the names in the 
issuer and subject fields are compared and not the names in the 
alternative name extensions.

In RFC 3280, comparisons of issuer and subject names in consecutive 
certificates is addressed in section 6 through the use of the 
working_issuer_name variable.   The working_issuer_name is defined as "the 
issuer distinguished name expected in the next certificate in the chain", 
it is set to the subject name from each certificate and compared against 
the issuer name in each certificate.  As with X.509, I read this language 
to mean that only the issuer and subject fields are compared and not the 
alternative names.

Dave

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 j6FMsIKk015122; Fri, 15 Jul 2005 15:54: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 j6FMsIdJ015121; Fri, 15 Jul 2005 15:54:18 -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 j6FMsGlJ015109 for <ietf-pkix@imc.org>; Fri, 15 Jul 2005 15:54:17 -0700 (PDT) (envelope-from stefans@microsoft.com)
Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Jul 2005 23:54:10 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: How ambiguous are names in actuality?
Date: Fri, 15 Jul 2005 23:54:10 +0100
Message-ID: <BF9309599A71984CAC5BAC5ECA62994402D45A27@EUR-MSG-11.europe.corp.microsoft.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: How ambiguous are names in actuality?
Thread-Index: AcWIqaj+9r8Jxa5fTc+zxyzbRC43pwA4kqgA
From: "Stefan Santesson" <stefans@microsoft.com>
To: "Tim Polk" <tim.polk@nist.gov>, <ietf-pkix@imc.org>
X-OriginalArrivalTime: 15 Jul 2005 22:54:10.0782 (UTC) FILETIME=[1D2EA7E0:01C58990]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j6FMsHlJ015116
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

Tim,
Thanks for the good analysis.

I do however feel that a point is slightly missing and thus my
conclusion differ a bit from yours.

I agree that subject naming ambiguity is not a real problem. Every CA is
well motivated to name its subjects in a way that makes sense within the
context of the intended use of the certificates and the naming structure
used in X.509 definitely allows this to be done sufficiently.

My concern is only with CRL Issuer naming and the reliance of this name
for security. In parallel I'm also concerned about path validation
complexity.

While validating a certificate path is a primary task for path
validation, the CRL validation is more of a background process that is
more or less invisible to relying parties and their applications. As
such, the consequences and threats concerning ambiguous naming of CRL
issuers might not be as clear to deployers of PKI as subject naming is.
I would suspect that someone deploying PKI will just assume that the
system will make sure that only the correct CRL will match the
certificates anyway since they will never understand this issue fully.

I do not believe that name constraints is a sufficient mechanism since a
valid path to a colliding CRL will have a valid path, or it would not
exist. So if such CRL exist, then we can't fix the problem with name
constraints.

Finally I do not worry too much about deployed products concerning
indirect CRLs since this is an almost non used feature as far as I know.

Thus I think a more restrictive path relationship between the target
certificate path and its CRL issuer path is still motivated here.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> -----Original Message-----
> From: owner-ietf-pkix@mail.imc.org
[mailto:owner-ietf-pkix@mail.imc.org]
> On Behalf Of Tim Polk
> Sent: den 14 juli 2005 20:24
> To: ietf-pkix@imc.org
> Subject: How ambiguous are names in actuality?
> 
> 
> 
> Ambiguity has recently become a hot topic on this list.  This is a
really
> complicated issue, and I have personally had a great deal of trouble
> sorting out the real level of risk.  Some of the proposed changes
would
> greatly impact current software, and these changes should only be
> contemplated if the risk is merits such change.
> 
> So, I have spent a lot of time, off and on, thinking about ambiguity.
I
> can't claim to have sorted it all out, but I have convinced myself
that
> one
> minor change is absolutely required, and that the current suite of
> mechanisms can virtually eliminate ambiguity in real PKIs.
> 
> My thinking is appended to this message;  I apologize for its length,
but
> to paraphrase Mark Twain, I simply don't have time to make this short
and
> concise.  I have attempted to define ambiguity, characterize the ways
> ambiguity can enter into a PKI, and describe the set of mechanisms
that
> mitigate this risk.
> 
> Thanks,
> 
> Tim Polk
> 
>
------------------------------------------------------------------------
--
> ------------------------------------------------------
> 
>               How ambiguous are names in actuality, and how important
is
> it?
> 
> I believe that X.509 expected assignment of unambiguous names based on
a
> hierarchical system of naming authorities.  Whether you agree with
that
> premise, it is safe to say that the global X.500 directory and its
> corresponding system of naming authorities do not exist. So, it may
not be
> safe to assume that there are no name collisions whatsoever in all the
DNs
> that appear in certificates and CRLs!  I am sure such collisions exist
> somewhere (although I haven't encountered any examples).  The real
> question
> here is "What security risk does this situation present, and are the
> current mechanisms adequate to address this risk?"
> 
> Let's recognize that the goal for PKIX is not to have globally
unambiguous
> names, but to be able to obtain a trustworthy public key to establish
a
> security service. Ambiguity in names is a problem when it causes the
> relying party to trust the wrong public key.
> 
> There are two ways ambiguous names could cause problems.  First, I
could
> accept public keys from two certificates as representing the same
person
> based on the same subject name.  If these two certificates are bound
to
> different individuals I may provide a service to the wrong party (or
> disclose confidential data, etc., etc.)  Second, I could accept a CRL
to
> validate a particular certificate, based on the same issuer name in
the
> certificate and CRL.  If the certificate and CRL were not actually
issued
> by the same CA, then the relying party may obtain incorrect
certificate
> status.
> 
> Note that both of these problems are in the context of path
validation.
> If
> a name collision exists, but only one of the objects (e.g.,
certificate or
> CRL) validates for a given relying party, then there is no actual
> ambiguity
> from that relying party's point of view.
> 
> That is, assume two certificates exist with the same subject name but
are
> bound to different people.  If Alice can only validate one of those
> certificates, there is no ambiguity in Alice's world.   Similarly, if
Bob
> can only validate one of those certificates, there is no ambiguity in
> Bob's
> world.   (It does not matter if Bob and Alice are validating the same
> certificate, or different ones!)   Similarly, if two CAs have the same
> issuer name, but Alice can only validate one, she can't accept the
wrong
> CRL.  Ditto for Bob.
> 
> So, ambiguity is a concern only in the context of path validation for
a
> given relying party. This means that the mechanisms that are employed
in
> path validation are relevant to when names are, and are not,
ambiguous.
> I'd
> also like to point out that path validation is always performed in the
> context of a particular trust anchor.  (A relying party may accept
paths
> that begin with multiple trust anchors, but each specific path has a
> single
> trust anchor.)  Seems irrelevant at the moment, but I will get back to
it!
> 
> Definition 1:  a Name N is unambiguous for a trust anchor T if and
only if
> all certificates that validate for T and have the subject N refer to
the
> same entity.
> 
> Now, let's think about where name collisions can occur in the first
place.
> There seems to be consensus that a single CA will not issue two
> certificates to two different entities with the same subject name.
So, if
> a single CA issues two certificates to "O=Microsoft, cn=John Wilson"
they
> better relate to the same guy.  Similarly if a particular CA issues
two
> certificates to "c=US, O=U.S. Government, OU=NIST, CN=CA1" then the
> subject
> of both certificates must be the same CA.
> 
> So, we are only worried about the case where two different CAs are
trusted
> with respect to a trust anchor T and issue certificates to different
> subjects but use the same name.  So, when can name collisions occur
> between
> CAs?  Or, better yet, under what conditions can we be sure name
collisions
> won't occur?  Let's start with user certificates.
> 
> In general, each CA that issues user certificates does so for a
particular
> name space.  That is, all names assigned to users will be in a
particular
> Directory Information Tree (DIT).   The CA will either work with a
naming
> authority that it considers authoritative or may assume that function
> itself.   For example, the NIST CA only issues user certificates in
the
> "C=US, O=U.S. Government, OU=NIST" DIT.   The NIST CA has been
designated
> as our naming authority as well, so it keeps track of the names it
> assigns.  Similarly, the CA that supports NASA only issues
certificates
> for
> the name space "C=US,  O=U.S. Government, OU=NASA" DIT.
> 
> These name spaces are disjoint, so name collisions cannot occur
involving
> user certificates generated by the NASA and NIST CAs.  In fact,
consider a
> PKI with trust anchor T and CAs C(1), C(2), ..., C(n) issuing for name
> spaces
> P(1), P(2), ..., P(n).  If spaces P(1), P(2), ..., P(n) are pairwise
disjoint,
> name collisions cannot occur involving user certificates generated by
> C(1),
> C(2), ..., C(n).
> 
> Case 1:  Consider a PKI with trust anchor T, and CAs C1, C2, and C3.
C1,
> C2, and C3 issue end user certificates in the DITs N1, N2, and N3
> respectively.  If N1, N2, and N3 are pairwise disjoint, then the user
> names
> are unambiguous with respect to T.
> 
> In more complex PKIs, we may encounter situations where CAs issue user
> certificates for name spaces that overlap.  For example, in the U.S
DoD's
> hierarchical PKI, CAs all issue certificates in the DIT "C=US, O=U.S.
> Government, OU=DOD".  Users routinely receive three certificates from
two
> different CAs, so all the DoD CAs rely on a common naming authority to
> ensure that certificates with the same DNs are issued to the same
person.
> 
> Case 2: Consider a PKI with trust anchor T, and CAs C1, C2, and C3.
C1,
> C2, and C3 issue end user certificates in the DITs N1, N2, and N3
> respectively.  N1 and N2 overlap, but N3 is disjoint from N1 and N2.
If
> CA1 and CA2 recognize the same naming authority, then the user names
in
> the
> PKI are unambiguous with respect to T.
> 
> That is, if all the CAs either: (1) issue certificates in disjoint
name
> spaces, or (2) issue certificates in shared name spaces based on a
common
> naming authority, names will be unambiguous!
> 
> Of course, CAs may issue CA certificates as well.  In this case, the
CA
> does not assign the names, but rather uses the established name.  This
is
> trickier, since the name spaces for CA certificates overlaps but no
naming
> authority exists.  It is still the responsibility of each CA to ensure
> that
> there are no name collisions in CA certificates it issues!  This is
not
> generally a problem, since we require names to be meaningful.  A CA
should
> never issue a certificate to a CA with the DN "C=US, O=Coca Cola"
unless
> the subject CA is associated with that company.  Similarly, if a CA
issues
> certificates in the DIT "C=US, O=Coca Cola" then it must be associated
> with
> the company!
> 
> Of course, a rogue CA may masquerade under the wrong name, or issue
> certificates in a DIT it clearly has no right to use, but no decent CA
> will
> cross certify with it.  Since we are interested in ambiguity with
respect
> to a trust anchor, the behavior of a rogue CA is irrelevant.  Without
> cross
> certification, no paths involving the rogue CA can be constructed.
(Note
> that users installing the rogue as a trust anchor is out of scope
here!)
> 
> However, authority for a name space is not always crystal clear.
Without
> a
> central naming authority, there is no clear title for a particular
DIT.
> We
> rely on heuristics that work nicely for large entities like Coca-Cola
but
> may fail for smaller organizations.  For example, there may be a
number of
> companies with variants on a particular name.  If the name space
assumed
> by
> an organization asserts "Orion" rather than "Orion Security" or "Orion
> Space Sciences", the name may be ambiguous without being blatantly
> false.  Each entity could reasonably assign user names in the "C=US,
> O=Orion" DIT.   If each organization established their CA with the
name
> "C=US, O=Orion, CN=CA1" things could get really ugly.
> 
> A trust anchor T may cross certify with two different CAs - say the
ones
> from NIST and NASA.  Each of those CAs may have a relationship with an
> "Orion".  If each of them cross certifies with the Orion they know and
> love, we have an immediate name collision for a CA named "C=US,
O=Orion,
> CN=CA1", and potentially name collisions for "C=US, O=Orion, CN=John
> Wilson", etc., etc.  Each CA has played by the rules, but names have
just
> become ambiguous with respect to T.  This might be avoided if T is
> involved
> in the policy decisions leading up to cross certification - but that
is
> often NOT the case.
> 
> Fortunately, we need not depend on policy alone.   Beyond the
> procedural/policy issues, there are some important mechanisms that
help us
> with name space control.  Most significant are path length constraints
and
> name constraints.  When trust anchor T issued those CA certificates,
it
> probably wasn't expecting to accept transitive trust from those CAs,
and
> it
> certainly didn't expect to accept the NIST or NASA CA as authoritative
for
> the "C=US, O=Orion" DIT.
> 
> I listed path length constraints first because this mechanism provides
the
> simplest and most widely available of our technical controls. Both
NASA
> and
> NIST use a single CA, rather than a mesh or hierarchy.  If the trust
> anchor
> does not wish to leverage other cross certifications performed by NASA
or
> NIST, it simply asserts a path length constraint of zero!  If T
asserted
> this constraint for at least one of the NIST or NASA CAs, then the
name
> "C=US, O=Orion, CN=John Wilson" is unambiguous. While this control was
not
> designed exclusively for name space control, it does have the effect
of
> prevenmting subsequent CAs from introducing unexpected name spaces.
> 
> Unfortunately, this does not solve our problem for "C=US, O=Orion,
> CN=CA1".   This name remains ambiguous.  Even with a path length
> constraints of zero, a relying party can validate a CRL from either
Orion
> CA.
> 
> Name constraints is a more appealing technical mechanism, if less
> consistently available.  T can explicitly designate the name spaces it
> wishes to recognize in the cross certificate issued to NIST (or NASA).
By
> asserting a permitted subtree of "C=US, O=U.S. Government, OU=NIST"
with a
> SkipCerts of zero, certificates in the Orion name space are
immediately
> eliminated.  This includes the offending CA certificate, so the
"wrong"
> CRL
> no longer validates.
> 
> Case 3: Consider a PKI with trust anchor T, and CAs C1, C2, and C3.
C1,
> C2, and C3 issue end user certificates in the DITs N1, N2, and N3
> respectively.
> 
> N1 and N2 are disjoint, but  N3 overlaps with N1 or N2.  C3 does not
> recognize the same naming authority as C1 or C2.   If name constraints
> permitted subtrees P3 is imposed in all cross certificates issued to
C3,
> where N1, N2, and P3 are pairwise disjoint, then names are unambiguous
> with
> respect to T.  (Names that could have collided are excluded from C3's
> DIT.)
> 
> Conclusion/Proposal
> 
> Ambiguity in names is a relatively minor risk with respect to a given
> trust
> anchor.  Ambiguity does not occur because of the actions of a single
CA;
> rather it requires a combination of actions by different CAs within
the
> infrastructure.  If all CA certificates accurately reflect the trust
> relationships between the CAs by incorporating appropriate path length
and
> name constraints, these risks are greatly reduced if not eliminated.
> 
> The risk of ambiguous names can be mitigated with a relatively simple
> modification in 3280bis, and the addition of some security
> considerations.  Most importantly, 32890bis should be modified to
ensure
> that certificate and CRL validation are always performed with respect
to
> the same trust anchor.  Security considerations should be added to
> highlight the risk of issuing CA certificates without appropriate
> constraints, and to caution application developers that trust anchor
> information should be considered when accepting certificates.
> 
> The changes that I believe should be implemented are as follows:
> 
>   (1) Modify section 6.3.3 to state that CRL validation MUST use the
same
> trust anchor T specified in the corresponding certification path.
> 
> (2) Add security considerations that indicate applications that accept
> multiple trust anchors should consider the trust anchor in access
control
> decisions to ensure that names are unambiguous.
> 
> (3) Add security considerations that explain the importance of
consistent
> use of path length and name constraints in preventing name ambiguity.
> 

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 j6FMApn8012229; Fri, 15 Jul 2005 15:10: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 j6FMAphG012228; Fri, 15 Jul 2005 15:10:51 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from web26601.mail.ukl.yahoo.com (web26601.mail.ukl.yahoo.com [217.146.176.51]) by above.proper.com (8.12.11/8.12.9) with SMTP id j6FMAnC9012215 for <ietf-pkix@imc.org>; Fri, 15 Jul 2005 15:10:50 -0700 (PDT) (envelope-from mskouri@yahoo.fr)
Received: (qmail 87866 invoked by uid 60001); 15 Jul 2005 22:10:44 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.fr; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=17Eqpo07wHoakballpesrftWx64eEH/GygdlJcH8H4usPBIeBPbCvhnivEojZMGxlkDHpAH2SnhgZj7+r/P+bbyrJbrEFLpkhACLsRNwsAfwTNm7vA/mr+OsBzKkSBxl9h6tAWx7NbHHceCdDmmCyPBx98psg0B9YZ976zdgTeg=  ;
Message-ID: <20050715221044.87864.qmail@web26601.mail.ukl.yahoo.com>
Received: from [196.203.34.9] by web26601.mail.ukl.yahoo.com via HTTP; Sat, 16 Jul 2005 00:10:43 CEST
Date: Sat, 16 Jul 2005 00:10:43 +0200 (CEST)
From: Mouna Skouri <mskouri@yahoo.fr>
Subject: SCVP implementation
To: ietf-pkix@imc.org
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1696810486-1121465443=:87537"
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>

--0-1696810486-1121465443=:87537
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Hi,

Does anyone know if there is any implementation of SCVP?

Thanks,
Mouna

---------------------------------
 Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger
 Téléchargez le ici !  
--0-1696810486-1121465443=:87537
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

<DIV>
<DIV>Hi,</DIV>
<DIV>&nbsp;</DIV>
<DIV>Does anyone know if there is&nbsp;any implementation of SCVP?<BR><BR>Thanks,<BR>Mouna<BR></DIV></DIV><p>
		<hr size=1> 
<b><font color=#FF0000>Appel audio GRATUIT</font> partout dans le monde</b> avec le nouveau Yahoo! Messenger<br> 
<a href="http://us.rd.yahoo.com/messenger/mail_taglines/default/*http://fr.messenger.yahoo.com">Téléchargez le ici !</a> 

--0-1696810486-1121465443=:87537--

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 j6FHDAGi082554; Fri, 15 Jul 2005 10:13: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 j6FHDAFF082553; Fri, 15 Jul 2005 10:13:10 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from host15.websitesource.com (host15.websitesource.com [209.239.32.38]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6FHD9p6082547 for <ietf-pkix@imc.org>; Fri, 15 Jul 2005 10:13:10 -0700 (PDT) (envelope-from chokhani@orionsec.com)
Received: from wchokhani3 (static-70-21-114-242.res.east.verizon.net [70.21.114.242]) by host15.websitesource.com (8.12.10/8.12.10) with ESMTP id j6FHD7qj029128 for <ietf-pkix@imc.org>; Fri, 15 Jul 2005 13:13:09 -0400
From: "Santosh Chokhani" <chokhani@orionsec.com>
To: "'pkix'" <ietf-pkix@imc.org>
Subject: RE: Correction to be done to <draft-pinkas-pkix-conf-crl-validation-01.txt>
Date: Fri, 15 Jul 2005 13:13:01 -0400
Message-ID: <001401c58960$787386f0$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
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Importance: Normal
In-Reply-To: 
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <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 apologies to the list for typo.

In the last paragraph, "CRL issuer" was meant to say "certificate issuer".
It is corrected below.

-----Original Message-----
From: Santosh Chokhani [mailto:chokhani@orionsec.com] 
Sent: Friday, July 15, 2005 1:09 PM
To: 'pkix'
Subject: RE: Correction to be done to
<draft-pinkas-pkix-conf-crl-validation-01.txt>

Denis,

The indirect CRL state machine is as follows:

	initial value of certificate_issuer_state = issuer field in the CRL
(1)

	certificate_issuer  = value in the CRL entry extension and if the
extension is absent, certificate_issuer = certificate_issuer_state (2)

	certificate_issuer_state = certificate_issuer

It is secure, standard compliant and provides for interoperability.  It is
probably too complex in comparison to doing nothing and yet to be defined
Denis's algorithms on a variety of CRL processing matters.

If the indirect CRL issuer is not a CA, the first revoked certificate entry
will contain a certificate issuer field.  There are numerous other
situations when first revoked certificate entry will contain a certificate
issuer field, but this is of no interest to a relying party that wants to
write a secure, interoperable, simple (i.e., not complex) CRL processing
logic.

-----Original Message-----
From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On
Behalf Of Denis Pinkas
Sent: Friday, July 15, 2005 4:24 AM
To: pkix
Subject: Correction to be done to
<draft-pinkas-pkix-conf-crl-validation-01.txt>

A correction needs to be done to 
<draft-pinkas-pkix-conf-crl-validation-01.txt>.

As explained in a previous e-mail, the certificate issuer name cannot
default to the name of the CRL issuer, hence the following text 
extracted from section 6.3.3.3 is incorrect :

        (ii) check if there exists a previous CRL entry
             and if that CRL entry contains a Certificate
             Issuer CRL entry extension and go back to (1).

                If there is no previous CRL entry, then
                check if the name of the issuer of the CRL
                matches the name of the issuer field of the
                target certificate.

                 - If it does, then set the cert_revoc_status
                   variable to REVOKED and if the CRL entry
                   extension " reasonCode " is present in
                   that CRL entry, then set the revoc_reason
                   variable to the value contained in that CRL
                   entry extension and the algorithm
                   terminates.

                 - If it does, then set the cert_revoc_status
                   variable to NOT_REVOKED and the algorithm
                   terminates.

It would need to be corrected (and greatly simplified)
in the following way:

          (ii) If there is no previous CRL entry, then
               this is an error in the structure of the CRL
               and the algorithm terminates.

               Otherwise, check if that CRL entry contains
               a Certificate Issuer CRL entry extension and
               go back to (1).

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 j6FH8fLV082145; Fri, 15 Jul 2005 10:08: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 j6FH8frw082144; Fri, 15 Jul 2005 10:08:41 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from host15.websitesource.com (host15.websitesource.com [209.239.32.38]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6FH8eru082138 for <ietf-pkix@imc.org>; Fri, 15 Jul 2005 10:08:40 -0700 (PDT) (envelope-from chokhani@orionsec.com)
Received: from wchokhani3 (static-70-21-114-242.res.east.verizon.net [70.21.114.242]) by host15.websitesource.com (8.12.10/8.12.10) with ESMTP id j6FH8cqj017346 for <ietf-pkix@imc.org>; Fri, 15 Jul 2005 13:08:39 -0400
From: "Santosh Chokhani" <chokhani@orionsec.com>
To: "'pkix'" <ietf-pkix@imc.org>
Subject: RE: Correction to be done to <draft-pinkas-pkix-conf-crl-validation-01.txt>
Date: Fri, 15 Jul 2005 13:08:30 -0400
Message-ID: <001301c5895f$d7f62b60$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.2900.2180
Importance: Normal
In-Reply-To: <42D772AF.6000704@bull.net>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j6FH8eru082139
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <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,

The indirect CRL state machine is as follows:

	initial value of certificate_issuer_state = issuer field in the CRL
(1)

	certificate_issuer  = value in the CRL entry extension and if the
extension is absent, certificate_issuer = certificate_issuer_state (2)

	certificate_issuer_state = certificate_issuer

It is secure, standard compliant and provides for interoperability.  It is
probably too complex in comparison to doing nothing and yet to be defined
Denis's algorithms on a variety of CRL processing matters.

If the indirect CRL issuer is not a CA, the first revoked certificate entry
will contain a CRL issuer field.  There are numerous other situations when
first revoked certificate entry will contain a CRL issuer field, but this is
of no interest to a relying party that wants to write a secure,
interoperable, simple (i.e., not complex) CRL processing logic.

-----Original Message-----
From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On
Behalf Of Denis Pinkas
Sent: Friday, July 15, 2005 4:24 AM
To: pkix
Subject: Correction to be done to
<draft-pinkas-pkix-conf-crl-validation-01.txt>

A correction needs to be done to 
<draft-pinkas-pkix-conf-crl-validation-01.txt>.

As explained in a previous e-mail, the certificate issuer name cannot
default to the name of the CRL issuer, hence the following text 
extracted from section 6.3.3.3 is incorrect :

        (ii) check if there exists a previous CRL entry
             and if that CRL entry contains a Certificate
             Issuer CRL entry extension and go back to (1).

                If there is no previous CRL entry, then
                check if the name of the issuer of the CRL
                matches the name of the issuer field of the
                target certificate.

                 - If it does, then set the cert_revoc_status
                   variable to REVOKED and if the CRL entry
                   extension " reasonCode " is present in
                   that CRL entry, then set the revoc_reason
                   variable to the value contained in that CRL
                   entry extension and the algorithm
                   terminates.

                 - If it does, then set the cert_revoc_status
                   variable to NOT_REVOKED and the algorithm
                   terminates.

It would need to be corrected (and greatly simplified)
in the following way:

          (ii) If there is no previous CRL entry, then
               this is an error in the structure of the CRL
               and the algorithm terminates.

               Otherwise, check if that CRL entry contains
               a Certificate Issuer CRL entry extension and
               go back to (1).

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 j6FH1TlE081570; Fri, 15 Jul 2005 10:01: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 j6FH1TKM081569; Fri, 15 Jul 2005 10:01:29 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from host15.websitesource.com (host15.websitesource.com [209.239.32.38]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6FH1S6x081562 for <ietf-pkix@imc.org>; Fri, 15 Jul 2005 10:01:28 -0700 (PDT) (envelope-from chokhani@orionsec.com)
Received: from wchokhani3 (static-70-21-114-242.res.east.verizon.net [70.21.114.242]) by host15.websitesource.com (8.12.10/8.12.10) with ESMTP id j6FH1Pqj032604 for <ietf-pkix@imc.org>; Fri, 15 Jul 2005 13:01:27 -0400
From: "Santosh Chokhani" <chokhani@orionsec.com>
To: "'pkix'" <ietf-pkix@imc.org>
Subject: RE: 3280bis: CRL validation: treatment of critical CRL entry extensions
Date: Fri, 15 Jul 2005 13:01:21 -0400
Message-ID: <001201c5895e$d65bf8d0$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.2900.2180
Importance: Normal
In-Reply-To: <42D771E0.5070209@bull.net>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j6FH1T6x081564
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <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,

Please see responses in-line in [Santosh2:] with irrelevant material
deleted.

-----Original Message-----
From: Denis Pinkas [mailto:Denis.Pinkas@bull.net] 
Sent: Friday, July 15, 2005 4:21 AM
To: Santosh Chokhani
Cc: 'pkix'
Subject: Re: 3280bis: CRL validation: treatment of critical CRL entry
extensions

>The problem is that, later on, a specific critical CRL entry extension 
>This problem was however addressed by RFC 3280 since RFC 3280 states on 
>page
>59:
>
>"The CRL issuer MUST assert the indirectCRL boolean, if the scope of 
>the CRL includes certificates issued by authorities other than the CRL 
>issuer.  The authority responsible for each entry is indicated by the 
>certificate issuer CRL entry extension (section 5.3.4)".
>
>These two sentences are within the same paragraph, just one after the 
>other.
>
>In the first sentence, the plural is used for "authorities" and thus 
>the first sentence is NOT written as follows : "The CRL issuer MUST 
>assert the indirectCRL boolean, if the scope of the CRL includes 
>certificates issued by *an authority* other than the CRL issuer".
>
>The two sentences from page 59 from RFC 3280 would need to be corrected 
>in the following way:
>
>"The CRL issuer MUST assert the indirectCRL boolean, if the scope of 
>the CRL includes certificates issued by *more than one certificate 
>issuer*. In such a case, the certificate issuer responsible for each 
>entry is indicated by the certificate issuer CRL entry extension 
>(section 5.3.4)".

>[Santosh: Denis has incorrect understanding of how indirect CRLs work. 
>First, the standard permits an indirect CRL issuer cover certificates 
>issued by a single CA.  Second, the second sentence above is worded 
>such that it could be misinterpreted to mean that each entry needs to 
>assert the certificate issuer.  That also is not true.]

You missed the "s" from the word "authority". You also missed the point that
a CRL issuer cannot issue certificates, unless it is also the CA. See my
last response to David.

[Santosh2: I am sure I have missed a lot.  But, that is not the point of
discussion.  Let us get back to the point of discussion and that is the
language proposed by Denis, which is wrong.  The standard permits an
indirect CRL to cover certificates issued by a single CA.  Denis's proposal
prohibits and hence changes the standard.  Furthermore, there is no security
or interoperability need to change the standard.  Thus, Denis's proposed
change must be rejected.] 

>These sentences indicate that, if the indirectCRL boolean is set to 
>TRUE, then one or more certificate issuer CRL entry extensions are 
>present.

>[Santosh: This statement is also incorrect.  Let us say that an 
>indirect CRL covers 1 or more CAs other than itself.  If none of the 
>certificates issued by those other CAs are revoked, none of the CRL 
>entries will have the certificate issuer present.]

Let us say that the boolean should indicate the presence of certificates
from multiples CAs. The wording "delegated" CRL should be used when the CRL
covers certificates from a single CA. See my response to David.

[Santosh2: Again, Denis's language is incorrect and he has not responded to
my response.  To repeat, just because there is an indirect CRL, does not
mean, that it will have any entries at all or from any of the CAs.  So
Denis's statement is false.  Even if started rising in the West and Denis's
statement were to be true, it would be useless from relying party
perspective.  We have a well defined algorithm for CRL processing and it
provides no security or interoperability benefit that a relying party check
that if indirect CRL flag is set, there are some certificateIssuer CRL entry
extensions.  This will be a useless and erroneous check.] 

>The indirectCRL boolean indicates the presence or absence of 
>certificate issuer CRL entry extensions in the CRL.

>[Santosh: This is poorly worded.  If the indirect CRL flag is set, 
>certificate issuer extension may be present, but need not be present.  
>It is also not clear why relying parties will care for many of the 
>assertions made by Denis.  We have a well-defined state machine for CRL 
>and indirect CRL processing.  It is best that the relying parties 
>implement that and not add other rules to make their software more 
>complex.  For example, a somewhat related problem I am uncovering is 
>that some relying party software that process extensions such as 
>"inhibit any policy" are checking the criticality of the extension.  Of 
>course, that is useless.]

The current processing rules are too complex and do not cover clearly what
"conforming relying parties" MUST support when handling CRLs, I mean relying
parties supporting the mandatory-to-support extensions for relying parties.

The text needs also to be clear about what additional treatments MAY be
supported.

The current algorithm from section 3280bis is also based on unsufficient
assumptions, I would even say "incorrect assumptions". There is no mention
when the cache is flushed  so it may contain multiples CRLs: "old" CRLs
which are useful to demonstrate that a certificate is revoked when the
"valid" CRL is not available.

The current algorithm does not also support the case where two or more
"valid" CRLs are present in the cache, or said in different words: may
provide a wrong output in that case.

The last I-D that I have posted takes care of all of these cases. It is
available at:
http://www.ietf.org/internet-drafts/draft-pinkas-pkix-conf-crl-validation-01
.txt

[Santosh2: Without going into complexity of current rules, the rules
proposed by Denis's are neither needed, nor accurate, not provide any
security benefit.  In short, they have no purpose.  At least the so called
"complex rules" have a purpose.  As to the new I-D, Denis's posting have one
common theme: they exhibit a lack of understanding of the CRL mechanism and
CRL processing rules.  It is not clear what benefit reviewing an I-D would
make when author's posting exhibit lack of understanding of the topic which
the I-D covers.]

>It allows to perform an efficient checking of the CRL entries :
>
> -    If the indirectCRL boolean is set to TRUE, then the CRL entry
>      extensions from previous CRL entries MUST be checked to verify
>      whether a certificate issuer CRL entry extension is present.
>
>[Santosh: A proper way to process an indirect CRL is to apply the 
>certificate issuer state machine for the indirect CRL and it requires 
>you to process the entries in sequence]
>
>-     If the IDP extension is not present or if the indirectCRL boolean
>      is set to FALSE, then CRL entry extensions from every CRL entry
>      can ignored or skipped.
>  
>

Not necessarily. This can be done backwards. See my proposal in :
http://www.ietf.org/internet-drafts/draft-pinkas-pkix-conf-crl-validation-01
.txt

>[Santosh: Again, assuming not using some the entry ordering extensions, 
>you need to go through all the entries and match the serial number.]

No. There is no need to go through every entry to check if the very specific
certificate issuer crl entry extension is present in a crl entry. This can
be done backwards. See my proposal in :
http://www.ietf.org/internet-drafts/draft-pinkas-pkix-conf-crl-validation-01
.txt
which avoids to test *every* crl entry extension.

[Santosh2: You can do what ever you want, but the state machine remains the
same: certificate_issuer  = value in the CRL entry extension and if the
extension is absent, certificate_issuer = certificate_issuer_state;
certificate_issuer_state = certificate_issuer.  This state machine must be
executed in sequence starting with the first entry and the initial value of
certificate_issuer_state = issuer field in the CRL.  If you want to come to
US from France via Asia and pacific ocean, feel free.]

>When the DP includes the cRLIssuer field, verifying that *one value* 
>from the issuer field in the complete CRL matches cRLIssuer in the DP 
>is both necessary and sufficient.

>[Santosh: You also want to make sure that the CRL is indirect CRL since 
>the crlIssuer in the CRL DP in certificate implies that the CRL issuer 
>is some one other than certificate issuer.  Please see section 4.2.1.14 
>of RFC 3280]

It is fully sufficient to check that the CRL issuer name is different from
the certificate issuer name.

[Santosh2: No.  You want to make sure that when they are different, the CRL
is truly an indirect CRL and you do not get a direct CRL from the CRL issuer
who can be CA.]

The presence or absence of the mis-named indirectCRL boolean from the IDP
extension is of no use at all from a relying party point of view. See my
proposal in :
http://www.ietf.org/internet-drafts/draft-pinkas-pkix-conf-crl-validation-01
.txt

Now, if  you can demonstrate that in case the CRL contains only certificates
issued by one CA, there would be some fraud possible in the absence of the
boolean, then I would be interrested to examine how.

Denis

>There is no need to have the following insertion :
>
>                                                      " and that
>         the complete CRL contains an issuing distribution point
>         extension with the indirectCRL boolean asserted ".
>
>[Santosh: See my previous comment.]
>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 j6F8O9ni012000; Fri, 15 Jul 2005 01:24:09 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6F8O95F011999; Fri, 15 Jul 2005 01:24:09 -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 j6F8O8pC011954 for <ietf-pkix@imc.org>; Fri, 15 Jul 2005 01:24:09 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net)
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id KAA37708 for <ietf-pkix@imc.org>; Fri, 15 Jul 2005 10:39:58 +0200
Received: from bull.net ([129.181.81.10]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005071510245571:909 ; Fri, 15 Jul 2005 10:24:55 +0200 
Message-ID: <42D772AF.6000704@bull.net>
Date: Fri, 15 Jul 2005 10:24:15 +0200
From: Denis Pinkas <Denis.Pinkas@bull.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: pkix <ietf-pkix@imc.org>
Subject: Correction to be done to <draft-pinkas-pkix-conf-crl-validation-01.txt>
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 15/07/2005 10:24:56, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 15/07/2005 10:24:57, Serialize complete at 15/07/2005 10:24:57
Content-Transfer-Encoding: 7bit
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>

A correction needs to be done to 
<draft-pinkas-pkix-conf-crl-validation-01.txt>.

As explained in a previous e-mail, the certificate issuer name
cannot default to the name of the CRL issuer, hence the following text 
extracted from section 6.3.3.3 is incorrect :

        (ii) check if there exists a previous CRL entry
             and if that CRL entry contains a Certificate
             Issuer CRL entry extension and go back to (1).

                If there is no previous CRL entry, then
                check if the name of the issuer of the CRL
                matches the name of the issuer field of the
                target certificate.

                 - If it does, then set the cert_revoc_status
                   variable to REVOKED and if the CRL entry
                   extension " reasonCode " is present in
                   that CRL entry, then set the revoc_reason
                   variable to the value contained in that CRL
                   entry extension and the algorithm
                   terminates.

                 - If it does, then set the cert_revoc_status
                   variable to NOT_REVOKED and the algorithm
                   terminates.

It would need to be corrected (and greatly simplified)
in the following way:

          (ii) If there is no previous CRL entry, then
               this is an error in the structure of the CRL
               and the algorithm terminates.

               Otherwise, check if that CRL entry contains
               a Certificate Issuer CRL entry extension and
               go back to (1).

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 j6F8L6It010903; Fri, 15 Jul 2005 01:21: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 j6F8L6j0010902; Fri, 15 Jul 2005 01:21:06 -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 j6F8L5sq010853 for <ietf-pkix@imc.org>; Fri, 15 Jul 2005 01:21:05 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net)
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id KAA44706; Fri, 15 Jul 2005 10:36:33 +0200
Received: from bull.net ([129.181.81.10]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005071510212884:908 ; Fri, 15 Jul 2005 10:21:28 +0200 
Message-ID: <42D771E0.5070209@bull.net>
Date: Fri, 15 Jul 2005 10:20:48 +0200
From: Denis Pinkas <Denis.Pinkas@bull.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Santosh Chokhani <chokhani@orionsec.com>
CC: "'pkix'" <ietf-pkix@imc.org>
Subject: Re: 3280bis: CRL validation: treatment of critical CRL entry extensions
References: <004f01c58626$07ffefe0$9a00a8c0@hq.orionsec.com>
In-Reply-To: <004f01c58626$07ffefe0$9a00a8c0@hq.orionsec.com>
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 15/07/2005 10:21:30, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 15/07/2005 10:21:32, Serialize complete at 15/07/2005 10:21:32
Content-Transfer-Encoding: 7bit
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>

Santosh,

>Denis,
>
>Please see responses in-line under [Santosh:]
>
>-----Original Message-----
>From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On
>Behalf Of Denis Pinkas
>Sent: Monday, July 11, 2005 7:33 AM
>To: pkix
>Subject: 3280bis: CRL validation: treatment of critical CRL entry extensions
>
>3280bis: CRL validation: treatment of critical CRL entry extensions
>RFC 3280 states on page 60 :
>
>" 5.3  CRL Entry Extensions
>   [...]
>   All CRL entry extensions used in this specification are non-critical."
>
>This is however untrue since RFC 3280 states on page 62 :
>
>" 5.3.4  Certificate Issuer
>   This CRL entry extension identifies the certificate issuer associated
>   with an entry in [...] a CRL that has the indirectCRL indicator set
>   in its issuing distribution point extension.
>   [...]
>   If used by conforming CRL issuers, this extension MUST always be
>   critical."
>
>The text is unclear about what to do with a critical CRL entry extension
>that is not recognized, and thus this needs to be clarified.
>
>CRL entry extensions did not existed originally in CRL version v1 and could
>be ignored when parsing a CRL. When introducing CRL entry extensions, the
>idea was the following: if a given CRL entry is found to be "appropriate"
>THEN and only THEN there is the need to make sure that it contains no
>critical CRL entry extension that is not understood. If it does then the CRL
>entry MUST be considered as invalid.
>
>The problem is that, later on, a specific critical CRL entry extension has
>been introduced: the Certificate Issuer CRL entry extension. That CRL entry
>extension is very special since its presence in a CRL entry extension
>earlier in the list of CRL entries modifies the meaning the CRL entry, even
>if it does not contain a CRL entry extension.
>
>This problem was however addressed by RFC 3280 since RFC 3280 states on page
>59:
>
>"The CRL issuer MUST assert the indirectCRL boolean, if the scope of the CRL
>includes certificates issued by authorities other than the CRL issuer.  The
>authority responsible for each entry is indicated by the certificate issuer
>CRL entry extension (section 5.3.4)".
>
>These two sentences are within the same paragraph, just one after the other.
>
>In the first sentence, the plural is used for "authorities" and thus the
>first sentence is NOT written as follows : "The CRL issuer MUST assert the
>indirectCRL boolean, if the scope of the CRL includes certificates issued by
>*an authority* other than the CRL issuer".
>
>The two sentences from page 59 from RFC 3280 would need to be corrected in
>the following way:
>
>"The CRL issuer MUST assert the indirectCRL boolean, if the scope of the CRL
>includes certificates issued by *more than one certificate issuer*. In such
>a case, the certificate issuer responsible for each entry is indicated by
>the certificate issuer CRL entry extension (section 5.3.4)".

>[Santosh: Denis has incorrect understanding of how indirect CRLs work.
>First, the standard permits an indirect CRL issuer cover certificates issued
>by a single CA.  Second, the second sentence above is worded such that it
>could be misinterpreted to mean that each entry needs to assert the
>certificate issuer.  That also is not true.]

You missed the "s" from the word "authority". You also missed the point
that a CRL issuer cannot issue certificates, unless it is also the CA.
See my last response to David.

>These sentences indicate that, if the indirectCRL boolean is set to TRUE,
>then one or more certificate issuer CRL entry extensions are present.

>[Santosh: This statement is also incorrect.  Let us say that an indirect CRL
>covers 1 or more CAs other than itself.  If none of the certificates issued
>by those other CAs are revoked, none of the CRL entries will have the
>certificate issuer present.]

Let us say that the boolean should indicate the presence of
certificates from multiples CAs. The wording "delegated" CRL should be
used when the CRL covers certificates from a single CA. See my response
to David.

>This also means that if the IDP extension is not present or if the
>indirectCRL boolean is set to FALSE, then no certificate issuer CRL entry
>extension is present.

>[Santosh: This is true.]

>The indirectCRL boolean indicates the presence or absence of certificate
>issuer CRL entry extensions in the CRL.

>[Santosh: This is poorly worded.  If the indirect CRL flag is set,
>certificate issuer extension may be present, but need not be present.  It is
>also not clear why relying parties will care for many of the assertions made
>by Denis.  We have a well-defined state machine for CRL and indirect CRL
>processing.  It is best that the relying parties implement that and not add
>other rules to make their software more complex.  For example, a somewhat
>related problem I am uncovering is that some relying party software that
>process extensions such as "inhibit any policy" are checking the criticality
>of the extension.  Of course, that is useless.]

The current processing rules are too complex and do not cover clearly
what "conforming relying parties" MUST support when handling CRLs,
I mean relying parties supporting the mandatory-to-support extensions
for relying parties.

The text needs also to be clear about what additional treatments MAY be
supported.

The current algorithm from section 3280bis is also based on unsufficient
assumptions, I would even say "incorrect assumptions". There is no
mention when the cache is flushed  so it may contain multiples CRLs:
"old" CRLs which are useful to demonstrate that a certificate is revoked
when the "valid" CRL is not available.

The current algorithm does not also support the case where two or more
"valid" CRLs are present in the cache, or said in different words:
may provide a wrong output in that case.

The last I-D that I have posted takes care of all of these cases.
It is available at:
http://www.ietf.org/internet-drafts/draft-pinkas-pkix-conf-crl-validation-01.txt

>It allows to perform an efficient checking of the CRL entries :
>
> -    If the indirectCRL boolean is set to TRUE, then the CRL entry
>      extensions from previous CRL entries MUST be checked to verify
>      whether a certificate issuer CRL entry extension is present.
>
>[Santosh: A proper way to process an indirect CRL is to apply the
>certificate issuer state machine for the indirect CRL and it requires you to
>process the entries in sequence]  
>
>-     If the IDP extension is not present or if the indirectCRL boolean
>      is set to FALSE, then CRL entry extensions from every CRL entry
>      can ignored or skipped.
>  
>

Not necessarily. This can be done backwards. See my proposal in :
http://www.ietf.org/internet-drafts/draft-pinkas-pkix-conf-crl-validation-01.txt

>[Santosh: Again, assuming not using some the entry ordering extensions, you
>need to go through all the entries and match the serial number.]

No. There is no need to go through every entry to check if the very
specific certificate issuer crl entry extension is present in a crl
entry. This can be done backwards. See my proposal in :
http://www.ietf.org/internet-drafts/draft-pinkas-pkix-conf-crl-validation-01.txt
which avoids to test *every* crl entry extension.

>The core of the issue is about the following paragraph in section 6.3.3 on
>page 84 :
>
>      (1)  If the DP includes cRLIssuer, then verify that the issuer
>      field in the complete CRL matches cRLIssuer in the DP and that
>      the complete CRL contains an issuing distribution point
>      extension with the indrectCRL boolean asserted.  Otherwise,
>      verify that the CRL issuer matches the certificate issuer.

>[Santosh: The above statement in 3280 is correct]

>BTW, there is a typo error where "indirectCRL" is typed "indrectCRL".

>Note that the current text in section 6.3.3 from RFC 3280 does not handle
>the Certificate Issuer CRL entry extension, when present, which may lead to
>incorrect results.

>When the DP includes the cRLIssuer field, verifying that *one value* from
>the issuer field in the complete CRL matches cRLIssuer in the DP is both
>necessary and sufficient.

>[Santosh: You also want to make sure that the CRL is indirect CRL since the
>crlIssuer in the CRL DP in certificate implies that the CRL issuer is some
>one other than certificate issuer.  Please see section 4.2.1.14 of RFC 3280]

It is fully sufficient to check that the CRL issuer name is different
from the certificate issuer name.

The presence or absence of the mis-named indirectCRL boolean from the
IDP extension is of no use at all from a relying party point of view.
See my proposal in :
http://www.ietf.org/internet-drafts/draft-pinkas-pkix-conf-crl-validation-01.txt

Now, if  you can demonstrate that in case the CRL contains only
certificates issued by one CA, there would be some fraud possible in the
absence of the boolean, then I would be interrested to examine how.

Denis

>There is no need to have the following insertion :
>
>                                                      " and that
>         the complete CRL contains an issuing distribution point
>         extension with the indirectCRL boolean asserted ".
>
>[Santosh: See my previous comment.]
>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 j6F8HMPA009372; Fri, 15 Jul 2005 01:17: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 j6F8HM2w009371; Fri, 15 Jul 2005 01:17:22 -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 j6F8HL9w009315 for <ietf-pkix@imc.org>; Fri, 15 Jul 2005 01:17:21 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net)
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id KAA24038; Fri, 15 Jul 2005 10:33:09 +0200
Received: from bull.net ([129.181.81.10]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005071510180437:907 ; Fri, 15 Jul 2005 10:18:04 +0200 
Message-ID: <42D77112.9000704@bull.net>
Date: Fri, 15 Jul 2005 10:17:22 +0200
From: Denis Pinkas <Denis.Pinkas@bull.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "David A. Cooper" <david.cooper@nist.gov>
CC: pkix <ietf-pkix@imc.org>
Subject: Re: 3280bis: CRL validation: treatment of critical CRL entry extensions
References: <42D258FC.5090108@bull.net> <42D29029.8030706@nist.gov>
In-Reply-To: <42D29029.8030706@nist.gov>
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 15/07/2005 10:18:06, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 15/07/2005 10:18:08, Serialize complete at 15/07/2005 10:18:08
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=windows-1252; 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>

David,

> Denis Pinkas wrote:
>
>> 3280bis: CRL validation: treatment of critical CRL entry extensions
>>
>> RFC 3280 states on page 60 :
>>
>> " 5.3  CRL Entry Extensions
>>
>>   [...]
>>
>>   All CRL entry extensions used in this specification are non-critical."
>
>
> Already changed in 3280bis-00.
>
>> CRL entry extensions did not existed originally in CRL version v1 and 
>> could
>> be ignored when parsing a CRL. When introducing CRL entry extensions, 
>> the
>> idea was the following: if a given CRL entry is found to be 
>> "appropriate"
>> THEN and only THEN there is the need to make sure that it contains no
>> critical CRL entry extension that is not understood. If it does then the
>> CRL entry MUST be considered as invalid.
>
>
> Yes.  There is a sentence in clause 7.3 of X.509 that states something 
> to this effect, but the rule was violated with the certificateIssuer 
> extension.  We have submitted a defect report, DR 311 
> (ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DefectReports/X.509andRelated/DR_311.pdf), 
> to have this sentence removed from X.509.

The defect report that has been submitted does not solve the issue.
First it is incorrect because the first sentence of note 5 is related
to CRL extensions, but not CRL entry extensions, and thus does not need
to be deleted.

Second: the note 4 remains. It is copied below:

    When an implementation processing a certificate revocation list does
    not recognize a critical extension in the *crlEntryExtensions* field,
    it shall assume that, at a minimum, the identified certificate has
    been revoked and is no longer valid and perform additional actions
    concerning that revoked certificate as dictated by local policy.
    When an implementation does not recognize a critical extension
    in the *crlExtensions* field, it shall assume that identified
    certificates have been revoked and are no longer valid.

You want to change the general rule and thus you want to delete the
note 5, but note 4 still remains.

The other way is to maintain the general rule (as it is explained in
note 4) and to adress the exception, i.e. how to deal with the
certificate issuer crl entry extension.

But we are are revising 3280 and the point is that there is no guidance
at all in RFC 3280 to know what a relying party should do with a
critical crl entry extension. We need text for the general rule and we
need text to handle the (single one) exception.

>> This problem was however addressed by RFC 3280 since RFC 3280
>> states on page 59:
>>
>> "The CRL issuer MUST assert the indirectCRL boolean, if the scope of
>> the CRL includes certificates issued by authorities other than the
>> CRL issuer.  The authority responsible for each entry is indicated
>> by the certificate issuer CRL entry extension (section 5.3.4)".
>>
>> These two sentences are within the same paragraph, just one after
>> the other.
>>
>> In the first sentence, the plural is used for "authorities" and thus
>> the first sentence is NOT written as follows : "The CRL issuer MUST
>> assert the indirectCRL boolean, if the scope of the CRL includes
>> certificates issued by *an authority* other than the CRL issuer".

> As has been stated many times, the indirectCRL boolean is asserted if 
> the scope of the CRL includes one or more certificates  for which the 
> issuer field in the certificate is different from the issuer field in 
> the CRL.  We cannot change that.  

The current text is as follows:

    "The CRL issuer MUST assert the indirectCRL boolean, if the scope of
     the CRL includes certificates issued by authorities other than the
     CRL issuer. The authority responsible for each entry is indicated
     by the certificate issuer CRL entry extension (section 5.3.4)".

RFC 3280 states:

« Whenever the CRL issuer is not the CA that issued the certificates,
   the CRL is referred to as an indirect CRL ».

This sentence means that an indirect CRL is not issued by an entity that
has issued the certificate.

This comes into conflict with the following sentence extracted from
section 5.3.4 Certificate Issuer :

    If this extension is not present on the first entry in an
    indirect CRL, the certificate issuer defaults to the CRL issuer.

For an indirect CRL, the certificate issuer cannot default to the name
of the CRL issuer since the CRL issuer has not issued any of the
certificates that are in the indirect CRL. This would only be the case
when the CRL is a direct CRL.

The current text of RFC 3280 is inconsistent.

The fact is that when a CRL is about certificates issued by more than
one CA, the certificate issuer CRL entry extension MUST be present,
whereas when a CRL is about certificates issued by only one CA, it is
unnecessary to use the certificate issuer CRL entry extension but it
were present this would not heart since the algorithm to be used by
relying parties to verify CRLs would not need to make use of it. This
opens the road for backwards compatibility, if necessary.

This also means that when an indirect CRL is related to certificates
from more than one CA, the certificate issuer CRL entry extension MUST
be present on the first entry in an indirect CRL,   ... which is
obviously in full contradiction with the current text from RFC 3280.

In addition, the end of section 5.3.4 is incorrect as already mentioned
in earlier e-mails. Itis copied again below:

    If used by conforming CRL issuers, this extension MUST always be
    critical.  If an implementation ignored this extension it could not
    correctly attribute CRL entries to certificates.  This specification
    RECOMMENDS that implementations recognize this extension.

Section 5.3.4 needs to be fully revised.

My interpretation of the boolean would be:

    "The CRL issuer MUST assert the indirectCRL boolean, if the scope
     of the CRL includes certificate serial numbers in the
     revokedCertificates list for which the issuer names are different.

or an alternative sentence which means the same:

    "The CRL issuer MUST assert the indirectCRL boolean, if the scope
     of the CRL includes certificate serial numbers in the
     revokedCertificates list from more than one CA.

If we keep the name of the boolean, then we should restrict the use of
the wording "indirect CRLs" to CRLs that contain serial numbers from
more than one CA.

The text from RF 3280 should then be changed into:

   " Whenever the CRL issuer is not the CA that issued the certificates,
   the CRL is referred to as a delegated CRL, if it contains certificates
   from a single CA, or as an indirect CRL when it may contain
   certificates from multiple CAs ".

Now, if the CRL is NOT issued by a CA and includes certificates from a
single CA, the certificate issuer CRL entry extension is unnecessary
since the name of the issuer is not taken from the name of the issuer in
the CRL, neither from any value of the certificate issuer CRL entry
extension, if present, but simply from the issuer name of the certificate.

Of course, there is also the need to add in 3280bis an adaptation of the
text of the security consideration section from
<draft-pinkas-pkix-conf-crl-validation-01.txt>:

    A CRL Issuer SHALL not accept the duty to issue CRLs for one CA,
    if it has already agreed to perform that task for another CA that
    has the same DN.

RFC3280 has problems of inconsistencies that need to be solved.

BTW, since I followed too closely the text from section 5.3.4, some text
of section the 6.3.3.3 of
<draft-pinkas-pkix-conf-crl-validation-01.txt> needs to be revised. The
correction is posted in a separate e-mail.

> However, if the use of the term
> "authorities" is truly causing confusion, we can change that.  How about:
>
>      If the scope of the CRL only includes certificates issued by the CRL
>      issuer then the indirectCRL boolean MUST be set to FALSE.  
> Otherwise,
>      if the scope of the CRL includes certificates issued by one or more
>      authorities other than the CRL issuer, the indirectCRL boolean MUST
>      be set to TRUE.  The authority responsible for each entry is
>      indicated by the certificate issuer CRL entry extension (section
>      5.3.4).

You know that we will never agree on that kind of statement since
"certificates issued by [whatever] *other than the issuer CRL*" is
unacceptable since a CRL issuer never issues CRLs, unless it also a CA.

>> These sentences indicate that, if the indirectCRL boolean is set to
>> TRUE, then one or more certificate issuer CRL entry extensions are
>> present.

> While this is usually the case, is not may always be.   The 
> indirectCRL boolean is set to TRUE if the SCOPE of the CRL includes 
> certificates issued by an authority (or authorities) other than the 
> CRL issuer, but it may be that none of these certificates have been 
> revoked.

The plural is used, i.e. "authorities. "authority" is NOT used. The text
is NOT "authority (or authorities)" as you would like it to be.

> If no certificates within the scope of the CRL have been revoked, then 
> revokedCertificates will be absent, but the indirectCRL could still be 
> asserted.  Similarly, if the only revoked certificates within the 
> scope of the CRL are certificates issued by the CRL issuer, then the 
> certificateIssuer CRL entry extension does not need to appear in any 
> of the CRL entries since  section 5.3.4 states:

>   If [the certificate issuer] extension is not present on the first 
> entry in an
>   indirect CRL, the certificate issuer defaults to the CRL issuer.  On
>   subsequent entries in an indirect CRL, if this extension is not 
> present,
>   the certificate issuer for the entry is the same as that for the 
> preceding entry.

> If the certificateIssuer CRL entry extension is not included in any of 
> the CRL entries, then the certificate issuer associated with each 
> entry will be the issuer of the CRL.  So, if all revoked certificates 
> were issued by the issuer of the CRL, then the certificateIssuer CRL 
> entry extension does not need to be included in any CRL entries even 
> if the scope of the CRL includes certificates that were not issued by 
> the issuer of the CRL.

See above.

>> BTW, there is a typo error where "indirectCRL" is typed
>> "indrectCRL".

> Fixed.

Fine. At least one issue on which we agree. :-)

>> Note that the current text in section 6.3.3 from RFC 3280 does not
>> handle the Certificate Issuer CRL entry extension, when present,
>> which may lead to incorrect results.

> In section 6.3.3, steps (i) and (j) refer to section 5.3.4.  Section 
> 5.3.4 specifies how to determine the certificate issuer associated 
> with each entry in the CRL.

This far from sufficient see my *new* I-D (version -01) that has been
published:
http://www.ietf.org/internet-drafts/draft-pinkas-pkix-conf-crl-validation-01.txt

It takes care in great details about the treatment of that specific crl
entry extension.

>> When the DP includes the cRLIssuer field, verifying that *one value*
>> from the issuer field in the complete CRL matches cRLIssuer in the
>> DP is both necessary and sufficient.
>>
>> There is no need to have the following insertion :
>>
>>                                                      " and that
>>         the complete CRL contains an issuing distribution point
>>         extension with the indirectCRL boolean asserted ".
>

> This step is a necessary part of determining whether the certificate 
> is included in the scope of the CRL.  

This step is fully unnecessary if the scope of the CRL includes
certificates from only one CA.

Denis

> If the indirectCRL boolean is 
> not asserted then the CRL does not cover any certificates for which 
> the issuer name in the certificate is different from the issuer name 
> in the CRL.  So, if you are using a CRL to determine the status of a 
> certificate, and the issuer names are not the same, you must verify 
> that indirectCRL boolean is asserted in the CRL in addition to 
> verifying that the CRL issuer's name appears in the cRLIssuer field in 
> the description of the distribution point in the certificate.

> Dave

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 j6F8FBFb008566; Fri, 15 Jul 2005 01:15: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 j6F8FBE7008565; Fri, 15 Jul 2005 01:15:11 -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 j6F8FA6G008481; Fri, 15 Jul 2005 01:15:10 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net)
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id KAA15446; Fri, 15 Jul 2005 10:30:59 +0200
Received: from bull.net ([129.181.81.10]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005071510155760:905 ; Fri, 15 Jul 2005 10:15:57 +0200 
Message-ID: <42D77094.304@bull.net>
Date: Fri, 15 Jul 2005 10:15:16 +0200
From: Denis Pinkas <Denis.Pinkas@bull.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: S-MIME / IETF <ietf-smime@imc.org>
CC: pkix <ietf-pkix@imc.org>
Subject: CMS Advanced Electronic Signatures (CAdES)
References: <42D514F9.8050700@bull.net>
In-Reply-To: <42D514F9.8050700@bull.net>
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 15/07/2005 10:15:58, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 15/07/2005 10:15:58, Serialize complete at 15/07/2005 10:15:58
Content-Transfer-Encoding: 7bit
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>

To the S-MIME list,
Copy to the PKIX list.

The I-D for the transposition of the latest revision of ETSI TS 101 773,
renamed "CMS Advanced Electronic Signatures (CAdES),"
<draft-pinkas-smime-cades-00.txt> was temporarily available from :
<http://www.imc.org/ietf-smime/TEMP-draft-pinkas-smime-cades-00.txt>
until available in the IETF repository.

It is now avaialble from the official IETF web site at:
http://www.ietf.org/internet-drafts/draft-pinkas-smime-cades-00.txt

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 j6F8E3v6007841; Fri, 15 Jul 2005 01:14: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 j6F8E3Ko007840; Fri, 15 Jul 2005 01:14:03 -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 j6F8E0Li007760 for <ietf-pkix@imc.org>; Fri, 15 Jul 2005 01:14:01 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net)
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id KAA16838; Fri, 15 Jul 2005 10:29:47 +0200
Received: from bull.net ([129.181.81.10]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005071510144418:903 ; Fri, 15 Jul 2005 10:14:44 +0200 
Message-ID: <42D7704A.9080504@bull.net>
Date: Fri, 15 Jul 2005 10:14:02 +0200
From: Denis Pinkas <Denis.Pinkas@bull.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "David A. Cooper" <david.cooper@nist.gov>
CC: pkix <ietf-pkix@imc.org>
Subject: Re: 3280bis: CRL validation: what is wrong and/or missing in section 6.3
References: <42D25881.2060908@bull.net> <42D2AF7E.7040701@nist.gov>
In-Reply-To: <42D2AF7E.7040701@nist.gov>
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 15/07/2005 10:14:46, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 15/07/2005 10:14:47, Serialize complete at 15/07/2005 10:14:47
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=windows-1252; 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>

David,

See my responses below.

> Denis Pinkas wrote:
>
>> 3280bis: CRL validation: what is wrong and/or missing in section 6.3.
>>
>> 1. The very first sentence states:
>>
>> " This section describes the steps necessary to determine if a
>>   certificate is revoked or on hold status when CRLs are the revocation
>>   mechanism used by the certificate issuer".
>>
>> a) This section should describe the steps necessary to determine
>>   if the revocation status of the certification path* is : REVOKED,
>>   NOT_REVOKED or UNKNOWN, instead of simply determine if the
>>   *target certificate* is REVOKED. So the sentence is incorrect.
>
>
> The algorithm in section 6.3 is used to determine the status of a 
> particular certificate, not a certification path, so the text is 
> correct.  However, as part of certification path validation, section 
> 6.1.3, step (a)(3) states that, for each certificate in the path, one 
> must verify that the certificate is not revoked or on hold, and it 
> indicates that if status is determined using CRLs that section 6.3 
> indicates how the status can be determined. 

The sentence should be replaced with:

"This section describes the steps necessary to determine whether the
revocation status of a target certificate is revoked, not revoked or
unknown. If the revocation status is "revoked", the algorithm can
further indicate whether the certificate is on hold".

> b) The current text mentions the return of the "on hold" status.
>
>>   However since CRLreason is not mentioned as an output parameter
>>   of the algorithm, this may not be the case (the only algorithm
>>   output is currently the revocation status of the certificate).
>
>
> The variable cert_status is output from the algorithm.  In section 
> 6.3.3 steps (i) and (j), the value of cert_status is set to the value 
> from the reason code CRL entry extension if the certificate is found 
> to be revoked and the reason code extension is present.

No.  Since (i) starts with "  (i)  If use-deltas is set" this is only
applicable with delta CRLs and not in the general case.

Without using delta CRLs it is important that the algorithm is able to
indicate the "on hold" status. Currently it does not.

>> 2. The text states: " Conforming implementations that support
>> CRLs are not required to implement this algorithm, but they MUST
>> be functionally equivalent to the external behavior resulting
>> from this procedure".

> If you believe that this sentence and some of text quoted below need 
> to be more precisely worded, please provide text for consideration.

The response was/is indicated just below. We need different sections to
address the different cases. This is exactly was
<draft-pinkas-pkix-conf-crl-validation-01.doc> is trying to achieve.

>> This sentence is incorrect since the algorithm would mandate
>> the support of many certificate extensions, CRL extensions and
>> CRL entry extensions that conforming relying party applications
>> are NOT REQUIRED to support. The current algorithm has many errors
>> in it cannot be easily simplified, if less than "all options"
>> are supported by a relying party.
>>
>> 3. The text states: "This algorithm assumes that all of the needed
>> CRLs are available in a local cache".
>>
>> This sentence is incorrect, because it may happen that the "right"
>> or a "current" CRL is  unavailable and thus absent; in such a case
>> the algorithm terminates with "UNDETERMINED" or "UNKNOWN".

> I don't understand what you mean by incorrect, the sentence states an 
> assumption, not a fact.

The assumption is incorrect for several reasons :

   a) the needed CRL may not be available,

   b) there may be more than one valid CRL in the local cache:
      if so, the freshest is not necessarily selected,

   c) old CRLs may be used to determine that the certificate is revoked
      (of course, they cant determine that the certificate is not
      revoked).

The current algorithm addresses none if the above three cases.
The I-D that I have posted addresses these three cases.
Please take a look at:
http://www.ietf.org/internet-drafts/draft-pinkas-pkix-conf-crl-validation-01.txt

>> 4. The text states:
>>
>> "This algorithm begins by assuming the certificate is not revoked."
>>
>> This sentence is incorrect, the algorithm should begin by assuming
>> the status of the certificate is "UNDETERMINED" or "UNKNOWN".

> cert_status is initialized to UNREVOKED.  If the status cannot be 
> determined, cert_status gets changed to UNDETERMINED as the final step.

The text states :

    If the revocation status remains undetermined, then
    return the cert_status UNDETERMINED.

How can this been done, since there is no internal state that allows to
know that the revocation status is undetermined ?

It is much more practical to start the algorithm with the UNKNOW
cert_status which is the right status at the beginning of the algorithm,
since it allows to exit the algorithm at any time with the right status.

>> 5. The text states, [omitting what is relevant to delta CRLs]
>>
>> "(a)  Update the local CRL cache by obtaining a complete CRL [ ] :
>>
>>         (1)  If the current time is after the value of the CRL next
>>         update field, then do one of the following :
>>
>>            (i) [ ].
>>
>>            (ii)  Update the local CRL cache with a current complete
>>            CRL, verify that the current time is before the next update
>>            value in the new CRL, [ ]".
>>
>> This is incorrect. If the "current" CRL cannot be found, then it is
>> still possible to use an older CRL to demonstrate that the certificate
>> was REVOKED. Of course, when using an older CRL it is not possible
>> to demonstrate that the certificate was NOT_REVOKED.

> Section 6.3 states "Further, if the next update time of a CRL has 
> passed, the algorithm assumes a mechanism to fetch a current CRL and 
> place it in the local CRL cache."  So, while the scenario you describe 
> could happen, section 6.3 states that the algorithm does not address 
> this scenario.

  ... and this is why the assumptions currently made in 3280bis are
incorrect. As you say, 3280bis does not address this scenario but it should.

>> 6. The current algorithm cannot make sure that an emergency CRL (
>> i.e. the latest captured CRL) will be used if more than one
>> "valid" CRLs are found in the local cache.
>
> True.  As long as untrusted mechanisms are used to distribute CRLs, 
> the relying party cannot ensure that it has the latest CRL.

You missed the point. If the latest CRL is in the cache, there is no
guarantee that it will even be seen. The I-D that I have posted
addresses this case.

>> 7. The text states:
>>
>>   (f)  Obtain and validate the certification path for the complete CRL
>>   issuer.  If a key usage extension is present in the CRL issuer's
>>   certificate, verify that the cRLSign bit is set.
>>
>>   (g)  Validate the signature on the complete CRL using the public key
>>   validated in step (f).
>>
>> The text is unclear about what is meant by :" validate the certification
>> path for the complete CRL issuer". In order to solve the problem of
>> identical CRL Issuer names or identical CA names, it is needed to say
>> that the certification path that has been used to validate the target
>> certificate MUST also be used.

> Would you like for step (f) to say that the validation should be 
> performed as specified in section 6.1 and/or section 6.2?

Certainly not ! The answer is just above. THE FULL CERTIFICATION PATH
THAT HAS BEEN USED TO VALIDATE THE TARGET CERTIFICATE MUST ALSO BE USED
TO VALIDATE THE CRL ISSUER CERTIFICATE . This is the point that Stefan
supported in another recent e-mail. He was also thinking that it might
be possible that the CRL Issuer certificate could be issued by another
CA from the same certification path. However this would not work, since
this would not prevent name collisions.

> Even though X.509 requires that names be unambiguous, there does seem 
> to be consensus within the PKIX WG that 3280bis should impose some 
> restrictions of the certification path used to validate a CRL in order 
> to address the concern that a name collision might occur despite 
> X.509's prohibition.  However, at the moment, WG consensus seems to be 
> in favor of only requiring that the certification path for the CRL use 
> the same trust anchor as the certification path for the corresponding 
> CRL.  There is language about this in the security considerations 
> section.  In order for 3280bis to be even more restrictive, it would 
> need to be shown that there is WG consensus in favor of imposing such 
> restrictions.

It appears that your understanding of the consensus about naming in
X.509 is incorrect. Sharon has sent a very explicit message on the list
about this. We have to face the reality of possible name collisions
either accidental or voluntary. The same trust anchor does not solve
the issue, since it is insecure. A secure way to handle the issue is
mentioned above. Here it is again copied : THE FULL CERTIFICATION PATH
THAT HAS BEEN USED TO VALIDATE THE TARGET CERTIFICATE MUST ALSO BE USED
TO VALIDATE THE CRL ISSUER CERTIFICATE .

>> 8. There is no handling of the Certificate Issuer CRL entry extension,
>> when present, which may lead to incorrect results.
>
> Section 6.3.3, steps (i) and (j) refer to section 5.3.4, which 
> indicates how to process this extension.

No. Section (i) starts with  (i)  If use-deltas is set,   .
It is thus specific to delta-CRL and is not applicable in the general
case. Also there is no clear indication of the processing and referring
to section 5.3.4 is far from sufficient.

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 j6EN2HNQ094291; Thu, 14 Jul 2005 16:02: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 j6EN2HwC094290; Thu, 14 Jul 2005 16:02:17 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from SMTP.Lamicro.com (66-163-8-251.ip.tor.radiant.net [66.163.8.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6EN2G84094283 for <ietf-pkix@imc.org>; Thu, 14 Jul 2005 16:02:17 -0700 (PDT) (envelope-from thierry.moreau@connotech.com)
Received: from Spooler by SMTP.Lamicro.com (Mercury/32 v4.01b) ID MO00048F; 14 Jul 2005 19:04:28 -0400
Received: from spooler by Lamicro.com (Mercury/32 v4.01b); 14 Jul 2005 19:04:14 -0400
Received: from connotech.com (209.71.204.110) by SMTP.Lamicro.com (Mercury/32 v4.01b) with ESMTP ID MG00048E; 14 Jul 2005 19:04:06 -0400
Message-ID: <42D6F608.7000704@connotech.com>
Date: Thu, 14 Jul 2005 19:32:24 -0400
From: Thierry Moreau <thierry.moreau@connotech.com>
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.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: A non-critical self-signed certificate extension for trust anchr renewal ...
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>

To the pkix list:

Here is a new trust anchor renewal scheme explained in an Internet draft 
document draft-moreau-pkix-takrem-00.txt (submitted today, also 
available at http://www.connotech.com/draft-moreau-pkix-takrem-00.txt).

See also http://www.connotech.com/takrem.pdf for a more tutorial 
explanation.

Regards,

-- 

- Thierry Moreau

CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, Qc
Canada   H2M 2A1

Tel.: (514)385-5691
Fax:  (514)385-5900

web site: http://www.connotech.com
e-mail: thierry.moreau@connotech.com

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 j6EIM5Se063511; Thu, 14 Jul 2005 11:22: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 j6EIM5tg063510; Thu, 14 Jul 2005 11:22:05 -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 (rimp2.nist.gov [129.6.16.227]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6EIM4vS063503 for <ietf-pkix@imc.org>; Thu, 14 Jul 2005 11:22:04 -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.13.1/8.13.1) with ESMTP id j6EILrJ2025874 for <ietf-pkix@imc.org>; Thu, 14 Jul 2005 14:21:54 -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 j6EILT6v019140 for <ietf-pkix@imc.org>; Thu, 14 Jul 2005 14:21:29 -0400 (EDT)
Message-Id: <5.1.0.14.2.20050714141350.034ee3f0@email.nist.gov>
X-Sender: wpolk@email.nist.gov
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 14 Jul 2005 14:24:00 -0400
To: ietf-pkix@imc.org
From: Tim Polk <tim.polk@nist.gov>
Subject: How ambiguous are names in actuality?
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: tim.polk@nist.gov
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j6EIM5vS063505
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

Ambiguity has recently become a hot topic on this list.  This is a really 
complicated issue, and I have personally had a great deal of trouble 
sorting out the real level of risk.  Some of the proposed changes would 
greatly impact current software, and these changes should only be 
contemplated if the risk is merits such change.

So, I have spent a lot of time, off and on, thinking about ambiguity.  I 
can't claim to have sorted it all out, but I have convinced myself that one 
minor change is absolutely required, and that the current suite of 
mechanisms can virtually eliminate ambiguity in real PKIs.

My thinking is appended to this message;  I apologize for its length, but 
to paraphrase Mark Twain, I simply don't have time to make this short and 
concise.  I have attempted to define ambiguity, characterize the ways 
ambiguity can enter into a PKI, and describe the set of mechanisms that 
mitigate this risk.

Thanks,

Tim Polk

--------------------------------------------------------------------------------------------------------------------------------

              How ambiguous are names in actuality, and how important is it?

I believe that X.509 expected assignment of unambiguous names based on a 
hierarchical system of naming authorities.  Whether you agree with that 
premise, it is safe to say that the global X.500 directory and its 
corresponding system of naming authorities do not exist. So, it may not be 
safe to assume that there are no name collisions whatsoever in all the DNs 
that appear in certificates and CRLs!  I am sure such collisions exist 
somewhere (although I havent encountered any examples).  The real question 
here is What security risk does this situation present, and are the 
current mechanisms adequate to address this risk?

Lets recognize that the goal for PKIX is not to have globally unambiguous 
names, but to be able to obtain a trustworthy public key to establish a 
security service. Ambiguity in names is a problem when it causes the 
relying party to trust the wrong public key.

There are two ways ambiguous names could cause problems.  First, I could 
accept public keys from two certificates as representing the same person 
based on the same subject name.  If these two certificates are bound to 
different individuals I may provide a service to the wrong party (or 
disclose confidential data, etc., etc.)  Second, I could accept a CRL to 
validate a particular certificate, based on the same issuer name in the 
certificate and CRL.  If the certificate and CRL were not actually issued 
by the same CA, then the relying party may obtain incorrect certificate status.

Note that both of these problems are in the context of path validation.  If 
a name collision exists, but only one of the objects (e.g., certificate or 
CRL) validates for a given relying party, then there is no actual ambiguity 
from that relying partys point of view.

That is, assume two certificates exist with the same subject name but are 
bound to different people.  If Alice can only validate one of those 
certificates, there is no ambiguity in Alices world.   Similarly, if Bob 
can only validate one of those certificates, there is no ambiguity in Bobs 
world.   (It does not matter if Bob and Alice are validating the same 
certificate, or different ones!)   Similarly, if two CAs have the same 
issuer name, but Alice can only validate one, she cant accept the wrong 
CRL.  Ditto for Bob.

So, ambiguity is a concern only in the context of path validation for a 
given relying party. This means that the mechanisms that are employed in 
path validation are relevant to when names are, and are not, ambiguous. Id 
also like to point out that path validation is always performed in the 
context of a particular trust anchor.  (A relying party may accept paths 
that begin with multiple trust anchors, but each specific path has a single 
trust anchor.)  Seems irrelevant at the moment, but I will get back to it!

Definition 1:  a Name N is unambiguous for a trust anchor T if and only if 
all certificates that validate for T and have the subject N refer to the 
same entity.

Now, lets think about where name collisions can occur in the first place. 
There seems to be consensus that a single CA will not issue two 
certificates to two different entities with the same subject name.  So, if 
a single CA issues two certificates to O=Microsoft, cn=John Wilson they 
better relate to the same guy.  Similarly if a particular CA issues two 
certificates to c=US, O=U.S. Government, OU=NIST, CN=CA1 then the subject 
of both certificates must be the same CA.

So, we are only worried about the case where two different CAs are trusted 
with respect to a trust anchor T and issue certificates to different 
subjects but use the same name.  So, when can name collisions occur between 
CAs?  Or, better yet, under what conditions can we be sure name collisions 
wont occur?  Lets start with user certificates.

In general, each CA that issues user certificates does so for a particular 
name space.  That is, all names assigned to users will be in a particular 
Directory Information Tree (DIT).   The CA will either work with a naming 
authority that it considers authoritative or may assume that function 
itself.   For example, the NIST CA only issues user certificates in the 
C=US, O=U.S. Government, OU=NIST DIT.   The NIST CA has been designated 
as our naming authority as well, so it keeps track of the names it 
assigns.  Similarly, the CA that supports NASA only issues certificates for 
the name space C=US,  O=U.S. Government, OU=NASA DIT.

These name spaces are disjoint, so name collisions cannot occur involving 
user certificates generated by the NASA and NIST CAs.  In fact, consider a 
PKI with trust anchor T and CAs C(1), C(2), , C(n) issuing for name spaces 
P(1), P(2), , P(n).  If spaces P(1), P(2), , P(n) are pairwise disjoint, 
name collisions cannot occur involving user certificates generated by C(1), 
C(2), , C(n).

Case 1:  Consider a PKI with trust anchor T, and CAs C1, C2, and C3.  C1, 
C2, and C3 issue end user certificates in the DITs N1, N2, and N3 
respectively.  If N1, N2, and N3 are pairwise disjoint, then the user names 
are unambiguous with respect to T.

In more complex PKIs, we may encounter situations where CAs issue user 
certificates for name spaces that overlap.  For example, in the U.S DoDs 
hierarchical PKI, CAs all issue certificates in the DIT C=US, O=U.S. 
Government, OU=DOD.  Users routinely receive three certificates from two 
different CAs, so all the DoD CAs rely on a common naming authority to 
ensure that certificates with the same DNs are issued to the same person.

Case 2: Consider a PKI with trust anchor T, and CAs C1, C2, and C3.  C1, 
C2, and C3 issue end user certificates in the DITs N1, N2, and N3 
respectively.  N1 and N2 overlap, but N3 is disjoint from N1 and N2.   If 
CA1 and CA2 recognize the same naming authority, then the user names in the 
PKI are unambiguous with respect to T.

That is, if all the CAs either: (1) issue certificates in disjoint name 
spaces, or (2) issue certificates in shared name spaces based on a common 
naming authority, names will be unambiguous!

Of course, CAs may issue CA certificates as well.  In this case, the CA 
does not assign the names, but rather uses the established name.  This is 
trickier, since the name spaces for CA certificates overlaps but no naming 
authority exists.  It is still the responsibility of each CA to ensure that 
there are no name collisions in CA certificates it issues!  This is not 
generally a problem, since we require names to be meaningful.  A CA should 
never issue a certificate to a CA with the DN C=US, O=Coca Cola unless 
the subject CA is associated with that company.  Similarly, if a CA issues 
certificates in the DIT C=US, O=Coca Cola then it must be associated with 
the company!

Of course, a rogue CA may masquerade under the wrong name, or issue 
certificates in a DIT it clearly has no right to use, but no decent CA will 
cross certify with it.  Since we are interested in ambiguity with respect 
to a trust anchor, the behavior of a rogue CA is irrelevant.  Without cross 
certification, no paths involving the rogue CA can be constructed.  (Note 
that users installing the rogue as a trust anchor is out of scope here!)

However, authority for a name space is not always crystal clear.  Without a 
central naming authority, there is no clear title for a particular DIT.  We 
rely on heuristics that work nicely for large entities like Coca-Cola but 
may fail for smaller organizations.  For example, there may be a number of 
companies with variants on a particular name.  If the name space assumed by 
an organization asserts Orion rather than Orion Security or Orion 
Space Sciences, the name may be ambiguous without being blatantly 
false.  Each entity could reasonably assign user names in the C=US, 
O=Orion DIT.   If each organization established their CA with the name 
C=US, O=Orion, CN=CA1 things could get really ugly.

A trust anchor T may cross certify with two different CAs  say the ones 
from NIST and NASA.  Each of those CAs may have a relationship with an 
Orion.  If each of them cross certifies with the Orion they know and 
love, we have an immediate name collision for a CA named C=US, O=Orion, 
CN=CA1, and potentially name collisions for C=US, O=Orion, CN=John 
Wilson, etc., etc.  Each CA has played by the rules, but names have just 
become ambiguous with respect to T.  This might be avoided if T is involved 
in the policy decisions leading up to cross certification  but that is 
often NOT the case.

Fortunately, we need not depend on policy alone.   Beyond the 
procedural/policy issues, there are some important mechanisms that help us 
with name space control.  Most significant are path length constraints and 
name constraints.  When trust anchor T issued those CA certificates, it 
probably wasnt expecting to accept transitive trust from those CAs, and it 
certainly didnt expect to accept the NIST or NASA CA as authoritative for 
the C=US, O=Orion DIT.

I listed path length constraints first because this mechanism provides the 
simplest and most widely available of our technical controls. Both NASA and 
NIST use a single CA, rather than a mesh or hierarchy.  If the trust anchor 
does not wish to leverage other cross certifications performed by NASA or 
NIST, it simply asserts a path length constraint of zero!  If T asserted 
this constraint for at least one of the NIST or NASA CAs, then the name 
C=US, O=Orion, CN=John Wilson is unambiguous. While this control was not 
designed exclusively for name space control, it does have the effect of 
prevenmting subsequent CAs from introducing unexpected name spaces.

Unfortunately, this does not solve our problem for C=US, O=Orion, 
CN=CA1.   This name remains ambiguous.  Even with a path length 
constraints of zero, a relying party can validate a CRL from either Orion CA.

Name constraints is a more appealing technical mechanism, if less 
consistently available.  T can explicitly designate the name spaces it 
wishes to recognize in the cross certificate issued to NIST (or NASA).  By 
asserting a permitted subtree of C=US, O=U.S. Government, OU=NIST with a 
SkipCerts of zero, certificates in the Orion name space are immediately 
eliminated.  This includes the offending CA certificate, so the wrong CRL 
no longer validates.

Case 3: Consider a PKI with trust anchor T, and CAs C1, C2, and C3.  C1, 
C2, and C3 issue end user certificates in the DITs N1, N2, and N3 respectively.

N1 and N2 are disjoint, but  N3 overlaps with N1 or N2.  C3 does not 
recognize the same naming authority as C1 or C2.   If name constraints 
permitted subtrees P3 is imposed in all cross certificates issued to C3, 
where N1, N2, and P3 are pairwise disjoint, then names are unambiguous with 
respect to T.  (Names that could have collided are excluded from C3s DIT.)

Conclusion/Proposal

Ambiguity in names is a relatively minor risk with respect to a given trust 
anchor.  Ambiguity does not occur because of the actions of a single CA; 
rather it requires a combination of actions by different CAs within the 
infrastructure.  If all CA certificates accurately reflect the trust 
relationships between the CAs by incorporating appropriate path length and 
name constraints, these risks are greatly reduced if not eliminated.

The risk of ambiguous names can be mitigated with a relatively simple 
modification in 3280bis, and the addition of some security 
considerations.  Most importantly, 32890bis should be modified to ensure 
that certificate and CRL validation are always performed with respect to 
the same trust anchor.  Security considerations should be added to 
highlight the risk of issuing CA certificates without appropriate 
constraints, and to caution application developers that trust anchor 
information should be considered when accepting certificates.

The changes that I believe should be implemented are as follows:

  (1) Modify section 6.3.3 to state that CRL validation MUST use the same 
trust anchor T specified in the corresponding certification path.

(2) Add security considerations that indicate applications that accept 
multiple trust anchors should consider the trust anchor in access control 
decisions to ensure that names are unambiguous.

(3) Add security considerations that explain the importance of consistent 
use of path length and name constraints in preventing name ambiguity.

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 j6EGExm2049859; Thu, 14 Jul 2005 09:14: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 j6EGExFK049858; Thu, 14 Jul 2005 09:14:59 -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 (rimp2.nist.gov [129.6.16.227]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6EGEw4x049846 for <ietf-pkix@imc.org>; Thu, 14 Jul 2005 09:14:58 -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.13.1/8.13.1) with ESMTP id j6EGEq8J012448; Thu, 14 Jul 2005 12:14:55 -0400
Received: from [129.6.54.72] (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id j6EGEb6u023328; Thu, 14 Jul 2005 12:14:38 -0400 (EDT)
Message-ID: <42D68FA5.1050409@nist.gov>
Date: Thu, 14 Jul 2005 12:15:33 -0400
From: "David A. Cooper" <david.cooper@nist.gov>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040804
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Valery Smyslov <svan@synartra.com>
CC: ietf-pkix@imc.org
Subject: Re: issuerAltName and path construction
References: <00a001c5883c$48cd8150$640572d4@trustworks.com>
In-Reply-To: <00a001c5883c$48cd8150$640572d4@trustworks.com>
Content-Type: multipart/alternative; boundary="------------050203050001010705030605"
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: david.cooper@nist.gov
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <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.
--------------050203050001010705030605
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Valery Smyslov wrote:

>Hi,
>
>I have probably very simple question. If certificate contains
>both non-null issuer and issuerAltName extension, should
>the latter take part in path construction, or not? It is clear from 
>RFC3280 anf X.509 that in case certificate contains no isuuer
>(null sequence), issuerAltName must be used instead for path building, 
>but it is unclear what should be done if both are present and populated.
>
>In other words, when RP tries to find an issuer for given certificate
>containing both non-null issuer and issuerAltName extension, should
>he/she check that not only issuer field in the certificate matches
>subject field in issuer certificate, but also issuerAltName matches
>subjectAltName in issuer certificate?
>
>Or, should it be done only when issuerAltName is marked critical,
>and RP is free to ignore issuerAltName completly when it is
>marked non-critical?
>  
>
Valery,

Is the question about path construction or path validation?

For path construction, you are free to use whatever means you want to 
try to build a certification path.

For path validation, as I read X.509 and RFC 3280, the issuerAltName and 
subjectAltName should NEVER be used (except checking the subjectAltName 
against name constraints).

In X.509, perhaps the clearest language on this subject appears in the 
FPDAM Enhancements to Public-Key and Attribute Certificates 
(ftp://ftp.bull.com/pub/OSIdirectory/Orlando2004Output/6N12793CertificateEnhancementDAM.pdf):

            7 Public-keys and public-key certificates

    /Add the following at the beginning of the paragraph that currently
    begins with "A certification path logically
    forms an unbroken chain ..."/.

    The *issuer* and *subject* fields of each certificate are used, in
    part, to identify a valid path.  For each pair of adjacent
    certificates in a valid certification path, the value of the
    *subject* field in one certificate shall match the value of the
    *issuer* field in the subsequent certificate.  In addition, the
    value of the *issuer* field in the first certificate shall match the
    DN of the trust anchor.  Only the names in these fields are used
    when checking validity of a certification path.  Names in
    certificate extensions are not used for this purpose.

I could not find any text in the 4th edition of X.509 that is this 
clear, but the path validation algorithm in clause 10 simply imposes the 
requirement:

    a) Check that the signature verifies, that dates are valid, that the
    certificate subject and certificate issuer names chain correctly,
    and that the certificate has not been revoked.

I believe that this text was intended to mean that only the names in the 
issuer and subject fields are compared and not the names in the 
alternative name extensions.

In RFC 3280, comparisons of issuer and subject names in consecutive 
certificates is addressed in section 6 through the use of the 
working_issuer_name variable.   The working_issuer_name is defined as 
"the issuer distinguished name expected in the next certificate in the 
chain", it is set to the subject name from each certificate and compared 
against the issuer name in each certificate.  As with X.509, I read this 
language to mean that only the issuer and subject fields are compared 
and not the alternative names.

Dave

--------------050203050001010705030605
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Valery Smyslov wrote:
<blockquote cite="mid00a001c5883c$48cd8150$640572d4@trustworks.com"
 type="cite">
  <pre wrap="">Hi,

I have probably very simple question. If certificate contains
both non-null issuer and issuerAltName extension, should
the latter take part in path construction, or not? It is clear from 
RFC3280 anf X.509 that in case certificate contains no isuuer
(null sequence), issuerAltName must be used instead for path building, 
but it is unclear what should be done if both are present and populated.

In other words, when RP tries to find an issuer for given certificate
containing both non-null issuer and issuerAltName extension, should
he/she check that not only issuer field in the certificate matches
subject field in issuer certificate, but also issuerAltName matches
subjectAltName in issuer certificate?

Or, should it be done only when issuerAltName is marked critical,
and RP is free to ignore issuerAltName completly when it is
marked non-critical?
  </pre>
</blockquote>
Valery,<br>
<br>
Is the question about path construction or path validation?<br>
<br>
For path construction, you are free to use whatever means you want to
try to build a certification path.<br>
<br>
For path validation, as I read X.509 and RFC 3280, the issuerAltName
and subjectAltName should NEVER be used (except checking the
subjectAltName against name constraints).<br>
<br>
In X.509, perhaps the clearest language on this subject appears in the
FPDAM Enhancements to Public-Key and Attribute Certificates
(<a class="moz-txt-link-freetext" href="ftp://ftp.bull.com/pub/OSIdirectory/Orlando2004Output/6N12793CertificateEnhancementDAM.pdf">ftp://ftp.bull.com/pub/OSIdirectory/Orlando2004Output/6N12793CertificateEnhancementDAM.pdf</a>):<br>
<blockquote>
  <h4>7 Public-keys and public-key certificates</h4>
  <i>Add the following at the beginning of the paragraph that currently
begins with &#8220;A certification path logically<br>
forms an unbroken chain &#8230;&#8221;</i>.<br>
  <p>The <b>issuer</b> and <b>subject</b> fields of each certificate
are used, in part, to identify a valid path.&nbsp; For each pair of adjacent
certificates in a valid certification path, the value of the <b>subject</b>
field in one certificate shall match the value of the <b>issuer</b>
field in the subsequent certificate.&nbsp; In addition, the value of the <b>issuer</b>
field in the first certificate shall match the DN of the trust anchor.&nbsp;
Only the names in these fields are used when checking validity of a
certification path.&nbsp; Names in certificate extensions are not used for
this purpose.</p>
</blockquote>
I could not find any text in the 4th edition of X.509 that is this
clear, but the path validation algorithm in clause 10 simply imposes
the requirement:<br>
<meta http-equiv="CONTENT-TYPE" content="text/html; charset=utf-8">
<title>ITU-T Rec. X.509 (03/2000) Information technology &#8211; Open system</title>
<meta name="GENERATOR" content="OpenOffice.org 1.1.3  (Linux)">
<meta name="AUTHOR" content="SB">
<meta name="CREATED" content="20030703;10040000">
<meta name="CHANGEDBY" content="SB">
<meta name="CHANGED" content="20030710;10030000">
<meta name="CLASSIFICATION"
 content="SERIES X: DATA NETWORKS AND OPEN SYSTEM COMMUNICATIONS -">
<meta name="DESCRIPTION"
 content="Saisie  KJ
Corr. BAT  17.4.01/KJ
Corr. 2e BAT  4.5.01/KJ
Ultimes   7.5.01/KJ
Ultime mail Mme Zenobi (7.5)
Corr. apr&egrave;s ultimes  22.5.01/KJ">
<meta name="KEYWORDS" content="X.509,X,509">
<style>
	<!--
		@page { size: 8.27in 11.69in; margin: 0.79in }
		P { margin-bottom: 0.08in }
	-->
	</style>
<blockquote>a) Check that the signature verifies, that dates are valid,
that the
certificate subject and certificate issuer names chain correctly, and
that the certificate has not been revoked.<br>
</blockquote>
I believe that this text was intended to mean that only the names in
the issuer and subject fields are compared and not the names in the
alternative name extensions.<br>
<br>
In RFC 3280, comparisons of issuer and subject names in consecutive
certificates is addressed in section 6 through the use of the
working_issuer_name variable.&nbsp;&nbsp; The working_issuer_name is defined as
"the issuer distinguished name expected in the next certificate in the
chain", it is set to the subject name from each certificate and
compared against the issuer name in each certificate.&nbsp; As with X.509, I
read this language to mean that only the issuer and subject fields are
compared and not the alternative names.<br>
<br>
Dave<br>
<br>
</body>
</html>

--------------050203050001010705030605--

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 j6E8kmhU025468; Thu, 14 Jul 2005 01:46: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 j6E8kmHd025467; Thu, 14 Jul 2005 01:46:48 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from pc-p1-informatica.org (69.Red-213-97-128.pooles.rima-tde.net [213.97.128.69]) by above.proper.com (8.12.11/8.12.9) with SMTP id j6E8kk9M025402 for <ietf-pkix@imc.org>; Thu, 14 Jul 2005 01:46:47 -0700 (PDT) (envelope-from wpolk@nist.gov)
Date: Thu, 14 Jul 2005 09:45:53 +0000
To: "Ietf-pkix" <ietf-pkix@imc.org>
From: "Wpolk" <wpolk@nist.gov>
Subject: Re:
Message-ID: <axlknqyhmlfnhedodgp@imc.org>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="--------qybkfpdztdsybtzyehhe"
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

----------qybkfpdztdsybtzyehhe
Content-Type: text/plain; charset="UTF-8"; format="flowed"

+----------------------------------------------------+

Panda GateDefender has detected malicious content (Virus) in the following file: [Dog.cpl]
W32/Bagle.AH.worm

The file has been deleted to protect the network.
07/14/2005 08:40 +0100

www.pandasoftware.com

+----------------------------------------------------+

----------qybkfpdztdsybtzyehhe
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: 7bit

<html><body>
>Animals<br>

<br>
</body></html>

----------qybkfpdztdsybtzyehhe--

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 j6E6MUuD061111; Wed, 13 Jul 2005 23: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 j6E6MU2I061108; Wed, 13 Jul 2005 23:22:30 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from relay1.synartra.com (zuka.synartra.com [212.114.5.147]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6E6MSji061085 for <ietf-pkix@imc.org>; Wed, 13 Jul 2005 23:22:29 -0700 (PDT) (envelope-from svan@synartra.com)
Received: by relay1.synartra.com (8.8.5/%I%) id KAA15984; Thu, 14 Jul 2005 10:22:56 +0400 (MSD)
Received: from svan-pc(212.114.5.100) by zuka via smap (V2.0) id xma015946; Thu, 14 Jul 05 10:22:05 +0400
Message-ID: <00a001c5883c$48cd8150$640572d4@trustworks.com>
From: "Valery Smyslov" <svan@synartra.com>
To: <ietf-pkix@imc.org>
Subject: issuerAltName and path construction
Date: Thu, 14 Jul 2005 10:21:34 +0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4942.400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4942.400
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <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,

I have probably very simple question. If certificate contains
both non-null issuer and issuerAltName extension, should
the latter take part in path construction, or not? It is clear from 
RFC3280 anf X.509 that in case certificate contains no isuuer
(null sequence), issuerAltName must be used instead for path building, 
but it is unclear what should be done if both are present and populated.

In other words, when RP tries to find an issuer for given certificate
containing both non-null issuer and issuerAltName extension, should
he/she check that not only issuer field in the certificate matches
subject field in issuer certificate, but also issuerAltName matches
subjectAltName in issuer certificate?

Or, should it be done only when issuerAltName is marked critical,
and RP is free to ignore issuerAltName completly when it is
marked non-critical?

Regards,
Valery Smyslov.

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 j6DDJuxL030530; Wed, 13 Jul 2005 06:19: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 j6DDJuSv030527; Wed, 13 Jul 2005 06:19:56 -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 j6DDJrei030474; Wed, 13 Jul 2005 06:19:54 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net)
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id PAA53450; Wed, 13 Jul 2005 15:35:40 +0200
Received: from bull.net ([129.181.81.18]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005071315203475:706 ; Wed, 13 Jul 2005 15:20:34 +0200 
Message-ID: <42D514F9.8050700@bull.net>
Date: Wed, 13 Jul 2005 15:19:53 +0200
From: Denis Pinkas <Denis.Pinkas@bull.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: S-MIME / IETF <ietf-smime@imc.org>
CC: pkix <ietf-pkix@imc.org>
Subject: CMS Advanced Electronic Signatures (CAdES)
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 13/07/2005 15:20:35, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 13/07/2005 15:20:38, Serialize complete at 13/07/2005 15:20:38
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=ISO-8859-1; 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>

To the S-MIME list,

Copy: the PKIX list.

RFC 3126 has been issued in September 2001 and its title is:

"Electronic Signature Format for long term electronic signatures"

The contents of this Informational RFC is technically equivalent
to ETSI TS 101 733 V.1.2.2.

In the mean time, ETSI TC ESI has revised this Technical Standard (TS)
and is going to publish a new version of it with a new title :

CMS Advanced Electronic Signatures (CAdES), in order to be the "brother" of
XML Advanced Electronic Signatures (XAdES), published as ETSI TS 101 903.

In order to make this document widely available, ETSI has produced
an equivalent of the revised TS using the format of a RFC.

This document is temporarily available (by a kind hosting from Paul Offman)
from:

<http://www.imc.org/ietf-smime/TEMP-draft-pinkas-smime-cades-00.txt>

until is is officially posted in the IETF repository.

The major changes are mentioned section  J :

   "The title of the document has changed to be aligned with the title
   of XAdES, the vocabulary used within the present document has been
   aligned with the vocabulary used in XAdES,

   In the previous version of TS 101 733 (i.e. version 1.5.1)
   sigPolicyHash was mandatory.  Implementations requiring to be
   backward compatible with version 1.5.1 and previous versions
   of the current document MUST include SigPolicyHash.

   The OIDs from the ASN.1 modules have changed for the following
   reasons:

    - the OIDs of the ASN.1 modules of RFC 2560 and RFC 3161 have been
      included.

    - since RFC 2459 and RFC 3369 has been obsoleted by RFC 3280 and
      RFC 3852 respectively, there was the need to refer to the OIDs
      of the ASN.1 modules of RFC 3280 and RFC 3852, instead of the
      OIDs of the ASN.1 modules of RFC 2459 and RFC 3369.

    - the other change is related to the field sigPolicyHash from
      SignaturePolicyId (see clause 5.8.1). That field was mandatory
      and is now optional."

It is proposed to progress this document within the S-MIME WG
as an Informational Standard.

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 j6DCLn0c008305; Wed, 13 Jul 2005 05:21: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 j6DCLn4Z008304; Wed, 13 Jul 2005 05:21:49 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from host15.websitesource.com (host15.websitesource.com [209.239.32.38]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6DCLmRJ008289 for <ietf-pkix@imc.org>; Wed, 13 Jul 2005 05:21:48 -0700 (PDT) (envelope-from chokhani@orionsec.com)
Received: from wchokhani3 (pcp09271453pcs.arlngt01.va.comcast.net [69.143.129.49]) by host15.websitesource.com (8.12.10/8.12.10) with ESMTP id j6DCLjqj008418 for <ietf-pkix@imc.org>; Wed, 13 Jul 2005 08:21:47 -0400
From: "Santosh Chokhani" <chokhani@orionsec.com>
To: "'pkix'" <ietf-pkix@imc.org>
Subject: RE: 3280bis: CRL validation: what is wrong and/or missing in section 6.3
Date: Wed, 13 Jul 2005 08:21:39 -0400
Message-ID: <004801c587a5$6f138130$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.2900.2180
Importance: Normal
In-Reply-To: <BF9309599A71984CAC5BAC5ECA62994402D07F06@EUR-MSG-11.europe.corp.microsoft.com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j6DCLnRJ008298
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <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 Cooper,

I do not have any objection on this if we have this as technical requirement
in 6.3 or punt in the Security Considerations section, but saying that there
is a WG consensus is mis-characterization.

-----Original Message-----
From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On
Behalf Of Stefan Santesson
Sent: Wednesday, July 13, 2005 6:32 AM
To: David A. Cooper; Denis Pinkas
Cc: pkix
Subject: RE: 3280bis: CRL validation: what is wrong and/or missing in
section 6.3

David,

I agree with your comments.

However on the following:

> Even though X.509 requires that names be unambiguous, there does seem
to
> be consensus within the PKIX WG that 3280bis should impose some 
> restrictions of the certification path used to validate a CRL in order 
> to address the concern that a name collision might occur despite
X.509's
> prohibition.  However, at the moment, WG consensus seems to be in
favor
> of only requiring that the certification path for the CRL use the same 
> trust anchor as the certification path for the corresponding CRL.
There
> is language about this in the security considerations section.  In
order
> for 3280bis to be even more restrictive, it would need to be shown
that
> there is WG consensus in favor of imposing such restrictions.

I would like to add my vote to be more restrictive than just terminating at
the same root.

I think the path processing complexity would be much simpler if the CRL
issuer certificate had to be issued by the CA that issued the target
certificate (the target CA). It would also eliminate potential name
collision problems.

Perhaps we need to also consider allowing the parent of the target CA to
issue the CRL issuer cert but I see no reason to allow the CRL issuer cert
to be issued by a CA that is not in the target cert path or by a CA higher
in the target cert path.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> -----Original Message-----
> From: owner-ietf-pkix@mail.imc.org
[mailto:owner-ietf-pkix@mail.imc.org]
> On Behalf Of David A. Cooper
> Sent: den 11 juli 2005 19:42
> To: Denis Pinkas
> Cc: pkix
> Subject: Re: 3280bis: CRL validation: what is wrong and/or missing in 
> section 6.3
> 
> 
> Denis Pinkas wrote:
> 
> >
> > 3280bis: CRL validation: what is wrong and/or missing in section
6.3.
> >
> > 1. The very first sentence states:
> >
> > " This section describes the steps necessary to determine if a
> >   certificate is revoked or on hold status when CRLs are the
revocation
> >   mechanism used by the certificate issuer".
> >
> > a) This section should describe the steps necessary to determine
> >   if the revocation status of the certification path* is : REVOKED,
> >   NOT_REVOKED or UNKNOWN, instead of simply determine if the
> >   *target certificate* is REVOKED. So the sentence is incorrect.
> 
> The algorithm in section 6.3 is used to determine the status of a 
> particular certificate, not a certification path, so the text is 
> correct.  However, as part of certification path validation, section 
> 6.1.3, step (a)(3) states that, for each certificate in the path, one 
> must verify that the certificate is not revoked or on hold, and it 
> indicates that if status is determined using CRLs that section 6.3 
> indicates how the status can be determined.
> 
> > b) The current text mentions the return of the "on hold" status.
> >   However since CRLreason is not mentioned as an output parameter
> >   of the algorithm, this may not be the case (the only algorithm
> >   output is currently the revocation status of the certificate).
> 
> The variable cert_status is output from the algorithm.  In section
6.3.3
> steps (i) and (j), the value of cert_status is set to the value from
the
> reason code CRL entry extension if the certificate is found to be 
> revoked and the reason code extension is present.
> 
> > 2. The text states: " Conforming implementations that support CRLs 
> > are not required to implement this algorithm, but they MUST be 
> > functionally equivalent to the external behavior resulting from this 
> > procedure".
> 
> If you believe that this sentence and some of text quoted below need
to
> be more precisely worded, please provide text for consideration.
> 
> > This sentence is incorrect since the algorithm would mandate the 
> > support of many certificate extensions, CRL extensions and CRL entry 
> > extensions that conforming relying party applications are NOT 
> > REQUIRED to support. The current algorithm has many errors in it 
> > cannot be easily simplified, if less than "all options" are 
> > supported by a relying party.
> >
> > 3. The text states: "This algorithm assumes that all of the needed 
> > CRLs are available in a local cache".
> >
> > This sentence is incorrect, because it may happen that the "right" 
> > or a "current" CRL is  unavailable and thus absent; in such a case 
> > the algorithm terminates with "UNDETERMINED" or "UNKNOWN".
> 
> I don't understand what you mean by incorrect, the sentence states an 
> assumption, not a fact.
> 
> > 4. The text states:
> >
> > "This algorithm begins by assuming the certificate is not revoked."
> >
> > This sentence is incorrect, the algorithm should begin by assuming 
> > the status of the certificate is "UNDETERMINED" or "UNKNOWN".
> 
> cert_status is initialized to UNREVOKED.  If the status cannot be 
> determined, cert_status gets changed to UNDETERMINED as the final
step.
> 
> > 5. The text states, [omitting what is relevant to delta CRLs]
> >
> > "(a)  Update the local CRL cache by obtaining a complete CRL [ ] :
> >
> >         (1)  If the current time is after the value of the CRL next
> >         update field, then do one of the following :
> >
> >            (i) [ ].
> >
> >            (ii)  Update the local CRL cache with a current complete
> >            CRL, verify that the current time is before the next
update
> >            value in the new CRL, [ ]".
> >
> > This is incorrect. If the "current" CRL cannot be found, then it is 
> > still possible to use an older CRL to demonstrate that the
certificate
> > was REVOKED. Of course, when using an older CRL it is not possible 
> > to demonstrate that the certificate was NOT_REVOKED.
> 
> Section 6.3 states "Further, if the next update time of a CRL has 
> passed, the algorithm assumes a mechanism to fetch a current CRL and 
> place it in the local CRL cache."  So, while the scenario you describe 
> could happen, section 6.3 states that the algorithm does not address 
> this scenario.
> 
> > 6. The current algorithm cannot make sure that an emergency CRL ( 
> > i.e. the latest captured CRL) will be used if more than one "valid" 
> > CRLs are found in the local cache.
> 
> True.  As long as untrusted mechanisms are used to distribute CRLs,
the
> relying party cannot ensure that it has the latest CRL.
> 
> > 7. The text states:
> >
> >   (f)  Obtain and validate the certification path for the complete
CRL
> >   issuer.  If a key usage extension is present in the CRL issuer's
> >   certificate, verify that the cRLSign bit is set.
> >
> >   (g)  Validate the signature on the complete CRL using the public
key
> >   validated in step (f).
> >
> > The text is unclear about what is meant by :" validate the
certification
> > path for the complete CRL issuer". In order to solve the problem of 
> > identical CRL Issuer names or identical CA names, it is needed to
say
> > that the certification path that has been used to validate the
target
> > certificate MUST also be used.
> 
> Would you like for step (f) to say that the validation should be 
> performed as specified in section 6.1 and/or section 6.2?
> 
> Even though X.509 requires that names be unambiguous, there does seem
to
> be consensus within the PKIX WG that 3280bis should impose some 
> restrictions of the certification path used to validate a CRL in order 
> to address the concern that a name collision might occur despite
X.509's
> prohibition.  However, at the moment, WG consensus seems to be in
favor
> of only requiring that the certification path for the CRL use the same 
> trust anchor as the certification path for the corresponding CRL.
There
> is language about this in the security considerations section.  In
order
> for 3280bis to be even more restrictive, it would need to be shown
that
> there is WG consensus in favor of imposing such restrictions.
> 
> > 8. There is no handling of the Certificate Issuer CRL entry
extension,
> > when present, which may lead to incorrect results.
> 
> Section 6.3.3, steps (i) and (j) refer to section 5.3.4, which
indicates
> how to process this extension.

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 j6DBoYx7097211; Wed, 13 Jul 2005 04:50: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 j6DBoYSY097210; Wed, 13 Jul 2005 04:50:34 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from host15.websitesource.com (host15.websitesource.com [209.239.32.38]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6DBoXQe097189 for <ietf-pkix@imc.org>; Wed, 13 Jul 2005 04:50:33 -0700 (PDT) (envelope-from chokhani@orionsec.com)
Received: from wchokhani3 (pcp09271453pcs.arlngt01.va.comcast.net [69.143.129.49]) by host15.websitesource.com (8.12.10/8.12.10) with ESMTP id j6DBoUqj025611 for <ietf-pkix@imc.org>; Wed, 13 Jul 2005 07:50:32 -0400
From: "Santosh Chokhani" <chokhani@orionsec.com>
To: "'pkix'" <ietf-pkix@imc.org>
Subject: RE: 3280bis: CRL validation: what is wrong and/or missing in section 6.3
Date: Wed, 13 Jul 2005 07:50:23 -0400
Message-ID: <003c01c587a1$10e4ed50$aa02a8c0@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
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Importance: Normal
In-Reply-To: <BF9309599A71984CAC5BAC5ECA62994402D07F06@EUR-MSG-11.europe.corp.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>

Stefan,

How is this different from my proposal for matching the two certification
path?

Also, this will not overly constrain indirect CRL issuer.

-----Original Message-----
From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On
Behalf Of Stefan Santesson
Sent: Wednesday, July 13, 2005 6:32 AM
To: David A. Cooper; Denis Pinkas
Cc: pkix
Subject: RE: 3280bis: CRL validation: what is wrong and/or missing in
section 6.3

David,

I agree with your comments.

However on the following:

> Even though X.509 requires that names be unambiguous, there does seem
to
> be consensus within the PKIX WG that 3280bis should impose some 
> restrictions of the certification path used to validate a CRL in order 
> to address the concern that a name collision might occur despite
X.509's
> prohibition.  However, at the moment, WG consensus seems to be in
favor
> of only requiring that the certification path for the CRL use the same 
> trust anchor as the certification path for the corresponding CRL.
There
> is language about this in the security considerations section.  In
order
> for 3280bis to be even more restrictive, it would need to be shown
that
> there is WG consensus in favor of imposing such restrictions.

I would like to add my vote to be more restrictive than just terminating at
the same root.

I think the path processing complexity would be much simpler if the CRL
issuer certificate had to be issued by the CA that issued the target
certificate (the target CA). It would also eliminate potential name
collision problems.

Perhaps we need to also consider allowing the parent of the target CA to
issue the CRL issuer cert but I see no reason to allow the CRL issuer cert
to be issued by a CA that is not in the target cert path or by a CA higher
in the target cert path.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> -----Original Message-----
> From: owner-ietf-pkix@mail.imc.org
[mailto:owner-ietf-pkix@mail.imc.org]
> On Behalf Of David A. Cooper
> Sent: den 11 juli 2005 19:42
> To: Denis Pinkas
> Cc: pkix
> Subject: Re: 3280bis: CRL validation: what is wrong and/or missing in 
> section 6.3
> 
> 
> Denis Pinkas wrote:
> 
> >
> > 3280bis: CRL validation: what is wrong and/or missing in section
6.3.
> >
> > 1. The very first sentence states:
> >
> > " This section describes the steps necessary to determine if a
> >   certificate is revoked or on hold status when CRLs are the
revocation
> >   mechanism used by the certificate issuer".
> >
> > a) This section should describe the steps necessary to determine
> >   if the revocation status of the certification path* is : REVOKED,
> >   NOT_REVOKED or UNKNOWN, instead of simply determine if the
> >   *target certificate* is REVOKED. So the sentence is incorrect.
> 
> The algorithm in section 6.3 is used to determine the status of a 
> particular certificate, not a certification path, so the text is 
> correct.  However, as part of certification path validation, section 
> 6.1.3, step (a)(3) states that, for each certificate in the path, one 
> must verify that the certificate is not revoked or on hold, and it 
> indicates that if status is determined using CRLs that section 6.3 
> indicates how the status can be determined.
> 
> > b) The current text mentions the return of the "on hold" status.
> >   However since CRLreason is not mentioned as an output parameter
> >   of the algorithm, this may not be the case (the only algorithm
> >   output is currently the revocation status of the certificate).
> 
> The variable cert_status is output from the algorithm.  In section
6.3.3
> steps (i) and (j), the value of cert_status is set to the value from
the
> reason code CRL entry extension if the certificate is found to be 
> revoked and the reason code extension is present.
> 
> > 2. The text states: " Conforming implementations that support CRLs 
> > are not required to implement this algorithm, but they MUST be 
> > functionally equivalent to the external behavior resulting from this 
> > procedure".
> 
> If you believe that this sentence and some of text quoted below need
to
> be more precisely worded, please provide text for consideration.
> 
> > This sentence is incorrect since the algorithm would mandate the 
> > support of many certificate extensions, CRL extensions and CRL entry 
> > extensions that conforming relying party applications are NOT 
> > REQUIRED to support. The current algorithm has many errors in it 
> > cannot be easily simplified, if less than "all options" are 
> > supported by a relying party.
> >
> > 3. The text states: "This algorithm assumes that all of the needed 
> > CRLs are available in a local cache".
> >
> > This sentence is incorrect, because it may happen that the "right" 
> > or a "current" CRL is  unavailable and thus absent; in such a case 
> > the algorithm terminates with "UNDETERMINED" or "UNKNOWN".
> 
> I don't understand what you mean by incorrect, the sentence states an 
> assumption, not a fact.
> 
> > 4. The text states:
> >
> > "This algorithm begins by assuming the certificate is not revoked."
> >
> > This sentence is incorrect, the algorithm should begin by assuming 
> > the status of the certificate is "UNDETERMINED" or "UNKNOWN".
> 
> cert_status is initialized to UNREVOKED.  If the status cannot be 
> determined, cert_status gets changed to UNDETERMINED as the final
step.
> 
> > 5. The text states, [omitting what is relevant to delta CRLs]
> >
> > "(a)  Update the local CRL cache by obtaining a complete CRL [ ] :
> >
> >         (1)  If the current time is after the value of the CRL next
> >         update field, then do one of the following :
> >
> >            (i) [ ].
> >
> >            (ii)  Update the local CRL cache with a current complete
> >            CRL, verify that the current time is before the next
update
> >            value in the new CRL, [ ]".
> >
> > This is incorrect. If the "current" CRL cannot be found, then it is 
> > still possible to use an older CRL to demonstrate that the
certificate
> > was REVOKED. Of course, when using an older CRL it is not possible 
> > to demonstrate that the certificate was NOT_REVOKED.
> 
> Section 6.3 states "Further, if the next update time of a CRL has 
> passed, the algorithm assumes a mechanism to fetch a current CRL and 
> place it in the local CRL cache."  So, while the scenario you describe 
> could happen, section 6.3 states that the algorithm does not address 
> this scenario.
> 
> > 6. The current algorithm cannot make sure that an emergency CRL ( 
> > i.e. the latest captured CRL) will be used if more than one "valid" 
> > CRLs are found in the local cache.
> 
> True.  As long as untrusted mechanisms are used to distribute CRLs,
the
> relying party cannot ensure that it has the latest CRL.
> 
> > 7. The text states:
> >
> >   (f)  Obtain and validate the certification path for the complete
CRL
> >   issuer.  If a key usage extension is present in the CRL issuer's
> >   certificate, verify that the cRLSign bit is set.
> >
> >   (g)  Validate the signature on the complete CRL using the public
key
> >   validated in step (f).
> >
> > The text is unclear about what is meant by :" validate the
certification
> > path for the complete CRL issuer". In order to solve the problem of 
> > identical CRL Issuer names or identical CA names, it is needed to
say
> > that the certification path that has been used to validate the
target
> > certificate MUST also be used.
> 
> Would you like for step (f) to say that the validation should be 
> performed as specified in section 6.1 and/or section 6.2?
> 
> Even though X.509 requires that names be unambiguous, there does seem
to
> be consensus within the PKIX WG that 3280bis should impose some 
> restrictions of the certification path used to validate a CRL in order 
> to address the concern that a name collision might occur despite
X.509's
> prohibition.  However, at the moment, WG consensus seems to be in
favor
> of only requiring that the certification path for the CRL use the same 
> trust anchor as the certification path for the corresponding CRL.
There
> is language about this in the security considerations section.  In
order
> for 3280bis to be even more restrictive, it would need to be shown
that
> there is WG consensus in favor of imposing such restrictions.
> 
> > 8. There is no handling of the Certificate Issuer CRL entry
extension,
> > when present, which may lead to incorrect results.
> 
> Section 6.3.3, steps (i) and (j) refer to section 5.3.4, which
indicates
> how to process this extension.

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 j6DAWavo067658; Wed, 13 Jul 2005 03:32: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 j6DAWaC8067657; Wed, 13 Jul 2005 03:32:36 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from mail-eur1.microsoft.com (mail-eur1.microsoft.com [213.199.128.139]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6DAWY23067581 for <ietf-pkix@imc.org>; Wed, 13 Jul 2005 03:32:34 -0700 (PDT) (envelope-from stefans@microsoft.com)
Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Jul 2005 11:32:28 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: 3280bis: CRL validation: what is wrong and/or missing in section 6.3
Date: Wed, 13 Jul 2005 11:32:29 +0100
Message-ID: <BF9309599A71984CAC5BAC5ECA62994402D07F06@EUR-MSG-11.europe.corp.microsoft.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: 3280bis: CRL validation: what is wrong and/or missing in section 6.3
Thread-Index: AcWGR/L5xy6zj2R2RGO9nYG1SHpzvgBTL4iQ
From: "Stefan Santesson" <stefans@microsoft.com>
To: "David A. Cooper" <david.cooper@nist.gov>, "Denis Pinkas" <Denis.Pinkas@bull.net>
Cc: "pkix" <ietf-pkix@imc.org>
X-OriginalArrivalTime: 13 Jul 2005 10:32:28.0752 (UTC) FILETIME=[2B144500:01C58796]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j6DAWZ23067649
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <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,

I agree with your comments.

However on the following:

> Even though X.509 requires that names be unambiguous, there does seem
to
> be consensus within the PKIX WG that 3280bis should impose some
> restrictions of the certification path used to validate a CRL in order
> to address the concern that a name collision might occur despite
X.509's
> prohibition.  However, at the moment, WG consensus seems to be in
favor
> of only requiring that the certification path for the CRL use the same
> trust anchor as the certification path for the corresponding CRL.
There
> is language about this in the security considerations section.  In
order
> for 3280bis to be even more restrictive, it would need to be shown
that
> there is WG consensus in favor of imposing such restrictions.

I would like to add my vote to be more restrictive than just terminating
at the same root.

I think the path processing complexity would be much simpler if the CRL
issuer certificate had to be issued by the CA that issued the target
certificate (the target CA). It would also eliminate potential name
collision problems.

Perhaps we need to also consider allowing the parent of the target CA to
issue the CRL issuer cert but I see no reason to allow the CRL issuer
cert to be issued by a CA that is not in the target cert path or by a CA
higher in the target cert path.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> -----Original Message-----
> From: owner-ietf-pkix@mail.imc.org
[mailto:owner-ietf-pkix@mail.imc.org]
> On Behalf Of David A. Cooper
> Sent: den 11 juli 2005 19:42
> To: Denis Pinkas
> Cc: pkix
> Subject: Re: 3280bis: CRL validation: what is wrong and/or missing in
> section 6.3
> 
> 
> Denis Pinkas wrote:
> 
> >
> > 3280bis: CRL validation: what is wrong and/or missing in section
6.3.
> >
> > 1. The very first sentence states:
> >
> > " This section describes the steps necessary to determine if a
> >   certificate is revoked or on hold status when CRLs are the
revocation
> >   mechanism used by the certificate issuer".
> >
> > a) This section should describe the steps necessary to determine
> >   if the revocation status of the certification path* is : REVOKED,
> >   NOT_REVOKED or UNKNOWN, instead of simply determine if the
> >   *target certificate* is REVOKED. So the sentence is incorrect.
> 
> The algorithm in section 6.3 is used to determine the status of a
> particular certificate, not a certification path, so the text is
> correct.  However, as part of certification path validation, section
> 6.1.3, step (a)(3) states that, for each certificate in the path, one
> must verify that the certificate is not revoked or on hold, and it
> indicates that if status is determined using CRLs that section 6.3
> indicates how the status can be determined.
> 
> > b) The current text mentions the return of the "on hold" status.
> >   However since CRLreason is not mentioned as an output parameter
> >   of the algorithm, this may not be the case (the only algorithm
> >   output is currently the revocation status of the certificate).
> 
> The variable cert_status is output from the algorithm.  In section
6.3.3
> steps (i) and (j), the value of cert_status is set to the value from
the
> reason code CRL entry extension if the certificate is found to be
> revoked and the reason code extension is present.
> 
> > 2. The text states: " Conforming implementations that support
> > CRLs are not required to implement this algorithm, but they MUST
> > be functionally equivalent to the external behavior resulting
> > from this procedure".
> 
> If you believe that this sentence and some of text quoted below need
to
> be more precisely worded, please provide text for consideration.
> 
> > This sentence is incorrect since the algorithm would mandate
> > the support of many certificate extensions, CRL extensions and
> > CRL entry extensions that conforming relying party applications
> > are NOT REQUIRED to support. The current algorithm has many errors
> > in it cannot be easily simplified, if less than "all options"
> > are supported by a relying party.
> >
> > 3. The text states: "This algorithm assumes that all of the needed
> > CRLs are available in a local cache".
> >
> > This sentence is incorrect, because it may happen that the "right"
> > or a "current" CRL is  unavailable and thus absent; in such a case
> > the algorithm terminates with "UNDETERMINED" or "UNKNOWN".
> 
> I don't understand what you mean by incorrect, the sentence states an
> assumption, not a fact.
> 
> > 4. The text states:
> >
> > "This algorithm begins by assuming the certificate is not revoked."
> >
> > This sentence is incorrect, the algorithm should begin by assuming
> > the status of the certificate is "UNDETERMINED" or "UNKNOWN".
> 
> cert_status is initialized to UNREVOKED.  If the status cannot be
> determined, cert_status gets changed to UNDETERMINED as the final
step.
> 
> > 5. The text states, [omitting what is relevant to delta CRLs]
> >
> > "(a)  Update the local CRL cache by obtaining a complete CRL [ ] :
> >
> >         (1)  If the current time is after the value of the CRL next
> >         update field, then do one of the following :
> >
> >            (i) [ ].
> >
> >            (ii)  Update the local CRL cache with a current complete
> >            CRL, verify that the current time is before the next
update
> >            value in the new CRL, [ ]".
> >
> > This is incorrect. If the "current" CRL cannot be found, then it is
> > still possible to use an older CRL to demonstrate that the
certificate
> > was REVOKED. Of course, when using an older CRL it is not possible
> > to demonstrate that the certificate was NOT_REVOKED.
> 
> Section 6.3 states "Further, if the next update time of a CRL has
> passed, the algorithm assumes a mechanism to fetch a current CRL and
> place it in the local CRL cache."  So, while the scenario you describe
> could happen, section 6.3 states that the algorithm does not address
> this scenario.
> 
> > 6. The current algorithm cannot make sure that an emergency CRL (
> > i.e. the latest captured CRL) will be used if more than one
> > "valid" CRLs are found in the local cache.
> 
> True.  As long as untrusted mechanisms are used to distribute CRLs,
the
> relying party cannot ensure that it has the latest CRL.
> 
> > 7. The text states:
> >
> >   (f)  Obtain and validate the certification path for the complete
CRL
> >   issuer.  If a key usage extension is present in the CRL issuer's
> >   certificate, verify that the cRLSign bit is set.
> >
> >   (g)  Validate the signature on the complete CRL using the public
key
> >   validated in step (f).
> >
> > The text is unclear about what is meant by :" validate the
certification
> > path for the complete CRL issuer". In order to solve the problem of
> > identical CRL Issuer names or identical CA names, it is needed to
say
> > that the certification path that has been used to validate the
target
> > certificate MUST also be used.
> 
> Would you like for step (f) to say that the validation should be
> performed as specified in section 6.1 and/or section 6.2?
> 
> Even though X.509 requires that names be unambiguous, there does seem
to
> be consensus within the PKIX WG that 3280bis should impose some
> restrictions of the certification path used to validate a CRL in order
> to address the concern that a name collision might occur despite
X.509's
> prohibition.  However, at the moment, WG consensus seems to be in
favor
> of only requiring that the certification path for the CRL use the same
> trust anchor as the certification path for the corresponding CRL.
There
> is language about this in the security considerations section.  In
order
> for 3280bis to be even more restrictive, it would need to be shown
that
> there is WG consensus in favor of imposing such restrictions.
> 
> > 8. There is no handling of the Certificate Issuer CRL entry
extension,
> > when present, which may lead to incorrect results.
> 
> Section 6.3.3, steps (i) and (j) refer to section 5.3.4, which
indicates
> how to process this extension.

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 j6D9IqZC036941; Wed, 13 Jul 2005 02:18: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 j6D9Iqb8036940; Wed, 13 Jul 2005 02:18:52 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from pc-p1-informatica.net (69.Red-213-97-128.pooles.rima-tde.net [213.97.128.69]) by above.proper.com (8.12.11/8.12.9) with SMTP id j6D9InDU036889 for <ietf-pkix@imc.org>; Wed, 13 Jul 2005 02:18:50 -0700 (PDT) (envelope-from wpolk@nist.gov)
Date: Wed, 13 Jul 2005 10:17:58 +0000
To: "Ietf-pkix" <ietf-pkix@imc.org>
From: "Wpolk" <wpolk@nist.gov>
Subject: Re:
Message-ID: <uedlkddmsjgxudttaea@imc.org>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="--------rdmqsgmwkkquoedgyeek"
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

----------rdmqsgmwkkquoedgyeek
Content-Type: text/plain; charset="UTF-8"; format="flowed"

+----------------------------------------------------+

Panda GateDefender has detected malicious content (Virus) in the following file: [Garry.cpl]
W32/Bagle.AH.worm

The file has been deleted to protect the network.
07/13/2005 09:12 +0100

www.pandasoftware.com

+----------------------------------------------------+

----------rdmqsgmwkkquoedgyeek
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: 7bit

<html><body>
>Animals<br>

<br>
</body></html>

----------rdmqsgmwkkquoedgyeek--

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 j6CC6X61094986; Tue, 12 Jul 2005 05:06: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 j6CC6XBt094985; Tue, 12 Jul 2005 05:06:33 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from host15.websitesource.com (host15.websitesource.com [209.239.32.38]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6CC6X6T094976 for <ietf-pkix@imc.org>; Tue, 12 Jul 2005 05:06:33 -0700 (PDT) (envelope-from chokhani@orionsec.com)
Received: from wchokhani3 (static-70-21-114-242.res.east.verizon.net [70.21.114.242]) by host15.websitesource.com (8.12.10/8.12.10) with ESMTP id j6CC6Vqj025063 for <ietf-pkix@imc.org>; Tue, 12 Jul 2005 08:06:33 -0400
From: "Santosh Chokhani" <chokhani@orionsec.com>
To: <ietf-pkix@imc.org>
Subject: 3280bis: Self Issued Certificates
Date: Tue, 12 Jul 2005 08:06:26 -0400
Message-ID: <001001c586da$24203450$9a00a8c0@hq.orionsec.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0011_01C586B8.9D0E9450"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
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>

This is a multi-part message in MIME format.

------=_NextPart_000_0011_01C586B8.9D0E9450
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

David,
=20
The Security Considerations Section should describe the problems an =
remedies
for checking the revocation status of self-issued certificates.

Santosh Chokhani=20
Orion Security Solutions, Inc.=20
1489 Chain Bridge Road, Suite 300=20
McLean, Virginia 22101=20
(703) 917-0060  Ext. 35 (voice)=20
(703) 917-0260 (Fax)=20
chokhani@orionsec.com=20
Visit our Web site=20
http://www.orionsec.com <http://www.orionsec.com/> =20

=20

------=_NextPart_000_0011_01C586B8.9D0E9450
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.2900.2668" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN=20
class=3D333090512-12072005>David,</DIV>
<DIV><SPAN=20
class=3D333090512-12072005>&nbsp;</DIV>
<DIV>The =
Security=20
Considerations Section should describe the problems an remedies for =
checking the=20
revocation status of self-issued certificates.</DIV>
Santosh =
Chokhani=20
 Orion Security =
Solutions,=20
Inc. 1489 Chain=20
Bridge Road, Suite 300 McLean, Virginia 22101 <FONT=20
face=3DArial size=3D2>(703) 917<FONT=20
face=3DArial size=3D2>-0060&nbsp; Ext. 35 (<FONT=20
face=3DArial size=3D2>voice) <SPAN=20
lang=3Den-us>(703) <FONT face=3DArial =

size=3D2>917</FONT><FONT face=3DArial size=3D2>-</FONT><FONT =
face=3DArial=20
size=3D2>0260</FONT><FONT face=3DArial size=3D2> (Fax)</FONT></SPAN> =
<BR><SPAN=20
lang=3Den-us><FONT face=3DArial =
size=3D2>chokhani@orionsec.com</FONT></SPAN> <BR><SPAN=20
lang=3Den-us><FONT face=3DArial size=3D2>Visit our Web =
site</FONT></SPAN> <BR><SPAN=20
lang=3Den-us><FONT face=3DArial size=3D2><A=20
href=3D"http://www.orionsec.com/">http://www.orionsec.com</A></FONT></SPA=
N> </P>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_0011_01C586B8.9D0E9450--

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 j6CC55oo094482; Tue, 12 Jul 2005 05:05: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 j6CC55CY094481; Tue, 12 Jul 2005 05:05:05 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from host15.websitesource.com (host15.websitesource.com [209.239.32.38]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6CC55S6094471 for <ietf-pkix@imc.org>; Tue, 12 Jul 2005 05:05:05 -0700 (PDT) (envelope-from chokhani@orionsec.com)
Received: from wchokhani3 (static-70-21-114-242.res.east.verizon.net [70.21.114.242]) by host15.websitesource.com (8.12.10/8.12.10) with ESMTP id j6CC52qj021700 for <ietf-pkix@imc.org>; Tue, 12 Jul 2005 08:05:04 -0400
From: "Santosh Chokhani" <chokhani@orionsec.com>
To: <ietf-pkix@imc.org>
Subject: RE: 3280bis: CRL validation: what is wrong and/or missing in section 6.3
Date: Tue, 12 Jul 2005 08:04:57 -0400
Message-ID: <000f01c586d9$ef452b00$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
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
In-Reply-To: <42D368CF.3080103@free.fr>
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 Cooper,

At a minimum, the cogent paragraph in the security consideration section
should be enhanced to recommend use of name constraints when cross
certifying with a CA in another PKI.

-----Original Message-----
From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On
Behalf Of Jean-Marc Desperrier
Sent: Tuesday, July 12, 2005 2:53 AM
To: ietf-pkix@imc.org
Subject: Re: 3280bis: CRL validation: what is wrong and/or missing in
section 6.3

David A. Cooper wrote:

> Even though X.509 requires that names be unambiguous, there does seem
> to be consensus within the PKIX WG that 3280bis should impose some 
> restrictions of the certification path used to validate a CRL in order 
> to address the concern that a name collision might occur despite 
> X.509's prohibition.  However, at the moment, WG consensus seems to be 
> in favor of only requiring that the certification path for the CRL use 
> the same trust anchor as the certification path for the corresponding 
> CRL.  There is language about this in the security considerations 
> section.  In order for 3280bis to be even more restrictive, it would 
> need to be shown that there is WG consensus in favor of imposing such 
> restrictions.

I support more restrictions. If you wish to be able to use 
cross-certification to interoperate with other PKI and not  multiply the 
trust anchors used, "the same trust anchor" does not mean much 
constraint at all.

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 j6C6r67m079128; Mon, 11 Jul 2005 23:53: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 j6C6r6nD079127; Mon, 11 Jul 2005 23:53:06 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from smtp-ft3.fr.colt.net (smtp-ft3.fr.colt.net [213.41.78.206]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6C6r5tQ079104 for <ietf-pkix@imc.org>; Mon, 11 Jul 2005 23:53:05 -0700 (PDT) (envelope-from jmdesp@free.fr)
Received: from [10.0.0.81] (host.104.92.68.195.rev.coltfrance.com [195.68.92.104]) by smtp-ft3.fr.colt.net with ESMTP id j6C6r3F02870 for <ietf-pkix@imc.org>; Tue, 12 Jul 2005 08:53:03 +0200
Message-ID: <42D368CF.3080103@free.fr>
Date: Tue, 12 Jul 2005 08:53:03 +0200
From: Jean-Marc Desperrier <jmdesp@free.fr>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; fr-FR; rv:1.8b2) Gecko/20050527
MIME-Version: 1.0
To: ietf-pkix@imc.org
Subject: Re: 3280bis: CRL validation: what is wrong and/or missing in section 6.3
References: <42D25881.2060908@bull.net> <42D2AF7E.7040701@nist.gov>
In-Reply-To: <42D2AF7E.7040701@nist.gov>
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>

David A. Cooper wrote:

> Even though X.509 requires that names be unambiguous, there does seem 
> to be consensus within the PKIX WG that 3280bis should impose some 
> restrictions of the certification path used to validate a CRL in order 
> to address the concern that a name collision might occur despite 
> X.509's prohibition.  However, at the moment, WG consensus seems to be 
> in favor of only requiring that the certification path for the CRL use 
> the same trust anchor as the certification path for the corresponding 
> CRL.  There is language about this in the security considerations 
> section.  In order for 3280bis to be even more restrictive, it would 
> need to be shown that there is WG consensus in favor of imposing such 
> restrictions.

I support more restrictions. If you wish to be able to use 
cross-certification to interoperate with other PKI and not  multiply the 
trust anchors used, "the same trust anchor" does not mean much 
constraint at all.

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 j6BK6VAq082837; Mon, 11 Jul 2005 13:06: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 j6BK6Vvp082836; Mon, 11 Jul 2005 13:06:31 -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 (rimp2.nist.gov [129.6.16.227]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6BK6T7C082829 for <ietf-pkix@imc.org>; Mon, 11 Jul 2005 13:06:29 -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.13.1/8.13.1) with ESMTP id j6BK6CGJ020278; Mon, 11 Jul 2005 16:06:14 -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 j6BK596v015332; Mon, 11 Jul 2005 16:05:09 -0400 (EDT)
Message-Id: <5.1.0.14.2.20050711155700.038c6ab8@email.nist.gov>
X-Sender: wpolk@email.nist.gov
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 11 Jul 2005 16:07:32 -0400
To: Sam Hartman <hartmans-ietf@mit.edu>
From: Tim Polk <tim.polk@nist.gov>
Subject: Progressing CRL AIA
Cc: ietf-pkix@imc.org, kent@bbn.com, stefans@microsoft.com, housley@vigilsec.com
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: tim.polk@nist.gov
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j6BK6T7C082830
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

Sam,

The PKIX WG has achieved rough consensus on "Authority Information Access 
CRL Extension".  This document is ready for progression; we are 
recommending progression as standards track document.

The current draft is available at

      http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-02.txt

The PROTO questionnaire and writeup for CRL AIA is appended below.

Thanks,

Tim Polk

------------------------- PROTO writeup for CRL AIA 
--------------------------------

PROTO Questionnaire and Writeup for the CRL AIA Extension

    1.a) Have the chairs personally reviewed this version of the Internet
         Draft (ID), and in particular, do they believe this ID is ready
         to forward to the IESG for publication?

The chairs have both reviewed this version of the Internet Draft and agree this
ID is ready to forward for publication.

    1.b) Has the document had adequate review from both key WG members
         and key non-WG members?  Do you have any concerns about the
         depth or breadth of the reviews that have been performed?

This document has undergone a thorough review.  Most WG members reviewed at 
least one draft of the CRL AIA specification, and many WG members repeated 
the process during WG Last Call.  The document was also reviewed by the RFC 
3280bis design team to ensure consistency with complementary 
specifications.  I have no remaining concerns about depth or breadth of 
reviews.

    1.c) Do you have concerns that the document needs more review from a
         particular (broader) perspective (e.g., security, operational
         complexity, someone familiar with AAA, etc.)?

No such concerns.

    1.d) Do you have any specific concerns/issues with this document that
         you believe the ADs and/or IESG should be aware of?  For
         example, perhaps you are uncomfortable with certain parts of the
         document, or have concerns whether there really is a need for
         it.  In any event, if your issues have been discussed in the WG
         and the WG has indicated it that it still wishes to advance the
         document, detail those concerns in the write-up.

WG discussions of this specification highlighted significant disagreements 
with respect to CRL validation.   Identifying appropriate CRLs, relying 
parties leverage names stated in the certificate of interest and the 
CRL.  Some members of the WG feel these names are potentially ambiguous, 
and that additional safeguards should be imposed by the family of PKIX 
specifications.

While these issues are important, they are not within the scope of this 
specification, and their resolution will not affect the technical
mechanisms specified in this document.  The WG has concluded that these
issues would be best addressed in RFC 3280bis.

    1.e) How solid is the WG consensus behind this document? Does it
         represent the strong concurrence of a few individuals, with
         others being silent, or does the WG as a whole understand and
         agree with it?

The WG consensus is strong  most WG members have reviewed this document
and are comfortable with the content.

    1.f) Has anyone threatened an appeal or otherwise indicated extreme
         discontent?  If so, please summarise the areas of conflict in
         separate email to the Responsible Area Director.

No.  The contentious issues have been resolved to mutual satisfaction or
deferred to the development of 3280bis.

    1.g) Have the chairs verified that the document adheres to all of the
         ID nits? (see http://www.ietf.org/ID-Checklist.html).

Yes

    1.h) Is the document split into normative and informative references?
         Are there normative references to IDs, where the IDs are not
         also ready for advancement or are otherwise in an unclear state?
         (note here that the RFC editor will not publish an RFC with
         normative references to IDs, it will delay publication until all
         such IDs are also ready for publication as RFCs.)

Yes

---------------------------------- Document Write-up 
-----------------------------------------

Technical Summary

This document updates RFC 3280 by defining the Authority Information
Access Certificate Revocation Lists (CRL) extension.  RFC 3280 [PKIX1]
provides for bottom-up discovery of certification paths through the
Authority Information Access extension.  This document defines the use
of the Authority Information Access extension in CRLs, enabling a CRL
checking application to to locate certificates that may be useful in
the construction of a valid CRL issuer certification path to an
appropriate trust anchor.

Working Group Summary

The working group had consensus to advance the draft to Proposed
Standard.

Protocol Quality

This document has been reviewed by members of the ietf-pkix@imc.org
mailing list, the RFC 3280bis design team, and by the working group chairs.

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 j6BHgIJT068271; Mon, 11 Jul 2005 10:42: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 j6BHgIUT068270; Mon, 11 Jul 2005 10:42:18 -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 (rimp2.nist.gov [129.6.16.227]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6BHgHPD068263 for <ietf-pkix@imc.org>; Mon, 11 Jul 2005 10:42:17 -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.13.1/8.13.1) with ESMTP id j6BHgA45006018; Mon, 11 Jul 2005 13:42:12 -0400
Received: from [129.6.54.72] (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id j6BHfZ6u010848; Mon, 11 Jul 2005 13:41:35 -0400 (EDT)
Message-ID: <42D2AF7E.7040701@nist.gov>
Date: Mon, 11 Jul 2005 13:42:22 -0400
From: "David A. Cooper" <david.cooper@nist.gov>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040804
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Denis Pinkas <Denis.Pinkas@bull.net>
CC: pkix <ietf-pkix@imc.org>
Subject: Re: 3280bis: CRL validation: what is wrong and/or missing in section 6.3
References: <42D25881.2060908@bull.net>
In-Reply-To: <42D25881.2060908@bull.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: david.cooper@nist.gov
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <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 Pinkas wrote:

>
> 3280bis: CRL validation: what is wrong and/or missing in section 6.3.
>
> 1. The very first sentence states:
>
> " This section describes the steps necessary to determine if a
>   certificate is revoked or on hold status when CRLs are the revocation
>   mechanism used by the certificate issuer".
>
> a) This section should describe the steps necessary to determine
>   if the revocation status of the certification path* is : REVOKED,
>   NOT_REVOKED or UNKNOWN, instead of simply determine if the
>   *target certificate* is REVOKED. So the sentence is incorrect.

The algorithm in section 6.3 is used to determine the status of a 
particular certificate, not a certification path, so the text is 
correct.  However, as part of certification path validation, section 
6.1.3, step (a)(3) states that, for each certificate in the path, one 
must verify that the certificate is not revoked or on hold, and it 
indicates that if status is determined using CRLs that section 6.3 
indicates how the status can be determined.

> b) The current text mentions the return of the "on hold" status.
>   However since CRLreason is not mentioned as an output parameter
>   of the algorithm, this may not be the case (the only algorithm
>   output is currently the revocation status of the certificate).

The variable cert_status is output from the algorithm.  In section 6.3.3 
steps (i) and (j), the value of cert_status is set to the value from the 
reason code CRL entry extension if the certificate is found to be 
revoked and the reason code extension is present.

> 2. The text states: " Conforming implementations that support
> CRLs are not required to implement this algorithm, but they MUST
> be functionally equivalent to the external behavior resulting
> from this procedure".

If you believe that this sentence and some of text quoted below need to 
be more precisely worded, please provide text for consideration.

> This sentence is incorrect since the algorithm would mandate
> the support of many certificate extensions, CRL extensions and
> CRL entry extensions that conforming relying party applications
> are NOT REQUIRED to support. The current algorithm has many errors
> in it cannot be easily simplified, if less than "all options"
> are supported by a relying party.
>
> 3. The text states: "This algorithm assumes that all of the needed
> CRLs are available in a local cache".
>
> This sentence is incorrect, because it may happen that the "right"
> or a "current" CRL is  unavailable and thus absent; in such a case
> the algorithm terminates with "UNDETERMINED" or "UNKNOWN".

I don't understand what you mean by incorrect, the sentence states an 
assumption, not a fact.

> 4. The text states:
>
> "This algorithm begins by assuming the certificate is not revoked."
>
> This sentence is incorrect, the algorithm should begin by assuming
> the status of the certificate is "UNDETERMINED" or "UNKNOWN".

cert_status is initialized to UNREVOKED.  If the status cannot be 
determined, cert_status gets changed to UNDETERMINED as the final step.

> 5. The text states, [omitting what is relevant to delta CRLs]
>
> "(a)  Update the local CRL cache by obtaining a complete CRL [ ] :
>
>         (1)  If the current time is after the value of the CRL next
>         update field, then do one of the following :
>
>            (i) [ ].
>
>            (ii)  Update the local CRL cache with a current complete
>            CRL, verify that the current time is before the next update
>            value in the new CRL, [ ]".
>
> This is incorrect. If the "current" CRL cannot be found, then it is
> still possible to use an older CRL to demonstrate that the certificate
> was REVOKED. Of course, when using an older CRL it is not possible
> to demonstrate that the certificate was NOT_REVOKED.

Section 6.3 states "Further, if the next update time of a CRL has 
passed, the algorithm assumes a mechanism to fetch a current CRL and 
place it in the local CRL cache."  So, while the scenario you describe 
could happen, section 6.3 states that the algorithm does not address 
this scenario.

> 6. The current algorithm cannot make sure that an emergency CRL (
> i.e. the latest captured CRL) will be used if more than one
> "valid" CRLs are found in the local cache.

True.  As long as untrusted mechanisms are used to distribute CRLs, the 
relying party cannot ensure that it has the latest CRL.

> 7. The text states:
>
>   (f)  Obtain and validate the certification path for the complete CRL
>   issuer.  If a key usage extension is present in the CRL issuer's
>   certificate, verify that the cRLSign bit is set.
>
>   (g)  Validate the signature on the complete CRL using the public key
>   validated in step (f).
>
> The text is unclear about what is meant by :" validate the certification
> path for the complete CRL issuer". In order to solve the problem of
> identical CRL Issuer names or identical CA names, it is needed to say
> that the certification path that has been used to validate the target
> certificate MUST also be used.

Would you like for step (f) to say that the validation should be 
performed as specified in section 6.1 and/or section 6.2?

Even though X.509 requires that names be unambiguous, there does seem to 
be consensus within the PKIX WG that 3280bis should impose some 
restrictions of the certification path used to validate a CRL in order 
to address the concern that a name collision might occur despite X.509's 
prohibition.  However, at the moment, WG consensus seems to be in favor 
of only requiring that the certification path for the CRL use the same 
trust anchor as the certification path for the corresponding CRL.  There 
is language about this in the security considerations section.  In order 
for 3280bis to be even more restrictive, it would need to be shown that 
there is WG consensus in favor of imposing such restrictions.

> 8. There is no handling of the Certificate Issuer CRL entry extension,
> when present, which may lead to incorrect results.

Section 6.3.3, steps (i) and (j) refer to section 5.3.4, which indicates 
how to process this extension.

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 j6BFuCmk058698; Mon, 11 Jul 2005 08:56: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 j6BFuCoG058697; Mon, 11 Jul 2005 08:56:12 -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 (rimp2.nist.gov [129.6.16.227]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6BFuBqo058690 for <ietf-pkix@imc.org>; Mon, 11 Jul 2005 08:56:11 -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.13.1/8.13.1) with ESMTP id j6BFu9be009774 for <ietf-pkix@imc.org>; Mon, 11 Jul 2005 11:56:09 -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 j6BFtC6v019555 for <ietf-pkix@imc.org>; Mon, 11 Jul 2005 11:55:13 -0400 (EDT)
Message-Id: <5.1.0.14.2.20050711114310.035421e0@email.nist.gov>
X-Sender: wpolk@email.nist.gov
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 11 Jul 2005 11:57:49 -0400
To: ietf-pkix@imc.org
From: Tim Polk <tim.polk@nist.gov>
Subject: Agenda requests for Paris
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-NIST-MailScanner: Found to be clean
X-NIST-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>

Folks,

I will be putting together a rough draft of the agenda for the PKIX session 
at Paris this week.  The agenda cannot be finalized until our time slot is 
set, but I would like to give everyone a *little* warning on which 
documents/topics will be addressed.

If you would like a time slot on the agenda, please send me an email.  I 
would appreciate it if you included a sentence or two describing the topic 
and the desired length of time.  I will accommodate as many requests as 
possible.  As always, presentations specific to our WG documents will 
receive preferential treatment.  Liaison presentations of interest to the 
WG will be included if time allows.

Thanks,

Tim Polk 

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 j6BFSM4a056073; Mon, 11 Jul 2005 08:28: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 j6BFSMuO056072; Mon, 11 Jul 2005 08:28:22 -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 (rimp2.nist.gov [129.6.16.227]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6BFSI1e056061 for <ietf-pkix@imc.org>; Mon, 11 Jul 2005 08:28:19 -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.13.1/8.13.1) with ESMTP id j6BFS9cY025857; Mon, 11 Jul 2005 11:28:11 -0400
Received: from [129.6.54.72] (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id j6BFRs6u007385; Mon, 11 Jul 2005 11:27:54 -0400 (EDT)
Message-ID: <42D29029.8030706@nist.gov>
Date: Mon, 11 Jul 2005 11:28:41 -0400
From: "David A. Cooper" <david.cooper@nist.gov>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040804
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Denis Pinkas <Denis.Pinkas@bull.net>
CC: pkix <ietf-pkix@imc.org>
Subject: Re: 3280bis: CRL validation: treatment of critical CRL entry extensions
References: <42D258FC.5090108@bull.net>
In-Reply-To: <42D258FC.5090108@bull.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: david.cooper@nist.gov
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <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 Pinkas wrote:

>
> 3280bis: CRL validation: treatment of critical CRL entry extensions
>
> RFC 3280 states on page 60 :
>
> " 5.3  CRL Entry Extensions
>
>   [...]
>
>   All CRL entry extensions used in this specification are non-critical."

Already changed in 3280bis-00.

> CRL entry extensions did not existed originally in CRL version v1 and 
> could
> be ignored when parsing a CRL. When introducing CRL entry extensions, the
> idea was the following: if a given CRL entry is found to be "appropriate"
> THEN and only THEN there is the need to make sure that it contains no
> critical CRL entry extension that is not understood. If it does then the
> CRL entry MUST be considered as invalid.

Yes.  There is a sentence in clause 7.3 of X.509 that states something 
to this effect, but the rule was violated with the certificateIssuer 
extension.  We have submitted a defect report, DR 311 
(ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DefectReports/X.509andRelated/DR_311.pdf), 
to have this sentence removed from X.509.

> This problem was however addressed by RFC 3280 since RFC 3280
> states on page 59:
>
> "The CRL issuer MUST assert the indirectCRL boolean, if the scope of
> the CRL includes certificates issued by authorities other than the
> CRL issuer.  The authority responsible for each entry is indicated
> by the certificate issuer CRL entry extension (section 5.3.4)".
>
> These two sentences are within the same paragraph, just one after
> the other.
>
> In the first sentence, the plural is used for "authorities" and thus
> the first sentence is NOT written as follows : "The CRL issuer MUST
> assert the indirectCRL boolean, if the scope of the CRL includes
> certificates issued by *an authority* other than the CRL issuer".

As has been stated many times, the indirectCRL boolean is asserted if 
the scope of the CRL includes one or more certificates  for which the 
issuer field in the certificate is different from the issuer field in 
the CRL.  We cannot change that.  However, if the use of the term 
"authorities" is truly causing confusion, we can change that.  How about:

      If the scope of the CRL only includes certificates issued by the CRL
      issuer then the indirectCRL boolean MUST be set to FALSE.  Otherwise,
      if the scope of the CRL includes certificates issued by one or more
      authorities other than the CRL issuer, the indirectCRL boolean MUST
      be set to TRUE.  The authority responsible for each entry is
      indicated by the certificate issuer CRL entry extension (section
      5.3.4).

> These sentences indicate that, if the indirectCRL boolean is set to
> TRUE, then one or more certificate issuer CRL entry extensions are
> present.

While this is usually the case, is not may always be.   The indirectCRL 
boolean is set to TRUE if the SCOPE of the CRL includes certificates 
issued by an authority (or authorities) other than the CRL issuer, but 
it may be that none of these certificates have been revoked.

If no certificates within the scope of the CRL have been revoked, then 
revokedCertificates will be absent, but the indirectCRL could still be 
asserted.  Similarly, if the only revoked certificates within the scope 
of the CRL are certificates issued by the CRL issuer, then the 
certificateIssuer CRL entry extension does not need to appear in any of 
the CRL entries since  section 5.3.4 states:

      If [the certificate issuer] extension is not present on the first 
entry in an
      indirect CRL, the certificate issuer defaults to the CRL issuer.  On
      subsequent entries in an indirect CRL, if this extension is not 
present,
      the certificate issuer for the entry is the same as that for the 
preceding entry.

If the certificateIssuer CRL entry extension is not included in any of 
the CRL entries, then the certificate issuer associated with each entry 
will be the issuer of the CRL.  So, if all revoked certificates were 
issued by the issuer of the CRL, then the certificateIssuer CRL entry 
extension does not need to be included in any CRL entries even if the 
scope of the CRL includes certificates that were not issued by the 
issuer of the CRL.

> BTW, there is a typo error where "indirectCRL" is typed
> "indrectCRL".

Fixed.

> Note that the current text in section 6.3.3 from RFC 3280 does not
> handle the Certificate Issuer CRL entry extension, when present,
> which may lead to incorrect results.

In section 6.3.3, steps (i) and (j) refer to section 5.3.4.  Section 
5.3.4 specifies how to determine the certificate issuer associated with 
each entry in the CRL.

> When the DP includes the cRLIssuer field, verifying that *one value*
> from the issuer field in the complete CRL matches cRLIssuer in the
> DP is both necessary and sufficient.
>
> There is no need to have the following insertion :
>
>                                                      " and that
>         the complete CRL contains an issuing distribution point
>         extension with the indirectCRL boolean asserted ".

This step is a necessary part of determining whether the certificate is 
included in the scope of the CRL.  If the indirectCRL boolean is not 
asserted then the CRL does not cover any certificates for which the 
issuer name in the certificate is different from the issuer name in the 
CRL.  So, if you are using a CRL to determine the status of a 
certificate, and the issuer names are not the same, you must verify that 
indirectCRL boolean is asserted in the CRL in addition to verifying that 
the CRL issuer's name appears in the cRLIssuer field in the description 
of the distribution point in the certificate.

Dave

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 j6BEbIZR051367; Mon, 11 Jul 2005 07:37: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 j6BEbIib051366; Mon, 11 Jul 2005 07:37:18 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from host15.websitesource.com (host15.websitesource.com [209.239.32.38]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6BEbHks051357 for <ietf-pkix@imc.org>; Mon, 11 Jul 2005 07:37:18 -0700 (PDT) (envelope-from chokhani@orionsec.com)
Received: from wchokhani3 (static-70-21-114-242.res.east.verizon.net [70.21.114.242]) by host15.websitesource.com (8.12.10/8.12.10) with ESMTP id j6BEbFM1001533 for <ietf-pkix@imc.org>; Mon, 11 Jul 2005 10:37:17 -0400
From: "Santosh Chokhani" <chokhani@orionsec.com>
To: "'pkix'" <ietf-pkix@imc.org>
Subject: RE: 3280bis: CRL validation: treatment of critical CRL entry extensions
Date: Mon, 11 Jul 2005 10:37:09 -0400
Message-ID: <004f01c58626$07ffefe0$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
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
In-Reply-To: <42D258FC.5090108@bull.net>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j6BEbIks051361
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <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,

Please see responses in-line under [Santosh:]

-----Original Message-----
From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On
Behalf Of Denis Pinkas
Sent: Monday, July 11, 2005 7:33 AM
To: pkix
Subject: 3280bis: CRL validation: treatment of critical CRL entry extensions

3280bis: CRL validation: treatment of critical CRL entry extensions

RFC 3280 states on page 60 :

" 5.3  CRL Entry Extensions

   [...]

   All CRL entry extensions used in this specification are non-critical."

This is however untrue since RFC 3280 states on page 62 :

" 5.3.4  Certificate Issuer

   This CRL entry extension identifies the certificate issuer associated
   with an entry in [...] a CRL that has the indirectCRL indicator set
   in its issuing distribution point extension.

[...]

   If used by conforming CRL issuers, this extension MUST always be
   critical."

The text is unclear about what to do with a critical CRL entry extension
that is not recognized, and thus this needs to be clarified.

CRL entry extensions did not existed originally in CRL version v1 and could
be ignored when parsing a CRL. When introducing CRL entry extensions, the
idea was the following: if a given CRL entry is found to be "appropriate"
THEN and only THEN there is the need to make sure that it contains no
critical CRL entry extension that is not understood. If it does then the CRL
entry MUST be considered as invalid.

The problem is that, later on, a specific critical CRL entry extension has
been introduced: the Certificate Issuer CRL entry extension. That CRL entry
extension is very special since its presence in a CRL entry extension
earlier in the list of CRL entries modifies the meaning the CRL entry, even
if it does not contain a CRL entry extension.

This problem was however addressed by RFC 3280 since RFC 3280 states on page
59:

"The CRL issuer MUST assert the indirectCRL boolean, if the scope of the CRL
includes certificates issued by authorities other than the CRL issuer.  The
authority responsible for each entry is indicated by the certificate issuer
CRL entry extension (section 5.3.4)".

These two sentences are within the same paragraph, just one after the other.

In the first sentence, the plural is used for "authorities" and thus the
first sentence is NOT written as follows : "The CRL issuer MUST assert the
indirectCRL boolean, if the scope of the CRL includes certificates issued by
*an authority* other than the CRL issuer".

The two sentences from page 59 from RFC 3280 would need to be corrected in
the following way:

"The CRL issuer MUST assert the indirectCRL boolean, if the scope of the CRL
includes certificates issued by *more than one certificate issuer*. In such
a case, the certificate issuer responsible for each entry is indicated by
the certificate issuer CRL entry extension (section 5.3.4)".

[Santosh: Denis has incorrect understanding of how indirect CRLs work.
First, the standard permits an indirect CRL issuer cover certificates issued
by a single CA.  Second, the second sentence above is worded such that it
could be misinterpreted to mean that each entry needs to assert the
certificate issuer.  That also is not true.]

These sentences indicate that, if the indirectCRL boolean is set to TRUE,
then one or more certificate issuer CRL entry extensions are present.

[Santosh: This statement is also incorrect.  Let us say that an indirect CRL
covers 1 or more CAs other than itself.  If none of the certificates issued
by those other CAs are revoked, none of the CRL entries will have the
certificate issuer present.]

This also means that if the IDP extension is not present or if the
indirectCRL boolean is set to FALSE, then no certificate issuer CRL entry
extension is present.

[Santosh: This is true.]

The indirectCRL boolean indicates the presence or absence of certificate
issuer CRL entry extensions in the CRL.

[Santosh: This is poorly worded.  If the indirect CRL flag is set,
certificate issuer extension may be present, but need not be present.  It is
also not clear why relying parties will care for many of the assertions made
by Denis.  We have a well-defined state machine for CRL and indirect CRL
processing.  It is best that the relying parties implement that and not add
other rules to make their software more complex.  For example, a somewhat
related problem I am uncovering is that some relying party software that
process extensions such as "inhibit any policy" are checking the criticality
of the extension.  Of course, that is useless.]

It allows to perform an efficient checking of the CRL entries :

 -    If the indirectCRL boolean is set to TRUE, then the CRL entry
      extensions from previous CRL entries MUST be checked to verify
      whether a certificate issuer CRL entry extension is present.

[Santosh: A proper way to process an indirect CRL is to apply the
certificate issuer state machine for the indirect CRL and it requires you to
process the entries in sequence]  

-     If the IDP extension is not present or if the indirectCRL boolean
      is set to FALSE, then CRL entry extensions from every CRL entry
      can ignored or skipped.

[Santosh: Again, assuming not using some the entry ordering extensions, you
need to go through all the entries and match the serial number.]

The core of the issue is about the following paragraph in section 6.3.3 on
page 84 :

      (1)  If the DP includes cRLIssuer, then verify that the issuer
      field in the complete CRL matches cRLIssuer in the DP and that
      the complete CRL contains an issuing distribution point
      extension with the indrectCRL boolean asserted.  Otherwise,
      verify that the CRL issuer matches the certificate issuer.

[Santosh: The above statement in 3280 is correct]

BTW, there is a typo error where "indirectCRL" is typed "indrectCRL".

Note that the current text in section 6.3.3 from RFC 3280 does not handle
the Certificate Issuer CRL entry extension, when present, which may lead to
incorrect results.

When the DP includes the cRLIssuer field, verifying that *one value* from
the issuer field in the complete CRL matches cRLIssuer in the DP is both
necessary and sufficient.

[Santosh: You also want to make sure that the CRL is indirect CRL since the
crlIssuer in the CRL DP in certificate implies that the CRL issuer is some
one other than certificate issuer.  Please see section 4.2.1.14 of RFC 3280]

There is no need to have the following insertion :

                                                      " and that
         the complete CRL contains an issuing distribution point
         extension with the indirectCRL boolean asserted ".

[Santosh: See my previous comment.]
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 j6BD05ce028780; Mon, 11 Jul 2005 06:00: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 j6BD05AX028779; Mon, 11 Jul 2005 06:00:05 -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 j6BD01kq028721 for <ietf-pkix@imc.org>; Mon, 11 Jul 2005 06:00:01 -0700 (PDT) (envelope-from stefans@microsoft.com)
Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Jul 2005 13:59:55 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: 3280bis: CRL validation: treatment of critical CRL entry extensions
Date: Mon, 11 Jul 2005 13:59:54 +0100
Message-ID: <BF9309599A71984CAC5BAC5ECA62994402CBE7B3@EUR-MSG-11.europe.corp.microsoft.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: 3280bis: CRL validation: treatment of critical CRL entry extensions
Thread-Index: AcWGFd4LlMk1RmbDQ8ikBBrrepJqwQAAVvXQ
From: "Stefan Santesson" <stefans@microsoft.com>
To: "Denis Pinkas" <Denis.Pinkas@bull.net>, "pkix" <ietf-pkix@imc.org>
X-OriginalArrivalTime: 11 Jul 2005 12:59:55.0049 (UTC) FILETIME=[6F0E9190:01C58618]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j6BD02kq028760
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <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,

Regarding criticality, the text is already changed in RFC 3280bis. It
would be useful if you could comment on the proposed resolution in RFC
3280bis instead.

The following is however false as David has pointed out in previous
mail:

<snip>
> The two sentences from page 59 from RFC 3280 would need to be
> corrected in the following way:
> 
> "The CRL issuer MUST assert the indirectCRL boolean, if the scope of
> the CRL includes certificates issued by *more than one certificate
> issuer*. In such a case, the certificate issuer responsible for each
> entry is indicated by the certificate issuer CRL entry extension
> (section 5.3.4)".

Following your text proposal I would not have to set the indirectCRL
Boolean in an indirect CRL if the scope of the CRL serves certificates
from only 1 CA. An indirect CRL may however (in most cases) be setup
this way. 

The current text is correct, yours is not.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> -----Original Message-----
> From: owner-ietf-pkix@mail.imc.org
[mailto:owner-ietf-pkix@mail.imc.org]
> On Behalf Of Denis Pinkas
> Sent: den 11 juli 2005 13:33
> To: pkix
> Subject: 3280bis: CRL validation: treatment of critical CRL entry
> extensions
> 
> 
> 3280bis: CRL validation: treatment of critical CRL entry extensions
> 
> RFC 3280 states on page 60 :
> 
> " 5.3  CRL Entry Extensions
> 
>    [...]
> 
>    All CRL entry extensions used in this specification are
non-critical."
> 
> This is however untrue since RFC 3280 states on page 62 :
> 
> " 5.3.4  Certificate Issuer
> 
>    This CRL entry extension identifies the certificate issuer
associated
>    with an entry in [...] a CRL that has the indirectCRL indicator set
>    in its issuing distribution point extension.
> 
> [...]
> 
>    If used by conforming CRL issuers, this extension MUST always be
>    critical."
> 
> The text is unclear about what to do with a critical CRL entry
extension
> that is not recognized, and thus this needs to be clarified.
> 
> CRL entry extensions did not existed originally in CRL version v1 and
> could
> be ignored when parsing a CRL. When introducing CRL entry extensions,
the
> idea was the following: if a given CRL entry is found to be
"appropriate"
> THEN and only THEN there is the need to make sure that it contains no
> critical CRL entry extension that is not understood. If it does then
the
> CRL entry MUST be considered as invalid.
> 
> The problem is that, later on, a specific critical CRL entry extension
has
> been introduced: the Certificate Issuer CRL entry extension. That CRL
> entry
> extension is very special since its presence in a CRL entry extension
> earlier in the list of CRL entries modifies the meaning the CRL entry,
> even if it does not contain a CRL entry extension.
> 
> This problem was however addressed by RFC 3280 since RFC 3280
> states on page 59:
> 
> "The CRL issuer MUST assert the indirectCRL boolean, if the scope of
> the CRL includes certificates issued by authorities other than the
> CRL issuer.  The authority responsible for each entry is indicated
> by the certificate issuer CRL entry extension (section 5.3.4)".
> 
> These two sentences are within the same paragraph, just one after
> the other.
> 
> In the first sentence, the plural is used for "authorities" and thus
> the first sentence is NOT written as follows : "The CRL issuer MUST
> assert the indirectCRL boolean, if the scope of the CRL includes
> certificates issued by *an authority* other than the CRL issuer".
> 
> The two sentences from page 59 from RFC 3280 would need to be
> corrected in the following way:
> 
> "The CRL issuer MUST assert the indirectCRL boolean, if the scope of
> the CRL includes certificates issued by *more than one certificate
> issuer*. In such a case, the certificate issuer responsible for each
> entry is indicated by the certificate issuer CRL entry extension
> (section 5.3.4)".
> 
> These sentences indicate that, if the indirectCRL boolean is set to
> TRUE, then one or more certificate issuer CRL entry extensions are
> present.
> 
> This also means that if the IDP extension is not present or if the
> indirectCRL boolean is set to FALSE, then no certificate issuer CRL
> entry extension is present.
> 
> The indirectCRL boolean indicates the presence or absence of
> certificate issuer CRL entry extensions in the CRL.
> 
> It allows to perform an efficient checking of the CRL entries :
> 
>  -    If the indirectCRL boolean is set to TRUE, then the CRL entry
>       extensions from previous CRL entries MUST be checked to verify
>       whether a certificate issuer CRL entry extension is present.
> 
> -     If the IDP extension is not present or if the indirectCRL
boolean
>       is set to FALSE, then CRL entry extensions from every CRL entry
>       can ignored or skipped.
> 
> The core of the issue is about the following paragraph in section
> 6.3.3 on page 84 :
> 
>       (1)  If the DP includes cRLIssuer, then verify that the issuer
>       field in the complete CRL matches cRLIssuer in the DP and that
>       the complete CRL contains an issuing distribution point
>       extension with the indrectCRL boolean asserted.  Otherwise,
>       verify that the CRL issuer matches the certificate issuer.
> 
> BTW, there is a typo error where "indirectCRL" is typed
> "indrectCRL".
> 
> Note that the current text in section 6.3.3 from RFC 3280 does not
> handle the Certificate Issuer CRL entry extension, when present,
> which may lead to incorrect results.
> 
> When the DP includes the cRLIssuer field, verifying that *one value*
> from the issuer field in the complete CRL matches cRLIssuer in the
> DP is both necessary and sufficient.
> 
> There is no need to have the following insertion :
> 
>                                                       " and that
>          the complete CRL contains an issuing distribution point
>          extension with the indirectCRL boolean asserted ".
> 
> 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 j6BCM4Lq014072; Mon, 11 Jul 2005 05:22: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 j6BCM4J8014071; Mon, 11 Jul 2005 05:22:04 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from laptipost.office.certipost.be (fw.certipost.be [81.246.20.164] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6BCM2mu014009 for <ietf-pkix@imc.org>; Mon, 11 Jul 2005 05:22:03 -0700 (PDT) (envelope-from marc.jadoul@swing.be)
Received: from laptipost.office.certipost.be (localhost.localdomain [127.0.0.1]) by laptipost.office.certipost.be (8.13.4/8.13.4) with ESMTP id j6BCLEXP008469; Mon, 11 Jul 2005 14:21:45 +0200
Received: (from mgjadoul@localhost) by local_1_35 (8.13.1/8.13.1/Submit) id j1II3HXu006581; Fri, 18 Feb 2005 19:03:17 +0100
Date: Fri, 18 Feb 2005 19:03:17 +0100
From: marc.jadoul@swing.be
Message-Id: <200502181803.j1II3HXu006581@local_1_35>
X-Authentication-Warning: local_1_35: mgjadoul set sender to marc.jadoul@swing.be using -f
Subject: RE: PKIX implications of SHA-1 collisions
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

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 j6BCM1tr014041; Mon, 11 Jul 2005 05:22: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 j6BCM0mR014034; Mon, 11 Jul 2005 05:22:00 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from laptipost.office.certipost.be (fw.certipost.be [81.246.20.164] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6BCLwsA013980 for <ietf-pkix@imc.org>; Mon, 11 Jul 2005 05:21:59 -0700 (PDT) (envelope-from marc.jadoul@swing.be)
Received: from laptipost.office.certipost.be (localhost.localdomain [127.0.0.1]) by laptipost.office.certipost.be (8.13.4/8.13.4) with ESMTP id j6BCLEXR008469; Mon, 11 Jul 2005 14:21:45 +0200
Received: (from mgjadoul@localhost) by local_1_35 (8.13.1/8.13.1/Submit) id j1IIUUFj006765; Fri, 18 Feb 2005 19:30:30 +0100
Date: Fri, 18 Feb 2005 19:30:30 +0100
From: marc.jadoul@swing.be
Message-Id: <200502181830.j1IIUUFj006765@local_1_35>
X-Authentication-Warning: local_1_35: mgjadoul set sender to marc.jadoul@swing.be using -f
Subject: RE: PKIX implications of SHA-1 collisions
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

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 j6BCM1gf014053; Mon, 11 Jul 2005 05:22: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 j6BCM1Vs014052; Mon, 11 Jul 2005 05:22:01 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from laptipost.office.certipost.be (fw.certipost.be [81.246.20.164] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6BCM0SX013992 for <ietf-pkix@imc.org>; Mon, 11 Jul 2005 05:22:00 -0700 (PDT) (envelope-from marc.jadoul@swing.be)
Received: from laptipost.office.certipost.be (localhost.localdomain [127.0.0.1]) by laptipost.office.certipost.be (8.13.4/8.13.4) with ESMTP id j6BCLEXN008469; Mon, 11 Jul 2005 14:21:45 +0200
Received: (from mgjadoul@localhost) by local_1_35 (8.13.1/8.13.1/Submit) id j1IIExTX006742; Fri, 18 Feb 2005 19:14:59 +0100
Date: Fri, 18 Feb 2005 19:14:59 +0100
From: marc.jadoul@swing.be
Message-Id: <200502181814.j1IIExTX006742@local_1_35>
X-Authentication-Warning: local_1_35: mgjadoul set sender to marc.jadoul@swing.be using -f
Subject: RE: PKIX implications of SHA-1 collisions
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

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 j6BCM1G2014042; Mon, 11 Jul 2005 05:22: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 j6BCM1fX014040; Mon, 11 Jul 2005 05:22:01 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from laptipost.office.certipost.be (fw.certipost.be [81.246.20.164] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6BCLxtZ013988 for <ietf-pkix@imc.org>; Mon, 11 Jul 2005 05:22:00 -0700 (PDT) (envelope-from marc.jadoul@swing.be)
Received: from laptipost.office.certipost.be (localhost.localdomain [127.0.0.1]) by laptipost.office.certipost.be (8.13.4/8.13.4) with ESMTP id j6BCLEXL008469; Mon, 11 Jul 2005 14:21:45 +0200
Received: (from mgjadoul@localhost) by local_1_35 (8.13.1/8.13.1/Submit) id j1IHfKLP006544; Fri, 18 Feb 2005 18:41:20 +0100
Date: Fri, 18 Feb 2005 18:41:20 +0100
From: marc.jadoul@swing.be
Message-Id: <200502181741.j1IHfKLP006544@local_1_35>
X-Authentication-Warning: local_1_35: mgjadoul set sender to marc.jadoul@swing.be using -f
Subject: RE: PKIX implications of SHA-1 collisions
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

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 j6BBXNB9096912; Mon, 11 Jul 2005 04:33: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 j6BBXNVD096911; Mon, 11 Jul 2005 04:33:23 -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 j6BBXLAK096875 for <ietf-pkix@imc.org>; Mon, 11 Jul 2005 04:33:22 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net)
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id NAA26440 for <ietf-pkix@imc.org>; Mon, 11 Jul 2005 13:49:07 +0200
Received: from bull.net ([129.181.81.64]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005071113335930:4077 ; Mon, 11 Jul 2005 13:33:59 +0200 
Message-ID: <42D258FC.5090108@bull.net>
Date: Mon, 11 Jul 2005 13:33:16 +0200
From: Denis Pinkas <Denis.Pinkas@bull.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: pkix <ietf-pkix@imc.org>
Subject: 3280bis: CRL validation: treatment of critical CRL entry extensions
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 07/11/2005 01:34:00 PM, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 07/11/2005 01:34:02 PM, Serialize complete at 07/11/2005 01:34:02 PM
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=ISO-8859-1; 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>

3280bis: CRL validation: treatment of critical CRL entry extensions

RFC 3280 states on page 60 :

" 5.3  CRL Entry Extensions

   [...]

   All CRL entry extensions used in this specification are non-critical."

This is however untrue since RFC 3280 states on page 62 :

" 5.3.4  Certificate Issuer

   This CRL entry extension identifies the certificate issuer associated
   with an entry in [...] a CRL that has the indirectCRL indicator set
   in its issuing distribution point extension.

[...]

   If used by conforming CRL issuers, this extension MUST always be
   critical."

The text is unclear about what to do with a critical CRL entry extension
that is not recognized, and thus this needs to be clarified.

CRL entry extensions did not existed originally in CRL version v1 and could
be ignored when parsing a CRL. When introducing CRL entry extensions, the
idea was the following: if a given CRL entry is found to be "appropriate"
THEN and only THEN there is the need to make sure that it contains no
critical CRL entry extension that is not understood. If it does then the
CRL entry MUST be considered as invalid.

The problem is that, later on, a specific critical CRL entry extension has
been introduced: the Certificate Issuer CRL entry extension. That CRL entry
extension is very special since its presence in a CRL entry extension
earlier in the list of CRL entries modifies the meaning the CRL entry,
even if it does not contain a CRL entry extension.

This problem was however addressed by RFC 3280 since RFC 3280
states on page 59:

"The CRL issuer MUST assert the indirectCRL boolean, if the scope of
the CRL includes certificates issued by authorities other than the
CRL issuer.  The authority responsible for each entry is indicated
by the certificate issuer CRL entry extension (section 5.3.4)".

These two sentences are within the same paragraph, just one after
the other.

In the first sentence, the plural is used for "authorities" and thus
the first sentence is NOT written as follows : "The CRL issuer MUST
assert the indirectCRL boolean, if the scope of the CRL includes
certificates issued by *an authority* other than the CRL issuer".

The two sentences from page 59 from RFC 3280 would need to be
corrected in the following way:

"The CRL issuer MUST assert the indirectCRL boolean, if the scope of
the CRL includes certificates issued by *more than one certificate
issuer*. In such a case, the certificate issuer responsible for each
entry is indicated by the certificate issuer CRL entry extension
(section 5.3.4)".

These sentences indicate that, if the indirectCRL boolean is set to
TRUE, then one or more certificate issuer CRL entry extensions are
present.

This also means that if the IDP extension is not present or if the
indirectCRL boolean is set to FALSE, then no certificate issuer CRL
entry extension is present.

The indirectCRL boolean indicates the presence or absence of
certificate issuer CRL entry extensions in the CRL.

It allows to perform an efficient checking of the CRL entries :

 -    If the indirectCRL boolean is set to TRUE, then the CRL entry
      extensions from previous CRL entries MUST be checked to verify
      whether a certificate issuer CRL entry extension is present.

-     If the IDP extension is not present or if the indirectCRL boolean
      is set to FALSE, then CRL entry extensions from every CRL entry
      can ignored or skipped.

The core of the issue is about the following paragraph in section
6.3.3 on page 84 :

      (1)  If the DP includes cRLIssuer, then verify that the issuer
      field in the complete CRL matches cRLIssuer in the DP and that
      the complete CRL contains an issuing distribution point
      extension with the indrectCRL boolean asserted.  Otherwise,
      verify that the CRL issuer matches the certificate issuer.

BTW, there is a typo error where "indirectCRL" is typed
"indrectCRL".

Note that the current text in section 6.3.3 from RFC 3280 does not
handle the Certificate Issuer CRL entry extension, when present,
which may lead to incorrect results.

When the DP includes the cRLIssuer field, verifying that *one value*
from the issuer field in the complete CRL matches cRLIssuer in the
DP is both necessary and sufficient.

There is no need to have the following insertion :

                                                      " and that
         the complete CRL contains an issuing distribution point
         extension with the indirectCRL boolean asserted ".

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 j6BBVLCh096191; Mon, 11 Jul 2005 04:31: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 j6BBVLOp096190; Mon, 11 Jul 2005 04:31:21 -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 j6BBVJGn096106 for <ietf-pkix@imc.org>; Mon, 11 Jul 2005 04:31:20 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net)
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id NAA29844 for <ietf-pkix@imc.org>; Mon, 11 Jul 2005 13:47:04 +0200
Received: from bull.net ([129.181.81.64]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005071113315661:4076 ; Mon, 11 Jul 2005 13:31:56 +0200 
Message-ID: <42D25881.2060908@bull.net>
Date: Mon, 11 Jul 2005 13:31:13 +0200
From: Denis Pinkas <Denis.Pinkas@bull.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: pkix <ietf-pkix@imc.org>
Subject: 3280bis: CRL validation: what is wrong and/or missing in section 6.3
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 07/11/2005 01:31:58 PM, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 07/11/2005 01:31:59 PM, Serialize complete at 07/11/2005 01:31:59 PM
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=ISO-8859-1; 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>

3280bis: CRL validation: what is wrong and/or missing in section 6.3.

1. The very first sentence states:

 " This section describes the steps necessary to determine if a
   certificate is revoked or on hold status when CRLs are the revocation
   mechanism used by the certificate issuer".

a) This section should describe the steps necessary to determine
   if the revocation status of the certification path* is : REVOKED,
   NOT_REVOKED or UNKNOWN, instead of simply determine if the
   *target certificate* is REVOKED. So the sentence is incorrect.

b) The current text mentions the return of the "on hold" status.
   However since CRLreason is not mentioned as an output parameter
   of the algorithm, this may not be the case (the only algorithm
   output is currently the revocation status of the certificate).

2. The text states: " Conforming implementations that support
CRLs are not required to implement this algorithm, but they MUST
be functionally equivalent to the external behavior resulting
from this procedure".

This sentence is incorrect since the algorithm would mandate
the support of many certificate extensions, CRL extensions and
CRL entry extensions that conforming relying party applications
are NOT REQUIRED to support. The current algorithm has many errors
in it cannot be easily simplified, if less than "all options"
are supported by a relying party.

3. The text states: "This algorithm assumes that all of the needed
CRLs are available in a local cache".

This sentence is incorrect, because it may happen that the "right"
or a "current" CRL is  unavailable and thus absent; in such a case
the algorithm terminates with "UNDETERMINED" or "UNKNOWN". 

4. The text states:

"This algorithm begins by assuming the certificate is not revoked."

This sentence is incorrect, the algorithm should begin by assuming
the status of the certificate is "UNDETERMINED" or "UNKNOWN".

5. The text states, [omitting what is relevant to delta CRLs]

"(a)  Update the local CRL cache by obtaining a complete CRL [ ] :

         (1)  If the current time is after the value of the CRL next
         update field, then do one of the following :

            (i) [ ].

            (ii)  Update the local CRL cache with a current complete
            CRL, verify that the current time is before the next update
            value in the new CRL, [ ]".

This is incorrect. If the "current" CRL cannot be found, then it is
still possible to use an older CRL to demonstrate that the certificate
was REVOKED. Of course, when using an older CRL it is not possible
to demonstrate that the certificate was NOT_REVOKED.

6. The current algorithm cannot make sure that an emergency CRL (
i.e. the latest captured CRL) will be used if more than one
"valid" CRLs are found in the local cache.

7. The text states:

   (f)  Obtain and validate the certification path for the complete CRL
   issuer.  If a key usage extension is present in the CRL issuer's
   certificate, verify that the cRLSign bit is set.

   (g)  Validate the signature on the complete CRL using the public key
   validated in step (f).

The text is unclear about what is meant by :" validate the certification
path for the complete CRL issuer". In order to solve the problem of
identical CRL Issuer names or identical CA names, it is needed to say
that the certification path that has been used to validate the target
certificate MUST also be used.

8. There is no handling of the Certificate Issuer CRL entry extension,
when present, which may lead to incorrect results.

9. The above list should not be considered as exhaustive.

This demonstrates the need to revise in depth section 6.3.

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 j68A91Gl026875; Fri, 8 Jul 2005 03: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 j68A918F026873; Fri, 8 Jul 2005 03:09:01 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from sniper.kisa.or.kr ([211.252.150.22]) by above.proper.com (8.12.11/8.12.9) with SMTP id j68A8x3Y026820 for <ietf-pkix@imc.org>; Fri, 8 Jul 2005 03:08:59 -0700 (PDT) (envelope-from parkbh@kisa.or.kr)
Message-Id: <200507081008.j68A8x3Y026820@above.proper.com>
Received: (snipe 12889 invoked by alias); 8 Jul 2005 19:06:11 +0900
Received: from parkbh@kisa.or.kr with  Spamsniper 2.83.29 (Processed in 0.161775 secs);
Received: from unknown (HELO s0fel8ezhdf4zfm) (192.168.250.47) by unknown with SMTP; 8 Jul 2005 19:06:11 +0900
X-RCPTTO: david.nospam.hopwood@blueyonder.co.uk, ietf-pkix@imc.org, ikjeun@kisa.or.kr, jhbaek@kisa.or.kr, jhyoon@kisa.or.kr, jiinii@kisa.or.kr, jilee@kisa.or.kr, sllee@kisa.or.kr
From: =?ks_c_5601-1987?B?udq56Mi/?= <parkbh@kisa.or.kr>
To: <david.nospam.hopwood@blueyonder.co.uk>, <ietf-pkix@imc.org>
Cc: <sllee@kisa.or.kr>, <jhbaek@kisa.or.kr>, <ikjeun@kisa.or.kr>, <jilee@kisa.or.kr>, <jhyoon@kisa.or.kr>, <jiinii@kisa.or.kr>
Subject: Re: Re: Last Call: 'Required functions of User Interface for the Internet X.509 Public Key Infrastructure' to Informational RFC
Date: Fri, 8 Jul 2005 19:11:15 +0900
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0017_01C583F0.D004C390"
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Thread-Index: AcWDpV/Xxs0jH+ypTw2+D2frvObX9w==
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <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_01C583F0.D004C390
Content-Type: text/plain;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: 7bit

Dear David Hopwood

This is BaeHyo Park, one of co-authors of draft-choi-pkix-ui-03. 

Most of all, thanks for your interests in this draft. I'd really appreciate
it. 

As you may agree, the main purpose of this draft is to make it sure that
there are many problems

on User Interface of PKI modules and software and to lead more discussions
for spreading better

PKI widely for users than now. However, from your comments, I think that
this draft needs to be

changed for representing this purpose. 

I'll give you my brief opinions on your comments. 

1. Inadequate motivation for "using one certificate [for] many PKI
applications" 

: It is from the idea that the client S/W of the applications should find
and display the users' certificates

without users' involvement. Of course, there can be more than one
certificate according to applications.

However, client S/Ws find and display all the certificates or some
certificates satisfied with application's

requirements, and then a user will select an appropriate certificate of
them.

2. Uncommon storage location of HARD DISK due to multi-user operating
systems and existing conventions

for where user certificates are stored 

: The issue related to HARD DISK will be totally changed because we didn't
give that much thought on OS

 even though the disk depends on OS. 

3. User software *cannot* validate the cert in a way that is guaranteed to
match the validation result of any relying party 

: Human users have the right to confirm that their certificates are valid
because there are many malicious attacks(Hacking)

on the certificates. (However, I don't think I understand your comment.
Could you please put more explanation on your advice?) 

4. Insecure method to update the PKI client software and the trust anchor's
certificate. 

  : In this text, "secure method" means the mechanism which guarantees the
integrity of PKI client S/W. 

In conclusion, I've got several opinions on this draft from PKI experts
including you.

We, authors, are willing to improve this draft with consideration of your
comments.

And also we hope to have more talks with you on user interface issues for
widespread

adoption of PKI in real world as well as standardizing this draft. 

I very much appreciate your review and thank you once again for sending it
to me. 

Best Regards 

BaeHyo Park

------=_NextPart_000_0017_01C583F0.D004C390
Content-Type: text/html;
	charset="ks_c_5601-1987"
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=3Dks_c_5601-1987">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"PlaceType"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"PlaceName"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"place"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:=B9=D9=C5=C1;
	panose-1:2 3 6 0 0 1 1 1 1 1;}
@font-face
	{font-family:=B1=BC=B8=B2;
	panose-1:2 11 6 0 0 1 1 1 1 1;}
@font-face
	{font-family:"\@=B1=BC=B8=B2";
	panose-1:2 11 6 0 0 1 1 1 1 1;}
@font-face
	{font-family:"\@=B9=D9=C5=C1";
	panose-1:2 3 6 0 0 1 1 1 1 1;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	text-align:justify;
	text-justify:inter-ideograph;
	text-autospace:none;
	word-break:break-hangul;
	font-size:10.0pt;
	font-family:=B9=D9=C5=C1;}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p
	{mso-margin-top-alt:auto;
	margin-right:0cm;
	mso-margin-bottom-alt:auto;
	margin-left:0cm;
	font-size:12.0pt;
	font-family:=B1=BC=B8=B2;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:=B1=BC=B8=B2;
	color:windowtext;}
 /* Page Definitions */
 @page Section1
	{size:595.3pt 841.9pt;
	margin:99.25pt 3.0cm 3.0cm 3.0cm;
	layout-grid:18.0pt;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DKO link=3Dblue vlink=3Dpurple>

<div class=3DSection1 style=3D'layout-grid:18.0pt'>

<p style=3D'margin:0cm;margin-bottom:.0001pt;line-height:12.0pt'><font =
size=3D2
color=3Dblack face=3D=B9=D9=C5=C1><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:=B9=D9=C5=C1;
color:black'>Dear David Hopwood<o:p></o:p></span></font></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt;line-height:12.0pt'><font =
size=3D2
color=3Dblack face=3D=B9=D9=C5=C1><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:=B9=D9=C5=C1;
color:black'><o:p>&nbsp;</o:p></span></font></p>

This is <st1:place w:st=3D"on"><st1:PlaceName =
w:st=3D"on">BaeHyo</st1:PlaceName>
 <st1:PlaceType w:st=3D"on">Park</st1:PlaceType></st1:place>, one of =
co-authors
of draft-choi-pkix-ui-03. <o:p></o:p>

Most of all, thanks for your interests in this draft. I'd =
really
appreciate it. <o:p></o:p>

<p style=3D'margin:0cm;margin-bottom:.0001pt;line-height:12.0pt'><font =
size=3D2
color=3Dblack face=3D=B9=D9=C5=C1><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:=B9=D9=C5=C1;
color:black'><o:p>&nbsp;</o:p></span></font></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt;line-height:12.0pt'><font =
size=3D2
color=3Dblack face=3D=B9=D9=C5=C1><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:=B9=D9=C5=C1;
color:black'>As you may agree, the main purpose of this draft is to make =
it
sure that there are many problems<o:p></o:p></span></font></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt;line-height:12.0pt'><font =
size=3D2
color=3Dblack face=3D=B9=D9=C5=C1><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:=B9=D9=C5=C1;
color:black'>on User Interface of PKI modules and software and to lead =
more
discussions for spreading better<o:p></o:p></span></font></p>

PKI widely for users than now. However, from your comments, =
I think
that this draft needs to be<o:p></o:p>

<p style=3D'margin:0cm;margin-bottom:.0001pt;line-height:12.0pt'><font =
size=3D2
color=3Dblack face=3D=B9=D9=C5=C1><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:=B9=D9=C5=C1;
color:black'>changed for representing this purpose. =
<o:p></o:p></span></font></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt;line-height:12.0pt'><font =
size=3D2
color=3Dblack face=3D=B9=D9=C5=C1><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:=B9=D9=C5=C1;
color:black'><o:p>&nbsp;</o:p></span></font></p>

I'll give you my brief opinions on your comments. =
<o:p></o:p>

<p style=3D'margin:0cm;margin-bottom:.0001pt;line-height:12.0pt'><font =
size=3D2
color=3Dblack face=3D=B9=D9=C5=C1><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:=B9=D9=C5=C1;
color:black'><o:p>&nbsp;</o:p></span></font></p>

1. Inadequate motivation for &quot;using one certificate =
[for]
many PKI applications&quot; <o:p></o:p>

<p =
style=3D'margin:0cm;margin-bottom:.0001pt;text-indent:9.0pt;line-height:1=
2.0pt'><font
size=3D2 color=3Dblack face=3D=B9=D9=C5=C1><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:
=B9=D9=C5=C1;color:black'>: It is from the idea that the client S/W of =
the applications
should find and display the users' =
certificates<o:p></o:p></span></font></p>

without users' involvement. Of course, there =
can be more than
one certificate according to applications.<o:p></o:p>

<p =
style=3D'margin:0cm;margin-bottom:.0001pt;text-indent:14.0pt;line-height:=
12.0pt'><font
size=3D2 color=3Dblack face=3D=B9=D9=C5=C1><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:
=B9=D9=C5=C1;color:black'>However, client S/Ws find and display all the =
certificates or
some certificates satisfied with =
application's<o:p></o:p></span></font></p>

<p =
style=3D'margin:0cm;margin-bottom:.0001pt;text-indent:14.0pt;line-height:=
12.0pt'><font
size=3D2 color=3Dblack face=3D=B9=D9=C5=C1><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:
=B9=D9=C5=C1;color:black'>requirements, and then a user will select an =
appropriate
certificate of them.<o:p></o:p></span></font></p>

2. Uncommon storage location of HARD DISK due to multi-user
operating systems and existing conventions<o:p></o:p>

<p =
style=3D'margin:0cm;margin-bottom:.0001pt;text-indent:10.0pt;line-height:=
12.0pt'><font
size=3D2 color=3Dblack face=3D=B9=D9=C5=C1><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:
=B9=D9=C5=C1;color:black'>for where user certificates are stored =
<o:p></o:p></span></font></p>

<p =
style=3D'margin:0cm;margin-bottom:.0001pt;text-indent:9.0pt;line-height:1=
2.0pt'><font
size=3D2 color=3Dblack face=3D=B9=D9=C5=C1><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:
=B9=D9=C5=C1;color:black'>: The issue related to HARD DISK will be =
totally changed
because we didn't give that much thought on =
OS<o:p></o:p></span></font></p>

<p =
style=3D'margin:0cm;margin-bottom:.0001pt;text-indent:9.0pt;line-height:1=
2.0pt'><font
size=3D2 color=3Dblack face=3D=B9=D9=C5=C1><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:
=B9=D9=C5=C1;color:black'>&nbsp;even though the disk depends on OS. =
<o:p></o:p></span></font></p>

3. User software =
*cannot* validate the
cert in a way that is guaranteed to match the validation result of any =
relying
party <o:p></o:p>

<p =
style=3D'margin:0cm;margin-bottom:.0001pt;text-indent:9.0pt;line-height:1=
2.0pt'><font
size=3D2 face=3D=B9=D9=C5=C1><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:=B9=D9=C5=C1'>: Human
users have the right to confirm that their certificates are valid =
because there
are many malicious attacks(Hacking)<o:p></o:p></span></font></p>

<p =
style=3D'mso-margin-top-alt:0cm;margin-right:0cm;margin-bottom:0cm;margin=
-left:
21.0pt;margin-bottom:.0001pt;mso-margin-top-alt:0cm;mso-para-margin-right=
:0cm;
mso-para-margin-bottom:0cm;mso-para-margin-left:1.0gd;mso-para-margin-bot=
tom:
.0001pt;text-indent:-11.0pt;line-height:12.0pt'><font size=3D2 =
face=3D=B9=D9=C5=C1><span
lang=3DEN-US style=3D'font-size:10.0pt;font-family:=B9=D9=C5=C1'>on the =
certificates. (However,
I don't think I understand your comment. Could you please put more =
explanation
on your advice?) <o:p></o:p></span></font></p>

<p =
style=3D'margin:0cm;margin-bottom:.0001pt;text-indent:9.0pt;line-height:1=
2.0pt'><font
size=3D2 color=3Dblack face=3D=B9=D9=C5=C1><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:
=B9=D9=C5=C1;color:black'><o:p>&nbsp;</o:p></span></font></p>

<!-- Document End -->

4. Insecure method to update the PKI client software and =
the trust
anchor's certificate. <o:p></o:p>

&nbsp; : In this text, &quot;secure method&quot; means the
mechanism which guarantees the integrity of PKI client S/W. =
<o:p></o:p>

<p style=3D'margin:0cm;margin-bottom:.0001pt;line-height:12.0pt'><font =
size=3D2
color=3Dblack face=3D=B9=D9=C5=C1><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:=B9=D9=C5=C1;
color:black'><o:p>&nbsp;</o:p></span></font></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt;line-height:12.0pt'><font =
size=3D2
color=3Dblack face=3D=B9=D9=C5=C1><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:=B9=D9=C5=C1;
color:black'>In conclusion, I've got several opinions on this draft from =
PKI
experts including you.<o:p></o:p></span></font></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt;line-height:12.0pt'><font =
size=3D2
color=3Dblack face=3D=B9=D9=C5=C1><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:=B9=D9=C5=C1;
color:black'>We, authors, are willing to improve this draft with =
consideration
of your comments.<o:p></o:p></span></font></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt;line-height:12.0pt'><font =
size=3D2
color=3Dblack face=3D=B9=D9=C5=C1><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:=B9=D9=C5=C1;
color:black'>And also we hope to have more talks with you on user =
interface
issues for widespread<o:p></o:p></span></font></p>

adoption of PKI in real world as well as standardizing this =
draft.
<o:p></o:p>

<p style=3D'margin:0cm;margin-bottom:.0001pt;line-height:12.0pt'><font =
size=3D2
color=3Dblack face=3D=B9=D9=C5=C1><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:=B9=D9=C5=C1;
color:black'><o:p>&nbsp;</o:p></span></font></p>

I very much appreciate your review and thank you once again =
for
sending it to me. <o:p></o:p>

<p style=3D'margin:0cm;margin-bottom:.0001pt;line-height:12.0pt'><font =
size=3D2
color=3Dblack face=3D=B9=D9=C5=C1><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:=B9=D9=C5=C1;
color:black'><o:p>&nbsp;</o:p></span></font></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt;line-height:12.0pt'><font =
size=3D2
color=3Dblack face=3D=B9=D9=C5=C1><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:=B9=D9=C5=C1;
color:black'>Best Regards <o:p></o:p></span></font></p>

<p =
style=3D'margin:0cm;margin-bottom:.0001pt;line-height:12.0pt'><st1:place
w:st=3D"on"><st1:PlaceName w:st=3D"on"><font size=3D2 color=3Dblack =
face=3D=B9=D9=C5=C1><span
  lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:=B9=D9=C5=C1;color:black'>BaeHyo</s=
pan></font></st1:PlaceName><font
 size=3D2 color=3Dblack face=3D=B9=D9=C5=C1><span lang=3DEN-US =
style=3D'font-size:10.0pt;
 font-family:=B9=D9=C5=C1;color:black'> <st1:PlaceType =
w:st=3D"on">Park</st1:PlaceType></span></font></st1:place><font
size=3D2 color=3Dblack face=3D=B9=D9=C5=C1><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:
=B9=D9=C5=C1;color:black'><o:p></o:p></span></font></p>

</div>

<!-- Document End -->
</body>

</html>

------=_NextPart_000_0017_01C583F0.D004C390--

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 j67EHo7f009178; Thu, 7 Jul 2005 07:17: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 j67EHolT009176; Thu, 7 Jul 2005 07:17:50 -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.9) with ESMTP id j67EHnWX009160 for <ietf-pkix@imc.org>; Thu, 7 Jul 2005 07:17:49 -0700 (PDT) (envelope-from kent@bbn.com)
Received: from [128.89.89.106] (dhcp89-089-106.bbn.com [128.89.89.106]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j67EHc2s014700; Thu, 7 Jul 2005 10:17:42 -0400 (EDT)
Mime-Version: 1.0
Message-Id: <p06230936bef2e5b7e8c4@[128.89.89.106]>
In-Reply-To: <002e01c582ce$72121a30$8217a8c0@arport2v>
References: <200562793918.342771@bbprime> <42C7494F.9090708@blueyonder.co.uk> <002e01c582ce$72121a30$8217a8c0@arport2v>
Date: Thu, 7 Jul 2005 10:03:36 -0400
To: "Anders Rundgren" <anders.rundgren@telia.com>
From: Stephen Kent <kent@bbn.com>
Subject: Re: Last Call: 'Required functions of User Interface for the Internet X.509 Public Key Infrastructure' to Informational RFC
Cc: <david.nospam.hopwood@blueyonder.co.uk>, <ietf-pkix@imc.org>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41
X-Virus-Status: Clean
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <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,

I refer you to a report by the U.S. National Research Council, 
entitled "Who Goes There? Authentication Through the Lens of 
Privacy."  The report was issued almost 2 years ago and it strongly 
recommends against the single cert per user model, for both privacy 
and security reasons.

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 j678VGIU078438; Thu, 7 Jul 2005 01:31: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 j678VGVH078437; Thu, 7 Jul 2005 01:31:16 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from pne-smtpout2-sn1.fre.skanova.net (pne-smtpout2-sn1.fre.skanova.net [81.228.11.159]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j678VFXw078383 for <ietf-pkix@imc.org>; Thu, 7 Jul 2005 01:31:16 -0700 (PDT) (envelope-from anders.rundgren@telia.com)
Received: from arport2v (213.64.36.56) by pne-smtpout2-sn1.fre.skanova.net (7.2.060.1) id 42B93717002AA776; Thu, 7 Jul 2005 10:31:08 +0200
Message-ID: <002e01c582ce$72121a30$8217a8c0@arport2v>
From: "Anders Rundgren" <anders.rundgren@telia.com>
To: <david.nospam.hopwood@blueyonder.co.uk>, <ietf-pkix@imc.org>
References: <200562793918.342771@bbprime> <42C7494F.9090708@blueyonder.co.uk>
Subject: Re: Last Call: 'Required functions of User Interface for the Internet X.509 Public Key Infrastructure' to Informational RFC
Date: Thu, 7 Jul 2005 10:32:39 +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>

David Hopwood wrote:

<snip>

>using a single certificate ensures that loss or compromise of one
> private key necessarily implies loss or compromise of the user's
> identity for many different applications. (This problem is not solved
>just by using multiple certificates, but at least it is not precluded
>from being solved.)

The use of the word "problem" is not entirely correct, I would rather
say that this usage *solves* a number of serious real-life problems
that will face a future PKI-enabled user.

Compromise (=theft/loss): ONE revocation and all
associated services are blocked.

Recovery of lost IT-life: ONE renewal/RA process and you are back.

Economics: To pay for having a passport-like ID seems reasonable
if you have multiple uses.  This is probably also a pre-requisite for
creating globally working CA/RA networks.

Company or national CA networks including the US PIV-program
do not address these issues.

<snip>

Sincerely
Anders Rundgren

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 j65JFYI7004734; Tue, 5 Jul 2005 12:15: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 j65JFY3c004733; Tue, 5 Jul 2005 12:15:34 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from host15.websitesource.com (host15.websitesource.com [209.239.32.38]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j65JFXxn004721 for <ietf-pkix@imc.org>; Tue, 5 Jul 2005 12:15:33 -0700 (PDT) (envelope-from chokhani@orionsec.com)
Received: from wchokhani3 (static-70-21-114-242.res.east.verizon.net [70.21.114.242]) by host15.websitesource.com (8.12.10/8.12.10) with ESMTP id j65JFUJb030080 for <ietf-pkix@imc.org>; Tue, 5 Jul 2005 15:15:32 -0400
From: "Santosh Chokhani" <chokhani@orionsec.com>
To: <ietf-pkix@imc.org>
Subject: RE: Authority Key Identifier extension for a CRL issued by a subordinate CA
Date: Tue, 5 Jul 2005 15:15:25 -0400
Message-ID: <013b01c58195$e94d88d0$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.2900.2180
In-Reply-To: <001101c58189$ad6e8050$6f00a8c0@seguridata.com>
Importance: Normal
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j65JFXxn004728
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

Miguel,

Generally it is not a good idea to use that option for AKID.

But, the value is supposed to represent the certificate issued to the CA.
Thus, the issuer DN should be that of the parent CA that issued a
certificate to the CRL issuing CA (it could be the Root or an intermediate
CA) and the serial number should be that of the certificate issued by the
issuer DN to the CRL issuing CA.

-----Original Message-----
From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On
Behalf Of Miguel A Rodriguez
Sent: Tuesday, July 05, 2005 1:48 PM
To: ietf-pkix@imc.org
Subject: Authority Key Identifier extension for a CRL issued by a
subordinate CA

Hi,

Consider a subordinate CA that issues a CRL. Regarding the Authority Key
Identifer extension for the CRL in the "issuer name and serial number" form.
What is the correct name to be included, the one of the subordinate CA or
the one of the root CA?

Thanks in advance,

Miguel Rodriguez
SeguriData 
Mexico

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 j65HnRJg097978; Tue, 5 Jul 2005 10:49: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 j65HnRS7097977; Tue, 5 Jul 2005 10:49:27 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from [200.53.113.210] (mail.seguridata.com [200.53.113.210]) by above.proper.com (8.12.11/8.12.9) with SMTP id j65HnJ2d097950 for <ietf-pkix@imc.org>; Tue, 5 Jul 2005 10:49:24 -0700 (PDT) (envelope-from mars@seguridata.com)
Received: from no.name.available by [200.53.113.210] via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; Tue, 5 Jul 2005 13:47:27 -0500
Received: from miguel2 ([192.168.0.111]) by mail.seguridata.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Jul 2005 12:53:07 -0500
From: "Miguel A Rodriguez" <mars@seguridata.com>
To: <ietf-pkix@imc.org>
Subject: Authority Key Identifier extension for a CRL issued by a subordinate CA
Date: Tue, 5 Jul 2005 12:47:56 -0500
Message-ID: <001101c58189$ad6e8050$6f00a8c0@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.2900.2180
X-OriginalArrivalTime: 05 Jul 2005 17:53:07.0741 (UTC) FILETIME=[66A3D4D0:01C5818A]
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <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,

Consider a subordinate CA that issues a CRL. Regarding the Authority Key
Identifer extension for the CRL in the "issuer name and serial number"
form. What is the correct name to be included, the one of the
subordinate CA or the one of the root CA?

Thanks in advance,

Miguel Rodriguez
SeguriData 
Mexico

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 j632BntA016857; Sat, 2 Jul 2005 19:11: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 j632Bnex016855; Sat, 2 Jul 2005 19:11:49 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from smtp-out6.blueyonder.co.uk (smtp-out6.blueyonder.co.uk [195.188.213.9]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j632BlWf016835 for <ietf-pkix@imc.org>; Sat, 2 Jul 2005 19:11:48 -0700 (PDT) (envelope-from david.hopwood@blueyonder.co.uk)
Received: from [127.0.0.1] ([82.42.16.20]) by smtp-out6.blueyonder.co.uk with Microsoft SMTPSVC(5.0.2195.6713); Sun, 3 Jul 2005 03:12:11 +0100
Message-ID: <42C7494F.9090708@blueyonder.co.uk>
Date: Sun, 03 Jul 2005 03:11:27 +0100
From: David Hopwood <david.nospam.hopwood@blueyonder.co.uk>
Reply-To: david.nospam.hopwood@blueyonder.co.uk
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf-pkix@imc.org
Subject: Re: Last Call: 'Required functions of User Interface for the Internet X.509 Public Key Infrastructure' to Informational RFC
References: <200562793918.342771@bbprime>
In-Reply-To: <200562793918.342771@bbprime>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 03 Jul 2005 02:12:11.0906 (UTC) FILETIME=[9F838E20:01C57F74]
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <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 due to "only members can post" on ietf-pkix]

Re: http://www.ietf.org/internet-drafts/draft-choi-pkix-ui-03.txt

Dave Crocker wrote:
>> - 'Required functions of User Interface for the Internet X.509 Public Key
>> Infrastructure '
>> <draft-choi-pkix-ui-03.txt> as an Informational RFC
> 
> RFC document titles should not carry language that states or implies that their 
> contents mandate conformans.
> 
> Hence, the word "Required" should be removed from this document title.
> 
> The issue is only exacerbated by the fact that it is seeking non-standards 
> status.

Also, the document has received no review in Working Groups for which it is
relevant, such as TLS and PKIX (there are references to its existence in the
PKIX archives, but no discussion). It seems to have been in desperate need
of such review:

#  Compatibility shall be accomplished for using one certificate to many
#  PKI applications. Generally, PKI application such as the Internet
#  Banking or E-mail application defines the user's certificate and
#  private key location by their own way. Thereby, when using those
#  applications, users are at a loss whenever receiving a question where
#  their certificates are. Most users do not know the answer, and they
#  want to use different PKI programs with their own certificate without
#  answering the question. It comes true as a certificate sharing
#  function and transfer function that mainly aim for increasing
#  certificate compatibility, which benefits the user's convenience.

The grammar here, and elsewhere in the document is bad enough to obscure
the meaning. More importantly, the argument given is inadequate motivation
for "using one certificate [for] many PKI applications":

  - the described usability problem could be solved even with multiple
    certificates
  - it is not clear that, in the situations where user certificates
    are typically used, implicitly selecting a certificate rather than
    prompting the user to select one would be a good thing
  - there are privacy implications of using a certificate for multiple
    applications, which are not discussed in the document
  - different relying parties may have requirements, for example on the
    algorithms used and on optional cert fields, that cannot be met by a
    single certificate
  - using a single certificate ensures that loss or compromise of one
    private key necessarily implies loss or compromise of the user's
    identity for many different applications. (This problem is not solved
    just by using multiple certificates, but at least it is not precluded
    from being solved.)

#  For example, a common storage location of a user's certificate and
#  private key in HARD DISK driver of different operating systems can be
#  assigned to be:
#
#      - MS  Windows :  C:Program Files/IETF/PKIX
#      - Linux/Unix  : (User Account)/IETF/PKIX
#      - Mac OS X    : (Hard disk label):Library/IETF/PKIX

Is this a joke? It ignores, at least, the fact that MS Windows and
Mac OS X are multi-user operating systems, and existing conventions for
where user certificates are stored.

#  Lastly, the user interface shall contain certificate management
#  commands as followings;
#
#      - Integrity verification function of trust anchor : defined in
#        [2.2.1]
#      - Import and export : defined in [2.1.2]
#      - Certificate verification : when a user wants to know whether
#        his or her certificate is valid or not

Valid for what purpose? User software *cannot* validate the cert in
a way that is guaranteed to match the validation result of any relying
party; it doesn't have enough information.

The Security Considerations section is totally inadequate. As an example,
consider this statement:

#  The PKI client software must provide a secure method to update PKI
#  client software and trust anchor's certificate. This document defines
#  it as automatic update function, which makes user involvement
#  minimized.

which has security considerations that are left entirely unaddressed.
(Just saying "a secure method" doesn't mean anything: How should it be
secured? Who should be trusted? What happens if keys are compromised?)

In summary, the document is not of adequate quality for publication as
an Informational RFC. It is not clear that anything useful is salvageable
from it.

-- 
David Hopwood <david.nospam.hopwood@blueyonder.co.uk>

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 j617QTdD028908; Fri, 1 Jul 2005 00:26: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 j617QQtt028721; Fri, 1 Jul 2005 00:26:26 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from pne-smtpout2-sn2.hy.skanova.net (pne-smtpout2-sn2.hy.skanova.net [81.228.8.164]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j617QJT4028279 for <ietf-pkix@imc.org>; Fri, 1 Jul 2005 00:26:24 -0700 (PDT) (envelope-from anders.rundgren@telia.com)
Received: from arport2v (195.252.45.35) by pne-smtpout2-sn2.hy.skanova.net (7.2.060.1) id 42B94E29001A54E1; Fri, 1 Jul 2005 09:25:53 +0200
Message-ID: <007401c57e0e$9cb867e0$8217a8c0@arport2v>
From: "Anders Rundgren" <anders.rundgren@telia.com>
To: "Massimiliano Pala" <massimiliano.pala@polito.it>, "pkix" <ietf-pkix@imc.org>
References: <42C420FF.2060403@polito.it>
Subject: Re: PKI Resources Query Protocol
Date: Fri, 1 Jul 2005 09:29:22 +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>

Massimiliano,

>I am working on the definition of a new protocol aimed to solve the problem
>tied to the lack of informations about repositories and services offered
>by a CSP.

OK. Does that also include warranties?

>One of the problems we are facing now is how to connect different
>closed existing PKIs.

What do you mean with "connect"?  I thought that NIST and other US
government bodies already consider this solved by using bridge CAs.
(personally I believe bridges will rarely reach outside of the public
sector border as neither the implicit trust model, nor the bridge CA 
business model are particularly suited for the commercial world)

>For this purpose I think that the availability of URI about offered services
>(e.g. OCSP, SCVP, etc... ) or available data (e.g. certificate and CRLs
>repositories) would help in PKI interoperability.

How do you find the URI?  In a certificate extension or OOB?

>Therefore I am trying to work on this subject by defining a newprotocol.
>Reasons to adopt such a protocol are:
>- extensions are too static, if new services or repositories are added
>   (or dismissed) by the CSP, there is no sign of the changes into the
>   already issued certificates
>- no need to define new type of extensions for new services and/or
>   repositories as this will be handled by the PRQP (PKI Resources Query
>   Protocol)
>- (practical consideration) in my experience it is easier to deal with a
>   protocol than with certificate extensions (from a management and implementation
>   point of view)

Sounds good.

>The protocol I am thinking about is a very lightweight (much like OCSP)
>one and it is based on a request/response mechanism over HTTP.

Here I am not entirely in agreement.  I doubt that you need to query these
things frequently and then a Web Services interface would be more extensible.
I.e. the URI would point to WSDL rather than to the service itself.

>Said this, I would really like to have your opinion on this approach, and to
>know if someone is already working on a similar idea. In that case we could
>collaborate on the subject and come up with a proposal for an RFC.
>When I'll have something readable I will send it to the list (I know the PKIX
>is going to be closed, but until that day I guess this is the best place
>for this discussion... if not, just let me know).

If you go for Web Services, maybe OASIS would be a better place?

thanks
Anders Rundgren

-- 

Best Regards,

Massimiliano Pala

--o------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager]      massimiliano.pala@polito.it
                                                 Tel.:   +39 (0)11  564 7081
http://security.polito.it                       Fax:    +39   178  270 2077
                                                 Mobile: +39 (0)347 7222 365

Politecnico di Torino (EuroPKI)
Certification Authority Informations:

Authority Access Point                                  http://ca.polito.it
Authority's Certificate:          http://ca.polito.it/ca_cert/en_index.html
Certificate Revocation List:              http://ca.polito.it/crl02/crl.crl
--o------------------------------------------------------------------------