Re: SCVP-22 Open Issue: RFC 3379 Requirement #14

[Russ Housley <[e-mail]>]

Peter:

>The requirement of returing a text was the result of my request to 
>allow identifiers
>of requestors and responders in both request and response. It seems that the
>authors of thge requirement have misunderstood identifier and textual
>reference.
>
>Anyway, if a text is to be added, then an opaque octetification doesn't seem
>appropriate. A string has no internal structure, but it is still a 
>string. The string
>still need to be displayed by the client, and other clients in case 
>of relaying
>etc.

I do not recall the origins at this point.  Your requirements is 
clearly already met by the existing protocol elements.  We need to 
deal with the protocol requirements as documented, or we need to 
changes them, which is more work at this point.

Russ





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 k0VILjIX006424; Tue, 31 Jan 2006 10:21:45 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k0VILjpG006423; Tue, 31 Jan 2006 10:21:45 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id k0VILif9006417 for <[e-mail]>; Tue, 31 Jan 2006 10:21:44 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 10276 invoked by uid 0); 31 Jan 2006 18:21:39 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (66.114.247.35) by woodstock.binhost.com with SMTP; 31 Jan 2006 18:21:39 -0000
Message-Id: <[e-mail]>
X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16
Date: Tue, 31 Jan 2006 13:21:24 -0500
To: Peter Sylvester <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: SCVP-22 Open Issue: RFC 3379 Requirement #14
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter:

>The requirement of returing a text was the result of my request to 
>allow identifiers
>of requestors and responders in both request and response. It seems that the
>authors of thge requirement have misunderstood identifier and textual
>reference.
>
>Anyway, if a text is to be added, then an opaque octetification doesn't seem
>appropriate. A string has no internal structure, but it is still a 
>string. The string
>still need to be displayed by the client, and other clients in case 
>of relaying
>etc.

I do not recall the origins at this point.  Your requirements is 
clearly already met by the existing protocol elements.  We need to 
deal with the protocol requirements as documented, or we need to 
changes them, which is more work at this point.

Russ



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 k0VGtIux093647; Tue, 31 Jan 2006 08:55:18 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k0VGtIj8093646; Tue, 31 Jan 2006 08:55:18 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id k0VGtH0l093631 for <[e-mail]>; Tue, 31 Jan 2006 08:55:17 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 18206 invoked by uid 0); 31 Jan 2006 16:55:13 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (66.114.247.35) by woodstock.binhost.com with SMTP; 31 Jan 2006 16:55:13 -0000
Message-Id: <[e-mail]>
X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16
Date: Tue, 31 Jan 2006 11:53:20 -0500
To: Tom Gindin <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: SCVP-22 Open Issue: RFC 3379 Requirement #14
Cc: [e-mail]
In-Reply-To: <OF02D9C079.716E285A-ON85257106.0061BE3F-85257107.0013074D@ us.ibm.com>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I would suggest:
     UTF8String (SIZE (1..256))

Russ

At 10:28 PM 1/30/2006, Tom Gindin wrote:
>         Russ:
>
>         Although several values of GeneralName are (IA5) text strings,
>none of them are free-form ones, so they don't really fit this
>requirement.  The solution given in your note seems better.  I do have one
>request for clarification, though.  Is the length limit 256 Unicode
>characters, or 256 octets?  The text suggests Unicode characters, but it
>isn't absolutely clear.  Given that the string is simply copied, a length
>limit in octets might make more sense.  Indeed, in view of the fact that
>the string's internal structure is not important to the server, it might
>be wiser to encode it as an OCTET STRING.
>
>                 Tom Gindin
>
>
>
>
>
>
>Russ Housley <[e-mail]>
>Sent by: [e-mail]
>01/26/2006 04:22 PM
>
>         To:     [e-mail]
>         cc:
>         Subject:        SCVP-22 Open Issue: RFC 3379 Requirement #14
>
>
>
>All:
>
>I am starting a thread for each of the open issues.  Hopefully, these
>can be brought to closure very quickly.
>
>One could also argue that the Nonce could be used to meet this
>requirement, but like requestorRef, this is not really a good fit.
>
>I think the most expedient solution is to ad the field as Tim suggests.
>
>Tim:
>
>Thanks for all of the work.  This clearly was a lot of effort.
>
>Russ
>
>At 11:06 AM 1/26/2006, Tim Polk wrote:
>
> >3379 Requirement #14. The DPV server MUST be able, upon request,
> >copy a text field provided by the client into the DPV response. (4.1
> >Basic Protocol)
> >
> >SCVP Draft 22:
> >
> >This requirement is poorly addressed in scvp-21
> >
> >An SCVP request may include a requesterRef, which is a SEQUENCE of
> >GeneralNames.
> >
> >"If the SCVP client includes a requestorRef value in the request,
> >then the SCVP server MUST return the same value if the server is
> >generating a non-cached response." Section 4.7
> >
> >One legal value for a GeneralName is an IA5string, so we could argue
> >that it is met, but this is a very poor fit.
> >
> >Proposed Resolution:
> >
> >Add an optional item, requesterText, to both the CVRequest and
> >CVResponse sequences.  The responseText would be UTF8String, maximum
> >size 256 characters.  There would be no semantics; the server would
> >be required to copy the value from the CVRequest into the CVResponse
> >for all non-cached responses.



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 k0VCF3uh055950; Tue, 31 Jan 2006 04:15:03 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k0VCF3xL055949; Tue, 31 Jan 2006 04:15:03 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] 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 k0VCF1in055942 for <[e-mail]>; Tue, 31 Jan 2006 04:15:02 -0800 (PST) (envelope-from [e-mail])
Received: from champagne.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id k0VCF0i06213; Tue, 31 Jan 2006 13:15:00 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/2.4); Tue, 31 Jan 2006 13:15:00 +0100 (MET)
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 NAA27774; Tue, 31 Jan 2006 13:14:59 +0100 (MET)
Message-ID: <[e-mail]>
Date: Tue, 31 Jan 2006 13:06:30 +0100
From: Peter Sylvester <[e-mail]>
User-Agent: Thunderbird 1.5 (X11/20051025)
MIME-Version: 1.0
To: Tom Gindin <[e-mail]>
CC: Russ Housley <[e-mail]>, [e-mail]
Subject: Re: SCVP-22 Open Issue: RFC 3379 Requirement #14
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040702060700040308050001"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a cryptographically signed message in MIME format.

--------------ms040702060700040308050001
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

The requirement of returing a text was the result of my request to allow 
identifiers
of requestors and responders in both request and response. It seems that the
authors of thge requirement have misunderstood identifier and textual
reference.

Anyway, if a text is to be added, then an opaque octetification doesn't seem
appropriate. A string has no internal structure, but it is still a 
string. The string
still need to be displayed by the client, and other clients in case of 
relaying
etc.

om Gindin wrote:
>         Russ:
>
>         Although several values of GeneralName are (IA5) text strings, 
> none of them are free-form ones, so they don't really fit this 
> requirement.  The solution given in your note seems better.  I do have one 
> request for clarification, though.  Is the length limit 256 Unicode 
> characters, or 256 octets?  The text suggests Unicode characters, but it 
> isn't absolutely clear.  Given that the string is simply copied, a length 
> limit in octets might make more sense.  Indeed, in view of the fact that 
> the string's internal structure is not important to the server, it might 
> be wiser to encode it as an OCTET STRING.
>
>                 Tom Gindin
>
>
>
>
>
>
> Russ Housley <[e-mail]>
> Sent by: [e-mail]
> 01/26/2006 04:22 PM
>  
>         To:     [e-mail]
>         cc: 
>         Subject:        SCVP-22 Open Issue: RFC 3379 Requirement #14
>
>
>
> All:
>
> I am starting a thread for each of the open issues.  Hopefully, these 
> can be brought to closure very quickly.
>
> One could also argue that the Nonce could be used to meet this 
> requirement, but like requestorRef, this is not really a good fit.
>
> I think the most expedient solution is to ad the field as Tim suggests.
>
> Tim:
>
> Thanks for all of the work.  This clearly was a lot of effort.
>
> Russ
>
> At 11:06 AM 1/26/2006, Tim Polk wrote:
>
>   
>> 3379 Requirement #14. The DPV server MUST be able, upon request, 
>> copy a text field provided by the client into the DPV response. (4.1 
>> Basic Protocol)
>>
>> SCVP Draft 22:
>>
>> This requirement is poorly addressed in scvp-21
>>
>> An SCVP request may include a requesterRef, which is a SEQUENCE of 
>> GeneralNames.
>>
>> "If the SCVP client includes a requestorRef value in the request, 
>> then the SCVP server MUST return the same value if the server is 
>> generating a non-cached response." Section 4.7
>>
>> One legal value for a GeneralName is an IA5string, so we could argue 
>> that it is met, but this is a very poor fit.
>>
>> Proposed Resolution:
>>
>> Add an optional item, requesterText, to both the CVRequest and 
>> CVResponse sequences.  The responseText would be UTF8String, maximum 
>> size 256 characters.  There would be no semantics; the server would 
>> be required to copy the value from the CVRequest into the CVResponse 
>> for all non-cached responses.
>>     
>
>
>
>   


-- 
To verify the signature, see http://edelpki.edelweb.fr/ 
Cela vous permet de charger le certificat de l'autorité; 
die Liste mit zurückgerufenen Zertifikaten finden Sie da auch. 


--------------ms040702060700040308050001
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
MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYwMTMxMTIwNjMwWjAjBgkqhkiG9w0B
CQQxFgQUwMtRBAmFWXEJtuJ9P4Nove7rt5owUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D
BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC
ASgwdAYJKwYBBAGCNxAEMWcwZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEY
MBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVy
c0dFTgIGCgzP6AA/MHYGCyqGSIb3DQEJEAILMWegZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UE
ChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJ
IEVkZWxXZWIgUGVyc0dFTgIGCgzP6AA/MA0GCSqGSIb3DQEBAQUABIGA552TOSSyfOxwOBM6
b4ZN1cjPqj4K4Qywoi/S/Zv0fJzQngfmr4uxKqkBBngnZkkQOfezWIEgFGf5q4FJ39ijpm8n
GHCb/DUYGgLAN8G+2QczUMlke/wBP0IZcg9npSuSvrwznOmgkFvSEV0mUfOZMCG7QI29sRjk
Oq8NPvmEYHIAAAAAAAA=
--------------ms040702060700040308050001--



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 k0V3SO9l068692; Mon, 30 Jan 2006 19:28:24 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k0V3SNW6068691; Mon, 30 Jan 2006 19:28:23 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.142]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0V3SMmJ068671 for <[e-mail]>; Mon, 30 Jan 2006 19:28:23 -0800 (PST) (envelope-from [e-mail])
Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e2.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id k0V3SGNt001130 for <[e-mail]>; Mon, 30 Jan 2006 22:28:16 -0500
Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay02.pok.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id k0V3SHQg150522 for <[e-mail]>; Mon, 30 Jan 2006 22:28:17 -0500
Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11/8.13.3) with ESMTP id k0V3SGAd003341 for <[e-mail]>; Mon, 30 Jan 2006 22:28:16 -0500
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.56.228.115]) by d01av03.pok.ibm.com (8.12.11/8.12.11) with ESMTP id k0V3SGJ2003338; Mon, 30 Jan 2006 22:28:16 -0500
In-Reply-To: <[e-mail]>
To: Russ Housley <[e-mail]>
Cc: [e-mail]
MIME-Version: 1.0
Subject: Re: SCVP-22 Open Issue: RFC 3379 Requirement #14
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
From: Tom Gindin <[e-mail]>
Message-ID: <[e-mail]>
Date: Mon, 30 Jan 2006 22:28:14 -0500
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 6.5.4FP2 HF4|December 20, 2005) at 01/30/2006 22:28:16, Serialize complete at 01/30/2006 22:28:16
Content-Type: text/plain; charset="US-ASCII"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

        Russ:

        Although several values of GeneralName are (IA5) text strings, 
none of them are free-form ones, so they don't really fit this 
requirement.  The solution given in your note seems better.  I do have one 
request for clarification, though.  Is the length limit 256 Unicode 
characters, or 256 octets?  The text suggests Unicode characters, but it 
isn't absolutely clear.  Given that the string is simply copied, a length 
limit in octets might make more sense.  Indeed, in view of the fact that 
the string's internal structure is not important to the server, it might 
be wiser to encode it as an OCTET STRING.

                Tom Gindin






Russ Housley <[e-mail]>
Sent by: [e-mail]
01/26/2006 04:22 PM
 
        To:     [e-mail]
        cc: 
        Subject:        SCVP-22 Open Issue: RFC 3379 Requirement #14



All:

I am starting a thread for each of the open issues.  Hopefully, these 
can be brought to closure very quickly.

One could also argue that the Nonce could be used to meet this 
requirement, but like requestorRef, this is not really a good fit.

I think the most expedient solution is to ad the field as Tim suggests.

Tim:

Thanks for all of the work.  This clearly was a lot of effort.

Russ

At 11:06 AM 1/26/2006, Tim Polk wrote:

>3379 Requirement #14. The DPV server MUST be able, upon request, 
>copy a text field provided by the client into the DPV response. (4.1 
>Basic Protocol)
>
>SCVP Draft 22:
>
>This requirement is poorly addressed in scvp-21
>
>An SCVP request may include a requesterRef, which is a SEQUENCE of 
>GeneralNames.
>
>"If the SCVP client includes a requestorRef value in the request, 
>then the SCVP server MUST return the same value if the server is 
>generating a non-cached response." Section 4.7
>
>One legal value for a GeneralName is an IA5string, so we could argue 
>that it is met, but this is a very poor fit.
>
>Proposed Resolution:
>
>Add an optional item, requesterText, to both the CVRequest and 
>CVResponse sequences.  The responseText would be UTF8String, maximum 
>size 256 characters.  There would be no semantics; the server would 
>be required to copy the value from the CVRequest into the CVResponse 
>for all non-cached responses.



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 k0V0JkP2039144; Mon, 30 Jan 2006 16:19:46 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k0V0Jk0X039143; Mon, 30 Jan 2006 16:19:46 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] 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 k0V0JiAl039137 for <[e-mail]>; Mon, 30 Jan 2006 16:19:44 -0800 (PST) (envelope-from [e-mail])
Received: from wmcooper2 (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 k0V0Jci2004391; Mon, 30 Jan 2006 19:19:43 -0500
From: "Matt Cooper" <[e-mail]>
To: "'Keutel, Jochen'" <[e-mail]>, <[e-mail]>
Subject: RE: again: pmiUser ...
Date: Mon, 30 Jan 2006 19:19:32 -0500
Message-ID: <00dc01c625fc$08d486d0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670
Thread-Index: AcX+pAkPiLNrW/dWRySQpGUbgRYL+QnUs7xw
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Perhaps I am incorrect, but I would think your initial finding of pmiUser ->
attributeCertificateAttribute would be an appropriate object class and
attribute.  At least one commercial product does this.

pmiUser OBJECT-CLASS ::= {
  SUBCLASS OF  {top}
  KIND         auxiliary
  MAY CONTAIN  {attributeCertificateAttribute}
  ID           id-oc-pmiUser
}

attributeCertificateAttribute ATTRIBUTE ::= {
  WITH SYNTAX             AttributeCertificate
  EQUALITY MATCHING RULE  attributeCertificateExactMatch
  ID                      id-at-attributeCertificate
}

http://www.itu.int/ITU-T/asn1/database/itu-t/x/x509/2000/AttributeCertificat
eDefinitions.html
 

Best Regards,

Matt


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Keutel, Jochen
Sent: Sunday, December 11, 2005 4:17 PM
To: [e-mail]
Subject: again: pmiUser ...


Hello,
   I didn't get any answer on the question I asked some days ago (see
below). So, let me ask this as follows:

Do you store attribute certificates in LDAP directories? If so:
Which object class are you using?

Bye, Jochen.

---

Hello,
   X.509 defines the LDAP object class pmiUser and the attribute
attributeCertificateAttribute.

I can't find these definitions in LDAP RFCs oder non-expired drafts ...
I found

http://tools.ietf.org/wg/pkix/draft-ietf-pkix-ldap-pmi-schema/draft-ietf-pki
x-ldap-pmi-schema-00.txt

- but it's from June, 2002 ...

Did I miss an I-D and/or RFC?

Regards,  Jochen.



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 k0QNIE8x097200; Thu, 26 Jan 2006 15:18:14 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k0QNIEIk097199; Thu, 26 Jan 2006 15:18:14 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] 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 k0QNIDDD097192 for <[e-mail]>; Thu, 26 Jan 2006 15:18:14 -0800 (PST) (envelope-from [e-mail])
Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id k0QNIAac029691 for <[e-mail]>; Thu, 26 Jan 2006 18:18:10 -0500
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 k0QNHr3u013441 for <[e-mail]>; Thu, 26 Jan 2006 18:17:54 -0500 (EST)
Message-ID: <[e-mail]>
Date: Thu, 26 Jan 2006 18:18:57 -0500
From: "David A. Cooper" <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.11) Gecko/20050729
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: pkix <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-scvp-22.txt
References: <[e-mail]>
In-Reply-To: <[e-mail]>
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: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

[e-mail] 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		: Standard Certificate Validation Protocol (SCVP)
>	Author(s)	: A. Malpani, et al.
>	Filename	: draft-ietf-pkix-scvp-22.txt
>	Pages		: 82
>	Date		: 2006-1-23
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-pkix-scvp-22.txt
>  
>
I have posted a "diff" file on the NIST Web site showing the differences 
between drafts 21 and 22 of SCVP.  It is available at:

    
http://csrc.nist.gov/pki/documents/PKIX/wdiff_draft-ietf-pkix-scvp-21_to_22.html

Draft 22 includes changes that were made to address the requirement for 
algorithm agility, but does not include changes to address any other issues.

As was agreed during the November IETF meeting, ESSCertID has been 
replaced with a data structure that allows the use of any hash algorithm 
rather than being limited to SHA-1.  The hash algorithm used to compute 
the hash of the certificate is specified as part of the data structure.  
The default value for the hash algorithm is SHA-1, so that the DER 
encoding of the data structure is the same as the DER encoding of 
ESSCertID when SHA-1 is used.

Since ESSCertID was the only data structure that hard coded the use of a 
particular cryptographic algorithm, no other data structures needed to 
be changed to allow for algorithm agility.  However, changes needed to 
be made to the protocol in order to allow the client and server to 
signal their capabilities to each other.

In draft 22, the SCVP server signals its capabilities to the client in 
its validation policy response message.  When the client is using 
cryptography in creating its request message, it should choose 
cryptographic algorithms based on the server's indicated capabilities.  
When the server will need to use cryptography in creating the response, 
the client should indicate which algorithm(s) the server should use by 
selecting from the set of algorithms that the server indicates in its 
validation policy response message that it can support.

There are four places that cryptography is used: when the client sends 
an authenticated request to the server; when the server sends an 
authenticated response to the client; when a certificate is specified by 
reference; and when the response includes a hash of the request.

Authenticated request messages may be either digitally signed or MACed.  
For digitally signed request messages, the server indicates the set of 
digital signature algorithms that it is capable of validating 
(signatureVerification).  When key agreement is used, the 
serverPublicKeys item in the validation policy response message 
indicates the set of key agreement keys that the server holds along with 
the key derivation function (KDF) and MAC algorithm that should be used 
with each key.  When pre-shared secret keys are used, it is expected 
that the client will know what MAC algorithm to use through out-of-band 
means.

It is expected that the server's response will be protected with a MAC 
only if the client's request was similarly protected or if there is a 
pre-shared secret key between the client and server.  If the client's 
request was protected with a MAC, the server will use the same 
algorithm(s) to protect the response.  In the case of pre-shared secret 
keys, it is expected that the algorithm to use will be determined 
through out-of-band means.

For digitally signed response messages (CVResponse messages), the server 
indicates in its validation policy response message the set of 
algorithms with with it can sign (signatureGeneration).  That is, it 
lists the algorithms for which its cryptographic module is capable of 
generating the signature and for which it has a certified public key.  
The first algorithm in the signatureGeneration sequence is designated as 
the server's default signature algorithm.  Clients requesting a 
digitally signed CVResponse message may either accept the server's 
default signature algorithm or may specify that the response is to be 
signed using one of the other algorithms listed in the 
signatureGeneration item from the server's validation policy response 
message.

The server's validation policy response message also indicates the set 
of hash algorithms that the server supports (hashAlgorithms), with the 
algorithm in the sequence being the server's default hash algorithm.  If 
the client includes a certificate by reference in its request (either in 
the queriedCerts or trustAnchors item, then the client must use one of 
these algorithms to compute the certHash.  If the client wishes the 
server's response message to include a hash of the request 
(requestHash), the client may either accept the server's default hash 
algorithm or may specify which of the hash algorithms from the 
hashAlgorithms item in the server's validation policy response message 
the server is to use to compute requestHash.

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 k0QLgSAJ091599; Thu, 26 Jan 2006 13:42:28 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k0QLgS0X091598; Thu, 26 Jan 2006 13:42:28 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id k0QLgR0v091592 for <[e-mail]>; Thu, 26 Jan 2006 13:42:28 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 26208 invoked by uid 0); 26 Jan 2006 21:42:20 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.9.167) by woodstock.binhost.com with SMTP; 26 Jan 2006 21:42:20 -0000
Message-Id: <[e-mail]>
X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16
Date: Thu, 26 Jan 2006 16:42:23 -0500
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: SCVP-22 Open Issue: RFC 3379 Requirement #29
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I do not see any value in making a change here.  I suggest that we 
add a section to the Introduction, stating that this protocol meets 
all of the requirements in RFC 3379.  Then go on to say that when 
SCVP is used for DPD, the response is the same when a path is 
constructed, but some and all of the revocation information is 
unavailable.  Provide the text from RFC 3379 and say that 2 and 3 
will result in the same response as some of the revocation 
information is not available.

Russ


At 11:06 AM 1/26/2006, Tim Polk wrote:

>3379 Requirement #29. Path discovery MUST be performed according to 
>the path discovery policy.  The DPD response MUST indicate one of 
>the following status alternatives:
>1.      one or more certification paths was found according to the 
>path discovery policy, with all of the requested revocation 
>information present.
>2.      one or more certification paths was found according to the 
>path discovery policy, with a subset of the requested revocation 
>information present.
>3.      one or more certification paths was found according to the 
>path discovery policy, with none of the requested revocation 
>information present.
>4.      no certification path was found according to the path 
>discovery policy.
>5.      path construction could not be performed due to an error.
>(Source for 29: 5. Delegated Path Discovery Protocol)
>
>SCVP Draft 22:
>
>This requirement is not fully satisfied.  The DPD response will not 
>differentiate between states 2 and 3 as described in requirement 29.
>
>The replyStatus item gives status information to the client about 
>the request for the specific certificate.
>
>State 1:  If one or more certification paths was found according to 
>the path discovery policy, with all of the requested revocation 
>information present, the replyStatus will be 0:
>
>"0  Success: all checks were performed successfully."
>
>State 2:  If one or more certification paths was found according to 
>the path discovery policy, but only a subset of the requested 
>revocation information was available, the replyStatus will be 8:
>
>"8  Failure: all checks were performed successfully, however one or
>        more of the wantBacks could not be satisfied."
>
>State 3: If one or more certification paths was found according to 
>the path discovery policy, but only a subset of the requested 
>revocation information was available, the replyStatus will be 8:
>
>"8  Failure: all checks were performed successfully, however one or
>        more of the wantBacks could not be satisfied."
>
>State 4: If no certification path was found according to the path 
>discovery policy, the replyStatus will be 5:
>
>"5  Failure: no certification path could be constructed."
>
>State 5:  If path construction could not be performed due to an 
>error, the replyStatus will be 1, 2, 3, or 4:
>
>"  1  Failure: the public key certificate was malformed.
>     2  Failure: the attribute certificate was malformed.
>     3  Failure: historical data for the requested validity time is not
>        available.
>     4  Failure: the server could not locate the reference certificate or
>        the referenced certificate did not match the hash value
>        provided."
>
>(Section 4.9.2)
>
>Possible resolution:  This requirement could be met by adding two 
>additional reply check status codes for  { id-stc 1} -- but we do 
>not see any value in this change!
>



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 k0QLYjqt091274; Thu, 26 Jan 2006 13:34:45 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k0QLYjjr091273; Thu, 26 Jan 2006 13:34:45 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id k0QLYi1b091267 for <[e-mail]>; Thu, 26 Jan 2006 13:34:45 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 20315 invoked by uid 0); 26 Jan 2006 21:34:38 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.9.167) by woodstock.binhost.com with SMTP; 26 Jan 2006 21:34:38 -0000
Message-Id: <[e-mail]>
X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16
Date: Thu, 26 Jan 2006 16:34:40 -0500
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: SCVP-22 Open Issue: RFC 3379 Requirement #23
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

All:

I think this is a straightforward one.  I propose the following text changes:

OLD:

     - id-swb-pkc-revocation-info: Proof of revocation status for each
        certificate in the certification path;

NEW:

     - id-swb-pkc-revocation-info: Proof of revocation status for each
        certificate in the certification path;

     - id-swb-pkc-ee-revocation-info: Proof of revocation status for the
        end-entity certificate;

     - id-swb-pkc-ca-revocation-info: Proof of revocation status for each
        issuer certificate in the certification path;


Then, this change needs to be made in two places:

OLD:

      id-swb-pkc-revocation-info     OBJECT IDENTIFIER ::= { id-swb 2 }

NEW:

      id-swb-pkc-revocation-info     OBJECT IDENTIFIER ::= { id-swb 2 }
      id-swb-pkc-ee-revocation-info  OBJECT IDENTIFIER ::= { id-swb 13 }
      id-swb-pkc-ca-revocation-info  OBJECT IDENTIFIER ::= { id-swb 14 }

Russ


At 11:06 AM 1/26/2006, Tim Polk wrote:
>3379 Requirement #23. Clients MUST be able to specify whether they 
>want, in addition to the certification path, the revocation 
>information associated with the path, for the end-entity 
>certificate, for the CA certificates, or for both. (5. Delegated 
>Path Discovery Protocol)
>SCVP Draft 22:
>
>SCVP does not permit the client to request status for just the EE 
>certificate or just the CA certificates.  Clients that request 
>status get status information for the entire path.
>
>The SCVP client requests this information by asserting the wantback
>
>"   - id-swb-pkc-revocation-info: Proof of revocation status for 
>each certificate in the certification path;"
>Section 3.2.3
>
>Propose adding two new wantbacks, id-swb-ee-revocation-info and 
>id-swb-CAs-revocation-info with the appropriate functionality.



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 k0QLMOkl090517; Thu, 26 Jan 2006 13:22:24 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k0QLMOaJ090516; Thu, 26 Jan 2006 13:22:24 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id k0QLMNRv090509 for <[e-mail]>; Thu, 26 Jan 2006 13:22:23 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 10872 invoked by uid 0); 26 Jan 2006 21:22:16 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.9.167) by woodstock.binhost.com with SMTP; 26 Jan 2006 21:22:16 -0000
Message-Id: <[e-mail]>
X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16
Date: Thu, 26 Jan 2006 16:22:17 -0500
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: SCVP-22 Open Issue: RFC 3379 Requirement #14
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

All:

I am starting a thread for each of the open issues.  Hopefully, these 
can be brought to closure very quickly.

One could also argue that the Nonce could be used to meet this 
requirement, but like requestorRef, this is not really a good fit.

I think the most expedient solution is to ad the field as Tim suggests.

Tim:

Thanks for all of the work.  This clearly was a lot of effort.

Russ

At 11:06 AM 1/26/2006, Tim Polk wrote:

>3379 Requirement #14. The DPV server MUST be able, upon request, 
>copy a text field provided by the client into the DPV response. (4.1 
>Basic Protocol)
>
>SCVP Draft 22:
>
>This requirement is poorly addressed in scvp-21
>
>An SCVP request may include a requesterRef, which is a SEQUENCE of 
>GeneralNames.
>
>"If the SCVP client includes a requestorRef value in the request, 
>then the SCVP server MUST return the same value if the server is 
>generating a non-cached response." Section 4.7
>
>One legal value for a GeneralName is an IA5string, so we could argue 
>that it is met, but this is a very poor fit.
>
>Proposed Resolution:
>
>Add an optional item, requesterText, to both the CVRequest and 
>CVResponse sequences.  The responseText would be UTF8String, maximum 
>size 256 characters.  There would be no semantics; the server would 
>be required to copy the value from the CVRequest into the CVResponse 
>for all non-cached responses.



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 k0QIfuI3078239; Thu, 26 Jan 2006 10:41:57 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k0QIfuZf078238; Thu, 26 Jan 2006 10:41:56 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] 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 k0QIftZk078229 for <[e-mail]>; Thu, 26 Jan 2006 10:41:56 -0800 (PST) (envelope-from [e-mail])
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 k0QIfnIC001099; Thu, 26 Jan 2006 13:41:49 -0500 (EST)
Mime-Version: 1.0
Message-Id: <p06230911bffec7ab116e@[128.89.89.106]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Thu, 26 Jan 2006 13:41:57 -0500
To: Tim Polk <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: RFC 3379 Compliance Matrix: SCVP draft 22 (intro)
Cc: [e-mail]
Content-Type: multipart/alternative; boundary="============_-1073821574==_ma============"
X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--============_-1073821574==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Tim,

Thanks to you and the other authors of SCVP for doing this in 
response to my request.

I hereby solicit comments from the WG on the compliance matrix that 
Tim sent in subsequent messages.  I plan to make a determination on 
forwarding SCVP to the IESG in about two weeks.  Please get comments 
to me before then.

Thanks,

Steve
--============_-1073821574==_ma============
Content-Type: text/html; charset="us-ascii"

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></style><title>Re: RFC 3379 Compliance Matrix: SCVP draft 22
(intro)</title></head><body>
<div>Tim,</div>
<div><br></div>
<div>Thanks to you and the other authors of SCVP for doing this in
response to my request.</div>
<div><br></div>
<div><b>I hereby solicit comments from the WG on the compliance matrix
that Tim sent in subsequent messages.&nbsp; I plan to make a
determination on forwarding SCVP to the IESG in about two weeks.&nbsp;
Please get comments to me before then.</b></div>
<div><br></div>
<div>Thanks,</div>
<div><br></div>
<div>Steve</div>
</body>
</html>
--============_-1073821574==_ma============--



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 k0QGICN9065548; Thu, 26 Jan 2006 08:18:12 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k0QGICOn065547; Thu, 26 Jan 2006 08:18:12 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] 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 k0QGIAQg065540 for <[e-mail]>; Thu, 26 Jan 2006 08:18:11 -0800 (PST) (envelope-from [e-mail])
Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id k0QGC6Ho011490; Thu, 26 Jan 2006 11:12:08 -0500
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 k0QGB33v024174; Thu, 26 Jan 2006 11:11:04 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 26 Jan 2006 11:11:46 -0500
To: [e-mail]
From: Tim Polk <[e-mail]>
Subject: 3379 Compliance Matrix: SCVP-22 (3 of 3)
Cc: [e-mail]
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: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id k0QGIBQg065541
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

[RFC 3379 requirements 25 through 34]

3379 Requirement #25. The DPD request MUST allow more elaborated path 
discovery policies to be referenced. (5. Delegated Path Discovery Protocol)

SCVP Draft 22:

The SCVP client either specifies a particular validation policy or the 
server’s default policy as an object identifier in the validationPolRef 
item.  (section 3.2.4.1)  The parameters associated with this policy may be 
modified through the use of optional items in the validationPolicy. 
(sections 3.2.4.1 through 3.2.4.9)

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


3379 Requirement #26. If the trust anchor is a self-signed certificate, 
that self-signed certificate MUST NOT be included.  In addition, if 
requested, the revocation information associated with each certificate in 
the path MUST also be returned. (5. Delegated Path Discovery Protocol)

SCVP Draft 22:

DPD servers do not include the self-signed certificate in the returned path.

“The octet string value for the certification path used to verify the 
certificate in the request, { id-swb 1 }, contains the CertBundle 
type.  …  This CertBundle includes all the certificates in the path, 
starting with the end certificate and ending with the certificate issued by 
the trust anchor.”
Section 4.9.5

“The octet string value for the proof of revocation status, { id-swb 2 }, 
contains the RevInfoWantBack type.  The RevInfoWantBack type is a SEQUENCE 
of the RevocationInfos type and an optional CertBundle. The syntax and 
semantics of the RevocationInfos type are described in section 3.2.9.  The 
CertBundle MUST be included if any certificates required to validate the 
revocation information were not returned in the id-swb-pkc-best-cert-path 
or id-swb-pkc-all-cert-paths want back.  The CertBundle MUST include all 
such certificates but there are no ordering requirements.

      RevInfoWantBack ::= SEQUENCE {
        revocationInfo             RevocationInfos,
        extraCerts                 CertBundle OPTIONAL }”
Section 4.9.5

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


3379 Requirement #27. By default, the DPD server MUST return a single 
certification path for each end-entity certificate in the DPD request. (5. 
Delegated Path Discovery Protocol)

SCVP Draft 22:

DPD clients specify the wantback id-swb-pkc-best-cert-path:

“- id-swb-pkc-best-cert-path: The certification path built for the 
certificate including the certificate that was validated;”
Section 3.2.3

“The octet string value for the certification path used to verify the 
certificate in the request, { id-swb 1 }, contains the CertBundle 
type.  …  This CertBundle includes all the certificates in the path, 
starting with the end certificate and ending with the certificate issued by 
the trust anchor.”
Section 4.9.5

If the DPD client checks revocation information, it will also spefiy the 
wantback id-swb-pkc-revocation-info:

“    - id-swb-pkc-revocation-info: Proof of revocation status for 
eachcertificate in the certification path;”
Section 3.2.3

“The octet string value for the proof of revocation status, { id-swb 2 }, 
contains the RevInfoWantBack type.  The RevInfoWantBack type is a SEQUENCE 
of the RevocationInfos type and an optional CertBundle. The syntax and 
semantics of the RevocationInfos type are described in section 3.2.9.  The 
CertBundle MUST be included if any certificates required to validate the 
revocation information were not returned in the id-swb-pkc-best-cert-path 
or id-swb-pkc-all-cert-paths want back.  The CertBundle MUST include all 
such certificates but there are no ordering requirements.

      RevInfoWantBack ::= SEQUENCE {
        revocationInfo             RevocationInfos,
        extraCerts                 CertBundle OPTIONAL }”
Section 4.9.5

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


3379 Requirement #28. Therefore, the DPD client MUST have a means of 
obtaining more than one certification path for each end-entity certificate 
in the DPD request.  At the same time, the mechanism for obtaining 
additional certification paths MUST NOT impose protocol state on the DPD 
server. (5. Delegated Path Discovery Protocol)

SCVP Draft 22:

SCVP includes two mechanisms for obtaining additional paths:

(1) If the DPD client wishes to get all the paths the DPD server can find, 
the client asserts the wantback id-swb-pkc-all-cert-paths:

“- id-swb-pkc-all-cert-paths: A set of certification paths for the 
certificate.”
(Section 3.2.3)

“The octet string value for returning all paths, { id-swb 12 }, contains an 
ASN.1 type CertBundles, as defined below.  The syntax and semantics of the 
CertBundle type are described in section 3.2.8. Each CertBundle includes 
all the certificates in one path, starting the end certificate and ending 
with the certificate issued by the trust anchor.

       CertBundles ::= SEQUENCE SIZE (1..MAX) OF CertBundle”

(Section 4.9.5)

No state is imposed by this mechanism, since multiple paths are returned 
from a single request.

(2) The client may also request a single path at a time.  If the server 
detects multiple paths, it may include a serverContextInfo item in the 
response.  If the client does not like the certification path returned, it 
can make a new query and pass along this context information.  After 
obtaining each path, the client could submit the serverContextInfo from the 
previous request to obtain another path until the client either found a 
suitable path or the server indicated (by not returning a 
serverContextInfo) that no more paths were available.

The server may choose to implement serverContextInfo so that all necessary 
state information is embedded in the opaque blob, so state is not imposed 
by the protocol.  (A stateful implementation is also possible, of course.)

(Sections 3.2.6 and 4.11)

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


3379 Requirement #29. Path discovery MUST be performed according to the 
path discovery policy.  The DPD response MUST indicate one of the following 
status alternatives:
1.	one or more certification paths was found according to the path 
discovery policy, with all of the requested revocation information present.
2.	one or more certification paths was found according to the path 
discovery policy, with a subset of the requested revocation information 
present.
3.	one or more certification paths was found according to the path 
discovery policy, with none of the requested revocation information present.
4.	no certification path was found according to the path discovery policy.
5.	path construction could not be performed due to an error.
(Source for 29: 5. Delegated Path Discovery Protocol)

SCVP Draft 22:

This requirement is not fully satisfied.  The DPD response will not 
differentiate between states 2 and 3 as described in requirement 29.

The replyStatus item gives status information to the client about the 
request for the specific certificate.

State 1:  If one or more certification paths was found according to the 
path discovery policy, with all of the requested revocation information 
present, the replyStatus will be 0:

“0  Success: all checks were performed successfully.”

State 2:  If one or more certification paths was found according to the 
path discovery policy, but only a subset of the requested revocation 
information was available, the replyStatus will be 8:

“8  Failure: all checks were performed successfully, however one or
        more of the wantBacks could not be satisfied.”

State 3: If one or more certification paths was found according to the path 
discovery policy, but only a subset of the requested revocation information 
was available, the replyStatus will be 8:

“8  Failure: all checks were performed successfully, however one or
        more of the wantBacks could not be satisfied.”

State 4: If no certification path was found according to the path discovery 
policy, the replyStatus will be 5:

“5  Failure: no certification path could be constructed.”

State 5:  If path construction could not be performed due to an error, the 
replyStatus will be 1, 2, 3, or 4:

“  1  Failure: the public key certificate was malformed.
     2  Failure: the attribute certificate was malformed.
     3  Failure: historical data for the requested validity time is not
        available.
     4  Failure: the server could not locate the reference certificate or
        the referenced certificate did not match the hash value
        provided.”

(Section 4.9.2)

Possible resolution:  This requirement could be met by adding two 
additional reply check status codes for  { id-stc 1} -- but we do not see 
any value in this change!

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


3379 Requirement #30.   For the client to be confident that all of the 
elements from the response originate from the expected DPD server, an 
authenticated response MAY be required.  For example, the server might sign 
the response or data authentication might also be achieved using a 
lower-layer security protocol. (5. Delegated Path Discovery Protocol)

SCVP Draft 22:


“The protectResponse item indicates whether the client requires the server 
to protect the response.”  If asserted, the server digitally signs or MACs 
the response.

“SCVP servers MUST support returning protected responses”
(Section 3.2.5.3)

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


3379 Requirement #31. The DPD server MAY require client authentication, 
allowing the DPD request MUST to be authenticated. (5. Delegated Path 
Discovery Protocol)

SCVP Draft 22:

“A server MAY require all requests to be protected, and a server MAY 
discard all unprotected requests.  Alternatively, a server MAY choose to 
process unprotected requests.”
(Section 3)

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


3379 Requirement #32. Using a separate request/response pair, the DPV or 
DPD client MUST be able to obtain references for the default policy or for 
all of the policies supported by the server. (6. DPV and DPD Policy Query)

SCVP Draft 22:

An SCVP client uses the Server Policy Request (i.e., the ValPolRequest 
item) “to request information about an SCVP server's policies and 
configuration information, including the list of validation policies 
supported by the SCVP server.”
(Section 5)
“In response to a ValPolRequest, the SCVP server provides a ValPolResponse.”

The ValPolResponse includes a comprehensive description of the default 
validation policy, as well as a list of all policies supported by the server.
(Section 6)

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


3379 Requirement #33. In order to succeed, one valid certification path 
(none of the certificates in the path are expired or revoked) MUST be found 
between an end-entity certificate and a trust anchor and all constraints 
that apply to the certification path MUST be verified. (7. Validation Policy)

SCVP Draft 22:

The replyStatus item gives status information to the client about the 
request for the specific certificate.

If one or more certification paths was found according to the validation 
policy, and all requested information  will be 0:

“0  Success: all checks were performed successfully.”

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


3379 Requirement #34. The validation policy MUST specify the source of 
revocation information:
1.	full CRLs (or full Authority Revocation Lists) have to be collected.
2.	OCSP responses, using [OCSP], have to be collected.
3.	delta CRLs and the relevant associated full CRLs (or full Authority 
Revocation Lists) are to be collected.
4.	any available revocation information has to be collected.
5.	no revocation information need be collected.
(Source for 34: 7.3. Revocation Requirements)

SCVP Draft 22:

The valPolResponse includes the revocationInfoTypes item.

RevocationInfoTypes ::= BIT STRING {
        fullCRLs                   (0),
        deltaCRLs                  (1),
        indirectCRLs               (2),
        oCSPResponses              (3) }

revocationInfoTypes allows the server to indicate the sources of revocation 
information that it is capable of processing.  For each bit in the 
RevocationInfoTypes bit string, the server MUST set the bit to one if it is 
capable of processing the corresponding revocation information type and to 
zero if it can not.

(Sections 6 and 6.11)




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 k0QGAHhh065079; Thu, 26 Jan 2006 08:10:17 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k0QGAH8w065078; Thu, 26 Jan 2006 08:10:17 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] 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 k0QGAF5K065070 for <[e-mail]>; Thu, 26 Jan 2006 08:10:16 -0800 (PST) (envelope-from [e-mail])
Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id k0QGA6Dd010261; Thu, 26 Jan 2006 11:10:07 -0500
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 k0QG9a3v023384; Thu, 26 Jan 2006 11:09:36 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 26 Jan 2006 11:10:18 -0500
To: [e-mail]
From: Tim Polk <[e-mail]>
Subject: 3379 Compliance Matrix: SCVP-22 (2 of 3)
Cc: [e-mail]
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: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id k0QGAG5K065073
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

[RFC 3379 requirements 13 through 24]



3379 Requirement #13. The DPV request MUST allow the client to request that 
the server include in its response additional information which will allow 
relying parties not trusting the DPV server to be confident that the 
certificate validation has correctly been performed. […]When the 
certificate is valid according to the validation policy, the server MUST, 
upon request, include that information in the response.  However, the 
server MAY omit that information when the certificate is invalid or when it 
cannot determine the validity. (4.1 Basic Protocol)

SCVP Draft 22:

Where requested, an SCVP server must return the certification path, status 
information (CRLs, OCSP responses and SCVP responses) and additional 
certificates required to validate the status information. This information 
is sufficient to verify that the validation has been performed correctly.

The SCVP client requests this information by asserting the wantbacks

“  - id-swb-pkc-best-cert-path: The certification path built for the 
certificate including the certificate that was validated;

     - id-swb-pkc-revocation-info: Proof of revocation status for each 
certificate in the certification path;

      - id-swb-relayed-responses: Any SCVP responses received by the server 
that were used to generate the response to this query.”
Section 3.2.3

Support for these wantbacks is optional for DPV servers and required for 
DPD servers:

“Conforming SCVP server implementations that support delegated path 
discovery (DPD) as defined in [RQMTS] MUST support the 
id-swb-pkc-best-cert-path and id-swb-pkc-revocation-info wantBacks.”
Section 3.2.3

If the requester asserts these codes and the SCVP server does not support 
them, the SCVP server must return the CVStatusCode “unsupportedWantBacks”
(Section 4.4)

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


3379 Requirement #14. The DPV server MUST be able, upon request, copy a 
text field provided by the client into the DPV response. (4.1 Basic Protocol)

SCVP Draft 22:

This requirement is poorly addressed in scvp-21

An SCVP request may include a requesterRef, which is a SEQUENCE of 
GeneralNames.

“If the SCVP client includes a requestorRef value in the request, then the 
SCVP server MUST return the same value if the server is generating a 
non-cached response.” Section 4.7

One legal value for a GeneralName is an IA5string, so we could argue that 
it is met, but this is a very poor fit.

Proposed Resolution:

Add an optional item, requesterText, to both the CVRequest and CVResponse 
sequences.  The responseText would be UTF8String, maximum size 256 
characters.  There would be no semantics; the server would be required to 
copy the value from the CVRequest into the CVResponse for all non-cached 
responses.

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


3379 Requirement #15. The DPV response MUST be bound to the DPV request so 
that the client can be sure that all the parameters from the request have 
been taken into consideration by the DPV server to build the 
response.  This can be accomplished by including a one-way hash of the 
request in the  response. In some environments it may be necessary to 
present only a DPV response to another relying party without the 
corresponding request. In this case the response MUST be self 
contained.  This can be accomplished by repeating only the important 
components from the request in the response. (4.1 Basic Protocol)

SCVP Draft 22:

“By default, the server includes a hash of the request in non-cached 
responses to allow the client to identify the response.  If the client 
wants the server to include the full request in the non-cached response, 
fullRequestInResponse is set to TRUE. (section 3.2.5.1)

The DPV response and request are bound through inclusion of a hash of the 
request, or the request itself, for all non-cached responses.

If the requester chooses to accept cached responses, the client can still 
verify the binding by comparing the parameters from the request, such as 
the requested certificate and the validation policy, with the parameters in 
the cached response.

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


3379 Requirement #16. For the client to be confident that the certificate 
validation was handled by the expected DPV server, the DPV response MUST be 
authenticated, unless an error is reported (such as a badly formatted 
request or unknown validation policy).For the client to be able prove to a 
third party that trusts the same DPV server that the certificate validation 
was handled correctly, the DPV response MUST be digitally signed, unless an 
error is reported. The DPV server's certificate MUST authenticate the DPV 
server. (4.1 Basic Protocol)

SCVP Draft 22:
“The protectResponse item indicates whether the client requires the server 
to protect the response. …

    SCVP clients that support delegated path validation (DPV) as defined in 
[RQMTS] require an authenticated response.  Unless a protected transport 
mechanism (such a TLS) is used, such clients MUST always set this value to 
TRUE or omit the responseFlags item entirely, which requires the server to 
return a protected response.

    SCVP servers MUST support returning protected responses…”

(Section 3.2.5.3)

If the client requests a protected response and signs the request, the 
server is required to sign the response.

(Section 4)


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


3379 Requirement #17. The DPV server MAY require client authentication, 
therefore, the DPV request MUST be able to be authenticated. (4.1 Basic 
Protocol)

SCVP Draft 22:

“There are two forms of SCVP request: unprotected and protected.  A 
protected request is used to authenticate the client to the server or to 
provide anonymous client integrity over the request-response pair.  The 
protection is provided by a digital signature or message authentication 
code (MAC).  In the later case, the MAC key is derived using a key 
agreement algorithm, such as Diffie-Hellman.  If the client's public key is 
contained in a certificate, then it may be used to authenticate the 
client.  More commonly, the client's key agreement public key will be 
ephemeral, supporting anonymous client integrity.

A server MAY require all requests to be protected, and a server MAY discard 
all unprotected requests.  Alternatively, a server MAY choose to process 
unprotected requests.”

Section 3.

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


3379 Requirement #18. When the DPV request is authenticated, the client 
SHOULD be able to include a client identifier in the request for the DPV 
server to copy into the response.  Mechanisms for matching this identifier 
with the authenticated identity depends on local DPV server conditions 
and/or the validation policy.  The DPV server MAY choose to blindly copy 
the identifier, omit the identifier, or return an error response. (4.1 
Basic Protocol)

SCVP Draft 22:


“The optional requestorName item is used by the client to include an 
identifier in the request.  The client MAY include this information for the 
DPV server to copy into the response.

Conforming SCVP clients MAY support specification of this item in 
requests.  SCVP servers MUST be able to process requests that include this 
item.”

Section 3.5

“The optional requestorName item is used by the server to return one or 
more identities associated with the client in the response.

The SCVP server MAY choose to include any or all of the following:

      (1) the identity asserted by the client in the requestorName item of 
the request,
      (2) an authenticated identity for the client from a certificate or 
other credential used to authenticate the request, or
      (3) a client identifier from an out-of-band mechanism.

Alternatively, the SCVP server MAY omit this item.”

(Section 4.8)

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


3379 Requirement #19. Protocols designed to satisfy these requirements MAY 
include optional fields and/or extensions to support relaying, re-direction 
or multicasting.  […]  If the protocol supports such features, the protocol 
MUST include provisions for DPV clients and DPV servers that do not support 
such features, allowing them to conform to the basic set of requirements. 
(4.2. Relaying, Re-direction and Multicasting)

SCVP Draft 22:

Servers that do not support redirection or relay are not required to 
process the requestorRef item or the responderName item.  The former is 
used for loop control, and is irrelevant for a server that does not itself 
relay requests.  The latter item identifies the intended signer, but 
servers that do not re-direct and sign under a single identity are not 
required to process this field.

As a general rule, redirection and relay are transparent to the 
client.  Clients are aware of redirection or relay only if they (1) wish to 
prompt redirection (through the responderName) or (2) request SCVP 
responses in the wantbacks.

(sections 3.2.3, 3.3, 3.6, 7)

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


3379 Requirement #20. When a server supports a relay mechanism, a mechanism 
to detect loops or repetition MUST be provided. (4.2. Relaying, 
Re-direction and Multicasting)

SCVP Draft 22:

“When an SCVP server relays a request, the request MUST include the 
requestorRef item.  If the request to be relayed already contains a 
requestorRef item, then the server-generated request MUST contain a 
requestorRef item constructed from this value followed by a GeneralName 
that contains an identifier of the SCVP server.  If the request to be 
relayed does not contain a requestorRef item, then the server-generated 
request MUST contain a requestorRef item that includes a GeneralName that 
contains an identifier of the SCVP server.

When an SVCP server receives a request that contains a requestorRef item, 
the server MUST check the sequence of names in the requestorRef item for 
its own identifier.  If the server discovers its own identifier in the 
requestor item, it MUST respond with an error, setting the cvResponseStatus 
to 40.”

(Section 7)

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


3379 Requirement #21. When a protocol provides the capability for a DPV 
server to redirect a request to another DPV server (that is, the protocol 
chooses to provide a referral mechanism), a mechanism to provide 
information to be used for the re-direction SHOULD be supported. If such 
re-direction information is sent back to clients, then the protocol MUST 
allow conforming clients to ignore it. (4.2. Relaying, Re-direction and 
Multicasting)

SCVP Draft 22:
The client can manage redirection by including the responderName item.  The 
optional responderName item is used by the client to indicate the identity 
of the SCVP server that the client expects to sign the SCVP response if the 
response is digitally signed.  If the server that receives this request 
behaves as a proxy, it can use this field to determine where to direct the 
request.  The success of the redirection can be established by verifying 
the signature on the response.  The processing server returns its response 
to the proxy, which passes the SCVP response to the client.

(Sections 3.6 and 7)

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


3379 Requirement #22. Optional parameters in the protocol request and/or 
response MAY be provide support for relaying, re-direction or 
multicasting.  DPV clients that ignore any such optional parameters MUST be 
able to use the DPV service.  DPV servers that ignore any such optional 
parameters MUST still be able to offer the DPV service, although they might 
not be able to overcome the limitations imposed by the network 
topology.  In this way, protocol implementers do not need to understand the 
syntax or semantics of any such optional parameters. (4.2. Relaying, 
Re-direction and Multicasting)

SCVP Draft 22:

If an SCVP server returns a response that reflects the results of relay or 
redirection, this will be transparent to the client unless the client 
requested SCVP responses in the wantbacks.

- id-swb-relayed-responses: Any SCVP responses received by the server that 
were used to generate the response to this query.

In this case, any SCVP responses used by the server will be included in the 
response in replyWantBacks:

“The octet string value for relayed responses, { id-swb 13 }, contains an 
ASN.1 type SCVPResponses, as defined below.  If the SCVP server used 
information obtained from other SCVP servers when generating this response, 
then SCVPResponses MUST include each of the SCVP responses received from 
those servers.  If the SCVP server did not use information obtained from 
other SCVP servers when generating the response, then SCVPResponses MUST be 
an empty sequence.

(Sections 3.2.3, 4.9.5)

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


3379 Requirement #23. Clients MUST be able to specify whether they want, in 
addition to the certification path, the revocation information associated 
with the path, for the end-entity certificate, for the CA certificates, or 
for both. (5. Delegated Path Discovery Protocol)
SCVP Draft 22:

SCVP does not permit the client to request status for just the EE 
certificate or just the CA certificates.  Clients that request status get 
status information for the entire path.

The SCVP client requests this information by asserting the wantback

“   - id-swb-pkc-revocation-info: Proof of revocation status for each 
certificate in the certification path;”
Section 3.2.3

Propose adding two new wantbacks, id-swb-ee-revocation-info and 
id-swb-CAs-revocation-info with the appropriate functionality.

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


3379 Requirement #24. If the DPD server does not support the client 
requested path discovery policy, the DPD server MUST return an error. (5. 
Delegated Path Discovery Protocol)

SCVP Draft 22:

“If the server is unable to perform validations using the required 
validation policy or the request contains an unsupported option, then the 
server MUST return an error response.”

(Section 4)

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




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 k0QG9SEI065037; Thu, 26 Jan 2006 08:09:28 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k0QG9SRV065036; Thu, 26 Jan 2006 08:09:28 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] 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 k0QG9R5E065030 for <[e-mail]>; Thu, 26 Jan 2006 08:09:27 -0800 (PST) (envelope-from [e-mail])
Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id k0QG963Z011968; Thu, 26 Jan 2006 11:09:06 -0500
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 k0QG883v022823; Thu, 26 Jan 2006 11:08:08 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 26 Jan 2006 11:08:44 -0500
To: [e-mail]
From: Tim Polk <[e-mail]>
Subject: 3379 Compliance Matrix: SCVP-22 (1 of 3)
Cc: [e-mail]
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: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id k0QG9S5E065031
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

[RFC 3379 requirements 1 through 12]



3379 Requirement #1. If the DPV server does not support the client 
requested validation policy, then the DPV server MUST return an error. 
(4.1. Basic Protocol)

SCVP Draft 22:

DPV responses include the responseStatus item.  If the client asserts the 
OID for an unsupported validation policy, the SCVP server returns an error 
response and specifies the statusCode unrecognizedValPol.

SCVP draft -21 specifies that unrecognizedValPol has the meaning “The 
request contained an unrecognized validation policy reference.” (section 4.4)

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

3379 Requirement #2. If the DPV request does not specify a validation 
policy, the server response MUST indicate the validation policy that was 
used. (4.1. Basic Protocol)

SCVP Draft 22:

All DPV requests include the validationPolicy item.  The validationPolicy 
item is itself a sequence with a single mandatory item, the 
validationPolRef item. (section 3.2.4)

The SCVP client either specifies a particular validation policy or the 
server’s default policy as an object identifier in the validationPolRef 
item.  (section 3.2.4.1)  The parameters associated with this policy may be 
modified through the use of optional items in the validationPolicy. 
(sections 3.2.4.1 through 3.2.4.9)

All DPV success responses include respValidationPolicy item (section 4.5), 
which indicate the validation policy that was used:

“The respValidationPolicy item contains either a reference to the full 
validation policy or the full policy by value used by the server to 
validate the request.”



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

3379 Requirement #3. The protocol MUST allow the client to include these 
policy dependent parameters in the DPV request; however, it is expected 
that most clients will simply reference a validation policy for a given 
application or accept the DPV server's default validation  policy. (4.1. 
Basic Protocol)

SCVP Draft 22:

All DPV requests include the validationPolicy item.  The validationPolicy 
item is itself a sequence with a single mandatory item, the 
validationPolRef item. (section 3.2.4)

The SCVP client either specifies a particular validation policy or the 
server’s default policy as an object identifier in the validationPolRef 
item.  (section 3.2.4.1)  The parameters associated with this policy may be 
modified through the use of optional items in the validationPolicy. 
(sections 3.2.4.1 through 3.2.4.9)

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

3379 Requirement #4. The DPV server MUST obtain revocation status 
information for the validation time in the client request. (4.1. Basic 
Protocol)

SCVP Draft 22:

An SCVP client specifies the validation time  by including the optional 
validationTime item (section 3.2.7)

“The optional validationTime item, if present, tells the date and time 
relative to which the SCVP client wants the server to perform the 
checks.  If the validationTime is not present, the server MUST perform the 
validation using the date and time at which the server processes the request.”

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

3379 Requirement #5. If the revocation status information for the requested 
validation time is unavailable, then the DPV server MUST return a status 
indicating that the certificate is invalid. Additional information about 
the reason for invalidity MAY also be provided. (4.1 Basic Protocol)

SCVP Draft 22:

The DPV server returns this information in the replyStatus item, which 
gives status information to the client about the request for the specific 
certificate.

If the revocation status information for the requested validation time is 
unavailable, the replyStatus will be 0 or 7:

“3  Failure: historical data for the requested validity time is notavailable.
    ….

7  Failure: the constructed certification path is not valid with respect to 
the validation policy, but a query at a later time may be successful.
    …

    Code 7 is used to tell the client that a valid certification path was 
found with the exception that a certificate in the path is on hold, current 
revocation information is unavailable, or the validation time precedes the 
notBefore time in one or more certificates in the path.”

(Section 4.9.2)


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

3379 Requirement #6. The certificate to be validated MUST either be 
directly provided in the request or unambiguously referenced, such as the 
CA distinguished name, certificate serial number, and the hash of the 
certificate, like ESSCertID as defined in [ESS] or OtherSigningCertificate 
as defined in [ES-F]. (4.1 Basic Protocol)

SCVP Draft 22:

The requestor specifies the list of certificates to be  validated in the 
sequence CertReferences.  Certificate references are performed by inclusion 
of the certificate itself or are specified using the CertID structure, 
which is based on the ESSCertID. The CertID structure includes the hash of 
the certificate and the issuer and serial number.  (section 3.2.1)


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

3379 Requirement #7. The DPV client MUST be able to provide to the 
validation server, associated with each certificate to be validated, useful 
certificates, as well as useful revocation information. (4.1 Basic Protocol)

SCVP Draft 22:

The DPV client can include potentially useful certificates in the request 
in the optional intermediateCerts item (section 3.2.8):

“The optional intermediateCerts item may help the SCVP server create valid 
certification paths.  The intermediateCerts item, when present, provides 
certificates that the server MAY use when forming a certification path.”

The DPV client can include potentially useful revocation information in the 
request in the optional revInfos item (section 3.2.9):

“The optional revInfos item specifies revocation information such as CRLs, 
delta CRLs [PKIX-1], and OCSP responses [OCSP] that the SCVP server MAY use 
when validating certification paths.  The purpose of the revInfos item is 
to provide revocation information to which the server might not otherwise 
have access, such as an OCSP response that the client received along with 
the certificate.”

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

3379 Requirement #8. The DPV server MUST have the certificate to be 
validated.  When the certificate is not provided in the request, the server 
MUST obtain the certificate and then verify that the certificate is indeed 
the one being unambiguous referenced by the client. (4.1 Basic Protocol)

SCVP Draft 22:

The DPV client must either explicitly provide the certificate to be 
validated to the DPV server or reference the certificate by its hash value 
in the queriedCerts item.

(Section 3.2.1)

The DPV server returns this information in the replyStatus item, which 
gives status information to the client about the request for the specific 
certificate.

If the certificate is not included in the request (i.e., the certificate is 
referenced by hash value), and the server is unable to obtain the 
certificate, the replyStatus will be 4:

“4  Failure: the server could not locate the reference certificate or the 
referenced certificate did not match the hash value provided.”

(Section 4.9.2)

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


3379 Requirement #9. The DPV server MUST include either the certificate or 
an unambiguous reference to the certificate (in case of a CA key 
compromise) in the DPV response. (4.1 Basic Protocol)

SCVP Draft 22:

The DPV server includes a certReply in the replyObjects in the response for 
each certificate that was validated.  The certReply is a sequence that 
includes the mandatory cert item (section 4.9.1)

“The cert item contains either the certificate or a reference to the 
certificate about which the client is requesting information.”

The CertID structure is used when the server specifies the certificate by 
reference.

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

3379 Requirement #10. The DPV response MUST indicate one of the following 
status alternatives:
1.      the certificate is valid according to the validation policy.
2.      the certificate is not valid according to the validation policy.
3.      the validity of the certificate is unknown according to the 
validation policy.
4.      the validity could not be determined due to an error.
(source for 10: 4.1 Basic Protocol)

SCVP Draft 22:

The replyStatus item gives status information to the client about the 
request for the specific certificate.

If the certificate is valid according to the validation policy, the 
replyStatus will be 0 or 8:

“0  Success: all checks were performed successfully.”

“8  Failure: all checks were performed successfully, however one or more of 
the wantBacks could not be satisfied.”

If the certificate is not valid according to the validation policy, the 
replyStatus will be 6 or 7:

“6  Failure: the constructed certification path is not valid with respect 
to the validation policy.
7  Failure: the constructed certification path is not valid with respect to 
the validation policy, but a query at a later time may be successful.”

If the validity of the certificate is unknown according to the validation 
policy, the replyStatus will be 3 or 5:

“3  Failure: historical data for the requested validity time is not available.
    ….
5       Failure: no certification path could be constructed.”

If the validity could not be determined due to an error, the replyStatus 
will be 1, 2, or 4:

“  1  Failure: the public key certificate was malformed.
     2  Failure: the attribute certificate was malformed.
   ….
     4  Failure: the server could not locate the reference certificate or 
the referenced certificate did not match the hash value provided.

(Section 4.9.2)

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

3379 Requirement #11. When the certificate is not valid according to the 
validation policy, then the reason MUST also be indicated.  Invalidity 
reasons include:
1.      the DPV server cannot determine the validity of the certificate 
because a certification path cannot be constructed.
2.      the DPV server successfully constructed a certification path, but 
it was not valid according to the validation algorithm in [PKIX-1].
3.      the certificate is not valid at this time.  If another request 
could be made later on, the certificate could possibly be determined as 
valid.  This condition may occur before a certificate validity period has 
begun or while a certificate is suspended
(Source for 11: 4.1 Basic Protocol)

SCVP Draft 22:

These reasons correspond to replyStatus codes 5, 6, and 7 respectively.

5  Failure: no certification path could be constructed.
6  Failure: the constructed certification path is not valid with respect to 
the validation policy.
7  Failure: the constructed certification path is not valid with respect to 
the validation policy, but a query at a later time may be successful.
(Section 4.9.2)

Additional information may be provided by the validation Errors field.

“The validationErrors item SHOULD only be included when the replyStatus is 
3, 5, 6, 7, or 8.  SCVP servers are not required to specify all of the 
reasons that validation failed. SCVP clients MUST NOT assume that the OIDs 
included in validationErrors represent all of the validation errors for the 
certification path.”
Section 4.9.6

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

3379 Requirement #12. The protocol MUST prevent replay attacks, and the 
replay prevention mechanism employed by the protocol MUST NOT rely on 
synchronized clocks. (4.1 Basic Protocol)

SCVP Draft 22:

SCVP includes a nonce mechanism to prevent replay attacks:

The requester may include a nonce in the request item requestNonce; the 
server returns this nonce in the response item respNonce. (section 3.4)

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




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 k0QG7Mr2064965; Thu, 26 Jan 2006 08:07:22 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k0QG7M25064964; Thu, 26 Jan 2006 08:07:22 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] 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 k0QG7KGh064958 for <[e-mail]>; Thu, 26 Jan 2006 08:07:21 -0800 (PST) (envelope-from [e-mail])
Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id k0QG76PF029353; Thu, 26 Jan 2006 11:07:08 -0500
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 k0QG6F3v022260; Thu, 26 Jan 2006 11:06:15 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 26 Jan 2006 11:06:57 -0500
To: [e-mail]
From: Tim Polk <[e-mail]>
Subject: RFC 3379 Compliance Matrix: SCVP draft 22 (intro)
Cc: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I have completed the RFC 3379 compliance matrix for SCVP draft 22.  As the 
compliance matrix is very large (24 pages!), I will post it in three 
parts.  This message includes only a summary of my results and three excerpts.

In my opinion, the current draft of SCVP fully satisfies 31 of the 34 
requirements.  I have selected text and provided references to the sections 
that satisfy the requirements in the compliance matrix.  Where requirements 
have multiple parts, I attempted to identify how each part was satisfied.

For requirements #14, #23, and #29, I could not convince myself that the 
current draft completely satisfied the requirements.  The matrix entries 
for these requirements describe the mechanisms already in SCVP -22 and 
proposes mechanisms for completely satisfying the requirement.  Note that 
in the case of #29, I am unclear why we included this requirement, so 
perhaps I am misinterpreting the text.

I have appended requirements #14, #23, and #29 to this message, for those 
who want to start with the agreed open issues.  (Those requirements are 
included in the completed matrix as well.)

Thanks,

Tim Polk


------------------ Known Open Issues ---------------------

3379 Requirement #14. The DPV server MUST be able, upon request, copy a 
text field provided by the client into the DPV response. (4.1 Basic Protocol)

SCVP Draft 22:

This requirement is poorly addressed in scvp-21

An SCVP request may include a requesterRef, which is a SEQUENCE of 
GeneralNames.

"If the SCVP client includes a requestorRef value in the request, then the 
SCVP server MUST return the same value if the server is generating a 
non-cached response." Section 4.7

One legal value for a GeneralName is an IA5string, so we could argue that 
it is met, but this is a very poor fit.

Proposed Resolution:

Add an optional item, requesterText, to both the CVRequest and CVResponse 
sequences.  The responseText would be UTF8String, maximum size 256 
characters.  There would be no semantics; the server would be required to 
copy the value from the CVRequest into the CVResponse for all non-cached 
responses.

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

3379 Requirement #23. Clients MUST be able to specify whether they want, in 
addition to the certification path, the revocation information associated 
with the path, for the end-entity certificate, for the CA certificates, or 
for both. (5. Delegated Path Discovery Protocol)
SCVP Draft 22:

SCVP does not permit the client to request status for just the EE 
certificate or just the CA certificates.  Clients that request status get 
status information for the entire path.

The SCVP client requests this information by asserting the wantback

"   - id-swb-pkc-revocation-info: Proof of revocation status for each 
certificate in the certification path;"
Section 3.2.3

Propose adding two new wantbacks, id-swb-ee-revocation-info and 
id-swb-CAs-revocation-info with the appropriate functionality.

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

3379 Requirement #29. Path discovery MUST be performed according to the 
path discovery policy.  The DPD response MUST indicate one of the following 
status alternatives:
1.	one or more certification paths was found according to the path 
discovery policy, with all of the requested revocation information present.
2.	one or more certification paths was found according to the path 
discovery policy, with a subset of the requested revocation information 
present.
3.	one or more certification paths was found according to the path 
discovery policy, with none of the requested revocation information present.
4.	no certification path was found according to the path discovery policy.
5.	path construction could not be performed due to an error.
(Source for 29: 5. Delegated Path Discovery Protocol)

SCVP Draft 22:

This requirement is not fully satisfied.  The DPD response will not 
differentiate between states 2 and 3 as described in requirement 29.

The replyStatus item gives status information to the client about the 
request for the specific certificate.

State 1:  If one or more certification paths was found according to the 
path discovery policy, with all of the requested revocation information 
present, the replyStatus will be 0:

"0  Success: all checks were performed successfully."

State 2:  If one or more certification paths was found according to the 
path discovery policy, but only a subset of the requested revocation 
information was available, the replyStatus will be 8:

"8  Failure: all checks were performed successfully, however one or
        more of the wantBacks could not be satisfied."

State 3: If one or more certification paths was found according to the path 
discovery policy, but only a subset of the requested revocation information 
was available, the replyStatus will be 8:

"8  Failure: all checks were performed successfully, however one or
        more of the wantBacks could not be satisfied."

State 4: If no certification path was found according to the path discovery 
policy, the replyStatus will be 5:

"5  Failure: no certification path could be constructed."

State 5:  If path construction could not be performed due to an error, the 
replyStatus will be 1, 2, 3, or 4:

"  1  Failure: the public key certificate was malformed.
     2  Failure: the attribute certificate was malformed.
     3  Failure: historical data for the requested validity time is not
        available.
     4  Failure: the server could not locate the reference certificate or
        the referenced certificate did not match the hash value
        provided."

(Section 4.9.2)

Possible resolution:  This requirement could be met by adding two 
additional reply check status codes for  { id-stc 1} -- but we do not see 
any value in this change!



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 k0PKTMvV063900; Wed, 25 Jan 2006 12:29:22 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k0PKTMAr063899; Wed, 25 Jan 2006 12:29:22 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] 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 k0PKTLJa063893 for <[e-mail]>; Wed, 25 Jan 2006 12:29:21 -0800 (PST) (envelope-from [e-mail])
Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id k0PKEr5a017202; Wed, 25 Jan 2006 15:20:07 -0500
Received: from othello.nist.gov (othello.ncsl.nist.gov [129.6.54.41]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id k0PK7Q3v000248; Wed, 25 Jan 2006 15:07:26 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1.1
Date: Wed, 25 Jan 2006 15:06:20 -0500
To: [e-mail]
From: Shu-jen Chang <[e-mail]>
Subject: The Second Cryptographic Hash Workshop Call for Participation
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=====================_17399171==_"
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--=====================_17399171==_
Content-Type: multipart/alternative;
	boundary="=====================_17399187==.ALT"

--=====================_17399187==.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

The Second Cryptographic Hash Workshop
Santa Barbara, CA
August 24-25, 2006 (Starting at 1PM, August 24)
Submission deadline: May 12, 2006 (Workshop without proceedings)

As a follow-up to the first Cryptographic Hash Workshop held on Oct. 
31-Nov. 1, 2005, NIST plans to host a series of public workshops to focus 
on hash function research.  The next workshop will be held on August 24-25, 
2006, in conjunction with Crypto 2006, at UCSB, Santa Barbara. Attached is 
the Call for Participation for the Second Cryptographic Hash Workshop. 
Details about the workshop will be available at the following web site 
shortly: http://www.nist.gov/hash-function

Shu-jen Chang
Computer Security Division
NIST


--=====================_17399187==.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<font face="Courier New, Courier">The Second Cryptographic Hash
Workshop<br>
Santa Barbara, CA<br>
August 24-25, 2006 (Starting at 1PM, August 24)<br>
<b>Submission deadline: May 12, 2006 (Workshop without
proceedings)<br><br>
</b>As a follow-up to the first Cryptographic Hash Workshop held on Oct.
31-Nov. 1, 2005, NIST plans to host a series of public workshops to focus
on hash function research.&nbsp; The next workshop will be held on August
24-25, 2006, in conjunction with Crypto 2006, at UCSB, Santa Barbara.
Attached is the Call for Participation for the Second Cryptographic Hash
Workshop. Details about the workshop will be available at the following
web site shortly:
</font><a href="http://www.nist.gov/hash-function" eudora="autourl"><font face="Courier New, Courier" color="#0000FF"><u>http://www.nist.gov/hash-function</a><br><br>
</u></font><font face="Courier New, Courier">Shu-jen Chang<br>
Computer Security Division<br>
NIST<br><br>
</font></html>

--=====================_17399187==.ALT--

--=====================_17399171==_
Content-Type: application/pdf; name="Second Cryptographic Hash Workshop CFP.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Second Cryptographic Hash Workshop CFP.pdf"

JVBERi0xLjQNJeLjz9MNCjEyNCAwIG9iajw8L0hbODUxIDI0MV0vTGluZWFyaXplZCAxL0UgMTk2
ODIvTCAzMDcwMC9OIDIvTyAxMjcvVCAyODE3Mj4+DWVuZG9iag0gICAgICAgICAgICAgICAgICAg
DQp4cmVmDQoxMjQgMjcNCjAwMDAwMDAwMTYgMDAwMDAgbg0KMDAwMDAwMTI2OSAwMDAwMCBuDQow
MDAwMDAwODUxIDAwMDAwIG4NCjAwMDAwMDE1MDUgMDAwMDAgbg0KMDAwMDAwMTgzNiAwMDAwMCBu
DQowMDAwMDAyNTEzIDAwMDAwIG4NCjAwMDAwMDI5NDYgMDAwMDAgbg0KMDAwMDAwMjk4MiAwMDAw
MCBuDQowMDAwMDAzMjIyIDAwMDAwIG4NCjAwMDAwMDM0NjggMDAwMDAgbg0KMDAwMDAwMzU0NSAw
MDAwMCBuDQowMDAwMDA0MTk2IDAwMDAwIG4NCjAwMDAwMDQ5MDYgMDAwMDAgbg0KMDAwMDAwNTAz
OSAwMDAwMCBuDQowMDAwMDA1MzM3IDAwMDAwIG4NCjAwMDAwMDYwMDMgMDAwMDAgbg0KMDAwMDAw
NjY5MCAwMDAwMCBuDQowMDAwMDA3MDA4IDAwMDAwIG4NCjAwMDAwMDc2ODcgMDAwMDAgbg0KMDAw
MDAwODIyMCAwMDAwMCBuDQowMDAwMDA4NzYwIDAwMDAwIG4NCjAwMDAwMDkyODEgMDAwMDAgbg0K
MDAwMDAxMTk1MSAwMDAwMCBuDQowMDAwMDE5MDI2IDAwMDAwIG4NCjAwMDAwMTkyNTcgMDAwMDAg
bg0KMDAwMDAxOTQ0OSAwMDAwMCBuDQowMDAwMDAxMDkyIDAwMDAwIG4NCnRyYWlsZXINCjw8L1Np
emUgMTUxL1ByZXYgMjgxNjAvWFJlZlN0bSAxMDkyL1Jvb3QgMTI1IDAgUi9JbmZvIDEyIDAgUi9J
RFs8OTQyZTEzMzM1NWIyYjhlY2Q0N2E2NTFkZGEyMWU1YTg+PDEyMDgyNGRiZjA4ZmVkNGM4ZGVm
YTIxYTRlZGE0YzhmPl0+Pg0Kc3RhcnR4cmVmDQowDQolJUVPRg0KICAgICAgICAgICAgDQoxMjYg
MCBvYmo8PC9MZW5ndGggMTU0L0ZpbHRlci9GbGF0ZURlY29kZS9DIDE2My9MIDE0Ny9TIDc4Pj5z
dHJlYW0NCnjaYmBgYGZgYPnAwMrAwPaRgZ8BAfgZWICiLAwcCxgaFBgY7sHEeRo1pkxOCl6aB2Qr
eXQ0gMQ6OhpAaoCAhYEh6BGQFgdiSbCICgMvp8UCZykGhjRmD1aldFEBCSce9UTXloyAxI/8BypD
pm7/kNhUILFAhvkF1AoOBoboLCDNBMQWQMzGwBB8GMJnXw6mWY8eAAgwAD7oHtANCmVuZHN0cmVh
bQ1lbmRvYmoNMTUwIDAgb2JqPDwvU2l6ZSAxMjQvTGVuZ3RoIDI3L0ZpbHRlci9GbGF0ZURlY29k
ZS9EZWNvZGVQYXJtczw8L0NvbHVtbnMgMy9QcmVkaWN0b3IgMTI+Pi9XWzEgMSAxXS9UeXBlL1hS
ZWYvSW5kZXhbMTMgMTExXT4+c3RyZWFtDQp42mJiYmNgYmBgHMWDBTPOJVYtQIABAEkdAfINCmVu
ZHN0cmVhbQ1lbmRvYmoNMTI1IDAgb2JqPDwvUGFnZXMgMTAgMCBSL1R5cGUvQ2F0YWxvZy9QYWdl
TGFiZWxzIDggMCBSL1N0cnVjdFRyZWVSb290IDEzIDAgUi9NZXRhZGF0YSAxMSAwIFIvUGllY2VJ
bmZvPDwvTWFya2VkUERGPDwvTGFzdE1vZGlmaWVkKEQ6MjAwNjAxMjUxNDA1MTMpPj4+Pi9MYXN0
TW9kaWZpZWQoRDoyMDA2MDEyNTE0MDUxMykvTWFya0luZm88PC9NYXJrZWQgdHJ1ZS9MZXR0ZXJz
cGFjZUZsYWdzIDA+Pj4+DWVuZG9iag0xMjcgMCBvYmo8PC9Db250ZW50c1sxMzQgMCBSIDEzNSAw
IFIgMTM4IDAgUiAxMzkgMCBSIDE0MSAwIFIgMTQyIDAgUiAxNDMgMCBSIDE0NCAwIFJdL1R5cGUv
UGFnZS9QYXJlbnQgMTAgMCBSL1JvdGF0ZSAwL01lZGlhQm94WzAgMCA2MTIgNzkyXS9Dcm9wQm94
WzAgMCA2MTIgNzkyXS9SZXNvdXJjZXM8PC9Db2xvclNwYWNlPDwvQ1MwIDEzMCAwIFI+Pi9Gb250
PDwvVFQyIDE0MCAwIFIvVFQwIDEyOCAwIFIvVFQxIDEyOSAwIFIvQzJfMCAxMzYgMCBSPj4vUHJv
Y1NldFsvUERGL1RleHRdL0V4dEdTdGF0ZTw8L0dTMCAxMzMgMCBSPj4+Pi9TdHJ1Y3RQYXJlbnRz
IDA+Pg1lbmRvYmoNMTI4IDAgb2JqPDwvVHlwZS9Gb250L0VuY29kaW5nL1dpbkFuc2lFbmNvZGlu
Zy9CYXNlRm9udC9UaW1lc05ld1JvbWFuUFNNVC9GaXJzdENoYXIgMzIvTGFzdENoYXIgMjI5L1N1
YnR5cGUvVHJ1ZVR5cGUvRm9udERlc2NyaXB0b3IgMTMxIDAgUi9XaWR0aHNbMjUwIDAgNDA4IDAg
MCAwIDAgMCAzMzMgMzMzIDAgMCAyNTAgMzMzIDI1MCAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAw
IDUwMCAwIDUwMCAwIDI3OCAyNzggMCAwIDAgMCAwIDcyMiA2NjcgNjY3IDcyMiA2MTEgNTU2IDcy
MiA3MjIgMzMzIDAgMCAwIDg4OSA3MjIgNzIyIDU1NiAwIDAgNTU2IDYxMSA3MjIgNzIyIDk0NCAw
IDAgMCAwIDAgMCAwIDAgMCA0NDQgNTAwIDQ0NCA1MDAgNDQ0IDMzMyA1MDAgNTAwIDI3OCAyNzgg
NTAwIDI3OCA3NzggNTAwIDUwMCA1MDAgNTAwIDMzMyAzODkgMjc4IDUwMCA1MDAgNzIyIDUwMCA1
MDAgNDQ0IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg
MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw
IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg
MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgNDQ0XT4+DWVu
ZG9iag0xMjkgMCBvYmo8PC9UeXBlL0ZvbnQvRW5jb2RpbmcvV2luQW5zaUVuY29kaW5nL0Jhc2VG
b250L1RpbWVzTmV3Um9tYW5QUy1Cb2xkTVQvRmlyc3RDaGFyIDMyL0xhc3RDaGFyIDEyMS9TdWJ0
eXBlL1RydWVUeXBlL0ZvbnREZXNjcmlwdG9yIDEzMiAwIFIvV2lkdGhzWzI1MCAwIDAgMCAwIDAg
MCAwIDMzMyAzMzMgMCAwIDI1MCAzMzMgMjUwIDI3OCA1MDAgNTAwIDUwMCA1MDAgMCAwIDUwMCAw
IDAgMCAzMzMgMCAwIDAgMCAwIDkzMCA3MjIgMCAwIDcyMiAwIDAgMCA3NzggMCA1MDAgMCAwIDk0
NCA3MjIgMCAwIDAgMCA1NTYgMCAwIDcyMiAxMDAwIDAgMCAwIDAgMCAwIDAgMCAwIDUwMCA1NTYg
NDQ0IDU1NiA0NDQgMzMzIDUwMCA1NTYgMjc4IDAgNTU2IDI3OCA4MzMgNTU2IDUwMCA1NTYgMCA0
NDQgMzg5IDMzMyA1NTYgNTAwIDcyMiAwIDUwMF0+Pg1lbmRvYmoNMTMwIDAgb2JqWy9JQ0NCYXNl
ZCAxNDUgMCBSXQ1lbmRvYmoNMTMxIDAgb2JqPDwvVHlwZS9Gb250RGVzY3JpcHRvci9Gb250QkJv
eFstNTY4IC0zMDcgMjAwMCAxMDA3XS9Gb250TmFtZS9UaW1lc05ld1JvbWFuUFNNVC9GbGFncyAz
NC9TdGVtViA4Mi9DYXBIZWlnaHQgNjU2L1hIZWlnaHQgMC9Bc2NlbnQgODkxL0Rlc2NlbnQgLTIx
Ni9JdGFsaWNBbmdsZSAwL0ZvbnRGYW1pbHkoVGltZXMgTmV3IFJvbWFuKS9Gb250U3RyZXRjaC9O
b3JtYWwvRm9udFdlaWdodCA0MDA+Pg1lbmRvYmoNMTMyIDAgb2JqPDwvVHlwZS9Gb250RGVzY3Jp
cHRvci9Gb250QkJveFstNTU4IC0zMDcgMjAwMCAxMDI2XS9Gb250TmFtZS9UaW1lc05ld1JvbWFu
UFMtQm9sZE1UL0ZsYWdzIDM0L1N0ZW1WIDEzNi9DYXBIZWlnaHQgNjU2L1hIZWlnaHQgMC9Bc2Nl
bnQgODkxL0Rlc2NlbnQgLTIxNi9JdGFsaWNBbmdsZSAwL0ZvbnRGYW1pbHkoVGltZXMgTmV3IFJv
bWFuKS9Gb250U3RyZXRjaC9Ob3JtYWwvRm9udFdlaWdodCA3MDA+Pg1lbmRvYmoNMTMzIDAgb2Jq
PDwvVHlwZS9FeHRHU3RhdGUvU0EgZmFsc2UvT1AgZmFsc2UvU00gMC4wMi9vcCBmYWxzZS9PUE0g
MT4+DWVuZG9iag0xMzQgMCBvYmo8PC9MZW5ndGggNTgxL0ZpbHRlci9GbGF0ZURlY29kZT4+c3Ry
ZWFtDQpIiYyTUWvbMBDH3/0p7lGGWJFk2bFHKaRpt3aQrhDBHtY9KLYXa0ulYMkN3aef5CRNx5ow
jPGdkO5+99ff4we4uBjPZ3fXQODy8up6BtF4tiBQWb8QHrCVjigov/7Jr69sdCWisRAEKIgfEcGE
MBAVJCEK4TYcEhYoCd/fPhOdT3CZlZQOJUNSQElgklLMs7LMQTxF35BoG1g0ldE1xBmadS9xMkGb
OGHIxTkyq05uWuWjCm6lbeGr6X7Z1mwg/i4+RzciupkH+uNE9DDRP8SkDMiHaHsKjxa48FvSHd5C
aifhSnZL2cVJhuQIZtOTzdnJ5uyNXvxMd5JjygfA0H3ar3rrgPGExRxl/h0BI8R/c3hECyc7F7TR
K5AO6MN8BNN4gvaH/C4eJxQ9xid507956ZGX5ke1PORJ4LxMMS/89r1c/fJJWauMhqBW3ch6rXTz
AebyBSgb6AO6h369ya1yrekdbDpTNU2t9MqeQebvSzzAnsEsCC4KkvGAiSAWP9+rnZ28vjDfXg12
pkteYMZITndi3GnoGrsx2jbgDLjg9NtpQuG5X+umk0u1VsHk3vIFCu53rXTD3EPL4jjTBKecZyGp
fV3YSgtSa9PrqqlBafjYLLE/H9TNRnB/txChXNusa5DwWpGFizyYMB0uNTmUTiimWbqr//8/ofEe
02EbfKkchpQm9+YZH0co3zTcu6jEKcv56ygek44GrwZXkywIZc3a91IxRZXytvDr/XKtKj/oEA9Y
+9YcgXLWjwh/BBgAjowpjw0KZW5kc3RyZWFtDWVuZG9iag0xMzUgMCBvYmo8PC9MZW5ndGggNjQw
L0ZpbHRlci9GbGF0ZURlY29kZT4+c3RyZWFtDQpIiXxUX2+bMBx851P8HkEqFBMgQaoq9U+kddKm
SeGt3YMLTmAltmWTRvv2O5skdFK3N+zYd/e7O6f+GqRJmrIV1Q2lVB8pZlWyyMocHwkrFlS3wXPY
mN9RvAx1FGfhqHaG665volVIHbcdbQ+yGXslSavoZ31CLDwivtIFc7gsS4qMMUfiEAfcX4ZABQiX
LVmsRnxw09qE6PvTpqZGybGXB2EpKkBLRjRqvxfSXWqJ02i4tL1nnnkr5ohjz8zYNNGJ+uNEW6P2
boDNl7uYEcDHTtDAzU4Y4lob9S5aR/vXgJZewg02cSfL8it/OSvK6WOxwg6XUQ5tbj1Lms1NvYZ8
WUDYI1QULHuJMO5TVIbSmYsZrQaROEs6whflfjFvtlP6CuyTORBGfLCKWtH0LcSOHR+pH53oozoM
Lb0K0gbAByfJQQiJA5JG7HV+TYPCb3I3a3U2XeybgksvvjnFozDet9ERv4tBacxMvG2RA3CV5MNc
ChzE7ic+sDLJ87kMCHDsnFR12HVuAE768IqKoAJ7LUaf8RXZ3lH3SOnsjseOz2gf8z2Jcxfc2FFc
hAi1EdbSVhl/+XVQzRs1ve4EThlvTXdReyrPM1y6a985TsgGLq8l3oL2nduc+opS3K03PsdJ0LoO
1t8eKLj+QTc3198enh6ppNvb+0fs3dfBdV2nBPBtkM6GpElVVN6R1C9WVKVULKukLNmionofhBTV
vz7DXn6OfXH8H9jl0p3IC4f9HN4L2CLgAbzmeHU7b1HjH4l/9pcUfPuQkR7w+lwQ/3t7+DMp2Cq9
JN0p6xtqEY9BVVwujmKquDjHflSoO7bReDsV+9gPAwoCMvojwACR1UX4DQplbmRzdHJlYW0NZW5k
b2JqDTEzNiAwIG9iajw8L1R5cGUvRm9udC9FbmNvZGluZy9JZGVudGl0eS1IL0Jhc2VGb250L01C
T0NQTitTeW1ib2xNVC9TdWJ0eXBlL1R5cGUwL0Rlc2NlbmRhbnRGb250c1sxNDggMCBSXS9Ub1Vu
aWNvZGUgMTM3IDAgUj4+DWVuZG9iag0xMzcgMCBvYmo8PC9MZW5ndGggMjI4L0ZpbHRlci9GbGF0
ZURlY29kZT4+c3RyZWFtDQpIiVSQsW7DIBCGd57ixkYZIDRVO1gs6eIhbVW73QmcHaQa0BkPfvsC
tRJ1AHT/3Xf3c/zUvrbeJeAfFEyHCQbnLeEcFjIIFxydh4ME60zaonqbSUfgGe7WOeHU+iFA0zD+
mZNzohUe+v5pL3bA38kiOT9m5Si/vrPSLTH+4IQ+gQClwOLA+Oms45ueEHgF72K/RgRZ48M2O1ic
ozZI2o8IjRDiUZXn+UUBevs/z+QfdRnMVRO7V0uh2AY1UkipWGa3qtKl/PDmyixE2XBdQ7VVDDmP
t03FEMvsctivAAMAGddtKAoNCmVuZHN0cmVhbQ1lbmRvYmoNMTM4IDAgb2JqPDwvTGVuZ3RoIDU5
Ni9GaWx0ZXIvRmxhdGVEZWNvZGU+PnN0cmVhbQ0KSImcVF1r3DAQfPev2EcJzo5kW/5oj0BySWkL
gUL9VkpRbd1ZqWMZS+4l/74r+y53gYRCMBhpLc3Ozuy6+hqwiDGeQVWDX7EYqj2EvIwELxjHVcTT
XHComoBsTT1ZMD200rawnfraadyNyio51m0EULUKevXoYG/GP5ZW9wt8McN7ZATOWSlKv2uCH6Q1
A1BB9rrr4LeCVnWNT3A17SbrIE5DmpFYrCBmLFuB7oH+rBbOMeceNfRrkfMj7QXd0xbJkqI2/f2B
Kk0J7LVrgYaCbManwRmIMTiD+5j/6A/5tcNatqbrzF73O9gZSQvS2Q8Lg9squL3bQHDxDdbri7vN
lxso4PLy+gZj11VwUVUMkNM2YKfSWYTUkDXDx28KKBmIuIxYwcscqocAE6Nkr2CX59ib+NcBfC6e
LUK8Ac9FlKVxmnn4NWN5gReSS8xyRtFbJJ47IJm15P6aONp0+zh0ZlQw0IQYGsbEqd5p2cGDRJnw
pWvcDKPuaz10yoLsm5NVS1PxIspFfkS0bpxqN2HvgGulg1r2eN/81Y2CRXlMNfWNnH1LCAbGE+JZ
R4UH3BeWj080zMkwM8UOMrtRDq2u0cEXvYtW9/YjvGkpZ+/VPS1wgtKEJf/RneVH3fkrsn8y1qkR
ZF3TMCWqUyMNMyKdauah80E/eHO74tR43WQvOyy+IJZyou2ZZFn5bPEhVx4lSfKczGxP2qBQXne7
AmUHVWtJw4R03dOc4vvnqzBezp7QS37myAH4ZAk5/ixQ7TdaHDm9V+ssiQSLSy81/BNgACsaN3IN
CmVuZHN0cmVhbQ1lbmRvYmoNMTM5IDAgb2JqPDwvTGVuZ3RoIDYxNy9GaWx0ZXIvRmxhdGVEZWNv
ZGU+PnN0cmVhbQ0KSIl8VEtvnDAQvu+vmCNIi2PzCCBFOeQhNZVSVQq3qAcHhuCWALXNrvLvOza7
bDaKegJj+J6DrzjPC855cl393lxUFQcBVbvhjHNxCVUN7o7HUO1BsMs0zoBD1Wyeg6dZ7zAsgvcw
KgKwHcJsaIkGxhY6aTpo56G2ahzMFuTQgBp2aMJf1fcFnIsVPS89fM7yIk7KI4FVr9KiR570OKG2
isBtJy1IjSCNmR31GzbusiV6bLYwajhxpCtF6hiilSISTGTJwjMgNtgweGhwsKp992IlsdVzfxSg
8e+sNDYe/jJo0CgtX/ozZS3ttbOdSZuzHybBKQG2iLqvNvePt7C5+AlXVxePtw93IGK4vr65o4c3
1cf8vXIfC2dlVgpBK+4XBZQc0qRgokg4eXjbBBBSeV+BJ1+Du2ySNZvsPzRxxrI4EY7lOfjx8FSB
GXtVK2soE4NS190WjBsFPwdUdaNMPRtDrmGSE65lLBWIkiUiS5eOA03vTw5nsPIwKbU0CMbODUVK
m3LA3oc8GtnTA2fUy8+c/OgI97FPV9/k+1OTR4VWj29hHoDse5pCi8RocXkpjLLAM6mh7j8NzpnW
54AkDa+ra3Ta3ddmMW5xoaAtZbG2tLvDoRn1Yfo99pd6aW41DQj4dPeKNJJZ68cuzAJZ1zgtaidH
hGFMsZ0gPzRYsCIpxSHas1iBQvB4h/Ri4X++yH/s2t1DweK8OFrdj/qP6cbJCdjjCxiydE75+WyI
4pwJkQvvLM0zsQC5VOfG/0NUqxpAwordEeA4WwbfKLgxjGKi2p3mJY5PEtODvyw5nj/wT4ABALPa
T0wNCmVuZHN0cmVhbQ1lbmRvYmoNMTQwIDAgb2JqPDwvVHlwZS9Gb250L0VuY29kaW5nL1dpbkFu
c2lFbmNvZGluZy9CYXNlRm9udC9Db3VyaWVyTmV3UFNNVC9GaXJzdENoYXIgMzIvTGFzdENoYXIg
MTExL1N1YnR5cGUvVHJ1ZVR5cGUvRm9udERlc2NyaXB0b3IgMTQ5IDAgUi9XaWR0aHNbNjAwIDAg
MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw
IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg
MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDYwMF0+Pg1lbmRvYmoNMTQx
IDAgb2JqPDwvTGVuZ3RoIDYwOS9GaWx0ZXIvRmxhdGVEZWNvZGU+PnN0cmVhbQ0KSIl0VDtv2zAQ
3v0rbqQKW6Eky7aKIEMeBVIgSYFyMzrQEh2zpUVCpGrk3/eOsS0lTTbyKH6vO2rNuim0Fra22ycr
Jg0cbPfH76wD19laqUa3zx5P4KCNgY2C5Jf4PuEp59kcRA204rg6wCxbpWWRl7hIs7IA0UyY6zdG
+51qUni8/ylAtbXtO/msPMIrr9ogg07E71fARXVGzDKCzMq0nK+WGXBCWzPbepBtA51ytgsebEsw
RpN03coumZXsJTqAsJMBkpI52QVdaydb/N4Z2R4NvCo+4Q+S1yxYOMoGZbw67FSnUhAW5F+rGwjJ
gu2SWc4UOOu9xu3GKGh6ZzTx1+gIddktOOlUh4LrWrmgGsoYZdEFn+RsCFqiejR1DvZoXnxBMTfd
SzJbMkeExGxpATnniymaI4O+30T7KIXiiW16fBLUqhoLukH5zdC08hxxEVlynhbL/JzwSaQf5Okt
FlSyZC+RW3YKkNMHTFRLY7CK0/FuKmYn2HGwPuazRyRtJLJYwoWoH0t0dvTwJjGqxxRW71MYOKss
ko4nZ5VWRT74osRSvEmJCet07SP4KbwROXruTQPUppZoatM3akr3Nn0Ycf43rLMz59g0xdXaAMch
JVfBTsdTtLXG2AM+s6+v6HdicvdwA5OLH3B5efFwc38LGOrV1fUtFq/F5EIIDsi4pSGuIU5yxtOq
rDKyy+NmBRWHIsvSJZ8XOYj9BK3jO/sIvPwYHJ3lyyHX6nOevKpSPp8XFfGs2YPEvu6TiuFLqPGP
8s32LcbXxIfhsf65z8VbKflIShZ7DP8EGACqp0QnDQplbmRzdHJlYW0NZW5kb2JqDTE0MiAwIG9i
ajw8L0xlbmd0aCA0NjMvRmlsdGVyL0ZsYXRlRGVjb2RlPj5zdHJlYW0NCkiJpFJNT9wwEL3nV8zR
lojXduzEVhFS2aUqlVbi4BvtIdqYJWWTrJwsFf31HQfYqjRZpFa5jJ2ZN+/DHNwPEJxZbYUAjl88
GBBSM2utzkCanGVGqRxck5AOqPueLJzDRnB3CWecC4nlBmLJ8xGP5UpqxHJVckuuBx/KoX700A/h
sKGpIsMh+P4MaubZGazKhhZkS1NDvmZKhypd+/Cw89AFKHc43I7T/Qeg39yX5MolV+slJIsbOD9f
rJfXKxAFXFxcrvDy0kVu8jc3KZ65vS+zyFghlZbzMnN7lBlR3+pcdjQtSEMN2dNUElTY110Ld4d2
M8Ri07XPBkQV075JplX2iheH0CTPtgw9eqx9j8Y8RZs8RfgTdph/tyOPZAqQuWA8V9pOupGOlOXf
Fnwu+/u63UI0oYsmVNES/6oilG3VUUWa+qev4P6lGWN+8DjwNPaitAqoJi9/T6i00yrflaYMU7my
xXzQ6hiLequRfOpCU+5gH7q9DwOGwkaECYKS/0mQHwnOB2DH/fieZaaZ4ToSQJazK8T0iunXemqd
zJhQWsRtt+RjW+7GNHpMo+4BY4uRrHxfb9vZQKT8/2eHZ2W0OJGNHZHglwADAOFoGxENCmVuZHN0
cmVhbQ1lbmRvYmoNMTQzIDAgb2JqPDwvTGVuZ3RoIDQ3MC9GaWx0ZXIvRmxhdGVEZWNvZGU+PnN0
cmVhbQ0KSIms00tvnDAQAOA7v2KOthS8YDAPNYqUl9RWShUp3KoeKJjF1a5NbW/T9td3DOmm7SZ7
qFZcwFjj+WbGccKSJElTaB4hZUXOBSTQ9NFHcqnbzQ8al8RRTpSDVvdABemlU2sNZoCxdbQiI405
gQH/7HTnlaE50ctmP0ploTNb3DUZLbV3b4B+at5Ht010e3cN0eoezs9Xd9fvboBncHFxdYOLV020
ahoOmNIQhex4yK4LaWGKCatFjQsJPuGjgpQXuCmt8K0uWcUFhmq2ETFAmy8hVPIcKs3mSIEsDsUf
5CN0Fs2Yb1D5dilBRTzyVAdedqNWX3c0IxKN61Zp50MdRhie9BnqjyjzEygrwdJCHEHme2R+iHyQ
3c4qP7PAyslYD0aD/K6cV3odWvwnSLszkG6SnWo3Sy3g4e1lzI8YxQmMJWeiEEX5n8jGmI2DwVhY
xjXAwkjuG/ozzDQuhuksQ7crYqVz6H2GHyEWJyCKmtWJKMXrxGJP5IfEe2u+tZ83EiZrJmm9wonE
S/l03cL4WhoL8i8Ku8nW7Cy02cp+tyyCN0vfbR/CYdStY6/ry7/1v1M+5q7n2mQZpHnJeC4qPrNn
9UtHVC8fEarC5wLDLwEGAOrlLf0NCmVuZHN0cmVhbQ1lbmRvYmoNMTQ0IDAgb2JqPDwvTGVuZ3Ro
IDQ1MS9GaWx0ZXIvRmxhdGVEZWNvZGU+PnN0cmVhbQ0KSImkk71u2zAURnc9xR1JoJL5IzIiEmRI
nKEFAnhQuxQdaJmCWciSSkpo+/YlmcSO69iLoYUihe/ec3hFCkKIhPo3UFIooSgFEp74UoEi4ZRx
DpSXhahEVUG9y76jldPNZBvdAc4F+uqNB91vYGWnVnedB/yj/pI91dnT8yNkixXc3S2eHz8vgSm4
v39Yhs2HOlvUNQMKdZulKqFw3YTKH3dCmQwf0SquaKGYUCK2ggbA9c8YRQ5RVKSkCMZpyitkyUTM
3oTmU7tDC1vtt6n/du4DzdB7sD1oLNE4dgHuZStyjW6Yhmbo/O1ZMk6uI2ORjKiCM8nZeTK6J7s5
BVu5YTRusu/wDmjTVk+gnQHtcV4iPyeSFCr3oSyFyqIspVBvsTuz+QTO/Jqti6vBwbDGHE3a9mYD
Nvjqcc5QsJSGwlyQRK+TxIMkJQspZXle0f80R4q+zV1vnF7bzp54whV6UdXo2QeygyDyTrt6VcSF
IvQtdv0X5xWCuTd/RtNMJo3M/i4c7PANsjiXQbu/5Idd50cQAVUZFrK88HfwPYw4FbQ03gY/nYkE
EWqMd/tK0gaUdp7mMEXH01UcI8E/AQYAV4gWfA0KZW5kc3RyZWFtDWVuZG9iag0xNDUgMCBvYmo8
PC9MZW5ndGggMjU3NS9GaWx0ZXIvRmxhdGVEZWNvZGUvTiAzL0FsdGVybmF0ZS9EZXZpY2VSR0I+
PnN0cmVhbQ0KSImclnlUU3cWx39vyZ6QlbDDYw1bgLAGkDVsYZEdBFEISQgBEkJI2AVBRAUURUSE
qpUy1m10Rk9FnS6uY60O1n3q0gP1MOroOLQW146dFzhHnU5nptPvH+/3Ofd37+/d3733nfMAoCel
qrXVMAsAjdagz0qMxRYVFGKkCQADCiACEQAyea0uLTshB+CSxkuwWtwJ/IueXgeQab0iTMrAMPD/
iS3X6Q0AQBk4ByiUtXKcO3GuqjfoTPYZnHmllSaGURPr8QRxtjSxap6953zmOdrECo1WgbMpZ51C
ozDxaZxX1xmVOCOpOHfVqZX1OF/F2aXKqFHj/NwUq1HKagFA6Sa7QSkvx9kPZ7o+J0uC8wIAyHTV
O1z6DhuUDQbTpSTVuka9WlVuwNzlHpgoNFSMJSnrq5QGgzBDJq+U6RWYpFqjk2kbAZi/85w4ptpi
eJGDRaHBwUJ/H9E7hfqvm79Qpt7O05PMuZ5B/AtvbT/nVz0KgHgWr836t7bSLQCMrwTA8uZbm8v7
ADDxvh2++M59+KZ5KTcYdGG+vvX19T5qpdzHVNA3+p8Ov0DvvM/HdNyb8mBxyjKZscqAmeomr66q
NuqxWp1MrsSEPx3iXx3483l4ZynLlHqlFo/Iw6dMrVXh7dYq1AZ1tRZTa/9TE39l2E80P9e4uGOv
Aa/YB7Au8gDytwsA5dIAUrQN34He9C2Vkgcy8DXf4d783M8J+vdT4T7To1atmouTZOVgcqO+bn7P
9FkCAqACJuABK2APnIE7EAJ/EALCQTSIB8kgHeSAArAUyEE50AA9qActoB10gR6wHmwCw2A7GAO7
wX5wEIyDj8EJ8EdwHnwJroFbYBJMg4dgBjwFryAIIkEMiAtZQQ6QK+QF+UNiKBKKh1KhLKgAKoFU
kBYyQi3QCqgH6oeGoR3Qbuj30FHoBHQOugR9BU1BD6DvoJcwAtNhHmwHu8G+sBiOgVPgHHgJrIJr
4Ca4E14HD8Gj8D74MHwCPg9fgyfhh/AsAhAawkccESEiRiRIOlKIlCF6pBXpRgaRUWQ/cgw5i1xB
JpFHyAuUiHJRDBWi4WgSmovK0Rq0Fe1Fh9Fd6GH0NHoFnUJn0NcEBsGW4EUII0gJiwgqQj2hizBI
2En4iHCGcI0wTXhKJBL5RAExhJhELCBWEJuJvcStxAPE48RLxLvEWRKJZEXyIkWQ0kkykoHURdpC
2kf6jHSZNE16TqaRHcj+5ARyIVlL7iAPkveQPyVfJt8jv6KwKK6UMEo6RUFppPRRxijHKBcp05RX
VDZVQI2g5lArqO3UIep+6hnqbeoTGo3mRAulZdLUtOW0IdrvaJ/Tpmgv6By6J11CL6Ib6evoH9KP
07+iP2EwGG6MaEYhw8BYx9jNOMX4mvHcjGvmYyY1U5i1mY2YHTa7bPaYSWG6MmOYS5lNzEHmIeZF
5iMWheXGkrBkrFbWCOso6wZrls1li9jpbA27l72HfY59n0PiuHHiOQpOJ+cDzinOXS7CdeZKuHLu
Cu4Y9wx3mkfkCXhSXgWvh/db3gRvxpxjHmieZ95gPmL+ifkkH+G78aX8Kn4f/yD/Ov+lhZ1FjIXS
Yo3FfovLFs8sbSyjLZWW3ZYHLK9ZvrTCrOKtKq02WI1b3bFGrT2tM63rrbdZn7F+ZMOzCbeR23Tb
HLS5aQvbetpm2TbbfmB7wXbWzt4u0U5nt8XulN0je759tH2F/YD9p/YPHLgOkQ5qhwGHzxz+iplj
MVgVNoSdxmYcbR2THI2OOxwnHF85CZxynTqcDjjdcaY6i53LnAecTzrPuDi4pLm0uOx1uelKcRW7
lrtudj3r+sxN4Jbvtspt3O2+wFIgFTQJ9gpuuzPco9xr3Efdr3oQPcQelR5bPb70hD2DPMs9Rzwv
esFewV5qr61el7wJ3qHeWu9R7xtCujBGWCfcK5zy4fuk+nT4jPs89nXxLfTd4HvW97VfkF+V35jf
LRFHlCzqEB0Tfefv6S/3H/G/GsAISAhoCzgS8G2gV6AycFvgn4O4QWlBq4JOBv0jOCRYH7w/+EGI
S0hJyHshN8Q8cYa4V/x5KCE0NrQt9OPQF2HBYYawg2F/DxeGV4bvCb+/QLBAuWBswd0IpwhZxI6I
yUgssiTy/cjJKMcoWdRo1DfRztGK6J3R92I8Yipi9sU8jvWL1cd+FPtMEiZZJjkeh8QlxnXHTcRz
4nPjh+O/TnBKUCXsTZhJDEpsTjyeREhKSdqQdENqJ5VLd0tnkkOSlyWfTqGnZKcMp3yT6pmqTz2W
Bqclp21Mu73QdaF24Xg6SJemb0y/kyHIqMn4QyYxMyNzJPMvWaKslqyz2dzs4uw92U9zYnP6cm7l
uucac0/mMfOK8nbnPcuPy+/Pn1zku2jZovMF1gXqgiOFpMK8wp2Fs4vjF29aPF0UVNRVdH2JYEnD
knNLrZdWLf2kmFksKz5UQijJL9lT8oMsXTYqmy2Vlr5XOiOXyDfLHyqiFQOKB8oIZb/yXllEWX/Z
fVWEaqPqQXlU+WD5I7VEPaz+tiKpYnvFs8r0yg8rf6zKrzqgIWtKNEe1HG2l9nS1fXVD9SWdl65L
N1kTVrOpZkafot9ZC9UuqT1i4OE/UxeM7saVxqm6yLqRuuf1efWHGtgN2oYLjZ6NaxrvNSU0/aYZ
bZY3n2xxbGlvmVoWs2xHK9Ra2nqyzbmts216eeLyXe3U9sr2P3X4dfR3fL8if8WxTrvO5Z13Vyau
3Ntl1qXvurEqfNX21ehq9eqJNQFrtqx53a3o/qLHr2ew54deee8Xa0Vrh9b+uK5s3URfcN+29cT1
2vXXN0Rt2NXP7m/qv7sxbePhAWyge+D7TcWbzg0GDm7fTN1s3Dw5lPpPAKQBW/6YuJkkmZCZ/Jpo
mtWbQpuvnByciZz3nWSd0p5Anq6fHZ+Ln/qgaaDYoUehtqImopajBqN2o+akVqTHpTilqaYapoum
/adup+CoUqjEqTepqaocqo+rAqt1q+msXKzQrUStuK4trqGvFq+LsACwdbDqsWCx1rJLssKzOLOu
tCW0nLUTtYq2AbZ5tvC3aLfguFm40blKucK6O7q1uy67p7whvJu9Fb2Pvgq+hL7/v3q/9cBwwOzB
Z8Hjwl/C28NYw9TEUcTOxUvFyMZGxsPHQce/yD3IvMk6ybnKOMq3yzbLtsw1zLXNNc21zjbOts83
z7jQOdC60TzRvtI/0sHTRNPG1EnUy9VO1dHWVdbY11zX4Nhk2OjZbNnx2nba+9uA3AXcit0Q3Zbe
HN6i3ynfr+A24L3hROHM4lPi2+Nj4+vkc+T85YTmDeaW5x/nqegy6LzpRunQ6lvq5etw6/vshu0R
7ZzuKO6070DvzPBY8OXxcvH/8ozzGfOn9DT0wvVQ9d72bfb794r4Gfio+Tj5x/pX+uf7d/wH/Jj9
Kf26/kv+3P9t//8CDAD3hPP7Cg0KZW5kc3RyZWFtDWVuZG9iag0xNDYgMCBvYmo8PC9MZW5ndGgg
Njk5MC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoMSAxMTA0MD4+c3RyZWFtDQpIidxXCVRTZxZ+
WYFEtiao41D9gaICSXgBg4bFGkLA50CCSYho1TEJDxLNRt4DpKiQqAhaLVXElYraiorUpbhMz9TB
o+NCheJW0XEbGadal2rdBXT+B1XQ1plz5pyZM2feO/95797/u/f//v/em/uC0BAE6YeUIAxkTJIG
S7lY2DwRao4jCJ+v0kRGzbt/3Qnfr0CdzphPgvBDHfMRJGAUgrCY2Y4c60P0UC6CDIqHsm+OpTB7
6/z6AwgSSuF3mXB91p/rJ+MIEn4dyjEmqPAVMlwIMiQVyu+ZrOTMgnRsNJQdCELvtNiN+oHxA6Gv
oZUIQnNb9TMddAarFtofhXhg01txzoEpUgQZPhDiv3A4cccc3wPQf7AFQRiQB0LrvqknwuuCTz7S
ffEeom7ePbZXeOnY0sfeNA96jZt3Faou0Wk0sQ/aj+3ZM0NnsRB0GpsTwaYxae6RdBqzRo2mo4I+
msANg0sCkfjuW4UYEAKxIxYER0g4RlM3Cl73x/RbWrfgWjOnc1n8uZS65/GyQzVu3/dRN70RjjA6
n1fecGLh9dpDX0uOrFlc1jSkSaP7BPV+xZXGhJRcn4qHoO+yGRlMDq+/DneaNeYcG9A68wgSKHGy
wO6cIR6ABlAALs/nJUAAMJtRJBag4T0TIb2WZisONKTe6jDbcoAGd+abjThQ2+2keAQa1YOOUKpA
KiZLxFIx7UQgk8sV6VpFkgAMN4ZJR4LX10AHD/CWjkQl4ih0JAqvSVCUiqOixT+L//sbcK3re+Y0
FsJwLYbnXk53uZBTInDXNEsgFLkCd7J31XL3+ntPOK9py2s/Fh2+6/Qjrw9G3L9R8dyrX+tffjvp
D83fPyrbWd24IPTm7Ew/YvrMb3IDug5nPgqry5xaxewSGvwzXYFNuZVngjMjzxzns+bFfFW5tSFt
3I07ccH1ulVzgtZaShvHpayY3rAp5kynl/BUg3QNnQGT+o2UYEBesf5r57NGn7xR0lF0ZsuDbYWd
rM7lCbkhWyKGX/6Ih5c/FyygfTxptaHJv7bkwd79/L0ndKtmeBoUhzd8fl5SzAq+5BQyS1m1s7z6
L+PL7z7un/adx5I1fpbM5xzJiqbydZeZjrXhs/VLDlzn5q7efCTbkJiwvDI4amVw+cJnWZ7vPTz5
DOZvMxwx9ADka//V5+W3gzqSM+eVNyWXVYTe4U/7/0vibeJhaGiP48H/nMbLnXLfutN/i+LL8+H8
4nz8UV9qwoPnidlI3GnDSdRV/YuUXgSjsIBK6Tr97Yb6xRUpFRca/KeaL3CKDRVscXPLi7JPks9i
sZU3TrPfr67fMHPSraedRoVqH9eG/rghpk7odfmefVid9/hpLImquEWrat0rSGzjti7eN/XFnpLW
9qqG4mAs0c9yauUOmm7jwW9F62IfFG/O3HQ2GL/2Ud3MtX88l5Jo+kA4u2s3ncb4lYS2TutY9fvP
zF+eKnJEGEIGJ4Hx20MCjpD0p9hPwwZN3laaK/GMePTxpSu7q64vqv1dO3F0rFf1jvOLzgcsbWJc
8wrVsb9Xfpby+YkJyadH6R4GNR8cGicMjWpZc/VPY1J+aLOm5F9rRDf6lrQUt8XNqXm6PFwcEfDs
KP/2xR03MmSOZKFgDur22gSHbw2DTqPT/Qqzq2xzd7Tuob1jq25swHP7MqbDhNb/yqm/PULRqLgn
4OGvMkJut1pxp9GstwCNPZss0DtxkJ5nsJgJE+4kgFzWnZKj0BHiGBR9lZKUGBUtkUqkk1A3bcp/
nIQ4GU3qMUooKCgQ5UNDAhqKjHZrJOzAdsJM2p2FkfJ0DbWG3ekQAUMhUOPZIgGV16JUbRKVyzHi
0Wh8jx9JkjnHTMIFsSQgt+gJAkQDIUgzG512AlLo5aHTW8xZetJst4H8KDEX9aLs2Tx6hkbMQ/0p
wZPHmaAnTLD0SLtN7If69ByFhxrPstptWeLBaCClYfADet3LIUe7s9vty3nuW+bhAYM3q8hN80ag
3pPuptGQhoqTQzdn/f1mwMEX1iKZivPUHp7bIhqo2RQVc+W06a+SLuydtqpO/FsNH+xnHvvw4TGH
tfLW8S+3h6OrozJn7dkyIzRnVePVgh9Y135sr3pcz/3Npi/i5zmuPrFPVs22+6oVCwPO4hfiAKs9
Yb1lRawPN5R3O+gbsET6oWEu61jIoE519bbq1Kqz8crMBHfRHS+JbrepMVGxIU68saNteUfGEcHm
jQfDVC0Plt1lDCm6FxC75cnW9Lksq+HuIl7ZqHPtgT7EAfaYr4YfvNm8NPfI/uxd67XB33FzZj1Z
UFi+LZuzdfyzLmdQZ+mUww/G+dzK1Iekte6MzbrC+3Tq0fnW1P7bEzxgIW90sy6ibta57ui8y2PS
UQTlUq++TCaDzqpBXWWURGO6StA5JX5FVX87Ie8yrbw/6rgt7ieue73xv1BIbha9AX4VokEUEyaN
9oI5AOWj1Jdf75ddfwbdowSB0YYQDpONQvLsMaibGdMHw6FM3cwQqB5SE1YyzESSDiI2MvJfFMZ6
N2Ofy81o0JrMBDDiTtKcbTbqSRyYuwuGSjacoKrGiWfjTtxmxAVAb8sCZpIAeQSEEYAgnWYjaSnk
EHmG6biRBKRdAEgTDnoP4ZVfql7SnXojSTVE2JpI3IrbSDAcMgnjQJoEBRCLULhIvt5s0RssFJPX
vfVuAOjJWM7bNhpHsVYIrdANxAG4gtCJ5+bhBEmMeR1nd3Ig9CXw9ZgKQJREGg3DqIcdUpaPQ0Wa
Pc9G6iErnRkvEMAQAukIdEQ0J0MjgzhHodOcYyKpJimWSmPecAeAzGIBagpBwB8iAvZkPEsE5Aq1
VoYpORNkarVMqcUUGpCEaeSpMixNkQRkyqQ+fTgVS8NgGxZxKLQSU6bEAu1YBcjQKIAqGb5imm53
WDIml2kVAIoarRqTa1MnAk1G4jiFXAu0KsqEo1OoMfjHStkHj6mUIF0tk2sxuQLaQQdpCqUW0qaW
wDSaDLjeP5iv8rAojiz+qqp7BgcVBfEAo62IgBp28MADJXIMh5wygiLqMpyiwChXQMCMI7qAyuGZ
IIp4LsEoJEHRRBGyoq64umJcQ9REVHBZ9SOJt2E6b1DAZXe/b//ab/tNz0xV16t6v987qlpwCpzn
4ReAtsi6jFR2IRA8ffy9Pd/arFjgH6BQKoUeVEiCr4t3oKt+lp5eGdrtowhw8cBmF0q/AMHNc56v
Xt0N/zsJ/k5oo0ugt1OA4B8Y4O+nVEzoXGS+p7e34Os3T+as6CTJW9Gp4OLnq1TMDUTjPZ28J6CK
r+c8z6C3Ol3G+iGqAMHVycfJXaG0FZQKhUyPU79f6OdwVeAobyUy7aLG3I9Hl6mjesdidEwiloXI
CCFeHa8Pq6iYyAjlm0RwSsLMCEvGBJJFpqJ+Z3CnqGKTI4XEpSqMg3h1khAWKYSr8VFE5ySqREEV
Hp6c8CYDo9QJcZ05I0t5s93gCIxUvQWeTrayffaayf9Nmnf1x6qj1bbRMVHyNUf1lUTg1hySa+Qa
iWHoeg+y/oWCSAnBDmuJAVYVnscKOnj4f5wfSZKHdY+k8iC56eBe9VCOhxViNqur0yqxk9mYnp24
u6YIsTGqMFshNglz4Z9Pl9B5yQe/U+nMOQO5BKsdfnqde/QntW3ee9MCm5IWbbCsOyi0x1Z/ke6W
vrtk1cmVEg9T48iGxTYv5jrkrKx8MmhaalP+EUONfcFijx1nYZpMWTN7qphrYhUH7pOfe3jbJvxc
37i6w1U9Ov+vm0vubn3UKsKFuscJw78rZvHHasPTJ6a6Ouxel/s6a/1Ua9vWg9OmOp789RethZ2W
G401eARClyf/D/aPf3MY7CsxeEMK5XnYs+awfFg3S32Y3bsbC4dnjJ6WoV2vbUc+skeRszPmBvB/
SJzY4FNRfbHt2eH4c/2Oyf3fGd7Xzlk+e89QzWBQQhrEQRioIRYEiMLfeEgqHaMZrY+mt8EU13Wo
6YympITkyKS0FZG/63Wk4bQEFp4zObesdVeO6seTIx4VVMiqis0dH5Y6DXGLiqzPO7/2uHaxc37u
w4JLs36cs+7zVcOO/lR8mL0KPl0cdzfpSnOTy08R1jWpL/2WbRly3KffpXu5YZuWfzZg1+il0h8G
DUvLGRP8yCorzGJYajLlppV4zTar+ZsiyNHad6j0vXCr+IXjtv190av0XV8mjMgsO/RMOXDn05aN
2sacktpRq4ya227HLAidVORFT3t8+vH+7PUPHG7r/HZebW061xw77tqp0K/ql14rslJZn89sVN0r
DLpsGmvsGXqPxHkmmnyyK9TkzgGLxlX16UK1yaqDQ0VIyWloKbxzMTivWTvzQv6hbN3Fk+n3J90Y
b12qJVfwVNfQ4wuJnZacwq4T+iBbU/1///5KTeHUwKIml0ejXrstyMr5s1t2geXjQaG9AjVYPvTd
ODXsbkgJhmn3E97OSP/qYSfHdw253ZRJkxf+S5i2FRb0u7ZXVrl6i/jcZJuRV++gWqNRpK+OC4mb
4pye8t39Gytemg70Kgy+3pBZK0b7OSY+zbgZNUW6PFIxqL85fCS+OlVUZlOc0lKVJh6Zmfn9om1P
HmsSSwaW9THL3HBhVNbENYNqL98XspraJmaHpN25IZqXbS101OaGWG6+te+p3Ni5dPVov6w+Hr+e
tN/p8PWnjb4tG8sT9UWNcJdIAfAAfBE/CZuWb37ZHoiixn0ZzxNKpBLKS6HX5aOOV8PsdqFd5Dfq
3MgkA0NSp+l+yi8GO94bRuI9nG0FcwDxztv7ni5YfMQvBwvdMvGmlREO/vLt/eZSgSUsARuYA3XQ
DqfJOPCHM+IVCIcF9EN4H/vz4TicgdvgChFAwYxkgCAWw0YYC2thD0znzMQq8IYHBkYwGMbADKIG
CZhCNOwmN8ETvHAOB3CHHEjA77nY/5xMwycEZLAYV98KO+E0/AV+gGE4oy1cR9c/F78CF6wo4ZAO
J+A278xvABMohENQBrVwn9iS/aSNPRarxAbxH6hlA3ZgDyFYfcJgM5TiuENwkVqwfaKZmC7+UTwP
w9H6ckRdC2dxrWdEIEEknB5kabpXYrxYjjz0RZvRehQnROMLSXAAR16H16QPipYK9AMarhsoDgEp
jMQKNx7tC8SKtxqyYROiKIISOAoPyAdkKblEHtN+VENreH+pr9S3T03Ht6K7+AzX6Auj0Nr5sBxS
UXMzbIHtqFmKa/0JpR06iD1xII7EkwSQfLKeHCAv6Hj6PX3N+jMjNoEFs1CWwZrZSwO+w0+3Q3dF
9BdTkUuCnMvQky6Icx4sghWQCB9CBmjQujyUAmSvHKUC+axB+QZuwV2UFngADzHmeMQoI+NQ5CgO
ZDaZQwLJ70k0SSQ7yDFSTU6Ts6SNPKGTqT2dTv1oAI2mK2gSLaAVtJLW0Hv0F7RyBlOwRPYRK2d1
7Dy7ypo44OZwKi6GS+a2chXct1w794TT8cBboNjyKn5Px16dly5EHCs6iGHiJrEA5QFyPALRjAUr
xOOPXg3HHSUaUa2AlShpyN06RLQddiN3evaOQTV8jVFah/6thyvQhPhuQTM8h5dIjh6fKRlF3id2
yO8s4o6yEP2UQjKIhuSRIuS5klShnCE3EaUOEQbRYLqEptAMuonuoDvpCXqGXkdPiEyCnhjK3JkX
m89C2BKWxLazj9knbDcrYdXsDKvnKDeD8+cSuLVcAbeXO8qd4xq5m7ycd+BzUSr4Kv4U3yIxlphL
JkuUkmqpxCDNoNVAB1/AOaiEqt65T7LJAFIJn5FWxjENbaALqCG9TrTcZWKFHphJgM/D3fZntPA9
cpVOJfNZOFmI/GlJFAmBXWw428vmQAMfT5TMn0SAktsBv/LfgIrPpZ8zyueyDvKSlsNSyKPLO8rE
YNIflGQ/PYgRkwkzwYYzg+t0OneCWFIbWiM9QqrBUSph09kMAyNs7Wd30UylgRFpAxX7jfxqC27i
OsP/2V3truULsjC2bGG0YpEcW5aNzcU31ZYsyRCEHdsyVAuk1cWiNkOxJwE6LiWlZSipCB5lMgOZ
XqaZDpMmTqY9MtCRMyn1W/uSJ2bcTukDhEv7UEomQ+g0xaj/WcnGTpm2j53pSt/57+f/91z27H6M
++cW7q1h7m18Jtwjf5RewOoW+V+gz0noJpeelMO7Bo2LkvXcJbJ78fTi7/kf5n5CqrmPARbLF32c
H1fcntwMdw0ewMUnfxduwjXuBuzBp0ZC3zmf4t77Bj5p9sJjrhT3UxifI5Penp7uL3m6Ojva27Zt
3dLasrm5yd3oaqh/rs7p2KRutCu2DbXrrTXVlqrKdRVrzeWmNWWlJcXGIlkSDQK+tUJjUO2LKtQZ
pYJT3bnTzWQ1horYCkWUKqjqW+1Dlajupqz29KLnwS94evOe3mVPYlI84HE3KkFVoR8FVCVL9g1F
kD8fUDWF3tf5fp0XnLpQioLdjhFK0DIWUCiJKkHad3wsFYwGsL9MsdGv+pNGdyNkjMXIFiNHq9TJ
DKnqJjrDVQU7MxzIpVgVrVEDQVqtBlgJlHcEY6N0cCgSDFjtds3dSIk/ocYpqL10jUt3Ab+ehop+
KulplHF2O3BOyTTOp17LmiAedZWMqqOxAxHKxzSWo9yFeQO06pt3LE9F7Nzsj5xdabXyqaBlXGFi
KnVWoW8NRVZa7azVNOwDYzlHXzTVh6lfw1EMhRXMxp3RIpScwZQKuxN2V/n7S6pBpokeUmiR2quO
pQ5FcW5qUhSGp+yzNTXeudxNqAkqqZGIaqc9VlWLBdZnKiA1PHW52qtUr7a4GzOm8vzAZsrWFJiS
0pVMctmmc7o740LDyyNLWEXq87giqJJQsJKIivfUzppkO6QS7eiGl0Ywio7ijIzTIn80ZepkehZP
DQ6TqqQ+A1wB6v2/rNbEChrRYfoMGMvWyfJaQ/sST10u2tDAlojkxznFGrt1eZu78XiW86mTJgUJ
Dh8M4tjGtM5mHH67nU3wuawX4ijQU0ORvKxA3DoL3maXRrkos8wvWdbtYZZTS5bl8KiKK/kKnl8A
66jsXP6vMVWuDY51UlL5b8zJvD0UVkND+yJKMBUtjG1oZJWUt7cv2wocXeuP8FauwHFWXrfiojyw
7MyESAkVHPgX9UU9mpVkXJW6hih91BTdmW81o93+XwZlc5+wKJ08DSuUSTtdq+WuVfKq8kpSPBYs
OLnQyL5UyrjSBmzQ5OIn3djuffLe4yb5qD6MK69rwkd4qrLrc8BXO8QM3DFcgZgA4BBGYUicgR1i
B+zkT0Mn2kYQbrS9jjYH+h8p0Ne5jlwO9bsQnyAaEWGEgogjNMRuxLcQQ1wHvI84h7EeFs8ofx4i
jDf8BioMe2EjUrNwF2qE21AnWmGncB1U1Dkx/xZDCQwg7zCchAqplsXk/ozybtGBPn/FGl4Gp/Ah
tGNsl+EMVGLtO9DWbqiHXvEA5rsNldjPz8Q/kUNIdxkCqIPcAwH4P2DfI1jHFKKPfwhBjH1ecMEO
fhfe33Vwcz8FP9Ig2tchWoQf4T254DnkWf1tyGtIx9FnAGNdaN+B4+nDWgf5T2E/0mbsdz//O7hO
fgCXkC6g/1bhEawln+t5PQRnC2O241iBKMKcKJLNSP+GeCTvhXrpLoSw/xeXKL8FDrKxwxN+vDCm
Uxh/EPP4+J/DocIYM2xiuWSAe8J1rkOG3Hm8d0W8gHN+Etw4Nl+R7pLv4lgN6LgAMaT9DNhfO6IN
0VVAp+EKMSKK0R5GeZc4DAkGyQatGNuEuUbY2kDbZqxTR6H+3YX6dYp1NuO4+pbixV3QgDEu3gzh
FYBlPMT3jYf4naNTcgljjmF8N9eC30EnubfzAD9vzr3Bm7kX8xRU5L+jU4wll2C9bx2YuTr8OTkn
TJBK3B1f1dsX9LZHb5tZyzXPNttsWa5p9i1GGmdr65Fs8hbfqrG11JltnjomV3m7Dtfbbs5U224h
3qtrtb3qabWdRjQjjqPM/Opm6m0TdRNfn/jexFmhDSorcZbN5bI3S27/ck9FUUVRWzpLfu3tkNK/
ktKXpfTXpPSolP6ylO6T0tuldJOUdklph5TeJFXIZtkkl8klslGWZVEWZE4GuSKbu+l1sc1fIZoY
EQXWCjpv4ljLNjo+CTgic/h1R9fyIS4U7qXtrlBWyg3TNleISoP7IxlCpjXUUu7VLIGRSJbkmOqM
lZ3ac0BI7sx5a4FqGgnR+QSE4gp9FFazxIgPKoPaS6g5BKGRXgtUHu+x9Ji7yzv6As9oooXW9fSy
uFZeocGpD8FGjrGPL3L0smR7Q2LaMGrTujbNtGlda6mlF0LhCJ2p1WgrY3K1Grnsu+o9wd4Domow
iYjSc8fHLPRUXFEy3quFFwRnNJ4YYzSWpFfVZIB61YCS8Z14hvkEM/vUQAZOBEcimRPeZGDW5/UF
1VhAm4MBEs80TK9K9/2ldHPQQOL/2mOWxFmXDSzjwPQzMk4z8wDLOM0yTrOMA94BPWNwPNxLQoOR
jAy9Gh4+Or3MFRtxqqJWu9ZbaZrs1uety255xfqBAOQdKMazuATf60oRzOT2uX3MhAuGmcrYK1/B
ZHmly279gLxTMJlQXa72guuY6wvXy+wCS3A8wICVzOXmuVOzZlurS2PnDMeOIPz6w22Mk9bl3SBK
CdQZhAQPRtGQ4HmupkgSEgSq5fp2i2vA9NDTv+gZMD3y9JsWPdDjWfQwtGy2l9vLHdjg2obHCj//
2GuAf+CJM6+fcte5G/jsKwb7HPDkiresSIKaUrG6pPSBnXXrGrhjugc9/fdbNpMKUd3o3LZ1+5bW
Su7GwsU3FxbevLjA+fJ0QT8dW//Pftr/2I9dRnhl+f3l2/knGLBVtAalPC8gP13gReR/jFYQilB6
Au8XeAIbyEyB56CM/LbA86hfKPAC8g8LvAgbOPPI1GTyYCyRVN5VRsaSSv/EkYmjqFL8Ey9NTrwU
Ozo+cUSZPJxoUgKxo7H/4NTMOlPCE4ePMc0/S6V6noShKHpCQtKEAf+AydsJn1ujMQIOEi2Q0t0U
qYXkAaavkDRxcPZvOLk6M7Cz+gecnBxdgdMLMupAmvt17rnv3CbXqNaEc1XbrhTpaiVV11q5o3AY
G+UGJojmwcBpdJrddqGXjPtT7Xh/l/CQ4BEBHuDjnlHhjeZhKLmDKSa0eM9SaLKKmKfeJz4ShiKi
OV9idiW4f+RL5cNmCj12NGYHjiHWYtzpVWHzq6C4z2qC1jmhGV3OhNwhlimX7xlahDn9gFs10OEm
XbRRoE6CMfqi5lA/ZYfU1dwv+od7THd3nUtqZeUaMzjh/18y+87mBUn7mWesnm5e7vLnP9apJfDr
9eIsje+3H5+bzfrC+rJyLHO/l78F0nkyzAoNCmVuZHN0cmVhbQ1lbmRvYmoNMTQ3IDAgb2JqPDwv
VHlwZS9Gb250RGVzY3JpcHRvci9Gb250RmlsZTIgMTQ2IDAgUi9Gb250QkJveFswIC0yMjAgMTEx
MyAxMDA1XS9Gb250TmFtZS9NQk9DUE4rU3ltYm9sTVQvRmxhZ3MgNC9TdGVtViAwL0NhcEhlaWdo
dCAwL0FzY2VudCAxMDA1L0Rlc2NlbnQgLTIxOS9JdGFsaWNBbmdsZSAwL0ZvbnRGYW1pbHkoU3lt
Ym9sKS9Gb250U3RyZXRjaC9Ob3JtYWwvRm9udFdlaWdodCA0MDA+Pg1lbmRvYmoNMTQ4IDAgb2Jq
PDwvV1szWzI1MF0xMjBbNDU5XV0vVHlwZS9Gb250L0Jhc2VGb250L01CT0NQTitTeW1ib2xNVC9T
dWJ0eXBlL0NJREZvbnRUeXBlMi9DSURTeXN0ZW1JbmZvPDwvT3JkZXJpbmcoSWRlbnRpdHkpL1Jl
Z2lzdHJ5KEFkb2JlKS9TdXBwbGVtZW50IDA+Pi9Gb250RGVzY3JpcHRvciAxNDcgMCBSL0RXIDEw
MDA+Pg1lbmRvYmoNMTQ5IDAgb2JqPDwvVHlwZS9Gb250RGVzY3JpcHRvci9Gb250QkJveFstMjEg
LTY4MCA2MzggMTAyMV0vRm9udE5hbWUvQ291cmllck5ld1BTTVQvRmxhZ3MgMzQvU3RlbVYgNDIv
Q2FwSGVpZ2h0IDU3OC9YSGVpZ2h0IDQyMS9Bc2NlbnQgODMyL0Rlc2NlbnQgLTMwMC9JdGFsaWNB
bmdsZSAwL0ZvbnRGYW1pbHkoQ291cmllciBOZXcpL0ZvbnRTdHJldGNoL05vcm1hbC9Gb250V2Vp
Z2h0IDQwMD4+DWVuZG9iag0xIDAgb2JqPDwvQW5ub3RzIDIgMCBSL0NvbnRlbnRzIDMgMCBSL1R5
cGUvUGFnZS9QYXJlbnQgMTAgMCBSL1JvdGF0ZSAwL01lZGlhQm94WzAgMCA2MTIgNzkyXS9Dcm9w
Qm94WzAgMCA2MTIgNzkyXS9SZXNvdXJjZXM8PC9Db2xvclNwYWNlPDwvQ1MwIDEzMCAwIFI+Pi9G
b250PDwvVFQwIDEyOCAwIFIvVFQxIDEyOSAwIFIvQzJfMCAxMzYgMCBSPj4vUHJvY1NldFsvUERG
L1RleHRdL0V4dEdTdGF0ZTw8L0dTMCAxMzMgMCBSPj4+Pi9TdHJ1Y3RQYXJlbnRzIDE+Pg1lbmRv
YmoNMiAwIG9ials1IDAgUl0NZW5kb2JqDTMgMCBvYmo8PC9MZW5ndGggMTQxNS9GaWx0ZXIvRmxh
dGVEZWNvZGU+PnN0cmVhbQ0KSImsV9tu20YQfddXDPpEAtKKu7y7QdDETtoGSGDAavvQFMWKXIls
KFLgrqw4X9+ZJXVLRAmpCz9YpMiZOWfOnFlN7+HFi+n721/vwIOXL1/f3cJoevvgQabxBv2BzuoR
hxLv/4z3l3r0ejaazmYecJgtRh7MMnxqtqVHZxq4R/+/0K0WL1gappzbQHSRQOpB7HMWhGkawWw1
csCd/TN6Mxu9eU+pD+XwXTkn6QYi8oQlnuf5FyOK04i8B8A8D+MhioHYXsS8OI1jG/tOybwqa6Vv
hrL4x1luxd994RPKM5yIewl974cQpYJFaRomlO+F58UW2EtMdlqzoEhdVEH0cxYFIiTe89GfzsNm
viq1Lpsa3Em4L/sG3ssn4GIMwvMicP+avTuHIbiOwbb8MpA4ZSLyvPQakC5gF9zn32J5tTFF02r4
0JhyUar8Bt5tagXCJxRu4FwAEv4vQKKQJcIL4ytAeGTjDXTkj6b9pItmDb+4E9+R7kQ4dd5sDPyu
WtunQ4/ebaonEPxKk6KzA+JdwpR2Yo8hCn0mhHdlBOPzGc6J71KuwGNhxOnBVa9MN3E6cWpASjZV
Dm7ozBWs2wb7+UjclLnKQVUqM21Tl5msqid3EjtjerKsO1LOkS48JmJ/z/r9nRs7b8ewaFrQRta5
bHP47QEqZYxqJ7r8glnlWrXw0UlYCJ8PkXstTnYRJ5zx0O/CItKyzgqlP7oM7u37ejN3J4mzwnyE
jaaO8NH1hgBpA3VjQH3OFCLj4RGEgCBgGj+O94Wv5VJpLEqX9bJSoNcyU2Mw2wayptpQ1JqiEjBK
tZIGtjapKQ6Rz4zWZJfnBM4PQD2Rru+0yxKr3lBakNhK7AesDWCW2CHuK9kuEe2iqc1HF5BQKOSj
ghqfaw6I0qO8nPd9iZNE8B0+KBRlzDFWQ+EabAcY9dkgZsWWbNyHJIyYluiAekNVznFeiPYjAsO9
Bg4gu2zHKO/bZt1oWWmrBgraKq1qI41VIt5by1pVe02iIOvmTJsCL0j3OKqmJj5MIWtYlMhEX6z+
sYtGmu6z7qR+kG66r5vv6+6iU91BHPIuCWqt2uSo1IaUFTnzSnXRS220bQJmL+sc5wQJIjjQLGBb
lJnLnYJaaKvavWA7ljX1omyJUNVVRAX4NLoi6NE5OeJSJfHSmjIr15YpNmQXybAhXfKHMI6ZL3gU
X/SidNCLvrHdS7migEURj4POi+4rJbWyG1L3tmTogmCjSKqq2dIclDUKxg6Ipdb0ovjK/ZOD88Z4
vvHTtGexkLqYLDZ1Rm//VGML2LJ5dLv98RVLPML93783eDLynnHEoGkIQ47uL4R/bqEdMxvsmQ2+
XWgf5AodSS4WZVVKSxvCG4Mib5JlNYZ10dT4BIrWyApknuO4dbNH9K7bciXbJ/JM0qKR+FrmCseA
tPt+cO9x/tylbjnwY7QINPZrHNi2niJ/W7bk5rIbHoFLqZJf3bAz2VPTjyOOoJJZgWAn1xCK5zZY
BMwP/Gc2eEZDUKJeC5V3BoJ7Dvt55Jpj6J30xOpwYOD+7i21mvaSJIsCaQyitysS397Z9zn0/n88
2AgfkXPEkPgivfzbIni2m1CyIE0ZfYg6N3lVVaCPTjeE1S5pjasZv8N9IrNPdbOtVL5UORtmIHwG
A0ESsUD4ncUNMzBwevxeBmKfxZGf8I6Bn1WtWtv/rvWkfDmnQ65LBxMF290huLTE0FYjgzX2MACt
WqI5tv17NEFZZllcEaf2U06vdQ9c2KPefu/f2e15Yt/7XjyiS0lapajRk+K2aq5xEUQOnsVPe/SA
Qj9wGA//oEwu9cr3BQt5igsiiLBOKrvjrzBmfTOdbrdbtlsT0wKps78WjpbIoHC+dwVDECQsOCOV
fwUYAKfX/FcNCmVuZHN0cmVhbQ1lbmRvYmoNNCAwIG9iajw8L1VSSShodHRwOi8vd3d3Lm5pc3Qu
Z292L2hhc2hfZnVuY3Rpb24pL1MvVVJJPj4NZW5kb2JqDTUgMCBvYmo8PC9IL0kvVHlwZS9Bbm5v
dC9SZWN0WzMzMi41MTk5ODkgNDU3LjcyOTA2NSA0OTIuNjY4ODg0IDQ3Mi4zNjU0NzldL0JvcmRl
clswIDAgMF0vQlM8PC9XIDAvVHlwZS9Cb3JkZXIvUy9TPj4vU3VidHlwZS9MaW5rL0EgNCAwIFIv
U3RydWN0UGFyZW50IDI+Pg1lbmRvYmoNNiAwIG9iajw8L0xlbmd0aCAxNTI2L0ZpbHRlci9GbGF0
ZURlY29kZS9UeXBlL09ialN0bS9GaXJzdCA4MDQvTiAxMDA+PnN0cmVhbQ0KeNrMWNtu20YQ/ZUF
+pxw7xcgMJA4Neo6jQXLfTL8oNhs6saWBJlq4359z+wsHSkkRRBNizzYq92dOTtz5rIklRFSKCuU
1EI5YbQRygtjMQvChCRUFD5iP4mEDQ1h6aTQSiiljNCQUx7rUNPQ0JDUXgnthDLSCe0x2iR0wCE4
QkeMDusAdnQQ8JyXwgDPS4vzMdooDJmRNAyBHRZywIsScsCLHuvASxIWAi85zIGXUhAWpkkYb2GC
9Engp1ZKCgtTFZSsxeitsDABGwLQWrsoLEwne3G0NjCCTDbBCHLV4lwHPAsncJS2wQoHPAcSHPCc
j4Jc8jDCAc+DDwe8AFoBrQOMcUQB5OCqDskJoigC1BMlCevASwCDaUZKrCMUEiCAMgq8eLiqSB7U
KPgJ14yGUwGUAEAEBcpAUgAVJioB0w3ZC1ONxSQAzyGGgagEeACeR/AC8HyUAoE2xDN+IuhGAMJE
kBmBF2MQEXgJwUAmmIS4RFBFeRA9qJZRQMQiUCKCShArIlEPYxNRj2RIoNoADKrWAhdHWAu/E4UC
zoMS6xGnBDwPvymUlHaJQgP+EvCIP4VYWCJQgSQbKf2QVTYiXkoCMwKA+LIJ5CgKaEqUsoiIpJxB
yjhJ6QybnVKkjqBRRlCWgCHKZ4RLU6Jj22lkxKtX1eXTuq7mzWZ701xu6vpitWqqM6obKS6q4/vF
4+MvizUVEM1ni029zHJUS/sr7+vPzVn9JEx1sbqvs1IgkaMjnHJ25fOEwpyHlAcEOQ+KB82D4cHy
kE+GyawfWSOyRmQN8jlPeUgsmljTZUOpbmmwLGIYxjCMYRhbZqxuWFKXxWzwdTVD1WfH59W8vmmy
c+9Xm4fFPdqDefb3/fbh8UpSi8n2UZPJYNRmCCcLnW+b+7sl2F8vltWvy9t682XKmNWsugStb1af
q7d3f1Ynm8VDzb8QpuWqqSGHfz8ub79M5r8vENGTu4/bTV2dLglyb+ny/DX+jmk8pR/076SsnJSV
+XZdbx5vNnfrhs2Zbz/sTZvN3ad6tS3Tt5vV+nixbk84Xj08ICl+0PKi/q1GftwUp05W9/erv+rb
n5Bz5OsnXv5q+rD6+0XzuXlxc9fUzeLjY149Ovq3GRQ4DwKjBEYJaTirIqNERomMEhklht2Ei4yS
GCUxSmKUxCjJ7uak55lnEc96Li9eX3Ea0YWzk7e6ZDGfq0tupuFkNoxiGMUwivHDGa71bqLnmuWl
tkmcv/n5ojr/8IcoveCjUJzvVBUMgqp4hziWkudbNZfN8XNCt61l/rzyjENKaBoQ/pIRswIB+Z3F
fRW5C+9G4CfI6glmm+r1lTMdZ21qaXmzun36WsmSku4oOXlA6cqVsF+TsuqeGA6d6HdFOYsGXQoT
3I8TZNOUbJDw0vqul/qQl0qRlutqmUPE4lI0vmXW2q62PHim2ZXleht2y07hwE0RnhKJYuWs3Hzk
2mkhw5YrkbuIlc+3X4v4rsUwQxil9/RsnVfvFk/59mgWm+YUN9+yAfcvZb7tyvyFii/l/yB+1tbB
rDwc7NHAHZYrstRWLw3aD2GUnt2z9X3RcIWLY+/qoTLw3dJzrlMGeudBr22qs/Lgtcum43vH8b3j
CrdukFQ/CFWuzv4tObhlqDH4btN06ZBPvUw6O5xQhrqW794GLn7TY3SiY7ptzoVveMxkq+RYA9rL
FjVJWk+SNpOk7SRpN0naT5IOk6TjJGlKGaW7zxxKxcNlnW9ipVWP5sHiwb2qymP2dUboeSJUfuTs
vbiHOJZT0wKvpkVeTQu98uS16lYpvZ8f9jpkTdvDlxzRjFnT9GiqkVil8mqTY6V68kSGw2frvfqP
fqyiJzYATXbJ7q2URtJXm6zYDUMaiYK2WbEnCnIkCtplzZ4oyJEo4GEiPV/B9BmoY/RIwei9FpLM
GKsTe0j7yJfC1zd8Kl9gUvkuI8tYXon94FXPr9B9mOW1un9LDW/pga3/9v77rsTP2vqbtZ/IdmNV
GlDbTtrm0JZ4f5jMIF75UDKw54b2prj0jwADANV26gsNCmVuZHN0cmVhbQ1lbmRvYmoNNyAwIG9i
ajw8L0xlbmd0aCAyMjgvRmlsdGVyL0ZsYXRlRGVjb2RlL1R5cGUvT2JqU3RtL0ZpcnN0IDg0L04g
MTEvRXh0ZW5kcyA2IDAgUj4+c3RyZWFtDQp42rSPQYvCMBCF/8r8AU0mjWkLUnDBg1hRtoIH8VC3
UQqSSsjC7r/fmZauCnoQ9PQy730z5CFGIAFRg45JRpBqEgOokZQsk5ImoIhDTEGxryQo9hVCxKxS
EBnKVQQaJYzHYiny8rf5DqIIpQ8zV1kXYKSHUqztTz8PMBnKLHs7Poc4oZKfYtVW4lch8lmXbbkd
WW27Tg3rjmndw/0d8/AOxPGj7O53+XdPtHs9vvF1qN1x0VRW5H69v9mXtD511dXExyan+ug6ThTn
8st+2EPjbZu38+QQrP/HL9tZ9ifAAJFPrJYNCmVuZHN0cmVhbQ1lbmRvYmoNOCAwIG9iajw8L051
bXNbMCA5IDAgUl0+Pg1lbmRvYmoNOSAwIG9iajw8L1MvRD4+DWVuZG9iag0xMCAwIG9iajw8L0Nv
dW50IDIvS2lkc1sxMjcgMCBSIDEgMCBSXS9UeXBlL1BhZ2VzPj4NZW5kb2JqDTExIDAgb2JqPDwv
TGVuZ3RoIDM5ODkvVHlwZS9NZXRhZGF0YS9TdWJ0eXBlL1hNTD4+c3RyZWFtDQo8P3hwYWNrZXQg
YmVnaW49J++7vycgaWQ9J1c1TTBNcENlaGlIenJlU3pOVGN6a2M5ZCc/Pgo8P2Fkb2JlLXhhcC1m
aWx0ZXJzIGVzYz0iQ1JMRiI/Pg0KPHg6eG1wbWV0YSB4bWxuczp4PSdhZG9iZTpuczptZXRhLycg
eDp4bXB0az0nWE1QIHRvb2xraXQgMi45LjEtMTMsIGZyYW1ld29yayAxLjYnPg0KPHJkZjpSREYg
eG1sbnM6cmRmPSdodHRwOi8vd3d3LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50YXgtbnMjJyB4
bWxuczppWD0naHR0cDovL25zLmFkb2JlLmNvbS9pWC8xLjAvJz4NCjxyZGY6RGVzY3JpcHRpb24g
cmRmOmFib3V0PSd1dWlkOmFkMDAwY2JhLTUyZWItNDQwYi1iMGM4LTU5NDdjYjg2MWM2ZScgeG1s
bnM6cGRmPSdodHRwOi8vbnMuYWRvYmUuY29tL3BkZi8xLjMvJyBwZGY6UHJvZHVjZXI9J0Fjcm9i
YXQgRGlzdGlsbGVyIDYuMCAoV2luZG93cyknPjwvcmRmOkRlc2NyaXB0aW9uPg0KPHJkZjpEZXNj
cmlwdGlvbiByZGY6YWJvdXQ9J3V1aWQ6YWQwMDBjYmEtNTJlYi00NDBiLWIwYzgtNTk0N2NiODYx
YzZlJyB4bWxuczpwZGZ4PSdodHRwOi8vbnMuYWRvYmUuY29tL3BkZngvMS4zLycgcGRmeDpDb21w
YW55PSdOSVNUJyBwZGZ4OlNvdXJjZU1vZGlmaWVkPSdEOjIwMDYwMTI1MTkwNDM4Jy8+DQo8cmRm
OkRlc2NyaXB0aW9uIHJkZjphYm91dD0ndXVpZDphZDAwMGNiYS01MmViLTQ0MGItYjBjOC01OTQ3
Y2I4NjFjNmUnIHhtbG5zOnBob3Rvc2hvcD0naHR0cDovL25zLmFkb2JlLmNvbS9waG90b3Nob3Av
MS4wLyc+PHBob3Rvc2hvcDpoZWFkbGluZT48cmRmOlNlcT48cmRmOmxpPjwvcmRmOmxpPjwvcmRm
OlNlcT48L3Bob3Rvc2hvcDpoZWFkbGluZT48L3JkZjpEZXNjcmlwdGlvbj4NCjxyZGY6RGVzY3Jp
cHRpb24gcmRmOmFib3V0PSd1dWlkOmFkMDAwY2JhLTUyZWItNDQwYi1iMGM4LTU5NDdjYjg2MWM2
ZScgeG1sbnM6eGFwPSdodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvJyB4YXA6Q3JlYXRvclRv
b2w9J0Fjcm9iYXQgUERGTWFrZXIgNi4wIGZvciBXb3JkJyB4YXA6TW9kaWZ5RGF0ZT0nMjAwNi0w
MS0yNVQxNDowNToxMy0wNTowMCcgeGFwOkNyZWF0ZURhdGU9JzIwMDYtMDEtMjVUMTQ6MDU6MDQt
MDU6MDAnIHhhcDpNZXRhZGF0YURhdGU9JzIwMDYtMDEtMjVUMTQ6MDU6MTMtMDU6MDAnPjwvcmRm
OkRlc2NyaXB0aW9uPg0KPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9J3V1aWQ6YWQwMDBjYmEt
NTJlYi00NDBiLWIwYzgtNTk0N2NiODYxYzZlJyB4bWxuczp4YXBNTT0naHR0cDovL25zLmFkb2Jl
LmNvbS94YXAvMS4wL21tLycgeGFwTU06RG9jdW1lbnRJRD0ndXVpZDpjODM3MzAzMC1iM2VhLTQx
MzItOWRkZC1mODc1NmNmMDMzZDInPjx4YXBNTTpWZXJzaW9uSUQ+PHJkZjpTZXE+PHJkZjpsaT40
PC9yZGY6bGk+PC9yZGY6U2VxPjwveGFwTU06VmVyc2lvbklEPjwvcmRmOkRlc2NyaXB0aW9uPg0K
PHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9J3V1aWQ6YWQwMDBjYmEtNTJlYi00NDBiLWIwYzgt
NTk0N2NiODYxYzZlJyB4bWxuczpkYz0naHR0cDovL3B1cmwub3JnL2RjL2VsZW1lbnRzLzEuMS8n
IGRjOmZvcm1hdD0nYXBwbGljYXRpb24vcGRmJz48ZGM6dGl0bGU+PHJkZjpBbHQ+PHJkZjpsaSB4
bWw6bGFuZz0neC1kZWZhdWx0Jz5UaGlzIHdvcmtzaG9wIGNvbnNpZGVycyB0aGUgZnVsbCByYW5n
ZSBvZiBwdWJsaWMga2V5IHRlY2hub2xvZ3kgdXNlZCBmb3Igc2VjdXJpdHkgZGVjaXNpb25zPC9y
ZGY6bGk+PC9yZGY6QWx0PjwvZGM6dGl0bGU+PGRjOmNyZWF0b3I+PHJkZjpTZXE+PHJkZjpsaT5j
YXN3ZWxsPC9yZGY6bGk+PC9yZGY6U2VxPjwvZGM6Y3JlYXRvcj48ZGM6c3ViamVjdD48cmRmOlNl
cT48cmRmOmxpPjwvcmRmOmxpPjwvcmRmOlNlcT48L2RjOnN1YmplY3Q+PC9yZGY6RGVzY3JpcHRp
b24+DQo8L3JkZjpSREY+DQo8L3g6eG1wbWV0YT4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAog
ICAgICAgICAgICAgICAgICAgICAgICAgICAKPD94cGFja2V0IGVuZD0ndyc/Pg0KZW5kc3RyZWFt
DWVuZG9iag0xMiAwIG9iajw8L01vZERhdGUoRDoyMDA2MDEyNTE0MDUxMy0wNScwMCcpL0NyZWF0
aW9uRGF0ZShEOjIwMDYwMTI1MTQwNTA0LTA1JzAwJykvVGl0bGUoVGhpcyB3b3Jrc2hvcCBjb25z
aWRlcnMgdGhlIGZ1bGwgcmFuZ2Ugb2YgcHVibGljIGtleSB0ZWNobm9sb2d5IHVzZWQgZm9yIHNl
Y3VyaXR5IGRlY2lzaW9ucykvQ3JlYXRvcihBY3JvYmF0IFBERk1ha2VyIDYuMCBmb3IgV29yZCkv
UHJvZHVjZXIoQWNyb2JhdCBEaXN0aWxsZXIgNi4wIFwoV2luZG93c1wpKS9BdXRob3IoY2Fzd2Vs
bCkvQ29tcGFueShOSVNUKS9Tb3VyY2VNb2RpZmllZChEOjIwMDYwMTI1MTkwNDM4KT4+DWVuZG9i
ag14cmVmDQowIDEyNA0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDE5NjgyIDAwMDAwIG4NCjAw
MDAwMTk5NTMgMDAwMDAgbg0KMDAwMDAxOTk3NSAwMDAwMCBuDQowMDAwMDIxNDU5IDAwMDAwIG4N
CjAwMDAwMjE1MjMgMDAwMDAgbg0KMDAwMDAyMTY4NCAwMDAwMCBuDQowMDAwMDIzMzA3IDAwMDAw
IG4NCjAwMDAwMjM2NDMgMDAwMDAgbg0KMDAwMDAyMzY3NiAwMDAwMCBuDQowMDAwMDIzNjk5IDAw
MDAwIG4NCjAwMDAwMjM3NTggMDAwMDAgbg0KMDAwMDAyNzgyNCAwMDAwMCBuDQowMDAwMDAwMDAw
IDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAw
MDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAw
MDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQow
MDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBm
DQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUz
NSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2
NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAw
MCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAw
MDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAw
MDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0K
MDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUg
Zg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1
MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAg
NjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAw
MDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAw
MDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAw
MDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYN
CjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1
IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1
NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAw
IDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAw
MDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAw
MDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQow
MDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBm
DQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUz
NSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2
NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAw
MCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAw
MDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAw
MDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0K
MDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUg
Zg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1
MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAg
NjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAw
MDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAw
MDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAw
MDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYN
CjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1
IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQp0cmFpbGVyDQo8PC9T
aXplIDEyND4+DQpzdGFydHhyZWYNCjExNg0KJSVFT0YNCg==
--=====================_17399171==_--



Received: from 64.182.135.10 (10-135-182-64.cust.propagation.net [64.182.135.10] (may be forged)) by above.proper.com (8.12.11/8.12.9) with SMTP id k0PGrecr044404 for <[e-mail]>; Wed, 25 Jan 2006 08:53:44 -0800 (PST) (envelope-from [e-mail])
From: "Triple Crown Stocks" <[e-mail]>
To: <[e-mail]>
Subject: TripleCrownStocks.com features Water Technology Stock
Date: Wed, 25 Jan 2006 08:53:46 -0800
MIME-Version: 1.0
Content-Type: text/html;
Content-Transfer-Encoding: quoted-printable
X-Mailer: Instamail v2.01
Message-Id: <p[5


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 k0O835NX059877; Tue, 24 Jan 2006 00:03:05 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k0O8359d059876; Tue, 24 Jan 2006 00:03:05 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.nbusr.sk (fw.nbu.ba.netlab.sk [213.215.74.202] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0O8319O059869 for <[e-mail]>; Tue, 24 Jan 2006 00:03:04 -0800 (PST) (envelope-from [e-mail])
Received: from [127.0.0.1] ([10.0.250.204]) by mail.nbusr.sk with esmtp; Tue, 24 Jan 2006 08:58:32 +0100 id 000C3B1A.43D5DE2A.0000CF76
Message-ID: <[e-mail]>
Date: Tue, 24 Jan 2006 09:03:31 +0100
From: Peter Rybar <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; cs-CZ; rv:1.7.5) Gecko/20041217
X-Accept-Language: sk, cs, en-us, en
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", Dave Cooper, 13-Jan-06
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hello,

I am very pleased to see your document which supersedes obsolete RFC 3280.

I compared the draft with the old RFC 3280 and I identified there 
several useful requirements that are similar to requirements published 
in documents on our web:
http://www.nbusr.sk/NBU_SEP/en_9.php
http://www.nbusr.sk/NBU_SEP/en_10.php
http://www.nbusr.sk/NBU_SEP/en_11.php
http://www.nbusr.sk/NBU_SEP/11_2.php  - finalCertCrl.zip

Our intend was to prepare easy readable documents containing simply 
understandable description of some standards and the best practices.
The documents can be helpful for SW developer, auditors or users to get 
a better view in a short time of the usage X.509 certificates in 
qualified electronic signatures.

Let me present some additional ideas which I considered to be useful in 
your draft.

Under the mandatory requirements:

If CRL1 (OCSP1) is issued then it is not possible to issue such CRL2 
(OCSP2) which would revoke a certificate before issuing time of CRL1 
(OCSP1) in which certificate has not been revoked yet.

It is useful in the verification process, because verification algorithm 
need found only one CRL (OCSP) issued after required time and it does 
not need to wait the whole caution (grace) period.

Under the optional requirements:

I recommend that certificate in the CRL (OCSP) can not be found in 
revocation reason certificateHold or removeFromCRL, thus its validity 
can not be stopped for certain period.
It eases verifying algorithms and enables to employ only final complete 
CRL and avoid SW application to collect all issued CRL to check if some 
certificate maybe has been in status certificateHold and removeFromCRL.

These CA practices are currently common in some countries as it was 
discussed with some participant at ETSI meeting in Sophia Antipolis in 
January and are useful in long term validation.

Best regards

Peter Rybar
National Security Authority of the Slovak Republic




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 k0NNo6oL023592; Mon, 23 Jan 2006 15:50:06 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k0NNo6MS023591; Mon, 23 Jan 2006 15:50:06 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from newodin.ietf.org ([132.151.6.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0NNo2id023585 for <[e-mail]>; Mon, 23 Jan 2006 15:50:05 -0800 (PST) (envelope-from [e-mail])
Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1F1BRi-0007OR-4R; Mon, 23 Jan 2006 18:50:02 -0500
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-scvp-22.txt 
Message-Id: <[e-mail]>
Date: Mon, 23 Jan 2006 18:50:02 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?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		: Standard Certificate Validation Protocol (SCVP)
	Author(s)	: A. Malpani, et al.
	Filename	: draft-ietf-pkix-scvp-22.txt
	Pages		: 82
	Date		: 2006-1-23
	
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-22.txt

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] 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-22.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:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-scvp-22.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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-scvp-22.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-scvp-22.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--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 k0NLgVRW014308; Mon, 23 Jan 2006 13:42:31 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k0NLgVZD014307; Mon, 23 Jan 2006 13:42:31 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] 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 k0NLgT6c014300 for <[e-mail]>; Mon, 23 Jan 2006 13:42:30 -0800 (PST) (envelope-from [e-mail])
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 k0NLgLIC015618 for <[e-mail]>; Mon, 23 Jan 2006 16:42:22 -0500 (EST)
Mime-Version: 1.0
Message-Id: <p06230917bffadef556f7@[128.89.89.106]>
Date: Mon, 23 Jan 2006 16:42:26 -0500
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: Last Call on CMC
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: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I am initiating a two-week last call period for the most recent version of CMC:

draft-ietf-pkix-cmc-trans-04.txt

Please direct any comments to the list before February 6, 2006.

Thanks,
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 k0KMJqvr019482; Fri, 20 Jan 2006 14:19:52 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k0KMJqBT019481; Fri, 20 Jan 2006 14:19:52 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from newodin.ietf.org ([132.151.6.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0KMJp4D019475 for <[e-mail]>; Fri, 20 Jan 2006 14:19:51 -0800 (PST) (envelope-from [e-mail])
Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1F04bm-0000sw-SO; Fri, 20 Jan 2006 17:19:50 -0500
X-test-idtracker: no
To: IETF-Announce <[e-mail]>
From: The IESG <[e-mail]>
Subject: Last Call: 'Using the GOST R 34.10-94, GOST R 34.10-2001 and GOST R  34.11-94 algorithms with the Internet X.509 Public Key Infrastructure  Certificate and CRL Profile.' to Proposed Standard 
Reply-to: [e-mail]
CC: <[e-mail]>
Message-Id: <[e-mail]>
Date: Fri, 20 Jan 2006 17:19:50 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

- 'Using the GOST R 34.10-94, GOST R 34.10-2001 and GOST R 34.11-94 algorithms 
   with the Internet X.509 Public Key Infrastructure Certificate and CRL 
   Profile. '
   <draft-ietf-pkix-gost-cppk-05.txt> as a Proposed Standard

This document contains a "downref."  That is, there is a normative dependency
in this document on an Informational RFC.  This is not uncommon when the
Informational RFC contains details of cryptographic algorithms, as is the
case here.  This document contains a normative reference to:

- Popov, V., Kurepkin, I., and S. Leontiev, "Additional
  Cryptographic Algorithms for Use with GOST 28147-89,
  GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94
  Algorithms", RFC 4357, January 2006.

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
[e-mail] or [e-mail] mailing lists by 2006-02-03.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-pkix-gost-cppk-05.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 k0KKo4vR012768; Fri, 20 Jan 2006 12:50:04 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k0KKo4Jj012767; Fri, 20 Jan 2006 12:50:04 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from newodin.ietf.org ([132.151.6.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0KKo37S012752 for <[e-mail]>; Fri, 20 Jan 2006 12:50:03 -0800 (PST) (envelope-from [e-mail])
Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1F03Cs-0003UP-GA; Fri, 20 Jan 2006 15:50:02 -0500
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-srvsan-01.txt 
Message-Id: <[e-mail]>
Date: Fri, 20 Jan 2006 15:50:02 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?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 
                          Subject Alternative Name for expression of service name
	Author(s)	: S. Santesson
	Filename	: draft-ietf-pkix-srvsan-01.txt
	Pages		: 9
	Date		: 2006-1-20
	
This document defines a new name form for inclusion in the otherName
   filed of an X.509 Subject Alternative Name extension which allows a
   certificate subject to be associated with the service name and domain
   name components of a DNS Service Resource Record.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-srvsan-01.txt

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] 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-srvsan-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:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-srvsan-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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-srvsan-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-srvsan-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--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 k0KERngF074216; Fri, 20 Jan 2006 06:27:49 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k0KERnAV074215; Fri, 20 Jan 2006 06:27:49 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from robin.verisign.com (robin.verisign.com [65.205.251.75]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0KERl8E074207 for <[e-mail]>; Fri, 20 Jan 2006 06:27:47 -0800 (PST) (envelope-from [e-mail])
Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by robin.verisign.com (8.13.1/8.13.4) with ESMTP id k0KERiXM018947; Fri, 20 Jan 2006 06:27:44 -0800
Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Jan 2006 06:27:43 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: The new High Assurance SSL Certificates
Date: Fri, 20 Jan 2006 06:27:43 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: The new High Assurance SSL Certificates
Thread-Index: AcYdjKshU2/X5VkYTFiDzowjZ4Ta6QAPaZlw
From: "Hallam-Baker, Phillip" <[e-mail]>
To: "Jeffrey I. Schiller" <[e-mail]>, "Aisenberg, Michael" <[e-mail]>
Cc: "Joel S. Kazin" <[e-mail]>, "Anders Rundgren" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 20 Jan 2006 14:27:43.0945 (UTC) FILETIME=[AD4A0B90:01C61DCD]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id k0KERl8E074208
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> [mailto:[e-mail]] On Behalf Of Jeffrey I. Schiller

> So If I were to incorporate AO1 Computers as my legitimate 
> business name and obtain the domain name AO1.COM (this is 
> hypothetical, I'm sure its not available :-) ), A High 
> Assurance CA would deny me a certificate because it looks too 
> much like an AOL certificate?
> 
> Is that really right?

No, there are some domains that you SHOULD be denied, AOL.com as an
international domain with the 0 from the Martian code set circle of
harmony. &ct.

However it is impossible to enumerate all the possible rules in advance
and EVEN WITHOUT international domain names there is a major business
detecting lookalike and cousin domains just in the ASCII character set.
Phishing gangs register names like security-bizybank.com.


> How do you decide which domains are "famous" enough to 
> deserve this protection? What constitutes a domain name that 
> looks too much like a famous domain?

It's a permissions based security approach - enumerate all the possible
failures in advance and try to stop them. Not a practical or effective
strategy in an open system with a billion users.


> On the other hand. If I obtain a high assurance certificate 
> and then use it to confuse consumers into believing my site 
> is AOL (it looks like AOL's, it abuses their trademarked 
> logos etc.) I am clearly acting in bad faith. If a High 
> Assurance CA had previously issued me a certificate, it would 
> be justified in revoking it. This is why I believe revocation 
> is a critical technology to making progress.

Revocation is critical. But revocation is not just a technical process,
there has to be a process to make the decision to revoke. That will
inevitably have to be human driven and is going to take some time, hours
rather than minutes. All owners of major trademarks like AOL will have a
trademark protection company monitoring its domain, the CA does not need
to be the only party detecting abuse.

Revocation is one aspect of an accountability scheme but where we need
to do more than deny the attempted fraudster their entry fee. We need to
hold someone accountable for the attempt, either the fraudster
themselves or the agent who set up their false corporate identity.

> It is easier to detect bad actors (and deal with them) then 
> assume someone *might* be a bad actor ahead of time and deny 
> them access to commerce by denying them a high assurance 
> certificate up front.

The real issue here is scope. The origins of the high assurance project
was with the people who still think that the function of a CA is to
establish identity, it isn't. The job of the CA in this environment is
to make it safe for the consumer by ensuring that the certificate
subject is accountable.

I would prefer to be discussing High Accountability SSL Certificates.



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 k0KDTSdh069596; Fri, 20 Jan 2006 05:29:28 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k0KDTSF2069595; Fri, 20 Jan 2006 05:29:28 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from chico.itss.auckland.ac.nz (chico.itss.auckland.ac.nz [130.216.190.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0KDTRd4069587 for <[e-mail]>; Fri, 20 Jan 2006 05:29:28 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by chico.itss.auckland.ac.nz (Postfix) with ESMTP id 0FA6934BB3 for <[e-mail]>; Sat, 21 Jan 2006 02:29:22 +1300 (NZDT)
Received: from chico.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpb.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05945-08 for <[e-mail]>; Sat, 21 Jan 2006 02:29:21 +1300 (NZDT)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by chico.itss.auckland.ac.nz (Postfix) with ESMTP id E99AC34598 for <[e-mail]>; Sat, 21 Jan 2006 02:29:21 +1300 (NZDT)
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id BD3E23774E for <[e-mail]>; Sat, 21 Jan 2006 02:29:21 +1300 (NZDT)
Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1EzwKZ-0005sN-00 for <[e-mail]>; Sat, 21 Jan 2006 02:29:31 +1300
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: RE: The new High Assurance SSL Certificates
Message-Id: <[e-mail]>
Date: Sat, 21 Jan 2006 02:29:31 +1300
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Marc Poulaud" <[e-mail]> writes:

>In the UK, if you try to incorporate a company with a similar name to
>another, your application will be turned down citing the similarity to avoid
>a AO1 type of problem.

You wouldn't need to do that, just get a "trading-as" certificate (a DBA cert
in the US) for (say) aolsecure.co.uk and get a cert for that (I'm using that
particular form because of existing precdent set by the visa-secure.com SSL'd
phishing site, but you can insert your name variant of choice).  Or create a
self-signed cert with all the high-assurance decorations in it.  Either is
fine for phishing purposes.

Peter.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0KAXW20053174; Fri, 20 Jan 2006 02:33:32 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k0KAXWwb053173; Fri, 20 Jan 2006 02:33:32 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail19.opentransfer.com (mail19.opentransfer.com [72.41.4.21]) by above.proper.com (8.12.11/8.12.9) with SMTP id k0KAXUUC053164 for <[e-mail]>; Fri, 20 Jan 2006 02:33:31 -0800 (PST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Received: (qmail 6110 invoked by uid 399); 20 Jan 2006 10:29:50 -0000
Received: from unknown (HELO ACERMP) (80.229.86.78) by mail.opentransfer.com with SMTP; 20 Jan 2006 10:29:50 -0000
From: "Marc Poulaud" <[e-mail]>
To: <[e-mail]>
Subject: RE: The new High Assurance SSL Certificates
Date: Fri, 20 Jan 2006 10:29:58 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Thread-Index: AcYdhhdH0pwroycrRqmLTs7eUlRb+AAGKStw
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

My 2 euro cents...

Depends on what the perceived role of the HACA is and what expectation users
might have. Let's face it, users will probably ignore any
guidance/disclaimers/warnings/T&Cs.

In the UK, if you try to incorporate a company with a similar name to
another, your application will be turned down citing the similarity to avoid
a AO1 type of problem.

IMHO, unless there was this type of control by the HACA, acceptance by users
and technology to enforce this on the user PC, it would seem unlikely to get
any real traction.

Marc.
-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Jeffrey I. Schiller
Sent: 20 January 2006 05:15
To: Aisenberg, Michael
Cc: Joel S. Kazin; Anders Rundgren; [e-mail]
Subject: Re: The new High Assurance SSL Certificates


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

So If I were to incorporate AO1 Computers as my legitimate business name
and obtain the domain name AO1.COM (this is hypothetical, I'm sure its
not available :-) ), A High Assurance CA would deny me a certificate
because it looks too much like an AOL certificate?

Is that really right?

How do you decide which domains are "famous" enough to deserve this
protection? What constitutes a domain name that looks too much like a
famous domain?

On the other hand. If I obtain a high assurance certificate and then use
it to confuse consumers into believing my site is AOL (it looks like
AOL's, it abuses their trademarked logos etc.) I am clearly acting in
bad faith. If a High Assurance CA had previously issued me a
certificate, it would be justified in revoking it. This is why I believe
revocation is a critical technology to making progress.

It is easier to detect bad actors (and deal with them) then assume
someone *might* be a bad actor ahead of time and deny them access to
commerce by denying them a high assurance certificate up front.

			-Jeff
- --
============================================================================
=
Jeffrey I. Schiller
MIT Network Manager
Information Services and Technology
Massachusetts Institute of Technology
77 Massachusetts Avenue  Room W92-190
Cambridge, MA 02139-4307
617.253.0161 - Voice
[e-mail]
============================================================================
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFD0HHA8CBzV/QUlSsRAqqzAKC725wPnb61lKKJo0Jg6i9bmOWeKQCdGvzT
zE6wOjwtxTfop4IvEYSGI0Y=
=RA67
-----END PGP SIGNATURE-----




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 k0K5FJK0029311; Thu, 19 Jan 2006 21:15:19 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k0K5FJXW029310; Thu, 19 Jan 2006 21:15:19 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0K5FFjH029303 for <[e-mail]>; Thu, 19 Jan 2006 21:15:16 -0800 (PST) (envelope-from [e-mail])
Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.12.4/8.9.2) with ESMTP id k0K5FBLd028801; Fri, 20 Jan 2006 00:15:11 -0500 (EST)
Received: from [192.168.94.131] (JISVPN.MIT.EDU [18.100.101.102]) (authenticated bits=0) (User authenticated as [e-mail]) by outgoing.mit.edu (8.13.1/8.12.4) with ESMTP id k0K5EsMn002257 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 20 Jan 2006 00:14:54 -0500 (EST)
Message-ID: <[e-mail]>
Date: Fri, 20 Jan 2006 00:14:42 -0500
From: "Jeffrey I. Schiller" <[e-mail]>
Organization: Massachusetts Institute of Technology
User-Agent: Debian Thunderbird 1.0.2 (X11/20050331)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Aisenberg, Michael" <[e-mail]>
CC: "Joel S. Kazin" <[e-mail]>, Anders Rundgren <[e-mail]>, [e-mail]
Subject: Re: The new High Assurance SSL Certificates
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.92.0.0
OpenPGP: id=F414952B
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Score: 1.217
X-Spam-Level: * (1.217)
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

So If I were to incorporate AO1 Computers as my legitimate business name
and obtain the domain name AO1.COM (this is hypothetical, I'm sure its
not available :-) ), A High Assurance CA would deny me a certificate
because it looks too much like an AOL certificate?

Is that really right?

How do you decide which domains are "famous" enough to deserve this
protection? What constitutes a domain name that looks too much like a
famous domain?

On the other hand. If I obtain a high assurance certificate and then use
it to confuse consumers into believing my site is AOL (it looks like
AOL's, it abuses their trademarked logos etc.) I am clearly acting in
bad faith. If a High Assurance CA had previously issued me a
certificate, it would be justified in revoking it. This is why I believe
revocation is a critical technology to making progress.

It is easier to detect bad actors (and deal with them) then assume
someone *might* be a bad actor ahead of time and deny them access to
commerce by denying them a high assurance certificate up front.

			-Jeff
- --
=============================================================================
Jeffrey I. Schiller
MIT Network Manager
Information Services and Technology
Massachusetts Institute of Technology
77 Massachusetts Avenue  Room W92-190
Cambridge, MA 02139-4307
617.253.0161 - Voice
[e-mail]
============================================================================
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFD0HHA8CBzV/QUlSsRAqqzAKC725wPnb61lKKJo0Jg6i9bmOWeKQCdGvzT
zE6wOjwtxTfop4IvEYSGI0Y=
=RA67
-----END PGP SIGNATURE-----



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 k0J2rslj001355; Wed, 18 Jan 2006 18:53:54 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k0J2rsXF001354; Wed, 18 Jan 2006 18:53:54 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from harpo.itss.auckland.ac.nz (harpo.itss.auckland.ac.nz [130.216.190.13]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0J2rpcA001338 for <[e-mail]>; Wed, 18 Jan 2006 18:53:52 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by harpo.itss.auckland.ac.nz (Postfix) with ESMTP id 1DD14343B6; Thu, 19 Jan 2006 15:53:45 +1300 (NZDT)
Received: from harpo.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpc.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16667-18; Thu, 19 Jan 2006 15:53:45 +1300 (NZDT)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by harpo.itss.auckland.ac.nz (Postfix) with ESMTP id 6D5123406C; Thu, 19 Jan 2006 15:53:44 +1300 (NZDT)
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 005E237755; Thu, 19 Jan 2006 15:53:44 +1300 (NZDT)
Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1EzPvo-0003dr-00; Thu, 19 Jan 2006 15:53:48 +1300
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: AW: The new High Assurance SSL Certificates
In-Reply-To: <B8C9EEB8DC896647952BA6051E00B84A0BC335@ASCALON>
Message-Id: <[e-mail]>
Date: Thu, 19 Jan 2006 15:53:48 +1300
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

[e-mail] writes:

>Ooops... the level of assurance depends on the amount of money I am willing
>to pay for?

Sure.  You know that someone who pays $495 for a cert is more serious about it
than someone who pays $9.95, in the same way that someone who buys a $1995
stereo is more serious than someone who buys a $199 one.

(Well, either that or they don't know that you can get $9.95 certs that behave
 identically to $495 certs.  I got private mail from someone else saying that
 a rule of thumb is that the more you pay, the less you know.  I guess this
 holds for hifi gear as it does for certs).

So we don't really need "high-assurnace policy OIDs" (or whatever), all we
need is an extension indicating how much the owner paid for it, and the
problem is solved.

Peter.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0INKKxc086418; Wed, 18 Jan 2006 15:20:20 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k0INKKUm086417; Wed, 18 Jan 2006 15:20:20 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] 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 k0INKJCp086411 for <[e-mail]>; Wed, 18 Jan 2006 15:20:20 -0800 (PST) (envelope-from [e-mail])
Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id k0INKB7v009965 for <[e-mail]>; Wed, 18 Jan 2006 18:20:16 -0500
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 k0INJJ3u027718 for <[e-mail]>; Wed, 18 Jan 2006 18:19:19 -0500 (EST)
Message-ID: <[e-mail]>
Date: Wed, 18 Jan 2006 18:20:02 -0500
From: "David A. Cooper" <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.11) Gecko/20050729
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: pkix <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-rfc3280bis-02.txt
References: <[e-mail]>
In-Reply-To: <[e-mail]>
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: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

[e-mail] 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-02.txt
> Pages :       140
> Date :         2006-1-13
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-02.txt


I have posted two "diff" files on the NIST Web site: one showing the 
differences between 3280bis-01 and 3280bis-02 and one showing the 
differences between RFC 3280 and 3280bis-02.  They are available at:

    
http://csrc.nist.gov/pki/documents/PKIX/draft3280bis-01todraft3280bis-02_diff.html

and

    
http://csrc.nist.gov/pki/documents/PKIX/rfc3280todraft3280bis-02_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 -01 and draft -02:

1) Text has been added to section 4.2.1.6 (Subject Alternative Name) to 
make it clear that a certificate must either include a non-empty subject 
field or a subjectAltName extension that is marked critical.

2) References to any RFCs that have been updated were changed to refer 
to the current RFC.

3) A new section has been added (section 5.2.7) to specify the use of 
the authorityInfoAccess extension in a CRL (i.e., 3280bis now 
incorporates RFC 4325).

4) The references section has been divided into Normative and 
Informative sections.

5) Appendix D, which described the privateKeyUsagePeriod extension, has 
been removed.

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 k0IKo6au077522; Wed, 18 Jan 2006 12:50:06 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k0IKo6LD077521; Wed, 18 Jan 2006 12:50:06 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from newodin.ietf.org ([132.151.6.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0IKo5Zn077492 for <[e-mail]>; Wed, 18 Jan 2006 12:50:05 -0800 (PST) (envelope-from [e-mail])
Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EzKFm-0007J8-5d; Wed, 18 Jan 2006 15:50:02 -0500
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-gost-cppk-05.txt 
Message-Id: <[e-mail]>
Date: Wed, 18 Jan 2006 15:50:02 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?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		: Using the GOST R 34.10-94, GOST R 34.10-2001 
                          and GOST R 34.11-94 algorithms with the 
                          Internet X.509 Public Key Infrastructure 
                          Certificate and CRL Profile.
	Author(s)	: S. Leontiev, et al.
	Filename	: draft-ietf-pkix-gost-cppk-05.txt
	Pages		: 19
	Date		: 2006-1-18
	
This document supplements RFC 3279. It describes encoding formats,
   identifiers and parameter formats for the algorithms GOST R 34.10-94,
   GOST R 34.10-2001 and GOST R 34.11-94 for use in Internet X.509
   Public Key Infrastructure (PKI).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-gost-cppk-05.txt

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] 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-gost-cppk-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-gost-cppk-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-gost-cppk-05.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-gost-cppk-05.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--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 k0IKo6o3077523; Wed, 18 Jan 2006 12:50:06 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k0IKo6bA077515; Wed, 18 Jan 2006 12:50:06 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from newodin.ietf.org ([132.151.6.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0IKo5po077509 for <[e-mail]>; Wed, 18 Jan 2006 12:50:05 -0800 (PST) (envelope-from [e-mail])
Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EzKFm-0007JP-7c; Wed, 18 Jan 2006 15:50:02 -0500
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-lightweight-ocsp-profile-03.txt 
Message-Id: <[e-mail]>
Date: Wed, 18 Jan 2006 15:50:02 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?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-03.txt
	Pages		: 19
	Date		: 2006-1-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-03.txt

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] 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-03.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:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-lightweight-ocsp-profile-03.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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-lightweight-ocsp-profile-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-lightweight-ocsp-profile-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--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 k0IGMixM032800; Wed, 18 Jan 2006 08:22:44 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k0IGMikK032799; Wed, 18 Jan 2006 08:22:44 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0IGMiPi032784 for <[e-mail]>; Wed, 18 Jan 2006 08:22:44 -0800 (PST) (envelope-from [e-mail])
Received: from mou1wnexcn01.vcorp.ad.vrsn.com (mailer1.verisign.com [65.205.251.34]) by colibri.verisign.com (8.13.1/8.13.4) with ESMTP id k0IGMcL8029044; Wed, 18 Jan 2006 08:22:38 -0800
Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by mou1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 18 Jan 2006 08:22:38 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: The new High Assurance SSL Certificates
Date: Wed, 18 Jan 2006 08:22:37 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: The new High Assurance SSL Certificates
Thread-Index: AcYcJs5SNBmFXtc0TdWjMsVoJ7EKJAAG40FA
From: "Hallam-Baker, Phillip" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>, "Aisenberg, Michael" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 18 Jan 2006 16:22:38.0544 (UTC) FILETIME=[65F6DD00:01C61C4B]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id k0IGMiPi032785
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> [mailto:[e-mail]] On Behalf Of 
> [e-mail]

> Ooops... the level of assurance depends on the amount of 
> money I am willing to pay for?

The level of authentication is certainly constrained by cost. It is hard
to see what authentication can be done at the bargain basement rates
some charge. Checking the credit card clears perhaps?

Providing effective revocation mechanisms such as OCSP also costs money.

The 'seriousness' effect Peter refers to might be significant in some
contexts, certainly if there is an effective revocation mechanism that
closes down a certificate used fraudulently in days it would be harder
for a criminal to make a profit on an expensive cert than a cheapie.
That is not the mechanism intended here.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0IEWd0i018462; Wed, 18 Jan 2006 06:32:39 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k0IEWdcG018461; Wed, 18 Jan 2006 06:32:39 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] 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 k0IEWbb1018453 for <[e-mail]>; Wed, 18 Jan 2006 06:32:38 -0800 (PST) (envelope-from [e-mail])
Received: from dul1wnexcn02.vcorp.ad.vrsn.com (dul1wnexcn02.vcorp.ad.vrsn.com [10.170.12.139]) by peregrine.verisign.com (8.13.1/8.13.4) with ESMTP id k0IEdiDT013419; Wed, 18 Jan 2006 09:39:44 -0500
Received: from dul1wnexmb02.vcorp.ad.vrsn.com ([10.170.12.135]) by dul1wnexcn02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Jan 2006 09:32:32 -0500
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_01C61C3C.03E6A917"
Subject: RE: AW: The new High Assurance SSL Certificates
Date: Wed, 18 Jan 2006 09:32:31 -0500
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: The new High Assurance SSL Certificates
Thread-Index: AcYcJs6R7UlXYUNoRlmBCvBqqKdelAAFTVaI
From: "Aisenberg, Michael" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 18 Jan 2006 14:32:32.0068 (UTC) FILETIME=[0432A040:01C61C3C]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C61C3C.03E6A917
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

No. It depends on the amount of info the subscriber wishes to provide to =
rhe CA.

 -----Original Message-----
From: 	[e-mail] =
[mailto:[e-mail]]
Sent:	Wed Jan 18 07:00:42 2006
To:	[e-mail]; [e-mail]; Aisenberg, Michael; =
[e-mail]
Subject:	AW: The new High Assurance SSL Certificates


Ooops... the level of assurance depends on the amount of money I am =
willing
to pay for?

Best regards

Thomas =20

> -----Urspr=FCngliche Nachricht-----
> Von: [e-mail]=20
> [mailto:[e-mail]] Im Auftrag von=20
> [e-mail]
> Gesendet: Mittwoch, 18. Januar 2006 10:23
> An: [e-mail]; [e-mail]; [e-mail]
> Betreff: Re: The new High Assurance SSL Certificates
>=20
>=20
> Paul Hoffman <[e-mail]> writes:
>=20
> >What is the difference between VeriSign high assurance and=20
> VeriSign low=20
> >assurance certificates? If a developer can't answer the=20
> question, then=20
> >the app doesn't need to differentiate.
>=20
> With the HA certs you have a high level of assurance that the=20
> cert owner paid more for them, thus indicating that they were=20
> more serious about obtaining a cert than a LA cert owner.
>=20
> Peter.
>=20
>=20



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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<TITLE>RE: AW: The new High Assurance SSL Certificates</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>No. It depends on the amount of info the subscriber =
wishes to provide to rhe CA.<BR>
<BR>
&nbsp;-----Original Message-----<BR>
From: &nbsp; [e-mail] [<A =
HREF=3D"mailto:[e-mail]">mailto:thomas.beckmann@ato=
sorigin.com</A>]<BR>
Sent:&nbsp;&nbsp; Wed Jan 18 07:00:42 2006<BR>
To:&nbsp;&nbsp;&nbsp;&nbsp; [e-mail]; =
[e-mail]; Aisenberg, Michael; [e-mail]<BR>
Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; AW: The new High =
Assurance SSL Certificates<BR>
<BR>
<BR>
Ooops... the level of assurance depends on the amount of money I am =
willing<BR>
to pay for?<BR>
<BR>
Best regards<BR>
<BR>
Thomas&nbsp;<BR>
<BR>
&gt; -----Urspr=FCngliche Nachricht-----<BR>
&gt; Von: [e-mail]<BR>
&gt; [<A =
HREF=3D"mailto:[e-mail]">mailto:owner-ietf-pkix@mail.=
imc.org</A>] Im Auftrag von<BR>
&gt; [e-mail]<BR>
&gt; Gesendet: Mittwoch, 18. Januar 2006 10:23<BR>
&gt; An: [e-mail]; [e-mail]; =
[e-mail]<BR>
&gt; Betreff: Re: The new High Assurance SSL Certificates<BR>
&gt;<BR>
&gt;<BR>
&gt; Paul Hoffman &lt;[e-mail]&gt; writes:<BR>
&gt;<BR>
&gt; &gt;What is the difference between VeriSign high assurance and<BR>
&gt; VeriSign low<BR>
&gt; &gt;assurance certificates? If a developer can't answer the<BR>
&gt; question, then<BR>
&gt; &gt;the app doesn't need to differentiate.<BR>
&gt;<BR>
&gt; With the HA certs you have a high level of assurance that the<BR>
&gt; cert owner paid more for them, thus indicating that they were<BR>
&gt; more serious about obtaining a cert than a LA cert owner.<BR>
&gt;<BR>
&gt; Peter.<BR>
&gt;<BR>
&gt;<BR>
<BR>
<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C61C3C.03E6A917--



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 k0IApvaf083887; Wed, 18 Jan 2006 02:51:57 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k0IApvB2083886; Wed, 18 Jan 2006 02:51:57 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mizar.origin-it.net (mail.de.atosorigin.com [194.8.96.234]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0IApuSs083875 for <[e-mail]>; Wed, 18 Jan 2006 02:51:56 -0800 (PST) (envelope-from [e-mail])
Received: from matar.hbg.de.int.atosorigin.com (dehsfw3e.origin-it.net [194.8.96.68]) by mizar.origin-it.net (8.13.4/8.13.4/hmo30jul04) with ESMTP id k0IApijU096560 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Jan 2006 11:51:46 +0100 (CET) (envelope-from [e-mail])
Received: from ascalon.mpn.de.int.atosorigin.com (ascalon.mpn.de.int.atosorigin.com [161.90.190.36]) by matar.hbg.de.int.atosorigin.com (8.13.4/8.13.4/hmo30jul04) with ESMTP id k0IAphYg053450; Wed, 18 Jan 2006 11:51:44 +0100 (CET) (envelope-from [e-mail])
Received: by ASCALON with Internet Mail Service (5.5.2653.19) id <D1HBP72L>; Wed, 18 Jan 2006 11:51:46 +0100
Message-ID: <B8C9EEB8DC896647952BA6051E00B84A0BC335@ASCALON>
From: [e-mail]
To: [e-mail], [e-mail], [e-mail], [e-mail]
Subject: AW: The new High Assurance SSL Certificates
Date: Wed, 18 Jan 2006 11:51:45 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
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 k0IApvSs083881
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Well,... okay, this seems clear... but... does my seriousity depend on the
amount of money?

> -----Ursprüngliche Nachricht-----
> Von: [e-mail] 
> [mailto:[e-mail]] Im Auftrag von Beckmann, Thomas
> Gesendet: Mittwoch, 18. Januar 2006 11:42
> An: [e-mail]; [e-mail]; 
> [e-mail]; [e-mail]
> Betreff: AW: The new High Assurance SSL Certificates
> 
> 
> Ooops... the level of assurance depends on the amount of 
> money I am willing to pay for?
> 
> Best regards
> 
> Thomas  
> 
> > -----Ursprüngliche Nachricht-----
> > Von: [e-mail]
> > [mailto:[e-mail]] Im Auftrag von 
> > [e-mail]
> > Gesendet: Mittwoch, 18. Januar 2006 10:23
> > An: [e-mail]; [e-mail]; 
> [e-mail]
> > Betreff: Re: The new High Assurance SSL Certificates
> > 
> > 
> > Paul Hoffman <[e-mail]> writes:
> > 
> > >What is the difference between VeriSign high assurance and
> > VeriSign low
> > >assurance certificates? If a developer can't answer the
> > question, then
> > >the app doesn't need to differentiate.
> > 
> > With the HA certs you have a high level of assurance that the cert 
> > owner paid more for them, thus indicating that they were 
> more serious 
> > about obtaining a cert than a LA cert owner.
> > 
> > Peter.
> > 
> > 
> 
> 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0IAgbaw082028; Wed, 18 Jan 2006 02:42:37 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k0IAgb84082027; Wed, 18 Jan 2006 02:42:37 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mizar.origin-it.net (mail.de.atosorigin.com [194.8.96.234]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0IAgZZa081999 for <[e-mail]>; Wed, 18 Jan 2006 02:42:36 -0800 (PST) (envelope-from [e-mail])
Received: from matar.hbg.de.int.atosorigin.com (dehsfw3e.origin-it.net [194.8.96.68]) by mizar.origin-it.net (8.13.4/8.13.4/hmo30jul04) with ESMTP id k0IAgM9Z094435 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Jan 2006 11:42:23 +0100 (CET) (envelope-from [e-mail])
Received: from ascalon.mpn.de.int.atosorigin.com (ascalon.mpn.de.int.atosorigin.com [161.90.190.36]) by matar.hbg.de.int.atosorigin.com (8.13.4/8.13.4/hmo30jul04) with ESMTP id k0IAgLlb051516; Wed, 18 Jan 2006 11:42:21 +0100 (CET) (envelope-from [e-mail])
Received: by ASCALON with Internet Mail Service (5.5.2653.19) id <D1HBP6Z7>; Wed, 18 Jan 2006 11:42:23 +0100
Message-ID: <B8C9EEB8DC896647952BA6051E00B84A0BC334@ASCALON>
From: [e-mail]
To: [e-mail], [e-mail], [e-mail], [e-mail]
Subject: AW: The new High Assurance SSL Certificates
Date: Wed, 18 Jan 2006 11:42:22 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
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 k0IAgaZa082022
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Ooops... the level of assurance depends on the amount of money I am willing
to pay for?

Best regards

Thomas  

> -----Ursprüngliche Nachricht-----
> Von: [e-mail] 
> [mailto:[e-mail]] Im Auftrag von 
> [e-mail]
> Gesendet: Mittwoch, 18. Januar 2006 10:23
> An: [e-mail]; [e-mail]; [e-mail]
> Betreff: Re: The new High Assurance SSL Certificates
> 
> 
> Paul Hoffman <[e-mail]> writes:
> 
> >What is the difference between VeriSign high assurance and 
> VeriSign low 
> >assurance certificates? If a developer can't answer the 
> question, then 
> >the app doesn't need to differentiate.
> 
> With the HA certs you have a high level of assurance that the 
> cert owner paid more for them, thus indicating that they were 
> more serious about obtaining a cert than a LA cert owner.
> 
> Peter.
> 
> 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0I9N9Ji059530; Wed, 18 Jan 2006 01:23:09 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k0I9N9ol059529; Wed, 18 Jan 2006 01:23:09 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from chico.itss.auckland.ac.nz (chico.itss.auckland.ac.nz [130.216.190.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0I9N79q059494 for <[e-mail]>; Wed, 18 Jan 2006 01:23:08 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by chico.itss.auckland.ac.nz (Postfix) with ESMTP id 3D2B435275; Wed, 18 Jan 2006 22:23:02 +1300 (NZDT)
Received: from chico.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpb.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27708-27; Wed, 18 Jan 2006 22:23:02 +1300 (NZDT)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by chico.itss.auckland.ac.nz (Postfix) with ESMTP id A899535240; Wed, 18 Jan 2006 22:23:01 +1300 (NZDT)
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 2936B3774C; Wed, 18 Jan 2006 22:23:01 +1300 (NZDT)
Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1Ez9X2-0002Tw-00; Wed, 18 Jan 2006 22:23:08 +1300
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail]
Subject: Re: The new High Assurance SSL Certificates
In-Reply-To: <p06230992bff1aa741743@[10.20.30.249]>
Message-Id: <[e-mail]>
Date: Wed, 18 Jan 2006 22:23:08 +1300
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Paul Hoffman <[e-mail]> writes:

>What is the difference between VeriSign high assurance and VeriSign low
>assurance certificates? If a developer can't answer the question, then the
>app doesn't need to differentiate.

With the HA certs you have a high level of assurance that the cert owner paid
more for them, thus indicating that they were more serious about obtaining a
cert than a LA cert owner.

Peter.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0HLi8BP050570; Tue, 17 Jan 2006 13:44:08 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k0HLi8XA050569; Tue, 17 Jan 2006 13:44:08 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0HLi7QI050488 for <[e-mail]>; Tue, 17 Jan 2006 13:44:07 -0800 (PST) (envelope-from [e-mail])
Received: from gto.missi.ncsc.mil (goodman.missi.ncsc.mil [144.51.60.3]) by stingray.missi.ncsc.mil with ESMTP id k0HLiKZU018164 for <[e-mail]>; Tue, 17 Jan 2006 16:44:20 -0500 (EST)
Received: from EXCH.missi.ncsc.mil ([144.51.60.19]) by gto.missi.ncsc.mil with Microsoft SMTPSVC(5.0.2195.6713); Tue, 17 Jan 2006 16:43:58 -0500
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Subject: RE: The new High Assurance SSL Certificates
Date: Tue, 17 Jan 2006 16:43:58 -0500
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: The new High Assurance SSL Certificates
Thread-Index: AcYZBUempluX/YnYSQKYAwPHt5QTaQCcjk7gAAsivzA=
From: "Kemp David P." <[e-mail]>
To: <[e-mail]>
X-OriginalArrivalTime: 17 Jan 2006 21:43:58.0937 (UTC) FILETIME=[1F8F9C90:01C61BAF]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id k0HLi7QI050553
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Displaying the CA logo is a helpful step, but is not sufficient.  CA
assurance levels need to be commoditized (to at least a binary level -
"UL Listed" or not), if only to solve the revocation problem.

There must be a way for a browser and a user to distinguish between
the large number of CAs in a trust list (for which the only
qualification is "we adhere to whatever claims, if any, we put
in our CPS"), and the smaller number of CAs that adhere to
industry consensus practices for HA organizational authentication.
How would that consensus be bootstrapped into existence? I don't
know, but I think a consortium like IMC or OATH would have a
better chance of gaining mindshare as the "Good Housekeeping"
of HA authentication than would any single CA operating alone.
There would have to be some general principles in the HA charter,
such as no CA could buy their way in by becoming a Platinum
level sponsor, and no CA could be excluded for reasons unrelated
to the assurance of their issuing practices, but beyond that
the listing criteria could be fairly informal ("we know HA
when we see it") and accountability-based ("two strikes and
you're out"), at least initially.

Technically, the HA could issue a list of approved root certificate
fingerprints signed along with the HA logo and the distribution
URL for the next list update.  Browsers could be modified to install
the HA authority signature key, download and validate the HA list,
and display the HA seal along with the SSL server logo whenever
the SSL cert can be validated back to a root on the HA fingerprint
list.  Would users benefit from or be confused by seeing three
logos (HA Seal, CA brand and SSL server)?  Who knows.

Is it better to invent a brand new structure (signed good-guy
list with logo) than to reuse existing structures (augment
the trust list with an HA root, HA issues CA certs and an ARL
for the previous roots)?  Probably, because otherwise there is
nothing to prevent a non-HA-listed CA from issuing a self-signed
cert with a logo identical or suspiciously close to the HA seal,
just as there is nothing to prevent a low assurance root from
claiming a high assurance CP OID.  Presumably users would have
an easier time managing 1 (or 2 or 3) HA approvers separately
from 150 root CAs.


-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Hallam-Baker, Phillip
Sent: Tuesday, January 17, 2006 10:41 AM
To: Anders Rundgren; [e-mail]
Subject: RE: The new High Assurance SSL Certificates


> 2. I may be wrong here, but is there actually anything that 
> prevents a low- assurance certificate issuer to include high 
> assurance policy identifiers?

I think that you identify the real problem here. The system today lacks
mechanisms to hold CAs accountable for untrustworthy certificate
practices.

The problem is made worse by the SSL user interface which gives only 1
bit of information and a pretty irrelevant one. All the padlock icon
actually means is 'this communication is encrypted'. Users are misled to
believe that it means 'this transaction is secure and I can trust that
the other party can be held accountable in case of default'.

The first problem can be solved using a self signed certificate. The
problem with the current situation is that all a CA needs to do to get
in the root store is to describe their issue practices and be audited.
It is entirely possible for a CA to essentially state that they do not
authenticate at all and still meet this criteria.


The high assurance CA project is one proposal to try to address the
problem. The question that has to be asked here is whether it is
sufficient to try to define a new bar. 

One area where it is certain that a higher bar is required is if
logotype certificates (Secure Internet Lettehead) are to be issued.
Logotypes are potentially a way to avoid the problem of domain name
attacks such cousin domain. They provide a means of providing the user
with an unambiguous proof of the subject identity but only if backed by
stringent authentication techniques that effectively prevent fraudulent
registrations.


The real key to solving this problem is to change the nature of the
business so that there is a positive incentive for all CAs to apply
stringent assurance practices. Holding the CA accountable by displaying
the ca logo as well as the subject logo creates a situation which is
effectively self-policing. The ca is required to put their own brand on
the line each time they issue a cert. Any CA that issues a bogus
certificate to the bank of england is going to be on the front page of
the new york times. 








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 k0HFfL2Z007457; Tue, 17 Jan 2006 07:41:21 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k0HFfL8P007456; Tue, 17 Jan 2006 07:41:21 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from robin.verisign.com (robin.verisign.com [65.205.251.75]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0HFfKjY007444 for <[e-mail]>; Tue, 17 Jan 2006 07:41:20 -0800 (PST) (envelope-from [e-mail])
Received: from MOU1WNEXCN02.vcorp.ad.vrsn.com (mailer2.verisign.com [65.205.251.35]) by robin.verisign.com (8.13.1/8.13.4) with ESMTP id k0HFfKJN008565; Tue, 17 Jan 2006 07:41:20 -0800
Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by MOU1WNEXCN02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 17 Jan 2006 07:41:20 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: The new High Assurance SSL Certificates
Date: Tue, 17 Jan 2006 07:41:19 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: The new High Assurance SSL Certificates
Thread-Index: AcYZBUempluX/YnYSQKYAwPHt5QTaQCcjk7g
From: "Hallam-Baker, Phillip" <[e-mail]>
To: "Anders Rundgren" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 17 Jan 2006 15:41:20.0187 (UTC) FILETIME=[7655D8B0:01C61B7C]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id k0HFfKjY007449
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 2. I may be wrong here, but is there actually anything that 
> prevents a low- assurance certificate issuer to include high 
> assurance policy identifiers?

I think that you identify the real problem here. The system today lacks
mechanisms to hold CAs accountable for untrustworthy certificate
practices.

The problem is made worse by the SSL user interface which gives only 1
bit of information and a pretty irrelevant one. All the padlock icon
actually means is 'this communication is encrypted'. Users are misled to
believe that it means 'this transaction is secure and I can trust that
the other party can be held accountable in case of default'.

The first problem can be solved using a self signed certificate. The
problem with the current situation is that all a CA needs to do to get
in the root store is to describe their issue practices and be audited.
It is entirely possible for a CA to essentially state that they do not
authenticate at all and still meet this criteria.


The high assurance CA project is one proposal to try to address the
problem. The question that has to be asked here is whether it is
sufficient to try to define a new bar. 

One area where it is certain that a higher bar is required is if
logotype certificates (Secure Internet Lettehead) are to be issued.
Logotypes are potentially a way to avoid the problem of domain name
attacks such cousin domain. They provide a means of providing the user
with an unambiguous proof of the subject identity but only if backed by
stringent authentication techniques that effectively prevent fraudulent
registrations.


The real key to solving this problem is to change the nature of the
business so that there is a positive incentive for all CAs to apply
stringent assurance practices. Holding the CA accountable by displaying
the ca logo as well as the subject logo creates a situation which is
effectively self-policing. The ca is required to put their own brand on
the line each time they issue a cert. Any CA that issues a bogus
certificate to the bank of england is going to be on the front page of
the new york times. 







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 k0HDFA9q047818; Tue, 17 Jan 2006 05:15:10 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k0HDFARl047817; Tue, 17 Jan 2006 05:15:10 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from trantor.eads-telecom.com (eads-telecom.com.siris.net [62.8.24.122] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0HDF7LT047715 for <[e-mail]>; Tue, 17 Jan 2006 05:15:09 -0800 (PST) (envelope-from [e-mail])
Received: from trantor.eads-telecom.com (root@localhost) by trantor.eads-telecom.com (8.12.5-20030924/8.12.5) with ESMTP id k0HDRkXg027675; Tue, 17 Jan 2006 14:27:47 +0100 (CET)
Received: from unknown(172.29.64.4) by trantor.eads-telecom.com via smap (5.0); id xma027669; Tue, 17 Jan 2006 14:27:22 +0100
Received: from edsnmsxbda01.edsn.com ([131.129.5.127]) by hermes.edsn.com (8.12.10/8.12.10) with ESMTP id k0HDI65r030006; Tue, 17 Jan 2006 14:18:06 +0100
Received: by edsnmsxbda01.edsn.com with Internet Mail Service (5.5.2653.19) id <CTFXX2MP>; Tue, 17 Jan 2006 14:13:44 +0100
Message-ID: <[e-mail]>
From: "Kuhn, Sebastien" <[e-mail]>
To: Tom Gindin <[e-mail]>, Richard Levitte - VMS Whacker <[e-mail]>, [e-mail]
Cc: [e-mail]
Subject: RE: pathLenConstraint
Date: Tue, 17 Jan 2006 14:13:43 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
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 k0HDFALT047810
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Thank you very much for your responses.
Best Regards,

Sebastien Kuhn.

-----Message d'origine-----
De : Tom Gindin [mailto:[e-mail]]
Envoyé : mardi 17 janvier 2006 04:29
À : Richard Levitte - VMS Whacker
Cc : [e-mail]; Kuhn, Sebastien
Objet : Re: pathLenConstraint


        If the verifier follows RFC 3280 6.1.4 steps L and M, 
pathLengthConstraint seems to have real effect in an intermediate 
certificate either only if it is less than the previous value of the 
length constraint minus one.  Step M suggests that pathLengthConstraint 
should be ignored if this is not the case.  The algorithm assumes that the 
length constraint is initialized to a non-negative integer, although it 
can be a large one.
        Sebastien's suggested setup is fine, of course.

                Tom Gindin






Richard Levitte - VMS Whacker <[e-mail]>
Sent by: [e-mail]
01/16/2006 08:36 AM
 
        To:     [e-mail]
        cc:     [e-mail]
        Subject:        Re: pathLenConstraint



In message 
<[e-mail]> on Fri, 
13 Jan 2006 16:24:49 +0100, "Kuhn, Sebastien" <[e-mail]> 
said:

sebastien.kuhn> Could you confirm that the attribute
sebastien.kuhn> "pathLenConstraint" (included in the extension
sebastien.kuhn> "BasicConstraints") can have no limit in a Root CA
sebastien.kuhn> certificate and a finite value in a CA certificate
sebastien.kuhn> subordinate to the Root CA ?

Yes, as far as I understand.  I can't really imagine why it shouldn't

Cheers,
Richard

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.

-- 
Richard Levitte                         [e-mail]
                                        http://richard.levitte.org/

"When I became a man I put away childish things, including
 the fear of childishness and the desire to be very grown up."
                 -- C.S. Lewis






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 k0HCxbG6039530; Tue, 17 Jan 2006 04:59:37 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k0HCxbNj039529; Tue, 17 Jan 2006 04:59:37 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] 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 k0HCxZwY039469 for <[e-mail]>; Tue, 17 Jan 2006 04:59:35 -0800 (PST) (envelope-from [e-mail])
Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by peregrine.verisign.com (8.13.1/8.13.4) with ESMTP id k0HD6Sg9030719; Tue, 17 Jan 2006 08:06:28 -0500
Received: from dul1wnexmb02.vcorp.ad.vrsn.com ([10.170.12.135]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jan 2006 07:59:28 -0500
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_01C61B65.D9677BE3"
Subject: Re: The new High Assurance SSL Certificates
Date: Tue, 17 Jan 2006 07:59:27 -0500
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: The new High Assurance SSL Certificates
Thread-Index: AcYa3Cq+BrQqjunbTbGN9d4AXJaKsAAia7GG
From: "Aisenberg, Michael" <[e-mail]>
To: "Jeffrey I. Schiller" <[e-mail]>, "Joel S. Kazin" <[e-mail]>
Cc: "Anders Rundgren" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 17 Jan 2006 12:59:28.0460 (UTC) FILETIME=[D9B1E8C0:01C61B65]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C61B65.D9677BE3
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Jeff
I believe you have described one of the core issues motivating browser =
publishers--combatting spam and other consumer abuses not presently =
remedied by some flavors of organizational SSL certs that require only =
minimum vetting of identity/legitimacy attributes of corporate/business =
subscribers.  The point is to deny the "AOL1" cert to anyone other than =
AOL to the extent this can be contributed to by a stronger Organization =
SSL cert.  It won't eliminate fraudsters getting organization certs, but =
it cuts it down.  Those of us in the CA community who already require =
more than an organization name and email address have already set a =
higher bar in practice.  The browsers are now proposing to serve =
consumers by differentiating.
 =20

 -----Original Message-----
From: 	Jeffrey I. Schiller [mailto:[e-mail]]
Sent:	Mon Jan 16 15:33:53 2006
To:	Joel S. Kazin
Cc:	Anders Rundgren; [e-mail]
Subject:	Re: The new High Assurance SSL Certificates


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Joel S. Kazin wrote:
> As discussed at the October 2005 ABA ISC meeting, a HCA does not =
address
> the handling of a consumer's personal information.

Well, I wasn't at the meeting, so I cannot comment about what went on. I
can understand why it won't address how an organization handles personal
information. But it *should* address how a consumer can *know* they are
giving their information to whom they believe they giving their
information. Thus my example about differentiating AOL.COM from AO1.COM.

Bottom line: If this doesn't improve consumer confidence, then it is a
worthless exercise. My take on it is that private key protection is not
the problem we have. Phishing is what it is about and phishing doesn't
require stealing the private key of the legitimate site. It requires
fooling the consumer into thinking they are at the legitimate site when
in fact they are not. The goal should be to address (or solve) this
problem. I original message was to point out that this is more about
policy of certificate issuance then private key protection and that the
key piece of technology we need is really working revocation, something
we do not have today (at least in deployed technologies).

			-Jeff

P.S. What was the junk on the end of your message, looks like the dump
of some random Window's settings file!

- --
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Jeffrey I. Schiller
MIT Network Manager
Information Services and Technology
Massachusetts Institute of Technology
77 Massachusetts Avenue  Room W92-190
Cambridge, MA 02139-4307
617.253.0161 - Voice
[e-mail]
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDy/NZ8CBzV/QUlSsRAsP8AJ4gAZkgdiCLgDBFR7gCbjk93gILOgCgsc6H
rkDibHfiPeMs1wBLfp+vEcY=3D
=3DxZxK
-----END PGP SIGNATURE-----



------_=_NextPart_001_01C61B65.D9677BE3
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: The new High Assurance SSL Certificates</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>Jeff<BR>
I believe you have described one of the core issues motivating browser =
publishers--combatting spam and other consumer abuses not presently =
remedied by some flavors of organizational SSL certs that require only =
minimum vetting of identity/legitimacy attributes of corporate/business =
subscribers.&nbsp; The point is to deny the &quot;AOL1&quot; cert to =
anyone other than AOL to the extent this can be contributed to by a =
stronger Organization SSL cert.&nbsp; It won't eliminate fraudsters =
getting organization certs, but it cuts it down.&nbsp; Those of us in =
the CA community who already require more than an organization name and =
email address have already set a higher bar in practice.&nbsp; The =
browsers are now proposing to serve consumers by differentiating.<BR>
&nbsp;<BR>
<BR>
&nbsp;-----Original Message-----<BR>
From: &nbsp; Jeffrey I. Schiller [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]<BR>
Sent:&nbsp;&nbsp; Mon Jan 16 15:33:53 2006<BR>
To:&nbsp;&nbsp;&nbsp;&nbsp; Joel S. Kazin<BR>
Cc:&nbsp;&nbsp;&nbsp;&nbsp; Anders Rundgren; [e-mail]<BR>
Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Re: The new High =
Assurance SSL Certificates<BR>
<BR>
<BR>
-----BEGIN PGP SIGNED MESSAGE-----<BR>
Hash: SHA1<BR>
<BR>
Joel S. Kazin wrote:<BR>
&gt; As discussed at the October 2005 ABA ISC meeting, a HCA does not =
address<BR>
&gt; the handling of a consumer's personal information.<BR>
<BR>
Well, I wasn't at the meeting, so I cannot comment about what went on. =
I<BR>
can understand why it won't address how an organization handles =
personal<BR>
information. But it *should* address how a consumer can *know* they =
are<BR>
giving their information to whom they believe they giving their<BR>
information. Thus my example about differentiating AOL.COM from =
AO1.COM.<BR>
<BR>
Bottom line: If this doesn't improve consumer confidence, then it is =
a<BR>
worthless exercise. My take on it is that private key protection is =
not<BR>
the problem we have. Phishing is what it is about and phishing =
doesn't<BR>
require stealing the private key of the legitimate site. It requires<BR>
fooling the consumer into thinking they are at the legitimate site =
when<BR>
in fact they are not. The goal should be to address (or solve) this<BR>
problem. I original message was to point out that this is more about<BR>
policy of certificate issuance then private key protection and that =
the<BR>
key piece of technology we need is really working revocation, =
something<BR>
we do not have today (at least in deployed technologies).<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -Jeff<BR>
<BR>
P.S. What was the junk on the end of your message, looks like the =
dump<BR>
of some random Window's settings file!<BR>
<BR>
- --<BR>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D<BR>
Jeffrey I. Schiller<BR>
MIT Network Manager<BR>
Information Services and Technology<BR>
Massachusetts Institute of Technology<BR>
77 Massachusetts Avenue&nbsp; Room W92-190<BR>
Cambridge, MA 02139-4307<BR>
617.253.0161 - Voice<BR>
[e-mail]<BR>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D<BR>
-----BEGIN PGP SIGNATURE-----<BR>
Version: GnuPG v1.4.1 (GNU/Linux)<BR>
Comment: Using GnuPG with Thunderbird - <A =
HREF=3D"http://enigmail.mozdev.org">http://enigmail.mozdev.org</A><BR>
<BR>
iD8DBQFDy/NZ8CBzV/QUlSsRAsP8AJ4gAZkgdiCLgDBFR7gCbjk93gILOgCgsc6H<BR>
rkDibHfiPeMs1wBLfp+vEcY=3D<BR>
=3DxZxK<BR>
-----END PGP SIGNATURE-----<BR>
<BR>
<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C61B65.D9677BE3--



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 k0H3Tns8053465; Mon, 16 Jan 2006 19:29:49 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k0H3Tn1l053464; Mon, 16 Jan 2006 19:29:49 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.142]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0H3Tk0T053424 for <[e-mail]>; Mon, 16 Jan 2006 19:29:47 -0800 (PST) (envelope-from [e-mail])
Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e2.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id k0H3TOKL020406 for <[e-mail]>; Mon, 16 Jan 2006 22:29:24 -0500
Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id k0H3TPMb123876 for <[e-mail]>; Mon, 16 Jan 2006 22:29:25 -0500
Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.13.3) with ESMTP id k0H3TPrl002558 for <[e-mail]>; Mon, 16 Jan 2006 22:29:25 -0500
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.56.228.115]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id k0H3TOD1002555; Mon, 16 Jan 2006 22:29:24 -0500
In-Reply-To: <[e-mail]>
To: Richard Levitte - VMS Whacker <[e-mail]>
Cc: [e-mail], [e-mail]
MIME-Version: 1.0
Subject: Re: pathLenConstraint
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
From: Tom Gindin <[e-mail]>
Message-ID: <[e-mail]>
Date: Mon, 16 Jan 2006 22:29:19 -0500
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 6.5.4FP2 HF4|December 20, 2005) at 01/16/2006 22:29:24, Serialize complete at 01/16/2006 22:29:24
Content-Type: text/plain; charset="US-ASCII"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

        If the verifier follows RFC 3280 6.1.4 steps L and M, 
pathLengthConstraint seems to have real effect in an intermediate 
certificate either only if it is less than the previous value of the 
length constraint minus one.  Step M suggests that pathLengthConstraint 
should be ignored if this is not the case.  The algorithm assumes that the 
length constraint is initialized to a non-negative integer, although it 
can be a large one.
        Sebastien's suggested setup is fine, of course.

                Tom Gindin






Richard Levitte - VMS Whacker <[e-mail]>
Sent by: [e-mail]
01/16/2006 08:36 AM
 
        To:     [e-mail]
        cc:     [e-mail]
        Subject:        Re: pathLenConstraint



In message 
<[e-mail]> on Fri, 
13 Jan 2006 16:24:49 +0100, "Kuhn, Sebastien" <[e-mail]> 
said:

sebastien.kuhn> Could you confirm that the attribute
sebastien.kuhn> "pathLenConstraint" (included in the extension
sebastien.kuhn> "BasicConstraints") can have no limit in a Root CA
sebastien.kuhn> certificate and a finite value in a CA certificate
sebastien.kuhn> subordinate to the Root CA ?

Yes, as far as I understand.  I can't really imagine why it shouldn't

Cheers,
Richard

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.

-- 
Richard Levitte                         [e-mail]
                                        http://richard.levitte.org/

"When I became a man I put away childish things, including
 the fear of childishness and the desire to be very grown up."
                 -- C.S. Lewis





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 k0H1ntS4017031; Mon, 16 Jan 2006 17:49:55 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k0H1ntdl017029; Mon, 16 Jan 2006 17:49:55 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from robin.verisign.com (robin.verisign.com [65.205.251.75]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0H1nt5p017006 for <[e-mail]>; Mon, 16 Jan 2006 17:49:55 -0800 (PST) (envelope-from [e-mail])
Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by robin.verisign.com (8.13.1/8.13.4) with ESMTP id k0H1nsro023402; Mon, 16 Jan 2006 17:49:54 -0800
Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Jan 2006 17:49:54 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: The new High Assurance SSL Certificates
Date: Mon, 16 Jan 2006 17:49:53 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: The new High Assurance SSL Certificates
Thread-Index: AcYa4DYzOSXUSnpfSym+NEe6Z1IB1wAJazuw
From: "Hallam-Baker, Phillip" <[e-mail]>
To: "Paul Hoffman" <[e-mail]>, "Aisenberg, Michael" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 17 Jan 2006 01:49:54.0502 (UTC) FILETIME=[50266660:01C61B08]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id k0H1nt5p017014
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

 

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Paul Hoffman
> Sent: Monday, January 16, 2006 2:58 PM
> To: Aisenberg, Michael; [e-mail]
> Subject: Re: The new High Assurance SSL Certificates
> 
> 
> At 11:01 AM -0500 1/16/06, Aisenberg, Michael wrote:
> >Another "process" ("labour") is the intra industry saga of reaching 
> >consensus on How and Where to do this (standards body, industry
> >assn.) and then doing it...Promptly.
> 
> I will repeat my earlier question, maybe a bit more pointed 
> at the VeriSign folks on the list:
> 
> What is the difference between VeriSign high assurance and 
> VeriSign low assurance certificates? If a developer can't 
> answer the question, then the app doesn't need to differentiate.

There are no VeriSign 'low assurance' certificates.

The basic principle is that all the information in the cert is assured,
the question is what information is there. In some Thawte branded
certificates there is only a domain name and only the domain name has
been authenticated. All the VeriSign branded SSL certificates (including
those off the old RSA root) are class 3 which requires authentication of
the subject identifier as well as the domain name.

The full details of the VeriSign assurance levels are given in the CPS.

If you want to connect up to an ISP to read you email or post to the
acne sufferers blog then all you need to be assured is the domain name.

If on the other hand what you want to do is to establish a commercial
relationship with a previously unknown entity then you need to be
assured that the party you are dealling with can be held legally and if
necessary criminally liable if the need arises.


> That is, if the developer cannot describe to the user what 
> the difference between two types of certificates is, the 
> application should not differentiate them to the user. Making 
> one "green" and one "not green" is a particularly bad method 
> without an explanation.

I think that the idea of comoditising trust levels is somewhat broken.
What the process is really about here is accountability. The purpose of
a ca process is to hold someone accountable. If the certificate holder
cannot be held accountable then lets hold the CA accountable in their
place.

The best way to do that is to show the CA who issued the certificate.
The real failure in the Shmoo group homologue cert was that the CA
should never have issued the certificate, I am somewhat disappointed
that the Shmoo paper never mentioned the CA concerned (not VeriSign).


Show the CA brand in place of the silly padlock icon and the problem of
inadequate assurance processes goes away. There will still be CAs who
attempt to compete to offer the minimum level of trust, most CAs however
will be looking to establish themselves as premium trust providers and
being the most careful and exclusive accreditors.



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 k0H0smN6081041; Mon, 16 Jan 2006 16:54:48 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k0H0smwi081040; Mon, 16 Jan 2006 16:54:48 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from robin.verisign.com (robin.verisign.com [65.205.251.75]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0H0sl0x081034 for <[e-mail]>; Mon, 16 Jan 2006 16:54:47 -0800 (PST) (envelope-from [e-mail])
Received: from mou1wnexcn01.vcorp.ad.vrsn.com (mailer1.verisign.com [65.205.251.34]) by robin.verisign.com (8.13.1/8.13.4) with ESMTP id k0H0sggQ020375; Mon, 16 Jan 2006 16:54:44 -0800
Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by mou1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 16 Jan 2006 16:54:42 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: The new High Assurance SSL Certificates
Date: Mon, 16 Jan 2006 16:54:41 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: The new High Assurance SSL Certificates
Thread-Index: AcYa3Cori9PYqGoOS7mNCDTJbKL/oQAFVVFA
From: "Hallam-Baker, Phillip" <[e-mail]>
To: "Jeffrey I. Schiller" <[e-mail]>, "Joel S. Kazin" <[e-mail]>
Cc: "Anders Rundgren" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 17 Jan 2006 00:54:42.0344 (UTC) FILETIME=[99F33280:01C61B00]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id k0H0sl0x081035
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> [mailto:[e-mail]] On Behalf Of Jeffrey I. Schiller

> Thus my example about differentiating AOL.COM 
> from AO1.COM.
> 
> Bottom line: If this doesn't improve consumer confidence, 
> then it is a worthless exercise.

Lets add 'justifiably' in there.

I think that we need to forget the AOL.com AO1.com issue which is really
a geek-centric subset of the cases that affect consumers, it is merely
one example of the ways in which the reasonable expectations of the
consumer is betrayed. 

Jeff is giving one example of a more general problem: it is very easy to
make an authentication process that is 'failure proof' if we allow a
useless definition of failure. The only measures that really matter here
are consumer frauds and consumer confidence.

It is also a problem if someone goes to a site that has AOL graphics
plastered all over it and there is no way to quickly and reliably
determine whether or not it is the authorized AOL.

> My take on it is that 
> private key protection is not the problem we have. Phishing 
> is what it is about and phishing doesn't require stealing the 
> private key of the legitimate site.

The problem here is that private key hardware is something that is
objectively and empirically measurable. Quality of authentication
process is not.

What we need to do here is to look at the security of the system as a
whole. It is not just the authentication process that matters, it is the
control and feedback processes.

For example there is no way that any CA can test for honesty of the
certificate holder. The point of the original class 3 certification
process was not to assure the consumer that they were really dealling
with company X, it was to assure the consumer that if X defaulted for
any reason that there was a high degree of probability that the
perpetrators could be identified and face the relevant consequences.

Trusted Third Party services provide accountability based security, it
is a mistake to analyze them as if they were a permission based scheme. 

Permission based security, access control lists, kerberos etc, works
well in closed, tightly controlled environments where the set of rules
is known in advanceand all the security system is required to do is to
enforce the rules. It is not a feasible strategy in a system with a
billion users.

To take the Ao1.com example, the verisign class3 process ensures that
there is an authenticated contact address on file. If ao1.com attempts
to pass itself off as aol they can expect an immediate lawsuit. All
corporations that have strong trusted consumer brands are aware of the
need to protect them. The point about accountability is that it is not
just limited to anticipated abuses, it works also for fredonline.com if
they attempt to pass themselves off as aol by stealling their trade
dress.

Life has inherrent risk. There can never be absolute guarantees. There
is always a finite chance of being hit by a meteor. There is always a
risk that an assurance process will fail - especially if the underlying
government or commercial authentication processes that are relied on are
also fallible. 

There are three separate concerns here, 1) what is the probability of an
authentication failure, 2) what measures are in place to detect and
prevent repeat 3) to what extent can the consequences be mitigated?

Ultimately criminals respond to economics. There is no point in
obtaining a $x certificate fraudulently unless they can expect to
realize a gain of $x+$y where $y is large enough to justify the effort
involved and the risk of being caught.

Realtime revocation mechanisms such as OCSP are likely to pay much
better dividends in a high assurance certification system than some of
the processes being proposed. No authentication process however good
would have denied a certificate to Enron.









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 k0GNgEkC047292; Mon, 16 Jan 2006 15:42:14 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k0GNgEAR047291; Mon, 16 Jan 2006 15:42:14 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] 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 k0GNgBjl047275 for <[e-mail]>; Mon, 16 Jan 2006 15:42:11 -0800 (PST) (envelope-from [e-mail])
Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.196]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Jan 2006 23:42:10 +0000
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: pathLenConstraint
Date: Mon, 16 Jan 2006 23:42:10 -0000
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: pathLenConstraint
thread-index: AcYaqTqhWHOVjaLGRzic7ZyNKBjt8wAS5gsg
From: "Stefan Santesson" <[e-mail]>
To: "Richard Levitte - VMS Whacker" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 16 Jan 2006 23:42:10.0417 (UTC) FILETIME=[77FFD610:01C61AF6]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id k0GNgCjl047283
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Sebastien,

Technically, all extensions in a Root certificate can be ignored by the
relying party since they are not used as input to the path validation
process.

Section 6.1.1. of RFC 3280 states the input from the selected trust
anchor:

      (d)  trust anchor information, describing a CA that serves as a
      trust anchor for the certification path.  The trust anchor
      information includes:

         (1)  the trusted issuer name,
         (2)  the trusted public key algorithm,
         (3)  the trusted public key, and
         (4)  optionally, the trusted public key parameters associated
         with the public key.


It can be debatable however if this is good or bad. The practice of our
(Microsoft) implementation is to by default process the extensions of
the root certificate (they probably was put there for some reason so we
honor them). In either case, your setup would work just fine.


Stefan Santesson
Program Manager, Standards Liaison
Windows Security


-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Richard Levitte - VMS Whacker
Sent: den 16 januari 2006 05:37
To: [e-mail]
Cc: [e-mail]
Subject: Re: pathLenConstraint


In message
<[e-mail]> on Fri,
13 Jan 2006 16:24:49 +0100, "Kuhn, Sebastien" <[e-mail]>
said:

sebastien.kuhn> Could you confirm that the attribute
sebastien.kuhn> "pathLenConstraint" (included in the extension
sebastien.kuhn> "BasicConstraints") can have no limit in a Root CA
sebastien.kuhn> certificate and a finite value in a CA certificate
sebastien.kuhn> subordinate to the Root CA ?

Yes, as far as I understand.  I can't really imagine why it shouldn't

Cheers,
Richard

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.

-- 
Richard Levitte                         [e-mail]
                                        http://richard.levitte.org/

"When I became a man I put away childish things, including
 the fear of childishness and the desire to be very grown up."
						-- C.S. Lewis




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 k0GJvmcA058476; Mon, 16 Jan 2006 11:57:48 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k0GJvmHC058475; Mon, 16 Jan 2006 11:57:48 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from [10.20.30.249] (dsl2-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0GJvjG3058430; Mon, 16 Jan 2006 11:57:46 -0800 (PST) (envelope-from [e-mail])
Mime-Version: 1.0
Message-Id: <p06230992bff1aa741743@[10.20.30.249]>
In-Reply-To:  <[e-mail]>
References:  <[e-mail]>
Date: Mon, 16 Jan 2006 11:57:42 -0800
To: "Aisenberg, Michael" <[e-mail]>, <[e-mail]>
From: Paul Hoffman <[e-mail]>
Subject: Re: The new High Assurance SSL Certificates
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 11:01 AM -0500 1/16/06, Aisenberg, Michael wrote:
>Another "process" ("labour") is the intra industry saga of reaching 
>consensus on How and Where to do this (standards body, industry 
>assn.) and then doing it...Promptly.

I will repeat my earlier question, maybe a bit more pointed at the 
VeriSign folks on the list:

What is the difference between VeriSign high assurance and VeriSign 
low assurance certificates? If a developer can't answer the question, 
then the app doesn't need to differentiate.

That is, if the developer cannot describe to the user what the 
difference between two types of certificates is, the application 
should not differentiate them to the user. Making one "green" and one 
"not green" is a particularly bad method without an explanation.

--Paul Hoffman, Director
--VPN Consortium



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0GJQhcv044509; Mon, 16 Jan 2006 11:26:43 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k0GJQhWd044508; Mon, 16 Jan 2006 11:26:43 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0GJQf0j044500 for <[e-mail]>; Mon, 16 Jan 2006 11:26:42 -0800 (PST) (envelope-from [e-mail])
Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.12.4/8.9.2) with ESMTP id k0GJQaYx004881; Mon, 16 Jan 2006 14:26:37 -0500 (EST)
Received: from [192.168.94.131] (JISVPN.MIT.EDU [18.100.101.102]) (authenticated bits=0) (User authenticated as [e-mail]) by outgoing.mit.edu (8.13.1/8.12.4) with ESMTP id k0GJQQhI007444 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 16 Jan 2006 14:26:27 -0500 (EST)
Message-ID: <[e-mail]>
Date: Mon, 16 Jan 2006 14:26:20 -0500
From: "Jeffrey I. Schiller" <[e-mail]>
Organization: Massachusetts Institute of Technology
User-Agent: Debian Thunderbird 1.0.2 (X11/20050331)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Joel S. Kazin" <[e-mail]>
CC: Anders Rundgren <[e-mail]>, [e-mail]
Subject: Re: The new High Assurance SSL Certificates
References: <018701c618fc$0422e9e0$8217a8c0@arport2v>	<018701c618fc$0422e9e0$8217a8c0@arport2v> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.92.0.0
OpenPGP: id=F414952B
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Score: 1.217
X-Spam-Level: * (1.217)
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Joel S. Kazin wrote:
> As discussed at the October 2005 ABA ISC meeting, a HCA does not address
> the handling of a consumer's personal information.

Well, I wasn't at the meeting, so I cannot comment about what went on. I
can understand why it won't address how an organization handles personal
information. But it *should* address how a consumer can *know* they are
giving their information to whom they believe they giving their
information. Thus my example about differentiating AOL.COM from AO1.COM.

Bottom line: If this doesn't improve consumer confidence, then it is a
worthless exercise. My take on it is that private key protection is not
the problem we have. Phishing is what it is about and phishing doesn't
require stealing the private key of the legitimate site. It requires
fooling the consumer into thinking they are at the legitimate site when
in fact they are not. The goal should be to address (or solve) this
problem. I original message was to point out that this is more about
policy of certificate issuance then private key protection and that the
key piece of technology we need is really working revocation, something
we do not have today (at least in deployed technologies).

			-Jeff

P.S. What was the junk on the end of your message, looks like the dump
of some random Window's settings file!

- --
=============================================================================
Jeffrey I. Schiller
MIT Network Manager
Information Services and Technology
Massachusetts Institute of Technology
77 Massachusetts Avenue  Room W92-190
Cambridge, MA 02139-4307
617.253.0161 - Voice
[e-mail]
============================================================================
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDy/NZ8CBzV/QUlSsRAsP8AJ4gAZkgdiCLgDBFR7gCbjk93gILOgCgsc6H
rkDibHfiPeMs1wBLfp+vEcY=
=xZxK
-----END PGP SIGNATURE-----



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 k0GG1sB9093229; Mon, 16 Jan 2006 08:01:54 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k0GG1shO093228; Mon, 16 Jan 2006 08:01:54 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] 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 k0GG1qnK093184 for <[e-mail]>; Mon, 16 Jan 2006 08:01:53 -0800 (PST) (envelope-from [e-mail])
Received: from dul1wnexcn02.vcorp.ad.vrsn.com (dul1wnexcn02.vcorp.ad.vrsn.com [10.170.12.139]) by osprey.verisign.com (8.13.1/8.13.4) with ESMTP id k0GG9mnH004124; Mon, 16 Jan 2006 11:09:48 -0500
Received: from dul1wnexmb02.vcorp.ad.vrsn.com ([10.170.12.135]) by dul1wnexcn02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Jan 2006 11:01:44 -0500
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_01C61AB6.24F5412B"
Subject: Re: The new High Assurance SSL Certificates
Date: Mon, 16 Jan 2006 11:01:43 -0500
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: The new High Assurance SSL Certificates
Thread-Index: AcYatGPADq0XEOHYRUyRaFnPiM6x7QAAcGM9
From: "Aisenberg, Michael" <[e-mail]>
To: "Joel S. Kazin" <[e-mail]>, "Jeffrey I. Schiller" <[e-mail]>, "Anders Rundgren" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 16 Jan 2006 16:01:44.0183 (UTC) FILETIME=[257B1070:01C61AB6]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C61AB6.24F5412B
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Joel
Thanks for pointing out that this discussion is around Organizational =
certs, obtained from C/As by entities seeking to do business over the =
Net with consumers. Mediated by the browsers, these engagements are the =
ones where the consumers' understanding of the assurances being made (by =
the organization itelf,  by the  C/A, and (transitively ?) by the =
browser-chrome) are what is "at issue".  Under discussion in the C/A =
community is the ? of the means to best express a strong (more paper =
world-like) level of CA dilligence regarding the  identity attributes of =
the organizational subjects of these SSL certificates.  This is a =
process ...really, 2 processes. 1) attribute vetting by the CAs and 2) =
attribute display ("communication") in the browser, discernable and =
understandable to the consumer/user.  Another "process" ("labour") is =
the intra industry saga of reaching consensus on How and Where to do =
this (standards body, industry assn.) and then doing it...Promptly.

Michael

 -----Original Message-----
From: 	Joel S. Kazin [mailto:[e-mail]]
Sent:	Mon Jan 16 10:49:09 2006
To:	Jeffrey I. Schiller; Anders Rundgren
Cc:	[e-mail]
Subject:	Re: The new High Assurance SSL Certificates

As discussed at the October 2005 ABA ISC meeting, a HCA does not address =

the handling of a consumer's personal information.

----System Information
Platform: Windows 2000
Machine Type: Intel
System Version: 5.00.2195
Processor: Pentium II or III Model 8, Stepping 6
Physical RAM Installed: 261532 Kb
Eudora: Version 5.1
Mode: Sponsored Mode
Registration #:
MSHTML Version: 6.00
WININET Version: 6.00

At 04:37 PM 1/14/2006 -0500, Jeffrey I. Schiller wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>I apologize, as I am joining this thread a little late.... and I =
haven't
>had time to read every single message.
>
>That said, I believe the issue of a High Assurance CA (HCA) isn't
>ensuring that private keys are properly protected (not that it isn't
>important), but ensuring that when consumers go to a site signed by a
>High Assurance CA, that they know they can trust it to properly handle
>their personal information. This is a much broader problem.
>
>To me this means that when AOL.COM goes to a HCA to obtain a =
certificate
>they get it. But when AO1.COM attempts to apply for one they are =
denied.
>
>The trick is how do you do this. If I start a company named ?AO1
>Vacuums? and have the legal right to use ?AO1? in my name, how can
>another company (or oligarchy) deny me the right to have my customers
>trust my website? Perhaps what is needed is legal language that let's
>AO1.COM obtain a certificate provided they agree to not intentionally
>attempt to confuse people into believing that they are AOL.COM. I'll
>leave it to the lawyers to figure out the language that accomplishes
>this goal.
>
>So now the real problem is revocation. If AO1.COM obtains a HCA
>certificate and turns out to be a bad actor, there needs to be an
>effective way of revoking their certificate. We don't have a deployed
>mechanism today. Perhaps this is what we need from a technical =
perspective.
>
>                         -Jeff
>
>- --
>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D
>Jeffrey I. Schiller
>MIT Network Manager
>Information Services and Technology
>Massachusetts Institute of Technology
>77 Massachusetts Avenue  Room W92-190
>Cambridge, MA 02139-4307
>617.253.0161 - Voice
>[e-mail]
>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.4.1 (GNU/Linux)
>Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
>iD8DBQFDyW7+8CBzV/QUlSsRAkqYAKDWtkD0OQ6UDGCKGUz3buS6z2OdfgCg5W0H
>Dhey/w4/bCR1dvDqjduKpzo=3D
>=3DmED5
>-----END PGP SIGNATURE-----


Joel S. Kazin CPA, CISA, CISSP, CISM
Senior Consultant
Atos Origin
40 Old Sleepy Hollow Road
Pleasantville, New York 10570-3802
USA
Phone  [phone]
Mobile  [phone]
email    [e-mail]
www.atosorigin.com

------_=_NextPart_001_01C61AB6.24F5412B
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: The new High Assurance SSL Certificates</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>Joel<BR>
Thanks for pointing out that this discussion is around Organizational =
certs, obtained from C/As by entities seeking to do business over the =
Net with consumers. Mediated by the browsers, these engagements are the =
ones where the consumers' understanding of the assurances being made (by =
the organization itelf,&nbsp; by the&nbsp; C/A, and (transitively ?) by =
the browser-chrome) are what is &quot;at issue&quot;.&nbsp; Under =
discussion in the C/A community is the ? of the means to best express a =
strong (more paper world-like) level of CA dilligence regarding =
the&nbsp; identity attributes of the organizational subjects of these =
SSL certificates.&nbsp; This is a process ...really, 2 processes. 1) =
attribute vetting by the CAs and 2) attribute display =
(&quot;communication&quot;) in the browser, discernable and =
understandable to the consumer/user.&nbsp; Another &quot;process&quot; =
(&quot;labour&quot;) is the intra industry saga of reaching consensus on =
How and Where to do this (standards body, industry assn.) and then doing =
it...Promptly.<BR>
<BR>
Michael<BR>
<BR>
&nbsp;-----Original Message-----<BR>
From: &nbsp; Joel S. Kazin [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]=
m</A>]<BR>
Sent:&nbsp;&nbsp; Mon Jan 16 10:49:09 2006<BR>
To:&nbsp;&nbsp;&nbsp;&nbsp; Jeffrey I. Schiller; Anders Rundgren<BR>
Cc:&nbsp;&nbsp;&nbsp;&nbsp; [e-mail]<BR>
Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Re: The new High =
Assurance SSL Certificates<BR>
<BR>
As discussed at the October 2005 ABA ISC meeting, a HCA does not =
address<BR>
the handling of a consumer's personal information.<BR>
<BR>
----System Information<BR>
Platform: Windows 2000<BR>
Machine Type: Intel<BR>
System Version: 5.00.2195<BR>
Processor: Pentium II or III Model 8, Stepping 6<BR>
Physical RAM Installed: 261532 Kb<BR>
Eudora: Version 5.1<BR>
Mode: Sponsored Mode<BR>
Registration #:<BR>
MSHTML Version: 6.00<BR>
WININET Version: 6.00<BR>
<BR>
At 04:37 PM 1/14/2006 -0500, Jeffrey I. Schiller wrote:<BR>
<BR>
&gt;-----BEGIN PGP SIGNED MESSAGE-----<BR>
&gt;Hash: SHA1<BR>
&gt;<BR>
&gt;I apologize, as I am joining this thread a little late.... and I =
haven't<BR>
&gt;had time to read every single message.<BR>
&gt;<BR>
&gt;That said, I believe the issue of a High Assurance CA (HCA) =
isn't<BR>
&gt;ensuring that private keys are properly protected (not that it =
isn't<BR>
&gt;important), but ensuring that when consumers go to a site signed by =
a<BR>
&gt;High Assurance CA, that they know they can trust it to properly =
handle<BR>
&gt;their personal information. This is a much broader problem.<BR>
&gt;<BR>
&gt;To me this means that when AOL.COM goes to a HCA to obtain a =
certificate<BR>
&gt;they get it. But when AO1.COM attempts to apply for one they are =
denied.<BR>
&gt;<BR>
&gt;The trick is how do you do this. If I start a company named ?AO1<BR>
&gt;Vacuums? and have the legal right to use ?AO1? in my name, how =
can<BR>
&gt;another company (or oligarchy) deny me the right to have my =
customers<BR>
&gt;trust my website? Perhaps what is needed is legal language that =
let's<BR>
&gt;AO1.COM obtain a certificate provided they agree to not =
intentionally<BR>
&gt;attempt to confuse people into believing that they are AOL.COM. =
I'll<BR>
&gt;leave it to the lawyers to figure out the language that =
accomplishes<BR>
&gt;this goal.<BR>
&gt;<BR>
&gt;So now the real problem is revocation. If AO1.COM obtains a HCA<BR>
&gt;certificate and turns out to be a bad actor, there needs to be =
an<BR>
&gt;effective way of revoking their certificate. We don't have a =
deployed<BR>
&gt;mechanism today. Perhaps this is what we need from a technical =
perspective.<BR>
&gt;<BR>
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; -Jeff<BR>
&gt;<BR>
&gt;- --<BR>
&gt;=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D<BR>
&gt;Jeffrey I. Schiller<BR>
&gt;MIT Network Manager<BR>
&gt;Information Services and Technology<BR>
&gt;Massachusetts Institute of Technology<BR>
&gt;77 Massachusetts Avenue&nbsp; Room W92-190<BR>
&gt;Cambridge, MA 02139-4307<BR>
&gt;617.253.0161 - Voice<BR>
&gt;[e-mail]<BR>
&gt;=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D<BR>
&gt;-----BEGIN PGP SIGNATURE-----<BR>
&gt;Version: GnuPG v1.4.1 (GNU/Linux)<BR>
&gt;Comment: Using GnuPG with Thunderbird - <A =
HREF=3D"http://enigmail.mozdev.org">http://enigmail.mozdev.org</A><BR>
&gt;<BR>
&gt;iD8DBQFDyW7+8CBzV/QUlSsRAkqYAKDWtkD0OQ6UDGCKGUz3buS6z2OdfgCg5W0H<BR>
&gt;Dhey/w4/bCR1dvDqjduKpzo=3D<BR>
&gt;=3DmED5<BR>
&gt;-----END PGP SIGNATURE-----<BR>
<BR>
<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; [phone]<BR>
Mobile&nbsp; [phone]<BR>
email&nbsp;&nbsp;&nbsp; [e-mail]<BR>
www.atosorigin.com<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C61AB6.24F5412B--



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 k0GEDuQY027254; Mon, 16 Jan 2006 06:13:56 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k0GEDuRM027253; Mon, 16 Jan 2006 06:13:56 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] 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 k0GEDs98027143 for <[e-mail]>; Mon, 16 Jan 2006 06:13:55 -0800 (PST) (envelope-from [e-mail])
Received: from USARX006.namerica.NA.INT.ATOSORIGIN.COM (unknown [172.16.146.107]) by smtprelay-us1.aopn-na.com (Postfix) with ESMTP id 3284D5FD88; Mon, 16 Jan 2006 08:13:39 -0600 (CST)
Received: from SCHLUMBE-U23SVV.atosorigin.com ([172.16.150.39]) by USARX006.namerica.NA.INT.ATOSORIGIN.COM with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Jan 2006 08:13:32 -0600
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 16 Jan 2006 09:13:18 -0500
To: "Jeffrey I. Schiller" <[e-mail]>, Anders Rundgren <[e-mail]>
From: "Joel S. Kazin" <[e-mail]>
Subject: Re: The new High Assurance SSL Certificates
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <018701c618fc$0422e9e0$8217a8c0@arport2v> <018701c618fc$0422e9e0$8217a8c0@arport2v>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=====================_1928603==_"
X-OriginalArrivalTime: 16 Jan 2006 14:13:33.0097 (UTC) FILETIME=[087DF190:01C61AA7]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--=====================_1928603==_
Content-Type: text/plain; charset="us-ascii"; format=flowed

As discussed at the October 2005 ABA ISC meeting, a HCA does not address 
the handling of a consumer's personal information.

----System Information
Platform: Windows 2000
Machine Type: Intel
System Version: 5.00.2195
Processor: Pentium II or III Model 8, Stepping 6
Physical RAM Installed: 261532 Kb
Eudora: Version 5.1
Mode: Sponsored Mode
Registration #:
MSHTML Version: 6.00
WININET Version: 6.00

At 04:37 PM 1/14/2006 -0500, Jeffrey I. Schiller wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>I apologize, as I am joining this thread a little late.... and I haven't
>had time to read every single message.
>
>That said, I believe the issue of a High Assurance CA (HCA) isn't
>ensuring that private keys are properly protected (not that it isn't
>important), but ensuring that when consumers go to a site signed by a
>High Assurance CA, that they know they can trust it to properly handle
>their personal information. This is a much broader problem.
>
>To me this means that when AOL.COM goes to a HCA to obtain a certificate
>they get it. But when AO1.COM attempts to apply for one they are denied.
>
>The trick is how do you do this. If I start a company named ?AO1
>Vacuums? and have the legal right to use ?AO1? in my name, how can
>another company (or oligarchy) deny me the right to have my customers
>trust my website? Perhaps what is needed is legal language that let's
>AO1.COM obtain a certificate provided they agree to not intentionally
>attempt to confuse people into believing that they are AOL.COM. I'll
>leave it to the lawyers to figure out the language that accomplishes
>this goal.
>
>So now the real problem is revocation. If AO1.COM obtains a HCA
>certificate and turns out to be a bad actor, there needs to be an
>effective way of revoking their certificate. We don't have a deployed
>mechanism today. Perhaps this is what we need from a technical perspective.
>
>                         -Jeff
>
>- --
>=============================================================================
>Jeffrey I. Schiller
>MIT Network Manager
>Information Services and Technology
>Massachusetts Institute of Technology
>77 Massachusetts Avenue  Room W92-190
>Cambridge, MA 02139-4307
>617.253.0161 - Voice
>[e-mail]
>============================================================================
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.4.1 (GNU/Linux)
>Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
>iD8DBQFDyW7+8CBzV/QUlSsRAkqYAKDWtkD0OQ6UDGCKGUz3buS6z2OdfgCg5W0H
>Dhey/w4/bCR1dvDqjduKpzo=
>=mED5
>-----END PGP SIGNATURE-----


Joel S. Kazin CPA, CISA, CISSP, CISM
Senior Consultant
Atos Origin
40 Old Sleepy Hollow Road
Pleasantville, New York 10570-3802
USA
Phone  [phone]
Mobile  [phone]
email    [e-mail]
www.atosorigin.com

--=====================_1928603==_
Content-Type: text/plain; charset="us-ascii"

[Settings]
NC=1
Code=NC
NeverRegister=1
DontShowUpdates=1
DontShowAudit=1
WarnLaunchExtentions=exe|com|bat|cmd|pif|htm|do|xl|reg|lnk|vbs|
TabooHeaders=Received,Status,X-,In-Reply,Mime-Version,Content-,Resent-Message,References,Return,X400,X,Mail-System,Errors-To,Delivery,Disposition,Precedence
Mode=0
UserSignatures=1
SeenIntro=1
POPAccount=[e-mail]
RealName=Joel S. Kazin
SMTPServer=usarx006.namerica.na.int.atosorigin.com
ReturnAddress=[e-mail]
ACAPServer=
ACAPUserID=
PopServer=usarx006.namerica.na.int.atosorigin.com
LoginName=JKazin
LastOptionsCategory=0
AutoReceiveAttachmentsDirectory=D:\Documents\Mail\Attach
MailboxPreviewPane=1
MailboxSuperclose=1
WarnMapiAutoSend=1
NetworkCaching=0
EmptyTrashOnQuit=1
Commercial32Version=16
AdToolbarFloat=0
AdToolbarDock=2
MainWindowState=3
NGBase1=972453254
NGLast1=972453254
NGBase2=972453254
NGLast2=972453254
NGBase3=972453254
NGLast3=972453254
NGBase4=972453254
NGLast4=972453254
NGBase5=972453254
NGLast5=972453254
UseBidentAlways=1
LastWindowMax=0
Signature=Joel S. Kazin
MAPIUseNever=1
MAPIUseEudora=0
AutoExpandNicknames=1
DomainQualifier=
ImapDirectoryPrefix=
Stationery=
LeaveOnServerDays=0
BigMessageThreshold=40960
IMAPMaxDownloadSize=0
TrashMailboxName=Trash
CheckMailByDefault=1
LeaveMailOnServer=0
AuthenticateKerberos=0
AuthenticateAPOP=0
UseWinSock=1
AuthenticateRPA=0
UsesIMAP=0
UsesPOP=1
AuthenticatePassword=1
DeleteMailFromServer=0
ServerDelete=0
SkipBigMessages=0
IMAPMinDownload=1
IMAPOmitAttachments=0
TransferToTrashOnDelete=0
MarkAsDeleted=1
SmtpAuthAllowed=1
SuccessfulSend=1
CurrentTipOfTheDay=31
CheckForMailEvery=10
DontCheckUnconnected=1
TaskStatusStateWidth=120
TaskStatusStatusWidth=182
TaskStatusProgressWidth=133
NicknameLastActivePropertyPage=0
NicknameViewByIndex=6
FindMsgsCriteria1=Anywhere;contains;bank
FindMsgsCriteria2=Anywhere;contains;
FindMsgsCriteria3=Anywhere;contains;
FindMsgsCriteria4=Anywhere;contains;
FindMsgsCriteria5=Anywhere;contains;
FileBrowserNameWidth=100
FileBrowserTypeWidth=80
FileBrowserSizeWidth=45
FileBrowserModifiedWidth=120
PersonaViewNameWidth=90
PersonaViewAccountWidth=200
SearchResultsDateWidth=167
SearchResultsSubjectWidth=357
FindMsgsCriteriaCount=1
WarnDefaultMailto=0
RegistrationFlag=-1
CompactMailbox=10
CompactDisk=10
WarnExternalLaunchAttach=0
RegFirstNamePro=
RegLastNamePro=SiteLicense
RegCodePro=
SeenPlugins=x515x
SSLReceiveUse=0
SSLSendUse=0
LastTextColor=12
CompleterListHeight=41
ShowTipOfTheDay=0
AutoOK=1
Alert=0
WarnQueueStyledText=0
TaskMgrWaitTime=0
TaskStatusShowColDetails=1
TaskStatusDetailsWidth=320
NetworkBufferSize=409600
OfflineLinkAction=1
FetchInlineCOntent=0
RunHtmlCode=1
EasyOpen=1
LinkHistoryNameWidth=100
LinkHistoryDateVisitedWidth=140
LinkHistoryTypeWidth=50
ShowMailboxLines=1
MessageWidth=133
Profile=d0320018b4349321bc6558d4c0854c6c
WarnDeleteUnread=0

[Mappings]
out=txt,ttxt,TEXT,text,plain
both=doc,MSWD,,application,msword
out=mcw,MSWD,WDBN,application,msword
in=xls,XCEL,,,
out=xls,XCEL,XLS4,,
both=xlc,XCEL,XLC3,,
both=xlm,XCEL,XLM3,,
both=xlw,XCEL,XLW,,
both=ppt,PPT3,SLD3,,
both=wav,SCPL,WAVE,audio,microsoft-wave
both=grp,,,application,microsoft-group
both=wri,,,application,microsoft-write
both=cal,,,application,microsoft-calendar
both=zip,pZIP,pZIP,application,zip
both=rtf,MSWD,TEXT,application,rtf
both=pdf,,,application,pdf
both=ps,,,application,postscript
in=eps,,EPSF,,
out=eps,dPro,EPSF,application,postscript
both=jpg,JVWR,JPEG,image,jpeg
out=jpeg,JVWR,JPEG,image,jpeg
both=jfif,JFIF,JPEG,image,jpeg
both=gif,JVWR,GIFf,image,gif
both=tif,JVWR,TIFF,image,tiff
both=mpg,mMPG,MPEG,video,mpeg
both=mpeg,mMPG,MPEG,video,mpeg
both=mov,TVOD,MooV,video,quicktime
both=qt,TVOD,MooV,video,quicktime
both=png,,PNGf,image,png
both=htm,,,text,html
out=html,,,text,html
out=1st,ttxt,TEXT,text,plain
both=aif,SCPL,AIFF,,
both=arc,arc*,mArc,,
both=arj,DArj,BINA,,
out=asc,ttxt,TEXT,text,plain
out=asm,ttxt,TEXT,text,plain
both=au,SCPL,ULAW,,
out=bas,ttxt,TEXT,text,plain
out=bat,ttxt,TEXT,text,plain
out=bga,JVWR,BMPp,,
both=bmp,JVWR,BMPp,,
out=c,ttxt,TEXT,text,plain
both=cgm,GKON,CGMm,,
out=cmd,ttxt,TEXT,text,plain
out=com,mdos,BINA,,
out=cp,ttxt,TEXT,text,plain
out=cpp,ttxt,TEXT,text,plain
both=cpt,CPCT,PACT,,
out=csv,XCEL,TEXT,,
both=cvs,DAD2,drw2,,
out=dif,XCEL,TEXT,,
both=dl,GKON,DLdI,,
both=dvi,OTEX,ODVI,,
out=exe,mdos,BINA,,
out=faq,ttxt,TEXT,text,plain
out=flc,GKON,FLI,,
both=fli,GKON,FLI,,
both=fm,FMPR,FMPR,,
out=for,ttxt,TEXT,text,plain
both=gl,AnVw,,,
both=gz,Gzip,Gzip,,
out=h,ttxt,TEXT,text,plain
both=hqx,BnHq,TEXT,application,mac-binhex40
both=ico,GKON,ICO,,
both=iff,GKON,ILBM,,
both=ima,dCpy,dImg,,
both=img,GKON,IMGg,,
out=ini,ttxt,TEXT,text,plain
both=lbm,GKON,ILBM,,
both=lha,LARC,LHA,,
both=lzh,LARC,LHA,,
out=m3,ttxt,TEXT,text,plain
both=mac,dPro,PICT,,
out=mak,ttxt,TEXT,text,plain
out=me,ttxt,TEXT,text,plain
both=mod,SCPL,STrk,,
both=msp,GKON,MSPp,,
out=out,ttxt,TEXT,text,plain
out=p,ttxt,TEXT,text,plain
both=PAC,GKON,STAD,,
out=pas,ttxt,TEXT,text,plain
both=pbm,GKON,PPGM,,
both=pcs,GKON,PICS,,
both=pct,ttxt,PICT,,
both=pcx,GKON,PCXx,,
both=pgm,GKON,PPGM,,
both=pic,ttxt,PICT,,
both=pit,UPIT,PIT,,
both=plt,GKON,HPGL,,
both=pm,GKON,PMpm,,
both=pm3,ALD3,ALB3,,
both=pm4,ALD4,ALB4,,
both=pm5,ALD5,ALB5,,
both=pntg,SPNT,PNTG,,
both=ppm,GKON,PPGM,,
out=prn,ttxt,TEXT,text,plain
both=psd,8BIM,8BPS,,
both=qxd,XPRS,XDOC,,
both=rif,GKON,RIFF,,
both=rle,GKON,RLE,,
both=shp,GKON,SHPp,,
both=sit,SITx,SIT!,,
both=sit,SITx,SITD,,
both=slk,XCEL,TEXT,,
both=spc,GKON,Spec,,
both=sr,GKON,SUNn,,
both=sun,GKON,SUNn,,
both=sup,GKON,SCRN,,
both=svx,SCPL,8SVX,,
both=tar,TAR,TARF,,
both=tex,OTEX,TEXT,,
both=tga,8BIM,TPIC,,
both=tga,GKON,TARG,,
out=tx8,ttxt,TEXT,text,plain
out=vga,JVWR,BMPp,,
both=wks,L123,WKS,,
both=wmf,GKON,WMF,,
both=wp,WPC2,.WP5,application,wordperfect5.1
both=wp5,WPC2,.WP5,application,wordperfect5.1
both=z,LZIV,ZIVU,,
both=zoo,Booz,Zoo,,
both=qcp,Blad,celp,audio,vnd.qcelp

[]
CompactMailbox%25=10
CompactDisk%25=10

[Labels]
LabelCount=7
Label1=255,128,0,Label 1
Label2=255,0,0,Label 2
Label3=255,0,255,Label 3
Label4=0,128,255,Label 4
Label5=0,0,255,Label 5
Label6=0,128,0,Label 6
Label7=128,64,64,Label 7

[ToolBar-Bar0]
BarID=59393
Style=32768
ExStyle=0
PrevFloating=0
MDIChild=0
PctWidth=1000000
MRUFloatCX=0
MRUFloatCY=0
MRUHorzDockCX=0
MRUHorzDockCY=0
MRUVertDockCX=0
MRUVertDockCY=0
MRUDockingState=0
DockingStyle=0
TypeID=0

[ToolBar-Bar1]
BarID=318
Visible=0
XPos=0
YPos=0
MRUWidth=192
Docking=1
MRUDockID=59422
MRUDockLeftPos=1
MRUDockTopPos=5
MRUDockRightPos=1025
MRUDockBottomPos=608
MRUFloatStyle=8192
MRUFloatXPos=318
MRUFloatYPos=314
Style=8069
ExStyle=3889
PrevFloating=0
MDIChild=0
PctWidth=1000000
MRUFloatCX=192
MRUFloatCY=591
MRUHorzDockCX=1024
MRUHorzDockCY=603
MRUVertDockCX=228
MRUVertDockCY=643
MRUDockingState=61440
DockingStyle=61440
TypeID=0

[ToolBar-Bar10]
BarID=59423
Horz=0
Floating=1
XPos=4
YPos=64
Bars=3
Style=0
ExStyle=0
PrevFloating=0
MDIChild=1
PctWidth=0
MRUFloatCX=0
MRUFloatCY=0
MRUHorzDockCX=0
MRUHorzDockCY=0
MRUVertDockCX=0
MRUVertDockCY=0
MRUDockingState=0
DockingStyle=0
TypeID=0
Bar#0=0
Bar#1=319
Bar#2=0

[ToolBar-Bar2]
BarID=319
Visible=0
XPos=237
YPos=0
MRUWidth=722
Docking=1
MRUDockID=0
MRUDockLeftPos=5
MRUDockTopPos=-2
MRUDockRightPos=185
MRUDockBottomPos=500
MRUFloatStyle=4
MRUFloatXPos=312
MRUFloatYPos=312
Style=8069
ExStyle=3889
PrevFloating=0
MDIChild=0
PctWidth=1000000
MRUFloatCX=722
MRUFloatCY=475
MRUHorzDockCX=300
MRUHorzDockCY=180
MRUVertDockCX=180
MRUVertDockCY=502
MRUDockingState=0
DockingStyle=61440
TypeID=0

[ToolBar-Bar3]
BarID=320
Visible=0
XPos=-2
YPos=-2
MRUWidth=821
Docking=1
MRUDockID=59422
MRUDockLeftPos=1
MRUDockTopPos=5
MRUDockRightPos=1025
MRUDockBottomPos=105
MRUFloatStyle=8192
MRUFloatXPos=107
MRUFloatYPos=234
Style=12165
ExStyle=3889
PrevFloating=0
MDIChild=0
PctWidth=1000000
MRUFloatCX=821
MRUFloatCY=177
MRUHorzDockCX=1024
MRUHorzDockCY=100
MRUVertDockCX=180
MRUVertDockCY=180
MRUDockingState=61440
DockingStyle=0
TypeID=0

[ToolBar-Bar4]
BarID=316
XPos=-2
YPos=-2
Docking=1
MRUDockID=59422
MRUDockLeftPos=752
MRUDockTopPos=-11
MRUDockRightPos=1776
MRUDockBottomPos=164
MRUFloatStyle=8192
MRUFloatXPos=819
MRUFloatYPos=506
Style=12163
ExStyle=769
PrevFloating=0
MDIChild=0
PctWidth=1000000
MRUFloatCX=300
MRUFloatCY=180
MRUHorzDockCX=165
MRUHorzDockCY=156
MRUVertDockCX=165
MRUVertDockCY=643
MRUDockingState=61440
DockingStyle=0
TypeID=0

[ToolBar-Bar5]
BarID=59419
Bars=6
Style=0
ExStyle=0
PrevFloating=0
MDIChild=0
PctWidth=0
MRUFloatCX=0
MRUFloatCY=0
MRUHorzDockCX=0
MRUHorzDockCY=0
MRUVertDockCX=0
MRUVertDockCY=0
MRUDockingState=0
DockingStyle=0
TypeID=0
Bar#0=0
Bar#1=59392
Bar#2=59424
Bar#3=0
Bar#4=65854
Bar#5=0

[ToolBar-Bar6]
BarID=59422
Bars=7
Style=0
ExStyle=0
PrevFloating=0
MDIChild=0
PctWidth=0
MRUFloatCX=0
MRUFloatCY=0
MRUHorzDockCX=0
MRUHorzDockCY=0
MRUVertDockCX=0
MRUVertDockCY=0
MRUDockingState=0
DockingStyle=0
TypeID=0
Bar#0=0
Bar#1=65854
Bar#2=0
Bar#3=65856
Bar#4=0
Bar#5=65852
Bar#6=0

[ToolBar-Bar7]
BarID=59420
Bars=5
Style=0
ExStyle=0
PrevFloating=0
MDIChild=0
PctWidth=0
MRUFloatCX=0
MRUFloatCY=0
MRUHorzDockCX=0
MRUHorzDockCY=0
MRUVertDockCX=0
MRUVertDockCY=0
MRUDockingState=0
DockingStyle=0
TypeID=0
Bar#0=0
Bar#1=65852
Bar#2=0
Bar#3=65854
Bar#4=0

[ToolBar-Bar8]
BarID=59421
Bars=5
Style=0
ExStyle=0
PrevFloating=0
MDIChild=0
PctWidth=0
MRUFloatCX=0
MRUFloatCY=0
MRUHorzDockCX=0
MRUHorzDockCY=0
MRUVertDockCX=0
MRUVertDockCY=0
MRUDockingState=0
DockingStyle=0
TypeID=0
Bar#0=0
Bar#1=65852
Bar#2=0
Bar#3=65855
Bar#4=0

[ToolBar-Bar9]
BarID=59392
MRUWidth=734
Docking=1
MRUDockID=59419
MRUDockLeftPos=-1
MRUDockTopPos=-1
MRUDockRightPos=733
MRUDockBottomPos=42
MRUFloatStyle=8196
MRUFloatXPos=-2147483648
MRUFloatYPos=0
Style=12212
ExStyle=780
PrevFloating=0
MDIChild=0
PctWidth=500000
MRUFloatCX=734
MRUFloatCY=43
MRUHorzDockCX=734
MRUHorzDockCY=43
MRUVertDockCX=43
MRUVertDockCY=693
MRUDockingState=0
DockingStyle=61440
TypeID=14946
Title=Toolbar
Buttons=FCAIAAAAAAAAAAAAAAAAIBAIAAAAAAJBAIAAAAAAAAAAAAAAAAEAAIAAAAAAAAAAAAAAAANBAIAAAAAAHFAIAAAAAAIFAIAAAAAAPBAIAAAAAAAAAAAAAAAAFOAIAAAAAAGOAIAAAAAAAAAAAAAAAAECAIAAAAAAAAAAAAAAAAKAAIAAAAAAAAAAAAAAAAMDAIAAAAAAAAAAAAAAAAHABOAAAAAAAAAAAAAAAAFEBOAAAAAAAAAAAAAAAA

[ToolBar-BarID59392]
btn0=32805
btn1=0
btn2=32792
btn3=32793
btn4=0
btn5=32772
btn6=0
btn7=32797
btn8=32855
btn9=32856
btn10=32799
btn11=0
btn12=32997
btn13=32998
btn14=0
btn15=32804
btn16=0
btn17=32778
btn18=0
btn19=32828
btn20=0
btn21=57607
btn22=0
btn23=57669
btn24=0
CustomButtonCount=0

[ToolBar-Summary]
Bars=14
ScreenCX=1024
ScreenCY=768

[ToolBar-ToolBarManager]
ToolTips=1
CoolLook=1
LargeButtons=1

[Window Position]
AdToolbarWindowPosition=927,39,1024,82
MainWindowPosition=306,77,551,717
NicknamesWindowSplitterPosition=247
FindMsgsWindowPosition=22,22,686,374
StatisticsWindowPosition=0,0,670,528
ProgressWindowPosition=252,526,702,631
FiltersWindowSplitterPosition=252
TextFileWindowPosition=0,0,600,27
CheckSpellingWindowPosition=60,84,467,257

[DirectoryServices]
OldKeepOnTopConverted=1
TopPaneY=134
BottomPaneY=187
PanesX=281
LeftPaneX=254
RightPaneX=423
PanesY=420
KeepOnTop=0
Finger:Qualcomm Finger Server=0
LDAP:Big Foot=0
LDAP:Switch Board=0
LDAP:Four11=0
LDAP:InfoSpace=0
LDAP:InfoSpace Business=0
LDAP:Atos LDAP replica - Summary=1
LDAP:SLB LDAP all attributes=1
LDAP:SLB LDAP Europe summary=1
LDAP:SLB LDAP Europe all attributes=1
LDAP:Who Where=0
Ph:SLB Ph interface to LDAP=0
Ph:SLB Ph server=0
Ph:BigFoot=0
Ph:Qualcomm=0
Eudora Address Book:Eudora Nicknames=0

[ToolBar-Bar11]
BarID=59423
Horz=1
Floating=1
XPos=111
YPos=254
Bars=3
Style=0
ExStyle=0
PrevFloating=0
MDIChild=0
PctWidth=0
MRUFloatCX=0
MRUFloatCY=0
MRUHorzDockCX=0
MRUHorzDockCY=0
MRUVertDockCX=0
MRUVertDockCY=0
MRUDockingState=0
DockingStyle=0
TypeID=0
Bar#0=0
Bar#1=320
Bar#2=0

[ToolBar-Bar12]
BarID=59423
Horz=0
Floating=1
XPos=10
YPos=66
Bars=3
Style=0
ExStyle=0
PrevFloating=0
MDIChild=1
PctWidth=0
MRUFloatCX=0
MRUFloatCY=0
MRUHorzDockCX=0
MRUHorzDockCY=0
MRUVertDockCX=0
MRUVertDockCY=0
MRUDockingState=0
DockingStyle=0
TypeID=0
Bar#0=0
Bar#1=318
Bar#2=0




[ToolBar-Bar13]
BarID=59423
Horz=1
Floating=1
XPos=823
YPos=526
Bars=3
Style=0
ExStyle=0
PrevFloating=0
MDIChild=0
PctWidth=0
MRUFloatCX=0
MRUFloatCY=0
MRUHorzDockCX=0
MRUHorzDockCY=0
MRUVertDockCX=0
MRUVertDockCY=0
MRUDockingState=0
DockingStyle=0
TypeID=0
Bar#0=0
Bar#1=316
Bar#2=0
[Open Windows]
OpenWindow1=2,1,Out.mbx,Out
OpenWindow2=2,3,In.mbx,In
[WazooBars]
WazooBarIds=318,319,320
WazooBar318=16,CMboxWazooWnd,CFileBrowseWazooWnd,CSignatureWazooWnd,CStationeryWazooWnd,CPersonalityWazooWnd
WazooMDI318=6,2,118,29,1,0
WazooBar319=16,CNicknamesWazooWnd,DirectoryServicesWazooWndNew,CFiltersWazooWnd,CFilterReportWazooWnd,CLinkHistoryWazooWnd
WazooMDI319=0,0,112,27,1,0
WazooBar320=64,CTaskStatusWazooWnd,CTaskErrorWazooWnd
[Recent File List]
File1=C:\Program Files\Qualcomm\Eudora\A
File2=D:\Documents\Pfizer\A
File3=D:\Documents\My Pictures\2004-11-12\A
File4=D:\Documents\ChevronTexaco\A

--=====================_1928603==_--



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 k0GDc8Ag010503; Mon, 16 Jan 2006 05:38:08 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k0GDc8LS010502; Mon, 16 Jan 2006 05:38:08 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from nic.lp.se (nic.lp.se [213.212.3.208]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0GDc6Cv010492 for <[e-mail]>; Mon, 16 Jan 2006 05:38:07 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (127.0.0.1) by nic.lp.se (MX V5.4 VnHj) with ESMTP; Mon, 16 Jan 2006 14:37:42 +0100
Date: Mon, 16 Jan 2006 14:36:50 +0100 (CET)
Message-ID: <[e-mail]>
To: [e-mail]
CC: [e-mail]
Subject: Re: pathLenConstraint
From: Richard Levitte - VMS Whacker <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
X-URL: http://richard.levitte.org/
X-Waved: dead chicken, GNU emacs 21.4.1, Mew version 4.2.52
X-Mew: See http://www.mew.org/
X-Mailer: Mew version 4.2.52 on Emacs 21.4 / Mule 5.0 (SAKAKI)
MIME-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

In message <[e-mail]> on Fri, 13 Jan 2006 16:24:49 +0100, "Kuhn, Sebastien" <[e-mail]> said:

sebastien.kuhn> Could you confirm that the attribute
sebastien.kuhn> "pathLenConstraint" (included in the extension
sebastien.kuhn> "BasicConstraints") can have no limit in a Root CA
sebastien.kuhn> certificate and a finite value in a CA certificate
sebastien.kuhn> subordinate to the Root CA ?

Yes, as far as I understand.  I can't really imagine why it shouldn't

Cheers,
Richard

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.

-- 
Richard Levitte                         [e-mail]
                                        http://richard.levitte.org/

"When I became a man I put away childish things, including
 the fear of childishness and the desire to be very grown up."
						-- C.S. Lewis



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 k0G6h2Lw092145; Sun, 15 Jan 2006 22:43:02 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k0G6h28d092144; Sun, 15 Jan 2006 22:43:02 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from trantor.eads-telecom.com (eads-telecom.com.siris.net [62.8.24.122] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0G6gxUr092025 for <[e-mail]>; Sun, 15 Jan 2006 22:43:01 -0800 (PST) (envelope-from [e-mail])
Received: from trantor.eads-telecom.com (root@localhost) by trantor.eads-telecom.com (8.12.5-20030924/8.12.5) with ESMTP id k0G6tYnP000115 for <[e-mail]>; Mon, 16 Jan 2006 07:55:41 +0100 (CET)
Received: from unknown(172.29.64.4) by trantor.eads-telecom.com via smap (5.0); id xma022039; Fri, 13 Jan 2006 16:37:59 +0100
Received: from edsnmsxbda01.edsn.com ([131.129.5.127]) by hermes.edsn.com (8.12.10/8.12.10) with ESMTP id k0DFTA5r018313 for <[e-mail]>; Fri, 13 Jan 2006 16:29:10 +0100
Received: by edsnmsxbda01.edsn.com with Internet Mail Service (5.5.2653.19) id <CTFXV9BT>; Fri, 13 Jan 2006 16:24:50 +0100
Message-ID: <[e-mail]>
From: "Kuhn, Sebastien" <[e-mail]>
To: [e-mail]
Subject: pathLenConstraint
Date: Fri, 13 Jan 2006 16:24:49 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hello,

Could you confirm that the attribute "pathLenConstraint" (included in the
extension "BasicConstraints") can have no limit in a Root CA certificate and
a finite value in a CA certificate subordinate to the Root CA ?

Thank you in advance.

Sebastien.



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 k0EMwsWJ011809; Sat, 14 Jan 2006 14:58:54 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k0EMwsgO011808; Sat, 14 Jan 2006 14:58:54 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mtiwmhc12.worldnet.att.net (mtiwmhc12.worldnet.att.net [204.127.131.116]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0EMwrcP011729 for <[e-mail]>; Sat, 14 Jan 2006 14:58:54 -0800 (PST) (envelope-from [e-mail])
Received: from gw (124.san-jose-06-08rs.ca.dial-access.att.net[12.72.194.124]) by worldnet.att.net (mtiwmhc12) with SMTP id <2006011422584211200270b3e>; Sat, 14 Jan 2006 22:58:47 +0000
Message-ID: <00ba01c6195e$18eddda0$7cc2480c@gw>
Reply-To: "todd glassey" <[e-mail]>
From: "todd glassey" <[e-mail]>
To: <[e-mail]>, "Paul Hoffman" <[e-mail]>
References: <018701c618fc$0422e9e0$8217a8c0@arport2v> <[e-mail]> <p0623092bbfef213732f1@[10.20.30.249]>
Subject: Re: The new High Assurance SSL Certificates
Date: Sat, 14 Jan 2006 14:58:48 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1506
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Paul, if I may, one of the problems that this group is running into is
whether there is a mechanical process that High-Reliability requires or
whether the issuance and maintenance models are sufficient with these new
'reliance models' to support the proposed use models, and personally its all
about how they are used that should force the stratification between
high-reliance and low-dollar value transactions...

Todd Glassey

----- Original Message ----- 
From: "Paul Hoffman" <[e-mail]>
To: <[e-mail]>
Sent: Saturday, January 14, 2006 1:46 PM
Subject: Re: The new High Assurance SSL Certificates


>
> At 12:05 PM -0800 1/14/06, Mark wrote:
> >Applications need to have mechanisms embedded into them to
> >distinguish between high assurance and other certificates.
>
> Applications only need that if there is a difference that is
> noticeable to the user.
>
> Question: what is the difference between VeriSign high assurance and
> VeriSign low assurance certificates? If a developer can't answer the
> question, then the app doesn't need to differentiate.
>
> --Paul Hoffman, Director
> --VPN Consortium
>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0ELkduQ061643; Sat, 14 Jan 2006 13:46:39 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k0ELkdfK061642; Sat, 14 Jan 2006 13:46:39 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from [10.20.30.249] (dsl2-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0ELkbeh061636 for <[e-mail]>; Sat, 14 Jan 2006 13:46:37 -0800 (PST) (envelope-from [e-mail])
Mime-Version: 1.0
Message-Id: <p0623092bbfef213732f1@[10.20.30.249]>
In-Reply-To: <[e-mail]>
References: <018701c618fc$0422e9e0$8217a8c0@arport2v> <[e-mail]>
Date: Sat, 14 Jan 2006 13:46:34 -0800
To: [e-mail]
From: Paul Hoffman <[e-mail]>
Subject: Re: The new High Assurance SSL Certificates
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 12:05 PM -0800 1/14/06, Mark wrote:
>Applications need to have mechanisms embedded into them to 
>distinguish between high assurance and other certificates.

Applications only need that if there is a difference that is 
noticeable to the user.

Question: what is the difference between VeriSign high assurance and 
VeriSign low assurance certificates? If a developer can't answer the 
question, then the app doesn't need to differentiate.

--Paul Hoffman, Director
--VPN Consortium



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0ELbwBn055970; Sat, 14 Jan 2006 13:37:58 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k0ELbwMR055969; Sat, 14 Jan 2006 13:37:58 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0ELbvSO055926 for <[e-mail]>; Sat, 14 Jan 2006 13:37:57 -0800 (PST) (envelope-from [e-mail])
Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.12.4/8.9.2) with ESMTP id k0ELbsY2007335; Sat, 14 Jan 2006 16:37:55 -0500 (EST)
Received: from [192.168.94.131] (JISVPN.MIT.EDU [18.100.101.102]) (authenticated bits=0) (User authenticated as [e-mail]) by outgoing.mit.edu (8.13.1/8.12.4) with ESMTP id k0ELbqeC000852 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 14 Jan 2006 16:37:53 -0500 (EST)
Message-ID: <[e-mail]>
Date: Sat, 14 Jan 2006 16:37:04 -0500
From: "Jeffrey I. Schiller" <[e-mail]>
Organization: Massachusetts Institute of Technology
User-Agent: Debian Thunderbird 1.0.2 (X11/20050331)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Anders Rundgren <[e-mail]>
CC: [e-mail]
Subject: Re: The new High Assurance SSL Certificates
References: <018701c618fc$0422e9e0$8217a8c0@arport2v>
In-Reply-To: <018701c618fc$0422e9e0$8217a8c0@arport2v>
X-Enigmail-Version: 0.92.0.0
OpenPGP: id=F414952B
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Score: 1.217
X-Spam-Level: * (1.217)
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I apologize, as I am joining this thread a little late.... and I haven't
had time to read every single message.

That said, I believe the issue of a High Assurance CA (HCA) isn't
ensuring that private keys are properly protected (not that it isn't
important), but ensuring that when consumers go to a site signed by a
High Assurance CA, that they know they can trust it to properly handle
their personal information. This is a much broader problem.

To me this means that when AOL.COM goes to a HCA to obtain a certificate
they get it. But when AO1.COM attempts to apply for one they are denied.

The trick is how do you do this. If I start a company named ?AO1
Vacuums? and have the legal right to use ?AO1? in my name, how can
another company (or oligarchy) deny me the right to have my customers
trust my website? Perhaps what is needed is legal language that let's
AO1.COM obtain a certificate provided they agree to not intentionally
attempt to confuse people into believing that they are AOL.COM. I'll
leave it to the lawyers to figure out the language that accomplishes
this goal.

So now the real problem is revocation. If AO1.COM obtains a HCA
certificate and turns out to be a bad actor, there needs to be an
effective way of revoking their certificate. We don't have a deployed
mechanism today. Perhaps this is what we need from a technical perspective.

			-Jeff

- --
=============================================================================
Jeffrey I. Schiller
MIT Network Manager
Information Services and Technology
Massachusetts Institute of Technology
77 Massachusetts Avenue  Room W92-190
Cambridge, MA 02139-4307
617.253.0161 - Voice
[e-mail]
============================================================================
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDyW7+8CBzV/QUlSsRAkqYAKDWtkD0OQ6UDGCKGUz3buS6z2OdfgCg5W0H
Dhey/w4/bCR1dvDqjduKpzo=
=mED5
-----END PGP SIGNATURE-----



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 k0EK5hBX092519; Sat, 14 Jan 2006 12:05:43 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k0EK5hFh092518; Sat, 14 Jan 2006 12:05:43 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pd3mo2so.prod.shaw.ca (shawidc-mo1.cg.shawcable.net [24.71.223.10]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0EK5gJ0092512 for <[e-mail]>; Sat, 14 Jan 2006 12:05:42 -0800 (PST) (envelope-from [e-mail])
Received: from pd5mr6so.prod.shaw.ca (pd5mr6so-qfe3.prod.shaw.ca [10.0.141.182]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0IT300AR2MHI6A70@l-daemon> for [e-mail]; Sat, 14 Jan 2006 13:05:42 -0700 (MST)
Received: from pn2ml7so.prod.shaw.ca ([10.0.121.151]) by pd5mr6so.prod.shaw.ca (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <[e-mail]> for [e-mail]; Sat, 14 Jan 2006 13:05:42 -0700 (MST)
Received: from [192.168.0.2] ([24.108.158.110]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0IT300DMPMHHLLA0@l-daemon> for [e-mail]; Sat, 14 Jan 2006 13:05:42 -0700 (MST)
Date: Sat, 14 Jan 2006 12:05:38 -0800
From: Mark <[e-mail]>
Subject: Re: The new High Assurance SSL Certificates
In-reply-to: <018701c618fc$0422e9e0$8217a8c0@arport2v>
To: Anders Rundgren <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0 (Apple Message framework v623)
X-Mailer: Apple Mail (2.623)
Content-type: text/plain; charset=US-ASCII; format=flowed
Content-transfer-encoding: 7bit
References: <018701c618fc$0422e9e0$8217a8c0@arport2v>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I agree with your two points.  Applications need to have mechanisms 
embedded into them to distinguish between high assurance and other 
certificates.  One of the standards I'm currently working on that may 
help is looking at using XML to classify documents.  I know that it 
does not directly relate to high assurance SSL server certificates and 
I will get to that point later.  There must be a way to distinguish how 
information and assets are differentiated by applications.  One of the 
ways is to enable a policy based management of information and 
certificates.  Using information classification you can set up policies 
to manage how that information is treated when it is sent or received.  
It still depends very much on the applications being able to 
differentiate the information.  However in looking at standards and how 
we could use PKI to provide a layer of security to further protect 
sensitive information and transactions we need some standards around 
how information is classified to improve interoperability.

On the second point it boils down to an organization issuing the high 
assurance certificates.  Somehow there needs to be a way to authorize 
and authenticate the certificate using existing methods.  We already 
deal with SSL certificates and can check revocation.  If several 
organizations are authorized and accredited to issue high assurance 
certificates, then applications can check CRLs or whatever the 
organization uses to validate high assurance certificates.  Now what 
organization should authorize and accredit organizations issuing high 
assurance certificates?  It should be not be government.

Sorry for getting a bit off-topic on the XML and information 
classification but I believe that there are a number of pieces to this 
issue and it gets down to business automation and there is a connection 
between using XML and PKI to enable policy based management of 
transactions and information.  I'd like to hear from others if I'm off 
base or this resonates with people.

Cheers


On 14-Jan-06, at 3:16 AM, Anders Rundgren wrote:

>
> Apparently a number of commercial issuers of certificates are
> currently considering creating a new class of "High Assurance"
> (HA) SSL server-certificates, in order to improve the somewhat
> bad reputation associated with the current scheme.
>
> In a recent Mozilla blob, it was suggested that Firefox in order to
> recognize that it is really dealing with a high assurance certificate
> (and presumably showing that to the user in some way), should rely on
> a specific set of agreed-upon RFC 3280 policy identifiers.  This is
> in my opinion not a particularly good idea for two reasons:
>
> 1.  SSL server-certificates are extensively used for other 
> applications, both
> in server-mode and in client-mode (as signature certificates).  Few if
> any of these applications, are currently "trained" to rely on anything
> but root anchors.   If you roll your own certs which is quite common
> in local installations, current instructions on how to use SSL such as
> featured in IIS, OpenSSL, Tomcat, JDK etc. never go into policy
> identifiers.
>
> 2. I may be wrong here, but is there actually anything that prevents a 
> low-
> assurance certificate issuer to include high assurance policy 
> identifiers?
>
> That is, the new HA certificates should preferably support the 
> following
> policy scheme:
>
>        CA_root => Implicit Policy + Explicit Policy
>
> ======================================================================
> Commercial issuers should seriously consider the liability issues
> associated with having a single root for different kinds of
> certificates.  It can in such a scheme hardly be the relying party
> who is responsible for unintentionally accepting "wrong" certificates.
> ======================================================================
>
> Note that this should not be interpreted as that there should not be
> any HA policy identifiers, it is just the idea to FORCE their usage
> on applications that I believe would in fact only complicate rollout.
>
> Comments?
>
> Anders Rundgren
>
> Disclaimer: The views expressed in this message are solely the
> author's and should not be attributed to his employer or their clients
>



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 k0EBEOqn084760; Sat, 14 Jan 2006 03:14:24 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k0EBEOOZ084759; Sat, 14 Jan 2006 03:14:24 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pne-smtpout1-sn2.hy.skanova.net (pne-smtpout1-sn2.hy.skanova.net [81.228.8.83]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0EBEO9r084752 for <[e-mail]>; Sat, 14 Jan 2006 03:14:24 -0800 (PST) (envelope-from [e-mail])
Received: from arport2v (81.232.45.196) by pne-smtpout1-sn2.hy.skanova.net (7.2.069.1) id 43C77BA4000539F8 for [e-mail]; Sat, 14 Jan 2006 12:14:17 +0100
Message-ID: <018701c618fc$0422e9e0$8217a8c0@arport2v>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>
Subject: The new High Assurance SSL Certificates
Date: Sat, 14 Jan 2006 12:16:50 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Apparently a number of commercial issuers of certificates are
currently considering creating a new class of "High Assurance"
(HA) SSL server-certificates, in order to improve the somewhat
bad reputation associated with the current scheme.

In a recent Mozilla blob, it was suggested that Firefox in order to
recognize that it is really dealing with a high assurance certificate
(and presumably showing that to the user in some way), should rely on
a specific set of agreed-upon RFC 3280 policy identifiers.  This is
in my opinion not a particularly good idea for two reasons:

1.  SSL server-certificates are extensively used for other applications, both
in server-mode and in client-mode (as signature certificates).  Few if
any of these applications, are currently "trained" to rely on anything
but root anchors.   If you roll your own certs which is quite common
in local installations, current instructions on how to use SSL such as
featured in IIS, OpenSSL, Tomcat, JDK etc. never go into policy
identifiers.

2. I may be wrong here, but is there actually anything that prevents a low-
assurance certificate issuer to include high assurance policy identifiers?

That is, the new HA certificates should preferably support the following
policy scheme:

       CA_root => Implicit Policy + Explicit Policy

======================================================================
Commercial issuers should seriously consider the liability issues
associated with having a single root for different kinds of
certificates.  It can in such a scheme hardly be the relying party
who is responsible for unintentionally accepting "wrong" certificates.
======================================================================

Note that this should not be interpreted as that there should not be
any HA policy identifiers, it is just the idea to FORCE their usage
on applications that I believe would in fact only complicate rollout.

Comments?

Anders Rundgren

Disclaimer: The views expressed in this message are solely the
author's and should not be attributed to his employer or their clients



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 k0DNo30t027986; Fri, 13 Jan 2006 15:50:03 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k0DNo3ln027985; Fri, 13 Jan 2006 15:50:03 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from newodin.ietf.org ([132.151.6.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0DNo25T027979 for <[e-mail]>; Fri, 13 Jan 2006 15:50:02 -0800 (PST) (envelope-from [e-mail])
Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1ExYgD-0004et-WA; Fri, 13 Jan 2006 18:50:02 -0500
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-rfc3280bis-02.txt 
Message-Id: <[e-mail]>
Date: Fri, 13 Jan 2006 18:50:01 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?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-02.txt
	Pages		: 140
	Date		: 2006-1-13
	
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-02.txt

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] 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-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:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-rfc3280bis-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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-rfc3280bis-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-rfc3280bis-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--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 k0DMDCpe017445; Fri, 13 Jan 2006 14:13:12 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k0DMDCsX017444; Fri, 13 Jan 2006 14:13:12 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0DMDBMR017437 for <[e-mail]>; Fri, 13 Jan 2006 14:13:11 -0800 (PST) (envelope-from [e-mail])
Received: from mailout2.microsoft.com ([157.54.1.120]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); Fri, 13 Jan 2006 14:13:11 -0800
Received: from red-hub-01.redmond.corp.microsoft.com ([157.54.7.71]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jan 2006 14:13:11 -0800
Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.196]) by red-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jan 2006 14:13:10 -0800
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-ecc-pkalgs-02.txt 
Date: Fri, 13 Jan 2006 22:13:01 -0000
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: I-D ACTION:draft-ietf-pkix-ecc-pkalgs-02.txt 
thread-index: AcYTJMKxzkEoHPxBTc2VGLOQDVt0qQFaVctg
From: "Stefan Santesson" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 13 Jan 2006 22:13:10.0622 (UTC) FILETIME=[89FE87E0:01C6188E]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id k0DMDCMR017438
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

There is a problem with this latest draft submission.
If you download it, it appears as a .zip file, but it is not.

If you just rename it as a regular text file then you can open it as
usual.


Stefan Santesson
Program Manager, Standards Liaison
Windows Security


-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of [e-mail]
Sent: den 6 januari 2006 15:50
To: [e-mail]
Cc: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-ecc-pkalgs-02.txt 

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		: Additional Algorithms and Identifiers for use
of Elliptic Curve Cryptography with PKIX
	Author(s)	: D. Brown
	Filename	: draft-ietf-pkix-ecc-pkalgs-02.txt
	Pages		: 25
	Date		: 2006-1-6
	
This document gives additional algorithms and associated ASN.1
   identifiers for elliptic curve cryptography (ECC) used with the
   Internet X.509 Public Key Infrastructure Certificate and
   Certificate Revocation List (CRL) Profile (PKIX).  The algorithms
   and identifiers here are consistent with both ANSI X9.62-1998 and
   X9.63-2001, and shall be consistent with the forthcoming revisions
   of these documents.  Consistency shall also be maintained with SEC1
   and SEC2, and any revisions or successors of such documents.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-ecc-pkalgs-02.txt

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] 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-ecc-pkalgs-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:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-ecc-pkalgs-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.



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 k06No2T2015652; Fri, 6 Jan 2006 15:50:02 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k06No2bZ015651; Fri, 6 Jan 2006 15:50:02 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from newodin.ietf.org ([132.151.6.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k06No1nS015645 for <[e-mail]>; Fri, 6 Jan 2006 15:50:02 -0800 (PST) (envelope-from [e-mail])
Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1Ev1LN-0003iJ-N3; Fri, 06 Jan 2006 18:50:01 -0500
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-ecc-pkalgs-02.txt 
Message-Id: <[e-mail]>
Date: Fri, 06 Jan 2006 18:50:01 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?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		: Additional Algorithms and Identifiers for use of Elliptic Curve Cryptography with PKIX
	Author(s)	: D. Brown
	Filename	: draft-ietf-pkix-ecc-pkalgs-02.txt
	Pages		: 25
	Date		: 2006-1-6
	
This document gives additional algorithms and associated ASN.1
   identifiers for elliptic curve cryptography (ECC) used with the
   Internet X.509 Public Key Infrastructure Certificate and
   Certificate Revocation List (CRL) Profile (PKIX).  The algorithms
   and identifiers here are consistent with both ANSI X9.62-1998 and
   X9.63-2001, and shall be consistent with the forthcoming revisions
   of these documents.  Consistency shall also be maintained with SEC1
   and SEC2, and any revisions or successors of such documents.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-ecc-pkalgs-02.txt

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] 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-ecc-pkalgs-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:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-ecc-pkalgs-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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-ecc-pkalgs-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-ecc-pkalgs-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--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 k02MGhVm093580; Mon, 2 Jan 2006 14:16:43 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k02MGhal093579; Mon, 2 Jan 2006 14:16:43 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-ft5.fr.colt.net (smtp-ft5.fr.colt.net [213.41.78.199]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k02MGf1t093569 for <[e-mail]>; Mon, 2 Jan 2006 14:16:42 -0800 (PST) (envelope-from [e-mail])
Received: from [10.0.0.81] (host.106.92.68.195.rev.coltfrance.com [195.68.92.106]) by smtp-ft5.fr.colt.net (8.13.4/8.13.4/Debian-3) with ESMTP id k02MGebS015977 for <[e-mail]>; Mon, 2 Jan 2006 23:16:40 +0100
Message-ID: <[e-mail]>
Date: Mon, 02 Jan 2006 23:16:39 +0100
From: Jean-Marc Desperrier <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; fr-FR; rv:1.9a1) Gecko/20051221 SeaMonkey/1.5a
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Certificate Validity Problem
References: <003401c6063b$4df1d7d0$[e-mail]>
In-Reply-To: <003401c6063b$4df1d7d0$[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

santosh chokhani wrote:
> If the cryptanalysis or compromise of expired keys is not a concern, one
> could do cumulative CRL using an X.509 extension (3280 does not have this)
> stating that the CRL contains expired certificates.
>   
I'm replying a bit late, but IMO that extension from X.509 (2005) 
(expiredCertsOnCRL) would be a very useful addition to rfc 3280bis.

If the motivation for not including it is to keep the document small, I 
can make a list of much less needed elements to remove :-)