Re: Certificate Policy Standardization

[[e-mail] (Peter Gutmann)]

=?ISO-8859-1?Q?Michael_Str=F6der?= <[e-mail]> writes:

>I'm not a lawyer and the terms are for sure used much differently in other
>countries. But I also guess that most ToS-style CPs would not withstand a
>court trial based on german AGB-Gesetz, the law regulating "Allgemeine 
>Gesch=E4ftsbedingungen" (similar to ToS).
>
>But since PKI did not hit the mass market yet a CA with such a ToS-style CP
>can assume that this risk is quite low. 
>
>Less RPs => less serious usage => less risks. ;-)

That was the feeling here too.  No-one knows what analysis (e.g.) Telecom's
lawyers went through to come up with their ToS, but certainly for PKI it was
felt that the stakes are so low that it's unlikely anyone will ever bother
testing the CP in court, just as with an ISP no-one will pursue a $100K test
case over a $29.95 account.  So it's not just what's legal, it's what you can
get away with, and since PKI is a legal gray area anyway the balance is
definitely skewed in favour of the large, well-funded incumbent applying
whatever terms they feel like, because any kind of legal challenge is going to
end up as an expensive, uncertain-outcome test case.

I know that there's been some legal analysis of the use of shared-key MACs in
situations where you'd normally expect a PKI to be used, and even though some
of the lawyers could immediately see that it wasn't secure, the feeling was
that the chances of it being successfully challenged in court were negligible.
This is at least in part because of signed (on paper) agreements assigning
responsibility (there are local variations on this, e.g. in the military you
can be ordered to accept the ToS just as they can order you to walk through a
minefield).

Banks got by with simple checksums for some decades without any major legal
problems...

Peter.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAT19Kib052754 for <[e-mail]>; Fri, 28 Nov 2003 17:09:20 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAT19KqB052753 for ietf-pkix-bks; Fri, 28 Nov 2003 17:09:20 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.cs.auckland.ac.nz (csmail.cs.auckland.ac.nz [130.216.33.150]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAT19Hib052746 for <[e-mail]>; Fri, 28 Nov 2003 17:09:19 -0800 (PST) (envelope-from [e-mail])
Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id CE40563C32; Sat, 29 Nov 2003 14:09:18 +1300 (NZDT)
Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id hAT1CGe15590; Sat, 29 Nov 2003 14:12:16 +1300
Date: Sat, 29 Nov 2003 14:12:16 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Certificate Policy Standardization
Cc: [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>

=?ISO-8859-1?Q?Michael_Str=F6der?= <[e-mail]> writes:

>I'm not a lawyer and the terms are for sure used much differently in other
>countries. But I also guess that most ToS-style CPs would not withstand a
>court trial based on german AGB-Gesetz, the law regulating "Allgemeine 
>Gesch=E4ftsbedingungen" (similar to ToS).
>
>But since PKI did not hit the mass market yet a CA with such a ToS-style CP
>can assume that this risk is quite low. 
>
>Less RPs => less serious usage => less risks. ;-)

That was the feeling here too.  No-one knows what analysis (e.g.) Telecom's
lawyers went through to come up with their ToS, but certainly for PKI it was
felt that the stakes are so low that it's unlikely anyone will ever bother
testing the CP in court, just as with an ISP no-one will pursue a $100K test
case over a $29.95 account.  So it's not just what's legal, it's what you can
get away with, and since PKI is a legal gray area anyway the balance is
definitely skewed in favour of the large, well-funded incumbent applying
whatever terms they feel like, because any kind of legal challenge is going to
end up as an expensive, uncertain-outcome test case.

I know that there's been some legal analysis of the use of shared-key MACs in
situations where you'd normally expect a PKI to be used, and even though some
of the lawyers could immediately see that it wasn't secure, the feeling was
that the chances of it being successfully challenged in court were negligible.
This is at least in part because of signed (on paper) agreements assigning
responsibility (there are local variations on this, e.g. in the military you
can be ordered to accept the ToS just as they can order you to walk through a
minefield).

Banks got by with simple checksums for some decades without any major legal
problems...

Peter.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAT0S6ib050732 for <[e-mail]>; Fri, 28 Nov 2003 16:28:06 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAT0S6RE050731 for ietf-pkix-bks; Fri, 28 Nov 2003 16:28:06 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from 21cn.com ([61.140.60.52]) by above.proper.com (8.12.10/8.12.8) with SMTP id hAT0S4ib050720 for <[e-mail]>; Fri, 28 Nov 2003 16:28:05 -0800 (PST) (envelope-from [e-mail])
Received: from 21cn.com([127.0.0.1]) by 21cn.com(AIMC 2.9.5.6) with SMTP id jm43fc85a96; Sat, 29 Nov 2003 08:41:58 +0800
Received: from 21cn.com([10.2.1.3]) by 21cn.com(AIMC 2.9.5.4) with SMTP id AISP action; Sat, 29 Nov 2003 08:41:58 +0800
Received: from above.proper.com([127.0.0.1]) by 21cn.com(AIMC 2.9.5.6) with SMTP id jmd93fc3305c; Tue, 25 Nov 2003 10:54:32 +0800
Received: from above.proper.com([208.184.76.39]) by 21cn.com(AIMC 2.9.5.4) with SMTP id AISP action; Tue, 25 Nov 2003 10:54:21 +0800
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAP2fDkT081709 for <[e-mail]>; Mon, 24 Nov 2003 18:41:13 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAP2fDY9081708 for ietf-pkix-bks; Mon, 24 Nov 2003 18:41:13 -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.10/8.12.8) with ESMTP id hAP2fCkT081702 for <[e-mail]>; Mon, 24 Nov 2003 18:41:13 -0800 (PST) (envelope-from [e-mail])
Received: from wchokhani (199.st.louis-24-25rs.mo.dial-access.att.net[12.74.109.199]) by worldnet.att.net (mtiwmhc12) with SMTP id <2003112502410811200rndf2e>; Tue, 25 Nov 2003 02:41:09 +0000
From: "Santosh Chokhani" <[e-mail]>
To: "'Peter Sylvester'" <[e-mail]>, <[e-mail]>
Subject: RE: TSA certificate content
Date: Mon, 24 Nov 2003 21:40:56 -0500
Message-ID: <019601c3b2fd$95508ce0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id hAP2fDkT081704
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-AIMC-AUTH: (null)
X-AIMC-MAILFROM: [e-mail]
X-AIMC-AUTH: (null)
X-AIMC-MAILFROM: [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>

Peter:

Based on a review of 3280 and 3161, I would say that absence of keyUsage
extension is permissible.

3161 requires extended key usage to be present as well as critical.  It also
requires only one key purpose in the extension, that for time stamping.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Peter Sylvester
Sent: Monday, November 24, 2003 8:30 AM
To: [e-mail]
Subject: TSA certificate content




I would like to hear some opinion about the setting
of the extension keyUsage in a certificate for a
3161 TSA. 

The question is whether a certificate contain no
keyUsage extension at all and only an extended
key usage with the appropriate key purpose
is conformant with 3161 and 3280. 

Peter 




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASMWNib047018 for <[e-mail]>; Fri, 28 Nov 2003 14:32:23 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hASMWMdk047017 for ietf-pkix-bks; Fri, 28 Nov 2003 14:32:22 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from sigurd.x509.com ([199.175.155.2]) by above.proper.com (8.12.10/8.12.8) with SMTP id hASMWLib047012 for <[e-mail]>; Fri, 28 Nov 2003 14:32:21 -0800 (PST) (envelope-from [e-mail])
Received: from nebula.x509.com by sigurd.x509.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 28 Nov 2003 22:32:24 UT
Received: from crack.x509.com (localhost [127.0.0.1]) by nebula.x509.com (8.12.10/NULL) with ESMTP id hASMSQ6L029341 for <[e-mail]>; Fri, 28 Nov 2003 14:28:26 -0800 (PST)
Received: from exvan01.x509.com (exvan01.x509.com [10.9.22.50]) by crack.x509.com (8.12.10/8.12.10) with ESMTP id hASMWMY0022881 for <[e-mail]>; Fri, 28 Nov 2003 14:32:22 -0800 (PST)
Received: from rsasecurity.com (mbranchaud2.eng.x509.com [10.7.33.48]) by exvan01.x509.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id VQFWHDZM; Fri, 28 Nov 2003 14:41:14 -0800
Message-ID: <[e-mail]>
Date: Fri, 28 Nov 2003 14:22:42 -0800
X-Sybari-Trust: 2727274c 64c784fd 31d958cc 00000139
From: Marc Branchaud <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031110
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: DISCUSS:  MUST  reject in OCSPv1
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010405000203000207060000"
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.

--------------ms010405000203000207060000
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit


Mike just gave me an offline whack to the head.

I have no objection to the original nonceUnsupported proposal, as 
described in
	http://www.imc.org/ietf-pkix/mail-archive/msg07210.html
including David's "return an error" addition in
	http://www.imc.org/ietf-pkix/mail-archive/msg07214.html

Having clarified my earlier clarification, I wish to reset the 
conversation...

Florian: As we both support the proposal, we may be in danger of violent 
agreement.

Ryan: Your arguments have failed to convince me that the proposal is bad.

Apologies to all for the churn.

		M.


Michael Myers wrote:
> Marc,
> 
> The proposal is to cycle *v1* at Proposed to address this one
> issue.
> We would also take the opportunity to clarify encoding of nonce
> as OCTET STRING, which was going to happen anyway as v1 went
> from
> Proposed to Draft.
> 
> I take it then you have no objection to the core technical
> aspects of the proposed resolution?
> 
> Mike
> 
> 
>>-----Original Message-----
>>From: [e-mail]
>>[mailto:[e-mail]]On Behalf Of
>>Marc Branchaud
>>Sent: Friday, November 28, 2003 10:28 AM
>>To: [e-mail]
>>Subject: Re: DISCUSS: MUST reject in OCSPv1
>>
>>
>>
>>Michael Myers wrote:
>>
>>>Marc, your response was ambiguous.
>>
>>Just to clarify, then:
>>
>>The resolution started with a "big if": Cycling at
>>proposed.  I have no
>>objection to cycling at Proposed and issuing an
>>OCSPv2 that works all
>>this out.
>>
>>It's the "then" I am objecting to.  The proposed
>>"then" is bad.
>>
>>		M.
>>
> 
> 

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISqTCC
AtcwggJAoAMCAQICEFgUQCxch7Sxp7XFFauIqpwwDQYJKoZIhvcNAQEFBQAwbDEaMBgGA1UE
ChMRUlNBIFNlY3VyaXR5IEluYy4xHjAcBgNVBAMTFVJTQSBQdWJsaWMgUm9vdCBDQSB2MTEu
MCwGCSqGSIb3DQEJARYfcnNha2VvbnJvb3RzaWduQHJzYXNlY3VyaXR5LmNvbTAeFw0wMjA5
MDYxNDEzNTJaFw0wNzA5MDYxNDEzNTJaMIGCMRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5j
LjEVMBMGA1UECxMMS0NBIFNlcnZpY2VzMRYwFAYDVQQDEw1SU0EgQ29ycG9yYXRlMRAwDgYD
VQQHEwdCZWRmb3JkMRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMQswCQYDVQQGEwJVUzCBnzAN
BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAqnOw876lPpMTkSqrqzpEON/609PDLEhmWX4tkC19
AHneDaoetL277GtYYXBCggP2E+s66MN1ccWXyApfWjCZkIHepPC08NVI1JRcbViW3kwLzDD2
w5T9QJcyL5V1pN/LQdxahM56TiLeXlPiJekdmTdJoo+5Pw4bQU+MxTqURk8CAwEAAaNjMGEw
HwYDVR0jBBgwFoAU9UwxelEDPyzXi5eZb6hxkKt4PZswHQYDVR0OBBYEFO2RCGt0t1lKkvah
HSJwJp8KrxaSMA8GA1UdEwQIMAYBAf8CAQMwDgYDVR0PAQH/BAQDAgGGMA0GCSqGSIb3DQEB
BQUAA4GBAHiSe1a79hnPr16PuBwUTBWbuNQ4GJNsyfrCXzAswIT2A2WtGZ1Hp1jEAWi9OfAX
IYAdy52Jyv9N87wAEbLUgVmsFEIlYM5mi6ag7YIRGp8JP5UhLAN9O5YHrR9FsrGK4WmSl3sY
W1qAPOXubFcfhTgUDIYzM30izZBP4nwO07FpMIIC+DCCAmGgAwIBAgIQeuiOriTayCwjwpmR
gmdIUjANBgkqhkiG9w0BAQUFADCBgjEaMBgGA1UEChMRUlNBIFNlY3VyaXR5IEluYy4xFTAT
BgNVBAsTDEtDQSBTZXJ2aWNlczEWMBQGA1UEAxMNUlNBIENvcnBvcmF0ZTEQMA4GA1UEBxMH
QmVkZm9yZDEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMwHhcNMDIwOTIz
MTkxMzAzWhcNMDYwOTIzMTUxMzAzWjCBjDEaMBgGA1UEChMRUlNBIFNlY3VyaXR5IEluYy4x
FTATBgNVBAsTDEtDQSBTZXJ2aWNlczEgMB4GA1UEAxMXUlNBIENsYXNzIDIgUGVyc29uYWwg
Q0ExEDAOBgNVBAcTB0JlZGZvcmQxFjAUBgNVBAgTDU1hc3NhY2h1c2V0dHMxCzAJBgNVBAYT
AlVTMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCkR9yiabyRo6+NwC3Sl8wPuUiBD3rP
sENNjXvzSbTAyXA8pDDndnlAa1nLUhSMgvn8g1sYMd0Bp+C1/mI5PFUZ8jukUK95yt+TK26L
hM/M5RUq/EINdDDdWzg9je498K6oGfyWR6ETSJbIrDe5qQcLCABs9E2gVKb7Z/FwFo3C9QID
AQABo2MwYTAPBgNVHRMECDAGAQH/AgECMA4GA1UdDwEB/wQEAwIBhjAfBgNVHSMEGDAWgBTt
kQhrdLdZSpL2oR0icCafCq8WkjAdBgNVHQ4EFgQUxpPuxqX+41WOz4ojH+6Y3iHyn6cwDQYJ
KoZIhvcNAQEFBQADgYEAcdRHBjq8GfdDoutUTJPtSzQd7XsdsQh2KBbu8utl92VQHuI0J5wc
Rc817G8YbmTtCt/xqAzrr6k7fdaoDBr/kBuVHA5FEJ94foPgrOlbT3zdziMATXh5ESSDLMx6
p8ITIsTJNmwszIG5P9AAKJCW48gu1ZZmLXhFbHcYJGf99pwwggMFMIICbqADAgECAhEAvhyf
0s21hKaAc2Nm1WX4LTANBgkqhkiG9w0BAQUFADCBuzEkMCIGA1UEBxMbVmFsaUNlcnQgVmFs
aWRhdGlvbiBOZXR3b3JrMRcwFQYDVQQKEw5WYWxpQ2VydCwgSW5jLjE1MDMGA1UECxMsVmFs
aUNlcnQgQ2xhc3MgMyBQb2xpY3kgVmFsaWRhdGlvbiBBdXRob3JpdHkxITAfBgNVBAMTGGh0
dHA6Ly93d3cudmFsaWNlcnQuY29tLzEgMB4GCSqGSIb3DQEJARYRaW5mb0B2YWxpY2VydC5j
b20wHhcNMDIwNDMwMTUzMDE5WhcNMTkwNDMwMDkyMTU1WjBsMRowGAYDVQQKExFSU0EgU2Vj
dXJpdHkgSW5jLjEeMBwGA1UEAxMVUlNBIFB1YmxpYyBSb290IENBIHYxMS4wLAYJKoZIhvcN
AQkBFh9yc2FrZW9ucm9vdHNpZ25AcnNhc2VjdXJpdHkuY29tMIGfMA0GCSqGSIb3DQEBAQUA
A4GNADCBiQKBgQC0dSVa2EQ740GxqiIKsHATT4f8XYwUU23pzRe5W6IVpt4jkwDWkgnvTcP6
M8PD4OfK6Imal4hAH/c3K/dUIH7YyQZRGAE5Y27G5klZYKidcFlrfautgVES170MLKFmJqym
2FWAfVOibXatRcw7B0S+mP9404jID/MaIpRXkH5JjwIDAQABo1cwVTAMBgNVHRMEBTADAQH/
MA4GA1UdDwEB/wQEAwIBhjAWBgNVHSAEDzANMAsGCSqGSIb3DQUGATAdBgNVHQ4EFgQU9Uwx
elEDPyzXi5eZb6hxkKt4PZswDQYJKoZIhvcNAQEFBQADgYEAKsviXBc1FeBT2hIwyWuGwnPZ
J9ctjrsO7NbVLjsx/EYclFFGwo+pphiwdUTml9yd7fXzfk0D+7LOs9ZA5xhiHVrGusV4OW4i
7hx2KVILkYlcXCN5tDltKwa5+BkGUuvZdyAoIhpyf61h7uKCFguhaJ+VOiNB4DPtsmxI+KxO
E6YwggTYMIIEQaADAgECAhBgzHl9dAoZGu0JMqXovSgdMA0GCSqGSIb3DQEBBQUAMIGMMRow
GAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEVMBMGA1UECxMMS0NBIFNlcnZpY2VzMSAwHgYD
VQQDExdSU0EgQ2xhc3MgMiBQZXJzb25hbCBDQTEQMA4GA1UEBxMHQmVkZm9yZDEWMBQGA1UE
CBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMwHhcNMDMwNzA3MjMwODEzWhcNMDQwNzA3
MjMwODEzWjCBvjETMBEGCgmSJomT8ixkARkWA2NvbTEbMBkGCgmSJomT8ixkARkWC3JzYXNl
Y3VyaXR5MRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEWMBQGA1UECxMNTm9ydGggQW1l
cmljYTEUMBIGA1UECxMLRW5naW5lZXJpbmcxFzAVBgNVBAMTDk1hcmMgQnJhbmNoYXVkMScw
JQYJKoZIhvcNAQkBFhhtYXJjbmFyY0Byc2FzZWN1cml0eS5jb20wggEiMA0GCSqGSIb3DQEB
AQUAA4IBDwAwggEKAoIBAQDg2xoRr+a/dtnuFG+oTHa+tGtzeObFazNhYV2iSLNED4fHRu86
tknBYFgXggcHW5gsyjfkCtVMzP2tCivmbJgvISo36vsCsmAJH6LRnJf8HsvfmWZaD9tzhDpL
QVsBHr88J0ZMdVniRc7MQoYeu/3hYtUBeGO9bGA6T8vTrnXYonnFtVoTqE62SFqPZZk7HpCS
X1n+dM3zSym2ylMFYE14nukF4I9vAhsQVzk3QNpghmzGj8uoEy9xpf3k0o5+neneAGvcSkwo
r1mH5tSqhrEQaZp7vuSA2bvXaZEnjZzZiTpPDzs1oMpn3guzYhU7wMKz6xvwvgEYyAAV+P5n
FWM/AgMBAAGjggGBMIIBfTCBkgYDVR0gBIGKMIGHMIGEBgkqhkiG9w0FBwIwdzAuBggrBgEF
BQcCARYiaHR0cDovL2NhLnJzYXNlY3VyaXR5LmNvbS9DUFMuaHRtbDBFBggrBgEFBQcCAjA5
MBgWEVJTQSBTZWN1cml0eSBJbmMuMAMCAQEaHUNQUyBJbmNvcnBvcmF0ZWQgYnkgcmVmZXJl
bmNlMCkGA1UdJQQiMCAGCisGAQQBgjcUAgIGCCsGAQUFBwMCBggrBgEFBQcDBDAjBgNVHREE
HDAagRhtYXJjbmFyY0Byc2FzZWN1cml0eS5jb20wDgYDVR0PAQH/BAQDAgeAMEYGA1UdHwQ/
MD0wO6A5oDeGNWh0dHA6Ly9jcmwucnNhc2VjdXJpdHkuY29tOjgwL1JTQUNsYXNzMlBlcnNv
bmFsQ0EuY3JsMB8GA1UdIwQYMBaAFMaT7sal/uNVjs+KIx/umN4h8p+nMB0GA1UdDgQWBBQ1
yQ/UrvKb563LjzHqJzBzrZp/ejANBgkqhkiG9w0BAQUFAAOBgQCV82oGGnglQQzklKg/wKhy
evNeJ6FNBZFhLlmZRNlKgqvPFmBcxygfBGpHqIhsHcrt2/AjhJuzAj7UdW1vTVCY5MkZw8P9
6+J6aTc3bNlGbk0jvcvVgDhmM4xYJLwMZKEw92HlRhfuMnj7ah9DTqbKSewmyAyOc+FLpGfd
lu6CgTCCBOkwggRSoAMCAQICEQDqxAXqre9Mr+FeYw3+MQhsMA0GCSqGSIb3DQEBBQUAMIGM
MRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEVMBMGA1UECxMMS0NBIFNlcnZpY2VzMSAw
HgYDVQQDExdSU0EgQ2xhc3MgMiBQZXJzb25hbCBDQTEQMA4GA1UEBxMHQmVkZm9yZDEWMBQG
A1UECBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMwHhcNMDMwNzA3MjMwODI4WhcNMDQw
NzA3MjMwODEzWjCBwjETMBEGCgmSJomT8ixkARkWA2NvbTEbMBkGCgmSJomT8ixkARkWC3Jz
YXNlY3VyaXR5MRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEWMBQGA1UECxMNTm9ydGgg
QW1lcmljYTEUMBIGA1UECxMLRW5naW5lZXJpbmcxGzAZBgNVBAMTEk1hcmMgQnJhbmNoYXVk
LUVuYzEnMCUGCSqGSIb3DQEJARYYbWFyY25hcmNAcnNhc2VjdXJpdHkuY29tMIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwBjNaHTwtCXpdJg+iDxYMkWjuZIF0ic2fRLymZe+
BnZYWPnik0dFmTulx+V8slsLEtBllcc5o1yfIYfeHPinwRxv86kCUSlgfGGXKjJZaIeURgbo
bUbIfDTPlvRUZuiZvTR4C8tEY88Lle66n62B7wjUvDbiwK4EjzlXOkjpcYXLH7FbaFaRLDBB
PlFD5ydDRhQ67t6fjUeS7p7o/l/VHmPC5LFLXZkjEhjGd5pknbQIAbUGACL5UET85NUFPowD
3F47g0GCKEnuOsk2Ra+WHu7honhIxqmOwGnu85V6tW5xscf4dTofWZONQeaD3gSxv8+hcfKN
k9cwjpnUG2xGzwIDAQABo4IBjTCCAYkwNQYDVR0lBC4wLAYKKwYBBAGCNxQCAgYIKwYBBQUH
AwIGCCsGAQUFBwMEBgorBgEEAYI3CgMEMIGSBgNVHSAEgYowgYcwgYQGCSqGSIb3DQUHAjB3
MC4GCCsGAQUFBwIBFiJodHRwOi8vY2EucnNhc2VjdXJpdHkuY29tL0NQUy5odG1sMEUGCCsG
AQUFBwICMDkwGBYRUlNBIFNlY3VyaXR5IEluYy4wAwIBARodQ1BTIEluY29ycG9yYXRlZCBi
eSByZWZlcmVuY2UwIwYDVR0RBBwwGoEYbWFyY25hcmNAcnNhc2VjdXJpdHkuY29tMEYGA1Ud
HwQ/MD0wO6A5oDeGNWh0dHA6Ly9jcmwucnNhc2VjdXJpdHkuY29tOjgwL1JTQUNsYXNzMlBl
cnNvbmFsQ0EuY3JsMB8GA1UdIwQYMBaAFMaT7sal/uNVjs+KIx/umN4h8p+nMB0GA1UdDgQW
BBT/OiMCyY8CPnNBySW1ijJOYhj7ejAOBgNVHQ8BAf8EBAMCAzgwDQYJKoZIhvcNAQEFBQAD
gYEAlchAObA9eVmeiLu0nTU985Fch6v+EZKodUhZUN7dILgd05HorHN9jxBH6XI4/b9ZVvub
Pkpicdc112YbcLYTD2NumVksyNDI7fDaqiszgk1zluXtZJ+HsCt+GIAKCDfOVLECclpGyizq
VjZFEK4Pt9FxPGTnUJEvIKJcAQ24EvgxggPsMIID6AIBATCBoTCBjDEaMBgGA1UEChMRUlNB
IFNlY3VyaXR5IEluYy4xFTATBgNVBAsTDEtDQSBTZXJ2aWNlczEgMB4GA1UEAxMXUlNBIENs
YXNzIDIgUGVyc29uYWwgQ0ExEDAOBgNVBAcTB0JlZGZvcmQxFjAUBgNVBAgTDU1hc3NhY2h1
c2V0dHMxCzAJBgNVBAYTAlVTAhBgzHl9dAoZGu0JMqXovSgdMAkGBSsOAwIaBQCgggIfMBgG
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMTEyODIyMjI0Mlow
IwYJKoZIhvcNAQkEMRYEFOeWdhUAI8/Z16RQ1cLpz067zcIBMFIGCSqGSIb3DQEJDzFFMEMw
CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G
CCqGSIb3DQMCAgEoMIGzBgkrBgEEAYI3EAQxgaUwgaIwgYwxGjAYBgNVBAoTEVJTQSBTZWN1
cml0eSBJbmMuMRUwEwYDVQQLEwxLQ0EgU2VydmljZXMxIDAeBgNVBAMTF1JTQSBDbGFzcyAy
IFBlcnNvbmFsIENBMRAwDgYDVQQHEwdCZWRmb3JkMRYwFAYDVQQIEw1NYXNzYWNodXNldHRz
MQswCQYDVQQGEwJVUwIRAOrEBeqt70yv4V5jDf4xCGwwgbUGCyqGSIb3DQEJEAILMYGloIGi
MIGMMRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEVMBMGA1UECxMMS0NBIFNlcnZpY2Vz
MSAwHgYDVQQDExdSU0EgQ2xhc3MgMiBQZXJzb25hbCBDQTEQMA4GA1UEBxMHQmVkZm9yZDEW
MBQGA1UECBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMCEQDqxAXqre9Mr+FeYw3+MQhs
MA0GCSqGSIb3DQEBAQUABIIBAEOA7UWVRrgh6hvsqy9u96VAGy9h7QTBIjnyqGzdUlUgJJ5T
1Z2ho2zHGe1VARVTrZXPbvUDNnqVfxMXNqWRoNTJ1icKOj5SBX7vylGdsfg/P+eFfSwTPJrt
Zs0neLB3N7nDsubd8F6y1ZKpOZMc4Khwa3SOxHljhVCzE093D/Zdeo292PRuytXEjRY+sg+r
HH3w+fAk0tMZUOdcyeuDuU/J+fBuVCEcTBn1+F5JF1UueXve4JJK0YNMd1iGY5wVS/AbF5KR
FjteFY9XG/VGhuKsk9FkJwTWe0GaxJkF9wgoBfc07lhpqsq/B/LLNy6zjy31UzM1mnRJEqq7
t6svam8AAAAAAAA=
--------------ms010405000203000207060000--


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASLt3ib045514 for <[e-mail]>; Fri, 28 Nov 2003 13:55:03 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hASLt3xY045513 for ietf-pkix-bks; Fri, 28 Nov 2003 13:55:03 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ns.malpani.biz (adsl-63-194-89-166.dsl.snfc21.pacbell.net [63.194.89.166]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASLt3ib045505 for <[e-mail]>; Fri, 28 Nov 2003 13:55:03 -0800 (PST) (envelope-from [e-mail])
Received: from nt1 (nt1.malpani.biz [192.168.25.13]) by ns.malpani.biz (8.12.9/8.12.9) with SMTP id hASLsw2B013456; Fri, 28 Nov 2003 13:54:58 -0800
From: "Ambarish Malpani" <[e-mail]>
To: "Florian Oelmaier" <[e-mail]>, "'Marc Branchaud'" <[e-mail]>, <[e-mail]>
Subject: RE: DISCUSS:  MUST  reject in OCSPv1
Date: Fri, 28 Nov 2003 14:00:55 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <003401c3b544$a6ce5710$4228a8c0@hagen>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
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>

Hi Florian,
    The reason for including a nonce in the request is to enable a
client that doesn't have a very precise knowledge of time to still
be sure the response he got from the server was generated for this
specific request.

While I do agree with Mark and think that the "right" way would be
to require the client to require the nonce in the response, in the
interests of moving ahead, I vote to accept Mike's compromise
proposal that a client MUST require the nonce in the response
unless it is accompanied by a nonceUnsupported extension in
the response and the client is willing to accept a response w/o
a nonce. This preserves the semantics for current clients and
still allows caching servers to supply responses to clients
who will take them.

Regards,
Ambarish



> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Florian Oelmaier
> Sent: Thursday, November 27, 2003 4:15 PM
> To: 'Marc Branchaud'; [e-mail]
> Subject: RE: DISCUSS: MUST reject in OCSPv1
> 
> 
> 
> Your argument is "nonces are only for replay protection". Thats true.
> 
> Now lets discuss WHY a client wants to get replay protection. Seeing
> that we have the three times in the response with a clear semantic, the
> client is not harmed by a replay. So why should a client include a nonce
> into the request?
> 
> There are different reasons for that, but the main reason is: the client
> wants a "fresh" response. Following that path Ryans arguments apply as
> he presented it in his previous replies. A client will include a nonce
> into the request to ask for a "fresh" response. If the client does not
> need a fresh response, then replaying is not a problem (then it is a
> feature called "caching").
> 
> So if a responder gets a request with a nonce, it not only means "the
> client wants replay protection" - it also means "the client would like
> to get a fresh response". Because otherwise replay attacks would not
> matter.
> 
> -- 
> Florian Oelmaier
> SyTrust
> 
> 


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASJv7ib041633 for <[e-mail]>; Fri, 28 Nov 2003 11:57:07 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hASJv7rM041632 for ietf-pkix-bks; Fri, 28 Nov 2003 11:57:07 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout02.sul.t-online.com (mailout02.sul.t-online.com [194.25.134.17]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASJv5ib041627 for <[e-mail]>; Fri, 28 Nov 2003 11:57:06 -0800 (PST) (envelope-from [e-mail])
Received: from fwd09.aul.t-online.de  by mailout02.sul.t-online.com with smtp  id 1APojc-0001Ro-04; Fri, 28 Nov 2003 20:57:00 +0100
Received: from hagen (VmH3uGZageo7MQw7PJsLKHBaJYIe+FCjn-9wbxWpu0zFXBly8yAok5@[217.228.239.148]) by fmrl09.sul.t-online.com with esmtp id 1APojM-1BpdA00; Fri, 28 Nov 2003 20:56:44 +0100
From: "Florian Oelmaier" <[e-mail]>
To: "'Marc Branchaud'" <[e-mail]>, <[e-mail]>
Subject: RE: DISCUSS:  MUST  reject in OCSPv1
Date: Fri, 28 Nov 2003 20:56:41 +0100
Organization: SyTrust
Message-ID: <008201c3b5e9$bea44570$4228a8c0@hagen>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Seen: false
X-ID: [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 agree. But the client behaves differently! It may
> > - display a warning to the user
> 
> Please.

Our client actually does in the default configuration. Sorry that I
(once again) could not live up to your imagination.

> > - apply another local policy regarding time checking
> > - add additional measures to ensure freshness if a nonce is not 
> > present
> > - etc.
> 
> Why not apply those measures in the first place and not 
> bother with the 
> nonce?

Come on. Answer that one for yourself. Those additional measures do not
come at no cost. E.g. contacting a trusted time source costs time. 

> Putting nonces into requests willy-nilly, just in case, is bad design.

Read the above. A response with nonce will trigger another handling than
a response without nonce according to the local policy. 

-- 
Florian Oelmaier
SyTrust




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASIKFib037886 for <[e-mail]>; Fri, 28 Nov 2003 10:20:15 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hASIKFbI037885 for ietf-pkix-bks; Fri, 28 Nov 2003 10:20:15 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASIKDib037877 for <[e-mail]>; Fri, 28 Nov 2003 10:20:13 -0800 (PST) (envelope-from [e-mail])
Received: from MMyersLapTop ([65.39.77.99]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id hASIKDA02796; Fri, 28 Nov 2003 11:20:13 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: "Marc Branchaud" <[e-mail]>, <[e-mail]>
Subject: RE: DISCUSS:  MUST  reject in OCSPv1
Date: Fri, 28 Nov 2003 11:22:24 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <[e-mail]>
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>

Marc,

The proposal is to cycle *v1* at Proposed to address this one
issue.
We would also take the opportunity to clarify encoding of nonce
as OCTET STRING, which was going to happen anyway as v1 went
from
Proposed to Draft.

I take it then you have no objection to the core technical
aspects of the proposed resolution?

Mike

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of
> Marc Branchaud
> Sent: Friday, November 28, 2003 10:28 AM
> To: [e-mail]
> Subject: Re: DISCUSS: MUST reject in OCSPv1
>
>
>
> Michael Myers wrote:
> >
> > Marc, your response was ambiguous.
>
> Just to clarify, then:
>
> The resolution started with a "big if": Cycling at
> proposed.  I have no
> objection to cycling at Proposed and issuing an
> OCSPv2 that works all
> this out.
>
> It's the "then" I am objecting to.  The proposed
> "then" is bad.
>
> 		M.
>



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASI1Qib036385 for <[e-mail]>; Fri, 28 Nov 2003 10:01:26 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hASI1QIS036384 for ietf-pkix-bks; Fri, 28 Nov 2003 10:01:26 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from sigurd.x509.com ([199.175.155.2]) by above.proper.com (8.12.10/8.12.8) with SMTP id hASI1Pib036378 for <[e-mail]>; Fri, 28 Nov 2003 10:01:25 -0800 (PST) (envelope-from [e-mail])
Received: from nebula.x509.com by sigurd.x509.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 28 Nov 2003 18:01:26 UT
Received: from crack.x509.com (localhost [127.0.0.1]) by nebula.x509.com (8.12.10/NULL) with ESMTP id hASHvR6L027037; Fri, 28 Nov 2003 09:57:28 -0800 (PST)
Received: from exvan01.x509.com (exvan01.x509.com [10.9.22.50]) by crack.x509.com (8.12.10/8.12.10) with ESMTP id hASI1NY0014365; Fri, 28 Nov 2003 10:01:23 -0800 (PST)
Received: from rsasecurity.com (mbranchaud2.eng.x509.com [10.7.33.48]) by exvan01.x509.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id VQFWHBBL; Fri, 28 Nov 2003 10:10:15 -0800
Message-ID: <[e-mail]>
Date: Fri, 28 Nov 2003 09:51:44 -0800
X-Sybari-Trust: 30c9fd30 64c784fd 31d958cc 00000139
From: Marc Branchaud <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031110
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: David Engberg <[e-mail]>
CC: [e-mail]
Subject: Re: Digression:  nonces prevent replay?
References: <002101c3b53f$869821b0$4228a8c0@hagen> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040704070706060800040606"
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.

--------------ms040704070706060800040606
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit


Do nonces prevent replay attacks?
Yes, they do.

Do nonces "automatically confer absolute freshness and correctness"?
No, they prevent replay attacks.

Is there a ton of other problems and attacks that nonces don't solve?
Yes, there is.

Should OCSP try to leverage nonces to solve these other problems?
No, it shouldn't.

		M.


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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISqTCC
AtcwggJAoAMCAQICEFgUQCxch7Sxp7XFFauIqpwwDQYJKoZIhvcNAQEFBQAwbDEaMBgGA1UE
ChMRUlNBIFNlY3VyaXR5IEluYy4xHjAcBgNVBAMTFVJTQSBQdWJsaWMgUm9vdCBDQSB2MTEu
MCwGCSqGSIb3DQEJARYfcnNha2VvbnJvb3RzaWduQHJzYXNlY3VyaXR5LmNvbTAeFw0wMjA5
MDYxNDEzNTJaFw0wNzA5MDYxNDEzNTJaMIGCMRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5j
LjEVMBMGA1UECxMMS0NBIFNlcnZpY2VzMRYwFAYDVQQDEw1SU0EgQ29ycG9yYXRlMRAwDgYD
VQQHEwdCZWRmb3JkMRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMQswCQYDVQQGEwJVUzCBnzAN
BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAqnOw876lPpMTkSqrqzpEON/609PDLEhmWX4tkC19
AHneDaoetL277GtYYXBCggP2E+s66MN1ccWXyApfWjCZkIHepPC08NVI1JRcbViW3kwLzDD2
w5T9QJcyL5V1pN/LQdxahM56TiLeXlPiJekdmTdJoo+5Pw4bQU+MxTqURk8CAwEAAaNjMGEw
HwYDVR0jBBgwFoAU9UwxelEDPyzXi5eZb6hxkKt4PZswHQYDVR0OBBYEFO2RCGt0t1lKkvah
HSJwJp8KrxaSMA8GA1UdEwQIMAYBAf8CAQMwDgYDVR0PAQH/BAQDAgGGMA0GCSqGSIb3DQEB
BQUAA4GBAHiSe1a79hnPr16PuBwUTBWbuNQ4GJNsyfrCXzAswIT2A2WtGZ1Hp1jEAWi9OfAX
IYAdy52Jyv9N87wAEbLUgVmsFEIlYM5mi6ag7YIRGp8JP5UhLAN9O5YHrR9FsrGK4WmSl3sY
W1qAPOXubFcfhTgUDIYzM30izZBP4nwO07FpMIIC+DCCAmGgAwIBAgIQeuiOriTayCwjwpmR
gmdIUjANBgkqhkiG9w0BAQUFADCBgjEaMBgGA1UEChMRUlNBIFNlY3VyaXR5IEluYy4xFTAT
BgNVBAsTDEtDQSBTZXJ2aWNlczEWMBQGA1UEAxMNUlNBIENvcnBvcmF0ZTEQMA4GA1UEBxMH
QmVkZm9yZDEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMwHhcNMDIwOTIz
MTkxMzAzWhcNMDYwOTIzMTUxMzAzWjCBjDEaMBgGA1UEChMRUlNBIFNlY3VyaXR5IEluYy4x
FTATBgNVBAsTDEtDQSBTZXJ2aWNlczEgMB4GA1UEAxMXUlNBIENsYXNzIDIgUGVyc29uYWwg
Q0ExEDAOBgNVBAcTB0JlZGZvcmQxFjAUBgNVBAgTDU1hc3NhY2h1c2V0dHMxCzAJBgNVBAYT
AlVTMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCkR9yiabyRo6+NwC3Sl8wPuUiBD3rP
sENNjXvzSbTAyXA8pDDndnlAa1nLUhSMgvn8g1sYMd0Bp+C1/mI5PFUZ8jukUK95yt+TK26L
hM/M5RUq/EINdDDdWzg9je498K6oGfyWR6ETSJbIrDe5qQcLCABs9E2gVKb7Z/FwFo3C9QID
AQABo2MwYTAPBgNVHRMECDAGAQH/AgECMA4GA1UdDwEB/wQEAwIBhjAfBgNVHSMEGDAWgBTt
kQhrdLdZSpL2oR0icCafCq8WkjAdBgNVHQ4EFgQUxpPuxqX+41WOz4ojH+6Y3iHyn6cwDQYJ
KoZIhvcNAQEFBQADgYEAcdRHBjq8GfdDoutUTJPtSzQd7XsdsQh2KBbu8utl92VQHuI0J5wc
Rc817G8YbmTtCt/xqAzrr6k7fdaoDBr/kBuVHA5FEJ94foPgrOlbT3zdziMATXh5ESSDLMx6
p8ITIsTJNmwszIG5P9AAKJCW48gu1ZZmLXhFbHcYJGf99pwwggMFMIICbqADAgECAhEAvhyf
0s21hKaAc2Nm1WX4LTANBgkqhkiG9w0BAQUFADCBuzEkMCIGA1UEBxMbVmFsaUNlcnQgVmFs
aWRhdGlvbiBOZXR3b3JrMRcwFQYDVQQKEw5WYWxpQ2VydCwgSW5jLjE1MDMGA1UECxMsVmFs
aUNlcnQgQ2xhc3MgMyBQb2xpY3kgVmFsaWRhdGlvbiBBdXRob3JpdHkxITAfBgNVBAMTGGh0
dHA6Ly93d3cudmFsaWNlcnQuY29tLzEgMB4GCSqGSIb3DQEJARYRaW5mb0B2YWxpY2VydC5j
b20wHhcNMDIwNDMwMTUzMDE5WhcNMTkwNDMwMDkyMTU1WjBsMRowGAYDVQQKExFSU0EgU2Vj
dXJpdHkgSW5jLjEeMBwGA1UEAxMVUlNBIFB1YmxpYyBSb290IENBIHYxMS4wLAYJKoZIhvcN
AQkBFh9yc2FrZW9ucm9vdHNpZ25AcnNhc2VjdXJpdHkuY29tMIGfMA0GCSqGSIb3DQEBAQUA
A4GNADCBiQKBgQC0dSVa2EQ740GxqiIKsHATT4f8XYwUU23pzRe5W6IVpt4jkwDWkgnvTcP6
M8PD4OfK6Imal4hAH/c3K/dUIH7YyQZRGAE5Y27G5klZYKidcFlrfautgVES170MLKFmJqym
2FWAfVOibXatRcw7B0S+mP9404jID/MaIpRXkH5JjwIDAQABo1cwVTAMBgNVHRMEBTADAQH/
MA4GA1UdDwEB/wQEAwIBhjAWBgNVHSAEDzANMAsGCSqGSIb3DQUGATAdBgNVHQ4EFgQU9Uwx
elEDPyzXi5eZb6hxkKt4PZswDQYJKoZIhvcNAQEFBQADgYEAKsviXBc1FeBT2hIwyWuGwnPZ
J9ctjrsO7NbVLjsx/EYclFFGwo+pphiwdUTml9yd7fXzfk0D+7LOs9ZA5xhiHVrGusV4OW4i
7hx2KVILkYlcXCN5tDltKwa5+BkGUuvZdyAoIhpyf61h7uKCFguhaJ+VOiNB4DPtsmxI+KxO
E6YwggTYMIIEQaADAgECAhBgzHl9dAoZGu0JMqXovSgdMA0GCSqGSIb3DQEBBQUAMIGMMRow
GAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEVMBMGA1UECxMMS0NBIFNlcnZpY2VzMSAwHgYD
VQQDExdSU0EgQ2xhc3MgMiBQZXJzb25hbCBDQTEQMA4GA1UEBxMHQmVkZm9yZDEWMBQGA1UE
CBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMwHhcNMDMwNzA3MjMwODEzWhcNMDQwNzA3
MjMwODEzWjCBvjETMBEGCgmSJomT8ixkARkWA2NvbTEbMBkGCgmSJomT8ixkARkWC3JzYXNl
Y3VyaXR5MRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEWMBQGA1UECxMNTm9ydGggQW1l
cmljYTEUMBIGA1UECxMLRW5naW5lZXJpbmcxFzAVBgNVBAMTDk1hcmMgQnJhbmNoYXVkMScw
JQYJKoZIhvcNAQkBFhhtYXJjbmFyY0Byc2FzZWN1cml0eS5jb20wggEiMA0GCSqGSIb3DQEB
AQUAA4IBDwAwggEKAoIBAQDg2xoRr+a/dtnuFG+oTHa+tGtzeObFazNhYV2iSLNED4fHRu86
tknBYFgXggcHW5gsyjfkCtVMzP2tCivmbJgvISo36vsCsmAJH6LRnJf8HsvfmWZaD9tzhDpL
QVsBHr88J0ZMdVniRc7MQoYeu/3hYtUBeGO9bGA6T8vTrnXYonnFtVoTqE62SFqPZZk7HpCS
X1n+dM3zSym2ylMFYE14nukF4I9vAhsQVzk3QNpghmzGj8uoEy9xpf3k0o5+neneAGvcSkwo
r1mH5tSqhrEQaZp7vuSA2bvXaZEnjZzZiTpPDzs1oMpn3guzYhU7wMKz6xvwvgEYyAAV+P5n
FWM/AgMBAAGjggGBMIIBfTCBkgYDVR0gBIGKMIGHMIGEBgkqhkiG9w0FBwIwdzAuBggrBgEF
BQcCARYiaHR0cDovL2NhLnJzYXNlY3VyaXR5LmNvbS9DUFMuaHRtbDBFBggrBgEFBQcCAjA5
MBgWEVJTQSBTZWN1cml0eSBJbmMuMAMCAQEaHUNQUyBJbmNvcnBvcmF0ZWQgYnkgcmVmZXJl
bmNlMCkGA1UdJQQiMCAGCisGAQQBgjcUAgIGCCsGAQUFBwMCBggrBgEFBQcDBDAjBgNVHREE
HDAagRhtYXJjbmFyY0Byc2FzZWN1cml0eS5jb20wDgYDVR0PAQH/BAQDAgeAMEYGA1UdHwQ/
MD0wO6A5oDeGNWh0dHA6Ly9jcmwucnNhc2VjdXJpdHkuY29tOjgwL1JTQUNsYXNzMlBlcnNv
bmFsQ0EuY3JsMB8GA1UdIwQYMBaAFMaT7sal/uNVjs+KIx/umN4h8p+nMB0GA1UdDgQWBBQ1
yQ/UrvKb563LjzHqJzBzrZp/ejANBgkqhkiG9w0BAQUFAAOBgQCV82oGGnglQQzklKg/wKhy
evNeJ6FNBZFhLlmZRNlKgqvPFmBcxygfBGpHqIhsHcrt2/AjhJuzAj7UdW1vTVCY5MkZw8P9
6+J6aTc3bNlGbk0jvcvVgDhmM4xYJLwMZKEw92HlRhfuMnj7ah9DTqbKSewmyAyOc+FLpGfd
lu6CgTCCBOkwggRSoAMCAQICEQDqxAXqre9Mr+FeYw3+MQhsMA0GCSqGSIb3DQEBBQUAMIGM
MRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEVMBMGA1UECxMMS0NBIFNlcnZpY2VzMSAw
HgYDVQQDExdSU0EgQ2xhc3MgMiBQZXJzb25hbCBDQTEQMA4GA1UEBxMHQmVkZm9yZDEWMBQG
A1UECBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMwHhcNMDMwNzA3MjMwODI4WhcNMDQw
NzA3MjMwODEzWjCBwjETMBEGCgmSJomT8ixkARkWA2NvbTEbMBkGCgmSJomT8ixkARkWC3Jz
YXNlY3VyaXR5MRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEWMBQGA1UECxMNTm9ydGgg
QW1lcmljYTEUMBIGA1UECxMLRW5naW5lZXJpbmcxGzAZBgNVBAMTEk1hcmMgQnJhbmNoYXVk
LUVuYzEnMCUGCSqGSIb3DQEJARYYbWFyY25hcmNAcnNhc2VjdXJpdHkuY29tMIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwBjNaHTwtCXpdJg+iDxYMkWjuZIF0ic2fRLymZe+
BnZYWPnik0dFmTulx+V8slsLEtBllcc5o1yfIYfeHPinwRxv86kCUSlgfGGXKjJZaIeURgbo
bUbIfDTPlvRUZuiZvTR4C8tEY88Lle66n62B7wjUvDbiwK4EjzlXOkjpcYXLH7FbaFaRLDBB
PlFD5ydDRhQ67t6fjUeS7p7o/l/VHmPC5LFLXZkjEhjGd5pknbQIAbUGACL5UET85NUFPowD
3F47g0GCKEnuOsk2Ra+WHu7honhIxqmOwGnu85V6tW5xscf4dTofWZONQeaD3gSxv8+hcfKN
k9cwjpnUG2xGzwIDAQABo4IBjTCCAYkwNQYDVR0lBC4wLAYKKwYBBAGCNxQCAgYIKwYBBQUH
AwIGCCsGAQUFBwMEBgorBgEEAYI3CgMEMIGSBgNVHSAEgYowgYcwgYQGCSqGSIb3DQUHAjB3
MC4GCCsGAQUFBwIBFiJodHRwOi8vY2EucnNhc2VjdXJpdHkuY29tL0NQUy5odG1sMEUGCCsG
AQUFBwICMDkwGBYRUlNBIFNlY3VyaXR5IEluYy4wAwIBARodQ1BTIEluY29ycG9yYXRlZCBi
eSByZWZlcmVuY2UwIwYDVR0RBBwwGoEYbWFyY25hcmNAcnNhc2VjdXJpdHkuY29tMEYGA1Ud
HwQ/MD0wO6A5oDeGNWh0dHA6Ly9jcmwucnNhc2VjdXJpdHkuY29tOjgwL1JTQUNsYXNzMlBl
cnNvbmFsQ0EuY3JsMB8GA1UdIwQYMBaAFMaT7sal/uNVjs+KIx/umN4h8p+nMB0GA1UdDgQW
BBT/OiMCyY8CPnNBySW1ijJOYhj7ejAOBgNVHQ8BAf8EBAMCAzgwDQYJKoZIhvcNAQEFBQAD
gYEAlchAObA9eVmeiLu0nTU985Fch6v+EZKodUhZUN7dILgd05HorHN9jxBH6XI4/b9ZVvub
Pkpicdc112YbcLYTD2NumVksyNDI7fDaqiszgk1zluXtZJ+HsCt+GIAKCDfOVLECclpGyizq
VjZFEK4Pt9FxPGTnUJEvIKJcAQ24EvgxggPsMIID6AIBATCBoTCBjDEaMBgGA1UEChMRUlNB
IFNlY3VyaXR5IEluYy4xFTATBgNVBAsTDEtDQSBTZXJ2aWNlczEgMB4GA1UEAxMXUlNBIENs
YXNzIDIgUGVyc29uYWwgQ0ExEDAOBgNVBAcTB0JlZGZvcmQxFjAUBgNVBAgTDU1hc3NhY2h1
c2V0dHMxCzAJBgNVBAYTAlVTAhBgzHl9dAoZGu0JMqXovSgdMAkGBSsOAwIaBQCgggIfMBgG
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMTEyODE3NTE0NFow
IwYJKoZIhvcNAQkEMRYEFNNlbyz96IzUiLETJWorifRPQyWQMFIGCSqGSIb3DQEJDzFFMEMw
CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G
CCqGSIb3DQMCAgEoMIGzBgkrBgEEAYI3EAQxgaUwgaIwgYwxGjAYBgNVBAoTEVJTQSBTZWN1
cml0eSBJbmMuMRUwEwYDVQQLEwxLQ0EgU2VydmljZXMxIDAeBgNVBAMTF1JTQSBDbGFzcyAy
IFBlcnNvbmFsIENBMRAwDgYDVQQHEwdCZWRmb3JkMRYwFAYDVQQIEw1NYXNzYWNodXNldHRz
MQswCQYDVQQGEwJVUwIRAOrEBeqt70yv4V5jDf4xCGwwgbUGCyqGSIb3DQEJEAILMYGloIGi
MIGMMRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEVMBMGA1UECxMMS0NBIFNlcnZpY2Vz
MSAwHgYDVQQDExdSU0EgQ2xhc3MgMiBQZXJzb25hbCBDQTEQMA4GA1UEBxMHQmVkZm9yZDEW
MBQGA1UECBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMCEQDqxAXqre9Mr+FeYw3+MQhs
MA0GCSqGSIb3DQEBAQUABIIBAGBphkSSdVpTzVya5wtaxCPRlV/aIG2Kyyx+Nu8SZKQ+l0QG
AyCyaXcCkNddureNIDftdbxf8ZQsgq/JoLa2meVVzeXwWJxRs8RmoYG5eL3A9v/+m99Sumfj
Y5bkxDZd8tiUhjreiXsiGeV7Ol3sTq/f4bTfnxL1CI38tdz8fX2h8e3IzWTVx/Ws4bDpbUog
RT5rGcyLfN5WkyTzTw6PdEricNDyfxzM0palQey3xSE5qrN1NZjkjBoEiNZdGy/Qxlofy37o
rREuuOT/Qmlne2ABYovrETr3H4j12ahl7ntIkbnAeA5Fp+kD0HBGS4LKsKQLAUmPTGMUqc/d
ZPjWQXQAAAAAAAA=
--------------ms040704070706060800040606--


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASHnlib034188 for <[e-mail]>; Fri, 28 Nov 2003 09:49:47 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hASHnlo9034186 for ietf-pkix-bks; Fri, 28 Nov 2003 09:49:47 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from sigurd.x509.com ([199.175.155.2]) by above.proper.com (8.12.10/8.12.8) with SMTP id hASHnjib034159 for <[e-mail]>; Fri, 28 Nov 2003 09:49:45 -0800 (PST) (envelope-from [e-mail])
Received: from nebula.x509.com by sigurd.x509.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 28 Nov 2003 17:49:47 UT
Received: from crack.x509.com (localhost [127.0.0.1]) by nebula.x509.com (8.12.10/NULL) with ESMTP id hASHjn6L026953; Fri, 28 Nov 2003 09:45:49 -0800 (PST)
Received: from exvan01.x509.com (exvan01.x509.com [10.9.22.50]) by crack.x509.com (8.12.10/8.12.10) with ESMTP id hASHnkY0014162; Fri, 28 Nov 2003 09:49:46 -0800 (PST)
Received: from rsasecurity.com (mbranchaud2.eng.x509.com [10.7.33.48]) by exvan01.x509.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id VQFWHA00; Fri, 28 Nov 2003 09:58:37 -0800
Message-ID: <[e-mail]>
Date: Fri, 28 Nov 2003 09:40:06 -0800
X-Sybari-Trust: 33ce4df3 64c784fd 31d958cc 00000139
From: Marc Branchaud <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031110
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Ryan M. Hurst" <[e-mail]>
CC: [e-mail]
Subject: Re: DISCUSS:  MUST  reject in OCSPv1
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070106080409010800080000"
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.

--------------ms070106080409010800080000
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Ryan M. Hurst wrote:
> 
> [rmh] The question is does it want it or does it need it, in the case I 
> gave the bookstore.com server would be happy with any response thats not 
> expired; maybe the pre-production responder already has one that meets 
> that criteria.

If the client doesn't need it, then it shouldn't use it.  To do 
otherwise makes for a bad protocol.

		M.

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISqTCC
AtcwggJAoAMCAQICEFgUQCxch7Sxp7XFFauIqpwwDQYJKoZIhvcNAQEFBQAwbDEaMBgGA1UE
ChMRUlNBIFNlY3VyaXR5IEluYy4xHjAcBgNVBAMTFVJTQSBQdWJsaWMgUm9vdCBDQSB2MTEu
MCwGCSqGSIb3DQEJARYfcnNha2VvbnJvb3RzaWduQHJzYXNlY3VyaXR5LmNvbTAeFw0wMjA5
MDYxNDEzNTJaFw0wNzA5MDYxNDEzNTJaMIGCMRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5j
LjEVMBMGA1UECxMMS0NBIFNlcnZpY2VzMRYwFAYDVQQDEw1SU0EgQ29ycG9yYXRlMRAwDgYD
VQQHEwdCZWRmb3JkMRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMQswCQYDVQQGEwJVUzCBnzAN
BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAqnOw876lPpMTkSqrqzpEON/609PDLEhmWX4tkC19
AHneDaoetL277GtYYXBCggP2E+s66MN1ccWXyApfWjCZkIHepPC08NVI1JRcbViW3kwLzDD2
w5T9QJcyL5V1pN/LQdxahM56TiLeXlPiJekdmTdJoo+5Pw4bQU+MxTqURk8CAwEAAaNjMGEw
HwYDVR0jBBgwFoAU9UwxelEDPyzXi5eZb6hxkKt4PZswHQYDVR0OBBYEFO2RCGt0t1lKkvah
HSJwJp8KrxaSMA8GA1UdEwQIMAYBAf8CAQMwDgYDVR0PAQH/BAQDAgGGMA0GCSqGSIb3DQEB
BQUAA4GBAHiSe1a79hnPr16PuBwUTBWbuNQ4GJNsyfrCXzAswIT2A2WtGZ1Hp1jEAWi9OfAX
IYAdy52Jyv9N87wAEbLUgVmsFEIlYM5mi6ag7YIRGp8JP5UhLAN9O5YHrR9FsrGK4WmSl3sY
W1qAPOXubFcfhTgUDIYzM30izZBP4nwO07FpMIIC+DCCAmGgAwIBAgIQeuiOriTayCwjwpmR
gmdIUjANBgkqhkiG9w0BAQUFADCBgjEaMBgGA1UEChMRUlNBIFNlY3VyaXR5IEluYy4xFTAT
BgNVBAsTDEtDQSBTZXJ2aWNlczEWMBQGA1UEAxMNUlNBIENvcnBvcmF0ZTEQMA4GA1UEBxMH
QmVkZm9yZDEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMwHhcNMDIwOTIz
MTkxMzAzWhcNMDYwOTIzMTUxMzAzWjCBjDEaMBgGA1UEChMRUlNBIFNlY3VyaXR5IEluYy4x
FTATBgNVBAsTDEtDQSBTZXJ2aWNlczEgMB4GA1UEAxMXUlNBIENsYXNzIDIgUGVyc29uYWwg
Q0ExEDAOBgNVBAcTB0JlZGZvcmQxFjAUBgNVBAgTDU1hc3NhY2h1c2V0dHMxCzAJBgNVBAYT
AlVTMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCkR9yiabyRo6+NwC3Sl8wPuUiBD3rP
sENNjXvzSbTAyXA8pDDndnlAa1nLUhSMgvn8g1sYMd0Bp+C1/mI5PFUZ8jukUK95yt+TK26L
hM/M5RUq/EINdDDdWzg9je498K6oGfyWR6ETSJbIrDe5qQcLCABs9E2gVKb7Z/FwFo3C9QID
AQABo2MwYTAPBgNVHRMECDAGAQH/AgECMA4GA1UdDwEB/wQEAwIBhjAfBgNVHSMEGDAWgBTt
kQhrdLdZSpL2oR0icCafCq8WkjAdBgNVHQ4EFgQUxpPuxqX+41WOz4ojH+6Y3iHyn6cwDQYJ
KoZIhvcNAQEFBQADgYEAcdRHBjq8GfdDoutUTJPtSzQd7XsdsQh2KBbu8utl92VQHuI0J5wc
Rc817G8YbmTtCt/xqAzrr6k7fdaoDBr/kBuVHA5FEJ94foPgrOlbT3zdziMATXh5ESSDLMx6
p8ITIsTJNmwszIG5P9AAKJCW48gu1ZZmLXhFbHcYJGf99pwwggMFMIICbqADAgECAhEAvhyf
0s21hKaAc2Nm1WX4LTANBgkqhkiG9w0BAQUFADCBuzEkMCIGA1UEBxMbVmFsaUNlcnQgVmFs
aWRhdGlvbiBOZXR3b3JrMRcwFQYDVQQKEw5WYWxpQ2VydCwgSW5jLjE1MDMGA1UECxMsVmFs
aUNlcnQgQ2xhc3MgMyBQb2xpY3kgVmFsaWRhdGlvbiBBdXRob3JpdHkxITAfBgNVBAMTGGh0
dHA6Ly93d3cudmFsaWNlcnQuY29tLzEgMB4GCSqGSIb3DQEJARYRaW5mb0B2YWxpY2VydC5j
b20wHhcNMDIwNDMwMTUzMDE5WhcNMTkwNDMwMDkyMTU1WjBsMRowGAYDVQQKExFSU0EgU2Vj
dXJpdHkgSW5jLjEeMBwGA1UEAxMVUlNBIFB1YmxpYyBSb290IENBIHYxMS4wLAYJKoZIhvcN
AQkBFh9yc2FrZW9ucm9vdHNpZ25AcnNhc2VjdXJpdHkuY29tMIGfMA0GCSqGSIb3DQEBAQUA
A4GNADCBiQKBgQC0dSVa2EQ740GxqiIKsHATT4f8XYwUU23pzRe5W6IVpt4jkwDWkgnvTcP6
M8PD4OfK6Imal4hAH/c3K/dUIH7YyQZRGAE5Y27G5klZYKidcFlrfautgVES170MLKFmJqym
2FWAfVOibXatRcw7B0S+mP9404jID/MaIpRXkH5JjwIDAQABo1cwVTAMBgNVHRMEBTADAQH/
MA4GA1UdDwEB/wQEAwIBhjAWBgNVHSAEDzANMAsGCSqGSIb3DQUGATAdBgNVHQ4EFgQU9Uwx
elEDPyzXi5eZb6hxkKt4PZswDQYJKoZIhvcNAQEFBQADgYEAKsviXBc1FeBT2hIwyWuGwnPZ
J9ctjrsO7NbVLjsx/EYclFFGwo+pphiwdUTml9yd7fXzfk0D+7LOs9ZA5xhiHVrGusV4OW4i
7hx2KVILkYlcXCN5tDltKwa5+BkGUuvZdyAoIhpyf61h7uKCFguhaJ+VOiNB4DPtsmxI+KxO
E6YwggTYMIIEQaADAgECAhBgzHl9dAoZGu0JMqXovSgdMA0GCSqGSIb3DQEBBQUAMIGMMRow
GAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEVMBMGA1UECxMMS0NBIFNlcnZpY2VzMSAwHgYD
VQQDExdSU0EgQ2xhc3MgMiBQZXJzb25hbCBDQTEQMA4GA1UEBxMHQmVkZm9yZDEWMBQGA1UE
CBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMwHhcNMDMwNzA3MjMwODEzWhcNMDQwNzA3
MjMwODEzWjCBvjETMBEGCgmSJomT8ixkARkWA2NvbTEbMBkGCgmSJomT8ixkARkWC3JzYXNl
Y3VyaXR5MRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEWMBQGA1UECxMNTm9ydGggQW1l
cmljYTEUMBIGA1UECxMLRW5naW5lZXJpbmcxFzAVBgNVBAMTDk1hcmMgQnJhbmNoYXVkMScw
JQYJKoZIhvcNAQkBFhhtYXJjbmFyY0Byc2FzZWN1cml0eS5jb20wggEiMA0GCSqGSIb3DQEB
AQUAA4IBDwAwggEKAoIBAQDg2xoRr+a/dtnuFG+oTHa+tGtzeObFazNhYV2iSLNED4fHRu86
tknBYFgXggcHW5gsyjfkCtVMzP2tCivmbJgvISo36vsCsmAJH6LRnJf8HsvfmWZaD9tzhDpL
QVsBHr88J0ZMdVniRc7MQoYeu/3hYtUBeGO9bGA6T8vTrnXYonnFtVoTqE62SFqPZZk7HpCS
X1n+dM3zSym2ylMFYE14nukF4I9vAhsQVzk3QNpghmzGj8uoEy9xpf3k0o5+neneAGvcSkwo
r1mH5tSqhrEQaZp7vuSA2bvXaZEnjZzZiTpPDzs1oMpn3guzYhU7wMKz6xvwvgEYyAAV+P5n
FWM/AgMBAAGjggGBMIIBfTCBkgYDVR0gBIGKMIGHMIGEBgkqhkiG9w0FBwIwdzAuBggrBgEF
BQcCARYiaHR0cDovL2NhLnJzYXNlY3VyaXR5LmNvbS9DUFMuaHRtbDBFBggrBgEFBQcCAjA5
MBgWEVJTQSBTZWN1cml0eSBJbmMuMAMCAQEaHUNQUyBJbmNvcnBvcmF0ZWQgYnkgcmVmZXJl
bmNlMCkGA1UdJQQiMCAGCisGAQQBgjcUAgIGCCsGAQUFBwMCBggrBgEFBQcDBDAjBgNVHREE
HDAagRhtYXJjbmFyY0Byc2FzZWN1cml0eS5jb20wDgYDVR0PAQH/BAQDAgeAMEYGA1UdHwQ/
MD0wO6A5oDeGNWh0dHA6Ly9jcmwucnNhc2VjdXJpdHkuY29tOjgwL1JTQUNsYXNzMlBlcnNv
bmFsQ0EuY3JsMB8GA1UdIwQYMBaAFMaT7sal/uNVjs+KIx/umN4h8p+nMB0GA1UdDgQWBBQ1
yQ/UrvKb563LjzHqJzBzrZp/ejANBgkqhkiG9w0BAQUFAAOBgQCV82oGGnglQQzklKg/wKhy
evNeJ6FNBZFhLlmZRNlKgqvPFmBcxygfBGpHqIhsHcrt2/AjhJuzAj7UdW1vTVCY5MkZw8P9
6+J6aTc3bNlGbk0jvcvVgDhmM4xYJLwMZKEw92HlRhfuMnj7ah9DTqbKSewmyAyOc+FLpGfd
lu6CgTCCBOkwggRSoAMCAQICEQDqxAXqre9Mr+FeYw3+MQhsMA0GCSqGSIb3DQEBBQUAMIGM
MRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEVMBMGA1UECxMMS0NBIFNlcnZpY2VzMSAw
HgYDVQQDExdSU0EgQ2xhc3MgMiBQZXJzb25hbCBDQTEQMA4GA1UEBxMHQmVkZm9yZDEWMBQG
A1UECBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMwHhcNMDMwNzA3MjMwODI4WhcNMDQw
NzA3MjMwODEzWjCBwjETMBEGCgmSJomT8ixkARkWA2NvbTEbMBkGCgmSJomT8ixkARkWC3Jz
YXNlY3VyaXR5MRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEWMBQGA1UECxMNTm9ydGgg
QW1lcmljYTEUMBIGA1UECxMLRW5naW5lZXJpbmcxGzAZBgNVBAMTEk1hcmMgQnJhbmNoYXVk
LUVuYzEnMCUGCSqGSIb3DQEJARYYbWFyY25hcmNAcnNhc2VjdXJpdHkuY29tMIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwBjNaHTwtCXpdJg+iDxYMkWjuZIF0ic2fRLymZe+
BnZYWPnik0dFmTulx+V8slsLEtBllcc5o1yfIYfeHPinwRxv86kCUSlgfGGXKjJZaIeURgbo
bUbIfDTPlvRUZuiZvTR4C8tEY88Lle66n62B7wjUvDbiwK4EjzlXOkjpcYXLH7FbaFaRLDBB
PlFD5ydDRhQ67t6fjUeS7p7o/l/VHmPC5LFLXZkjEhjGd5pknbQIAbUGACL5UET85NUFPowD
3F47g0GCKEnuOsk2Ra+WHu7honhIxqmOwGnu85V6tW5xscf4dTofWZONQeaD3gSxv8+hcfKN
k9cwjpnUG2xGzwIDAQABo4IBjTCCAYkwNQYDVR0lBC4wLAYKKwYBBAGCNxQCAgYIKwYBBQUH
AwIGCCsGAQUFBwMEBgorBgEEAYI3CgMEMIGSBgNVHSAEgYowgYcwgYQGCSqGSIb3DQUHAjB3
MC4GCCsGAQUFBwIBFiJodHRwOi8vY2EucnNhc2VjdXJpdHkuY29tL0NQUy5odG1sMEUGCCsG
AQUFBwICMDkwGBYRUlNBIFNlY3VyaXR5IEluYy4wAwIBARodQ1BTIEluY29ycG9yYXRlZCBi
eSByZWZlcmVuY2UwIwYDVR0RBBwwGoEYbWFyY25hcmNAcnNhc2VjdXJpdHkuY29tMEYGA1Ud
HwQ/MD0wO6A5oDeGNWh0dHA6Ly9jcmwucnNhc2VjdXJpdHkuY29tOjgwL1JTQUNsYXNzMlBl
cnNvbmFsQ0EuY3JsMB8GA1UdIwQYMBaAFMaT7sal/uNVjs+KIx/umN4h8p+nMB0GA1UdDgQW
BBT/OiMCyY8CPnNBySW1ijJOYhj7ejAOBgNVHQ8BAf8EBAMCAzgwDQYJKoZIhvcNAQEFBQAD
gYEAlchAObA9eVmeiLu0nTU985Fch6v+EZKodUhZUN7dILgd05HorHN9jxBH6XI4/b9ZVvub
Pkpicdc112YbcLYTD2NumVksyNDI7fDaqiszgk1zluXtZJ+HsCt+GIAKCDfOVLECclpGyizq
VjZFEK4Pt9FxPGTnUJEvIKJcAQ24EvgxggPsMIID6AIBATCBoTCBjDEaMBgGA1UEChMRUlNB
IFNlY3VyaXR5IEluYy4xFTATBgNVBAsTDEtDQSBTZXJ2aWNlczEgMB4GA1UEAxMXUlNBIENs
YXNzIDIgUGVyc29uYWwgQ0ExEDAOBgNVBAcTB0JlZGZvcmQxFjAUBgNVBAgTDU1hc3NhY2h1
c2V0dHMxCzAJBgNVBAYTAlVTAhBgzHl9dAoZGu0JMqXovSgdMAkGBSsOAwIaBQCgggIfMBgG
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMTEyODE3NDAwNlow
IwYJKoZIhvcNAQkEMRYEFDSG7Kk4FAZQAn6QdaUu0fgkCCmJMFIGCSqGSIb3DQEJDzFFMEMw
CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G
CCqGSIb3DQMCAgEoMIGzBgkrBgEEAYI3EAQxgaUwgaIwgYwxGjAYBgNVBAoTEVJTQSBTZWN1
cml0eSBJbmMuMRUwEwYDVQQLEwxLQ0EgU2VydmljZXMxIDAeBgNVBAMTF1JTQSBDbGFzcyAy
IFBlcnNvbmFsIENBMRAwDgYDVQQHEwdCZWRmb3JkMRYwFAYDVQQIEw1NYXNzYWNodXNldHRz
MQswCQYDVQQGEwJVUwIRAOrEBeqt70yv4V5jDf4xCGwwgbUGCyqGSIb3DQEJEAILMYGloIGi
MIGMMRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEVMBMGA1UECxMMS0NBIFNlcnZpY2Vz
MSAwHgYDVQQDExdSU0EgQ2xhc3MgMiBQZXJzb25hbCBDQTEQMA4GA1UEBxMHQmVkZm9yZDEW
MBQGA1UECBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMCEQDqxAXqre9Mr+FeYw3+MQhs
MA0GCSqGSIb3DQEBAQUABIIBAEP20alrXhOJAJ7c+ZQi0elIghrJVUCwQhaALB0F/dTb7TZ+
HqrYLbORtQV9mMqhUO2SP24r6W1MBtaqFBxJrdbLyWjBdRi/8EZmgJmJhoyiWyqGNxzRi1Xn
ha+OFSEI6CL3SDHqCcY6tFOsfEbLVPjLb1vtvlM5v6j0CgcJ8OY0ckJ7y4Uy+Dv5Grp6grGO
lKajouiipJrTjtppBQEDlxSPxN+dVGs/+VORNCLjaXwEtoSYpzlZcMXcrMk7/vJ7PK+D3kR0
1HrSgtRH+5Aw0xdSbaVy9s9tIEh0l/UuiPoB+4lY1FWYuTYU1DWAWAOgIGP2LxSRQUdSeQoi
9GcxiyYAAAAAAAA=
--------------ms070106080409010800080000--


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASHgxib031424 for <[e-mail]>; Fri, 28 Nov 2003 09:43:00 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hASHgxoV031422 for ietf-pkix-bks; Fri, 28 Nov 2003 09:42:59 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from sigurd.x509.com ([199.175.155.2]) by above.proper.com (8.12.10/8.12.8) with SMTP id hASHguib031383 for <[e-mail]>; Fri, 28 Nov 2003 09:42:58 -0800 (PST) (envelope-from [e-mail])
Received: from nebula.x509.com by sigurd.x509.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 28 Nov 2003 17:42:57 UT
Received: from crack.x509.com (localhost [127.0.0.1]) by nebula.x509.com (8.12.10/NULL) with ESMTP id hASHd06L026906 for <[e-mail]>; Fri, 28 Nov 2003 09:39:00 -0800 (PST)
Received: from exvan01.x509.com (exvan01.x509.com [10.9.22.50]) by crack.x509.com (8.12.10/8.12.10) with ESMTP id hASHguY0014088 for <[e-mail]>; Fri, 28 Nov 2003 09:42:56 -0800 (PST)
Received: from rsasecurity.com (mbranchaud2.eng.x509.com [10.7.33.48]) by exvan01.x509.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id VQFWHA0T; Fri, 28 Nov 2003 09:51:48 -0800
Message-ID: <[e-mail]>
Date: Fri, 28 Nov 2003 09:33:17 -0800
X-Sybari-Trust: 811fca64 64c784fd 31d958cc 00000139
From: Marc Branchaud <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031110
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: DISCUSS:  MUST  reject in OCSPv1
References: <> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070200010103030102090402"
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.

--------------ms070200010103030102090402
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Florian Oelmaier wrote:
>>If the client puts a nonce in a request and doesn't behave differently 
>>depending on the presence/absence of the nonce in the response, then why 
>>put the nonce in at all?
> 
> I agree. But the client behaves differently! It may
> - display a warning to the user

Please.

> - apply another local policy regarding time checking
> - add additional measures to ensure freshness if a nonce is not present
> - etc.

Why not apply those measures in the first place and not bother with the 
nonce?

If the client has a policy that can let it live with the risk of replay 
within certain parameters, then it has no need for nonces.

Putting nonces into requests willy-nilly, just in case, is bad design.

		M.

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISqTCC
AtcwggJAoAMCAQICEFgUQCxch7Sxp7XFFauIqpwwDQYJKoZIhvcNAQEFBQAwbDEaMBgGA1UE
ChMRUlNBIFNlY3VyaXR5IEluYy4xHjAcBgNVBAMTFVJTQSBQdWJsaWMgUm9vdCBDQSB2MTEu
MCwGCSqGSIb3DQEJARYfcnNha2VvbnJvb3RzaWduQHJzYXNlY3VyaXR5LmNvbTAeFw0wMjA5
MDYxNDEzNTJaFw0wNzA5MDYxNDEzNTJaMIGCMRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5j
LjEVMBMGA1UECxMMS0NBIFNlcnZpY2VzMRYwFAYDVQQDEw1SU0EgQ29ycG9yYXRlMRAwDgYD
VQQHEwdCZWRmb3JkMRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMQswCQYDVQQGEwJVUzCBnzAN
BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAqnOw876lPpMTkSqrqzpEON/609PDLEhmWX4tkC19
AHneDaoetL277GtYYXBCggP2E+s66MN1ccWXyApfWjCZkIHepPC08NVI1JRcbViW3kwLzDD2
w5T9QJcyL5V1pN/LQdxahM56TiLeXlPiJekdmTdJoo+5Pw4bQU+MxTqURk8CAwEAAaNjMGEw
HwYDVR0jBBgwFoAU9UwxelEDPyzXi5eZb6hxkKt4PZswHQYDVR0OBBYEFO2RCGt0t1lKkvah
HSJwJp8KrxaSMA8GA1UdEwQIMAYBAf8CAQMwDgYDVR0PAQH/BAQDAgGGMA0GCSqGSIb3DQEB
BQUAA4GBAHiSe1a79hnPr16PuBwUTBWbuNQ4GJNsyfrCXzAswIT2A2WtGZ1Hp1jEAWi9OfAX
IYAdy52Jyv9N87wAEbLUgVmsFEIlYM5mi6ag7YIRGp8JP5UhLAN9O5YHrR9FsrGK4WmSl3sY
W1qAPOXubFcfhTgUDIYzM30izZBP4nwO07FpMIIC+DCCAmGgAwIBAgIQeuiOriTayCwjwpmR
gmdIUjANBgkqhkiG9w0BAQUFADCBgjEaMBgGA1UEChMRUlNBIFNlY3VyaXR5IEluYy4xFTAT
BgNVBAsTDEtDQSBTZXJ2aWNlczEWMBQGA1UEAxMNUlNBIENvcnBvcmF0ZTEQMA4GA1UEBxMH
QmVkZm9yZDEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMwHhcNMDIwOTIz
MTkxMzAzWhcNMDYwOTIzMTUxMzAzWjCBjDEaMBgGA1UEChMRUlNBIFNlY3VyaXR5IEluYy4x
FTATBgNVBAsTDEtDQSBTZXJ2aWNlczEgMB4GA1UEAxMXUlNBIENsYXNzIDIgUGVyc29uYWwg
Q0ExEDAOBgNVBAcTB0JlZGZvcmQxFjAUBgNVBAgTDU1hc3NhY2h1c2V0dHMxCzAJBgNVBAYT
AlVTMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCkR9yiabyRo6+NwC3Sl8wPuUiBD3rP
sENNjXvzSbTAyXA8pDDndnlAa1nLUhSMgvn8g1sYMd0Bp+C1/mI5PFUZ8jukUK95yt+TK26L
hM/M5RUq/EINdDDdWzg9je498K6oGfyWR6ETSJbIrDe5qQcLCABs9E2gVKb7Z/FwFo3C9QID
AQABo2MwYTAPBgNVHRMECDAGAQH/AgECMA4GA1UdDwEB/wQEAwIBhjAfBgNVHSMEGDAWgBTt
kQhrdLdZSpL2oR0icCafCq8WkjAdBgNVHQ4EFgQUxpPuxqX+41WOz4ojH+6Y3iHyn6cwDQYJ
KoZIhvcNAQEFBQADgYEAcdRHBjq8GfdDoutUTJPtSzQd7XsdsQh2KBbu8utl92VQHuI0J5wc
Rc817G8YbmTtCt/xqAzrr6k7fdaoDBr/kBuVHA5FEJ94foPgrOlbT3zdziMATXh5ESSDLMx6
p8ITIsTJNmwszIG5P9AAKJCW48gu1ZZmLXhFbHcYJGf99pwwggMFMIICbqADAgECAhEAvhyf
0s21hKaAc2Nm1WX4LTANBgkqhkiG9w0BAQUFADCBuzEkMCIGA1UEBxMbVmFsaUNlcnQgVmFs
aWRhdGlvbiBOZXR3b3JrMRcwFQYDVQQKEw5WYWxpQ2VydCwgSW5jLjE1MDMGA1UECxMsVmFs
aUNlcnQgQ2xhc3MgMyBQb2xpY3kgVmFsaWRhdGlvbiBBdXRob3JpdHkxITAfBgNVBAMTGGh0
dHA6Ly93d3cudmFsaWNlcnQuY29tLzEgMB4GCSqGSIb3DQEJARYRaW5mb0B2YWxpY2VydC5j
b20wHhcNMDIwNDMwMTUzMDE5WhcNMTkwNDMwMDkyMTU1WjBsMRowGAYDVQQKExFSU0EgU2Vj
dXJpdHkgSW5jLjEeMBwGA1UEAxMVUlNBIFB1YmxpYyBSb290IENBIHYxMS4wLAYJKoZIhvcN
AQkBFh9yc2FrZW9ucm9vdHNpZ25AcnNhc2VjdXJpdHkuY29tMIGfMA0GCSqGSIb3DQEBAQUA
A4GNADCBiQKBgQC0dSVa2EQ740GxqiIKsHATT4f8XYwUU23pzRe5W6IVpt4jkwDWkgnvTcP6
M8PD4OfK6Imal4hAH/c3K/dUIH7YyQZRGAE5Y27G5klZYKidcFlrfautgVES170MLKFmJqym
2FWAfVOibXatRcw7B0S+mP9404jID/MaIpRXkH5JjwIDAQABo1cwVTAMBgNVHRMEBTADAQH/
MA4GA1UdDwEB/wQEAwIBhjAWBgNVHSAEDzANMAsGCSqGSIb3DQUGATAdBgNVHQ4EFgQU9Uwx
elEDPyzXi5eZb6hxkKt4PZswDQYJKoZIhvcNAQEFBQADgYEAKsviXBc1FeBT2hIwyWuGwnPZ
J9ctjrsO7NbVLjsx/EYclFFGwo+pphiwdUTml9yd7fXzfk0D+7LOs9ZA5xhiHVrGusV4OW4i
7hx2KVILkYlcXCN5tDltKwa5+BkGUuvZdyAoIhpyf61h7uKCFguhaJ+VOiNB4DPtsmxI+KxO
E6YwggTYMIIEQaADAgECAhBgzHl9dAoZGu0JMqXovSgdMA0GCSqGSIb3DQEBBQUAMIGMMRow
GAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEVMBMGA1UECxMMS0NBIFNlcnZpY2VzMSAwHgYD
VQQDExdSU0EgQ2xhc3MgMiBQZXJzb25hbCBDQTEQMA4GA1UEBxMHQmVkZm9yZDEWMBQGA1UE
CBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMwHhcNMDMwNzA3MjMwODEzWhcNMDQwNzA3
MjMwODEzWjCBvjETMBEGCgmSJomT8ixkARkWA2NvbTEbMBkGCgmSJomT8ixkARkWC3JzYXNl
Y3VyaXR5MRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEWMBQGA1UECxMNTm9ydGggQW1l
cmljYTEUMBIGA1UECxMLRW5naW5lZXJpbmcxFzAVBgNVBAMTDk1hcmMgQnJhbmNoYXVkMScw
JQYJKoZIhvcNAQkBFhhtYXJjbmFyY0Byc2FzZWN1cml0eS5jb20wggEiMA0GCSqGSIb3DQEB
AQUAA4IBDwAwggEKAoIBAQDg2xoRr+a/dtnuFG+oTHa+tGtzeObFazNhYV2iSLNED4fHRu86
tknBYFgXggcHW5gsyjfkCtVMzP2tCivmbJgvISo36vsCsmAJH6LRnJf8HsvfmWZaD9tzhDpL
QVsBHr88J0ZMdVniRc7MQoYeu/3hYtUBeGO9bGA6T8vTrnXYonnFtVoTqE62SFqPZZk7HpCS
X1n+dM3zSym2ylMFYE14nukF4I9vAhsQVzk3QNpghmzGj8uoEy9xpf3k0o5+neneAGvcSkwo
r1mH5tSqhrEQaZp7vuSA2bvXaZEnjZzZiTpPDzs1oMpn3guzYhU7wMKz6xvwvgEYyAAV+P5n
FWM/AgMBAAGjggGBMIIBfTCBkgYDVR0gBIGKMIGHMIGEBgkqhkiG9w0FBwIwdzAuBggrBgEF
BQcCARYiaHR0cDovL2NhLnJzYXNlY3VyaXR5LmNvbS9DUFMuaHRtbDBFBggrBgEFBQcCAjA5
MBgWEVJTQSBTZWN1cml0eSBJbmMuMAMCAQEaHUNQUyBJbmNvcnBvcmF0ZWQgYnkgcmVmZXJl
bmNlMCkGA1UdJQQiMCAGCisGAQQBgjcUAgIGCCsGAQUFBwMCBggrBgEFBQcDBDAjBgNVHREE
HDAagRhtYXJjbmFyY0Byc2FzZWN1cml0eS5jb20wDgYDVR0PAQH/BAQDAgeAMEYGA1UdHwQ/
MD0wO6A5oDeGNWh0dHA6Ly9jcmwucnNhc2VjdXJpdHkuY29tOjgwL1JTQUNsYXNzMlBlcnNv
bmFsQ0EuY3JsMB8GA1UdIwQYMBaAFMaT7sal/uNVjs+KIx/umN4h8p+nMB0GA1UdDgQWBBQ1
yQ/UrvKb563LjzHqJzBzrZp/ejANBgkqhkiG9w0BAQUFAAOBgQCV82oGGnglQQzklKg/wKhy
evNeJ6FNBZFhLlmZRNlKgqvPFmBcxygfBGpHqIhsHcrt2/AjhJuzAj7UdW1vTVCY5MkZw8P9
6+J6aTc3bNlGbk0jvcvVgDhmM4xYJLwMZKEw92HlRhfuMnj7ah9DTqbKSewmyAyOc+FLpGfd
lu6CgTCCBOkwggRSoAMCAQICEQDqxAXqre9Mr+FeYw3+MQhsMA0GCSqGSIb3DQEBBQUAMIGM
MRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEVMBMGA1UECxMMS0NBIFNlcnZpY2VzMSAw
HgYDVQQDExdSU0EgQ2xhc3MgMiBQZXJzb25hbCBDQTEQMA4GA1UEBxMHQmVkZm9yZDEWMBQG
A1UECBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMwHhcNMDMwNzA3MjMwODI4WhcNMDQw
NzA3MjMwODEzWjCBwjETMBEGCgmSJomT8ixkARkWA2NvbTEbMBkGCgmSJomT8ixkARkWC3Jz
YXNlY3VyaXR5MRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEWMBQGA1UECxMNTm9ydGgg
QW1lcmljYTEUMBIGA1UECxMLRW5naW5lZXJpbmcxGzAZBgNVBAMTEk1hcmMgQnJhbmNoYXVk
LUVuYzEnMCUGCSqGSIb3DQEJARYYbWFyY25hcmNAcnNhc2VjdXJpdHkuY29tMIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwBjNaHTwtCXpdJg+iDxYMkWjuZIF0ic2fRLymZe+
BnZYWPnik0dFmTulx+V8slsLEtBllcc5o1yfIYfeHPinwRxv86kCUSlgfGGXKjJZaIeURgbo
bUbIfDTPlvRUZuiZvTR4C8tEY88Lle66n62B7wjUvDbiwK4EjzlXOkjpcYXLH7FbaFaRLDBB
PlFD5ydDRhQ67t6fjUeS7p7o/l/VHmPC5LFLXZkjEhjGd5pknbQIAbUGACL5UET85NUFPowD
3F47g0GCKEnuOsk2Ra+WHu7honhIxqmOwGnu85V6tW5xscf4dTofWZONQeaD3gSxv8+hcfKN
k9cwjpnUG2xGzwIDAQABo4IBjTCCAYkwNQYDVR0lBC4wLAYKKwYBBAGCNxQCAgYIKwYBBQUH
AwIGCCsGAQUFBwMEBgorBgEEAYI3CgMEMIGSBgNVHSAEgYowgYcwgYQGCSqGSIb3DQUHAjB3
MC4GCCsGAQUFBwIBFiJodHRwOi8vY2EucnNhc2VjdXJpdHkuY29tL0NQUy5odG1sMEUGCCsG
AQUFBwICMDkwGBYRUlNBIFNlY3VyaXR5IEluYy4wAwIBARodQ1BTIEluY29ycG9yYXRlZCBi
eSByZWZlcmVuY2UwIwYDVR0RBBwwGoEYbWFyY25hcmNAcnNhc2VjdXJpdHkuY29tMEYGA1Ud
HwQ/MD0wO6A5oDeGNWh0dHA6Ly9jcmwucnNhc2VjdXJpdHkuY29tOjgwL1JTQUNsYXNzMlBl
cnNvbmFsQ0EuY3JsMB8GA1UdIwQYMBaAFMaT7sal/uNVjs+KIx/umN4h8p+nMB0GA1UdDgQW
BBT/OiMCyY8CPnNBySW1ijJOYhj7ejAOBgNVHQ8BAf8EBAMCAzgwDQYJKoZIhvcNAQEFBQAD
gYEAlchAObA9eVmeiLu0nTU985Fch6v+EZKodUhZUN7dILgd05HorHN9jxBH6XI4/b9ZVvub
Pkpicdc112YbcLYTD2NumVksyNDI7fDaqiszgk1zluXtZJ+HsCt+GIAKCDfOVLECclpGyizq
VjZFEK4Pt9FxPGTnUJEvIKJcAQ24EvgxggPsMIID6AIBATCBoTCBjDEaMBgGA1UEChMRUlNB
IFNlY3VyaXR5IEluYy4xFTATBgNVBAsTDEtDQSBTZXJ2aWNlczEgMB4GA1UEAxMXUlNBIENs
YXNzIDIgUGVyc29uYWwgQ0ExEDAOBgNVBAcTB0JlZGZvcmQxFjAUBgNVBAgTDU1hc3NhY2h1
c2V0dHMxCzAJBgNVBAYTAlVTAhBgzHl9dAoZGu0JMqXovSgdMAkGBSsOAwIaBQCgggIfMBgG
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMTEyODE3MzMxN1ow
IwYJKoZIhvcNAQkEMRYEFHBwWdgsY5iLDF+QiZee9XsJNFzoMFIGCSqGSIb3DQEJDzFFMEMw
CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G
CCqGSIb3DQMCAgEoMIGzBgkrBgEEAYI3EAQxgaUwgaIwgYwxGjAYBgNVBAoTEVJTQSBTZWN1
cml0eSBJbmMuMRUwEwYDVQQLEwxLQ0EgU2VydmljZXMxIDAeBgNVBAMTF1JTQSBDbGFzcyAy
IFBlcnNvbmFsIENBMRAwDgYDVQQHEwdCZWRmb3JkMRYwFAYDVQQIEw1NYXNzYWNodXNldHRz
MQswCQYDVQQGEwJVUwIRAOrEBeqt70yv4V5jDf4xCGwwgbUGCyqGSIb3DQEJEAILMYGloIGi
MIGMMRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEVMBMGA1UECxMMS0NBIFNlcnZpY2Vz
MSAwHgYDVQQDExdSU0EgQ2xhc3MgMiBQZXJzb25hbCBDQTEQMA4GA1UEBxMHQmVkZm9yZDEW
MBQGA1UECBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMCEQDqxAXqre9Mr+FeYw3+MQhs
MA0GCSqGSIb3DQEBAQUABIIBAGhQKPwLnX/pvb9Q82bWji5wh6scyZSASdtPo5HY0vQmdnhX
u3kW7OCjUXXYzO64DybmMj2Zf0FeYm7Z8Qa+G0x1tJlR/Yxp5Br/3kjHwMBezWGnAdX9dYel
/xPJqiiupjiBdRXh/0bjhvLbfuDim4rULWw06M3ACn+demcG5ndRgyQW5lXC1YRC4erxVAhG
wnC6/+0e12GrUgx41J3LrQ9EHy2rc5iVBWmdCBC92LN7KqfHzb39qPNY2eYfX7itCgxwGolp
LoAt8OdalrSxxn8EZBbzeTrMQ4EAdS9VyzkVBZN5u77zqbzoeN+XjuLUBE+qYYmwAdkIXbXR
WfeQcC0AAAAAAAA=
--------------ms070200010103030102090402--


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASHbPib029399 for <[e-mail]>; Fri, 28 Nov 2003 09:37:25 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hASHbPVY029398 for ietf-pkix-bks; Fri, 28 Nov 2003 09:37:25 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from sigurd.x509.com ([199.175.155.2]) by above.proper.com (8.12.10/8.12.8) with SMTP id hASHbOib029393 for <[e-mail]>; Fri, 28 Nov 2003 09:37:24 -0800 (PST) (envelope-from [e-mail])
Received: from nebula.x509.com by sigurd.x509.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 28 Nov 2003 17:37:25 UT
Received: from crack.x509.com (localhost [127.0.0.1]) by nebula.x509.com (8.12.10/NULL) with ESMTP id hASHXR6L026861 for <[e-mail]>; Fri, 28 Nov 2003 09:33:28 -0800 (PST)
Received: from exvan01.x509.com (exvan01.x509.com [10.9.22.50]) by crack.x509.com (8.12.10/8.12.10) with ESMTP id hASHbOY0014044 for <[e-mail]>; Fri, 28 Nov 2003 09:37:24 -0800 (PST)
Received: from rsasecurity.com (mbranchaud2.eng.x509.com [10.7.33.48]) by exvan01.x509.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id VQFWHA9W; Fri, 28 Nov 2003 09:46:15 -0800
Message-ID: <[e-mail]>
Date: Fri, 28 Nov 2003 09:27:44 -0800
X-Sybari-Trust: b74ba093 64c784fd 31d958cc 00000139
From: Marc Branchaud <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031110
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: DISCUSS:  MUST  reject in OCSPv1
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070809080805000405090205"
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.

--------------ms070809080805000405090205
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit


Michael Myers wrote:
> 
> Marc, your response was ambiguous.

Just to clarify, then:

The resolution started with a "big if": Cycling at proposed.  I have no 
objection to cycling at Proposed and issuing an OCSPv2 that works all 
this out.

It's the "then" I am objecting to.  The proposed "then" is bad.

		M.

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISqTCC
AtcwggJAoAMCAQICEFgUQCxch7Sxp7XFFauIqpwwDQYJKoZIhvcNAQEFBQAwbDEaMBgGA1UE
ChMRUlNBIFNlY3VyaXR5IEluYy4xHjAcBgNVBAMTFVJTQSBQdWJsaWMgUm9vdCBDQSB2MTEu
MCwGCSqGSIb3DQEJARYfcnNha2VvbnJvb3RzaWduQHJzYXNlY3VyaXR5LmNvbTAeFw0wMjA5
MDYxNDEzNTJaFw0wNzA5MDYxNDEzNTJaMIGCMRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5j
LjEVMBMGA1UECxMMS0NBIFNlcnZpY2VzMRYwFAYDVQQDEw1SU0EgQ29ycG9yYXRlMRAwDgYD
VQQHEwdCZWRmb3JkMRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMQswCQYDVQQGEwJVUzCBnzAN
BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAqnOw876lPpMTkSqrqzpEON/609PDLEhmWX4tkC19
AHneDaoetL277GtYYXBCggP2E+s66MN1ccWXyApfWjCZkIHepPC08NVI1JRcbViW3kwLzDD2
w5T9QJcyL5V1pN/LQdxahM56TiLeXlPiJekdmTdJoo+5Pw4bQU+MxTqURk8CAwEAAaNjMGEw
HwYDVR0jBBgwFoAU9UwxelEDPyzXi5eZb6hxkKt4PZswHQYDVR0OBBYEFO2RCGt0t1lKkvah
HSJwJp8KrxaSMA8GA1UdEwQIMAYBAf8CAQMwDgYDVR0PAQH/BAQDAgGGMA0GCSqGSIb3DQEB
BQUAA4GBAHiSe1a79hnPr16PuBwUTBWbuNQ4GJNsyfrCXzAswIT2A2WtGZ1Hp1jEAWi9OfAX
IYAdy52Jyv9N87wAEbLUgVmsFEIlYM5mi6ag7YIRGp8JP5UhLAN9O5YHrR9FsrGK4WmSl3sY
W1qAPOXubFcfhTgUDIYzM30izZBP4nwO07FpMIIC+DCCAmGgAwIBAgIQeuiOriTayCwjwpmR
gmdIUjANBgkqhkiG9w0BAQUFADCBgjEaMBgGA1UEChMRUlNBIFNlY3VyaXR5IEluYy4xFTAT
BgNVBAsTDEtDQSBTZXJ2aWNlczEWMBQGA1UEAxMNUlNBIENvcnBvcmF0ZTEQMA4GA1UEBxMH
QmVkZm9yZDEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMwHhcNMDIwOTIz
MTkxMzAzWhcNMDYwOTIzMTUxMzAzWjCBjDEaMBgGA1UEChMRUlNBIFNlY3VyaXR5IEluYy4x
FTATBgNVBAsTDEtDQSBTZXJ2aWNlczEgMB4GA1UEAxMXUlNBIENsYXNzIDIgUGVyc29uYWwg
Q0ExEDAOBgNVBAcTB0JlZGZvcmQxFjAUBgNVBAgTDU1hc3NhY2h1c2V0dHMxCzAJBgNVBAYT
AlVTMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCkR9yiabyRo6+NwC3Sl8wPuUiBD3rP
sENNjXvzSbTAyXA8pDDndnlAa1nLUhSMgvn8g1sYMd0Bp+C1/mI5PFUZ8jukUK95yt+TK26L
hM/M5RUq/EINdDDdWzg9je498K6oGfyWR6ETSJbIrDe5qQcLCABs9E2gVKb7Z/FwFo3C9QID
AQABo2MwYTAPBgNVHRMECDAGAQH/AgECMA4GA1UdDwEB/wQEAwIBhjAfBgNVHSMEGDAWgBTt
kQhrdLdZSpL2oR0icCafCq8WkjAdBgNVHQ4EFgQUxpPuxqX+41WOz4ojH+6Y3iHyn6cwDQYJ
KoZIhvcNAQEFBQADgYEAcdRHBjq8GfdDoutUTJPtSzQd7XsdsQh2KBbu8utl92VQHuI0J5wc
Rc817G8YbmTtCt/xqAzrr6k7fdaoDBr/kBuVHA5FEJ94foPgrOlbT3zdziMATXh5ESSDLMx6
p8ITIsTJNmwszIG5P9AAKJCW48gu1ZZmLXhFbHcYJGf99pwwggMFMIICbqADAgECAhEAvhyf
0s21hKaAc2Nm1WX4LTANBgkqhkiG9w0BAQUFADCBuzEkMCIGA1UEBxMbVmFsaUNlcnQgVmFs
aWRhdGlvbiBOZXR3b3JrMRcwFQYDVQQKEw5WYWxpQ2VydCwgSW5jLjE1MDMGA1UECxMsVmFs
aUNlcnQgQ2xhc3MgMyBQb2xpY3kgVmFsaWRhdGlvbiBBdXRob3JpdHkxITAfBgNVBAMTGGh0
dHA6Ly93d3cudmFsaWNlcnQuY29tLzEgMB4GCSqGSIb3DQEJARYRaW5mb0B2YWxpY2VydC5j
b20wHhcNMDIwNDMwMTUzMDE5WhcNMTkwNDMwMDkyMTU1WjBsMRowGAYDVQQKExFSU0EgU2Vj
dXJpdHkgSW5jLjEeMBwGA1UEAxMVUlNBIFB1YmxpYyBSb290IENBIHYxMS4wLAYJKoZIhvcN
AQkBFh9yc2FrZW9ucm9vdHNpZ25AcnNhc2VjdXJpdHkuY29tMIGfMA0GCSqGSIb3DQEBAQUA
A4GNADCBiQKBgQC0dSVa2EQ740GxqiIKsHATT4f8XYwUU23pzRe5W6IVpt4jkwDWkgnvTcP6
M8PD4OfK6Imal4hAH/c3K/dUIH7YyQZRGAE5Y27G5klZYKidcFlrfautgVES170MLKFmJqym
2FWAfVOibXatRcw7B0S+mP9404jID/MaIpRXkH5JjwIDAQABo1cwVTAMBgNVHRMEBTADAQH/
MA4GA1UdDwEB/wQEAwIBhjAWBgNVHSAEDzANMAsGCSqGSIb3DQUGATAdBgNVHQ4EFgQU9Uwx
elEDPyzXi5eZb6hxkKt4PZswDQYJKoZIhvcNAQEFBQADgYEAKsviXBc1FeBT2hIwyWuGwnPZ
J9ctjrsO7NbVLjsx/EYclFFGwo+pphiwdUTml9yd7fXzfk0D+7LOs9ZA5xhiHVrGusV4OW4i
7hx2KVILkYlcXCN5tDltKwa5+BkGUuvZdyAoIhpyf61h7uKCFguhaJ+VOiNB4DPtsmxI+KxO
E6YwggTYMIIEQaADAgECAhBgzHl9dAoZGu0JMqXovSgdMA0GCSqGSIb3DQEBBQUAMIGMMRow
GAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEVMBMGA1UECxMMS0NBIFNlcnZpY2VzMSAwHgYD
VQQDExdSU0EgQ2xhc3MgMiBQZXJzb25hbCBDQTEQMA4GA1UEBxMHQmVkZm9yZDEWMBQGA1UE
CBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMwHhcNMDMwNzA3MjMwODEzWhcNMDQwNzA3
MjMwODEzWjCBvjETMBEGCgmSJomT8ixkARkWA2NvbTEbMBkGCgmSJomT8ixkARkWC3JzYXNl
Y3VyaXR5MRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEWMBQGA1UECxMNTm9ydGggQW1l
cmljYTEUMBIGA1UECxMLRW5naW5lZXJpbmcxFzAVBgNVBAMTDk1hcmMgQnJhbmNoYXVkMScw
JQYJKoZIhvcNAQkBFhhtYXJjbmFyY0Byc2FzZWN1cml0eS5jb20wggEiMA0GCSqGSIb3DQEB
AQUAA4IBDwAwggEKAoIBAQDg2xoRr+a/dtnuFG+oTHa+tGtzeObFazNhYV2iSLNED4fHRu86
tknBYFgXggcHW5gsyjfkCtVMzP2tCivmbJgvISo36vsCsmAJH6LRnJf8HsvfmWZaD9tzhDpL
QVsBHr88J0ZMdVniRc7MQoYeu/3hYtUBeGO9bGA6T8vTrnXYonnFtVoTqE62SFqPZZk7HpCS
X1n+dM3zSym2ylMFYE14nukF4I9vAhsQVzk3QNpghmzGj8uoEy9xpf3k0o5+neneAGvcSkwo
r1mH5tSqhrEQaZp7vuSA2bvXaZEnjZzZiTpPDzs1oMpn3guzYhU7wMKz6xvwvgEYyAAV+P5n
FWM/AgMBAAGjggGBMIIBfTCBkgYDVR0gBIGKMIGHMIGEBgkqhkiG9w0FBwIwdzAuBggrBgEF
BQcCARYiaHR0cDovL2NhLnJzYXNlY3VyaXR5LmNvbS9DUFMuaHRtbDBFBggrBgEFBQcCAjA5
MBgWEVJTQSBTZWN1cml0eSBJbmMuMAMCAQEaHUNQUyBJbmNvcnBvcmF0ZWQgYnkgcmVmZXJl
bmNlMCkGA1UdJQQiMCAGCisGAQQBgjcUAgIGCCsGAQUFBwMCBggrBgEFBQcDBDAjBgNVHREE
HDAagRhtYXJjbmFyY0Byc2FzZWN1cml0eS5jb20wDgYDVR0PAQH/BAQDAgeAMEYGA1UdHwQ/
MD0wO6A5oDeGNWh0dHA6Ly9jcmwucnNhc2VjdXJpdHkuY29tOjgwL1JTQUNsYXNzMlBlcnNv
bmFsQ0EuY3JsMB8GA1UdIwQYMBaAFMaT7sal/uNVjs+KIx/umN4h8p+nMB0GA1UdDgQWBBQ1
yQ/UrvKb563LjzHqJzBzrZp/ejANBgkqhkiG9w0BAQUFAAOBgQCV82oGGnglQQzklKg/wKhy
evNeJ6FNBZFhLlmZRNlKgqvPFmBcxygfBGpHqIhsHcrt2/AjhJuzAj7UdW1vTVCY5MkZw8P9
6+J6aTc3bNlGbk0jvcvVgDhmM4xYJLwMZKEw92HlRhfuMnj7ah9DTqbKSewmyAyOc+FLpGfd
lu6CgTCCBOkwggRSoAMCAQICEQDqxAXqre9Mr+FeYw3+MQhsMA0GCSqGSIb3DQEBBQUAMIGM
MRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEVMBMGA1UECxMMS0NBIFNlcnZpY2VzMSAw
HgYDVQQDExdSU0EgQ2xhc3MgMiBQZXJzb25hbCBDQTEQMA4GA1UEBxMHQmVkZm9yZDEWMBQG
A1UECBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMwHhcNMDMwNzA3MjMwODI4WhcNMDQw
NzA3MjMwODEzWjCBwjETMBEGCgmSJomT8ixkARkWA2NvbTEbMBkGCgmSJomT8ixkARkWC3Jz
YXNlY3VyaXR5MRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEWMBQGA1UECxMNTm9ydGgg
QW1lcmljYTEUMBIGA1UECxMLRW5naW5lZXJpbmcxGzAZBgNVBAMTEk1hcmMgQnJhbmNoYXVk
LUVuYzEnMCUGCSqGSIb3DQEJARYYbWFyY25hcmNAcnNhc2VjdXJpdHkuY29tMIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwBjNaHTwtCXpdJg+iDxYMkWjuZIF0ic2fRLymZe+
BnZYWPnik0dFmTulx+V8slsLEtBllcc5o1yfIYfeHPinwRxv86kCUSlgfGGXKjJZaIeURgbo
bUbIfDTPlvRUZuiZvTR4C8tEY88Lle66n62B7wjUvDbiwK4EjzlXOkjpcYXLH7FbaFaRLDBB
PlFD5ydDRhQ67t6fjUeS7p7o/l/VHmPC5LFLXZkjEhjGd5pknbQIAbUGACL5UET85NUFPowD
3F47g0GCKEnuOsk2Ra+WHu7honhIxqmOwGnu85V6tW5xscf4dTofWZONQeaD3gSxv8+hcfKN
k9cwjpnUG2xGzwIDAQABo4IBjTCCAYkwNQYDVR0lBC4wLAYKKwYBBAGCNxQCAgYIKwYBBQUH
AwIGCCsGAQUFBwMEBgorBgEEAYI3CgMEMIGSBgNVHSAEgYowgYcwgYQGCSqGSIb3DQUHAjB3
MC4GCCsGAQUFBwIBFiJodHRwOi8vY2EucnNhc2VjdXJpdHkuY29tL0NQUy5odG1sMEUGCCsG
AQUFBwICMDkwGBYRUlNBIFNlY3VyaXR5IEluYy4wAwIBARodQ1BTIEluY29ycG9yYXRlZCBi
eSByZWZlcmVuY2UwIwYDVR0RBBwwGoEYbWFyY25hcmNAcnNhc2VjdXJpdHkuY29tMEYGA1Ud
HwQ/MD0wO6A5oDeGNWh0dHA6Ly9jcmwucnNhc2VjdXJpdHkuY29tOjgwL1JTQUNsYXNzMlBl
cnNvbmFsQ0EuY3JsMB8GA1UdIwQYMBaAFMaT7sal/uNVjs+KIx/umN4h8p+nMB0GA1UdDgQW
BBT/OiMCyY8CPnNBySW1ijJOYhj7ejAOBgNVHQ8BAf8EBAMCAzgwDQYJKoZIhvcNAQEFBQAD
gYEAlchAObA9eVmeiLu0nTU985Fch6v+EZKodUhZUN7dILgd05HorHN9jxBH6XI4/b9ZVvub
Pkpicdc112YbcLYTD2NumVksyNDI7fDaqiszgk1zluXtZJ+HsCt+GIAKCDfOVLECclpGyizq
VjZFEK4Pt9FxPGTnUJEvIKJcAQ24EvgxggPsMIID6AIBATCBoTCBjDEaMBgGA1UEChMRUlNB
IFNlY3VyaXR5IEluYy4xFTATBgNVBAsTDEtDQSBTZXJ2aWNlczEgMB4GA1UEAxMXUlNBIENs
YXNzIDIgUGVyc29uYWwgQ0ExEDAOBgNVBAcTB0JlZGZvcmQxFjAUBgNVBAgTDU1hc3NhY2h1
c2V0dHMxCzAJBgNVBAYTAlVTAhBgzHl9dAoZGu0JMqXovSgdMAkGBSsOAwIaBQCgggIfMBgG
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMTEyODE3Mjc0NFow
IwYJKoZIhvcNAQkEMRYEFEeHDjAPPuNHquWYDudJ+5Fd3mR3MFIGCSqGSIb3DQEJDzFFMEMw
CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G
CCqGSIb3DQMCAgEoMIGzBgkrBgEEAYI3EAQxgaUwgaIwgYwxGjAYBgNVBAoTEVJTQSBTZWN1
cml0eSBJbmMuMRUwEwYDVQQLEwxLQ0EgU2VydmljZXMxIDAeBgNVBAMTF1JTQSBDbGFzcyAy
IFBlcnNvbmFsIENBMRAwDgYDVQQHEwdCZWRmb3JkMRYwFAYDVQQIEw1NYXNzYWNodXNldHRz
MQswCQYDVQQGEwJVUwIRAOrEBeqt70yv4V5jDf4xCGwwgbUGCyqGSIb3DQEJEAILMYGloIGi
MIGMMRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEVMBMGA1UECxMMS0NBIFNlcnZpY2Vz
MSAwHgYDVQQDExdSU0EgQ2xhc3MgMiBQZXJzb25hbCBDQTEQMA4GA1UEBxMHQmVkZm9yZDEW
MBQGA1UECBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMCEQDqxAXqre9Mr+FeYw3+MQhs
MA0GCSqGSIb3DQEBAQUABIIBAMMzbXCaY9hal+FjWnB1sKa9XEdk/P5PpMaHnlBsbzJ/mr6o
lUe4WzXe/PmfDjMBdrIV8ndQpbQKs0alowSFKjy1Nq+efmzPfHgxq4NNo8LtJLuc8NPwOpI6
gMdEM+GG/kKvz8qTIirmVbkYsa5XPy3wkmjuGBhGZ/rHqW+s8oFrQN+aySKysKPUz4nnRSoJ
ukRhHMT/TqYV5NRZPjrAL6O7SU5IjMGJo2NKChRh3Osn6JXKShRymNwyXnRH8neRivnWjVWR
YUao+xw8RNRP8StV/Aiszd87AsNVhaJAqZ/JLMJNAVMnvlbupSBmf+tgdQCYFt184i6EfecY
8rtXWKUAAAAAAAA=
--------------ms070809080805000405090205--


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASGjMib016802 for <[e-mail]>; Fri, 28 Nov 2003 08:45:22 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hASGjLuc016800 for ietf-pkix-bks; Fri, 28 Nov 2003 08:45:21 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASGjKib016779 for <[e-mail]>; Fri, 28 Nov 2003 08:45:20 -0800 (PST) (envelope-from [e-mail])
Received: from MMyersLapTop ([65.39.77.99]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id hASGjGA97546; Fri, 28 Nov 2003 09:45:16 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: "Ryan M. Hurst" <[e-mail]>, "Marc Branchaud" <[e-mail]>, <[e-mail]>
Subject: DIGRESS:   MUST  reject in OCSPv1
Date: Fri, 28 Nov 2003 09:47:27 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <[e-mail]>
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>

If we must digress, and I think it's useful to do so, let's do
it here.

Marc wrote:
> If the group wishes to address the use of nonces for more than
replay
> prevention, then I think the only option is to devise a new
OCSPv2
> spec.

Ryan wrote:
> [rmh] its not necesssary, the current RFC works and by
changing the
> semantics you disallow a legitimate use that worked and was
> conformant.

Marc countered:
> But that use wasn't conformant.  All that RFC2560 wants to use
nonces
> for is to prevent replay attacks.  Any other use of nonces
goes beyond
> what RFC2560 says they're for.

Ryan responded:
> [rmh] it absolutley is; find the text that precludes this
behavior.


To which I comment:

I dislike negative requirements.  They are untestable and are
therefore useless in customer acceptance testing.  Neither
should an OCSP server bake bread, but I didn't think it
necessary to point this out.

A potential improvement in degree of freshness is inherent in
the use of nonces.  This is, however, a secondary effect.  The
primary purpose of nonces is to address replay attacks:

"4.4.1  Nonce
The nonce cryptographically binds a request
and a response to prevent replay attacks."

Any secondary interpretation of nonce extension usage that
preserves this primary effect is arguably conformant.

Any secondary interpretation of nonce extension usage that does
not preserve this primary effect is by definition
non-conformant.

Mike



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASGUeib009717 for <[e-mail]>; Fri, 28 Nov 2003 08:30:40 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hASGUe8e009715 for ietf-pkix-bks; Fri, 28 Nov 2003 08:30:40 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.smarttrust.com ([213.212.5.232]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASGUaid009641 for <[e-mail]>; Fri, 28 Nov 2003 08:30:38 -0800 (PST) (envelope-from [e-mail])
Received: from sek43.smarttrust.com ([172.16.0.43]) by mail.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 17:31:19 +0100
Received: from mail pickup service by sek43.smarttrust.com with Microsoft SMTPSVC; Fri, 28 Nov 2003 17:30:32 +0100
Received: from mail.smarttrust.com ([192.168.1.10]) by sek43.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 26 Nov 2003 18:17:48 +0100
Received: from sek13 ([192.168.1.15]) by mail.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 26 Nov 2003 18:18:31 +0100
Received: from [208.184.76.39]:4840 (EHLO above.proper.com) by sek13.smarttrust.com ([192.168.1.15]:25) (F-Secure Anti-Virus for Internet Mail 6.0.34 Release) with SMTP; Wed, 26 Nov 2003 17:17:05 -0000
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQFXXib027570 for <[e-mail]>; Wed, 26 Nov 2003 07:33:33 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQFXXdQ027569 for ietf-pkix-bks; Wed, 26 Nov 2003 07:33:33 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.cs.auckland.ac.nz (csmail.cs.auckland.ac.nz [130.216.33.150]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQFXVib027563 for <[e-mail]>; Wed, 26 Nov 2003 07:33:32 -0800 (PST) (envelope-from [e-mail])
Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id 80B7463C1D; Thu, 27 Nov 2003 04:33:32 +1300 (NZDT)
Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id hAQFa4Y01319; Thu, 27 Nov 2003 04:36:04 +1300
Date: Thu, 27 Nov 2003 04:36:04 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Certificate Policy Standardization
Cc: [e-mail]
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-OriginalArrivalTime: 26 Nov 2003 17:18:31.0187 (UTC) FILETIME=[506F9630:01C3B441]
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>

Andreas Mitrakas <[e-mail]> writes:

>Especially so in some implementations in Europe where there is a direct link
>between the policy and the law under which certain certs like QC certs are
>issued.

The feeling was that digital signature legislation (following the UNCITRAL
model) is so vaguely worded that this wouldn't be a problem.  Qualified certs
are a bit more problematic, but that's only in Europe.

>A CP becomes part of the parties agreement and binding by means of e.g. a
>subscriber agreement. So it is not unthinkable albeit not necessarily
>desirable, that a courts might  scrutinise policies. --God forbid.

The feeling here was that a ToS-style policy might violate (at least NZ)
consumer protection legislation, however since a number of large organisations
relied on these types of agreements there would probably be a spirited defence
of them in court and/or existing case law upholding them.  See e.g Xtra
(Telecom NZ ISP) terms, which state:

  12. Changes to these Customer Terms

  We may change these Customer Terms by changing or removing existing terms,
  or by adding new ones. Changes may take the form of completely new terms.

  [Notification stuff snipped]

  A copy of our current terms is displayed on our Website. It is your
  responsibility to check these Customer Terms regularly (at least monthly)
  for any modifications or updates. You will be deemed to have accepted the
  changes to these Customer Terms and to have agreed to be bound by the
  revised Customer Terms if you continue to use and/or access the Services
  after the date that the changes are stated to be effective.

  We reserve the right to change any charges or Services, or any Separate
  Terms, at any time without notice. It is your responsibility to check all
  applicable Separate Terms regularly for any modifications or updates.

That's the sort of thing the "policy is what we say it is" that I mentioned
earlier was based on.  Just for reference, here's what Yahoo says:

  Yahoo! provides its service to you, subject to the following Terms of
  Service ("TOS"), which may be updated by us from time to time without notice
  to you. You can review the most current version of the TOS at any time at:
  http://docs.yahoo.com/info/terms/. 
  
  [Snippage]

  Yahoo! reserves the right at any time and from time to time to modify or
  discontinue, temporarily or permanently, the Service (or any part thereof)
  with or without notice. You agree that Yahoo! shall not be liable to you or
  to any third party for any modification, suspension or discontinuance of the
  Service.

The debate then went off on a tangent about whether a PKI was providing a
service of any value to a user (if it doesn't it's not covered by standard
consumer-protection law), and how you'd present that in court.

Disclaimer: IANAL, I just talk to them occasionally.

Peter.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASGUdib009707 for <[e-mail]>; Fri, 28 Nov 2003 08:30:39 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hASGUdk3009697 for ietf-pkix-bks; Fri, 28 Nov 2003 08:30:39 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.smarttrust.com ([213.212.5.232]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASGUaib009641 for <[e-mail]>; Fri, 28 Nov 2003 08:30:37 -0800 (PST) (envelope-from [e-mail])
Received: from sek43.smarttrust.com ([172.16.0.43]) by mail.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 17:31:18 +0100
Received: from mail pickup service by sek43.smarttrust.com with Microsoft SMTPSVC; Fri, 28 Nov 2003 17:30:31 +0100
Received: from mail.smarttrust.com ([192.168.1.10]) by sek43.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 26 Nov 2003 20:12:15 +0100
Received: from sek13 ([192.168.1.15]) by mail.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 26 Nov 2003 20:12:57 +0100
Received: from [208.184.76.39]:1973 (EHLO above.proper.com) by sek13.smarttrust.com ([192.168.1.15]:25) (F-Secure Anti-Virus for Internet Mail 6.0.34 Release) with SMTP; Wed, 26 Nov 2003 19:11:31 -0000
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQHTOib033804 for <[e-mail]>; Wed, 26 Nov 2003 09:29:24 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQHTO9E033803 for ietf-pkix-bks; Wed, 26 Nov 2003 09:29:24 -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.10/8.12.8) with ESMTP id hAQHTNib033796 for <[e-mail]>; Wed, 26 Nov 2003 09:29:23 -0800 (PST) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Wed, 26 Nov 2003 12:29:18 -0500
From: "David P. Kemp" <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Certificate Policy Standardization
References: <[e-mail]>            <[e-mail]>            <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-MIME-Autoconverted: from 8bit to quoted-printable by above.proper.com id hAQHTOib033804
X-OriginalArrivalTime: 26 Nov 2003 19:12:57.0796 (UTC) FILETIME=[4D40F840:01C3B451]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id hASGUcib009681
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>

Michael,

Do you believe any problems are solved by labeling of gasoline octane? 
The issuer of the gasoline advertises that it meets a certain technical 
specification, and each relying party decides what octane is required in 
his particular automobile.

With regard to granularity, some years ago there was a "Sunoco Custom 
Blending Pump" where you could dial up the exact quality of gasoline 
desired.  In my opinion, that's overkill - three grades is plenty. 
(Don't mention the different combinations of additives, which may vary 
by season, required by each of the 50 US states.  If any area cried out 
for policy standardization and granularity reduction, that is it.)

Three, coincidentally, is approximately the number of certificate 
policies actually used by the Department of Defense PKI.  Any number 
greater than two and less than six is a good number :-).

Dave



Michael Ströder wrote:

> Personally I'm not aware of any problems solved with the help of policy 
> OIDs. ;-) Maybe others on this list feel more enlightened.





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASGR3ib007820 for <[e-mail]>; Fri, 28 Nov 2003 08:27:03 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hASGR3jN007816 for ietf-pkix-bks; Fri, 28 Nov 2003 08:27:03 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASGR2ib007782 for <[e-mail]>; Fri, 28 Nov 2003 08:27:02 -0800 (PST) (envelope-from [e-mail])
Received: from orionsec.com (localhost [127.0.0.1]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id hASGR2B3012465 for <[e-mail]>; Fri, 28 Nov 2003 11:27:02 -0500
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: DISCUSS:  MUST  reject in OCSPv1
Date: Fri, 28 Nov 2003 12:27:02 -0400
Message-Id: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
X-Mailer: Open WebMail 1.81 20021127
X-OriginatingIP: 68.147.139.109 (chokhani)
MIME-Version: 1.0
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>

Mike:

I do not know if this was said or not, but with the new extension, a 
compliant Responder must not be permitted to switch between nonce supported 
and nonce not supported responses

On Fri, 28 Nov 2003 08:05:56 -0700, Michael Myers wrote
> These are constructive discussions but somewhat off topic for
> this thread.  We need to determine if we as a WG can agree on a
> least-impact near term path forward for disambiguating the
> relationship between nonces and pre-produced responses.
> 
> After much work, we finally have a potential resolution on the
> table.
> 
> David and Florian agree with it.
> Ryan does not.
> Marc, your response was ambiguous.
> 
> Anyone else care to voice an opinion on the proposal?
> 
> Mike






Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASGPFib007422 for <[e-mail]>; Fri, 28 Nov 2003 08:25:15 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hASGPFKZ007421 for ietf-pkix-bks; Fri, 28 Nov 2003 08:25:15 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.smarttrust.com ([213.212.5.232]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASGP6if007384 for <[e-mail]>; Fri, 28 Nov 2003 08:25:12 -0800 (PST) (envelope-from [e-mail])
Received: from sek43.smarttrust.com ([172.16.0.43]) by mail.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 17:25:52 +0100
Received: from mail pickup service by sek43.smarttrust.com with Microsoft SMTPSVC; Fri, 28 Nov 2003 17:25:00 +0100
Received: from mail.smarttrust.com ([192.168.1.10]) by sek43.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 27 Nov 2003 00:54:13 +0100
Received: from sek13 ([192.168.1.15]) by mail.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 27 Nov 2003 00:54:56 +0100
Received: from [208.184.76.39]:3846 (EHLO above.proper.com) by sek13.smarttrust.com ([192.168.1.15]:25) (F-Secure Anti-Virus for Internet Mail 6.0.34 Release) with SMTP; Wed, 26 Nov 2003 23:53:30 -0000
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQM5eib046331 for <[e-mail]>; Wed, 26 Nov 2003 14:05:40 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQM5e1g046330 for ietf-pkix-bks; Wed, 26 Nov 2003 14:05:40 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQM5cib046325 for <[e-mail]>; Wed, 26 Nov 2003 14:05:39 -0800 (PST) (envelope-from [e-mail])
Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Wed, 26 Nov 2003 14:05:38 -0800
Received: from 157.54.8.23 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 26 Nov 2003 14:05:37 -0800
Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 26 Nov 2003 14:05:35 -0800
Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 26 Nov 2003 14:05:35 -0800
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 26 Nov 2003 14:05:50 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.7122.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: DISCUSS:  MUST  reject in OCSPv1
Date: Wed, 26 Nov 2003 14:05:32 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: DISCUSS:  MUST  reject in OCSPv1
Thread-Index: AcO0aJdnOYDeYy8tQkOFBo9O7K5QbAAAKIMg
From: "Ryan M. Hurst" <[e-mail]>
To: "Michael Myers" <[e-mail]>, <[e-mail]>
Cc: "Carlisle Adams" <[e-mail]>
X-OriginalArrivalTime: 26 Nov 2003 22:05:50.0894 (UTC) FILETIME=[741A1CE0:01C3B469]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id hAQM5dib046326
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
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 know this isn't a poll, but to be clear MSFT does not support the MUST
reject in v1, nor the creation of a v2 for the nonce reason alone.

Ryan

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Michael Myers
Sent: Wednesday, November 26, 2003 12:05 PM
To: [e-mail]
Cc: Carlisle Adams
Subject: DISCUSS: MUST reject in OCSPv1


Colleagues,

I recently proposed to the chairs and the AD the following
action plan with respect to nonces in OCSP.  They in turn remain
curious as to working group consensus on the subject with a
particular emphasis on objections.  I had hoped for an ad-hoc
quorum on this in Minneapolis but it never materialized due to
the absence of several key players.

So, once more into the breach.  Who would object and why to the
following action plan (silence WILL be taken as consent):

1.  Regarding v1, clarify per the minutes as
    2560 goes from Proposed to Draft.  The
    operative text of which is that clients
    MUST reject a response that fails to
    incorporate a client's nonce.

2.  Simultaneously, initiate action on a v2
    I-D that will in part address technical
    changes in syntax and processing rules
    related to the use of nonces.

This is not a poll.  It is a request for discussion.  I expect
little disagreement on the intent of the v2 action item. The
core issue on v1 is "MUST reject".

To initiate the v1 discussion, my opinions are as follows.

1.  Nonces were established in OCSP to enable
    client driven prevention of replay attacks.
    Failure to respect a client's nonce is a
    direct denial of a client's request for
    this security service.  A responder that
    does so is contributing to the very security
    risks the requestor is seeking to mitigate.

2.  While 2560 also enables use of pre-produced
    responses, nonces and pre-produced responses
    are by definition mutually exclusive.  This
    effect should be immediately obvious to even
    the most naive of implementors, else they have
    no business writing code against this standard.
    A competent level of technical proficiency
    in implementing secure protocols is assumed.

3.  The "breakage" poll indicates that an
    overwhelming majority of OCSP implementors
    possess this competency.  11 of 12 client-side
    implementors reported no breakage with
    "MUST reject" while 10 of 12 server-side
    implementors responded likewise.

4.  The two server-side breakage points occur
    as a consequence of their use of pre-produced
    responses in a context where they have no
    administrative control over clients' use of
    nonces.  This can be addressed in v2, but in
    a v1 context we have no choice but to clarify
    original intent as ratified by the breakage poll.
    This breakage could also be relieved by relay
    of OCSP requests.

5.  The absence of normative language providing a
    tutorial on the proper use of nonces in a
    security protocol SHOULD NOT be taken up by
    any participant in this WG as an excuse to
    refute sound security principles.  Active
    participants in the Security Area of the IETF
    should be able to assume of their peers a
    superior grasp of and respect for foundational
    principles.

Objections to the "MUST reject" clarification are sought on the
basis of sound security engineering principles rather than
artful readings of ancillary language that enable specious
excuse from adherence to these principles in order to justify
current business models.

We are setting standards that must survive the test of time.  We
are supposed to check our corporate identities at the door.  We
are supposed to be individual engineers chartered to improve
Internet security.  Let us do so and get this problem solved.

My thanks to you all in advance for your patience with the
length of this note.


Mike





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASGPCib007413 for <[e-mail]>; Fri, 28 Nov 2003 08:25:12 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hASGPCER007411 for ietf-pkix-bks; Fri, 28 Nov 2003 08:25:12 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.smarttrust.com ([213.212.5.232]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASGP6ib007384 for <[e-mail]>; Fri, 28 Nov 2003 08:25:10 -0800 (PST) (envelope-from [e-mail])
Received: from sek43.smarttrust.com ([172.16.0.43]) by mail.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 17:25:48 +0100
Received: from mail pickup service by sek43.smarttrust.com with Microsoft SMTPSVC; Fri, 28 Nov 2003 17:24:57 +0100
Received: from mail.smarttrust.com ([192.168.1.10]) by sek43.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 27 Nov 2003 03:03:33 +0100
Received: from sek13 ([192.168.1.15]) by mail.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 27 Nov 2003 03:04:16 +0100
Received: from [208.184.76.39]:1944 (EHLO above.proper.com) by sek13.smarttrust.com ([192.168.1.15]:25) (F-Secure Anti-Virus for Internet Mail 6.0.34 Release) with SMTP; Thu, 27 Nov 2003 02:02:49 -0000
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAR0MXib051732 for <[e-mail]>; Wed, 26 Nov 2003 16:22:33 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAR0MXX5051731 for ietf-pkix-bks; Wed, 26 Nov 2003 16:22:33 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAR0MWib051725 for <[e-mail]>; Wed, 26 Nov 2003 16:22:32 -0800 (PST) (envelope-from [e-mail])
Received: from MMyersLapTop ([65.39.77.99]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id hAR0MXA94975; Wed, 26 Nov 2003 17:22:33 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: "David Engberg" <[e-mail]>, <[e-mail]>
Subject: RE: DISCUSS:  MUST  reject in OCSPv1
Date: Wed, 26 Nov 2003 17:24:45 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1106
In-Reply-To: <[e-mail]>
Importance: Normal
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-OriginalArrivalTime: 27 Nov 2003 02:04:16.0390 (UTC) FILETIME=[C2D79260:01C3B48A]
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>

Dave,

As I hope you realize, I take your point in a v2 context.
However, in v1, there was no discussion whatsoever regarding
conditional incorporation of a client's nonce.  This is a new
requirement, leading to new processing functionality and
doubtless must be taken up in v2 on that basis.

Meanwhile I remained disturbed that this WG of the IETF Security
Area will walk away from this issue tacitly condoning an
insecure practice by inaction on "MUST reject".  It's a tough
call, I know, but one that is supported by prior poll and an
issue that begs clarification before this insecure practice
finds it way to even more environments.  At least, that's my
opinion.

I should note as well that another of this WG's products, SCVP,
very clearly respects the underlying principle.  c.f. Section
3.4 of
http://www.ietf.org/internet-drafts/draft-ietf-pkix-scvp-13.txt,
where it is stated that:

    "If the client includes a requestNonce value
    in the request, then the server MUST return the
    same value in the response."

So again, it's not like this WG is blind the principle.

If "MUST reject" in v1 causes such pain, then find alternative
means to signal to the relying party that their use of nonces is
not acceptable and thus motivate a retry.  Goodness knows, web
surfers today receive ample notice that cookies must be enabled
to participate on many sites.


Mike


> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of
> David Engberg
> Sent: Wednesday, November 26, 2003 3:20 PM
> To: [e-mail]
> Subject: Re: DISCUSS: MUST reject in OCSPv1
>
>
>
>
> In brief:  I would object to a plan to require that
> v1-compatible
> clients MUST reject nonceless responses for nonced
> requests, regardless
> of local security policy.  I would favor a plan to
> strongly recommend
> that v1-compatible clients SHOULD reject nonceless
> responses for nonced
> requests.
>
> Rationale:
>
> Imagine an OCSP client who receives signed email with
> a cert from Acme
> Certs.  He chains it up (e.g through bridging) to
> some trusted root, and
> then finds Acme's responder URL through the cert's
> AIA field.  The
> client trusts the cert, but needs to validate its
> revocation status
> through OCSP.  With the "MUST" language, the client
> is limited to two
> automatically-enforced local security policies:
>
>    1) Don't send a nonce, whether or not Acme's
> server supports nonces.
>
>    2) Send a nonce whether or not Acme's server
> supports nonces, and
>       fail to perform any validation if it does not.
>
> These two local security policies are both perfectly
> valid for many
> users, but the indirect question being asked is:  Are
> these the ONLY two
> security policies that v1 OCSP clients may permit
> users to choose.
>
> I posit that there is a third local security policy
> that the MUST
> language prohibits, and that policy can be achieved
> under v1 SHOULD
> language:
>
>    3) Send a nonce to Acme's server, and accept the
> response IFF
>       the response contains the nonce OR the server
> SECURELY signals
>       that it does not supply nonces to anyone.
>
> There was plenty of discussion around the best way to
> achieve this
> secure signalling, but there was overwhelming
> consensus on this list
> that this should at least be a theoretical option.
> By using SHOULD, you
> permit willing clients and servers to extend RFC2560
> (that's what
> extensions are there for?) to adopt such an optional
> security model,
> rather than arbitrarily preventing all such extensibility.
>
> No one is arguing that this third local security
> policy must be
> implemented by every client and server, but by
> adopting language using
> SHOULD instead of MUST, you will permit v1-compliant
> servers and clients
> to at least consider implementing such a policy
> before v2-final in a few
> years.
>
>
>



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASGPCib007412 for <[e-mail]>; Fri, 28 Nov 2003 08:25:12 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hASGPCwp007410 for ietf-pkix-bks; Fri, 28 Nov 2003 08:25:12 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.smarttrust.com ([213.212.5.232]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASGP6id007384 for <[e-mail]>; Fri, 28 Nov 2003 08:25:11 -0800 (PST) (envelope-from [e-mail])
Received: from sek43.smarttrust.com ([172.16.0.43]) by mail.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 17:25:50 +0100
Received: from mail pickup service by sek43.smarttrust.com with Microsoft SMTPSVC; Fri, 28 Nov 2003 17:25:00 +0100
Received: from mail.smarttrust.com ([192.168.1.10]) by sek43.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 27 Nov 2003 00:48:00 +0100
Received: from sek13 ([192.168.1.15]) by mail.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 27 Nov 2003 00:48:42 +0100
Received: from [208.184.76.39]:3586 (EHLO above.proper.com) by sek13.smarttrust.com ([192.168.1.15]:25) (F-Secure Anti-Virus for Internet Mail 6.0.34 Release) with SMTP; Wed, 26 Nov 2003 23:47:16 -0000
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQMJpib046844 for <[e-mail]>; Wed, 26 Nov 2003 14:19:51 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQMJpls046843 for ietf-pkix-bks; Wed, 26 Nov 2003 14:19:51 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from the-humungus.corestreet.com ([68.162.232.130]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQMJoib046834 for <[e-mail]>; Wed, 26 Nov 2003 14:19:50 -0800 (PST) (envelope-from [e-mail])
Received: from corestreet.com (engberg2.corestreet.com [192.168.2.119]) by the-humungus.corestreet.com (8.12.8/8.12.8) with ESMTP id hAQMJlEj031222 for <[e-mail]>; Wed, 26 Nov 2003 17:19:47 -0500
Message-ID: <[e-mail]>
Date: Wed, 26 Nov 2003 17:19:48 -0500
From: David Engberg <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: DISCUSS:  MUST  reject in OCSPv1
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-OriginalArrivalTime: 26 Nov 2003 23:48:42.0953 (UTC) FILETIME=[D2EF9390:01C3B477]
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 brief:  I would object to a plan to require that v1-compatible 
clients MUST reject nonceless responses for nonced requests, regardless 
of local security policy.  I would favor a plan to strongly recommend 
that v1-compatible clients SHOULD reject nonceless responses for nonced 
requests.

Rationale:

Imagine an OCSP client who receives signed email with a cert from Acme 
Certs.  He chains it up (e.g through bridging) to some trusted root, and 
then finds Acme's responder URL through the cert's AIA field.  The 
client trusts the cert, but needs to validate its revocation status 
through OCSP.  With the "MUST" language, the client is limited to two 
automatically-enforced local security policies:

   1) Don't send a nonce, whether or not Acme's server supports nonces.

   2) Send a nonce whether or not Acme's server supports nonces, and
      fail to perform any validation if it does not.

These two local security policies are both perfectly valid for many 
users, but the indirect question being asked is:  Are these the ONLY two 
security policies that v1 OCSP clients may permit users to choose.

I posit that there is a third local security policy that the MUST 
language prohibits, and that policy can be achieved under v1 SHOULD 
language:

   3) Send a nonce to Acme's server, and accept the response IFF
      the response contains the nonce OR the server SECURELY signals
      that it does not supply nonces to anyone.

There was plenty of discussion around the best way to achieve this 
secure signalling, but there was overwhelming consensus on this list 
that this should at least be a theoretical option.  By using SHOULD, you 
permit willing clients and servers to extend RFC2560 (that's what 
extensions are there for?) to adopt such an optional security model, 
rather than arbitrarily preventing all such extensibility.

No one is arguing that this third local security policy must be 
implemented by every client and server, but by adopting language using 
SHOULD instead of MUST, you will permit v1-compliant servers and clients 
to at least consider implementing such a policy before v2-final in a few 
years.





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASGNLib007218 for <[e-mail]>; Fri, 28 Nov 2003 08:23:21 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hASGNLkQ007217 for ietf-pkix-bks; Fri, 28 Nov 2003 08:23:21 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.smarttrust.com ([213.212.5.232]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASGNJib007206 for <[e-mail]>; Fri, 28 Nov 2003 08:23:19 -0800 (PST) (envelope-from [e-mail])
Received: from sek43.smarttrust.com ([172.16.0.43]) by mail.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 17:24:01 +0100
Received: from mail pickup service by sek43.smarttrust.com with Microsoft SMTPSVC; Fri, 28 Nov 2003 17:22:57 +0100
Received: from mail.smarttrust.com ([192.168.1.10]) by sek43.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 27 Nov 2003 23:41:18 +0100
Received: from sek13 ([192.168.1.15]) by mail.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 27 Nov 2003 23:42:03 +0100
Received: from [208.184.76.39]:3271 (EHLO above.proper.com) by sek13.smarttrust.com ([192.168.1.15]:25) (F-Secure Anti-Virus for Internet Mail 6.0.34 Release) with SMTP; Thu, 27 Nov 2003 22:40:34 -0000
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hARL8fib082579 for <[e-mail]>; Thu, 27 Nov 2003 13:08:41 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hARL8fr2082578 for ietf-pkix-bks; Thu, 27 Nov 2003 13:08:41 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from nb2.stroeder.com (du-041-193.access.de.clara.net [213.221.64.193]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hARL8bib082570 for <[e-mail]>; Thu, 27 Nov 2003 13:08:39 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (localhost [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id 768EB8AE59; Thu, 27 Nov 2003 16:44:54 +0100 (CET)
Received: from stroeder.com (localhost [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id 57A6D87C4F; Thu, 27 Nov 2003 16:44:53 +0100 (CET)
Message-ID: <[e-mail]>
Date: Thu, 27 Nov 2003 16:44:53 +0100
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007
X-Accept-Language: de-de, de, en-us, en
MIME-Version: 1.0
To: Peter Gutmann <[e-mail]>
Cc: [e-mail]
Subject: Re: Certificate Policy Standardization
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
X-Virus-Scanned: by AMaViS 0.3.12pre8
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id hARL8eib082573
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-MIME-Autoconverted: from 8bit to quoted-printable by above.proper.com id hARL8fib082579
X-OriginalArrivalTime: 27 Nov 2003 22:42:03.0125 (UTC) FILETIME=[AD440250:01C3B537]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id hASGNKib007213
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 Gutmann wrote:
> 
> The feeling here was that a ToS-style policy might violate (at least NZ) 
> consumer protection legislation,

I'm not a lawyer and the terms are for sure used much differently in other
countries. But I also guess that most ToS-style CPs would not withstand a
court trial based on german AGB-Gesetz, the law regulating "Allgemeine
Geschäftsbedingungen" (similar to ToS).

But since PKI did not hit the mass market yet a CA with such a ToS-style CP
can assume that this risk is quite low.
Less RPs => less serious usage => less risks. ;-)

Ciao, Michael.






Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASGN7ib007204 for <[e-mail]>; Fri, 28 Nov 2003 08:23:07 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hASGN7Hv007203 for ietf-pkix-bks; Fri, 28 Nov 2003 08:23:07 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.smarttrust.com ([213.212.5.232]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASGN5ib007198 for <[e-mail]>; Fri, 28 Nov 2003 08:23:06 -0800 (PST) (envelope-from [e-mail])
Received: from sek43.smarttrust.com ([172.16.0.43]) by mail.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 17:23:47 +0100
Received: from mail pickup service by sek43.smarttrust.com with Microsoft SMTPSVC; Fri, 28 Nov 2003 17:22:45 +0100
Received: from mail.smarttrust.com ([192.168.1.10]) by sek43.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 27 Nov 2003 16:32:58 +0100
Received: from sek13 ([192.168.1.15]) by mail.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 27 Nov 2003 16:33:41 +0100
Received: from [208.184.76.39]:1516 (EHLO above.proper.com) by sek13.smarttrust.com ([192.168.1.15]:25) (F-Secure Anti-Virus for Internet Mail 6.0.34 Release) with SMTP; Thu, 27 Nov 2003 15:32:14 -0000
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hARE75ib060653 for <[e-mail]>; Thu, 27 Nov 2003 06:07:05 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hARE75Ax060652 for ietf-pkix-bks; Thu, 27 Nov 2003 06:07:05 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp4.hy.skanova.net (smtp4.hy.skanova.net [195.67.199.133]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hARE74ib060647 for <[e-mail]>; Thu, 27 Nov 2003 06:07:05 -0800 (PST) (envelope-from [e-mail])
Received: from arport (t12o913p47.telia.com [213.64.28.167]) by smtp4.hy.skanova.net (8.12.10/8.12.10) with SMTP id hARE6kBZ005296; Thu, 27 Nov 2003 15:06:47 +0100 (CET)
Message-ID: <001301c3b4ef$29ffa8b0$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Peter Gutmann" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: Straw poll: An advice to a commercial CA
Date: Thu, 27 Nov 2003 15:02:56 +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
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-OriginalArrivalTime: 27 Nov 2003 15:33:41.0843 (UTC) FILETIME=[D61B9A30:01C3B4FB]
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 cryptlib finds constraints in a CA cert it'll apply them down the chain, but
>there's no way for a user to configure the behaviour.  The reason for this is
>that no-one has ever asked for this [0], so I can't even begin to imagine what
>sort of interface it'd require to manage things.  Do users type in a list of
>OIDs from a piece of paper?  Do they click on a CA cert and say "Use the
>policies advertised by this CA"? 

Oh Peter, now you become far too practical for _this_ list!

But it is indeed a real challenge to write a GUI to be used by
ordinary IS administrators, for a mechanism that you need a Phd
or better to grasp!

I guess you can wait with the GUI as long as Microsoft will
wait with a GUI in their products.  That is, forever.

Eureka, I got it!  Since this is black magic anyway, Microsoft
could make this configurable with Regedit!  That's how MSFT
usually treat stuff that you really shouldn't muck around with
at all or only on your own risk.  Finally RFC3280 has found
its true sole-mate.  It was a long journey...

Anders


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASGMsib007189 for <[e-mail]>; Fri, 28 Nov 2003 08:22:54 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hASGMs5B007188 for ietf-pkix-bks; Fri, 28 Nov 2003 08:22:54 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.smarttrust.com ([213.212.5.232]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASGMoid007172 for <[e-mail]>; Fri, 28 Nov 2003 08:22:52 -0800 (PST) (envelope-from [e-mail])
Received: from sek43.smarttrust.com ([172.16.0.43]) by mail.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 17:23:37 +0100
Received: from mail pickup service by sek43.smarttrust.com with Microsoft SMTPSVC; Fri, 28 Nov 2003 17:22:41 +0100
Received: from mail.smarttrust.com ([192.168.1.10]) by sek43.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 02:06:30 +0100
Received: from sek13 ([192.168.1.15]) by mail.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 02:07:15 +0100
Received: from [208.184.76.39]:3302 (EHLO above.proper.com) by sek13.smarttrust.com ([192.168.1.15]:25) (F-Secure Anti-Virus for Internet Mail 6.0.34 Release) with SMTP; Fri, 28 Nov 2003 01:05:46 -0000
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hARNd3ib089328 for <[e-mail]>; Thu, 27 Nov 2003 15:39:03 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hARNd3jO089327 for ietf-pkix-bks; Thu, 27 Nov 2003 15:39:03 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout07.sul.t-online.com (mailout07.sul.t-online.com [194.25.134.83]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hARNd1ib089322 for <[e-mail]>; Thu, 27 Nov 2003 15:39:01 -0800 (PST) (envelope-from [e-mail])
Received: from fwd05.aul.t-online.de  by mailout07.sul.t-online.com with smtp  id 1APViv-0005FJ-06; Fri, 28 Nov 2003 00:39:01 +0100
Received: from hagen (EB7BNyZpgemyjzEnp3SsPUnBt3a4OCCZ8dHU-iv7MpND3PjRu+cxZ1@[217.228.232.10]) by fmrl05.sul.t-online.com with esmtp id 1APViB-2CQjRI0; Fri, 28 Nov 2003 00:38:15 +0100
From: "Florian Oelmaier" <[e-mail]>
To: "'Marc Branchaud'" <[e-mail]>, <[e-mail]>
Subject: RE: DISCUSS:  MUST  reject in OCSPv1
Date: Fri, 28 Nov 2003 00:38:13 +0100
Organization: SyTrust
Message-ID: <002101c3b53f$869821b0$4228a8c0@hagen>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Seen: false
X-ID: [e-mail]
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-OriginalArrivalTime: 28 Nov 2003 01:07:15.0015 (UTC) FILETIME=[F5F4ED70:01C3B54B]
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 Marc,

> > I object. It breaks running code in installations.
> 
> That code is not secure, and did not follow the spec.

Accept it or not, but even code not using nonces is secure! At least as
secure as using CRLs. And definitely better than not checking revocation
at all.

If we follow the path of your arguments, we should make nonce a
requirement in OCSP. Seeing the TLS OCSP extensions this renders OCSP
unusable. If we agree that pre-produced responses are reasonable for
some use-cases, then you cannot argue that code accepting nonce-less
responses is not secure.

> > Seeing this it is a very acceptable for a client to TRY to get a 
> > nonce, but to accept answers without nonces as a fallback.
> 
> No, it is not acceptable.  The RFC is very clear: use nonces 
> to prevent 
> replay attacks.  If the client is concerned about replay attacks, it 
> must reject a nonceless response.

Most clients are concerned about replay attacks. But the first priority
of an OCSP-client is to get secure revocation information (at least the
same quality as a CRL). If the client is also able to get replay
protection, fine!

> > It is a "natural"
> > behaviour - I try for all extensions I support, but will 
> fall back to 
> > the very basics of the standard, to the "not extended" 
> behaviour when 
> > I cannot get what I want. This is the usual way of doing things in 
> > nearly all protocols out there, PKIX or not.
> 
> Nearly all protocols out there are insecure.  This is a security WG...

[A rant?] Tell that to the TLS and the IPSEC guys. Feature-fallback and
security are not mutually exclusive.




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASGMrib007182 for <[e-mail]>; Fri, 28 Nov 2003 08:22:53 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hASGMruH007181 for ietf-pkix-bks; Fri, 28 Nov 2003 08:22:53 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.smarttrust.com ([213.212.5.232]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASGMoib007172 for <[e-mail]>; Fri, 28 Nov 2003 08:22:51 -0800 (PST) (envelope-from [e-mail])
Received: from sek43.smarttrust.com ([172.16.0.43]) by mail.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 17:23:32 +0100
Received: from mail pickup service by sek43.smarttrust.com with Microsoft SMTPSVC; Fri, 28 Nov 2003 17:22:41 +0100
Received: from mail.smarttrust.com ([192.168.1.10]) by sek43.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 02:27:07 +0100
Received: from sek13 ([192.168.1.15]) by mail.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 02:27:52 +0100
Received: from [208.184.76.39]:4779 (EHLO above.proper.com) by sek13.smarttrust.com ([192.168.1.15]:25) (F-Secure Anti-Virus for Internet Mail 6.0.34 Release) with SMTP; Fri, 28 Nov 2003 01:26:24 -0000
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS02nib091186 for <[e-mail]>; Thu, 27 Nov 2003 16:02:49 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAS02naM091185 for ietf-pkix-bks; Thu, 27 Nov 2003 16:02:49 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from sigurd.x509.com ([199.175.155.2]) by above.proper.com (8.12.10/8.12.8) with SMTP id hAS02mib091179 for <[e-mail]>; Thu, 27 Nov 2003 16:02:48 -0800 (PST) (envelope-from [e-mail])
Received: from nebula.x509.com by sigurd.x509.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 28 Nov 2003 00:02:50 UT
Received: from crack.x509.com (localhost [127.0.0.1]) by nebula.x509.com (8.12.10/NULL) with ESMTP id hARNws6L017084 for <[e-mail]>; Thu, 27 Nov 2003 15:58:54 -0800 (PST)
Received: from exvan01.x509.com (exvan01.x509.com [10.9.22.50]) by crack.x509.com (8.12.10/8.12.10) with ESMTP id hAS02nY0028932 for <[e-mail]>; Thu, 27 Nov 2003 16:02:49 -0800 (PST)
Received: from rsasecurity.com (mbranchaud2.eng.x509.com [10.7.33.48]) by exvan01.x509.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id VQFWG8ZV; Thu, 27 Nov 2003 16:11:40 -0800
Message-ID: <[e-mail]>
Date: Thu, 27 Nov 2003 15:53:12 -0800
X-Sybari-Trust: d2cce05a 64c784fd c3b38011 00000139
From: Marc Branchaud <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031110
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: DISCUSS:  MUST  reject in OCSPv1
References: <002101c3b53f$869821b0$4228a8c0@hagen>
In-Reply-To: <002101c3b53f$869821b0$4228a8c0@hagen>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020802090503030700060305"
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-OriginalArrivalTime: 28 Nov 2003 01:27:52.0156 (UTC) FILETIME=[D759A9C0:01C3B54E]
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.

--------------ms020802090503030700060305
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Florian Oelmaier wrote:
> 
>>>I object. It breaks running code in installations.
>>
>>That code is not secure, and did not follow the spec.
> 
> Accept it or not, but even code not using nonces is secure! At least as
> secure as using CRLs. And definitely better than not checking revocation
> at all.

Yes, it is just as secure as using CRLs.  CRLs are also vulnerable to 
replay attacks.  OCSP has a mechanism - nonces - to thwart replay 
attacks.  Code that abuses (or just doesn't use) that mechanism is 
insecure against replay attacks.

> If we follow the path of your arguments, we should make nonce a
> requirement in OCSP.

Not at all.  Many environments are perfectly fine with the risk of 
replay attacks.

> Seeing the TLS OCSP extensions this renders OCSP
> unusable.

I don't see how that follows.

> If we agree that pre-produced responses are reasonable for
> some use-cases, then you cannot argue that code accepting nonce-less
> responses is not secure.

That's not my argument.  The crux is whether a nonce is in the request.

If the request as a nonce, then the response MUST echo the nonce and the 
client MUST reject a nonceless response.  Why?  Because nonces are how 
OCSP prevents replay attacks.  To act any other way fails to prevent 
replay attacks.

However, if the request does _not_ have a nonce, then the client is 
perfectly free to accept nonceless (or nonceful) responses.

> Most clients are concerned about replay attacks.

Not the ones that don't care about nonces in responses.

> But the first priority
> of an OCSP-client is to get secure revocation information (at least the
> same quality as a CRL). If the client is also able to get replay
> protection, fine!

If the client puts a nonce in a request and doesn't behave differently 
depending on the presence/absence of the nonce in the response, then why 
put the nonce in at all?

>>Nearly all protocols out there are insecure.  This is a security WG...
> 
> [A rant?] Tell that to the TLS and the IPSEC guys. Feature-fallback and
> security are not mutually exclusive.

Nonces are not a feature-fallback mechanism.  Nonces prevent replay 
attacks.  If you want feature-fallback, you need to carefully consider 
the mechanism(s) you use.  Overloading the use of nonces as OCSPv1 
progresses up the standards track is wrong, ill-advised and insecure.

		M.

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISqTCC
AtcwggJAoAMCAQICEFgUQCxch7Sxp7XFFauIqpwwDQYJKoZIhvcNAQEFBQAwbDEaMBgGA1UE
ChMRUlNBIFNlY3VyaXR5IEluYy4xHjAcBgNVBAMTFVJTQSBQdWJsaWMgUm9vdCBDQSB2MTEu
MCwGCSqGSIb3DQEJARYfcnNha2VvbnJvb3RzaWduQHJzYXNlY3VyaXR5LmNvbTAeFw0wMjA5
MDYxNDEzNTJaFw0wNzA5MDYxNDEzNTJaMIGCMRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5j
LjEVMBMGA1UECxMMS0NBIFNlcnZpY2VzMRYwFAYDVQQDEw1SU0EgQ29ycG9yYXRlMRAwDgYD
VQQHEwdCZWRmb3JkMRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMQswCQYDVQQGEwJVUzCBnzAN
BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAqnOw876lPpMTkSqrqzpEON/609PDLEhmWX4tkC19
AHneDaoetL277GtYYXBCggP2E+s66MN1ccWXyApfWjCZkIHepPC08NVI1JRcbViW3kwLzDD2
w5T9QJcyL5V1pN/LQdxahM56TiLeXlPiJekdmTdJoo+5Pw4bQU+MxTqURk8CAwEAAaNjMGEw
HwYDVR0jBBgwFoAU9UwxelEDPyzXi5eZb6hxkKt4PZswHQYDVR0OBBYEFO2RCGt0t1lKkvah
HSJwJp8KrxaSMA8GA1UdEwQIMAYBAf8CAQMwDgYDVR0PAQH/BAQDAgGGMA0GCSqGSIb3DQEB
BQUAA4GBAHiSe1a79hnPr16PuBwUTBWbuNQ4GJNsyfrCXzAswIT2A2WtGZ1Hp1jEAWi9OfAX
IYAdy52Jyv9N87wAEbLUgVmsFEIlYM5mi6ag7YIRGp8JP5UhLAN9O5YHrR9FsrGK4WmSl3sY
W1qAPOXubFcfhTgUDIYzM30izZBP4nwO07FpMIIC+DCCAmGgAwIBAgIQeuiOriTayCwjwpmR
gmdIUjANBgkqhkiG9w0BAQUFADCBgjEaMBgGA1UEChMRUlNBIFNlY3VyaXR5IEluYy4xFTAT
BgNVBAsTDEtDQSBTZXJ2aWNlczEWMBQGA1UEAxMNUlNBIENvcnBvcmF0ZTEQMA4GA1UEBxMH
QmVkZm9yZDEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMwHhcNMDIwOTIz
MTkxMzAzWhcNMDYwOTIzMTUxMzAzWjCBjDEaMBgGA1UEChMRUlNBIFNlY3VyaXR5IEluYy4x
FTATBgNVBAsTDEtDQSBTZXJ2aWNlczEgMB4GA1UEAxMXUlNBIENsYXNzIDIgUGVyc29uYWwg
Q0ExEDAOBgNVBAcTB0JlZGZvcmQxFjAUBgNVBAgTDU1hc3NhY2h1c2V0dHMxCzAJBgNVBAYT
AlVTMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCkR9yiabyRo6+NwC3Sl8wPuUiBD3rP
sENNjXvzSbTAyXA8pDDndnlAa1nLUhSMgvn8g1sYMd0Bp+C1/mI5PFUZ8jukUK95yt+TK26L
hM/M5RUq/EINdDDdWzg9je498K6oGfyWR6ETSJbIrDe5qQcLCABs9E2gVKb7Z/FwFo3C9QID
AQABo2MwYTAPBgNVHRMECDAGAQH/AgECMA4GA1UdDwEB/wQEAwIBhjAfBgNVHSMEGDAWgBTt
kQhrdLdZSpL2oR0icCafCq8WkjAdBgNVHQ4EFgQUxpPuxqX+41WOz4ojH+6Y3iHyn6cwDQYJ
KoZIhvcNAQEFBQADgYEAcdRHBjq8GfdDoutUTJPtSzQd7XsdsQh2KBbu8utl92VQHuI0J5wc
Rc817G8YbmTtCt/xqAzrr6k7fdaoDBr/kBuVHA5FEJ94foPgrOlbT3zdziMATXh5ESSDLMx6
p8ITIsTJNmwszIG5P9AAKJCW48gu1ZZmLXhFbHcYJGf99pwwggMFMIICbqADAgECAhEAvhyf
0s21hKaAc2Nm1WX4LTANBgkqhkiG9w0BAQUFADCBuzEkMCIGA1UEBxMbVmFsaUNlcnQgVmFs
aWRhdGlvbiBOZXR3b3JrMRcwFQYDVQQKEw5WYWxpQ2VydCwgSW5jLjE1MDMGA1UECxMsVmFs
aUNlcnQgQ2xhc3MgMyBQb2xpY3kgVmFsaWRhdGlvbiBBdXRob3JpdHkxITAfBgNVBAMTGGh0
dHA6Ly93d3cudmFsaWNlcnQuY29tLzEgMB4GCSqGSIb3DQEJARYRaW5mb0B2YWxpY2VydC5j
b20wHhcNMDIwNDMwMTUzMDE5WhcNMTkwNDMwMDkyMTU1WjBsMRowGAYDVQQKExFSU0EgU2Vj
dXJpdHkgSW5jLjEeMBwGA1UEAxMVUlNBIFB1YmxpYyBSb290IENBIHYxMS4wLAYJKoZIhvcN
AQkBFh9yc2FrZW9ucm9vdHNpZ25AcnNhc2VjdXJpdHkuY29tMIGfMA0GCSqGSIb3DQEBAQUA
A4GNADCBiQKBgQC0dSVa2EQ740GxqiIKsHATT4f8XYwUU23pzRe5W6IVpt4jkwDWkgnvTcP6
M8PD4OfK6Imal4hAH/c3K/dUIH7YyQZRGAE5Y27G5klZYKidcFlrfautgVES170MLKFmJqym
2FWAfVOibXatRcw7B0S+mP9404jID/MaIpRXkH5JjwIDAQABo1cwVTAMBgNVHRMEBTADAQH/
MA4GA1UdDwEB/wQEAwIBhjAWBgNVHSAEDzANMAsGCSqGSIb3DQUGATAdBgNVHQ4EFgQU9Uwx
elEDPyzXi5eZb6hxkKt4PZswDQYJKoZIhvcNAQEFBQADgYEAKsviXBc1FeBT2hIwyWuGwnPZ
J9ctjrsO7NbVLjsx/EYclFFGwo+pphiwdUTml9yd7fXzfk0D+7LOs9ZA5xhiHVrGusV4OW4i
7hx2KVILkYlcXCN5tDltKwa5+BkGUuvZdyAoIhpyf61h7uKCFguhaJ+VOiNB4DPtsmxI+KxO
E6YwggTYMIIEQaADAgECAhBgzHl9dAoZGu0JMqXovSgdMA0GCSqGSIb3DQEBBQUAMIGMMRow
GAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEVMBMGA1UECxMMS0NBIFNlcnZpY2VzMSAwHgYD
VQQDExdSU0EgQ2xhc3MgMiBQZXJzb25hbCBDQTEQMA4GA1UEBxMHQmVkZm9yZDEWMBQGA1UE
CBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMwHhcNMDMwNzA3MjMwODEzWhcNMDQwNzA3
MjMwODEzWjCBvjETMBEGCgmSJomT8ixkARkWA2NvbTEbMBkGCgmSJomT8ixkARkWC3JzYXNl
Y3VyaXR5MRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEWMBQGA1UECxMNTm9ydGggQW1l
cmljYTEUMBIGA1UECxMLRW5naW5lZXJpbmcxFzAVBgNVBAMTDk1hcmMgQnJhbmNoYXVkMScw
JQYJKoZIhvcNAQkBFhhtYXJjbmFyY0Byc2FzZWN1cml0eS5jb20wggEiMA0GCSqGSIb3DQEB
AQUAA4IBDwAwggEKAoIBAQDg2xoRr+a/dtnuFG+oTHa+tGtzeObFazNhYV2iSLNED4fHRu86
tknBYFgXggcHW5gsyjfkCtVMzP2tCivmbJgvISo36vsCsmAJH6LRnJf8HsvfmWZaD9tzhDpL
QVsBHr88J0ZMdVniRc7MQoYeu/3hYtUBeGO9bGA6T8vTrnXYonnFtVoTqE62SFqPZZk7HpCS
X1n+dM3zSym2ylMFYE14nukF4I9vAhsQVzk3QNpghmzGj8uoEy9xpf3k0o5+neneAGvcSkwo
r1mH5tSqhrEQaZp7vuSA2bvXaZEnjZzZiTpPDzs1oMpn3guzYhU7wMKz6xvwvgEYyAAV+P5n
FWM/AgMBAAGjggGBMIIBfTCBkgYDVR0gBIGKMIGHMIGEBgkqhkiG9w0FBwIwdzAuBggrBgEF
BQcCARYiaHR0cDovL2NhLnJzYXNlY3VyaXR5LmNvbS9DUFMuaHRtbDBFBggrBgEFBQcCAjA5
MBgWEVJTQSBTZWN1cml0eSBJbmMuMAMCAQEaHUNQUyBJbmNvcnBvcmF0ZWQgYnkgcmVmZXJl
bmNlMCkGA1UdJQQiMCAGCisGAQQBgjcUAgIGCCsGAQUFBwMCBggrBgEFBQcDBDAjBgNVHREE
HDAagRhtYXJjbmFyY0Byc2FzZWN1cml0eS5jb20wDgYDVR0PAQH/BAQDAgeAMEYGA1UdHwQ/
MD0wO6A5oDeGNWh0dHA6Ly9jcmwucnNhc2VjdXJpdHkuY29tOjgwL1JTQUNsYXNzMlBlcnNv
bmFsQ0EuY3JsMB8GA1UdIwQYMBaAFMaT7sal/uNVjs+KIx/umN4h8p+nMB0GA1UdDgQWBBQ1
yQ/UrvKb563LjzHqJzBzrZp/ejANBgkqhkiG9w0BAQUFAAOBgQCV82oGGnglQQzklKg/wKhy
evNeJ6FNBZFhLlmZRNlKgqvPFmBcxygfBGpHqIhsHcrt2/AjhJuzAj7UdW1vTVCY5MkZw8P9
6+J6aTc3bNlGbk0jvcvVgDhmM4xYJLwMZKEw92HlRhfuMnj7ah9DTqbKSewmyAyOc+FLpGfd
lu6CgTCCBOkwggRSoAMCAQICEQDqxAXqre9Mr+FeYw3+MQhsMA0GCSqGSIb3DQEBBQUAMIGM
MRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEVMBMGA1UECxMMS0NBIFNlcnZpY2VzMSAw
HgYDVQQDExdSU0EgQ2xhc3MgMiBQZXJzb25hbCBDQTEQMA4GA1UEBxMHQmVkZm9yZDEWMBQG
A1UECBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMwHhcNMDMwNzA3MjMwODI4WhcNMDQw
NzA3MjMwODEzWjCBwjETMBEGCgmSJomT8ixkARkWA2NvbTEbMBkGCgmSJomT8ixkARkWC3Jz
YXNlY3VyaXR5MRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEWMBQGA1UECxMNTm9ydGgg
QW1lcmljYTEUMBIGA1UECxMLRW5naW5lZXJpbmcxGzAZBgNVBAMTEk1hcmMgQnJhbmNoYXVk
LUVuYzEnMCUGCSqGSIb3DQEJARYYbWFyY25hcmNAcnNhc2VjdXJpdHkuY29tMIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwBjNaHTwtCXpdJg+iDxYMkWjuZIF0ic2fRLymZe+
BnZYWPnik0dFmTulx+V8slsLEtBllcc5o1yfIYfeHPinwRxv86kCUSlgfGGXKjJZaIeURgbo
bUbIfDTPlvRUZuiZvTR4C8tEY88Lle66n62B7wjUvDbiwK4EjzlXOkjpcYXLH7FbaFaRLDBB
PlFD5ydDRhQ67t6fjUeS7p7o/l/VHmPC5LFLXZkjEhjGd5pknbQIAbUGACL5UET85NUFPowD
3F47g0GCKEnuOsk2Ra+WHu7honhIxqmOwGnu85V6tW5xscf4dTofWZONQeaD3gSxv8+hcfKN
k9cwjpnUG2xGzwIDAQABo4IBjTCCAYkwNQYDVR0lBC4wLAYKKwYBBAGCNxQCAgYIKwYBBQUH
AwIGCCsGAQUFBwMEBgorBgEEAYI3CgMEMIGSBgNVHSAEgYowgYcwgYQGCSqGSIb3DQUHAjB3
MC4GCCsGAQUFBwIBFiJodHRwOi8vY2EucnNhc2VjdXJpdHkuY29tL0NQUy5odG1sMEUGCCsG
AQUFBwICMDkwGBYRUlNBIFNlY3VyaXR5IEluYy4wAwIBARodQ1BTIEluY29ycG9yYXRlZCBi
eSByZWZlcmVuY2UwIwYDVR0RBBwwGoEYbWFyY25hcmNAcnNhc2VjdXJpdHkuY29tMEYGA1Ud
HwQ/MD0wO6A5oDeGNWh0dHA6Ly9jcmwucnNhc2VjdXJpdHkuY29tOjgwL1JTQUNsYXNzMlBl
cnNvbmFsQ0EuY3JsMB8GA1UdIwQYMBaAFMaT7sal/uNVjs+KIx/umN4h8p+nMB0GA1UdDgQW
BBT/OiMCyY8CPnNBySW1ijJOYhj7ejAOBgNVHQ8BAf8EBAMCAzgwDQYJKoZIhvcNAQEFBQAD
gYEAlchAObA9eVmeiLu0nTU985Fch6v+EZKodUhZUN7dILgd05HorHN9jxBH6XI4/b9ZVvub
Pkpicdc112YbcLYTD2NumVksyNDI7fDaqiszgk1zluXtZJ+HsCt+GIAKCDfOVLECclpGyizq
VjZFEK4Pt9FxPGTnUJEvIKJcAQ24EvgxggPsMIID6AIBATCBoTCBjDEaMBgGA1UEChMRUlNB
IFNlY3VyaXR5IEluYy4xFTATBgNVBAsTDEtDQSBTZXJ2aWNlczEgMB4GA1UEAxMXUlNBIENs
YXNzIDIgUGVyc29uYWwgQ0ExEDAOBgNVBAcTB0JlZGZvcmQxFjAUBgNVBAgTDU1hc3NhY2h1
c2V0dHMxCzAJBgNVBAYTAlVTAhBgzHl9dAoZGu0JMqXovSgdMAkGBSsOAwIaBQCgggIfMBgG
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMTEyNzIzNTMxMlow
IwYJKoZIhvcNAQkEMRYEFLW2dYaf1IqBY/ZioLQGJckNxmxhMFIGCSqGSIb3DQEJDzFFMEMw
CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G
CCqGSIb3DQMCAgEoMIGzBgkrBgEEAYI3EAQxgaUwgaIwgYwxGjAYBgNVBAoTEVJTQSBTZWN1
cml0eSBJbmMuMRUwEwYDVQQLEwxLQ0EgU2VydmljZXMxIDAeBgNVBAMTF1JTQSBDbGFzcyAy
IFBlcnNvbmFsIENBMRAwDgYDVQQHEwdCZWRmb3JkMRYwFAYDVQQIEw1NYXNzYWNodXNldHRz
MQswCQYDVQQGEwJVUwIRAOrEBeqt70yv4V5jDf4xCGwwgbUGCyqGSIb3DQEJEAILMYGloIGi
MIGMMRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEVMBMGA1UECxMMS0NBIFNlcnZpY2Vz
MSAwHgYDVQQDExdSU0EgQ2xhc3MgMiBQZXJzb25hbCBDQTEQMA4GA1UEBxMHQmVkZm9yZDEW
MBQGA1UECBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMCEQDqxAXqre9Mr+FeYw3+MQhs
MA0GCSqGSIb3DQEBAQUABIIBAHekN1TmYFMZYaSnXjLIenW+E6g/oEtdeiTaNwLraITq/+1+
5eMEw52yMiljaTQcIAzn/xe3v+vaUmA4doOWyiXJIyrFxnJlSzL9B+aYiCxlDY7p+qRQ9usS
tnn5HHPn1bkUNScFHKEBFrxKEOyjouCQWVaCDLd2A6zjnsjqUoKfIp5wkNRojGjxHgWiRYry
rnQbmnKzlGz6z5NosZz5tMwzu20jsuIBlqlcEjBk85msEiej9VAkbCzd3TMEtnVDj+l8Zj67
X8e8GAe2/YR7K4thCpsxvhYkJYaZ0ZfLruTu8P094K4iR2HWu8wzUsVWPpnLBFXlQ2F7IbfJ
ejbX+GoAAAAAAAA=
--------------ms020802090503030700060305--


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASGLcib007097 for <[e-mail]>; Fri, 28 Nov 2003 08:21:38 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hASGLcHv007096 for ietf-pkix-bks; Fri, 28 Nov 2003 08:21:38 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.smarttrust.com ([213.212.5.232]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASGL8j7006970 for <[e-mail]>; Fri, 28 Nov 2003 08:21:36 -0800 (PST) (envelope-from [e-mail])
Received: from sek43.smarttrust.com ([172.16.0.43]) by mail.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 17:22:15 +0100
Received: from mail pickup service by sek43.smarttrust.com with Microsoft SMTPSVC; Fri, 28 Nov 2003 17:21:18 +0100
Received: from mail.smarttrust.com ([192.168.1.10]) by sek43.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 12:03:31 +0100
Received: from sek13 ([192.168.1.15]) by mail.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 12:04:16 +0100
Received: from [208.184.76.39]:4104 (EHLO above.proper.com) by sek13.smarttrust.com ([192.168.1.15]:25) (F-Secure Anti-Virus for Internet Mail 6.0.34 Release) with SMTP; Fri, 28 Nov 2003 11:02:47 -0000
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9krib085829 for <[e-mail]>; Fri, 28 Nov 2003 01:46:53 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAS9krbe085827 for ietf-pkix-bks; Fri, 28 Nov 2003 01:46:53 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from relhubc02-ukbr.tcrelay.net ([217.32.166.20]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9kpib085784 for <[e-mail]>; Fri, 28 Nov 2003 01:46:51 -0800 (PST) (envelope-from [e-mail])
Received: from mail pickup service by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC; Fri, 28 Nov 2003 09:40:56 +0000
Received: from above.proper.com ([208.184.76.39]) by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 26 Nov 2003 17:03:57 +0000
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQGvFib031847 for <[e-mail]>; Wed, 26 Nov 2003 08:57:15 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQGvFPk031846 for ietf-pkix-bks; Wed, 26 Nov 2003 08:57:15 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.cs.auckland.ac.nz (csmail.cs.auckland.ac.nz [130.216.33.150]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQGvEib031841 for <[e-mail]>; Wed, 26 Nov 2003 08:57:14 -0800 (PST) (envelope-from [e-mail])
Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id 5930863C1D; Thu, 27 Nov 2003 05:57:15 +1300 (NZDT)
Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id hAQGxm001648; Thu, 27 Nov 2003 05:59:48 +1300
Date: Thu, 27 Nov 2003 05:59:48 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Certificate Policy Standardization
Cc: [e-mail]
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-OriginalArrivalTime: 26 Nov 2003 17:05:08.0504 (UTC) FILETIME=[71FFE180:01C3B43F]
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
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>

Stephen Kent <[e-mail]> writes:

>one might ask why the most widely distributed product that claims to
>implement IPsec  (Windows) does not provide a user/administrator the ability
>to order SPD entries, as required by RFC 2401. The answer is that the
>implementors did not understand why this was an important (in the case of
>IPsec, a critical) aspect of the standard and so the implementors omitted an
>important management control.
>
>what one can learn from this an similar examples is that vendors are a very
>poor basis for determining the worth of a feature in a standard. 

Actually what I learn from this is that complex standards with often
incomprehensible requirements are just asking for trouble if they don't
include a rationale.  Even a single sentence explaining the background behind
the SPD entry ordering would have prevented this in a manner that no amount of
MUSTs/SHALLs ever can.

Peter.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASGLaib007085 for <[e-mail]>; Fri, 28 Nov 2003 08:21:36 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hASGLaED007084 for ietf-pkix-bks; Fri, 28 Nov 2003 08:21:36 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.smarttrust.com ([213.212.5.232]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASGL8j5006970 for <[e-mail]>; Fri, 28 Nov 2003 08:21:33 -0800 (PST) (envelope-from [e-mail])
Received: from sek43.smarttrust.com ([172.16.0.43]) by mail.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 17:22:12 +0100
Received: from mail pickup service by sek43.smarttrust.com with Microsoft SMTPSVC; Fri, 28 Nov 2003 17:21:10 +0100
Received: from mail.smarttrust.com ([192.168.1.10]) by sek43.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 12:16:59 +0100
Received: from sek13 ([192.168.1.15]) by mail.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 12:17:44 +0100
Received: from [208.184.76.39]:4098 (EHLO above.proper.com) by sek13.smarttrust.com ([192.168.1.15]:25) (F-Secure Anti-Virus for Internet Mail 6.0.34 Release) with SMTP; Fri, 28 Nov 2003 11:16:15 -0000
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9jQib085370 for <[e-mail]>; Fri, 28 Nov 2003 01:45:26 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAS9jQ9N085368 for ietf-pkix-bks; Fri, 28 Nov 2003 01:45:26 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from relhubc02-ukbr.tcrelay.net ([217.32.166.20]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9jNid085302 for <[e-mail]>; Fri, 28 Nov 2003 01:45:25 -0800 (PST) (envelope-from [e-mail])
Received: from mail pickup service by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC; Fri, 28 Nov 2003 09:39:33 +0000
Received: from above.proper.com ([208.184.76.39]) by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 26 Nov 2003 16:48:48 +0000
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQFdYib027926 for <[e-mail]>; Wed, 26 Nov 2003 07:39:34 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQFdYCA027925 for ietf-pkix-bks; Wed, 26 Nov 2003 07:39:34 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.cs.auckland.ac.nz (csmail.cs.auckland.ac.nz [130.216.33.150]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQFdWib027920 for <[e-mail]>; Wed, 26 Nov 2003 07:39:33 -0800 (PST) (envelope-from [e-mail])
Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id 8818063C1D; Thu, 27 Nov 2003 04:39:33 +1300 (NZDT)
Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id hAQFg5L01342; Thu, 27 Nov 2003 04:42:05 +1300
Date: Thu, 27 Nov 2003 04:42:05 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Certificate Policy Standardization
Cc: [e-mail], [e-mail]
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-OriginalArrivalTime: 26 Nov 2003 16:49:33.0097 (UTC) FILETIME=[44741990:01C3B43D]
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
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>

Stephen Kent <[e-mail]> writes:

>For example, most certs used with IKE will not be subject to some attorney's
>advice, I suspect.

Actually now that you mention it one of the three classes of certs that were
going to be used in the situation I mentioned were IKE certs.  I think they
were going to subclass "doWhatISay" into "doWhatISayWithIKE",
"doWhatISayWithSSL", and "doWhatISayWithSMIMESigning"(not sure about the last
one, I have the paperwork downstairs but I'm too lazy to look it up).  All of
them were going to go through the full legal wringer.

Peter.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASGLYib007077 for <[e-mail]>; Fri, 28 Nov 2003 08:21:34 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hASGLYI1007076 for ietf-pkix-bks; Fri, 28 Nov 2003 08:21:34 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.smarttrust.com ([213.212.5.232]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASGL8j3006970 for <[e-mail]>; Fri, 28 Nov 2003 08:21:32 -0800 (PST) (envelope-from [e-mail])
Received: from sek43.smarttrust.com ([172.16.0.43]) by mail.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 17:22:08 +0100
Received: from mail pickup service by sek43.smarttrust.com with Microsoft SMTPSVC; Fri, 28 Nov 2003 17:21:20 +0100
Received: from mail.smarttrust.com ([192.168.1.10]) by sek43.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 11:49:32 +0100
Received: from sek13 ([192.168.1.15]) by mail.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 11:50:17 +0100
Received: from [208.184.76.39]:1306 (EHLO above.proper.com) by sek13.smarttrust.com ([192.168.1.15]:25) (F-Secure Anti-Virus for Internet Mail 6.0.34 Release) with SMTP; Fri, 28 Nov 2003 10:48:48 -0000
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS90Iib070776 for <[e-mail]>; Fri, 28 Nov 2003 01:00:18 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAS90IVI070774 for ietf-pkix-bks; Fri, 28 Nov 2003 01:00:18 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from www16.your-server.de (IDENT:[e-mail] [213.133.104.16]) by above.proper.com (8.12.10/8.12.8) with SMTP id hAS90Eib070724 for <[e-mail]>; Fri, 28 Nov 2003 01:00:17 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 30347 invoked by uid 1649); 28 Nov 2003 09:00:09 -0000
Date: 28 Nov 2003 09:00:09 -0000
Message-ID: <[e-mail]>
From: "Florian Oelmaier" <[e-mail]>
To: Marc Branchaud <[e-mail]>, [e-mail]
Subject: Re: DISCUSS:  MUST  reject in OCSPv1
References:   <>
In-Reply-To:  <>
X-Mailer: oMail 0.98.2 - http://webmail.omnis.ch
X-IPAddress: 195.212.95.34
X-Sender: [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-OriginalArrivalTime: 28 Nov 2003 10:50:17.0609 (UTC) FILETIME=[69352790:01C3B59D]
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 client puts a nonce in a request and doesn't behave differently 
> depending on the presence/absence of the nonce in the response, then why 
> put the nonce in at all?

I agree. But the client behaves differently! It may
- display a warning to the user
- apply another local policy regarding time checking
- add additional measures to ensure freshness if a nonce is not present
- etc.

-- 
Florian Oelmaier
SyTrust



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASGLWib007069 for <[e-mail]>; Fri, 28 Nov 2003 08:21:32 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hASGLWMO007068 for ietf-pkix-bks; Fri, 28 Nov 2003 08:21:32 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.smarttrust.com ([213.212.5.232]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASGL8j1006970 for <[e-mail]>; Fri, 28 Nov 2003 08:21:31 -0800 (PST) (envelope-from [e-mail])
Received: from sek43.smarttrust.com ([172.16.0.43]) by mail.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 17:22:06 +0100
Received: from mail pickup service by sek43.smarttrust.com with Microsoft SMTPSVC; Fri, 28 Nov 2003 17:21:19 +0100
Received: from mail.smarttrust.com ([192.168.1.10]) by sek43.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 12:10:49 +0100
Received: from sek13 ([192.168.1.15]) by mail.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 12:11:34 +0100
Received: from [208.184.76.39]:1852 (EHLO above.proper.com) by sek13.smarttrust.com ([192.168.1.15]:25) (F-Secure Anti-Virus for Internet Mail 6.0.34 Release) with SMTP; Fri, 28 Nov 2003 11:10:05 -0000
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9oiib086371 for <[e-mail]>; Fri, 28 Nov 2003 01:50:44 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAS9oiCt086370 for ietf-pkix-bks; Fri, 28 Nov 2003 01:50:44 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from relhubc02-ukbr.tcrelay.net ([217.32.166.20]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9ogib086350 for <[e-mail]>; Fri, 28 Nov 2003 01:50:43 -0800 (PST) (envelope-from [e-mail])
Received: from mail pickup service by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC; Fri, 28 Nov 2003 09:44:48 +0000
Received: from above.proper.com ([208.184.76.39]) by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 26 Nov 2003 18:39:05 +0000
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQHbnib034140 for <[e-mail]>; Wed, 26 Nov 2003 09:37:49 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQHbmO8034139 for ietf-pkix-bks; Wed, 26 Nov 2003 09:37:48 -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.10/8.12.8) with ESMTP id hAQHblib034129 for <[e-mail]>; Wed, 26 Nov 2003 09:37:47 -0800 (PST) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id hAQHbesj027338; Wed, 26 Nov 2003 12:37:41 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p06010210bbea90868896@[128.89.89.75]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Wed, 26 Nov 2003 12:33:48 -0500
To: [e-mail] (Peter Gutmann)
From: Stephen Kent <[e-mail]>
Subject: Re: Certificate Policy Standardization
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-OriginalArrivalTime: 26 Nov 2003 18:39:06.0164 (UTC) FILETIME=[924E8740:01C3B44C]
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
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 5:59 +1300 11/27/03, Peter Gutmann wrote:
>Stephen Kent <[e-mail]> writes:
>
>>one might ask why the most widely distributed product that claims to
>>implement IPsec  (Windows) does not provide a user/administrator the ability
>>to order SPD entries, as required by RFC 2401. The answer is that the
>>implementors did not understand why this was an important (in the case of
>>IPsec, a critical) aspect of the standard and so the implementors omitted an
>>important management control.
>>
>>what one can learn from this an similar examples is that vendors are a very
>>poor basis for determining the worth of a feature in a standard.
>
>Actually what I learn from this is that complex standards with often
>incomprehensible requirements are just asking for trouble if they don't
>include a rationale.  Even a single sentence explaining the background behind
>the SPD entry ordering would have prevented this in a manner that no amount of
>MUSTs/SHALLs ever can.
>
>Peter.

The SPD is an ordered list for the same reason that ACLs have been 
ordered in operating systems for last 30 years, and in firewalls and 
routers for the last decade.  At what point does one not have to 
provide rationale?

Implementors of a technology ought (MUST/SHALL?) be competent in the 
technology that they are implementing. A standard like IPsec is not a 
"Secure Communication  Protocols for Dummies" document.

Steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASGLVib007059 for <[e-mail]>; Fri, 28 Nov 2003 08:21:31 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hASGLV1K007058 for ietf-pkix-bks; Fri, 28 Nov 2003 08:21:31 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.smarttrust.com ([213.212.5.232]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASGL8ix006970 for <[e-mail]>; Fri, 28 Nov 2003 08:21:29 -0800 (PST) (envelope-from [e-mail])
Received: from sek43.smarttrust.com ([172.16.0.43]) by mail.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 17:22:06 +0100
Received: from mail pickup service by sek43.smarttrust.com with Microsoft SMTPSVC; Fri, 28 Nov 2003 17:21:19 +0100
Received: from mail.smarttrust.com ([192.168.1.10]) by sek43.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 12:25:07 +0100
Received: from sek13 ([192.168.1.15]) by mail.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 12:25:52 +0100
Received: from [208.184.76.39]:2533 (EHLO above.proper.com) by sek13.smarttrust.com ([192.168.1.15]:25) (F-Secure Anti-Virus for Internet Mail 6.0.34 Release) with SMTP; Fri, 28 Nov 2003 11:24:22 -0000
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9rfib086502 for <[e-mail]>; Fri, 28 Nov 2003 01:53:41 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAS9rfvZ086501 for ietf-pkix-bks; Fri, 28 Nov 2003 01:53:41 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from relhubc02-ukbr.tcrelay.net ([217.32.166.20]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9rcid086487 for <[e-mail]>; Fri, 28 Nov 2003 01:53:40 -0800 (PST) (envelope-from [e-mail])
Received: from mail pickup service by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC; Fri, 28 Nov 2003 09:47:50 +0000
Received: from above.proper.com ([208.184.76.39]) by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 26 Nov 2003 16:24:53 +0000
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQFDJib026445 for <[e-mail]>; Wed, 26 Nov 2003 07:13:19 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQFDJpE026444 for ietf-pkix-bks; Wed, 26 Nov 2003 07:13:19 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail4.it-norr.com ([80.244.64.43]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQFDHib026437 for <[e-mail]>; Wed, 26 Nov 2003 07:13:17 -0800 (PST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Received: from HANSTOSHIBA ([217.211.59.248]) by mail4.it-norr.com (IT-NORR Mail Cluster v2003) with ASMTP id DUA74354 for <[e-mail]>; Wed, 26 Nov 2003 16:13:15 +0100
From: "Hans Nilsson" <[e-mail]>
To: <[e-mail]>
Subject: RE: Certificate Policy Standardization
Date: Wed, 26 Nov 2003 16:12:53 +0100
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.2800.1165
thread-index: AcO0KecT/TLEeVeFQcqZodb6XFOSFQABQ0Gw
In-Reply-To: <025b01c3b421$683107b0$0500a8c0@arport>
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-OriginalArrivalTime: 26 Nov 2003 16:25:52.0129 (UTC) FILETIME=[F57D9710:01C3B439]
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
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 know of at least one CA product (SmartTrust Certificate Manager) which can
supports multiple issuance of certs (with different CPs) per CA root.

I know that this feature also is used by several of SmartTrust's customers,
for example for distinguishing between different issuing procedures and/or
private key storage media.

And when talking about Relying Party software, we do not usually mean
Outlook Express. After all, secure e-mail is not the number 1 PKI
application. 
Instead, RPs are usually servers, validating signatures in e-government and
e-banking applications. And RP software (from MS and others) can pick out
any field of a certificate and make a decision based on that.

Hans

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
On
> Behalf Of Anders Rundgren
> Sent: Wednesday, November 26, 2003 2:30 PM
> To: [e-mail]
> Subject: Re: Certificate Policy Standardization
> 
> 
> Hum,
> 
> I wonder how many times I have to repeat the same very basic
> questions and only getting answers back in "ASN.1"?  Sort of.
> So here we go again...
> 
> 1. Why does practically no shrink-wrap PKI-enabled software
> package support any kind of certificate policy settings?
> 
> 2. And why do few if any commercial CAs support multiple
> issuances (i.e. different CPs) per CA root?
> 
> Because they have understood the problems associated?
> Because they enjoy "violating" standards?
> Because they are ignorant?
> Because their budget is too limited?
> Other?
> 
> Anders
> 
> ----- Original Message -----
> From: "Santosh Chokhani" <[e-mail]>
> To: <[e-mail]>
> Sent: Wednesday, November 26, 2003 12:04
> Subject: RE: Certificate Policy Standardization
> 
> 
> 
> Anders:
> 
> The relying parties are free to ignore the policies and policy related
> extensions altogether and verify paths.  The certification path will
verify
> unless:
> 
> 1.  One or more CAs in the path require that the certification path be
valid
> for a policy; or
> 
> 2.  Make the policy related extensions critical.
> 
> While some may view the two conditions as interoperability problem, I view
> it CA(s) saying that I do not want you to use the certificate unless you
> understand and abide by constraints I impose on the certificates.
> 
> The current X.509 and RFC 3280 permit you build PKI and applications that
do
> not use certificate policies.  So, I do not quite understand your concern
> below.
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
On
> Behalf Of Anders Rundgren
> Sent: Wednesday, November 26, 2003 4:03 AM
> To: Santosh Chokhani; [e-mail]
> Subject: Re: Certificate Policy Standardization
> 
> 
> 
> 
> >I am not what you mean by ".....another useless PKIX bloat extension".
> 
> >If properly used by the CA and relying party systems, the certificate
> >policy OID can be used to provide amount of trust the relying party
> >should place in a certificate.
> 
> What Michael referred to as "bloat" is not policy identifiers themselves
but
> that they need another trust adminstration GUI and associated hassles.
> 
> Policy identifiers used for path validation purposes is indeed a very
> "fancy" thing from a technical point of view (maybe 2% of the people
> subscribed to the PKIX list can understand this part of RFC3280...), but
> from an interoperability point of view they are not that great.
> 
> Hum, there simply must be a reason why practically all commercial CAs have
> selected an entirely different approach.  And that they did this
completely
> on their own without any commitee descision etc.
> 
> I wonder how this really happend.   Could it be...
> 
>     that it sort of feels "natural"?
> 
> /a
> 





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASGLTib007051 for <[e-mail]>; Fri, 28 Nov 2003 08:21:29 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hASGLTTG007050 for ietf-pkix-bks; Fri, 28 Nov 2003 08:21:29 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.smarttrust.com ([213.212.5.232]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASGL8iv006970 for <[e-mail]>; Fri, 28 Nov 2003 08:21:26 -0800 (PST) (envelope-from [e-mail])
Received: from sek43.smarttrust.com ([172.16.0.43]) by mail.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 17:22:04 +0100
Received: from mail pickup service by sek43.smarttrust.com with Microsoft SMTPSVC; Fri, 28 Nov 2003 17:21:14 +0100
Received: from mail.smarttrust.com ([192.168.1.10]) by sek43.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 12:10:24 +0100
Received: from sek13 ([192.168.1.15]) by mail.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 12:11:09 +0100
Received: from [208.184.76.39]:1696 (EHLO above.proper.com) by sek13.smarttrust.com ([192.168.1.15]:25) (F-Secure Anti-Virus for Internet Mail 6.0.34 Release) with SMTP; Fri, 28 Nov 2003 11:09:41 -0000
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9mfib086302 for <[e-mail]>; Fri, 28 Nov 2003 01:48:41 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAS9mfdC086301 for ietf-pkix-bks; Fri, 28 Nov 2003 01:48:41 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from relhubc02-ukbr.tcrelay.net ([217.32.166.20]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9meib086296 for <[e-mail]>; Fri, 28 Nov 2003 01:48:40 -0800 (PST) (envelope-from [e-mail])
Received: from mail pickup service by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC; Fri, 28 Nov 2003 09:42:45 +0000
Received: from above.proper.com ([208.184.76.39]) by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 26 Nov 2003 16:29:15 +0000
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQF7kib026184 for <[e-mail]>; Wed, 26 Nov 2003 07:07:46 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQF7kno026183 for ietf-pkix-bks; Wed, 26 Nov 2003 07:07:46 -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.10/8.12.8) with ESMTP id hAQF7jib026174 for <[e-mail]>; Wed, 26 Nov 2003 07:07:45 -0800 (PST) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id hAQF7esj017220; Wed, 26 Nov 2003 10:07:40 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p06010205bbea7029f2b0@[128.89.89.75]>
In-Reply-To: <025b01c3b421$683107b0$0500a8c0@arport>
References: <033e01c3b40d$0b962670$[e-mail]> <025b01c3b421$683107b0$0500a8c0@arport>
Date: Wed, 26 Nov 2003 10:06:41 -0500
To: "Anders Rundgren" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Certificate Policy Standardization
Cc: <[e-mail]>
Content-Type: multipart/alternative; boundary="============_-1142263285==_ma============"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-OriginalArrivalTime: 26 Nov 2003 16:29:55.0363 (UTC) FILETIME=[86782730:01C3B43A]
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
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>

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

At 14:30 +0100 11/26/03, Anders Rundgren wrote:
>Hum,
>
>I wonder how many times I have to repeat the same very basic
>questions and only getting answers back in "ASN.1"?  Sort of.
>So here we go again...
>
>1. Why does practically no shrink-wrap PKI-enabled software
>package support any kind of certificate policy settings?

one might ask why the most widely distributed product that claims to 
implement IPsec  (Windows) does not provide a user/administrator the 
ability to order SPD entries, as required by RFC 2401. The answer is 
that the implementors did not understand why this was an important 
(in the case of IPsec, a critical) aspect of the standard and so the 
implementors omitted an important management control.

what one can learn from this an similar examples is that vendors are 
a very poor basis for determining the worth of a feature in a 
standard. a very big vendor can screw up an implementation and get 
away with it due to market dominance. other vendors, eager to be 
compatible with the dominant vendor, follow suit.  most users may not 
understand a complex technology and don't know what's missing.

>2. And why do few if any commercial CAs support multiple
>issuances (i.e. different CPs) per CA root?
>
>Because they have understood the problems associated?

sometimes, but rarely, in my experience.

>Because they enjoy "violating" standards?

"enjoy" is probably the wrong term, but "don't care" is accurate.

>Because they are ignorant?

sometimes, yes!

>Because their budget is too limited?

prioritization of development resources, combined with time to market 
pressure is often the reason that a vendor omits certain features.

>Other?

yes, you left out implementors who have decided that in the market 
niche of interest to them, they have a "better" way of implementing a 
capability that is incompatible with the standard and so they pursue 
their proprietary approach.

Steve
--============_-1142263285==_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: Certificate Policy
Standardization</title></head><body>
<div>At 14:30 +0100 11/26/03, Anders Rundgren wrote:</div>
<blockquote type="cite" cite>Hum,<br>
<br>
I wonder how many times I have to repeat the same very basic<br>
questions and only getting answers back in &quot;ASN.1&quot;?&nbsp;
Sort of.<br>
So here we go again...<br>
<br>
1. Why does practically no shrink-wrap PKI-enabled software<br>
package support any kind of certificate policy settings?</blockquote>
<div><br></div>
<div>one might ask why the most widely distributed product that claims
to implement IPsec&nbsp; (Windows) does not provide a
user/administrator the ability to order SPD entries, as required by
RFC 2401. The answer is that the implementors did not understand why
this was an important (in the case of IPsec, a<u> critical</u>) aspect
of the standard and so the implementors omitted an important
management control.</div>
<div><br></div>
<div>what one can learn from this an similar examples is that vendors
are a very poor basis for determining the worth of a feature in a
standard. a very big vendor can screw up an implementation and get
away with it due to market dominance. other vendors, eager to be
compatible with the dominant vendor, follow suit.&nbsp; most users may
not understand a complex technology and don't know what's
missing.</div>
<div><br></div>
<blockquote type="cite" cite>2. And why do few if any commercial CAs
support multiple<br>
issuances (i.e. different CPs) per CA root?<br>
<br>
Because they have understood the problems associated?</blockquote>
<div><br>
sometimes, but rarely, in my experience.<br>
</div>
<blockquote type="cite" cite>Because they enjoy &quot;violating&quot;
standards?</blockquote>
<div><br></div>
<div>&quot;enjoy&quot; is probably the wrong term, but &quot;don't
care&quot; is accurate.</div>
<div><br></div>
<blockquote type="cite" cite>Because they are ignorant?</blockquote>
<div><br></div>
<div>sometimes, yes!</div>
<div><br></div>
<blockquote type="cite" cite>Because their budget is too
limited?</blockquote>
<div><br></div>
<div>prioritization of development resources, combined with time to
market pressure is often the reason that a vendor omits certain
features.</div>
<div><br></div>
<blockquote type="cite" cite>Other?</blockquote>
<div><br></div>
<div>yes, you left out implementors who have decided that in the
market niche of interest to them, they have a &quot;better&quot; way
of implementing a capability that is incompatible with the standard
and so they pursue their proprietary approach.</div>
<div><br></div>
<div>Steve</div>
</body>
</html>
--============_-1142263285==_ma============--


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASGLQib007044 for <[e-mail]>; Fri, 28 Nov 2003 08:21:26 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hASGLQlF007043 for ietf-pkix-bks; Fri, 28 Nov 2003 08:21:26 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.smarttrust.com ([213.212.5.232]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASGL8it006970 for <[e-mail]>; Fri, 28 Nov 2003 08:21:23 -0800 (PST) (envelope-from [e-mail])
Received: from sek43.smarttrust.com ([172.16.0.43]) by mail.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 17:22:02 +0100
Received: from mail pickup service by sek43.smarttrust.com with Microsoft SMTPSVC; Fri, 28 Nov 2003 17:21:12 +0100
Received: from mail.smarttrust.com ([192.168.1.10]) by sek43.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 12:24:34 +0100
Received: from sek13 ([192.168.1.15]) by mail.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 12:25:19 +0100
Received: from [208.184.76.39]:2377 (EHLO above.proper.com) by sek13.smarttrust.com ([192.168.1.15]:25) (F-Secure Anti-Virus for Internet Mail 6.0.34 Release) with SMTP; Fri, 28 Nov 2003 11:23:50 -0000
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9m6ib086246 for <[e-mail]>; Fri, 28 Nov 2003 01:48:06 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAS9m6Kk086244 for ietf-pkix-bks; Fri, 28 Nov 2003 01:48:06 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from relhubc02-ukbr.tcrelay.net ([217.32.166.20]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9m4ib086205 for <[e-mail]>; Fri, 28 Nov 2003 01:48:05 -0800 (PST) (envelope-from [e-mail])
Received: from mail pickup service by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC; Fri, 28 Nov 2003 09:42:10 +0000
Received: from above.proper.com ([208.184.76.39]) by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 26 Nov 2003 16:50:20 +0000
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQGj9ib031373 for <[e-mail]>; Wed, 26 Nov 2003 08:45:09 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQGj9i0031372 for ietf-pkix-bks; Wed, 26 Nov 2003 08:45:09 -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.10/8.12.8) with ESMTP id hAQGj7ib031367 for <[e-mail]>; Wed, 26 Nov 2003 08:45:07 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (127.0.0.1) by nic.lp.se (MX V5.3 VnHj) with ESMTP; Wed, 26 Nov 2003 17:44:59 +0100
Date: Wed, 26 Nov 2003 17:44:58 +0100 (CET)
Message-ID: <[e-mail]>
To: [e-mail]
CC: [e-mail], [e-mail]
Subject: Re: Certificate Policy Standardization
From: Richard Levitte - VMS Whacker <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
X-URL: http://www.lp.se/
X-Waved: dead chicken, GNU emacs 21.3.1, Mew version 4.0.60
X-Mew: See http://www.mew.org/
X-Mailer: Mew version 4.0.60 on Emacs 21.3.1 / Mule 5.0 (SAKAKI)
MIME-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-OriginalArrivalTime: 26 Nov 2003 16:51:07.0863 (UTC) FILETIME=[7CF03E70:01C3B43D]
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
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 Thu, 27 Nov 2003 04:13:30 +1300, [e-mail] (Peter Gutmann) said:

pgut001> "Anders Rundgren" <[e-mail]> writes:
pgut001> 
pgut001> >1. Why does practically no shrink-wrap PKI-enabled software package support
pgut001> >any kind of certificate policy settings?
pgut001> 
pgut001> Zero demand.  Heck, it wasn't too long ago that MS PKI
pgut001> software hardcoded the Verisign policy into CryptoAPI, so
pgut001> that no matter what the actual policy was in the cert, what
pgut001> was displayed was the Verisign policy.  That shows how much
pgut001> attention people are paying to the policy stuff.

Let's take note of what Peter says here.  First, M$ did some
hardcoding, which they have subsequently changed (I got that right, I
hope).  That means M$ is capable of change, and does listen to some
concerns.  Sure, that's pretty slow development, but development
still.  A bunch more times with a LART, and even M$ might do policy
checks :-).

pgut001> ...  So the trusted-roots mechanism does what the policy
pgut001> extension is supposed to do,

Which only works as long as the formula CA<=>Policy is true...

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.
You don't have to be rich, a $10 donation is appreciated!

-- 
Richard Levitte     | http://richard.levitte.org/ | Tunnlandsv. 3
Levitte Programming | http://www.lp.se/           | S-168 36 Bromma
T: [phone] |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASGLNib007037 for <[e-mail]>; Fri, 28 Nov 2003 08:21:23 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hASGLNu3007036 for ietf-pkix-bks; Fri, 28 Nov 2003 08:21:23 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.smarttrust.com ([213.212.5.232]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASGL8ir006970 for <[e-mail]>; Fri, 28 Nov 2003 08:21:22 -0800 (PST) (envelope-from [e-mail])
Received: from sek43.smarttrust.com ([172.16.0.43]) by mail.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 17:22:01 +0100
Received: from mail pickup service by sek43.smarttrust.com with Microsoft SMTPSVC; Fri, 28 Nov 2003 17:21:13 +0100
Received: from mail.smarttrust.com ([192.168.1.10]) by sek43.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 12:10:18 +0100
Received: from sek13 ([192.168.1.15]) by mail.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 12:11:03 +0100
Received: from [208.184.76.39]:1664 (EHLO above.proper.com) by sek13.smarttrust.com ([192.168.1.15]:25) (F-Secure Anti-Virus for Internet Mail 6.0.34 Release) with SMTP; Fri, 28 Nov 2003 11:09:34 -0000
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9tsib086617 for <[e-mail]>; Fri, 28 Nov 2003 01:55:54 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAS9trZw086616 for ietf-pkix-bks; Fri, 28 Nov 2003 01:55:53 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from relhubc02-ukbr.tcrelay.net ([217.32.166.20]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9tqib086610 for <[e-mail]>; Fri, 28 Nov 2003 01:55:53 -0800 (PST) (envelope-from [e-mail])
Received: from mail pickup service by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC; Fri, 28 Nov 2003 09:49:58 +0000
Received: from above.proper.com ([208.184.76.39]) by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 26 Nov 2003 14:31:30 +0000
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQBaPib013852 for <[e-mail]>; Wed, 26 Nov 2003 03:36:25 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQBaPrM013851 for ietf-pkix-bks; Wed, 26 Nov 2003 03:36:25 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp4.hy.skanova.net (smtp4.hy.skanova.net [195.67.199.133]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQBaOib013844 for <[e-mail]>; Wed, 26 Nov 2003 03:36:25 -0800 (PST) (envelope-from [e-mail])
Received: from arport (t11o913p109.telia.com [213.64.28.109]) by smtp4.hy.skanova.net (8.12.10/8.12.10) with SMTP id hAQBaMBZ006267; Wed, 26 Nov 2003 12:36:22 +0100 (CET)
Message-ID: <00f901c3b410$fda8f250$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>, "Richard Levitte - VMS Whacker" <[e-mail]>, =?iso-8859-1?Q?Michael_Str=F6der?= <[e-mail]>
References: <[e-mail]>
Subject: Re: Certificate Policy Standardization
Date: Wed, 26 Nov 2003 12:31:19 +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
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-OriginalArrivalTime: 26 Nov 2003 14:31:30.0507 (UTC) FILETIME=[FBA529B0:01C3B429]
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
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>

>For me, OIDs are yet to have their time. As a concept they are elegant
>but will resist widespread use until security-exploiting applications
>support them. Until then they are destined to stay on the back-burner.

Sure.

>I encourage people to adopt their use, however, if only to future-proof
>themselves and I don't see any harm whatsoever in embedding in a certificate
>some mechanism that links the trust level it represents to a real-world
>legal mechanism, even if at present the software support for such a link
>is absent.

In case you are advicing people setting up CAs, I would (in case the
CP OID stuff stays forever in the backburner), also recommend them
to only apply one CP per CA root, as anyhting else is actually
incompatible with some 99.9% of existing RP software.

/anders



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASGLMib007030 for <[e-mail]>; Fri, 28 Nov 2003 08:21:22 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hASGLMQh007029 for ietf-pkix-bks; Fri, 28 Nov 2003 08:21:22 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.smarttrust.com ([213.212.5.232]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASGL8ip006970 for <[e-mail]>; Fri, 28 Nov 2003 08:21:21 -0800 (PST) (envelope-from [e-mail])
Received: from sek43.smarttrust.com ([172.16.0.43]) by mail.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 17:21:58 +0100
Received: from mail pickup service by sek43.smarttrust.com with Microsoft SMTPSVC; Fri, 28 Nov 2003 17:21:09 +0100
Received: from mail.smarttrust.com ([192.168.1.10]) by sek43.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 12:16:55 +0100
Received: from sek13 ([192.168.1.15]) by mail.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 12:17:40 +0100
Received: from [208.184.76.39]:4072 (EHLO above.proper.com) by sek13.smarttrust.com ([192.168.1.15]:25) (F-Secure Anti-Virus for Internet Mail 6.0.34 Release) with SMTP; Fri, 28 Nov 2003 11:16:11 -0000
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9phib086416 for <[e-mail]>; Fri, 28 Nov 2003 01:51:43 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAS9phE5086415 for ietf-pkix-bks; Fri, 28 Nov 2003 01:51:43 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from relhubc02-ukbr.tcrelay.net ([217.32.166.20]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9pgib086406 for <[e-mail]>; Fri, 28 Nov 2003 01:51:42 -0800 (PST) (envelope-from [e-mail])
Received: from mail pickup service by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC; Fri, 28 Nov 2003 09:45:47 +0000
Received: from above.proper.com ([208.184.76.39]) by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 26 Nov 2003 17:42:26 +0000
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQHbnib034140 for <[e-mail]>; Wed, 26 Nov 2003 09:37:49 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQHbmO8034139 for ietf-pkix-bks; Wed, 26 Nov 2003 09:37:48 -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.10/8.12.8) with ESMTP id hAQHblib034129 for <[e-mail]>; Wed, 26 Nov 2003 09:37:47 -0800 (PST) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id hAQHbesj027338; Wed, 26 Nov 2003 12:37:41 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p06010210bbea90868896@[128.89.89.75]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Wed, 26 Nov 2003 12:33:48 -0500
To: [e-mail] (Peter Gutmann)
From: Stephen Kent <[e-mail]>
Subject: Re: Certificate Policy Standardization
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-OriginalArrivalTime: 26 Nov 2003 17:42:39.0129 (UTC) FILETIME=[AF7A0090:01C3B444]
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
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 5:59 +1300 11/27/03, Peter Gutmann wrote:
>Stephen Kent <[e-mail]> writes:
>
>>one might ask why the most widely distributed product that claims to
>>implement IPsec  (Windows) does not provide a user/administrator the ability
>>to order SPD entries, as required by RFC 2401. The answer is that the
>>implementors did not understand why this was an important (in the case of
>>IPsec, a critical) aspect of the standard and so the implementors omitted an
>>important management control.
>>
>>what one can learn from this an similar examples is that vendors are a very
>>poor basis for determining the worth of a feature in a standard.
>
>Actually what I learn from this is that complex standards with often
>incomprehensible requirements are just asking for trouble if they don't
>include a rationale.  Even a single sentence explaining the background behind
>the SPD entry ordering would have prevented this in a manner that no amount of
>MUSTs/SHALLs ever can.
>
>Peter.

The SPD is an ordered list for the same reason that ACLs have been 
ordered in operating systems for last 30 years, and in firewalls and 
routers for the last decade.  At what point does one not have to 
provide rationale?

Implementors of a technology ought (MUST/SHALL?) be competent in the 
technology that they are implementing. A standard like IPsec is not a 
"Secure Communication  Protocols for Dummies" document.

Steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASGLKib007022 for <[e-mail]>; Fri, 28 Nov 2003 08:21:20 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hASGLKGB007021 for ietf-pkix-bks; Fri, 28 Nov 2003 08:21:20 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.smarttrust.com ([213.212.5.232]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASGL8in006970 for <[e-mail]>; Fri, 28 Nov 2003 08:21:18 -0800 (PST) (envelope-from [e-mail])
Received: from sek43.smarttrust.com ([172.16.0.43]) by mail.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 17:21:57 +0100
Received: from mail pickup service by sek43.smarttrust.com with Microsoft SMTPSVC; Fri, 28 Nov 2003 17:21:09 +0100
Received: from mail.smarttrust.com ([192.168.1.10]) by sek43.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 12:16:54 +0100
Received: from sek13 ([192.168.1.15]) by mail.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 12:17:39 +0100
Received: from [208.184.76.39]:4065 (EHLO above.proper.com) by sek13.smarttrust.com ([192.168.1.15]:25) (F-Secure Anti-Virus for Internet Mail 6.0.34 Release) with SMTP; Fri, 28 Nov 2003 11:16:10 -0000
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9lgib086103 for <[e-mail]>; Fri, 28 Nov 2003 01:47:42 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAS9lgg1086101 for ietf-pkix-bks; Fri, 28 Nov 2003 01:47:42 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from relhubc02-ukbr.tcrelay.net ([217.32.166.20]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9leib086064 for <[e-mail]>; Fri, 28 Nov 2003 01:47:41 -0800 (PST) (envelope-from [e-mail])
Received: from mail pickup service by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC; Fri, 28 Nov 2003 09:41:46 +0000
Received: from above.proper.com ([208.184.76.39]) by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 26 Nov 2003 15:38:30 +0000
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQFZ3ib027684 for <[e-mail]>; Wed, 26 Nov 2003 07:35:03 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQFZ31R027683 for ietf-pkix-bks; Wed, 26 Nov 2003 07:35:03 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail4.consignia.com (mail4.consignia.com [144.87.143.84]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQFZ2ib027677 for <[e-mail]>; Wed, 26 Nov 2003 07:35:03 -0800 (PST) (envelope-from [e-mail])
Received: from postoffice.co.uk (mta2.int.consignia.com [144.87.146.16]) by mail4.consignia.com (Postfix) with SMTP id 724821221FE; Wed, 26 Nov 2003 15:35:03 +0000 (GMT)
Received: by postoffice.co.uk(Lotus SMTP MTA v4.6.6  (890.1 7-16-1999))  id 00256DEA.00559D17 ; Wed, 26 Nov 2003 15:35:07 +0000
X-Lotus-FromDomain: POSTOFFICE
From: [e-mail]
To: "Anders Rundgren" <[e-mail]>
Cc: [e-mail]
Message-ID: <[e-mail]>
Date: Wed, 26 Nov 2003 15:34:52 +0000
Subject: Re: Certificate Policy Standardization
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-OriginalArrivalTime: 26 Nov 2003 15:38:31.0179 (UTC) FILETIME=[582705B0:01C3B433]
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
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>

> 1. Why does practically no shrink-wrap PKI-enabled software
> package support any kind of certificate policy settings?

My experiences with so far 4 different PKI 'systems' are that
all of them could implement CP but only one did so out-of-the-box.
I feel very strongly that the vanilla deployment is one
that supports a homogeneous environment and does not take into
account interop with other PKIs. This is likely to be caused
by a number of factors including a desire to steer the end
user away from competitors, saving money in deploying unrequired
features and keeping the vanilla deployment as simple as possible
(if that is possible with PKI!!!). Given the current lack of
support for CP it does not surprise me that it is not part of
the vanilla deployment.

> 2. And why do few if any commercial CAs support multiple
> issuances (i.e. different CPs) per CA root?

Differentiate between 'cannot' and 'do not'. I would be very
surprised if they all cannot but I am not surprised that they
all do not (if that makes sense). Application of CP is, as you
have already said, a function of RP s/w. Commercial CAs issue
certificates to anyone who wants them yet CP is function of
local, company policy. Why should a commercial CA issue certs
with my CP in them (unless I pay them to do so)? As I see it,
at present a commercial CA will issue a CP which says no more
than 'this is my CP'. Third party s/w has no reason to enforce
this CP because it is private to the CA. When apps become
more security aware I will expect to see them enforce CP issued
from the corporate CA or from other Xcert CAs mapped through
policyMap.

Don't ask me when this will happen, though :-)

Chris




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASGLJib007015 for <[e-mail]>; Fri, 28 Nov 2003 08:21:19 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hASGLJcX007014 for ietf-pkix-bks; Fri, 28 Nov 2003 08:21:19 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.smarttrust.com ([213.212.5.232]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASGL8il006970 for <[e-mail]>; Fri, 28 Nov 2003 08:21:17 -0800 (PST) (envelope-from [e-mail])
Received: from sek43.smarttrust.com ([172.16.0.43]) by mail.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 17:21:57 +0100
Received: from mail pickup service by sek43.smarttrust.com with Microsoft SMTPSVC; Fri, 28 Nov 2003 17:21:09 +0100
Received: from mail.smarttrust.com ([192.168.1.10]) by sek43.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 12:16:57 +0100
Received: from sek13 ([192.168.1.15]) by mail.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 12:17:42 +0100
Received: from [208.184.76.39]:4089 (EHLO above.proper.com) by sek13.smarttrust.com ([192.168.1.15]:25) (F-Secure Anti-Virus for Internet Mail 6.0.34 Release) with SMTP; Fri, 28 Nov 2003 11:16:13 -0000
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9pXib086404 for <[e-mail]>; Fri, 28 Nov 2003 01:51:33 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAS9pXeE086403 for ietf-pkix-bks; Fri, 28 Nov 2003 01:51:33 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from relhubc02-ukbr.tcrelay.net ([217.32.166.20]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9pVib086391 for <[e-mail]>; Fri, 28 Nov 2003 01:51:31 -0800 (PST) (envelope-from [e-mail])
Received: from mail pickup service by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC; Fri, 28 Nov 2003 09:45:36 +0000
Received: from above.proper.com ([208.184.76.39]) by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 26 Nov 2003 16:16:25 +0000
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQFC7ib026381 for <[e-mail]>; Wed, 26 Nov 2003 07:12:07 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQFC7vJ026380 for ietf-pkix-bks; Wed, 26 Nov 2003 07:12:07 -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.10/8.12.8) with ESMTP id hAQFC5ib026372 for <[e-mail]>; Wed, 26 Nov 2003 07:12:06 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (127.0.0.1) by nic.lp.se (MX V5.3 VnHj) with ESMTP; Wed, 26 Nov 2003 16:12:04 +0100
Date: Wed, 26 Nov 2003 16:12:03 +0100 (CET)
Message-ID: <[e-mail]>
To: [e-mail]
CC: [e-mail]
Subject: Re: Certificate Policy Standardization
From: Richard Levitte - VMS Whacker <[e-mail]>
In-Reply-To: <025b01c3b421$683107b0$0500a8c0@arport>
References: <033e01c3b40d$0b962670$[e-mail]> <025b01c3b421$683107b0$0500a8c0@arport>
X-URL: http://www.lp.se/
X-Waved: dead chicken, GNU emacs 21.3.1, Mew version 4.0.60
X-Mew: See http://www.mew.org/
X-Mailer: Mew version 4.0.60 on Emacs 21.3.1 / Mule 5.0 (SAKAKI)
MIME-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-OriginalArrivalTime: 26 Nov 2003 16:17:15.0269 (UTC) FILETIME=[C16B0350:01C3B438]
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
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 <025b01c3b421$683107b0$0500a8c0@arport> on Wed, 26 Nov 2003 14:30:06 +0100, "Anders Rundgren" <[e-mail]> said:

anders.rundgren> I wonder how many times I have to repeat the same
anders.rundgren> very basic questions and only getting answers back in
anders.rundgren> "ASN.1"?  Sort of.  So here we go again...
anders.rundgren> 
anders.rundgren> 1. Why does practically no shrink-wrap PKI-enabled
anders.rundgren>    software package support any kind of certificate
anders.rundgren>    policy settings?
anders.rundgren> 
anders.rundgren> 2. And why do few if any commercial CAs support
anders.rundgren>    multiple issuances (i.e. different CPs) per CA
anders.rundgren>    root?
anders.rundgren> 
anders.rundgren> Because they have understood the problems associated?
anders.rundgren> Because they enjoy "violating" standards?
anders.rundgren> Because they are ignorant?
anders.rundgren> Because their budget is too limited?
anders.rundgren> Other?

Because they won't bother implementing something that a customer
hasn't asked for specifically.

I have literaly heard the sentence "Yeah, it would probably be useful
and might increase the value of our product, but no customer has said
they wanted or needed this, so we'll wait for that to happen".  And
this was for a product that had a lot to do with security.  It wasn't
about policy OIDs back then, but something similar enough.

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.
You don't have to be rich, a $10 donation is appreciated!

-- 
Richard Levitte     | http://richard.levitte.org/ | Tunnlandsv. 3
Levitte Programming | http://www.lp.se/           | S-168 36 Bromma
T: [phone] |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASGLHib007007 for <[e-mail]>; Fri, 28 Nov 2003 08:21:17 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hASGLHoW007006 for ietf-pkix-bks; Fri, 28 Nov 2003 08:21:17 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.smarttrust.com ([213.212.5.232]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASGL8ij006970 for <[e-mail]>; Fri, 28 Nov 2003 08:21:15 -0800 (PST) (envelope-from [e-mail])
Received: from sek43.smarttrust.com ([172.16.0.43]) by mail.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 17:21:56 +0100
Received: from mail pickup service by sek43.smarttrust.com with Microsoft SMTPSVC; Fri, 28 Nov 2003 17:21:07 +0100
Received: from mail.smarttrust.com ([192.168.1.10]) by sek43.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 12:16:30 +0100
Received: from sek13 ([192.168.1.15]) by mail.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 12:17:15 +0100
Received: from [208.184.76.39]:3859 (EHLO above.proper.com) by sek13.smarttrust.com ([192.168.1.15]:25) (F-Secure Anti-Virus for Internet Mail 6.0.34 Release) with SMTP; Fri, 28 Nov 2003 11:15:46 -0000
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9r9ib086469 for <[e-mail]>; Fri, 28 Nov 2003 01:53:09 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAS9r9w4086468 for ietf-pkix-bks; Fri, 28 Nov 2003 01:53:09 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from relhubc02-ukbr.tcrelay.net ([217.32.166.20]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9r7ib086462 for <[e-mail]>; Fri, 28 Nov 2003 01:53:07 -0800 (PST) (envelope-from [e-mail])
Received: from mail pickup service by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC; Fri, 28 Nov 2003 09:47:12 +0000
Received: from above.proper.com ([208.184.76.39]) by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 26 Nov 2003 20:06:25 +0000
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQK2Uib041331 for <[e-mail]>; Wed, 26 Nov 2003 12:02:30 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQK2UGu041330 for ietf-pkix-bks; Wed, 26 Nov 2003 12:02:30 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQK2Sib041323 for <[e-mail]>; Wed, 26 Nov 2003 12:02:28 -0800 (PST) (envelope-from [e-mail])
Received: from MMyersLapTop ([65.39.77.99]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id hAQK2UA79456; Wed, 26 Nov 2003 13:02:30 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: <[e-mail]>
Cc: "Carlisle Adams" <[e-mail]>
Subject: DISCUSS:  MUST  reject in OCSPv1
Date: Wed, 26 Nov 2003 13:04:42 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1106
In-Reply-To: <p06010205bbea7029f2b0@[128.89.89.75]>
Importance: Normal
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-OriginalArrivalTime: 26 Nov 2003 20:06:26.0132 (UTC) FILETIME=[C5923140:01C3B458]
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
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>

Colleagues,

I recently proposed to the chairs and the AD the following
action plan with respect to nonces in OCSP.  They in turn remain
curious as to working group consensus on the subject with a
particular emphasis on objections.  I had hoped for an ad-hoc
quorum on this in Minneapolis but it never materialized due to
the absence of several key players.

So, once more into the breach.  Who would object and why to the
following action plan (silence WILL be taken as consent):

1.  Regarding v1, clarify per the minutes as
    2560 goes from Proposed to Draft.  The
    operative text of which is that clients
    MUST reject a response that fails to
    incorporate a client's nonce.

2.  Simultaneously, initiate action on a v2
    I-D that will in part address technical
    changes in syntax and processing rules
    related to the use of nonces.

This is not a poll.  It is a request for discussion.  I expect
little disagreement on the intent of the v2 action item. The
core issue on v1 is "MUST reject".

To initiate the v1 discussion, my opinions are as follows.

1.  Nonces were established in OCSP to enable
    client driven prevention of replay attacks.
    Failure to respect a client's nonce is a
    direct denial of a client's request for
    this security service.  A responder that
    does so is contributing to the very security
    risks the requestor is seeking to mitigate.

2.  While 2560 also enables use of pre-produced
    responses, nonces and pre-produced responses
    are by definition mutually exclusive.  This
    effect should be immediately obvious to even
    the most naive of implementors, else they have
    no business writing code against this standard.
    A competent level of technical proficiency
    in implementing secure protocols is assumed.

3.  The "breakage" poll indicates that an
    overwhelming majority of OCSP implementors
    possess this competency.  11 of 12 client-side
    implementors reported no breakage with
    "MUST reject" while 10 of 12 server-side
    implementors responded likewise.

4.  The two server-side breakage points occur
    as a consequence of their use of pre-produced
    responses in a context where they have no
    administrative control over clients' use of
    nonces.  This can be addressed in v2, but in
    a v1 context we have no choice but to clarify
    original intent as ratified by the breakage poll.
    This breakage could also be relieved by relay
    of OCSP requests.

5.  The absence of normative language providing a
    tutorial on the proper use of nonces in a
    security protocol SHOULD NOT be taken up by
    any participant in this WG as an excuse to
    refute sound security principles.  Active
    participants in the Security Area of the IETF
    should be able to assume of their peers a
    superior grasp of and respect for foundational
    principles.

Objections to the "MUST reject" clarification are sought on the
basis of sound security engineering principles rather than
artful readings of ancillary language that enable specious
excuse from adherence to these principles in order to justify
current business models.

We are setting standards that must survive the test of time.  We
are supposed to check our corporate identities at the door.  We
are supposed to be individual engineers chartered to improve
Internet security.  Let us do so and get this problem solved.

My thanks to you all in advance for your patience with the
length of this note.


Mike




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASGLGib007000 for <[e-mail]>; Fri, 28 Nov 2003 08:21:16 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hASGLGji006999 for ietf-pkix-bks; Fri, 28 Nov 2003 08:21:16 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.smarttrust.com ([213.212.5.232]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASGL8ih006970 for <[e-mail]>; Fri, 28 Nov 2003 08:21:13 -0800 (PST) (envelope-from [e-mail])
Received: from sek43.smarttrust.com ([172.16.0.43]) by mail.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 17:21:55 +0100
Received: from mail pickup service by sek43.smarttrust.com with Microsoft SMTPSVC; Fri, 28 Nov 2003 17:21:06 +0100
Received: from mail.smarttrust.com ([192.168.1.10]) by sek43.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 12:16:27 +0100
Received: from sek13 ([192.168.1.15]) by mail.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 12:17:13 +0100
Received: from [208.184.76.39]:3845 (EHLO above.proper.com) by sek13.smarttrust.com ([192.168.1.15]:25) (F-Secure Anti-Virus for Internet Mail 6.0.34 Release) with SMTP; Fri, 28 Nov 2003 11:15:44 -0000
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9kXib085728 for <[e-mail]>; Fri, 28 Nov 2003 01:46:33 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAS9kXWN085726 for ietf-pkix-bks; Fri, 28 Nov 2003 01:46:33 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from relhubc02-ukbr.tcrelay.net ([217.32.166.20]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9kUib085694 for <[e-mail]>; Fri, 28 Nov 2003 01:46:31 -0800 (PST) (envelope-from [e-mail])
Received: from mail pickup service by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC; Fri, 28 Nov 2003 09:40:36 +0000
Received: from above.proper.com ([208.184.76.39]) by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 26 Nov 2003 19:12:33 +0000
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQIBeib035761 for <[e-mail]>; Wed, 26 Nov 2003 10:11:40 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQIBeHC035760 for ietf-pkix-bks; Wed, 26 Nov 2003 10:11:40 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.cs.auckland.ac.nz (csmail.cs.auckland.ac.nz [130.216.33.150]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQIBcib035752 for <[e-mail]>; Wed, 26 Nov 2003 10:11:38 -0800 (PST) (envelope-from [e-mail])
Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id 45A3C63C1D; Thu, 27 Nov 2003 07:11:37 +1300 (NZDT)
Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id hAQIEA202922; Thu, 27 Nov 2003 07:14:10 +1300
Date: Thu, 27 Nov 2003 07:14:10 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Certificate Policy Standardization
Cc: [e-mail]
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-OriginalArrivalTime: 26 Nov 2003 19:12:34.0382 (UTC) FILETIME=[3F4C46E0:01C3B451]
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
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>

Stephen Kent <[e-mail]> writes:

>Implementors of a technology ought (MUST/SHALL?) be competent in the
>technology that they are implementing. A standard like IPsec is not a "Secure
>Communication  Protocols for Dummies" document.

  The first thing one notices when looking at IPsec is that the documentation
  is very hard to understand. There is no overview or introduction, the reader
  has to assemble all the pieces and build an overview himself. This is a
  highly unsatisfactorily state of affairs; after all, the documentation is
  meant to convey information to the readers. We do not believe it is
  reasonable to expect anyone to learn IPsec from the IPsec documentation.
  Various parts of the IPsec documentation are very hard to read. For ex-
  ample, the ISAKMP specifications [MSST98] contain numerous errors, essential
  explanations are missing, and the document contradicts itself in various
  places.

  [...]
  
  None of the IPsec documentation provides any rationale for any of the
  choices that were made. Although this is somewhat less important than a
  clear statement of the goals, we nevertheless consider it crucial
  information. If a reviewer is to comment on the design (and RFCs are, after
  all, Requests For Comments), he should be told what each option was intended
  to achieve. Without any rationale, the reviewer is left to guess at it, and
  then review the design based on the guessed-at rationale.

  [...]
  
  In our opinion, IPsec is too complex to be secure. The design obviously
  tries to support many different situations with different options. We feel
  very strongly that the resulting system is well beyond the level of
  complexity that can be analysed or properly implemented with current method-
  ologies. Thus, no IPsec system will achieve the goal of providing a high
  level of security.

  [...]

  It is far too complex, and the complexity has lead to a large number of
  ambiguities, contradictions, inefficiencies, and weaknesses. It has been
  very hard work to perform any kind of security analysis; we do not feel that
  we fully understand the system, let alone have fully analyzed it.

Obviously non-dummies can't make much sense of it either.

Peter.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASGLDib006992 for <[e-mail]>; Fri, 28 Nov 2003 08:21:13 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hASGLDLg006991 for ietf-pkix-bks; Fri, 28 Nov 2003 08:21:13 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.smarttrust.com ([213.212.5.232]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASGL8if006970 for <[e-mail]>; Fri, 28 Nov 2003 08:21:12 -0800 (PST) (envelope-from [e-mail])
Received: from sek43.smarttrust.com ([172.16.0.43]) by mail.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 17:21:52 +0100
Received: from mail pickup service by sek43.smarttrust.com with Microsoft SMTPSVC; Fri, 28 Nov 2003 17:21:04 +0100
Received: from mail.smarttrust.com ([192.168.1.10]) by sek43.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 12:08:34 +0100
Received: from sek13 ([192.168.1.15]) by mail.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 12:09:20 +0100
Received: from [208.184.76.39]:1269 (EHLO above.proper.com) by sek13.smarttrust.com ([192.168.1.15]:25) (F-Secure Anti-Virus for Internet Mail 6.0.34 Release) with SMTP; Fri, 28 Nov 2003 11:07:51 -0000
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9thib086608 for <[e-mail]>; Fri, 28 Nov 2003 01:55:43 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAS9thOn086607 for ietf-pkix-bks; Fri, 28 Nov 2003 01:55:43 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from relhubc02-ukbr.tcrelay.net ([217.32.166.20]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9tgib086599 for <[e-mail]>; Fri, 28 Nov 2003 01:55:42 -0800 (PST) (envelope-from [e-mail])
Received: from mail pickup service by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC; Fri, 28 Nov 2003 09:49:47 +0000
Received: from above.proper.com ([208.184.76.39]) by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 26 Nov 2003 14:02:46 +0000
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQDu1ib021994 for <[e-mail]>; Wed, 26 Nov 2003 05:56:01 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQDu1Rd021993 for ietf-pkix-bks; Wed, 26 Nov 2003 05:56:01 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp4.hy.skanova.net (smtp4.hy.skanova.net [195.67.199.133]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQDtxib021987 for <[e-mail]>; Wed, 26 Nov 2003 05:56:00 -0800 (PST) (envelope-from [e-mail])
Received: from arport (t8o913p59.telia.com [213.64.26.179]) by smtp4.hy.skanova.net (8.12.10/8.12.10) with SMTP id hAQDtwBZ009924; Wed, 26 Nov 2003 14:55:58 +0100 (CET)
Message-ID: <028101c3b424$7dd4b460$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Richard Levitte - VMS Whacker" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]> <[e-mail]>            <00e001c3b366$7c1cbc80$0500a8c0@arport> <[e-mail]>
Subject: Re: Certificate Policy Standardization
Date: Wed, 26 Nov 2003 14:52:10 +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
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-OriginalArrivalTime: 26 Nov 2003 14:02:46.0945 (UTC) FILETIME=[F8527910:01C3B425]
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
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>

Richard,
That external parties to the US e-governments, like various
businesses would ever (on a wider scale) bother with cross-
certification is unlikely, they will just purchase a TTP-issued
"business certificate" for a few hundred dollars, not run CAs.

And in the case of the US e-government, they have a much more
serious problem to cater for than CP OIDs and that is that their
business parties, will authenticate messages at the business partner
level, not on employee level (as the latter is incompatible with
all e-business systems I have heard about).  So they probably
have to take down the whole thing and startover anyway.
Or have "gateway" servers do the transformation from their
internal "mess-PKI" (not mesh PKI) to something that works.
Like "flat", "boring", "simple",  you know.  In that world
CP OIDs are mostly unknown.   I have yet to find a CP OID
in my fairly new Thawte SSL certificate.

Anders


----- Original Message -----
From: "Richard Levitte - VMS Whacker" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>
Sent: Wednesday, November 26, 2003 14:30
Subject: Re: Certificate Policy Standardization


In message <00e001c3b366$7c1cbc80$0500a8c0@arport> on Tue, 25 Nov 2003 16:11:57 +0100, "Anders Rundgren" <[e-mail]>
said:

anders.rundgren> Policy OIDs may be "perfect" as long as you stay
anders.rundgren> inside of your "walled garden", but the USs
anders.rundgren> government PKI will likely find itself up the creek
anders.rundgren> when they are going to connect to the outside world
anders.rundgren> who hardly ever use this feature (which I BTW cannot
anders.rundgren> find a single "knob" for in my W2K system), or even
anders.rundgren> worse, have settled on another set of OIDs.

Uhmm, especially that last thing about other PKIs having other sets
of OIDs makes me think you have missed the mechanism called "policy
mapping".  There's no requirement whatsoever that everyone uses the
same set of OIDs.  However, if the owner of one PKI decides to do
business with another PKI owner and have the two PKIs connected, they
will typically do some cross certification, and those certificates
will contain the appropriate mappings of policies, as decided by the
two parties together.

As far as I understand, those kinds of mechanisms are already in use
and working.  I assume others here will be able to say yay or ney
about this matter.

Of course, what I said above implies some level of "meshness", about
which I've read some negative comments from one person...

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.
You don't have to be rich, a $10 donation is appreciated!

--
Richard Levitte     | http://richard.levitte.org/ | Tunnlandsv. 3
Levitte Programming | http://www.lp.se/           | S-168 36 Bromma
T: [phone] |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASGLCib006985 for <[e-mail]>; Fri, 28 Nov 2003 08:21:12 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hASGLC1E006984 for ietf-pkix-bks; Fri, 28 Nov 2003 08:21:12 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.smarttrust.com ([213.212.5.232]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASGL8id006970 for <[e-mail]>; Fri, 28 Nov 2003 08:21:10 -0800 (PST) (envelope-from [e-mail])
Received: from sek43.smarttrust.com ([172.16.0.43]) by mail.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 17:21:51 +0100
Received: from mail pickup service by sek43.smarttrust.com with Microsoft SMTPSVC; Fri, 28 Nov 2003 17:21:03 +0100
Received: from mail.smarttrust.com ([192.168.1.10]) by sek43.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 12:22:52 +0100
Received: from sek13 ([192.168.1.15]) by mail.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 12:23:37 +0100
Received: from [208.184.76.39]:1950 (EHLO above.proper.com) by sek13.smarttrust.com ([192.168.1.15]:25) (F-Secure Anti-Virus for Internet Mail 6.0.34 Release) with SMTP; Fri, 28 Nov 2003 11:22:08 -0000
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9s0ib086535 for <[e-mail]>; Fri, 28 Nov 2003 01:54:00 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAS9s0H9086534 for ietf-pkix-bks; Fri, 28 Nov 2003 01:54:00 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from relhubc02-ukbr.tcrelay.net ([217.32.166.20]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9rwib086519 for <[e-mail]>; Fri, 28 Nov 2003 01:53:59 -0800 (PST) (envelope-from [e-mail])
Received: from mail pickup service by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC; Fri, 28 Nov 2003 09:48:04 +0000
Received: from above.proper.com ([208.184.76.39]) by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 26 Nov 2003 16:10:41 +0000
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQF12ib025722 for <[e-mail]>; Wed, 26 Nov 2003 07:01:04 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQF12ud025721 for ietf-pkix-bks; Wed, 26 Nov 2003 07:01:02 -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.10/8.12.8) with ESMTP id hAQF0xib025703 for <[e-mail]>; Wed, 26 Nov 2003 07:01:00 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (127.0.0.1) by nic.lp.se (MX V5.3 VnHj) with ESMTP; Wed, 26 Nov 2003 16:00:57 +0100
Date: Wed, 26 Nov 2003 16:00:56 +0100 (CET)
Message-ID: <[e-mail]>
To: [e-mail]
CC: [e-mail], [e-mail]
Subject: Re: Certificate Policy Standardization
From: Richard Levitte - VMS Whacker <[e-mail]>
In-Reply-To: <014b01c3b416$b6075580$0500a8c0@arport>
References: <[e-mail]> <014b01c3b416$b6075580$0500a8c0@arport>
X-URL: http://www.lp.se/
X-Waved: dead chicken, GNU emacs 21.3.1, Mew version 4.0.60
X-Mew: See http://www.mew.org/
X-Mailer: Mew version 4.0.60 on Emacs 21.3.1 / Mule 5.0 (SAKAKI)
MIME-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-OriginalArrivalTime: 26 Nov 2003 16:10:41.0597 (UTC) FILETIME=[D6C56ED0:01C3B437]
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
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 <014b01c3b416$b6075580$0500a8c0@arport> on Wed, 26 Nov 2003 13:13:32 +0100, "Anders Rundgren" <[e-mail]> said:

anders.rundgren> >I don't see how you can say that, Anders. That's not
anders.rundgren> >how the system is designed to work. No CA s/w that I
anders.rundgren> >have yet to encounter limits certificates to a
anders.rundgren> >single policy, let alone the CA. CertificatePolicies
anders.rundgren> >can be multivalued, is not a mandatory field, does
anders.rundgren> >not get marked as critical and in all except bespoke
anders.rundgren> >applications is currently ignored. Failure on the
anders.rundgren> >part of software developers to meet the agreed
anders.rundgren> >standards does not always indicate a failing of the
anders.rundgren> >standard (granted that in some cases it does).
anders.rundgren> 
anders.rundgren> Well Chris,
anders.rundgren> I think you read this in big haste.
anders.rundgren> 
anders.rundgren> CA s/w is not equivalent to RP s/w.
anders.rundgren> 
anders.rundgren> Please tell me where I in the latest edition of
anders.rundgren> Outlook Express (I'm indeed a daring guy...), can
anders.rundgren> "tweak" the CA policy trust settings.

That's today.  I believe that to the crowd, awareness of the type of
trust we're discussing here is fairly new (and in many cases so new
they aren't aware yet).  And M$ is fairly well-known for implementing
what it thinks the crowd wants and try to avoid things that could be
seen as complicated ("oh, I should protect my private key with a pass
phrase???"), so pardon me for rejecting that particular example.

I believe that when the crowd becomes a bit more aware of what their
actions mean when done through a computer, compared to the "real
world", they might demand  certain amount of control, and it's
perfectly possible that you will see those kinds of "knobs" sometime
in the future.

anders.rundgren> In case you don't find the "knob", does this in your
anders.rundgren> opinion mean that Microsoft is not
anders.rundgren> standards-compliant w.r.t. policy-OIDs?

Nope, it just means that they have assumed you would always press the
"Accept any policy" knob, and besides, that's all they currently
support, so the knob would be quite lonely in that otherwise empty
space, so they won't bother to put it up yet.

However, if M$ doesn't check for policy OID and mappings and keep
track of those along with the other data while verifying the path,
then they aren't standards-compliant w.r.t. policy OIDs.  As it is
right now, I wouldn't be surprised if they're in good company :-/.

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.
You don't have to be rich, a $10 donation is appreciated!

-- 
Richard Levitte     | http://richard.levitte.org/ | Tunnlandsv. 3
Levitte Programming | http://www.lp.se/           | S-168 36 Bromma
T: [phone] |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASGLAib006978 for <[e-mail]>; Fri, 28 Nov 2003 08:21:10 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hASGLArc006977 for ietf-pkix-bks; Fri, 28 Nov 2003 08:21:10 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.smarttrust.com ([213.212.5.232]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASGL8ib006970 for <[e-mail]>; Fri, 28 Nov 2003 08:21:08 -0800 (PST) (envelope-from [e-mail])
Received: from sek43.smarttrust.com ([172.16.0.43]) by mail.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 17:21:50 +0100
Received: from mail pickup service by sek43.smarttrust.com with Microsoft SMTPSVC; Fri, 28 Nov 2003 17:21:00 +0100
Received: from mail.smarttrust.com ([192.168.1.10]) by sek43.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 12:22:20 +0100
Received: from sek13 ([192.168.1.15]) by mail.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 12:23:05 +0100
Received: from [208.184.76.39]:1795 (EHLO above.proper.com) by sek13.smarttrust.com ([192.168.1.15]:25) (F-Secure Anti-Virus for Internet Mail 6.0.34 Release) with SMTP; Fri, 28 Nov 2003 11:21:36 -0000
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9tuib086628 for <[e-mail]>; Fri, 28 Nov 2003 01:55:56 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAS9tuug086627 for ietf-pkix-bks; Fri, 28 Nov 2003 01:55:56 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from relhubc02-ukbr.tcrelay.net ([217.32.166.20]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9tqid086610 for <[e-mail]>; Fri, 28 Nov 2003 01:55:54 -0800 (PST) (envelope-from [e-mail])
Received: from mail pickup service by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC; Fri, 28 Nov 2003 09:50:00 +0000
Received: from above.proper.com ([208.184.76.39]) by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 26 Nov 2003 18:20:35 +0000
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQFB3ib026313 for <[e-mail]>; Wed, 26 Nov 2003 07:11:03 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQFB3OD026312 for ietf-pkix-bks; Wed, 26 Nov 2003 07:11:03 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.cs.auckland.ac.nz (csmail.cs.auckland.ac.nz [130.216.33.150]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQFB0ib026302 for <[e-mail]>; Wed, 26 Nov 2003 07:11:02 -0800 (PST) (envelope-from [e-mail])
Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id A299863C1D; Thu, 27 Nov 2003 04:10:58 +1300 (NZDT)
Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id hAQFDUG01265; Thu, 27 Nov 2003 04:13:30 +1300
Date: Thu, 27 Nov 2003 04:13:30 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Certificate Policy Standardization
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-OriginalArrivalTime: 26 Nov 2003 18:20:35.0835 (UTC) FILETIME=[FC7FC4B0:01C3B449]
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
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>

"Anders Rundgren" <[e-mail]> writes:

>1. Why does practically no shrink-wrap PKI-enabled software package support
>any kind of certificate policy settings?

Zero demand.  Heck, it wasn't too long ago that MS PKI software hardcoded the
Verisign policy into CryptoAPI, so that no matter what the actual policy was
in the cert, what was displayed was the Verisign policy.  That shows how much
attention people are paying to the policy stuff.

That doesn't mean that RPs don't use a policy-equivalent: The software is
configured - via trusted roots - to only accept certs from a given set of CAs
(Anders, that's the policy-configurability you asked for, it's just not called
that).  So the trusted-roots mechanism does what the policy extension is
supposed to do, and the policy extension becomes a legal self-defence
mechanism for the benefit of the CA.  This is an almost complete inversion of
what RFC 3280 thinks that the policy extension is meant for:

  Applications with specific policy requirements are expected to have a list
  of those policies which they will accept and to compare the policy OIDs in
  the certificate to that list.

Peter.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASGKuib006962 for <[e-mail]>; Fri, 28 Nov 2003 08:20:56 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hASGKu5d006961 for ietf-pkix-bks; Fri, 28 Nov 2003 08:20:56 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.smarttrust.com ([213.212.5.232]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASGKrib006949 for <[e-mail]>; Fri, 28 Nov 2003 08:20:54 -0800 (PST) (envelope-from [e-mail])
Received: from sek43.smarttrust.com ([172.16.0.43]) by mail.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 17:21:35 +0100
Received: from mail pickup service by sek43.smarttrust.com with Microsoft SMTPSVC; Fri, 28 Nov 2003 17:20:47 +0100
Received: from mail.smarttrust.com ([192.168.1.10]) by sek43.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 12:21:13 +0100
Received: from sek13 ([192.168.1.15]) by mail.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 12:21:58 +0100
Received: from [208.184.76.39]:1426 (EHLO above.proper.com) by sek13.smarttrust.com ([192.168.1.15]:25) (F-Secure Anti-Virus for Internet Mail 6.0.34 Release) with SMTP; Fri, 28 Nov 2003 11:20:29 -0000
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9stib086568 for <[e-mail]>; Fri, 28 Nov 2003 01:54:55 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAS9stol086567 for ietf-pkix-bks; Fri, 28 Nov 2003 01:54:55 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from relhubc02-ukbr.tcrelay.net ([217.32.166.20]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9srib086561 for <[e-mail]>; Fri, 28 Nov 2003 01:54:54 -0800 (PST) (envelope-from [e-mail])
Received: from mail pickup service by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC; Fri, 28 Nov 2003 09:48:51 +0000
Received: from above.proper.com ([208.184.76.39]) by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 26 Nov 2003 15:42:27 +0000
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQFdYib027926 for <[e-mail]>; Wed, 26 Nov 2003 07:39:34 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQFdYCA027925 for ietf-pkix-bks; Wed, 26 Nov 2003 07:39:34 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.cs.auckland.ac.nz (csmail.cs.auckland.ac.nz [130.216.33.150]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQFdWib027920 for <[e-mail]>; Wed, 26 Nov 2003 07:39:33 -0800 (PST) (envelope-from [e-mail])
Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id 8818063C1D; Thu, 27 Nov 2003 04:39:33 +1300 (NZDT)
Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id hAQFg5L01342; Thu, 27 Nov 2003 04:42:05 +1300
Date: Thu, 27 Nov 2003 04:42:05 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Certificate Policy Standardization
Cc: [e-mail], [e-mail]
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-OriginalArrivalTime: 26 Nov 2003 15:42:28.0335 (UTC) FILETIME=[E58227F0:01C3B433]
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
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>

Stephen Kent <[e-mail]> writes:

>For example, most certs used with IKE will not be subject to some attorney's
>advice, I suspect.

Actually now that you mention it one of the three classes of certs that were
going to be used in the situation I mentioned were IKE certs.  I think they
were going to subclass "doWhatISay" into "doWhatISayWithIKE",
"doWhatISayWithSSL", and "doWhatISayWithSMIMESigning"(not sure about the last
one, I have the paperwork downstairs but I'm too lazy to look it up).  All of
them were going to go through the full legal wringer.

Peter.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASGKkib006947 for <[e-mail]>; Fri, 28 Nov 2003 08:20:46 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hASGKkOq006946 for ietf-pkix-bks; Fri, 28 Nov 2003 08:20:46 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.smarttrust.com ([213.212.5.232]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASGKVir006879 for <[e-mail]>; Fri, 28 Nov 2003 08:20:44 -0800 (PST) (envelope-from [e-mail])
Received: from sek43.smarttrust.com ([172.16.0.43]) by mail.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 17:21:28 +0100
Received: from mail pickup service by sek43.smarttrust.com with Microsoft SMTPSVC; Fri, 28 Nov 2003 17:20:39 +0100
Received: from mail.smarttrust.com ([192.168.1.10]) by sek43.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 12:34:28 +0100
Received: from sek13 ([192.168.1.15]) by mail.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 12:35:13 +0100
Received: from [208.184.76.39]:3890 (EHLO above.proper.com) by sek13.smarttrust.com ([192.168.1.15]:25) (F-Secure Anti-Virus for Internet Mail 6.0.34 Release) with SMTP; Fri, 28 Nov 2003 11:33:44 -0000
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9reib086495 for <[e-mail]>; Fri, 28 Nov 2003 01:53:40 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAS9rdXt086494 for ietf-pkix-bks; Fri, 28 Nov 2003 01:53:39 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from relhubc02-ukbr.tcrelay.net ([217.32.166.20]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9rcib086487 for <[e-mail]>; Fri, 28 Nov 2003 01:53:39 -0800 (PST) (envelope-from [e-mail])
Received: from mail pickup service by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC; Fri, 28 Nov 2003 09:47:44 +0000
Received: from above.proper.com ([208.184.76.39]) by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 26 Nov 2003 16:46:18 +0000
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQFZ3ib027684 for <[e-mail]>; Wed, 26 Nov 2003 07:35:03 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQFZ31R027683 for ietf-pkix-bks; Wed, 26 Nov 2003 07:35:03 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail4.consignia.com (mail4.consignia.com [144.87.143.84]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQFZ2ib027677 for <[e-mail]>; Wed, 26 Nov 2003 07:35:03 -0800 (PST) (envelope-from [e-mail])
Received: from postoffice.co.uk (mta2.int.consignia.com [144.87.146.16]) by mail4.consignia.com (Postfix) with SMTP id 724821221FE; Wed, 26 Nov 2003 15:35:03 +0000 (GMT)
Received: by postoffice.co.uk(Lotus SMTP MTA v4.6.6  (890.1 7-16-1999))  id 00256DEA.00559D17 ; Wed, 26 Nov 2003 15:35:07 +0000
X-Lotus-FromDomain: POSTOFFICE
From: [e-mail]
To: "Anders Rundgren" <[e-mail]>
Cc: [e-mail]
Message-ID: <[e-mail]>
Date: Wed, 26 Nov 2003 15:34:52 +0000
Subject: Re: Certificate Policy Standardization
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-OriginalArrivalTime: 26 Nov 2003 16:47:00.0925 (UTC) FILETIME=[E9C07ED0:01C3B43C]
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
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>

> 1. Why does practically no shrink-wrap PKI-enabled software
> package support any kind of certificate policy settings?

My experiences with so far 4 different PKI 'systems' are that
all of them could implement CP but only one did so out-of-the-box.
I feel very strongly that the vanilla deployment is one
that supports a homogeneous environment and does not take into
account interop with other PKIs. This is likely to be caused
by a number of factors including a desire to steer the end
user away from competitors, saving money in deploying unrequired
features and keeping the vanilla deployment as simple as possible
(if that is possible with PKI!!!). Given the current lack of
support for CP it does not surprise me that it is not part of
the vanilla deployment.

> 2. And why do few if any commercial CAs support multiple
> issuances (i.e. different CPs) per CA root?

Differentiate between 'cannot' and 'do not'. I would be very
surprised if they all cannot but I am not surprised that they
all do not (if that makes sense). Application of CP is, as you
have already said, a function of RP s/w. Commercial CAs issue
certificates to anyone who wants them yet CP is function of
local, company policy. Why should a commercial CA issue certs
with my CP in them (unless I pay them to do so)? As I see it,
at present a commercial CA will issue a CP which says no more
than 'this is my CP'. Third party s/w has no reason to enforce
this CP because it is private to the CA. When apps become
more security aware I will expect to see them enforce CP issued
from the corporate CA or from other Xcert CAs mapped through
policyMap.

Don't ask me when this will happen, though :-)

Chris




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASGKjib006940 for <[e-mail]>; Fri, 28 Nov 2003 08:20:45 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hASGKjvl006939 for ietf-pkix-bks; Fri, 28 Nov 2003 08:20:45 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.smarttrust.com ([213.212.5.232]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASGKVip006879 for <[e-mail]>; Fri, 28 Nov 2003 08:20:43 -0800 (PST) (envelope-from [e-mail])
Received: from sek43.smarttrust.com ([172.16.0.43]) by mail.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 17:21:28 +0100
Received: from mail pickup service by sek43.smarttrust.com with Microsoft SMTPSVC; Fri, 28 Nov 2003 17:20:36 +0100
Received: from mail.smarttrust.com ([192.168.1.10]) by sek43.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 12:19:44 +0100
Received: from sek13 ([192.168.1.15]) by mail.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 12:20:29 +0100
Received: from [208.184.76.39]:1076 (EHLO above.proper.com) by sek13.smarttrust.com ([192.168.1.15]:25) (F-Secure Anti-Virus for Internet Mail 6.0.34 Release) with SMTP; Fri, 28 Nov 2003 11:19:00 -0000
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9rWib086485 for <[e-mail]>; Fri, 28 Nov 2003 01:53:32 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAS9rWig086484 for ietf-pkix-bks; Fri, 28 Nov 2003 01:53:32 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from relhubc02-ukbr.tcrelay.net ([217.32.166.20]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9rUib086478 for <[e-mail]>; Fri, 28 Nov 2003 01:53:31 -0800 (PST) (envelope-from [e-mail])
Received: from mail pickup service by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC; Fri, 28 Nov 2003 09:47:36 +0000
Received: from above.proper.com ([208.184.76.39]) by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 26 Nov 2003 15:05:59 +0000
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQF31ib025846 for <[e-mail]>; Wed, 26 Nov 2003 07:03:01 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQF31Fi025845 for ietf-pkix-bks; Wed, 26 Nov 2003 07:03:01 -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.10/8.12.8) with ESMTP id hAQF30ib025837 for <[e-mail]>; Wed, 26 Nov 2003 07:03:00 -0800 (PST) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id hAQF2tsj016901; Wed, 26 Nov 2003 10:02:56 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p06010204bbea6fb4d743@[128.89.89.75]>
In-Reply-To: <009e01c3b40d$329bed40$0500a8c0@arport>
References: <009e01c3b40d$329bed40$0500a8c0@arport>
Date: Wed, 26 Nov 2003 09:57:09 -0500
To: "Anders Rundgren" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Da Capo: Re: Certificate Policy Standardization
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-OriginalArrivalTime: 26 Nov 2003 15:05:59.0695 (UTC) FILETIME=[CCFA31F0:01C3B42E]
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
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 +0100 11/26/03, Anders Rundgren wrote:
>  >Policy OIDs might come handy to protect RPs from issuing authorities who
>>might seek to alter their terms arbitrarily without necessarily providing
>>notice to that effect. In practice, ambiguity over the exact content of
>>applicable policy might render that CP unenforceable.
>
>When I read a statement like above, I get really sad and begin
>to completely lose faith in the PKI technology [1], wondering
>if I maybe should go and waste my talent on something useful
>for a change.
>

Promises, promises ...


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASGKiib006934 for <[e-mail]>; Fri, 28 Nov 2003 08:20:44 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hASGKiwg006932 for ietf-pkix-bks; Fri, 28 Nov 2003 08:20:44 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.smarttrust.com ([213.212.5.232]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASGKVin006879 for <[e-mail]>; Fri, 28 Nov 2003 08:20:42 -0800 (PST) (envelope-from [e-mail])
Received: from sek43.smarttrust.com ([172.16.0.43]) by mail.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 17:21:23 +0100
Received: from mail pickup service by sek43.smarttrust.com with Microsoft SMTPSVC; Fri, 28 Nov 2003 17:20:34 +0100
Received: from mail.smarttrust.com ([192.168.1.10]) by sek43.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 12:19:30 +0100
Received: from sek13 ([192.168.1.15]) by mail.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 12:20:15 +0100
Received: from [208.184.76.39]:4987 (EHLO above.proper.com) by sek13.smarttrust.com ([192.168.1.15]:25) (F-Secure Anti-Virus for Internet Mail 6.0.34 Release) with SMTP; Fri, 28 Nov 2003 11:18:46 -0000
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9qRib086449 for <[e-mail]>; Fri, 28 Nov 2003 01:52:27 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAS9qRSS086448 for ietf-pkix-bks; Fri, 28 Nov 2003 01:52:27 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from relhubc02-ukbr.tcrelay.net ([217.32.166.20]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9qOid086434 for <[e-mail]>; Fri, 28 Nov 2003 01:52:25 -0800 (PST) (envelope-from [e-mail])
Received: from mail pickup service by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC; Fri, 28 Nov 2003 09:46:28 +0000
Received: from above.proper.com ([208.184.76.39]) by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 26 Nov 2003 16:45:34 +0000
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQFXXib027570 for <[e-mail]>; Wed, 26 Nov 2003 07:33:33 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQFXXdQ027569 for ietf-pkix-bks; Wed, 26 Nov 2003 07:33:33 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.cs.auckland.ac.nz (csmail.cs.auckland.ac.nz [130.216.33.150]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQFXVib027563 for <[e-mail]>; Wed, 26 Nov 2003 07:33:32 -0800 (PST) (envelope-from [e-mail])
Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id 80B7463C1D; Thu, 27 Nov 2003 04:33:32 +1300 (NZDT)
Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id hAQFa4Y01319; Thu, 27 Nov 2003 04:36:04 +1300
Date: Thu, 27 Nov 2003 04:36:04 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Certificate Policy Standardization
Cc: [e-mail]
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-OriginalArrivalTime: 26 Nov 2003 16:46:13.0129 (UTC) FILETIME=[CD436790:01C3B43C]
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
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>

Andreas Mitrakas <[e-mail]> writes:

>Especially so in some implementations in Europe where there is a direct link
>between the policy and the law under which certain certs like QC certs are
>issued.

The feeling was that digital signature legislation (following the UNCITRAL
model) is so vaguely worded that this wouldn't be a problem.  Qualified certs
are a bit more problematic, but that's only in Europe.

>A CP becomes part of the parties agreement and binding by means of e.g. a
>subscriber agreement. So it is not unthinkable albeit not necessarily
>desirable, that a courts might  scrutinise policies. --God forbid.

The feeling here was that a ToS-style policy might violate (at least NZ)
consumer protection legislation, however since a number of large organisations
relied on these types of agreements there would probably be a spirited defence
of them in court and/or existing case law upholding them.  See e.g Xtra
(Telecom NZ ISP) terms, which state:

  12. Changes to these Customer Terms

  We may change these Customer Terms by changing or removing existing terms,
  or by adding new ones. Changes may take the form of completely new terms.

  [Notification stuff snipped]

  A copy of our current terms is displayed on our Website. It is your
  responsibility to check these Customer Terms regularly (at least monthly)
  for any modifications or updates. You will be deemed to have accepted the
  changes to these Customer Terms and to have agreed to be bound by the
  revised Customer Terms if you continue to use and/or access the Services
  after the date that the changes are stated to be effective.

  We reserve the right to change any charges or Services, or any Separate
  Terms, at any time without notice. It is your responsibility to check all
  applicable Separate Terms regularly for any modifications or updates.

That's the sort of thing the "policy is what we say it is" that I mentioned
earlier was based on.  Just for reference, here's what Yahoo says:

  Yahoo! provides its service to you, subject to the following Terms of
  Service ("TOS"), which may be updated by us from time to time without notice
  to you. You can review the most current version of the TOS at any time at:
  http://docs.yahoo.com/info/terms/. 
  
  [Snippage]

  Yahoo! reserves the right at any time and from time to time to modify or
  discontinue, temporarily or permanently, the Service (or any part thereof)
  with or without notice. You agree that Yahoo! shall not be liable to you or
  to any third party for any modification, suspension or discontinuance of the
  Service.

The debate then went off on a tangent about whether a PKI was providing a
service of any value to a user (if it doesn't it's not covered by standard
consumer-protection law), and how you'd present that in court.

Disclaimer: IANAL, I just talk to them occasionally.

Peter.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASGKgib006926 for <[e-mail]>; Fri, 28 Nov 2003 08:20:42 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hASGKgbS006925 for ietf-pkix-bks; Fri, 28 Nov 2003 08:20:42 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.smarttrust.com ([213.212.5.232]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASGKVil006879 for <[e-mail]>; Fri, 28 Nov 2003 08:20:40 -0800 (PST) (envelope-from [e-mail])
Received: from sek43.smarttrust.com ([172.16.0.43]) by mail.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 17:21:23 +0100
Received: from mail pickup service by sek43.smarttrust.com with Microsoft SMTPSVC; Fri, 28 Nov 2003 17:20:35 +0100
Received: from mail.smarttrust.com ([192.168.1.10]) by sek43.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 12:19:37 +0100
Received: from sek13 ([192.168.1.15]) by mail.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 12:20:22 +0100
Received: from [208.184.76.39]:1039 (EHLO above.proper.com) by sek13.smarttrust.com ([192.168.1.15]:25) (F-Secure Anti-Virus for Internet Mail 6.0.34 Release) with SMTP; Fri, 28 Nov 2003 11:18:53 -0000
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9mHib086289 for <[e-mail]>; Fri, 28 Nov 2003 01:48:17 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAS9mHhf086288 for ietf-pkix-bks; Fri, 28 Nov 2003 01:48:17 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from relhubc02-ukbr.tcrelay.net ([217.32.166.20]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9mFib086271 for <[e-mail]>; Fri, 28 Nov 2003 01:48:16 -0800 (PST) (envelope-from [e-mail])
Received: from mail pickup service by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC; Fri, 28 Nov 2003 09:42:21 +0000
Received: from above.proper.com ([208.184.76.39]) by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 26 Nov 2003 18:16:22 +0000
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQIBeib035761 for <[e-mail]>; Wed, 26 Nov 2003 10:11:40 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQIBeHC035760 for ietf-pkix-bks; Wed, 26 Nov 2003 10:11:40 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.cs.auckland.ac.nz (csmail.cs.auckland.ac.nz [130.216.33.150]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQIBcib035752 for <[e-mail]>; Wed, 26 Nov 2003 10:11:38 -0800 (PST) (envelope-from [e-mail])
Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id 45A3C63C1D; Thu, 27 Nov 2003 07:11:37 +1300 (NZDT)
Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id hAQIEA202922; Thu, 27 Nov 2003 07:14:10 +1300
Date: Thu, 27 Nov 2003 07:14:10 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Certificate Policy Standardization
Cc: [e-mail]
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-OriginalArrivalTime: 26 Nov 2003 18:16:22.0835 (UTC) FILETIME=[65B30830:01C3B449]
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
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>

Stephen Kent <[e-mail]> writes:

>Implementors of a technology ought (MUST/SHALL?) be competent in the
>technology that they are implementing. A standard like IPsec is not a "Secure
>Communication  Protocols for Dummies" document.

  The first thing one notices when looking at IPsec is that the documentation
  is very hard to understand. There is no overview or introduction, the reader
  has to assemble all the pieces and build an overview himself. This is a
  highly unsatisfactorily state of affairs; after all, the documentation is
  meant to convey information to the readers. We do not believe it is
  reasonable to expect anyone to learn IPsec from the IPsec documentation.
  Various parts of the IPsec documentation are very hard to read. For ex-
  ample, the ISAKMP specifications [MSST98] contain numerous errors, essential
  explanations are missing, and the document contradicts itself in various
  places.

  [...]
  
  None of the IPsec documentation provides any rationale for any of the
  choices that were made. Although this is somewhat less important than a
  clear statement of the goals, we nevertheless consider it crucial
  information. If a reviewer is to comment on the design (and RFCs are, after
  all, Requests For Comments), he should be told what each option was intended
  to achieve. Without any rationale, the reviewer is left to guess at it, and
  then review the design based on the guessed-at rationale.

  [...]
  
  In our opinion, IPsec is too complex to be secure. The design obviously
  tries to support many different situations with different options. We feel
  very strongly that the resulting system is well beyond the level of
  complexity that can be analysed or properly implemented with current method-
  ologies. Thus, no IPsec system will achieve the goal of providing a high
  level of security.

  [...]

  It is far too complex, and the complexity has lead to a large number of
  ambiguities, contradictions, inefficiencies, and weaknesses. It has been
  very hard work to perform any kind of security analysis; we do not feel that
  we fully understand the system, let alone have fully analyzed it.

Obviously non-dummies can't make much sense of it either.

Peter.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASGKfib006918 for <[e-mail]>; Fri, 28 Nov 2003 08:20:41 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hASGKfVU006917 for ietf-pkix-bks; Fri, 28 Nov 2003 08:20:41 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.smarttrust.com ([213.212.5.232]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASGKVij006879 for <[e-mail]>; Fri, 28 Nov 2003 08:20:39 -0800 (PST) (envelope-from [e-mail])
Received: from sek43.smarttrust.com ([172.16.0.43]) by mail.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 17:21:22 +0100
Received: from mail pickup service by sek43.smarttrust.com with Microsoft SMTPSVC; Fri, 28 Nov 2003 17:20:34 +0100
Received: from mail.smarttrust.com ([192.168.1.10]) by sek43.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 12:12:12 +0100
Received: from sek13 ([192.168.1.15]) by mail.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 12:12:57 +0100
Received: from [208.184.76.39]:2433 (EHLO above.proper.com) by sek13.smarttrust.com ([192.168.1.15]:25) (F-Secure Anti-Virus for Internet Mail 6.0.34 Release) with SMTP; Fri, 28 Nov 2003 11:11:28 -0000
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9qPib086441 for <[e-mail]>; Fri, 28 Nov 2003 01:52:25 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAS9qPpZ086440 for ietf-pkix-bks; Fri, 28 Nov 2003 01:52:25 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from relhubc02-ukbr.tcrelay.net ([217.32.166.20]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9qOib086434 for <[e-mail]>; Fri, 28 Nov 2003 01:52:24 -0800 (PST) (envelope-from [e-mail])
Received: from mail pickup service by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC; Fri, 28 Nov 2003 09:46:26 +0000
Received: from above.proper.com ([208.184.76.39]) by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 26 Nov 2003 16:09:46 +0000
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQF31ib025846 for <[e-mail]>; Wed, 26 Nov 2003 07:03:01 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQF31Fi025845 for ietf-pkix-bks; Wed, 26 Nov 2003 07:03:01 -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.10/8.12.8) with ESMTP id hAQF30ib025837 for <[e-mail]>; Wed, 26 Nov 2003 07:03:00 -0800 (PST) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id hAQF2tsj016901; Wed, 26 Nov 2003 10:02:56 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p06010204bbea6fb4d743@[128.89.89.75]>
In-Reply-To: <009e01c3b40d$329bed40$0500a8c0@arport>
References: <009e01c3b40d$329bed40$0500a8c0@arport>
Date: Wed, 26 Nov 2003 09:57:09 -0500
To: "Anders Rundgren" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Da Capo: Re: Certificate Policy Standardization
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-OriginalArrivalTime: 26 Nov 2003 16:09:46.0800 (UTC) FILETIME=[B61C1300:01C3B437]
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
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 +0100 11/26/03, Anders Rundgren wrote:
>  >Policy OIDs might come handy to protect RPs from issuing authorities who
>>might seek to alter their terms arbitrarily without necessarily providing
>>notice to that effect. In practice, ambiguity over the exact content of
>>applicable policy might render that CP unenforceable.
>
>When I read a statement like above, I get really sad and begin
>to completely lose faith in the PKI technology [1], wondering
>if I maybe should go and waste my talent on something useful
>for a change.
>

Promises, promises ...


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASGKdib006911 for <[e-mail]>; Fri, 28 Nov 2003 08:20:39 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hASGKde0006910 for ietf-pkix-bks; Fri, 28 Nov 2003 08:20:39 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.smarttrust.com ([213.212.5.232]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASGKVih006879 for <[e-mail]>; Fri, 28 Nov 2003 08:20:37 -0800 (PST) (envelope-from [e-mail])
Received: from sek43.smarttrust.com ([172.16.0.43]) by mail.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 17:21:21 +0100
Received: from mail pickup service by sek43.smarttrust.com with Microsoft SMTPSVC; Fri, 28 Nov 2003 17:20:33 +0100
Received: from mail.smarttrust.com ([192.168.1.10]) by sek43.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 12:12:08 +0100
Received: from sek13 ([192.168.1.15]) by mail.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 12:12:53 +0100
Received: from [208.184.76.39]:2393 (EHLO above.proper.com) by sek13.smarttrust.com ([192.168.1.15]:25) (F-Secure Anti-Virus for Internet Mail 6.0.34 Release) with SMTP; Fri, 28 Nov 2003 11:11:24 -0000
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9krib085830 for <[e-mail]>; Fri, 28 Nov 2003 01:46:53 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAS9krIb085828 for ietf-pkix-bks; Fri, 28 Nov 2003 01:46:53 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from relhubc02-ukbr.tcrelay.net ([217.32.166.20]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9kpid085784 for <[e-mail]>; Fri, 28 Nov 2003 01:46:52 -0800 (PST) (envelope-from [e-mail])
Received: from mail pickup service by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC; Fri, 28 Nov 2003 09:40:58 +0000
Received: from above.proper.com ([208.184.76.39]) by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 26 Nov 2003 17:03:57 +0000
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQGxOib031953 for <[e-mail]>; Wed, 26 Nov 2003 08:59:24 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQGxOlp031952 for ietf-pkix-bks; Wed, 26 Nov 2003 08:59:24 -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.10/8.12.8) with ESMTP id hAQGxNib031946 for <[e-mail]>; Wed, 26 Nov 2003 08:59:23 -0800 (PST) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Wed, 26 Nov 2003 11:59:18 -0500
From: "David P. Kemp" <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
CC: [e-mail]
Subject: Re: Web-PKI Keygen/Certreq Questions
References: <00e101c39fc2$a59fa200$3a1b40d5@arport> <p06002003bbc83730f4f9@[128.89.89.75]> <[e-mail]> <p0600200bbbc8676a42ac@[128.89.89.75]> <006b01c3ad13$d7ddff60$0500a8c0@arport>
In-Reply-To: <006b01c3ad13$d7ddff60$0500a8c0@arport>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-OriginalArrivalTime: 26 Nov 2003 17:05:08.0504 (UTC) FILETIME=[71FFE180:01C3B43F]
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
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>

Hopefully the consortium is planning to construct its solution by 
profiling: a) attributes to be included in RFC 2797 messages and b) 
transport of those messages over http, rather than inventing something 
from scratch.

Dave



Anders Rundgren wrote:

> Just to set the record straight: Another consortium has indeed
> [also] found the existings keygen/certreq mechanisms largely
> inferior and will publish a draft solution in a couple of months
> or so.  I just talked to one of the architects, and he confirmed that
> it will support the kind of stuff that most of the proprietary solutions
> already do, such as key-container co-signing, passphrase policy
> control, and multi-key generation.
> 
> /a
> 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASGKcib006904 for <[e-mail]>; Fri, 28 Nov 2003 08:20:38 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hASGKcgw006903 for ietf-pkix-bks; Fri, 28 Nov 2003 08:20:38 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.smarttrust.com ([213.212.5.232]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASGKVif006879 for <[e-mail]>; Fri, 28 Nov 2003 08:20:36 -0800 (PST) (envelope-from [e-mail])
Received: from sek43.smarttrust.com ([172.16.0.43]) by mail.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 17:21:18 +0100
Received: from mail pickup service by sek43.smarttrust.com with Microsoft SMTPSVC; Fri, 28 Nov 2003 17:20:30 +0100
Received: from mail.smarttrust.com ([192.168.1.10]) by sek43.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 12:26:07 +0100
Received: from sek13 ([192.168.1.15]) by mail.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 12:26:52 +0100
Received: from [208.184.76.39]:2765 (EHLO above.proper.com) by sek13.smarttrust.com ([192.168.1.15]:25) (F-Secure Anti-Virus for Internet Mail 6.0.34 Release) with SMTP; Fri, 28 Nov 2003 11:25:23 -0000
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9tuib086630 for <[e-mail]>; Fri, 28 Nov 2003 01:55:56 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAS9tutg086629 for ietf-pkix-bks; Fri, 28 Nov 2003 01:55:56 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from relhubc02-ukbr.tcrelay.net ([217.32.166.20]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9tqif086610 for <[e-mail]>; Fri, 28 Nov 2003 01:55:54 -0800 (PST) (envelope-from [e-mail])
Received: from mail pickup service by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC; Fri, 28 Nov 2003 09:50:02 +0000
Received: from above.proper.com ([208.184.76.39]) by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 26 Nov 2003 14:24:23 +0000
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQEIPib023318 for <[e-mail]>; Wed, 26 Nov 2003 06:18:25 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQEIPRQ023317 for ietf-pkix-bks; Wed, 26 Nov 2003 06:18:25 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp2.mivlmd.cablespeed.com (smtp2.mivlmd.cablespeed.com [24.35.0.19]) by above.proper.com (8.12.10/8.12.8) with SMTP id hAQEINib023312 for <[e-mail]>; Wed, 26 Nov 2003 06:18:23 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 17480 invoked by uid 0); 26 Nov 2003 14:17:47 -0000
Received: from unknown (HELO cablespeed.com) (24.35.57.71) by 0 with SMTP; 26 Nov 2003 14:17:47 -0000
Message-ID: <[e-mail]>
Date: Wed, 26 Nov 2003 09:19:55 -0500
From: jim <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Certificate Policy Standardization
References: <[e-mail]> <[e-mail]>            <00e001c3b366$7c1cbc80$0500a8c0@arport> <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-OriginalArrivalTime: 26 Nov 2003 14:24:24.0070 (UTC) FILETIME=[FD780A60:01C3B428]
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
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>

Richard brings up an excellent point that should be considered by the 
members of this body.  On the horizon is the implementation of security 
middleware from a number of sources, which will allow for simpler 
PKEnablement of Web applications.  The issue in this regard is going to 
be the identification of how trust can be shared without having to go 
back to the original CA who issued a cert and cross-certifying CAs in 
that regard so that Internet commerce can be accomplished with many uses 
on the fly from disparate PKIs.  Meaningful OIDs offer a lot that can 
increase the success or failure of PK technology adaptation for 
commerce.  In that regard, please everyone, see what you can think of 
that will make this a useful and helpful solution to allow PK technology 
to flourish.

Jim Heimberg, ABC, Ph.D.
Secure Course
www.securecourse.com


Richard Levitte - VMS Whacker wrote:

>In message <00e001c3b366$7c1cbc80$0500a8c0@arport> on Tue, 25 Nov 2003 16:11:57 +0100, "Anders Rundgren" <[e-mail]> said:
>
>anders.rundgren> Policy OIDs may be "perfect" as long as you stay
>anders.rundgren> inside of your "walled garden", but the USs
>anders.rundgren> government PKI will likely find itself up the creek
>anders.rundgren> when they are going to connect to the outside world
>anders.rundgren> who hardly ever use this feature (which I BTW cannot
>anders.rundgren> find a single "knob" for in my W2K system), or even
>anders.rundgren> worse, have settled on another set of OIDs.
>
>Uhmm, especially that last thing about other PKIs having other sets
>of OIDs makes me think you have missed the mechanism called "policy
>mapping".  There's no requirement whatsoever that everyone uses the
>same set of OIDs.  However, if the owner of one PKI decides to do
>business with another PKI owner and have the two PKIs connected, they
>will typically do some cross certification, and those certificates
>will contain the appropriate mappings of policies, as decided by the
>two parties together.
>
>As far as I understand, those kinds of mechanisms are already in use
>and working.  I assume others here will be able to say yay or ney
>about this matter.
>
>Of course, what I said above implies some level of "meshness", about
>which I've read some negative comments from one person...
>
>-----
>Please consider sponsoring my work on free software.
>See http://www.free.lp.se/sponsoring.html for details.
>You don't have to be rich, a $10 donation is appreciated!
>
>  
>





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASGKaib006896 for <[e-mail]>; Fri, 28 Nov 2003 08:20:36 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hASGKa4W006895 for ietf-pkix-bks; Fri, 28 Nov 2003 08:20:36 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.smarttrust.com ([213.212.5.232]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASGKVid006879 for <[e-mail]>; Fri, 28 Nov 2003 08:20:35 -0800 (PST) (envelope-from [e-mail])
Received: from sek43.smarttrust.com ([172.16.0.43]) by mail.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 17:21:16 +0100
Received: from mail pickup service by sek43.smarttrust.com with Microsoft SMTPSVC; Fri, 28 Nov 2003 17:20:28 +0100
Received: from mail.smarttrust.com ([192.168.1.10]) by sek43.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 12:11:31 +0100
Received: from sek13 ([192.168.1.15]) by mail.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 12:12:16 +0100
Received: from [208.184.76.39]:2064 (EHLO above.proper.com) by sek13.smarttrust.com ([192.168.1.15]:25) (F-Secure Anti-Virus for Internet Mail 6.0.34 Release) with SMTP; Fri, 28 Nov 2003 11:10:47 -0000
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9kXib085732 for <[e-mail]>; Fri, 28 Nov 2003 01:46:33 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAS9kX4M085729 for ietf-pkix-bks; Fri, 28 Nov 2003 01:46:33 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from relhubc02-ukbr.tcrelay.net ([217.32.166.20]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9kUid085694 for <[e-mail]>; Fri, 28 Nov 2003 01:46:32 -0800 (PST) (envelope-from [e-mail])
Received: from mail pickup service by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC; Fri, 28 Nov 2003 09:40:40 +0000
Received: from above.proper.com ([208.184.76.39]) by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 26 Nov 2003 16:13:37 +0000
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQF6oib026145 for <[e-mail]>; Wed, 26 Nov 2003 07:06:50 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQF6nTf026144 for ietf-pkix-bks; Wed, 26 Nov 2003 07:06:49 -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.10/8.12.8) with ESMTP id hAQF6mib026135 for <[e-mail]>; Wed, 26 Nov 2003 07:06:48 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (127.0.0.1) by nic.lp.se (MX V5.3 VnHj) with ESMTP; Wed, 26 Nov 2003 16:06:47 +0100
Date: Wed, 26 Nov 2003 16:06:46 +0100 (CET)
Message-ID: <[e-mail]>
To: [e-mail]
CC: [e-mail]
Subject: Re: Certificate Policy Standardization
From: Richard Levitte - VMS Whacker <[e-mail]>
In-Reply-To: <028101c3b424$7dd4b460$0500a8c0@arport>
References: <00e001c3b366$7c1cbc80$0500a8c0@arport> <[e-mail]> <028101c3b424$7dd4b460$0500a8c0@arport>
X-URL: http://www.lp.se/
X-Waved: dead chicken, GNU emacs 21.3.1, Mew version 4.0.60
X-Mew: See http://www.mew.org/
X-Mailer: Mew version 4.0.60 on Emacs 21.3.1 / Mule 5.0 (SAKAKI)
MIME-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-OriginalArrivalTime: 26 Nov 2003 16:14:26.0425 (UTC) FILETIME=[5CC77690:01C3B438]
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
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 <028101c3b424$7dd4b460$0500a8c0@arport> on Wed, 26 Nov 2003 14:52:10 +0100, "Anders Rundgren" <[e-mail]> said:

anders.rundgren> Richard,

Anders,

anders.rundgren> That external parties to the US e-governments, like
anders.rundgren> various businesses would ever (on a wider scale)
anders.rundgren> bother with cross-certification is unlikely, they
anders.rundgren> will just purchase a TTP-issued "business
anders.rundgren> certificate" for a few hundred dollars, not run CAs.

Wait, weren't you just asking about connecting different PKIs
together, or did I misunderstand you?  Going out shopping "business
certificates" will mean absolutely nothing in terms of PKI connection
unless everyone agrees to shop from the same CA.  I see that
happening, right...

It's true that smaller businesses will most likely not bother running
their own CA (unless they are run by techno-geeks like me, but that's
a different matter :-)).  I'm not so sure about larger ones...

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.
You don't have to be rich, a $10 donation is appreciated!

-- 
Richard Levitte     | http://richard.levitte.org/ | Tunnlandsv. 3
Levitte Programming | http://www.lp.se/           | S-168 36 Bromma
T: [phone] |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASGKXib006888 for <[e-mail]>; Fri, 28 Nov 2003 08:20:33 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hASGKX8S006887 for ietf-pkix-bks; Fri, 28 Nov 2003 08:20:33 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.smarttrust.com ([213.212.5.232]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASGKVib006879 for <[e-mail]>; Fri, 28 Nov 2003 08:20:32 -0800 (PST) (envelope-from [e-mail])
Received: from sek43.smarttrust.com ([172.16.0.43]) by mail.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 17:21:13 +0100
Received: from mail pickup service by sek43.smarttrust.com with Microsoft SMTPSVC; Fri, 28 Nov 2003 17:20:21 +0100
Received: from mail.smarttrust.com ([192.168.1.10]) by sek43.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 12:03:31 +0100
Received: from sek13 ([192.168.1.15]) by mail.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 12:04:16 +0100
Received: from [208.184.76.39]:4103 (EHLO above.proper.com) by sek13.smarttrust.com ([192.168.1.15]:25) (F-Secure Anti-Virus for Internet Mail 6.0.34 Release) with SMTP; Fri, 28 Nov 2003 11:02:47 -0000
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9rmib086512 for <[e-mail]>; Fri, 28 Nov 2003 01:53:48 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAS9rmHI086511 for ietf-pkix-bks; Fri, 28 Nov 2003 01:53:48 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from relhubc02-ukbr.tcrelay.net ([217.32.166.20]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9rkib086503 for <[e-mail]>; Fri, 28 Nov 2003 01:53:46 -0800 (PST) (envelope-from [e-mail])
Received: from mail pickup service by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC; Fri, 28 Nov 2003 09:47:52 +0000
Received: from above.proper.com ([208.184.76.39]) by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 26 Nov 2003 16:24:53 +0000
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQEr6ib025318 for <[e-mail]>; Wed, 26 Nov 2003 06:53:06 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQEr6aR025317 for ietf-pkix-bks; Wed, 26 Nov 2003 06:53:06 -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.10/8.12.8) with ESMTP id hAQEr5ib025306 for <[e-mail]>; Wed, 26 Nov 2003 06:53:05 -0800 (PST) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id hAQEqcsj016166; Wed, 26 Nov 2003 09:52:39 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p06010201bbea6cf53279@[128.89.89.75]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Wed, 26 Nov 2003 09:49:16 -0500
To: [e-mail] (Peter Gutmann)
From: Stephen Kent <[e-mail]>
Subject: Re: Certificate Policy Standardization
Cc: [e-mail], [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-OriginalArrivalTime: 26 Nov 2003 16:25:53.0566 (UTC) FILETIME=[F658DBE0:01C3B439]
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
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 19:07 +1300 11/26/03, Peter Gutmann wrote:
>Stephen Kent <[e-mail]> writes:
>
>>Note that with the advent of 3280, we decided to let protocols that are PKI
>>clients define extended key usage options for themselves.
>
>I recently had to deal with someone who's working with certs from (at least)
>two difference (largeish) public CAs.  One CA turned the eKU into a kind of
>lamp test packet, with every usage they could think of set ("Let's see, what
>have we got here... timestamping, IPsec, encrypted filesystem, Win2K logon,
>and S/MIME, that sounds like a sensible combination of usages for a private
>key").  The other CA didn't populate the eKU at all, justifying it with
>"Everything ignores those anyway, so it doesn't matter what you put in there"
>(obviously they have to ignore them, in order to allow certs like the ones I'm
>describing to function).  In the end after taking legal considerations into
>account the conclusion was to define a new eKU, "doWhatISay", defined as "This
>key may only be used as we say it can be used" (it's not quite worded like
>that in their CPS, that'll take another six months for the lawyers to sort
>out).
>
>I dunno about the situation in the PKIX reality, but in the real world from
>the legal point of view (which is what matters in the end) that's about the
>best way to make use of eKU.
>
>Peter.

Your example is one in which CAs chose to make up their own, private 
EKUs. This is certainly allowed, but it is not what I said we had 
decided to do in the IETF, where we would expect EKU OIDs to be 
standardized by the cognizant WGs for the protocols with which the 
certs are used.

Also, you claim that what matters in the end is what "the legal point 
of view" says.  This is certainly true in some contexts, but not all 
certs are used in ways that have legal ramifications of the sort you 
imply. For example, most certs used with IKE will not be subject to 
some attorney's advice, I suspect.

Steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASGHsib006666 for <[e-mail]>; Fri, 28 Nov 2003 08:17:54 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hASGHsYf006665 for ietf-pkix-bks; Fri, 28 Nov 2003 08:17:54 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.smarttrust.com ([213.212.5.232]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASGHqib006653 for <[e-mail]>; Fri, 28 Nov 2003 08:17:52 -0800 (PST) (envelope-from [e-mail])
Received: from sek43.smarttrust.com ([172.16.0.43]) by mail.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 17:18:34 +0100
Received: from mail pickup service by sek43.smarttrust.com with Microsoft SMTPSVC; Fri, 28 Nov 2003 17:17:42 +0100
Received: from mail.smarttrust.com ([192.168.1.10]) by sek43.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 14:32:59 +0100
Received: from sek13 ([192.168.1.15]) by mail.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 14:33:44 +0100
Received: from [208.184.76.39]:3820 (EHLO above.proper.com) by sek13.smarttrust.com ([192.168.1.15]:25) (F-Secure Anti-Virus for Internet Mail 6.0.34 Release) with SMTP; Fri, 28 Nov 2003 13:32:15 -0000
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASBsVib096972 for <[e-mail]>; Fri, 28 Nov 2003 03:54:31 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hASBsVa7096971 for ietf-pkix-bks; Fri, 28 Nov 2003 03:54:31 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASBsTib096965 for <[e-mail]>; Fri, 28 Nov 2003 03:54:30 -0800 (PST) (envelope-from [e-mail])
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id NAA14290; Fri, 28 Nov 2003 13:01:10 +0100
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id MAA23309; Fri, 28 Nov 2003 12:56:46 +0100
Message-ID: <[e-mail]>
Date: Fri, 28 Nov 2003 12:54:25 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Russ Housley <[e-mail]>, Alice Sturgeon <[e-mail]>
CC: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-warranty-extn-04.txt
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-OriginalArrivalTime: 28 Nov 2003 13:33:44.0375 (UTC) FILETIME=[3E7EE470:01C3B5B4]
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>

Alice and Russ,

I have sent several message about the status of  draft-ietf-pkix-warranty-extn.

My last message on that topic has been addressed to Alice, but I have not 
received a response yet.

Please, Russ, would you also clarify where we are now, with respect to the 
comments that I sent during the last call.

Denis


> Alice,
> 
> Does this new document addresses the issues I raised to the IESG during 
> the last call ?
> 
> If yes, would you please provide a resolution for my comments.
> 
> Denis
> 
> 
>> 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 Warranty 
>> Certificate Extension
>>     Author(s)    : D. Linsenbardt, S. Pontius, A. Sturgeon
>>     Filename    : draft-ietf-pkix-warranty-extn-04.txt
>>     Pages        : 8
>>     Date        : 2003-11-18
>>     
>> This document describes a certificate extension to explicitly state
>> the warranty offered by a Certificate Authority (CA) for a the
>> certificate containing the extension.
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-pkix-warranty-extn-04.txt
>>
>> To remove yourself from the IETF Announcement list, send a message to 
>> ietf-announce-request with the word unsubscribe in the body of the 
>> message.
>>
>> 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-warranty-extn-04.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-warranty-extn-04.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 [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASGHjib006651 for <[e-mail]>; Fri, 28 Nov 2003 08:17:45 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hASGHiuD006650 for ietf-pkix-bks; Fri, 28 Nov 2003 08:17:44 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.smarttrust.com ([213.212.5.232]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASGHhib006642 for <[e-mail]>; Fri, 28 Nov 2003 08:17:43 -0800 (PST) (envelope-from [e-mail])
Received: from sek43.smarttrust.com ([172.16.0.43]) by mail.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 17:18:25 +0100
Received: from mail pickup service by sek43.smarttrust.com with Microsoft SMTPSVC; Fri, 28 Nov 2003 17:17:37 +0100
Received: from mail.smarttrust.com ([192.168.1.10]) by sek43.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 16:05:41 +0100
Received: from sek13 ([192.168.1.15]) by mail.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 15:50:42 +0100
Received: from [208.184.76.39]:2163 (EHLO above.proper.com) by sek13.smarttrust.com ([192.168.1.15]:25) (F-Secure Anti-Virus for Internet Mail 6.0.34 Release) with SMTP; Fri, 28 Nov 2003 14:49:12 -0000
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASDXNib000685 for <[e-mail]>; Fri, 28 Nov 2003 05:33:23 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hASDXNdY000684 for ietf-pkix-bks; Fri, 28 Nov 2003 05:33:23 -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.240.3]) by above.proper.com (8.12.10/8.12.8) with SMTP id hASDXLib000679 for <[e-mail]>; Fri, 28 Nov 2003 05:33:22 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 5153 invoked by uid 0); 28 Nov 2003 13:33:01 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.33.92) by woodstock.binhost.com with SMTP; 28 Nov 2003 13:33:01 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Fri, 28 Nov 2003 08:33:20 -0500
To: Denis Pinkas <[e-mail]>, Alice Sturgeon <[e-mail]>, [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-warranty-extn-04.txt
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
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-OriginalArrivalTime: 28 Nov 2003 14:50:42.0453 (UTC) FILETIME=[FF15AC50:01C3B5BE]
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>

Denis:

Steve Bellovin is the shepherd for this document.  He will have more 
up-to-date information than me.

Russ

At 12:54 PM 11/28/2003 +0100, Denis Pinkas wrote:
>Please, Russ, would you also clarify where we are now, with respect to the 
>comments that I sent during the last call.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASGHYib006640 for <[e-mail]>; Fri, 28 Nov 2003 08:17:34 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hASGHYCD006639 for ietf-pkix-bks; Fri, 28 Nov 2003 08:17:34 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.smarttrust.com ([213.212.5.232]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASGHTid006618 for <[e-mail]>; Fri, 28 Nov 2003 08:17:31 -0800 (PST) (envelope-from [e-mail])
Received: from sek43.smarttrust.com ([172.16.0.43]) by mail.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 17:18:14 +0100
Received: from mail pickup service by sek43.smarttrust.com with Microsoft SMTPSVC; Fri, 28 Nov 2003 17:17:18 +0100
Received: from mail.smarttrust.com ([192.168.1.10]) by sek43.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 15:42:27 +0100
Received: from sek13 ([192.168.1.15]) by mail.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 15:43:12 +0100
Received: from [208.184.76.39]:1859 (EHLO above.proper.com) by sek13.smarttrust.com ([192.168.1.15]:25) (F-Secure Anti-Virus for Internet Mail 6.0.34 Release) with SMTP; Fri, 28 Nov 2003 14:41:42 -0000
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASDHDib000163 for <[e-mail]>; Fri, 28 Nov 2003 05:17:13 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hASDHDKk000161 for ietf-pkix-bks; Fri, 28 Nov 2003 05:17:13 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from zloty.izecom.com (cust.10.30.adsl.cistron.nl [62.216.10.30]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASDHAib000154 for <[e-mail]>; Fri, 28 Nov 2003 05:17:11 -0800 (PST) (envelope-from [e-mail])
Received: from pengo ([192.168.0.235]) by zloty.izecom.com (8.12.8p1/8.12.8) with SMTP id hASDGuGh015655; Fri, 28 Nov 2003 14:16:56 +0100
Message-Id: <4.3.2.7.2.20031128140532.02a3dea0@localhost>
X-Sender: chk@192.168.0.200@localhost
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 28 Nov 2003 14:16:42 +0100
To: "Peter Gutmann"<[e-mail] (Peter Gutmann)>
From: Christine Karman <[e-mail]>
Subject: Re: Straw poll: An advice to a commercial CA
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="{42F53F2B-4D8D-44E0-8C4D-FB0FF7232BEB}"
X-Izemail-Send-Version: 1.3.0.445 (POP3)
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-OriginalArrivalTime: 28 Nov 2003 14:43:12.0328 (UTC) FILETIME=[F2CA0C80:01C3B5BD]
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.

--{42F53F2B-4D8D-44E0-8C4D-FB0FF7232BEB}
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 12:27 11-27-03, Peter Gutmann wrote:

>To answer an earlier question about support for policy restrictions, cryptlib
>supports these (policy constraints with all its weird variations).  If
>cryptlib finds constraints in a CA cert it'll apply them down the chain, but
>there's no way for a user to configure the behaviour.  The reason for this is
>that no-one has ever asked for this [0], so I can't even begin to imagine what
>sort of interface it'd require to manage things.  Do users type in a list of
>OIDs from a piece of paper?  Do they click on a CA cert and say "Use the
>policies advertised by this CA"?

Typical users hardly know what a CA is. They don't know what kind of 
policies you are talking about. So a GUI would assume a most probable 
strategy, and then prompt the user with "I recommend you adopt policy xyz 
for this certificate. Press 'OK', or press 'advanced' to change". On a 
company level, a system administrator would force a certain behavior of the 
GUI, which cannot be changed by individual users.
Having said this, the GUI would probably make the choice by itself, because 
user interaction suggests that the user makes a decision on the subject, 
while in reality the user just presses a button that may as well read 
"Whatever".
I agree, this is not what the world should be like. But it is.

dagdag
Christine
--
Izecom BV
Secure e-mail and digital signatures
www.izecom.com

--{42F53F2B-4D8D-44E0-8C4D-FB0FF7232BEB}
Content-Type: application/x-pkcs7-signature; 
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIJO2wYJKoZIhvcNAQcCoIJOzDCCTsgCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCCTI0w
ggI9MIIBpgIRAM26f1bw3+S8VP4irLNyqlUwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UEBhMCVVMx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5
IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk2MDEyOTAwMDAwMFoXDTI4MDgwMTIzNTk1OVow
XzELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAx
IFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUA
A4GNADCBiQKBgQDlGb9to1ZhLZlIcfZn3rmN67eehoAKkQ76OCWvRoiC5XOooJskXQ0fzGVuDLDQ
VoQYh5oGmxChc9+0WDlrbsH2FdWoqD+qEgaNMax/sDTXjzRniAnNFBHiTkVWaR94AoDa3EeRKbs2
yWNcxeDXLYd7obcysHswuiovMaruo2fa2wIDAQABMA0GCSqGSIb3DQEBAgUAA4GBAEw/uIvGaN/u
QzMOXemmyweETXoz/5Ib9Dat2JUiNmgRbHxCzPOcLsQHPxSwD0//kJJ2+eK8SumPzaCACvfFKfGC
Il24sd2BI6N7JRVGMHkW+OoFS5R/HcIcyOO39BBAPBPDXx9T6EjkhrR7oTWweyW6uNOOqz84nQA0
AJjz0XGUMIICPTCCAaYCEQDNun9W8N/kvFT+IqyzcqpVMA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNV
BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMg
UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05NjAxMjkwMDAwMDBaFw0yODA4MDEy
MzU5NTlaMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMu
Q2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG
9w0BAQEFAAOBjQAwgYkCgYEA5Rm/baNWYS2ZSHH2Z965jeu3noaACpEO+jglr0aIguVzqKCbJF0N
H8xlbgyw0FaEGIeaBpsQoXPftFg5a27B9hXVqKg/qhIGjTGsf7A01480Z4gJzRQR4k5FVmkfeAKA
2txHkSm7NsljXMXg1y2He6G3MrB7MLoqLzGq7qNn2tsCAwEAATANBgkqhkiG9w0BAQIFAAOBgQBM
P7iLxmjf7kMzDl3ppssHhE16M/+SG/Q2rdiVIjZoEWx8QszznC7EBz8UsA9P/5CSdvnivErpj82g
gAr3xSnxgiJduLHdgSOjeyUVRjB5FvjqBUuUfx3CHMjjt/QQQDwTw18fU+hI5Ia0e6E1sHslurjT
jqs/OJ0ANACY89FxlDCCAzswggIjoAMCAQICEH51qFsO2Pq5fgSIHQ5ZZzMwDQYJKoZIhvcNAQEF
BQAwgY4xEjAQBgNVBAoTCUl6ZWNvbSBCVjEfMB0GCSqGSIb3DQEJARYQaW5mb0BpemVtYWlsLmNv
bTEMMAoGA1UECBMDbi9hMRIwEAYDVQQHEwlBbXN0ZXJkYW0xCzAJBgNVBAYTAk5MMSgwJgYDVQQD
Ex9JemVtYWlsIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTAzMDMwNjIxMTMwOVoXDTA0MDMx
MjIxMTMwOVowdDELMAkGA1UEBhMCTkwxEjAQBgNVBAcTCUFtc3RlcmRhbTESMBAGA1UEChMJWmFw
aG9kIEJWMSIwIAYJKoZIhvcNAQkBFhNjaHJpc3RpbmVAa2FybWFuLm5sMRkwFwYDVQQDExBDaHJp
c3RpbmUgS2FybWFuMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC0qliGIqcmrgFgH3WukcAS
WU6NIo+a2Tb07f022Ew7CK7lENXx2uav6S6JMcz+67t1tJqfy6JdAxVcAIY65seKx1AApFnTMsE1
W8Nmqrv6A1mOC6R3148OSlcJhYqzyU+vSVRJdaYtwZIYXy+S6DUk94eY48ItH1GpbK5ixk9njQID
AQABozIwMDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwDwYDVR0TBAgwBgEBAAIBADAN
BgkqhkiG9w0BAQUFAAOCAQEAJgqIr+yuq8YWe0asKjNZG3J0ue4X7+NwhZkaElWyJ+Zraidpp/wq
YlcR6aUCzh4GYohltLaotQ+Bg366dS6XyTnukgxSaAsbXz2Yjv+aW3y9jKkJFW6kPcdoKcP8RZer
YwvQ1cW+4nRre8XvJasPuFD1DtEMHHIYedcbrYI7+cpt4WXTOSHj7Jcn7TSCbgrcNdTx8ij6bBCB
snVHEZSl7beWR+cGZGLIZk0/XFuDe0lZBqTgraIFC1p3TPLZ0HQLPpXAiE9xpOmrobLO5X+6SNtV
NmdMX3Ni4UyspgoZnhzNniDYb9SsdhYJ3iKsLjqgluStQFXT1oSr3lVl1M4ccDCCA0QwggIsoAMC
AQICEAeuoFSX1AX4LCO3xTKgFukwDQYJKoZIhvcNAQEFBQAwgY4xEjAQBgNVBAoTCUl6ZWNvbSBC
VjEfMB0GCSqGSIb3DQEJARYQaW5mb0BpemVtYWlsLmNvbTEMMAoGA1UECBMDbi9hMRIwEAYDVQQH
EwlBbXN0ZXJkYW0xCzAJBgNVBAYTAk5MMSgwJgYDVQQDEx9JemVtYWlsIENlcnRpZmljYXRpb24g
QXV0aG9yaXR5MB4XDTAzMDEzMDIwMzQzN1oXDTA0MDIwNjIwMzQzN1owfTEUMBIGA1UEBhMLTmV0
aGVybGFuZHMxEjAQBgNVBAcTCUFtc3RlcmRhbTEPMA0GA1UEChMGWmFwaG9kMSUwIwYJKoZIhvcN
AQkBFhZjaHJpc3RpbmVAY2hyaXN0aW5lLm5sMRkwFwYDVQQDExBDaHJpc3RpbmUgS2FybWFuMIGf
MA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCulat3hEupfMrJpuw1/eOnpI7u4LZLXDBJxRlRcu3z
6XhKZRmFbWCWdHRK3e1IoSqzpCIM/DZmvtfWjYQSrDKIMhwAjVfc04s53G9EZ01NfYpYL9X4SXWX
Y4dwUFCxc+54fejUXPDnamrxmw8m68tqdQbA3E1dKWWiqUbgKWjbpwIDAQABozIwMDAdBgNVHSUE
FjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwDwYDVR0TBAgwBgEBAAIBADANBgkqhkiG9w0BAQUFAAOC
AQEAbViEzzTQzuapibeZVx8JQvCzMc/8cYKwUwrzK2COxd0GX8puYOFMMLFNBysdQh2ZV5dzAaWi
bubjf6Ip28dMCPUvSRnyON4GD9nYesROYs0hWdDJjSnsEplyQ8UFtn+bTzlvsuyjj5oMQwas0fkR
6TB1Rql3FuhtbwFaqv5P4uoD9aaLP/KJbVFty9d9fho9/gDBmYEfIZTjnTczjQeH8gdCthb9bdg3
kr+DvlIFsyomOYN/PUTA49qjx8k1hkIwT7eUDPkGOa6d+MxEduTUTCRSnU+pqC9U9gMw/p/lrvPd
2wM87T93SRBJC7J3XRxEa1DsBBK5So9E8PYQJNh8azCCA2IwggLLoAMCAQICEAvaCxfBP4mOqwl0
erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ
bmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9y
aXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWdu
LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVy
aXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgw
RgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25h
IE5vdCBWYWxpZGF0ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2U
TxV4NrgNSrJvnFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7
u77JJwpdtrA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZ
AgMBAAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w
KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCowKDAm
oCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEGMBEGCWCG
SAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzkTCuPHv6SQKzY
CjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+sMVTUixnI2COo7wQr
Mn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+i+P7FTCCA2IwggLLoAMC
AQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UEBhMCVVMxFzAVBgNV
BAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp
ZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4MDUxMjIzNTk1OVowgcwxFzAV
BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYw
RAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixM
SUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vi
c2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGB
ALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJvnFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8Ci
kqtEXKpC8IIOAukv+8I7u77JJwpdtrA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6
p7F+78nbN2rISsgJBuSZAgMBAAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwG
C2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S
UEEwMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYD
VR0PBAQDAgEGMBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje
6VNkIbzkTCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh
3s+sMVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+
i+P7FTCCA40wggJ1oAMCAQICEQCdN6WFU8voqm9Iw16mj2uEMA0GCSqGSIb3DQEBBQUAMIGDMRIw
EAYDVQQKEwlJemVjb20gQlYxHzAdBgkqhkiG9w0BCQEWEGluZm9AaXplbWFpbC5jb20xFjAUBgNV
BAgTDU5vb3JkLUhvbGxhbmQxEjAQBgNVBAcTCUFtc3RlcmRhbTELMAkGA1UEBhMCTkwxEzARBgNV
BAMTCkl6ZW1haWwgQ0EwHhcNMDMxMTA1MTQ1MzM4WhcNMDQwMjA1MjMwMDAwWjBtMQswCQYDVQQG
EwJOTDESMBAGA1UEBxMJQW1zdGVyZGFtMQkwBwYDVQQKEwAxJTAjBgkqhkiG9w0BCQEWFmNocmlz
dGluZUBjaHJpc3RpbmUubmwxGDAWBgNVBAMTD0NocmlzdGluZSBwcml2ZTCBnzANBgkqhkiG9w0B
AQEFAAOBjQAwgYkCgYEA15upgKOSjpN/FhOGOhb7CkYFtOt2stjanOoEqWRTHfzY4B2N814fcT1n
m7p/sECpQf3LDX66NOgf4uVxjy98Uy529pSeYOUAPAZg1uxqSbxPPx4YZ/S6X5oAnvOq+nVzOxAN
uq8IaCHyK6umVKpdlBzbniBVODtlNVkxiYo8iz8CAwEAAaOBlDCBkTAPBgNVHRMECDAGAQEAAgEA
MDwGA1UdHwQ1MDMwMaAvoC2GK2h0dHA6Ly93d3cuaXplY29tLmNvbS9pemVtYWlsL2l6ZW1haWwu
MS5jcmwwIQYDVR0RBBowGIEWY2hyaXN0aW5lQGNocmlzdGluZS5ubDAdBgNVHSUEFjAUBggrBgEF
BQcDBAYIKwYBBQUHAwIwDQYJKoZIhvcNAQEFBQADggEBADnoQbAh9WFjy97IuNoi4a1w557FusxU
aYlGzb1mvCZbs00vb1Yexv6IAYtFKgpSMrKF8x5i4G5yL/3ZzU5UPMHawEHL3mIOJNnKpOzk/6lY
PSCWTo1nHNaFM7Sz/++KPDJ0Y4Ji2DJcLzx8VWJeEulhf/xdRQcG/Muf1B+Jz6U+8QmA42Ail1od
KcQQfL9QkoHL/YZekyFFS+K+Me0Q4ilO94jGo/1ryo7PL66gMxz+snwBYSrL3J9WOe2WiG18ZKLI
xIKc0La4Wf4lz5/tlA3DqW6yqHpumq4lD+F0y8kLw3HsemBPdqJ5usM5CSgUNf9ods4EB1UEwB5r
pjLtKNYwggOZMIICgaADAgECAhEAp5HQLk86PUNLsj8f7VFTjDANBgkqhkiG9w0BAQUFADCBjjES
MBAGA1UEChMJSXplY29tIEJWMR8wHQYJKoZIhvcNAQkBFhBpbmZvQGl6ZW1haWwuY29tMQwwCgYD
VQQIEwNuL2ExEjAQBgNVBAcTCUFtc3RlcmRhbTELMAkGA1UEBhMCTkwxKDAmBgNVBAMTH0l6ZW1h
aWwgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMDMwOTI5MDk1NjEzWhcNMDQxMDA1MDk1NjEz
WjByMQswCQYDVQQGEwJOTDESMBAGA1UEBxMJYW1zdGVyZGFtMQ8wDQYDVQQKEwZpemVjb20xIzAh
BgkqhkiG9w0BCQEWFGNocmlzdGluZUBpemVjb20uY29tMRkwFwYDVQQDExBjaHJpc3RpbmUga2Fy
bWFuMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8x5Pje5kP7gi6jdYcCl4Z0MeQx2zwRQmi
mfC3oIZvxG84Dnv8mPsM9pIQnuxjNJobv+GzQSQAk/baCUx28X8dZY5cjB8JGWAlC65XXzGWGJ2u
+cc8LuJ35kXaWUpg6k8yBiCYPRM8CRmsL9r9t7Yut0YSjgs5nUu/wDmgESkJswIDAQABo4GQMIGN
MB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAPBgNVHRMECDAGAQEAAgEAMDoGA1UdHwQz
MDEwL6AtoCuGKWh0dHA6Ly93d3cuaXplY29tLmNvbS9pemVtYWlsL2l6ZW1haWwuY3JsMB8GA1Ud
EQQYMBaBFGNocmlzdGluZUBpemVjb20uY29tMA0GCSqGSIb3DQEBBQUAA4IBAQA8LC2fl9YWSS6U
/VByvgKyHf905fQxJ15r3K1xlLK3eoe49e2iFOMsMiCzTp1R8VSLGDzhyYJNTPonRVD5fmIuxNYt
KqycuAAycaSiLvg/U2kXXgdzuVHBQW9l4CWtl9H3kM4hm630WNJRKTNJv6X3et/xUy/At/xXDT3h
5tjFJgcud+3NqsRjNoq6uYRvETzxrCKLj/PLQ7lI2Mvnm6GywXXQM1GJcDjzRcb7GScjiXfsBtau
ZKEJDa0boKfUtGT6CYAxlIgciQtSkG+4IIf+OUfeGuZA8nhA/GfIkyygUPixB/CkAYYOFvGHFmVE
4u2ItGXR8do6l2cXpxYvtVY8MIIDqzCCApOgAwIBAgIRAPfl7mMkXQ6kKqRIT7cqvBcwDQYJKoZI
hvcNAQEFBQAwgZExEjAQBgNVBAoTCUl6ZWNvbSBCVjEeMBwGCSqGSIb3DQEJARYPaW5mb0BpemVj
b20uY29tMQwwCgYDVQQIEwNuL2ExEjAQBgNVBAcTCUFtc3RlcmRhbTELMAkGA1UEBhMCTkwxLDAq
BgNVBAMTI0l6ZWNvbSBSb290IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTAzMDEyOTE2MjA0
NloXDTE2MDIwMjE2MjA0NlowgZExEjAQBgNVBAoTCUl6ZWNvbSBCVjEeMBwGCSqGSIb3DQEJARYP
aW5mb0BpemVjb20uY29tMQwwCgYDVQQIEwNuL2ExEjAQBgNVBAcTCUFtc3RlcmRhbTELMAkGA1UE
BhMCTkwxLDAqBgNVBAMTI0l6ZWNvbSBSb290IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MIIBIDAN
BgkqhkiG9w0BAQEFAAOCAQ0AMIIBCAKCAQEA9XehWqD0AK8jSepGl5mMpn3LWW930PXr5RtckP/R
tVAu08TIOAkILvlx5Sjm2nOqbdYUHavIRgMLoyI0gaH8vKINixLDgb/vgtTVQkd09k+VGIOJ/jq4
0PvWQ4BVRImd/0mbMYgAePhFSQrgRfALhd0e+pNweBEO5Gg+OYkElGU6f5B+cH3LHiMhfJ7JEJKG
jMHsFGGDAp/jeQTcK9icqCg+NqR/FT/xw6eh35ucxL5A74hFvog06u8m5MAOB2Y7RT2NPHAoYy3W
CdYeSZmWYnQa0GRn0WBCvefQdtL6mCkMfwcP0EBBV2dnz+nz93XE7ln06j8gaw1bBMDEibHo+wIB
ETANBgkqhkiG9w0BAQUFAAOCAQEAi7ej2XrLJv896UmfB1QSsCz87MbBgH8IJDMKODQG9fd1mEBk
YLrtSUamMgYLp1yY/jLLwoMa9Am6+wL1UjeBiiv0CXHy+K69uM1DnarenYqDIJOoLJ+7bNifG28y
uPiaelCT3KPSB4Z06K6iOY2ZTU2eNw+HIQC06mR9x0oSa97yWf51CsiKbj+yE2GUd8dUuEVMqiCH
B5KLAJGh/MsoapVJygOcRXh1JHhRPOicqzNXOZaML2RE1glkJJsugLul9ZG5OtJaabQ3T59eUVB5
0mM8FXl5KZmRD4Uu3LNd+JwUVweURQxpkA23DB+hPcTLyQyPxVAr8idWdRfPp3IlBzCCA6swggKT
oAMCAQICEQD35e5jJF0OpCqkSE+3KrwXMA0GCSqGSIb3DQEBBQUAMIGRMRIwEAYDVQQKEwlJemVj
b20gQlYxHjAcBgkqhkiG9w0BCQEWD2luZm9AaXplY29tLmNvbTEMMAoGA1UECBMDbi9hMRIwEAYD
VQQHEwlBbXN0ZXJkYW0xCzAJBgNVBAYTAk5MMSwwKgYDVQQDEyNJemVjb20gUm9vdCBDZXJ0aWZp
Y2F0aW9uIEF1dGhvcml0eTAeFw0wMzAxMjkxNjIwNDZaFw0xNjAyMDIxNjIwNDZaMIGRMRIwEAYD
VQQKEwlJemVjb20gQlYxHjAcBgkqhkiG9w0BCQEWD2luZm9AaXplY29tLmNvbTEMMAoGA1UECBMD
bi9hMRIwEAYDVQQHEwlBbXN0ZXJkYW0xCzAJBgNVBAYTAk5MMSwwKgYDVQQDEyNJemVjb20gUm9v
dCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCCASAwDQYJKoZIhvcNAQEBBQADggENADCCAQgCggEB
APV3oVqg9ACvI0nqRpeZjKZ9y1lvd9D16+UbXJD/0bVQLtPEyDgJCC75ceUo5tpzqm3WFB2ryEYD
C6MiNIGh/LyiDYsSw4G/74LU1UJHdPZPlRiDif46uND71kOAVUSJnf9JmzGIAHj4RUkK4EXwC4Xd
HvqTcHgRDuRoPjmJBJRlOn+QfnB9yx4jIXyeyRCShozB7BRhgwKf43kE3CvYnKgoPjakfxU/8cOn
od+bnMS+QO+IRb6INOrvJuTADgdmO0U9jTxwKGMt1gnWHkmZlmJ0GtBkZ9FgQr3n0HbS+pgpDH8H
D9BAQVdnZ8/p8/d1xO5Z9Oo/IGsNWwTAxImx6PsCAREwDQYJKoZIhvcNAQEFBQADggEBAIu3o9l6
yyb/PelJnwdUErAs/OzGwYB/CCQzCjg0BvX3dZhAZGC67UlGpjIGC6dcmP4yy8KDGvQJuvsC9VI3
gYor9Alx8viuvbjNQ52q3p2KgyCTqCyfu2zYnxtvMrj4mnpQk9yj0geGdOiuojmNmU1NnjcPhyEA
tOpkfcdKEmve8ln+dQrIim4/shNhlHfHVLhFTKoghweSiwCRofzLKGqVScoDnEV4dSR4UTzonKsz
VzmWjC9kRNYJZCSbLoC7pfWRuTrSWmm0N0+fXlFQedJjPBV5eSmZkQ+FLtyzXficFFcHlEUMaZAN
twwfoT3Ey8kMj8VQK/InVnUXz6dyJQcwggOrMIICk6ADAgECAhEA9+XuYyRdDqQqpEhPtyq8FzAN
BgkqhkiG9w0BAQUFADCBkTESMBAGA1UEChMJSXplY29tIEJWMR4wHAYJKoZIhvcNAQkBFg9pbmZv
QGl6ZWNvbS5jb20xDDAKBgNVBAgTA24vYTESMBAGA1UEBxMJQW1zdGVyZGFtMQswCQYDVQQGEwJO
TDEsMCoGA1UEAxMjSXplY29tIFJvb3QgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMDMwMTI5
MTYyMDQ2WhcNMTYwMjAyMTYyMDQ2WjCBkTESMBAGA1UEChMJSXplY29tIEJWMR4wHAYJKoZIhvcN
AQkBFg9pbmZvQGl6ZWNvbS5jb20xDDAKBgNVBAgTA24vYTESMBAGA1UEBxMJQW1zdGVyZGFtMQsw
CQYDVQQGEwJOTDEsMCoGA1UEAxMjSXplY29tIFJvb3QgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkw
ggEgMA0GCSqGSIb3DQEBAQUAA4IBDQAwggEIAoIBAQD1d6FaoPQAryNJ6kaXmYymfctZb3fQ9evl
G1yQ/9G1UC7TxMg4CQgu+XHlKObac6pt1hQdq8hGAwujIjSBofy8og2LEsOBv++C1NVCR3T2T5UY
g4n+OrjQ+9ZDgFVEiZ3/SZsxiAB4+EVJCuBF8AuF3R76k3B4EQ7kaD45iQSUZTp/kH5wfcseIyF8
nskQkoaMwewUYYMCn+N5BNwr2JyoKD42pH8VP/HDp6Hfm5zEvkDviEW+iDTq7ybkwA4HZjtFPY08
cChjLdYJ1h5JmZZidBrQZGfRYEK959B20vqYKQx/Bw/QQEFXZ2fP6fP3dcTuWfTqPyBrDVsEwMSJ
sej7AgERMA0GCSqGSIb3DQEBBQUAA4IBAQCLt6PZessm/z3pSZ8HVBKwLPzsxsGAfwgkMwo4NAb1
93WYQGRguu1JRqYyBgunXJj+MsvCgxr0Cbr7AvVSN4GKK/QJcfL4rr24zUOdqt6dioMgk6gsn7ts
2J8bbzK4+Jp6UJPco9IHhnTorqI5jZlNTZ43D4chALTqZH3HShJr3vJZ/nUKyIpuP7ITYZR3x1S4
RUyqIIcHkosAkaH8yyhqlUnKA5xFeHUkeFE86JyrM1c5lowvZETWCWQkmy6Au6X1kbk60lpptDdP
n15RUHnSYzwVeXkpmZEPhS7cs134nBRXB5RFDGmQDbcMH6E9xMvJDI/FUCvyJ1Z1F8+nciUHMIID
qzCCApOgAwIBAgIRAPfl7mMkXQ6kKqRIT7cqvBcwDQYJKoZIhvcNAQEFBQAwgZExEjAQBgNVBAoT
CUl6ZWNvbSBCVjEeMBwGCSqGSIb3DQEJARYPaW5mb0BpemVjb20uY29tMQwwCgYDVQQIEwNuL2Ex
EjAQBgNVBAcTCUFtc3RlcmRhbTELMAkGA1UEBhMCTkwxLDAqBgNVBAMTI0l6ZWNvbSBSb290IENl
cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTAzMDEyOTE2MjA0NloXDTE2MDIwMjE2MjA0NlowgZEx
EjAQBgNVBAoTCUl6ZWNvbSBCVjEeMBwGCSqGSIb3DQEJARYPaW5mb0BpemVjb20uY29tMQwwCgYD
VQQIEwNuL2ExEjAQBgNVBAcTCUFtc3RlcmRhbTELMAkGA1UEBhMCTkwxLDAqBgNVBAMTI0l6ZWNv
bSBSb290IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MIIBIDANBgkqhkiG9w0BAQEFAAOCAQ0AMIIB
CAKCAQEA9XehWqD0AK8jSepGl5mMpn3LWW930PXr5RtckP/RtVAu08TIOAkILvlx5Sjm2nOqbdYU
HavIRgMLoyI0gaH8vKINixLDgb/vgtTVQkd09k+VGIOJ/jq40PvWQ4BVRImd/0mbMYgAePhFSQrg
RfALhd0e+pNweBEO5Gg+OYkElGU6f5B+cH3LHiMhfJ7JEJKGjMHsFGGDAp/jeQTcK9icqCg+NqR/
FT/xw6eh35ucxL5A74hFvog06u8m5MAOB2Y7RT2NPHAoYy3WCdYeSZmWYnQa0GRn0WBCvefQdtL6
mCkMfwcP0EBBV2dnz+nz93XE7ln06j8gaw1bBMDEibHo+wIBETANBgkqhkiG9w0BAQUFAAOCAQEA
i7ej2XrLJv896UmfB1QSsCz87MbBgH8IJDMKODQG9fd1mEBkYLrtSUamMgYLp1yY/jLLwoMa9Am6
+wL1UjeBiiv0CXHy+K69uM1DnarenYqDIJOoLJ+7bNifG28yuPiaelCT3KPSB4Z06K6iOY2ZTU2e
Nw+HIQC06mR9x0oSa97yWf51CsiKbj+yE2GUd8dUuEVMqiCHB5KLAJGh/MsoapVJygOcRXh1JHhR
POicqzNXOZaML2RE1glkJJsugLul9ZG5OtJaabQ3T59eUVB50mM8FXl5KZmRD4Uu3LNd+JwUVweU
RQxpkA23DB+hPcTLyQyPxVAr8idWdRfPp3IlBzCCA6swggKToAMCAQICEQD35e5jJF0OpCqkSE+3
KrwXMA0GCSqGSIb3DQEBBQUAMIGRMRIwEAYDVQQKEwlJemVjb20gQlYxHjAcBgkqhkiG9w0BCQEW
D2luZm9AaXplY29tLmNvbTEMMAoGA1UECBMDbi9hMRIwEAYDVQQHEwlBbXN0ZXJkYW0xCzAJBgNV
BAYTAk5MMSwwKgYDVQQDEyNJemVjb20gUm9vdCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0w
MzAxMjkxNjIwNDZaFw0xNjAyMDIxNjIwNDZaMIGRMRIwEAYDVQQKEwlJemVjb20gQlYxHjAcBgkq
hkiG9w0BCQEWD2luZm9AaXplY29tLmNvbTEMMAoGA1UECBMDbi9hMRIwEAYDVQQHEwlBbXN0ZXJk
YW0xCzAJBgNVBAYTAk5MMSwwKgYDVQQDEyNJemVjb20gUm9vdCBDZXJ0aWZpY2F0aW9uIEF1dGhv
cml0eTCCASAwDQYJKoZIhvcNAQEBBQADggENADCCAQgCggEBAPV3oVqg9ACvI0nqRpeZjKZ9y1lv
d9D16+UbXJD/0bVQLtPEyDgJCC75ceUo5tpzqm3WFB2ryEYDC6MiNIGh/LyiDYsSw4G/74LU1UJH
dPZPlRiDif46uND71kOAVUSJnf9JmzGIAHj4RUkK4EXwC4XdHvqTcHgRDuRoPjmJBJRlOn+QfnB9
yx4jIXyeyRCShozB7BRhgwKf43kE3CvYnKgoPjakfxU/8cOnod+bnMS+QO+IRb6INOrvJuTADgdm
O0U9jTxwKGMt1gnWHkmZlmJ0GtBkZ9FgQr3n0HbS+pgpDH8HD9BAQVdnZ8/p8/d1xO5Z9Oo/IGsN
WwTAxImx6PsCAREwDQYJKoZIhvcNAQEFBQADggEBAIu3o9l6yyb/PelJnwdUErAs/OzGwYB/CCQz
Cjg0BvX3dZhAZGC67UlGpjIGC6dcmP4yy8KDGvQJuvsC9VI3gYor9Alx8viuvbjNQ52q3p2KgyCT
qCyfu2zYnxtvMrj4mnpQk9yj0geGdOiuojmNmU1NnjcPhyEAtOpkfcdKEmve8ln+dQrIim4/shNh
lHfHVLhFTKoghweSiwCRofzLKGqVScoDnEV4dSR4UTzonKszVzmWjC9kRNYJZCSbLoC7pfWRuTrS
Wmm0N0+fXlFQedJjPBV5eSmZkQ+FLtyzXficFFcHlEUMaZANtwwfoT3Ey8kMj8VQK/InVnUXz6dy
JQcwggO2MIICnqADAgECAhAhQVblAVcWjoxkw84STmMBMA0GCSqGSIb3DQEBBQUAMIGOMRIwEAYD
VQQKEwlJemVjb20gQlYxHzAdBgkqhkiG9w0BCQEWEGluZm9AaXplbWFpbC5jb20xDDAKBgNVBAgT
A24vYTESMBAGA1UEBxMJQW1zdGVyZGFtMQswCQYDVQQGEwJOTDEoMCYGA1UEAxMfSXplbWFpbCBD
ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wMzExMTgxNjA4MDhaFw0wNDAxMDkyMzAwMDBaMIGG
MQswCQYDVQQGEwJOTDESMBAGA1UEBxMJQW1zdGVyZGFtMQ8wDQYDVQQKEwZJemVjb20xLDAqBgkq
hkiG9w0BCQEWHWNocmlzdGluZUBleGNoYW5nZS5pemVjb20uY29tMSQwIgYDVQQDExtDaHJpc3Rp
bmUgS2FybWFuIChFeGNoYW5nZSkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOKKHFvKAQdK
gWFEE4E47P9PK4bdoHSVR/+PttqgzhHtAmnD3CV4Szzb4kpE+rgwcBhQq35HB35kP41mSmLDg399
lcsEXJLs3DNMQo9lv8vIQb6ucK5q7sOyqrTYstvSZ/h+97tO3DHFtor5IFbrHVAGvYJe6C2Ar90Q
7dRDFkDJAgMBAAGjgZkwgZYwDwYDVR0TBAgwBgEBAAIBADA6BgNVHR8EMzAxMC+gLaArhilodHRw
Oi8vd3d3Lml6ZWNvbS5jb20vaXplbWFpbC9pemVtYWlsLmNybDAoBgNVHREEITAfgR1jaHJpc3Rp
bmVAZXhjaGFuZ2UuaXplY29tLmNvbTAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwDQYJ
KoZIhvcNAQEFBQADggEBABs+YVSWPBAglz8v8Qq8LldkOtIMHjrfzNNFs6ZVq1DgSAbbVNDNPs7B
BSMNzCFox2zvVqIEQ7BF8Uoj9VWwUGsn+FfOJ2RNG4R2radbDNZHkh/mut2Ie+Gy9VJThmxA9Gzl
FsFQOWv7cVl7Iwpkcjy4cexpL2GuBRM3qJJwDYMO/BjUOYTZacyWyom+f2xMJet63WG/ZdGzVyF8
FTm7x1ieR0C6pnNLQQD3ZYU4g2M72zUAaeBkxZ02FbyU2vzjWBDCS4DBatOlD2VLHmpfHvtCS1w3
qadUZ7K3O8XZK8HXNBa+G2vkSdsbS3eOypuY2R8dRjx5P/U8/F5A6dq2+28wggP8MIIC5KADAgEC
AhEAkRzEQl+3lUGfoi109w5blTANBgkqhkiG9w0BAQUFADCBkTESMBAGA1UEChMJSXplY29tIEJW
MR4wHAYJKoZIhvcNAQkBFg9pbmZvQGl6ZWNvbS5jb20xDDAKBgNVBAgTA24vYTESMBAGA1UEBxMJ
QW1zdGVyZGFtMQswCQYDVQQGEwJOTDEsMCoGA1UEAxMjSXplY29tIFJvb3QgQ2VydGlmaWNhdGlv
biBBdXRob3JpdHkwHhcNMDMwMTI5MTYyMTI4WhcNMTQwMjAyMTYyMTI4WjCBjjESMBAGA1UEChMJ
SXplY29tIEJWMR8wHQYJKoZIhvcNAQkBFhBpbmZvQGl6ZW1haWwuY29tMQwwCgYDVQQIEwNuL2Ex
EjAQBgNVBAcTCUFtc3RlcmRhbTELMAkGA1UEBhMCTkwxKDAmBgNVBAMTH0l6ZW1haWwgQ2VydGlm
aWNhdGlvbiBBdXRob3JpdHkwggEgMA0GCSqGSIb3DQEBAQUAA4IBDQAwggEIAoIBAQCo/rB7lTHt
ws4xQlQSA1DS6V+1ghSjfDLiWfGqiTB7wOWOPge5jnSzV355jW65X2MNJTFYlXiyLM7627XtDlYf
eIsZm0H8cHElRJoLJFGFHDkQ1H+YOUg/iTXTsRcufTvwP3ywbKe7AGdmi3pWXVWB6gJ81AtU1oJ7
K+h/g3OUqh79+Kd/zJuEAmfQrggDdeb335AW0ckOtyQ8FiISe0Op1wn7aOqvn0jKNDnnj5glsptT
aBMXU54uQHEoIrolZeyQUxvaRcfYG4UFxhMlfo9Dfp5WaJxasfLEFOmIOEmmJdbsMTyYFzgLo75Z
d2SrHh4VuuoMH22vPl5vOX6NFJsZAgERo1IwUDALBgNVHQ8EBAMCAQYwDwYDVR0TBAgwBgEB/wIB
ADARBglghkgBhvhCAQEEBAMCAQYwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqG
SIb3DQEBBQUAA4IBAQDxyi/r3gUlGF1xaGUMJ/9n9LCGW1brfpanQaZWmMGHr0l3G8eAysw7heZ8
HlAG7mZcuzeRmaPNP+orJPzu8SgVkoMUajVXJf4n1FXbcDW2KrwsUjJ+dAD8qDCUoNXJin/UjSkS
3+Bkl7MmcxDvC6mpsySah0ggqWotP0z+/8WKXY0nDFu5PueyshCZxfvHISr9eoRlljZlVx1TNVsl
DmqG42k+FR+rUJg+T8rgXpyieE6eusUB3Q9AorhksqFYfYy3oMetSVdn9ybxwfBK88GtJkH+KWNI
i9onG5AEEIDOwUcMR4bOZbexRAda2BSLcL0xdNY1S9Vb0xR7EfYkRiTPMIID/DCCAuSgAwIBAgIR
AJEcxEJft5VBn6ItdPcOW5UwDQYJKoZIhvcNAQEFBQAwgZExEjAQBgNVBAoTCUl6ZWNvbSBCVjEe
MBwGCSqGSIb3DQEJARYPaW5mb0BpemVjb20uY29tMQwwCgYDVQQIEwNuL2ExEjAQBgNVBAcTCUFt
c3RlcmRhbTELMAkGA1UEBhMCTkwxLDAqBgNVBAMTI0l6ZWNvbSBSb290IENlcnRpZmljYXRpb24g
QXV0aG9yaXR5MB4XDTAzMDEyOTE2MjEyOFoXDTE0MDIwMjE2MjEyOFowgY4xEjAQBgNVBAoTCUl6
ZWNvbSBCVjEfMB0GCSqGSIb3DQEJARYQaW5mb0BpemVtYWlsLmNvbTEMMAoGA1UECBMDbi9hMRIw
EAYDVQQHEwlBbXN0ZXJkYW0xCzAJBgNVBAYTAk5MMSgwJgYDVQQDEx9JemVtYWlsIENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5MIIBIDANBgkqhkiG9w0BAQEFAAOCAQ0AMIIBCAKCAQEAqP6we5Ux7cLO
MUJUEgNQ0ulftYIUo3wy4lnxqokwe8Dljj4HuY50s1d+eY1uuV9jDSUxWJV4sizO+tu17Q5WH3iL
GZtB/HBxJUSaCyRRhRw5ENR/mDlIP4k107EXLn078D98sGynuwBnZot6Vl1VgeoCfNQLVNaCeyvo
f4NzlKoe/finf8ybhAJn0K4IA3Xm99+QFtHJDrckPBYiEntDqdcJ+2jqr59IyjQ554+YJbKbU2gT
F1OeLkBxKCK6JWXskFMb2kXH2BuFBcYTJX6PQ36eVmicWrHyxBTpiDhJpiXW7DE8mBc4C6O+WXdk
qx4eFbrqDB9trz5ebzl+jRSbGQIBEaNSMFAwCwYDVR0PBAQDAgEGMA8GA1UdEwQIMAYBAf8CAQAw
EQYJYIZIAYb4QgEBBAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjANBgkqhkiG
9w0BAQUFAAOCAQEA8cov694FJRhdcWhlDCf/Z/SwhltW636Wp0GmVpjBh69JdxvHgMrMO4XmfB5Q
Bu5mXLs3kZmjzT/qKyT87vEoFZKDFGo1VyX+J9RV23A1tiq8LFIyfnQA/KgwlKDVyYp/1I0pEt/g
ZJezJnMQ7wupqbMkmodIIKlqLT9M/v/Fil2NJwxbuT7nsrIQmcX7xyEq/XqEZZY2ZVcdUzVbJQ5q
huNpPhUfq1CYPk/K4F6conhOnrrFAd0PQKK4ZLKhWH2Mt6DHrUlXZ/cm8cHwSvPBrSZB/iljSIva
JxuQBBCAzsFHDEeGzmW3sUQHWtgUi3C9MXTWNUvVW9MUexH2JEYkzzCCA/wwggLkoAMCAQICEQCR
HMRCX7eVQZ+iLXT3DluVMA0GCSqGSIb3DQEBBQUAMIGRMRIwEAYDVQQKEwlJemVjb20gQlYxHjAc
BgkqhkiG9w0BCQEWD2luZm9AaXplY29tLmNvbTEMMAoGA1UECBMDbi9hMRIwEAYDVQQHEwlBbXN0
ZXJkYW0xCzAJBgNVBAYTAk5MMSwwKgYDVQQDEyNJemVjb20gUm9vdCBDZXJ0aWZpY2F0aW9uIEF1
dGhvcml0eTAeFw0wMzAxMjkxNjIxMjhaFw0xNDAyMDIxNjIxMjhaMIGOMRIwEAYDVQQKEwlJemVj
b20gQlYxHzAdBgkqhkiG9w0BCQEWEGluZm9AaXplbWFpbC5jb20xDDAKBgNVBAgTA24vYTESMBAG
A1UEBxMJQW1zdGVyZGFtMQswCQYDVQQGEwJOTDEoMCYGA1UEAxMfSXplbWFpbCBDZXJ0aWZpY2F0
aW9uIEF1dGhvcml0eTCCASAwDQYJKoZIhvcNAQEBBQADggENADCCAQgCggEBAKj+sHuVMe3CzjFC
VBIDUNLpX7WCFKN8MuJZ8aqJMHvA5Y4+B7mOdLNXfnmNbrlfYw0lMViVeLIszvrbte0OVh94ixmb
QfxwcSVEmgskUYUcORDUf5g5SD+JNdOxFy59O/A/fLBsp7sAZ2aLelZdVYHqAnzUC1TWgnsr6H+D
c5SqHv34p3/Mm4QCZ9CuCAN15vffkBbRyQ63JDwWIhJ7Q6nXCfto6q+fSMo0OeePmCWym1NoExdT
ni5AcSgiuiVl7JBTG9pFx9gbhQXGEyV+j0N+nlZonFqx8sQU6Yg4SaYl1uwxPJgXOAujvll3ZKse
HhW66gwfba8+Xm85fo0UmxkCARGjUjBQMAsGA1UdDwQEAwIBBjAPBgNVHRMECDAGAQH/AgEAMBEG
CWCGSAGG+EIBAQQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwDQYJKoZIhvcN
AQEFBQADggEBAPHKL+veBSUYXXFoZQwn/2f0sIZbVut+lqdBplaYwYevSXcbx4DKzDuF5nweUAbu
Zly7N5GZo80/6isk/O7xKBWSgxRqNVcl/ifUVdtwNbYqvCxSMn50APyoMJSg1cmKf9SNKRLf4GSX
syZzEO8LqamzJJqHSCCpai0/TP7/xYpdjScMW7k+57KyEJnF+8chKv16hGWWNmVXHVM1WyUOaobj
aT4VH6tQmD5PyuBenKJ4Tp66xQHdD0CiuGSyoVh9jLegx61JV2f3JvHB8Erzwa0mQf4pY0iL2icb
kAQQgM7BRwxHhs5lt7FEB1rYFItwvTF01jVL1VvTFHsR9iRGJM8wggP8MIIC5KADAgECAhEAkRzE
Ql+3lUGfoi109w5blTANBgkqhkiG9w0BAQUFADCBkTESMBAGA1UEChMJSXplY29tIEJWMR4wHAYJ
KoZIhvcNAQkBFg9pbmZvQGl6ZWNvbS5jb20xDDAKBgNVBAgTA24vYTESMBAGA1UEBxMJQW1zdGVy
ZGFtMQswCQYDVQQGEwJOTDEsMCoGA1UEAxMjSXplY29tIFJvb3QgQ2VydGlmaWNhdGlvbiBBdXRo
b3JpdHkwHhcNMDMwMTI5MTYyMTI4WhcNMTQwMjAyMTYyMTI4WjCBjjESMBAGA1UEChMJSXplY29t
IEJWMR8wHQYJKoZIhvcNAQkBFhBpbmZvQGl6ZW1haWwuY29tMQwwCgYDVQQIEwNuL2ExEjAQBgNV
BAcTCUFtc3RlcmRhbTELMAkGA1UEBhMCTkwxKDAmBgNVBAMTH0l6ZW1haWwgQ2VydGlmaWNhdGlv
biBBdXRob3JpdHkwggEgMA0GCSqGSIb3DQEBAQUAA4IBDQAwggEIAoIBAQCo/rB7lTHtws4xQlQS
A1DS6V+1ghSjfDLiWfGqiTB7wOWOPge5jnSzV355jW65X2MNJTFYlXiyLM7627XtDlYfeIsZm0H8
cHElRJoLJFGFHDkQ1H+YOUg/iTXTsRcufTvwP3ywbKe7AGdmi3pWXVWB6gJ81AtU1oJ7K+h/g3OU
qh79+Kd/zJuEAmfQrggDdeb335AW0ckOtyQ8FiISe0Op1wn7aOqvn0jKNDnnj5glsptTaBMXU54u
QHEoIrolZeyQUxvaRcfYG4UFxhMlfo9Dfp5WaJxasfLEFOmIOEmmJdbsMTyYFzgLo75Zd2SrHh4V
uuoMH22vPl5vOX6NFJsZAgERo1IwUDALBgNVHQ8EBAMCAQYwDwYDVR0TBAgwBgEB/wIBADARBglg
hkgBhvhCAQEEBAMCAQYwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEB
BQUAA4IBAQDxyi/r3gUlGF1xaGUMJ/9n9LCGW1brfpanQaZWmMGHr0l3G8eAysw7heZ8HlAG7mZc
uzeRmaPNP+orJPzu8SgVkoMUajVXJf4n1FXbcDW2KrwsUjJ+dAD8qDCUoNXJin/UjSkS3+Bkl7Mm
cxDvC6mpsySah0ggqWotP0z+/8WKXY0nDFu5PueyshCZxfvHISr9eoRlljZlVx1TNVslDmqG42k+
FR+rUJg+T8rgXpyieE6eusUB3Q9AorhksqFYfYy3oMetSVdn9ybxwfBK88GtJkH+KWNIi9onG5AE
EIDOwUcMR4bOZbexRAda2BSLcL0xdNY1S9Vb0xR7EfYkRiTPMIIEDTCCAvWgAwIBAgIQZukaRJOd
0047Jqoo58OaMjANBgkqhkiG9w0BAQUFADCBkTESMBAGA1UEChMJSXplY29tIEJWMR4wHAYJKoZI
hvcNAQkBFg9pbmZvQGl6ZWNvbS5jb20xDDAKBgNVBAgTA24vYTESMBAGA1UEBxMJQW1zdGVyZGFt
MQswCQYDVQQGEwJOTDEsMCoGA1UEAxMjSXplY29tIFJvb3QgQ2VydGlmaWNhdGlvbiBBdXRob3Jp
dHkwHhcNMDMxMDA5MDkzOTIyWhcNMTQxMDEzMDkzOTIyWjCBgzESMBAGA1UEChMJSXplY29tIEJW
MR8wHQYJKoZIhvcNAQkBFhBpbmZvQGl6ZW1haWwuY29tMRYwFAYDVQQIEw1Ob29yZC1Ib2xsYW5k
MRIwEAYDVQQHEwlBbXN0ZXJkYW0xCzAJBgNVBAYTAk5MMRMwEQYDVQQDEwpJemVtYWlsIENBMIIB
IDANBgkqhkiG9w0BAQEFAAOCAQ0AMIIBCAKCAQEAk5I0X5lf7qjlX7k8iWRzRxh+BHrQRCT+Wc3e
lx2OF1BkIPpYgxrfbik9z2+Ag3N2ya6fh1oQ83XcxnP7OuHaT/ePKFEVzBo30pqfSd+QuGERp99i
AnglxeTDwtatd86vIMB7/XwlZtrbjo0v3FC4vE7zoBHnNL5D+IjxFbcEBaVZvMJT7f8SZShzM23y
rnlXVYcaC4C6H9p2cyafag1KVe1+rSUgpefKt16wxVQFuTJOl1tViFJdiGlACOwUvQ0buhcCmY5u
aH5owOolEjNUjfy3F4iPTj3QDS/lD4Kc+zeBHTNIe4iPyN1G12Lu2GQl+NAY7t5KM0xK3svD+L18
XwIBEaNvMG0wOgYDVR0fBDMwMTAvoC2gK4YpaHR0cDovL3d3dy5pemVjb20uY29tL2l6ZW1haWwv
aXplcm9vdC5jcmwwCwYDVR0PBAQDAgEGMA8GA1UdEwQIMAYBAf8CAQEwEQYJYIZIAYb4QgEBBAQD
AgEGMA0GCSqGSIb3DQEBBQUAA4IBAQCfSVaVl9acK4iqjnOwhPjzZAuy7HhbXraNK7Zl0ZAmCLgD
lWGe+tjPTOJ5jg6miO1u4jKY/T4+WltYt1m4OcqSNT8ZsXWA4vDZZ69Br7jJeOHwr99UZtTLJSwN
tURgeDb0390XiCyiMJgF/yRlPrPBBoXutyZ7OImIypYytrHDq//esWntMZgksYk6XvIw0yLvrbIi
FJzQvpR8F3I03XGu1xEswWd/1NA+D13JYLv4J6WXLKR7KR81qqfkj9Jds31C7R1rl6AZpnVHHtaG
AS8SjHQbgrh/PtLFTCFTFcZvAvTawPpGRvxZlDgZDI+TQf50EJY47zHdUMchVuSnY2UBMIIEpjCC
BA+gAwIBAgIQWYKh8NsnSwS4jw/pFlnjFTANBgkqhkiG9w0BAQQFADCBzDEXMBUGA1UEChMOVmVy
aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3
dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMp
OTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBl
cnNvbmEgTm90IFZhbGlkYXRlZDAeFw0wMzA4MDUwMDAwMDBaFw0wNDAxMDkyMzU5NTlaMIIBGDEX
MBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx
RjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYu
LExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE0MDIGA1UECxMr
RGlnaXRhbCBJRCBDbGFzcyAxIC0gTWljcm9zb2Z0IEZ1bGwgU2VydmljZTEZMBcGA1UEAxQQQ2hy
aXN0aW5lIEthcm1hbjEjMCEGCSqGSIb3DQEJARYUY2hyaXN0aW5lQGl6ZWNvbS5jb20wgZ8wDQYJ
KoZIhvcNAQEBBQADgY0AMIGJAoGBALhEzrZwfeHbV+uUWfLEtXGFGGrgv8wahX2fi83afKZlIty9
ATl8PjrtxSIgP3FC1HNu67Pi8CnTT5LfqhI9fjdug6EUA1hmAAis+LGHMy0s+0WrgdpWrVZ2vJ6/
T88u0q6hOKhXEfZ7dyeh4EMgb0Q6INnRIt4UgWFi/1GZSOd7AgMBAAGjggE4MIIBNDAJBgNVHRME
AjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczov
L3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIB
ARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBW
ZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMAYKYIZIAYb4RQEGBwQiFiA0MWJkN2IwYzE1OTdm
YTVmYjllZDk1NTQ0MzJiYmExNDAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWdu
LmNvbS9jbGFzczEuY3JsMA0GCSqGSIb3DQEBBAUAA4GBADLc57OahZ+LXdAZrFH6LstiF0VnaAj4
QfdFKBOAlWhFAjSjlgLH05waMclFF17725O4M71Q0cEowxbvIYj5rCQubLNzwGIjfXlHE5XSTZfr
+1melpIpNObGYpu/26fenzdgafjbS1FbOqU7xk7MH4H7pBS0aKXeYofjWiiWwRbwMIIEpjCCBA+g
AwIBAgIQWYKh8NsnSwS4jw/pFlnjFTANBgkqhkiG9w0BAQQFADCBzDEXMBUGA1UEChMOVmVyaVNp
Z24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52
ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgx
SDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNv
bmEgTm90IFZhbGlkYXRlZDAeFw0wMzA4MDUwMDAwMDBaFw0wNDAxMDkyMzU5NTlaMIIBGDEXMBUG
A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBE
BgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJ
QUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE0MDIGA1UECxMrRGln
aXRhbCBJRCBDbGFzcyAxIC0gTWljcm9zb2Z0IEZ1bGwgU2VydmljZTEZMBcGA1UEAxQQQ2hyaXN0
aW5lIEthcm1hbjEjMCEGCSqGSIb3DQEJARYUY2hyaXN0aW5lQGl6ZWNvbS5jb20wgZ8wDQYJKoZI
hvcNAQEBBQADgY0AMIGJAoGBALhEzrZwfeHbV+uUWfLEtXGFGGrgv8wahX2fi83afKZlIty9ATl8
PjrtxSIgP3FC1HNu67Pi8CnTT5LfqhI9fjdug6EUA1hmAAis+LGHMy0s+0WrgdpWrVZ2vJ6/T88u
0q6hOKhXEfZ7dyeh4EMgb0Q6INnRIt4UgWFi/1GZSOd7AgMBAAGjggE4MIIBNDAJBgNVHRMEAjAA
MIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3
dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9
VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJp
U2lnbjARBglghkgBhvhCAQEEBAMCB4AwMAYKYIZIAYb4RQEGBwQiFiA0MWJkN2IwYzE1OTdmYTVm
YjllZDk1NTQ0MzJiYmExNDAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNv
bS9jbGFzczEuY3JsMA0GCSqGSIb3DQEBBAUAA4GBADLc57OahZ+LXdAZrFH6LstiF0VnaAj4QfdF
KBOAlWhFAjSjlgLH05waMclFF17725O4M71Q0cEowxbvIYj5rCQubLNzwGIjfXlHE5XSTZfr+1me
lpIpNObGYpu/26fenzdgafjbS1FbOqU7xk7MH4H7pBS0aKXeYofjWiiWwRbwMYICFjCCAhICAQEw
geEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO
ZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2
aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFmCofDbJ0sEuI8P6RZZ4xUw
CQYFKw4DAhoFAKCBizAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0w
MzExMjgxMzE2NTdaMCMGCSqGSIb3DQEJBDEWBBRkfVwpfDRMP9M6xH9cstZ3xhSsEjAsBgkqhkiG
9w0BCQ8xHzAdMA8GCCqGSIb3DQMCMAMCATowCgYIKoZIhvcNAwcwDQYJKoZIhvcNAQEBBQAEgYBq
Tq8Fdb8oWVY00V9vWJ8qzAMxgS7mK+zUJLyfXClEHeIkWHfdm24TPxfv2uoPo5nJjy5iozg3mpv2
cEU+12rM6UpEKeHeV2vAKF2bSHJTykseWm0E2+Aut3CvDdB2FZR2V7mUoSOsPkbT3ErZtHTmzCjZ
c4S4VO2x0pkBwhV1ZA==

--{42F53F2B-4D8D-44E0-8C4D-FB0FF7232BEB}--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASGHWib006633 for <[e-mail]>; Fri, 28 Nov 2003 08:17:32 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hASGHWnk006632 for ietf-pkix-bks; Fri, 28 Nov 2003 08:17:32 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.smarttrust.com ([213.212.5.232]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASGHTib006618 for <[e-mail]>; Fri, 28 Nov 2003 08:17:30 -0800 (PST) (envelope-from [e-mail])
Received: from sek43.smarttrust.com ([172.16.0.43]) by mail.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 17:18:10 +0100
Received: from mail pickup service by sek43.smarttrust.com with Microsoft SMTPSVC; Fri, 28 Nov 2003 17:17:09 +0100
Received: from mail.smarttrust.com ([192.168.1.10]) by sek43.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 14:13:44 +0100
Received: from sek13 ([192.168.1.15]) by mail.smarttrust.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 14:14:29 +0100
Received: from [208.184.76.39]:3186 (EHLO above.proper.com) by sek13.smarttrust.com ([192.168.1.15]:25) (F-Secure Anti-Virus for Internet Mail 6.0.34 Release) with SMTP; Fri, 28 Nov 2003 13:13:00 -0000
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASBHQib093665 for <[e-mail]>; Fri, 28 Nov 2003 03:17:26 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hASBHQFK093664 for ietf-pkix-bks; Fri, 28 Nov 2003 03:17:26 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kiki.ssb.it ([192.106.128.1]) by above.proper.com (8.12.10/8.12.8) with SMTP id hASBHNib093650 for <[e-mail]>; Fri, 28 Nov 2003 03:17:24 -0800 (PST) (envelope-from [e-mail])
Received: from mail.tsp.it ([192.168.100.243]) by kiki; Fri, 28 Nov 2003 12:17:33 +0100 (CET)
Received: from mail.tsp.it (unknown [192.168.100.244]) by dns.tsp.it (Postfix) with ESMTP id BAF402D567 for <[e-mail]>; Fri, 28 Nov 2003 13:14:03 +0100 (CET)
Subject: 
To: [e-mail]
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <[e-mail]>
From: "Marco Nicoli" <[e-mail]>
Date: Fri, 28 Nov 2003 12:17:17 +0100
X-MIMETrack: Serialize by Router on Notes/TSP(Release 5.07a |May 14, 2001) at 28/11/2003  12.17.18
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-OriginalArrivalTime: 28 Nov 2003 13:14:29.0562 (UTC) FILETIME=[8E2C69A0:01C3B5B1]
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>

remove




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASFfVib005408 for <[e-mail]>; Fri, 28 Nov 2003 07:41:31 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hASFfVml005407 for ietf-pkix-bks; Fri, 28 Nov 2003 07:41:31 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from seguridata1.seguridata.com ([200.57.34.107]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASFfUib005400 for <[e-mail]>; Fri, 28 Nov 2003 07:41:30 -0800 (PST) (envelope-from [e-mail])
Received: from MarsXP ([200.67.231.235]) by seguridata1.seguridata.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Nov 2003 09:42:22 -0600
From: "Miguel Rodriguez" <[e-mail]>
To: <[e-mail]>
Subject: RE: DISCUSS:  MUST  reject in OCSPv1
Date: Fri, 28 Nov 2003 09:43:59 -0600
Message-ID: <001b01c3b5c6$74ca4170$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
X-OriginalArrivalTime: 28 Nov 2003 15:42:24.0265 (UTC) FILETIME=[37E89F90:01C3B5C6]
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 it is a good solution.

> -----Original Message-----
> From: [e-mail]
[mailto:[e-mail]]
> On Behalf Of Michael Myers
> Sent: Thursday, November 27, 2003 2:32 PM
> To: [e-mail]
> Subject: RE: DISCUSS: MUST reject in OCSPv1
> 
> 
> 
> If anyone objects to the path forward as discussed below, please
> speak up now.  Concurrence is equally welcome.
> 
> Mike
> 
> 
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]]On Behalf Of
> > David Engberg
> > Sent: Thursday, November 27, 2003 12:46 PM
> > To: Michael Myers
> > Cc: [e-mail]
> > Subject: Re: DISCUSS: MUST reject in OCSPv1
> >
> >
> >
> >
> > Exactly.  I'd implement this right now if I wasn't so
> > full of turkey.
> >
> >
> > Michael Myers wrote:
> > >
> > > Understand your caching servers MUST send back a caveated
> > > response which by presence of the caveat may or may not be
> > > accepted.  No fair sending back plain ones, errors
> > > notwithstanding.  Is this understood?
> > >
> > > Mike
> > >
> > >
> > >>-----Original Message-----
> > >>From: David Engberg [mailto:[e-mail]]
> > >>Sent: Thursday, November 27, 2003 12:25 PM
> > >>To: Michael Myers
> > >>Cc: [e-mail]
> > >>Subject: Re: DISCUSS: MUST reject in OCSPv1
> > >>
> > >>
> > >>
> > >>I'd add "or return an error [e.g. unauthorized?]" to
> > >>the end of '4' (to
> > >>remain compliant in the presence of requests for
> > >>unknown certs), but it
> > >>is otherwise my dream scenario.
> > >>
> > >>
> > >>Michael Myers wrote:
> > >>
> > >>>Dave,
> > >>>
> > >>>So how about:
> > >>>
> > >>>1. If we can cycle v1 at Proposed (a big if); then
> > >>>
> > >>>2. Define nonceUnsupported extension subject to
> > >>>   the following semantics (I'm squeezing the
> > >>>   words a bit but you'll get the drift)
> > >>>
> > >>>3. Clients that send a nonce:
> > >>>
> > >>>   a. MUST reject a non-nonced response
> > >>>      if that response includes either the
> > >>>      value "good" or "revoked" AND it fails
> > >>>      to include the nonceUnsupported extension;
> > >>>
> > >>>   b. Else, if such response includes the
> > >>>      nonceUnsupported extension, clients
> > >>>      MAY accept the response subject to the
> > >>>      advice in the Security Considerations
> > >>>      section of this document.
> > >>>
> > >>>4. Conversely, if a server receives a nonced
> > >>>   request but is unable to incorporate the
> > >>>   nonce in its response, the server MUST
> > >>>   include the nonceUnsupported extension.
> > >>>
> > >>> Note that I made no distinction between "good",
> > >>> "revoked" or "unknown" in #3.b or #4.  Thus,
> > >>> a plain nonceless response of "good" or
> > >>> "revoked" is non-conformant, while a caveated
> > >>> response is subject to the client's local
> > >>> security policy.
> > >>>
> > >>> Does this seem a fair compromise?  Note well it's highly
> > >>> dependent on cycling v1 at Proposed.
> > >>>
> > >>> Mike
> > >
> > >
> > >
> >




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASF3jib004266 for <[e-mail]>; Fri, 28 Nov 2003 07:03:45 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hASF3j4o004265 for ietf-pkix-bks; Fri, 28 Nov 2003 07:03:45 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASF3hib004259 for <[e-mail]>; Fri, 28 Nov 2003 07:03:43 -0800 (PST) (envelope-from [e-mail])
Received: from MMyersLapTop ([65.39.77.99]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id hASF3iA93173 for <[e-mail]>; Fri, 28 Nov 2003 08:03:44 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: <[e-mail]>
Subject: RE: DISCUSS:  MUST  reject in OCSPv1
Date: Fri, 28 Nov 2003 08:05:56 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <[e-mail]>
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>

These are constructive discussions but somewhat off topic for
this thread.  We need to determine if we as a WG can agree on a
least-impact near term path forward for disambiguating the
relationship between nonces and pre-produced responses.

After much work, we finally have a potential resolution on the
table.

David and Florian agree with it.
Ryan does not.
Marc, your response was ambiguous.

Anyone else care to voice an opinion on the proposal?

Mike





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASDXNib000685 for <[e-mail]>; Fri, 28 Nov 2003 05:33:23 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hASDXNdY000684 for ietf-pkix-bks; Fri, 28 Nov 2003 05:33:23 -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.240.3]) by above.proper.com (8.12.10/8.12.8) with SMTP id hASDXLib000679 for <[e-mail]>; Fri, 28 Nov 2003 05:33:22 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 5153 invoked by uid 0); 28 Nov 2003 13:33:01 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.33.92) by woodstock.binhost.com with SMTP; 28 Nov 2003 13:33:01 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Fri, 28 Nov 2003 08:33:20 -0500
To: Denis Pinkas <[e-mail]>, Alice Sturgeon <[e-mail]>, [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-warranty-extn-04.txt
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>

Denis:

Steve Bellovin is the shepherd for this document.  He will have more 
up-to-date information than me.

Russ

At 12:54 PM 11/28/2003 +0100, Denis Pinkas wrote:
>Please, Russ, would you also clarify where we are now, with respect to the 
>comments that I sent during the last call.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASDHDib000163 for <[e-mail]>; Fri, 28 Nov 2003 05:17:13 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hASDHDKk000161 for ietf-pkix-bks; Fri, 28 Nov 2003 05:17:13 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from zloty.izecom.com (cust.10.30.adsl.cistron.nl [62.216.10.30]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASDHAib000154 for <[e-mail]>; Fri, 28 Nov 2003 05:17:11 -0800 (PST) (envelope-from [e-mail])
Received: from pengo ([192.168.0.235]) by zloty.izecom.com (8.12.8p1/8.12.8) with SMTP id hASDGuGh015655; Fri, 28 Nov 2003 14:16:56 +0100
Message-Id: <4.3.2.7.2.20031128140532.02a3dea0@localhost>
X-Sender: chk@192.168.0.200@localhost
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 28 Nov 2003 14:16:42 +0100
To: "Peter Gutmann"<[e-mail] (Peter Gutmann)>
From: Christine Karman <[e-mail]>
Subject: Re: Straw poll: An advice to a commercial CA
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="{42F53F2B-4D8D-44E0-8C4D-FB0FF7232BEB}"
X-Izemail-Send-Version: 1.3.0.445 (POP3)
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.

--{42F53F2B-4D8D-44E0-8C4D-FB0FF7232BEB}
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 12:27 11-27-03, Peter Gutmann wrote:

>To answer an earlier question about support for policy restrictions, cryptlib
>supports these (policy constraints with all its weird variations).  If
>cryptlib finds constraints in a CA cert it'll apply them down the chain, but
>there's no way for a user to configure the behaviour.  The reason for this is
>that no-one has ever asked for this [0], so I can't even begin to imagine what
>sort of interface it'd require to manage things.  Do users type in a list of
>OIDs from a piece of paper?  Do they click on a CA cert and say "Use the
>policies advertised by this CA"?

Typical users hardly know what a CA is. They don't know what kind of 
policies you are talking about. So a GUI would assume a most probable 
strategy, and then prompt the user with "I recommend you adopt policy xyz 
for this certificate. Press 'OK', or press 'advanced' to change". On a 
company level, a system administrator would force a certain behavior of the 
GUI, which cannot be changed by individual users.
Having said this, the GUI would probably make the choice by itself, because 
user interaction suggests that the user makes a decision on the subject, 
while in reality the user just presses a button that may as well read 
"Whatever".
I agree, this is not what the world should be like. But it is.

dagdag
Christine
--
Izecom BV
Secure e-mail and digital signatures
www.izecom.com

--{42F53F2B-4D8D-44E0-8C4D-FB0FF7232BEB}
Content-Type: application/x-pkcs7-signature; 
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIJO2wYJKoZIhvcNAQcCoIJOzDCCTsgCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCCTI0w
ggI9MIIBpgIRAM26f1bw3+S8VP4irLNyqlUwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UEBhMCVVMx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5
IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk2MDEyOTAwMDAwMFoXDTI4MDgwMTIzNTk1OVow
XzELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAx
IFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUA
A4GNADCBiQKBgQDlGb9to1ZhLZlIcfZn3rmN67eehoAKkQ76OCWvRoiC5XOooJskXQ0fzGVuDLDQ
VoQYh5oGmxChc9+0WDlrbsH2FdWoqD+qEgaNMax/sDTXjzRniAnNFBHiTkVWaR94AoDa3EeRKbs2
yWNcxeDXLYd7obcysHswuiovMaruo2fa2wIDAQABMA0GCSqGSIb3DQEBAgUAA4GBAEw/uIvGaN/u
QzMOXemmyweETXoz/5Ib9Dat2JUiNmgRbHxCzPOcLsQHPxSwD0//kJJ2+eK8SumPzaCACvfFKfGC
Il24sd2BI6N7JRVGMHkW+OoFS5R/HcIcyOO39BBAPBPDXx9T6EjkhrR7oTWweyW6uNOOqz84nQA0
AJjz0XGUMIICPTCCAaYCEQDNun9W8N/kvFT+IqyzcqpVMA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNV
BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMg
UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05NjAxMjkwMDAwMDBaFw0yODA4MDEy
MzU5NTlaMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMu
Q2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG
9w0BAQEFAAOBjQAwgYkCgYEA5Rm/baNWYS2ZSHH2Z965jeu3noaACpEO+jglr0aIguVzqKCbJF0N
H8xlbgyw0FaEGIeaBpsQoXPftFg5a27B9hXVqKg/qhIGjTGsf7A01480Z4gJzRQR4k5FVmkfeAKA
2txHkSm7NsljXMXg1y2He6G3MrB7MLoqLzGq7qNn2tsCAwEAATANBgkqhkiG9w0BAQIFAAOBgQBM
P7iLxmjf7kMzDl3ppssHhE16M/+SG/Q2rdiVIjZoEWx8QszznC7EBz8UsA9P/5CSdvnivErpj82g
gAr3xSnxgiJduLHdgSOjeyUVRjB5FvjqBUuUfx3CHMjjt/QQQDwTw18fU+hI5Ia0e6E1sHslurjT
jqs/OJ0ANACY89FxlDCCAzswggIjoAMCAQICEH51qFsO2Pq5fgSIHQ5ZZzMwDQYJKoZIhvcNAQEF
BQAwgY4xEjAQBgNVBAoTCUl6ZWNvbSBCVjEfMB0GCSqGSIb3DQEJARYQaW5mb0BpemVtYWlsLmNv
bTEMMAoGA1UECBMDbi9hMRIwEAYDVQQHEwlBbXN0ZXJkYW0xCzAJBgNVBAYTAk5MMSgwJgYDVQQD
Ex9JemVtYWlsIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTAzMDMwNjIxMTMwOVoXDTA0MDMx
MjIxMTMwOVowdDELMAkGA1UEBhMCTkwxEjAQBgNVBAcTCUFtc3RlcmRhbTESMBAGA1UEChMJWmFw
aG9kIEJWMSIwIAYJKoZIhvcNAQkBFhNjaHJpc3RpbmVAa2FybWFuLm5sMRkwFwYDVQQDExBDaHJp
c3RpbmUgS2FybWFuMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC0qliGIqcmrgFgH3WukcAS
WU6NIo+a2Tb07f022Ew7CK7lENXx2uav6S6JMcz+67t1tJqfy6JdAxVcAIY65seKx1AApFnTMsE1
W8Nmqrv6A1mOC6R3148OSlcJhYqzyU+vSVRJdaYtwZIYXy+S6DUk94eY48ItH1GpbK5ixk9njQID
AQABozIwMDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwDwYDVR0TBAgwBgEBAAIBADAN
BgkqhkiG9w0BAQUFAAOCAQEAJgqIr+yuq8YWe0asKjNZG3J0ue4X7+NwhZkaElWyJ+Zraidpp/wq
YlcR6aUCzh4GYohltLaotQ+Bg366dS6XyTnukgxSaAsbXz2Yjv+aW3y9jKkJFW6kPcdoKcP8RZer
YwvQ1cW+4nRre8XvJasPuFD1DtEMHHIYedcbrYI7+cpt4WXTOSHj7Jcn7TSCbgrcNdTx8ij6bBCB
snVHEZSl7beWR+cGZGLIZk0/XFuDe0lZBqTgraIFC1p3TPLZ0HQLPpXAiE9xpOmrobLO5X+6SNtV
NmdMX3Ni4UyspgoZnhzNniDYb9SsdhYJ3iKsLjqgluStQFXT1oSr3lVl1M4ccDCCA0QwggIsoAMC
AQICEAeuoFSX1AX4LCO3xTKgFukwDQYJKoZIhvcNAQEFBQAwgY4xEjAQBgNVBAoTCUl6ZWNvbSBC
VjEfMB0GCSqGSIb3DQEJARYQaW5mb0BpemVtYWlsLmNvbTEMMAoGA1UECBMDbi9hMRIwEAYDVQQH
EwlBbXN0ZXJkYW0xCzAJBgNVBAYTAk5MMSgwJgYDVQQDEx9JemVtYWlsIENlcnRpZmljYXRpb24g
QXV0aG9yaXR5MB4XDTAzMDEzMDIwMzQzN1oXDTA0MDIwNjIwMzQzN1owfTEUMBIGA1UEBhMLTmV0
aGVybGFuZHMxEjAQBgNVBAcTCUFtc3RlcmRhbTEPMA0GA1UEChMGWmFwaG9kMSUwIwYJKoZIhvcN
AQkBFhZjaHJpc3RpbmVAY2hyaXN0aW5lLm5sMRkwFwYDVQQDExBDaHJpc3RpbmUgS2FybWFuMIGf
MA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCulat3hEupfMrJpuw1/eOnpI7u4LZLXDBJxRlRcu3z
6XhKZRmFbWCWdHRK3e1IoSqzpCIM/DZmvtfWjYQSrDKIMhwAjVfc04s53G9EZ01NfYpYL9X4SXWX
Y4dwUFCxc+54fejUXPDnamrxmw8m68tqdQbA3E1dKWWiqUbgKWjbpwIDAQABozIwMDAdBgNVHSUE
FjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwDwYDVR0TBAgwBgEBAAIBADANBgkqhkiG9w0BAQUFAAOC
AQEAbViEzzTQzuapibeZVx8JQvCzMc/8cYKwUwrzK2COxd0GX8puYOFMMLFNBysdQh2ZV5dzAaWi
bubjf6Ip28dMCPUvSRnyON4GD9nYesROYs0hWdDJjSnsEplyQ8UFtn+bTzlvsuyjj5oMQwas0fkR
6TB1Rql3FuhtbwFaqv5P4uoD9aaLP/KJbVFty9d9fho9/gDBmYEfIZTjnTczjQeH8gdCthb9bdg3
kr+DvlIFsyomOYN/PUTA49qjx8k1hkIwT7eUDPkGOa6d+MxEduTUTCRSnU+pqC9U9gMw/p/lrvPd
2wM87T93SRBJC7J3XRxEa1DsBBK5So9E8PYQJNh8azCCA2IwggLLoAMCAQICEAvaCxfBP4mOqwl0
erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ
bmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9y
aXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWdu
LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVy
aXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgw
RgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25h
IE5vdCBWYWxpZGF0ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2U
TxV4NrgNSrJvnFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7
u77JJwpdtrA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZ
AgMBAAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w
KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCowKDAm
oCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEGMBEGCWCG
SAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzkTCuPHv6SQKzY
CjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+sMVTUixnI2COo7wQr
Mn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+i+P7FTCCA2IwggLLoAMC
AQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UEBhMCVVMxFzAVBgNV
BAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp
ZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4MDUxMjIzNTk1OVowgcwxFzAV
BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYw
RAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixM
SUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vi
c2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGB
ALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJvnFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8Ci
kqtEXKpC8IIOAukv+8I7u77JJwpdtrA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6
p7F+78nbN2rISsgJBuSZAgMBAAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwG
C2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S
UEEwMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYD
VR0PBAQDAgEGMBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje
6VNkIbzkTCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh
3s+sMVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+
i+P7FTCCA40wggJ1oAMCAQICEQCdN6WFU8voqm9Iw16mj2uEMA0GCSqGSIb3DQEBBQUAMIGDMRIw
EAYDVQQKEwlJemVjb20gQlYxHzAdBgkqhkiG9w0BCQEWEGluZm9AaXplbWFpbC5jb20xFjAUBgNV
BAgTDU5vb3JkLUhvbGxhbmQxEjAQBgNVBAcTCUFtc3RlcmRhbTELMAkGA1UEBhMCTkwxEzARBgNV
BAMTCkl6ZW1haWwgQ0EwHhcNMDMxMTA1MTQ1MzM4WhcNMDQwMjA1MjMwMDAwWjBtMQswCQYDVQQG
EwJOTDESMBAGA1UEBxMJQW1zdGVyZGFtMQkwBwYDVQQKEwAxJTAjBgkqhkiG9w0BCQEWFmNocmlz
dGluZUBjaHJpc3RpbmUubmwxGDAWBgNVBAMTD0NocmlzdGluZSBwcml2ZTCBnzANBgkqhkiG9w0B
AQEFAAOBjQAwgYkCgYEA15upgKOSjpN/FhOGOhb7CkYFtOt2stjanOoEqWRTHfzY4B2N814fcT1n
m7p/sECpQf3LDX66NOgf4uVxjy98Uy529pSeYOUAPAZg1uxqSbxPPx4YZ/S6X5oAnvOq+nVzOxAN
uq8IaCHyK6umVKpdlBzbniBVODtlNVkxiYo8iz8CAwEAAaOBlDCBkTAPBgNVHRMECDAGAQEAAgEA
MDwGA1UdHwQ1MDMwMaAvoC2GK2h0dHA6Ly93d3cuaXplY29tLmNvbS9pemVtYWlsL2l6ZW1haWwu
MS5jcmwwIQYDVR0RBBowGIEWY2hyaXN0aW5lQGNocmlzdGluZS5ubDAdBgNVHSUEFjAUBggrBgEF
BQcDBAYIKwYBBQUHAwIwDQYJKoZIhvcNAQEFBQADggEBADnoQbAh9WFjy97IuNoi4a1w557FusxU
aYlGzb1mvCZbs00vb1Yexv6IAYtFKgpSMrKF8x5i4G5yL/3ZzU5UPMHawEHL3mIOJNnKpOzk/6lY
PSCWTo1nHNaFM7Sz/++KPDJ0Y4Ji2DJcLzx8VWJeEulhf/xdRQcG/Muf1B+Jz6U+8QmA42Ail1od
KcQQfL9QkoHL/YZekyFFS+K+Me0Q4ilO94jGo/1ryo7PL66gMxz+snwBYSrL3J9WOe2WiG18ZKLI
xIKc0La4Wf4lz5/tlA3DqW6yqHpumq4lD+F0y8kLw3HsemBPdqJ5usM5CSgUNf9ods4EB1UEwB5r
pjLtKNYwggOZMIICgaADAgECAhEAp5HQLk86PUNLsj8f7VFTjDANBgkqhkiG9w0BAQUFADCBjjES
MBAGA1UEChMJSXplY29tIEJWMR8wHQYJKoZIhvcNAQkBFhBpbmZvQGl6ZW1haWwuY29tMQwwCgYD
VQQIEwNuL2ExEjAQBgNVBAcTCUFtc3RlcmRhbTELMAkGA1UEBhMCTkwxKDAmBgNVBAMTH0l6ZW1h
aWwgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMDMwOTI5MDk1NjEzWhcNMDQxMDA1MDk1NjEz
WjByMQswCQYDVQQGEwJOTDESMBAGA1UEBxMJYW1zdGVyZGFtMQ8wDQYDVQQKEwZpemVjb20xIzAh
BgkqhkiG9w0BCQEWFGNocmlzdGluZUBpemVjb20uY29tMRkwFwYDVQQDExBjaHJpc3RpbmUga2Fy
bWFuMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8x5Pje5kP7gi6jdYcCl4Z0MeQx2zwRQmi
mfC3oIZvxG84Dnv8mPsM9pIQnuxjNJobv+GzQSQAk/baCUx28X8dZY5cjB8JGWAlC65XXzGWGJ2u
+cc8LuJ35kXaWUpg6k8yBiCYPRM8CRmsL9r9t7Yut0YSjgs5nUu/wDmgESkJswIDAQABo4GQMIGN
MB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAPBgNVHRMECDAGAQEAAgEAMDoGA1UdHwQz
MDEwL6AtoCuGKWh0dHA6Ly93d3cuaXplY29tLmNvbS9pemVtYWlsL2l6ZW1haWwuY3JsMB8GA1Ud
EQQYMBaBFGNocmlzdGluZUBpemVjb20uY29tMA0GCSqGSIb3DQEBBQUAA4IBAQA8LC2fl9YWSS6U
/VByvgKyHf905fQxJ15r3K1xlLK3eoe49e2iFOMsMiCzTp1R8VSLGDzhyYJNTPonRVD5fmIuxNYt
KqycuAAycaSiLvg/U2kXXgdzuVHBQW9l4CWtl9H3kM4hm630WNJRKTNJv6X3et/xUy/At/xXDT3h
5tjFJgcud+3NqsRjNoq6uYRvETzxrCKLj/PLQ7lI2Mvnm6GywXXQM1GJcDjzRcb7GScjiXfsBtau
ZKEJDa0boKfUtGT6CYAxlIgciQtSkG+4IIf+OUfeGuZA8nhA/GfIkyygUPixB/CkAYYOFvGHFmVE
4u2ItGXR8do6l2cXpxYvtVY8MIIDqzCCApOgAwIBAgIRAPfl7mMkXQ6kKqRIT7cqvBcwDQYJKoZI
hvcNAQEFBQAwgZExEjAQBgNVBAoTCUl6ZWNvbSBCVjEeMBwGCSqGSIb3DQEJARYPaW5mb0BpemVj
b20uY29tMQwwCgYDVQQIEwNuL2ExEjAQBgNVBAcTCUFtc3RlcmRhbTELMAkGA1UEBhMCTkwxLDAq
BgNVBAMTI0l6ZWNvbSBSb290IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTAzMDEyOTE2MjA0
NloXDTE2MDIwMjE2MjA0NlowgZExEjAQBgNVBAoTCUl6ZWNvbSBCVjEeMBwGCSqGSIb3DQEJARYP
aW5mb0BpemVjb20uY29tMQwwCgYDVQQIEwNuL2ExEjAQBgNVBAcTCUFtc3RlcmRhbTELMAkGA1UE
BhMCTkwxLDAqBgNVBAMTI0l6ZWNvbSBSb290IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MIIBIDAN
BgkqhkiG9w0BAQEFAAOCAQ0AMIIBCAKCAQEA9XehWqD0AK8jSepGl5mMpn3LWW930PXr5RtckP/R
tVAu08TIOAkILvlx5Sjm2nOqbdYUHavIRgMLoyI0gaH8vKINixLDgb/vgtTVQkd09k+VGIOJ/jq4
0PvWQ4BVRImd/0mbMYgAePhFSQrgRfALhd0e+pNweBEO5Gg+OYkElGU6f5B+cH3LHiMhfJ7JEJKG
jMHsFGGDAp/jeQTcK9icqCg+NqR/FT/xw6eh35ucxL5A74hFvog06u8m5MAOB2Y7RT2NPHAoYy3W
CdYeSZmWYnQa0GRn0WBCvefQdtL6mCkMfwcP0EBBV2dnz+nz93XE7ln06j8gaw1bBMDEibHo+wIB
ETANBgkqhkiG9w0BAQUFAAOCAQEAi7ej2XrLJv896UmfB1QSsCz87MbBgH8IJDMKODQG9fd1mEBk
YLrtSUamMgYLp1yY/jLLwoMa9Am6+wL1UjeBiiv0CXHy+K69uM1DnarenYqDIJOoLJ+7bNifG28y
uPiaelCT3KPSB4Z06K6iOY2ZTU2eNw+HIQC06mR9x0oSa97yWf51CsiKbj+yE2GUd8dUuEVMqiCH
B5KLAJGh/MsoapVJygOcRXh1JHhRPOicqzNXOZaML2RE1glkJJsugLul9ZG5OtJaabQ3T59eUVB5
0mM8FXl5KZmRD4Uu3LNd+JwUVweURQxpkA23DB+hPcTLyQyPxVAr8idWdRfPp3IlBzCCA6swggKT
oAMCAQICEQD35e5jJF0OpCqkSE+3KrwXMA0GCSqGSIb3DQEBBQUAMIGRMRIwEAYDVQQKEwlJemVj
b20gQlYxHjAcBgkqhkiG9w0BCQEWD2luZm9AaXplY29tLmNvbTEMMAoGA1UECBMDbi9hMRIwEAYD
VQQHEwlBbXN0ZXJkYW0xCzAJBgNVBAYTAk5MMSwwKgYDVQQDEyNJemVjb20gUm9vdCBDZXJ0aWZp
Y2F0aW9uIEF1dGhvcml0eTAeFw0wMzAxMjkxNjIwNDZaFw0xNjAyMDIxNjIwNDZaMIGRMRIwEAYD
VQQKEwlJemVjb20gQlYxHjAcBgkqhkiG9w0BCQEWD2luZm9AaXplY29tLmNvbTEMMAoGA1UECBMD
bi9hMRIwEAYDVQQHEwlBbXN0ZXJkYW0xCzAJBgNVBAYTAk5MMSwwKgYDVQQDEyNJemVjb20gUm9v
dCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCCASAwDQYJKoZIhvcNAQEBBQADggENADCCAQgCggEB
APV3oVqg9ACvI0nqRpeZjKZ9y1lvd9D16+UbXJD/0bVQLtPEyDgJCC75ceUo5tpzqm3WFB2ryEYD
C6MiNIGh/LyiDYsSw4G/74LU1UJHdPZPlRiDif46uND71kOAVUSJnf9JmzGIAHj4RUkK4EXwC4Xd
HvqTcHgRDuRoPjmJBJRlOn+QfnB9yx4jIXyeyRCShozB7BRhgwKf43kE3CvYnKgoPjakfxU/8cOn
od+bnMS+QO+IRb6INOrvJuTADgdmO0U9jTxwKGMt1gnWHkmZlmJ0GtBkZ9FgQr3n0HbS+pgpDH8H
D9BAQVdnZ8/p8/d1xO5Z9Oo/IGsNWwTAxImx6PsCAREwDQYJKoZIhvcNAQEFBQADggEBAIu3o9l6
yyb/PelJnwdUErAs/OzGwYB/CCQzCjg0BvX3dZhAZGC67UlGpjIGC6dcmP4yy8KDGvQJuvsC9VI3
gYor9Alx8viuvbjNQ52q3p2KgyCTqCyfu2zYnxtvMrj4mnpQk9yj0geGdOiuojmNmU1NnjcPhyEA
tOpkfcdKEmve8ln+dQrIim4/shNhlHfHVLhFTKoghweSiwCRofzLKGqVScoDnEV4dSR4UTzonKsz
VzmWjC9kRNYJZCSbLoC7pfWRuTrSWmm0N0+fXlFQedJjPBV5eSmZkQ+FLtyzXficFFcHlEUMaZAN
twwfoT3Ey8kMj8VQK/InVnUXz6dyJQcwggOrMIICk6ADAgECAhEA9+XuYyRdDqQqpEhPtyq8FzAN
BgkqhkiG9w0BAQUFADCBkTESMBAGA1UEChMJSXplY29tIEJWMR4wHAYJKoZIhvcNAQkBFg9pbmZv
QGl6ZWNvbS5jb20xDDAKBgNVBAgTA24vYTESMBAGA1UEBxMJQW1zdGVyZGFtMQswCQYDVQQGEwJO
TDEsMCoGA1UEAxMjSXplY29tIFJvb3QgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMDMwMTI5
MTYyMDQ2WhcNMTYwMjAyMTYyMDQ2WjCBkTESMBAGA1UEChMJSXplY29tIEJWMR4wHAYJKoZIhvcN
AQkBFg9pbmZvQGl6ZWNvbS5jb20xDDAKBgNVBAgTA24vYTESMBAGA1UEBxMJQW1zdGVyZGFtMQsw
CQYDVQQGEwJOTDEsMCoGA1UEAxMjSXplY29tIFJvb3QgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkw
ggEgMA0GCSqGSIb3DQEBAQUAA4IBDQAwggEIAoIBAQD1d6FaoPQAryNJ6kaXmYymfctZb3fQ9evl
G1yQ/9G1UC7TxMg4CQgu+XHlKObac6pt1hQdq8hGAwujIjSBofy8og2LEsOBv++C1NVCR3T2T5UY
g4n+OrjQ+9ZDgFVEiZ3/SZsxiAB4+EVJCuBF8AuF3R76k3B4EQ7kaD45iQSUZTp/kH5wfcseIyF8
nskQkoaMwewUYYMCn+N5BNwr2JyoKD42pH8VP/HDp6Hfm5zEvkDviEW+iDTq7ybkwA4HZjtFPY08
cChjLdYJ1h5JmZZidBrQZGfRYEK959B20vqYKQx/Bw/QQEFXZ2fP6fP3dcTuWfTqPyBrDVsEwMSJ
sej7AgERMA0GCSqGSIb3DQEBBQUAA4IBAQCLt6PZessm/z3pSZ8HVBKwLPzsxsGAfwgkMwo4NAb1
93WYQGRguu1JRqYyBgunXJj+MsvCgxr0Cbr7AvVSN4GKK/QJcfL4rr24zUOdqt6dioMgk6gsn7ts
2J8bbzK4+Jp6UJPco9IHhnTorqI5jZlNTZ43D4chALTqZH3HShJr3vJZ/nUKyIpuP7ITYZR3x1S4
RUyqIIcHkosAkaH8yyhqlUnKA5xFeHUkeFE86JyrM1c5lowvZETWCWQkmy6Au6X1kbk60lpptDdP
n15RUHnSYzwVeXkpmZEPhS7cs134nBRXB5RFDGmQDbcMH6E9xMvJDI/FUCvyJ1Z1F8+nciUHMIID
qzCCApOgAwIBAgIRAPfl7mMkXQ6kKqRIT7cqvBcwDQYJKoZIhvcNAQEFBQAwgZExEjAQBgNVBAoT
CUl6ZWNvbSBCVjEeMBwGCSqGSIb3DQEJARYPaW5mb0BpemVjb20uY29tMQwwCgYDVQQIEwNuL2Ex
EjAQBgNVBAcTCUFtc3RlcmRhbTELMAkGA1UEBhMCTkwxLDAqBgNVBAMTI0l6ZWNvbSBSb290IENl
cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTAzMDEyOTE2MjA0NloXDTE2MDIwMjE2MjA0NlowgZEx
EjAQBgNVBAoTCUl6ZWNvbSBCVjEeMBwGCSqGSIb3DQEJARYPaW5mb0BpemVjb20uY29tMQwwCgYD
VQQIEwNuL2ExEjAQBgNVBAcTCUFtc3RlcmRhbTELMAkGA1UEBhMCTkwxLDAqBgNVBAMTI0l6ZWNv
bSBSb290IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MIIBIDANBgkqhkiG9w0BAQEFAAOCAQ0AMIIB
CAKCAQEA9XehWqD0AK8jSepGl5mMpn3LWW930PXr5RtckP/RtVAu08TIOAkILvlx5Sjm2nOqbdYU
HavIRgMLoyI0gaH8vKINixLDgb/vgtTVQkd09k+VGIOJ/jq40PvWQ4BVRImd/0mbMYgAePhFSQrg
RfALhd0e+pNweBEO5Gg+OYkElGU6f5B+cH3LHiMhfJ7JEJKGjMHsFGGDAp/jeQTcK9icqCg+NqR/
FT/xw6eh35ucxL5A74hFvog06u8m5MAOB2Y7RT2NPHAoYy3WCdYeSZmWYnQa0GRn0WBCvefQdtL6
mCkMfwcP0EBBV2dnz+nz93XE7ln06j8gaw1bBMDEibHo+wIBETANBgkqhkiG9w0BAQUFAAOCAQEA
i7ej2XrLJv896UmfB1QSsCz87MbBgH8IJDMKODQG9fd1mEBkYLrtSUamMgYLp1yY/jLLwoMa9Am6
+wL1UjeBiiv0CXHy+K69uM1DnarenYqDIJOoLJ+7bNifG28yuPiaelCT3KPSB4Z06K6iOY2ZTU2e
Nw+HIQC06mR9x0oSa97yWf51CsiKbj+yE2GUd8dUuEVMqiCHB5KLAJGh/MsoapVJygOcRXh1JHhR
POicqzNXOZaML2RE1glkJJsugLul9ZG5OtJaabQ3T59eUVB50mM8FXl5KZmRD4Uu3LNd+JwUVweU
RQxpkA23DB+hPcTLyQyPxVAr8idWdRfPp3IlBzCCA6swggKToAMCAQICEQD35e5jJF0OpCqkSE+3
KrwXMA0GCSqGSIb3DQEBBQUAMIGRMRIwEAYDVQQKEwlJemVjb20gQlYxHjAcBgkqhkiG9w0BCQEW
D2luZm9AaXplY29tLmNvbTEMMAoGA1UECBMDbi9hMRIwEAYDVQQHEwlBbXN0ZXJkYW0xCzAJBgNV
BAYTAk5MMSwwKgYDVQQDEyNJemVjb20gUm9vdCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0w
MzAxMjkxNjIwNDZaFw0xNjAyMDIxNjIwNDZaMIGRMRIwEAYDVQQKEwlJemVjb20gQlYxHjAcBgkq
hkiG9w0BCQEWD2luZm9AaXplY29tLmNvbTEMMAoGA1UECBMDbi9hMRIwEAYDVQQHEwlBbXN0ZXJk
YW0xCzAJBgNVBAYTAk5MMSwwKgYDVQQDEyNJemVjb20gUm9vdCBDZXJ0aWZpY2F0aW9uIEF1dGhv
cml0eTCCASAwDQYJKoZIhvcNAQEBBQADggENADCCAQgCggEBAPV3oVqg9ACvI0nqRpeZjKZ9y1lv
d9D16+UbXJD/0bVQLtPEyDgJCC75ceUo5tpzqm3WFB2ryEYDC6MiNIGh/LyiDYsSw4G/74LU1UJH
dPZPlRiDif46uND71kOAVUSJnf9JmzGIAHj4RUkK4EXwC4XdHvqTcHgRDuRoPjmJBJRlOn+QfnB9
yx4jIXyeyRCShozB7BRhgwKf43kE3CvYnKgoPjakfxU/8cOnod+bnMS+QO+IRb6INOrvJuTADgdm
O0U9jTxwKGMt1gnWHkmZlmJ0GtBkZ9FgQr3n0HbS+pgpDH8HD9BAQVdnZ8/p8/d1xO5Z9Oo/IGsN
WwTAxImx6PsCAREwDQYJKoZIhvcNAQEFBQADggEBAIu3o9l6yyb/PelJnwdUErAs/OzGwYB/CCQz
Cjg0BvX3dZhAZGC67UlGpjIGC6dcmP4yy8KDGvQJuvsC9VI3gYor9Alx8viuvbjNQ52q3p2KgyCT
qCyfu2zYnxtvMrj4mnpQk9yj0geGdOiuojmNmU1NnjcPhyEAtOpkfcdKEmve8ln+dQrIim4/shNh
lHfHVLhFTKoghweSiwCRofzLKGqVScoDnEV4dSR4UTzonKszVzmWjC9kRNYJZCSbLoC7pfWRuTrS
Wmm0N0+fXlFQedJjPBV5eSmZkQ+FLtyzXficFFcHlEUMaZANtwwfoT3Ey8kMj8VQK/InVnUXz6dy
JQcwggO2MIICnqADAgECAhAhQVblAVcWjoxkw84STmMBMA0GCSqGSIb3DQEBBQUAMIGOMRIwEAYD
VQQKEwlJemVjb20gQlYxHzAdBgkqhkiG9w0BCQEWEGluZm9AaXplbWFpbC5jb20xDDAKBgNVBAgT
A24vYTESMBAGA1UEBxMJQW1zdGVyZGFtMQswCQYDVQQGEwJOTDEoMCYGA1UEAxMfSXplbWFpbCBD
ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wMzExMTgxNjA4MDhaFw0wNDAxMDkyMzAwMDBaMIGG
MQswCQYDVQQGEwJOTDESMBAGA1UEBxMJQW1zdGVyZGFtMQ8wDQYDVQQKEwZJemVjb20xLDAqBgkq
hkiG9w0BCQEWHWNocmlzdGluZUBleGNoYW5nZS5pemVjb20uY29tMSQwIgYDVQQDExtDaHJpc3Rp
bmUgS2FybWFuIChFeGNoYW5nZSkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOKKHFvKAQdK
gWFEE4E47P9PK4bdoHSVR/+PttqgzhHtAmnD3CV4Szzb4kpE+rgwcBhQq35HB35kP41mSmLDg399
lcsEXJLs3DNMQo9lv8vIQb6ucK5q7sOyqrTYstvSZ/h+97tO3DHFtor5IFbrHVAGvYJe6C2Ar90Q
7dRDFkDJAgMBAAGjgZkwgZYwDwYDVR0TBAgwBgEBAAIBADA6BgNVHR8EMzAxMC+gLaArhilodHRw
Oi8vd3d3Lml6ZWNvbS5jb20vaXplbWFpbC9pemVtYWlsLmNybDAoBgNVHREEITAfgR1jaHJpc3Rp
bmVAZXhjaGFuZ2UuaXplY29tLmNvbTAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwDQYJ
KoZIhvcNAQEFBQADggEBABs+YVSWPBAglz8v8Qq8LldkOtIMHjrfzNNFs6ZVq1DgSAbbVNDNPs7B
BSMNzCFox2zvVqIEQ7BF8Uoj9VWwUGsn+FfOJ2RNG4R2radbDNZHkh/mut2Ie+Gy9VJThmxA9Gzl
FsFQOWv7cVl7Iwpkcjy4cexpL2GuBRM3qJJwDYMO/BjUOYTZacyWyom+f2xMJet63WG/ZdGzVyF8
FTm7x1ieR0C6pnNLQQD3ZYU4g2M72zUAaeBkxZ02FbyU2vzjWBDCS4DBatOlD2VLHmpfHvtCS1w3
qadUZ7K3O8XZK8HXNBa+G2vkSdsbS3eOypuY2R8dRjx5P/U8/F5A6dq2+28wggP8MIIC5KADAgEC
AhEAkRzEQl+3lUGfoi109w5blTANBgkqhkiG9w0BAQUFADCBkTESMBAGA1UEChMJSXplY29tIEJW
MR4wHAYJKoZIhvcNAQkBFg9pbmZvQGl6ZWNvbS5jb20xDDAKBgNVBAgTA24vYTESMBAGA1UEBxMJ
QW1zdGVyZGFtMQswCQYDVQQGEwJOTDEsMCoGA1UEAxMjSXplY29tIFJvb3QgQ2VydGlmaWNhdGlv
biBBdXRob3JpdHkwHhcNMDMwMTI5MTYyMTI4WhcNMTQwMjAyMTYyMTI4WjCBjjESMBAGA1UEChMJ
SXplY29tIEJWMR8wHQYJKoZIhvcNAQkBFhBpbmZvQGl6ZW1haWwuY29tMQwwCgYDVQQIEwNuL2Ex
EjAQBgNVBAcTCUFtc3RlcmRhbTELMAkGA1UEBhMCTkwxKDAmBgNVBAMTH0l6ZW1haWwgQ2VydGlm
aWNhdGlvbiBBdXRob3JpdHkwggEgMA0GCSqGSIb3DQEBAQUAA4IBDQAwggEIAoIBAQCo/rB7lTHt
ws4xQlQSA1DS6V+1ghSjfDLiWfGqiTB7wOWOPge5jnSzV355jW65X2MNJTFYlXiyLM7627XtDlYf
eIsZm0H8cHElRJoLJFGFHDkQ1H+YOUg/iTXTsRcufTvwP3ywbKe7AGdmi3pWXVWB6gJ81AtU1oJ7
K+h/g3OUqh79+Kd/zJuEAmfQrggDdeb335AW0ckOtyQ8FiISe0Op1wn7aOqvn0jKNDnnj5glsptT
aBMXU54uQHEoIrolZeyQUxvaRcfYG4UFxhMlfo9Dfp5WaJxasfLEFOmIOEmmJdbsMTyYFzgLo75Z
d2SrHh4VuuoMH22vPl5vOX6NFJsZAgERo1IwUDALBgNVHQ8EBAMCAQYwDwYDVR0TBAgwBgEB/wIB
ADARBglghkgBhvhCAQEEBAMCAQYwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqG
SIb3DQEBBQUAA4IBAQDxyi/r3gUlGF1xaGUMJ/9n9LCGW1brfpanQaZWmMGHr0l3G8eAysw7heZ8
HlAG7mZcuzeRmaPNP+orJPzu8SgVkoMUajVXJf4n1FXbcDW2KrwsUjJ+dAD8qDCUoNXJin/UjSkS
3+Bkl7MmcxDvC6mpsySah0ggqWotP0z+/8WKXY0nDFu5PueyshCZxfvHISr9eoRlljZlVx1TNVsl
DmqG42k+FR+rUJg+T8rgXpyieE6eusUB3Q9AorhksqFYfYy3oMetSVdn9ybxwfBK88GtJkH+KWNI
i9onG5AEEIDOwUcMR4bOZbexRAda2BSLcL0xdNY1S9Vb0xR7EfYkRiTPMIID/DCCAuSgAwIBAgIR
AJEcxEJft5VBn6ItdPcOW5UwDQYJKoZIhvcNAQEFBQAwgZExEjAQBgNVBAoTCUl6ZWNvbSBCVjEe
MBwGCSqGSIb3DQEJARYPaW5mb0BpemVjb20uY29tMQwwCgYDVQQIEwNuL2ExEjAQBgNVBAcTCUFt
c3RlcmRhbTELMAkGA1UEBhMCTkwxLDAqBgNVBAMTI0l6ZWNvbSBSb290IENlcnRpZmljYXRpb24g
QXV0aG9yaXR5MB4XDTAzMDEyOTE2MjEyOFoXDTE0MDIwMjE2MjEyOFowgY4xEjAQBgNVBAoTCUl6
ZWNvbSBCVjEfMB0GCSqGSIb3DQEJARYQaW5mb0BpemVtYWlsLmNvbTEMMAoGA1UECBMDbi9hMRIw
EAYDVQQHEwlBbXN0ZXJkYW0xCzAJBgNVBAYTAk5MMSgwJgYDVQQDEx9JemVtYWlsIENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5MIIBIDANBgkqhkiG9w0BAQEFAAOCAQ0AMIIBCAKCAQEAqP6we5Ux7cLO
MUJUEgNQ0ulftYIUo3wy4lnxqokwe8Dljj4HuY50s1d+eY1uuV9jDSUxWJV4sizO+tu17Q5WH3iL
GZtB/HBxJUSaCyRRhRw5ENR/mDlIP4k107EXLn078D98sGynuwBnZot6Vl1VgeoCfNQLVNaCeyvo
f4NzlKoe/finf8ybhAJn0K4IA3Xm99+QFtHJDrckPBYiEntDqdcJ+2jqr59IyjQ554+YJbKbU2gT
F1OeLkBxKCK6JWXskFMb2kXH2BuFBcYTJX6PQ36eVmicWrHyxBTpiDhJpiXW7DE8mBc4C6O+WXdk
qx4eFbrqDB9trz5ebzl+jRSbGQIBEaNSMFAwCwYDVR0PBAQDAgEGMA8GA1UdEwQIMAYBAf8CAQAw
EQYJYIZIAYb4QgEBBAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjANBgkqhkiG
9w0BAQUFAAOCAQEA8cov694FJRhdcWhlDCf/Z/SwhltW636Wp0GmVpjBh69JdxvHgMrMO4XmfB5Q
Bu5mXLs3kZmjzT/qKyT87vEoFZKDFGo1VyX+J9RV23A1tiq8LFIyfnQA/KgwlKDVyYp/1I0pEt/g
ZJezJnMQ7wupqbMkmodIIKlqLT9M/v/Fil2NJwxbuT7nsrIQmcX7xyEq/XqEZZY2ZVcdUzVbJQ5q
huNpPhUfq1CYPk/K4F6conhOnrrFAd0PQKK4ZLKhWH2Mt6DHrUlXZ/cm8cHwSvPBrSZB/iljSIva
JxuQBBCAzsFHDEeGzmW3sUQHWtgUi3C9MXTWNUvVW9MUexH2JEYkzzCCA/wwggLkoAMCAQICEQCR
HMRCX7eVQZ+iLXT3DluVMA0GCSqGSIb3DQEBBQUAMIGRMRIwEAYDVQQKEwlJemVjb20gQlYxHjAc
BgkqhkiG9w0BCQEWD2luZm9AaXplY29tLmNvbTEMMAoGA1UECBMDbi9hMRIwEAYDVQQHEwlBbXN0
ZXJkYW0xCzAJBgNVBAYTAk5MMSwwKgYDVQQDEyNJemVjb20gUm9vdCBDZXJ0aWZpY2F0aW9uIEF1
dGhvcml0eTAeFw0wMzAxMjkxNjIxMjhaFw0xNDAyMDIxNjIxMjhaMIGOMRIwEAYDVQQKEwlJemVj
b20gQlYxHzAdBgkqhkiG9w0BCQEWEGluZm9AaXplbWFpbC5jb20xDDAKBgNVBAgTA24vYTESMBAG
A1UEBxMJQW1zdGVyZGFtMQswCQYDVQQGEwJOTDEoMCYGA1UEAxMfSXplbWFpbCBDZXJ0aWZpY2F0
aW9uIEF1dGhvcml0eTCCASAwDQYJKoZIhvcNAQEBBQADggENADCCAQgCggEBAKj+sHuVMe3CzjFC
VBIDUNLpX7WCFKN8MuJZ8aqJMHvA5Y4+B7mOdLNXfnmNbrlfYw0lMViVeLIszvrbte0OVh94ixmb
QfxwcSVEmgskUYUcORDUf5g5SD+JNdOxFy59O/A/fLBsp7sAZ2aLelZdVYHqAnzUC1TWgnsr6H+D
c5SqHv34p3/Mm4QCZ9CuCAN15vffkBbRyQ63JDwWIhJ7Q6nXCfto6q+fSMo0OeePmCWym1NoExdT
ni5AcSgiuiVl7JBTG9pFx9gbhQXGEyV+j0N+nlZonFqx8sQU6Yg4SaYl1uwxPJgXOAujvll3ZKse
HhW66gwfba8+Xm85fo0UmxkCARGjUjBQMAsGA1UdDwQEAwIBBjAPBgNVHRMECDAGAQH/AgEAMBEG
CWCGSAGG+EIBAQQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwDQYJKoZIhvcN
AQEFBQADggEBAPHKL+veBSUYXXFoZQwn/2f0sIZbVut+lqdBplaYwYevSXcbx4DKzDuF5nweUAbu
Zly7N5GZo80/6isk/O7xKBWSgxRqNVcl/ifUVdtwNbYqvCxSMn50APyoMJSg1cmKf9SNKRLf4GSX
syZzEO8LqamzJJqHSCCpai0/TP7/xYpdjScMW7k+57KyEJnF+8chKv16hGWWNmVXHVM1WyUOaobj
aT4VH6tQmD5PyuBenKJ4Tp66xQHdD0CiuGSyoVh9jLegx61JV2f3JvHB8Erzwa0mQf4pY0iL2icb
kAQQgM7BRwxHhs5lt7FEB1rYFItwvTF01jVL1VvTFHsR9iRGJM8wggP8MIIC5KADAgECAhEAkRzE
Ql+3lUGfoi109w5blTANBgkqhkiG9w0BAQUFADCBkTESMBAGA1UEChMJSXplY29tIEJWMR4wHAYJ
KoZIhvcNAQkBFg9pbmZvQGl6ZWNvbS5jb20xDDAKBgNVBAgTA24vYTESMBAGA1UEBxMJQW1zdGVy
ZGFtMQswCQYDVQQGEwJOTDEsMCoGA1UEAxMjSXplY29tIFJvb3QgQ2VydGlmaWNhdGlvbiBBdXRo
b3JpdHkwHhcNMDMwMTI5MTYyMTI4WhcNMTQwMjAyMTYyMTI4WjCBjjESMBAGA1UEChMJSXplY29t
IEJWMR8wHQYJKoZIhvcNAQkBFhBpbmZvQGl6ZW1haWwuY29tMQwwCgYDVQQIEwNuL2ExEjAQBgNV
BAcTCUFtc3RlcmRhbTELMAkGA1UEBhMCTkwxKDAmBgNVBAMTH0l6ZW1haWwgQ2VydGlmaWNhdGlv
biBBdXRob3JpdHkwggEgMA0GCSqGSIb3DQEBAQUAA4IBDQAwggEIAoIBAQCo/rB7lTHtws4xQlQS
A1DS6V+1ghSjfDLiWfGqiTB7wOWOPge5jnSzV355jW65X2MNJTFYlXiyLM7627XtDlYfeIsZm0H8
cHElRJoLJFGFHDkQ1H+YOUg/iTXTsRcufTvwP3ywbKe7AGdmi3pWXVWB6gJ81AtU1oJ7K+h/g3OU
qh79+Kd/zJuEAmfQrggDdeb335AW0ckOtyQ8FiISe0Op1wn7aOqvn0jKNDnnj5glsptTaBMXU54u
QHEoIrolZeyQUxvaRcfYG4UFxhMlfo9Dfp5WaJxasfLEFOmIOEmmJdbsMTyYFzgLo75Zd2SrHh4V
uuoMH22vPl5vOX6NFJsZAgERo1IwUDALBgNVHQ8EBAMCAQYwDwYDVR0TBAgwBgEB/wIBADARBglg
hkgBhvhCAQEEBAMCAQYwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEB
BQUAA4IBAQDxyi/r3gUlGF1xaGUMJ/9n9LCGW1brfpanQaZWmMGHr0l3G8eAysw7heZ8HlAG7mZc
uzeRmaPNP+orJPzu8SgVkoMUajVXJf4n1FXbcDW2KrwsUjJ+dAD8qDCUoNXJin/UjSkS3+Bkl7Mm
cxDvC6mpsySah0ggqWotP0z+/8WKXY0nDFu5PueyshCZxfvHISr9eoRlljZlVx1TNVslDmqG42k+
FR+rUJg+T8rgXpyieE6eusUB3Q9AorhksqFYfYy3oMetSVdn9ybxwfBK88GtJkH+KWNIi9onG5AE
EIDOwUcMR4bOZbexRAda2BSLcL0xdNY1S9Vb0xR7EfYkRiTPMIIEDTCCAvWgAwIBAgIQZukaRJOd
0047Jqoo58OaMjANBgkqhkiG9w0BAQUFADCBkTESMBAGA1UEChMJSXplY29tIEJWMR4wHAYJKoZI
hvcNAQkBFg9pbmZvQGl6ZWNvbS5jb20xDDAKBgNVBAgTA24vYTESMBAGA1UEBxMJQW1zdGVyZGFt
MQswCQYDVQQGEwJOTDEsMCoGA1UEAxMjSXplY29tIFJvb3QgQ2VydGlmaWNhdGlvbiBBdXRob3Jp
dHkwHhcNMDMxMDA5MDkzOTIyWhcNMTQxMDEzMDkzOTIyWjCBgzESMBAGA1UEChMJSXplY29tIEJW
MR8wHQYJKoZIhvcNAQkBFhBpbmZvQGl6ZW1haWwuY29tMRYwFAYDVQQIEw1Ob29yZC1Ib2xsYW5k
MRIwEAYDVQQHEwlBbXN0ZXJkYW0xCzAJBgNVBAYTAk5MMRMwEQYDVQQDEwpJemVtYWlsIENBMIIB
IDANBgkqhkiG9w0BAQEFAAOCAQ0AMIIBCAKCAQEAk5I0X5lf7qjlX7k8iWRzRxh+BHrQRCT+Wc3e
lx2OF1BkIPpYgxrfbik9z2+Ag3N2ya6fh1oQ83XcxnP7OuHaT/ePKFEVzBo30pqfSd+QuGERp99i
AnglxeTDwtatd86vIMB7/XwlZtrbjo0v3FC4vE7zoBHnNL5D+IjxFbcEBaVZvMJT7f8SZShzM23y
rnlXVYcaC4C6H9p2cyafag1KVe1+rSUgpefKt16wxVQFuTJOl1tViFJdiGlACOwUvQ0buhcCmY5u
aH5owOolEjNUjfy3F4iPTj3QDS/lD4Kc+zeBHTNIe4iPyN1G12Lu2GQl+NAY7t5KM0xK3svD+L18
XwIBEaNvMG0wOgYDVR0fBDMwMTAvoC2gK4YpaHR0cDovL3d3dy5pemVjb20uY29tL2l6ZW1haWwv
aXplcm9vdC5jcmwwCwYDVR0PBAQDAgEGMA8GA1UdEwQIMAYBAf8CAQEwEQYJYIZIAYb4QgEBBAQD
AgEGMA0GCSqGSIb3DQEBBQUAA4IBAQCfSVaVl9acK4iqjnOwhPjzZAuy7HhbXraNK7Zl0ZAmCLgD
lWGe+tjPTOJ5jg6miO1u4jKY/T4+WltYt1m4OcqSNT8ZsXWA4vDZZ69Br7jJeOHwr99UZtTLJSwN
tURgeDb0390XiCyiMJgF/yRlPrPBBoXutyZ7OImIypYytrHDq//esWntMZgksYk6XvIw0yLvrbIi
FJzQvpR8F3I03XGu1xEswWd/1NA+D13JYLv4J6WXLKR7KR81qqfkj9Jds31C7R1rl6AZpnVHHtaG
AS8SjHQbgrh/PtLFTCFTFcZvAvTawPpGRvxZlDgZDI+TQf50EJY47zHdUMchVuSnY2UBMIIEpjCC
BA+gAwIBAgIQWYKh8NsnSwS4jw/pFlnjFTANBgkqhkiG9w0BAQQFADCBzDEXMBUGA1UEChMOVmVy
aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3
dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMp
OTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBl
cnNvbmEgTm90IFZhbGlkYXRlZDAeFw0wMzA4MDUwMDAwMDBaFw0wNDAxMDkyMzU5NTlaMIIBGDEX
MBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx
RjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYu
LExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE0MDIGA1UECxMr
RGlnaXRhbCBJRCBDbGFzcyAxIC0gTWljcm9zb2Z0IEZ1bGwgU2VydmljZTEZMBcGA1UEAxQQQ2hy
aXN0aW5lIEthcm1hbjEjMCEGCSqGSIb3DQEJARYUY2hyaXN0aW5lQGl6ZWNvbS5jb20wgZ8wDQYJ
KoZIhvcNAQEBBQADgY0AMIGJAoGBALhEzrZwfeHbV+uUWfLEtXGFGGrgv8wahX2fi83afKZlIty9
ATl8PjrtxSIgP3FC1HNu67Pi8CnTT5LfqhI9fjdug6EUA1hmAAis+LGHMy0s+0WrgdpWrVZ2vJ6/
T88u0q6hOKhXEfZ7dyeh4EMgb0Q6INnRIt4UgWFi/1GZSOd7AgMBAAGjggE4MIIBNDAJBgNVHRME
AjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczov
L3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIB
ARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBW
ZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMAYKYIZIAYb4RQEGBwQiFiA0MWJkN2IwYzE1OTdm
YTVmYjllZDk1NTQ0MzJiYmExNDAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWdu
LmNvbS9jbGFzczEuY3JsMA0GCSqGSIb3DQEBBAUAA4GBADLc57OahZ+LXdAZrFH6LstiF0VnaAj4
QfdFKBOAlWhFAjSjlgLH05waMclFF17725O4M71Q0cEowxbvIYj5rCQubLNzwGIjfXlHE5XSTZfr
+1melpIpNObGYpu/26fenzdgafjbS1FbOqU7xk7MH4H7pBS0aKXeYofjWiiWwRbwMIIEpjCCBA+g
AwIBAgIQWYKh8NsnSwS4jw/pFlnjFTANBgkqhkiG9w0BAQQFADCBzDEXMBUGA1UEChMOVmVyaVNp
Z24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52
ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgx
SDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNv
bmEgTm90IFZhbGlkYXRlZDAeFw0wMzA4MDUwMDAwMDBaFw0wNDAxMDkyMzU5NTlaMIIBGDEXMBUG
A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBE
BgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJ
QUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE0MDIGA1UECxMrRGln
aXRhbCBJRCBDbGFzcyAxIC0gTWljcm9zb2Z0IEZ1bGwgU2VydmljZTEZMBcGA1UEAxQQQ2hyaXN0
aW5lIEthcm1hbjEjMCEGCSqGSIb3DQEJARYUY2hyaXN0aW5lQGl6ZWNvbS5jb20wgZ8wDQYJKoZI
hvcNAQEBBQADgY0AMIGJAoGBALhEzrZwfeHbV+uUWfLEtXGFGGrgv8wahX2fi83afKZlIty9ATl8
PjrtxSIgP3FC1HNu67Pi8CnTT5LfqhI9fjdug6EUA1hmAAis+LGHMy0s+0WrgdpWrVZ2vJ6/T88u
0q6hOKhXEfZ7dyeh4EMgb0Q6INnRIt4UgWFi/1GZSOd7AgMBAAGjggE4MIIBNDAJBgNVHRMEAjAA
MIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3
dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9
VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJp
U2lnbjARBglghkgBhvhCAQEEBAMCB4AwMAYKYIZIAYb4RQEGBwQiFiA0MWJkN2IwYzE1OTdmYTVm
YjllZDk1NTQ0MzJiYmExNDAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNv
bS9jbGFzczEuY3JsMA0GCSqGSIb3DQEBBAUAA4GBADLc57OahZ+LXdAZrFH6LstiF0VnaAj4QfdF
KBOAlWhFAjSjlgLH05waMclFF17725O4M71Q0cEowxbvIYj5rCQubLNzwGIjfXlHE5XSTZfr+1me
lpIpNObGYpu/26fenzdgafjbS1FbOqU7xk7MH4H7pBS0aKXeYofjWiiWwRbwMYICFjCCAhICAQEw
geEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO
ZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2
aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFmCofDbJ0sEuI8P6RZZ4xUw
CQYFKw4DAhoFAKCBizAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0w
MzExMjgxMzE2NTdaMCMGCSqGSIb3DQEJBDEWBBRkfVwpfDRMP9M6xH9cstZ3xhSsEjAsBgkqhkiG
9w0BCQ8xHzAdMA8GCCqGSIb3DQMCMAMCATowCgYIKoZIhvcNAwcwDQYJKoZIhvcNAQEBBQAEgYBq
Tq8Fdb8oWVY00V9vWJ8qzAMxgS7mK+zUJLyfXClEHeIkWHfdm24TPxfv2uoPo5nJjy5iozg3mpv2
cEU+12rM6UpEKeHeV2vAKF2bSHJTykseWm0E2+Aut3CvDdB2FZR2V7mUoSOsPkbT3ErZtHTmzCjZ
c4S4VO2x0pkBwhV1ZA==

--{42F53F2B-4D8D-44E0-8C4D-FB0FF7232BEB}--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASBsVib096972 for <[e-mail]>; Fri, 28 Nov 2003 03:54:31 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hASBsVa7096971 for ietf-pkix-bks; Fri, 28 Nov 2003 03:54:31 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASBsTib096965 for <[e-mail]>; Fri, 28 Nov 2003 03:54:30 -0800 (PST) (envelope-from [e-mail])
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id NAA14290; Fri, 28 Nov 2003 13:01:10 +0100
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id MAA23309; Fri, 28 Nov 2003 12:56:46 +0100
Message-ID: <[e-mail]>
Date: Fri, 28 Nov 2003 12:54:25 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Russ Housley <[e-mail]>, Alice Sturgeon <[e-mail]>
CC: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-warranty-extn-04.txt
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii; 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>

Alice and Russ,

I have sent several message about the status of  draft-ietf-pkix-warranty-extn.

My last message on that topic has been addressed to Alice, but I have not 
received a response yet.

Please, Russ, would you also clarify where we are now, with respect to the 
comments that I sent during the last call.

Denis


> Alice,
> 
> Does this new document addresses the issues I raised to the IESG during 
> the last call ?
> 
> If yes, would you please provide a resolution for my comments.
> 
> Denis
> 
> 
>> 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 Warranty 
>> Certificate Extension
>>     Author(s)    : D. Linsenbardt, S. Pontius, A. Sturgeon
>>     Filename    : draft-ietf-pkix-warranty-extn-04.txt
>>     Pages        : 8
>>     Date        : 2003-11-18
>>     
>> This document describes a certificate extension to explicitly state
>> the warranty offered by a Certificate Authority (CA) for a the
>> certificate containing the extension.
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-pkix-warranty-extn-04.txt
>>
>> To remove yourself from the IETF Announcement list, send a message to 
>> ietf-announce-request with the word unsubscribe in the body of the 
>> message.
>>
>> 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-warranty-extn-04.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-warranty-extn-04.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 [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASBHQib093665 for <[e-mail]>; Fri, 28 Nov 2003 03:17:26 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hASBHQFK093664 for ietf-pkix-bks; Fri, 28 Nov 2003 03:17:26 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kiki.ssb.it ([192.106.128.1]) by above.proper.com (8.12.10/8.12.8) with SMTP id hASBHNib093650 for <[e-mail]>; Fri, 28 Nov 2003 03:17:24 -0800 (PST) (envelope-from [e-mail])
Received: from mail.tsp.it ([192.168.100.243]) by kiki; Fri, 28 Nov 2003 12:17:33 +0100 (CET)
Received: from mail.tsp.it (unknown [192.168.100.244]) by dns.tsp.it (Postfix) with ESMTP id BAF402D567 for <[e-mail]>; Fri, 28 Nov 2003 13:14:03 +0100 (CET)
Subject: 
To: [e-mail]
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <[e-mail]>
From: "Marco Nicoli" <[e-mail]>
Date: Fri, 28 Nov 2003 12:17:17 +0100
X-MIMETrack: Serialize by Router on Notes/TSP(Release 5.07a |May 14, 2001) at 28/11/2003  12.17.18
MIME-Version: 1.0
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>

remove




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9tuib086628 for <[e-mail]>; Fri, 28 Nov 2003 01:55:56 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAS9tuug086627 for ietf-pkix-bks; Fri, 28 Nov 2003 01:55:56 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from relhubc02-ukbr.tcrelay.net ([217.32.166.20]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9tqid086610 for <[e-mail]>; Fri, 28 Nov 2003 01:55:54 -0800 (PST) (envelope-from [e-mail])
Received: from mail pickup service by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC; Fri, 28 Nov 2003 09:50:00 +0000
Received: from above.proper.com ([208.184.76.39]) by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 26 Nov 2003 18:20:35 +0000
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQFB3ib026313 for <[e-mail]>; Wed, 26 Nov 2003 07:11:03 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQFB3OD026312 for ietf-pkix-bks; Wed, 26 Nov 2003 07:11:03 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.cs.auckland.ac.nz (csmail.cs.auckland.ac.nz [130.216.33.150]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQFB0ib026302 for <[e-mail]>; Wed, 26 Nov 2003 07:11:02 -0800 (PST) (envelope-from [e-mail])
Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id A299863C1D; Thu, 27 Nov 2003 04:10:58 +1300 (NZDT)
Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id hAQFDUG01265; Thu, 27 Nov 2003 04:13:30 +1300
Date: Thu, 27 Nov 2003 04:13:30 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Certificate Policy Standardization
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-OriginalArrivalTime: 26 Nov 2003 18:20:35.0835 (UTC) FILETIME=[FC7FC4B0:01C3B449]
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>

"Anders Rundgren" <[e-mail]> writes:

>1. Why does practically no shrink-wrap PKI-enabled software package support
>any kind of certificate policy settings?

Zero demand.  Heck, it wasn't too long ago that MS PKI software hardcoded the
Verisign policy into CryptoAPI, so that no matter what the actual policy was
in the cert, what was displayed was the Verisign policy.  That shows how much
attention people are paying to the policy stuff.

That doesn't mean that RPs don't use a policy-equivalent: The software is
configured - via trusted roots - to only accept certs from a given set of CAs
(Anders, that's the policy-configurability you asked for, it's just not called
that).  So the trusted-roots mechanism does what the policy extension is
supposed to do, and the policy extension becomes a legal self-defence
mechanism for the benefit of the CA.  This is an almost complete inversion of
what RFC 3280 thinks that the policy extension is meant for:

  Applications with specific policy requirements are expected to have a list
  of those policies which they will accept and to compare the policy OIDs in
  the certificate to that list.

Peter.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9tuib086630 for <[e-mail]>; Fri, 28 Nov 2003 01:55:56 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAS9tutg086629 for ietf-pkix-bks; Fri, 28 Nov 2003 01:55:56 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from relhubc02-ukbr.tcrelay.net ([217.32.166.20]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9tqif086610 for <[e-mail]>; Fri, 28 Nov 2003 01:55:54 -0800 (PST) (envelope-from [e-mail])
Received: from mail pickup service by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC; Fri, 28 Nov 2003 09:50:02 +0000
Received: from above.proper.com ([208.184.76.39]) by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 26 Nov 2003 14:24:23 +0000
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQEIPib023318 for <[e-mail]>; Wed, 26 Nov 2003 06:18:25 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQEIPRQ023317 for ietf-pkix-bks; Wed, 26 Nov 2003 06:18:25 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp2.mivlmd.cablespeed.com (smtp2.mivlmd.cablespeed.com [24.35.0.19]) by above.proper.com (8.12.10/8.12.8) with SMTP id hAQEINib023312 for <[e-mail]>; Wed, 26 Nov 2003 06:18:23 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 17480 invoked by uid 0); 26 Nov 2003 14:17:47 -0000
Received: from unknown (HELO cablespeed.com) (24.35.57.71) by 0 with SMTP; 26 Nov 2003 14:17:47 -0000
Message-ID: <[e-mail]>
Date: Wed, 26 Nov 2003 09:19:55 -0500
From: jim <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Certificate Policy Standardization
References: <[e-mail]> <[e-mail]>            <00e001c3b366$7c1cbc80$0500a8c0@arport> <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-OriginalArrivalTime: 26 Nov 2003 14:24:24.0070 (UTC) FILETIME=[FD780A60:01C3B428]
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>

Richard brings up an excellent point that should be considered by the 
members of this body.  On the horizon is the implementation of security 
middleware from a number of sources, which will allow for simpler 
PKEnablement of Web applications.  The issue in this regard is going to 
be the identification of how trust can be shared without having to go 
back to the original CA who issued a cert and cross-certifying CAs in 
that regard so that Internet commerce can be accomplished with many uses 
on the fly from disparate PKIs.  Meaningful OIDs offer a lot that can 
increase the success or failure of PK technology adaptation for 
commerce.  In that regard, please everyone, see what you can think of 
that will make this a useful and helpful solution to allow PK technology 
to flourish.

Jim Heimberg, ABC, Ph.D.
Secure Course
www.securecourse.com


Richard Levitte - VMS Whacker wrote:

>In message <00e001c3b366$7c1cbc80$0500a8c0@arport> on Tue, 25 Nov 2003 16:11:57 +0100, "Anders Rundgren" <[e-mail]> said:
>
>anders.rundgren> Policy OIDs may be "perfect" as long as you stay
>anders.rundgren> inside of your "walled garden", but the USs
>anders.rundgren> government PKI will likely find itself up the creek
>anders.rundgren> when they are going to connect to the outside world
>anders.rundgren> who hardly ever use this feature (which I BTW cannot
>anders.rundgren> find a single "knob" for in my W2K system), or even
>anders.rundgren> worse, have settled on another set of OIDs.
>
>Uhmm, especially that last thing about other PKIs having other sets
>of OIDs makes me think you have missed the mechanism called "policy
>mapping".  There's no requirement whatsoever that everyone uses the
>same set of OIDs.  However, if the owner of one PKI decides to do
>business with another PKI owner and have the two PKIs connected, they
>will typically do some cross certification, and those certificates
>will contain the appropriate mappings of policies, as decided by the
>two parties together.
>
>As far as I understand, those kinds of mechanisms are already in use
>and working.  I assume others here will be able to say yay or ney
>about this matter.
>
>Of course, what I said above implies some level of "meshness", about
>which I've read some negative comments from one person...
>
>-----
>Please consider sponsoring my work on free software.
>See http://www.free.lp.se/sponsoring.html for details.
>You don't have to be rich, a $10 donation is appreciated!
>
>  
>





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9tsib086617 for <[e-mail]>; Fri, 28 Nov 2003 01:55:54 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAS9trZw086616 for ietf-pkix-bks; Fri, 28 Nov 2003 01:55:53 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from relhubc02-ukbr.tcrelay.net ([217.32.166.20]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9tqib086610 for <[e-mail]>; Fri, 28 Nov 2003 01:55:53 -0800 (PST) (envelope-from [e-mail])
Received: from mail pickup service by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC; Fri, 28 Nov 2003 09:49:58 +0000
Received: from above.proper.com ([208.184.76.39]) by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 26 Nov 2003 14:31:30 +0000
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQBaPib013852 for <[e-mail]>; Wed, 26 Nov 2003 03:36:25 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQBaPrM013851 for ietf-pkix-bks; Wed, 26 Nov 2003 03:36:25 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp4.hy.skanova.net (smtp4.hy.skanova.net [195.67.199.133]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQBaOib013844 for <[e-mail]>; Wed, 26 Nov 2003 03:36:25 -0800 (PST) (envelope-from [e-mail])
Received: from arport (t11o913p109.telia.com [213.64.28.109]) by smtp4.hy.skanova.net (8.12.10/8.12.10) with SMTP id hAQBaMBZ006267; Wed, 26 Nov 2003 12:36:22 +0100 (CET)
Message-ID: <00f901c3b410$fda8f250$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>, "Richard Levitte - VMS Whacker" <[e-mail]>, =?iso-8859-1?Q?Michael_Str=F6der?= <[e-mail]>
References: <[e-mail]>
Subject: Re: Certificate Policy Standardization
Date: Wed, 26 Nov 2003 12:31:19 +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
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-OriginalArrivalTime: 26 Nov 2003 14:31:30.0507 (UTC) FILETIME=[FBA529B0:01C3B429]
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>

>For me, OIDs are yet to have their time. As a concept they are elegant
>but will resist widespread use until security-exploiting applications
>support them. Until then they are destined to stay on the back-burner.

Sure.

>I encourage people to adopt their use, however, if only to future-proof
>themselves and I don't see any harm whatsoever in embedding in a certificate
>some mechanism that links the trust level it represents to a real-world
>legal mechanism, even if at present the software support for such a link
>is absent.

In case you are advicing people setting up CAs, I would (in case the
CP OID stuff stays forever in the backburner), also recommend them
to only apply one CP per CA root, as anyhting else is actually
incompatible with some 99.9% of existing RP software.

/anders



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9thib086608 for <[e-mail]>; Fri, 28 Nov 2003 01:55:43 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAS9thOn086607 for ietf-pkix-bks; Fri, 28 Nov 2003 01:55:43 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from relhubc02-ukbr.tcrelay.net ([217.32.166.20]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9tgib086599 for <[e-mail]>; Fri, 28 Nov 2003 01:55:42 -0800 (PST) (envelope-from [e-mail])
Received: from mail pickup service by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC; Fri, 28 Nov 2003 09:49:47 +0000
Received: from above.proper.com ([208.184.76.39]) by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 26 Nov 2003 14:02:46 +0000
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQDu1ib021994 for <[e-mail]>; Wed, 26 Nov 2003 05:56:01 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQDu1Rd021993 for ietf-pkix-bks; Wed, 26 Nov 2003 05:56:01 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp4.hy.skanova.net (smtp4.hy.skanova.net [195.67.199.133]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQDtxib021987 for <[e-mail]>; Wed, 26 Nov 2003 05:56:00 -0800 (PST) (envelope-from [e-mail])
Received: from arport (t8o913p59.telia.com [213.64.26.179]) by smtp4.hy.skanova.net (8.12.10/8.12.10) with SMTP id hAQDtwBZ009924; Wed, 26 Nov 2003 14:55:58 +0100 (CET)
Message-ID: <028101c3b424$7dd4b460$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Richard Levitte - VMS Whacker" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]> <[e-mail]>            <00e001c3b366$7c1cbc80$0500a8c0@arport> <[e-mail]>
Subject: Re: Certificate Policy Standardization
Date: Wed, 26 Nov 2003 14:52:10 +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
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-OriginalArrivalTime: 26 Nov 2003 14:02:46.0945 (UTC) FILETIME=[F8527910:01C3B425]
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>

Richard,
That external parties to the US e-governments, like various
businesses would ever (on a wider scale) bother with cross-
certification is unlikely, they will just purchase a TTP-issued
"business certificate" for a few hundred dollars, not run CAs.

And in the case of the US e-government, they have a much more
serious problem to cater for than CP OIDs and that is that their
business parties, will authenticate messages at the business partner
level, not on employee level (as the latter is incompatible with
all e-business systems I have heard about).  So they probably
have to take down the whole thing and startover anyway.
Or have "gateway" servers do the transformation from their
internal "mess-PKI" (not mesh PKI) to something that works.
Like "flat", "boring", "simple",  you know.  In that world
CP OIDs are mostly unknown.   I have yet to find a CP OID
in my fairly new Thawte SSL certificate.

Anders


----- Original Message -----
From: "Richard Levitte - VMS Whacker" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>
Sent: Wednesday, November 26, 2003 14:30
Subject: Re: Certificate Policy Standardization


In message <00e001c3b366$7c1cbc80$0500a8c0@arport> on Tue, 25 Nov 2003 16:11:57 +0100, "Anders Rundgren" <[e-mail]>
said:

anders.rundgren> Policy OIDs may be "perfect" as long as you stay
anders.rundgren> inside of your "walled garden", but the USs
anders.rundgren> government PKI will likely find itself up the creek
anders.rundgren> when they are going to connect to the outside world
anders.rundgren> who hardly ever use this feature (which I BTW cannot
anders.rundgren> find a single "knob" for in my W2K system), or even
anders.rundgren> worse, have settled on another set of OIDs.

Uhmm, especially that last thing about other PKIs having other sets
of OIDs makes me think you have missed the mechanism called "policy
mapping".  There's no requirement whatsoever that everyone uses the
same set of OIDs.  However, if the owner of one PKI decides to do
business with another PKI owner and have the two PKIs connected, they
will typically do some cross certification, and those certificates
will contain the appropriate mappings of policies, as decided by the
two parties together.

As far as I understand, those kinds of mechanisms are already in use
and working.  I assume others here will be able to say yay or ney
about this matter.

Of course, what I said above implies some level of "meshness", about
which I've read some negative comments from one person...

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.
You don't have to be rich, a $10 donation is appreciated!

--
Richard Levitte     | http://richard.levitte.org/ | Tunnlandsv. 3
Levitte Programming | http://www.lp.se/           | S-168 36 Bromma
T: [phone] |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9stib086568 for <[e-mail]>; Fri, 28 Nov 2003 01:54:55 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAS9stol086567 for ietf-pkix-bks; Fri, 28 Nov 2003 01:54:55 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from relhubc02-ukbr.tcrelay.net ([217.32.166.20]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9srib086561 for <[e-mail]>; Fri, 28 Nov 2003 01:54:54 -0800 (PST) (envelope-from [e-mail])
Received: from mail pickup service by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC; Fri, 28 Nov 2003 09:48:51 +0000
Received: from above.proper.com ([208.184.76.39]) by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 26 Nov 2003 15:42:27 +0000
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQFdYib027926 for <[e-mail]>; Wed, 26 Nov 2003 07:39:34 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQFdYCA027925 for ietf-pkix-bks; Wed, 26 Nov 2003 07:39:34 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.cs.auckland.ac.nz (csmail.cs.auckland.ac.nz [130.216.33.150]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQFdWib027920 for <[e-mail]>; Wed, 26 Nov 2003 07:39:33 -0800 (PST) (envelope-from [e-mail])
Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id 8818063C1D; Thu, 27 Nov 2003 04:39:33 +1300 (NZDT)
Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id hAQFg5L01342; Thu, 27 Nov 2003 04:42:05 +1300
Date: Thu, 27 Nov 2003 04:42:05 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Certificate Policy Standardization
Cc: [e-mail], [e-mail]
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-OriginalArrivalTime: 26 Nov 2003 15:42:28.0335 (UTC) FILETIME=[E58227F0:01C3B433]
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>

Stephen Kent <[e-mail]> writes:

>For example, most certs used with IKE will not be subject to some attorney's
>advice, I suspect.

Actually now that you mention it one of the three classes of certs that were
going to be used in the situation I mentioned were IKE certs.  I think they
were going to subclass "doWhatISay" into "doWhatISayWithIKE",
"doWhatISayWithSSL", and "doWhatISayWithSMIMESigning"(not sure about the last
one, I have the paperwork downstairs but I'm too lazy to look it up).  All of
them were going to go through the full legal wringer.

Peter.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9s0ib086535 for <[e-mail]>; Fri, 28 Nov 2003 01:54:00 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAS9s0H9086534 for ietf-pkix-bks; Fri, 28 Nov 2003 01:54:00 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from relhubc02-ukbr.tcrelay.net ([217.32.166.20]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9rwib086519 for <[e-mail]>; Fri, 28 Nov 2003 01:53:59 -0800 (PST) (envelope-from [e-mail])
Received: from mail pickup service by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC; Fri, 28 Nov 2003 09:48:04 +0000
Received: from above.proper.com ([208.184.76.39]) by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 26 Nov 2003 16:10:41 +0000
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQF12ib025722 for <[e-mail]>; Wed, 26 Nov 2003 07:01:04 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQF12ud025721 for ietf-pkix-bks; Wed, 26 Nov 2003 07:01:02 -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.10/8.12.8) with ESMTP id hAQF0xib025703 for <[e-mail]>; Wed, 26 Nov 2003 07:01:00 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (127.0.0.1) by nic.lp.se (MX V5.3 VnHj) with ESMTP; Wed, 26 Nov 2003 16:00:57 +0100
Date: Wed, 26 Nov 2003 16:00:56 +0100 (CET)
Message-ID: <[e-mail]>
To: [e-mail]
CC: [e-mail], [e-mail]
Subject: Re: Certificate Policy Standardization
From: Richard Levitte - VMS Whacker <[e-mail]>
In-Reply-To: <014b01c3b416$b6075580$0500a8c0@arport>
References: <[e-mail]> <014b01c3b416$b6075580$0500a8c0@arport>
X-URL: http://www.lp.se/
X-Waved: dead chicken, GNU emacs 21.3.1, Mew version 4.0.60
X-Mew: See http://www.mew.org/
X-Mailer: Mew version 4.0.60 on Emacs 21.3.1 / Mule 5.0 (SAKAKI)
MIME-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-OriginalArrivalTime: 26 Nov 2003 16:10:41.0597 (UTC) FILETIME=[D6C56ED0:01C3B437]
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 <014b01c3b416$b6075580$0500a8c0@arport> on Wed, 26 Nov 2003 13:13:32 +0100, "Anders Rundgren" <[e-mail]> said:

anders.rundgren> >I don't see how you can say that, Anders. That's not
anders.rundgren> >how the system is designed to work. No CA s/w that I
anders.rundgren> >have yet to encounter limits certificates to a
anders.rundgren> >single policy, let alone the CA. CertificatePolicies
anders.rundgren> >can be multivalued, is not a mandatory field, does
anders.rundgren> >not get marked as critical and in all except bespoke
anders.rundgren> >applications is currently ignored. Failure on the
anders.rundgren> >part of software developers to meet the agreed
anders.rundgren> >standards does not always indicate a failing of the
anders.rundgren> >standard (granted that in some cases it does).
anders.rundgren> 
anders.rundgren> Well Chris,
anders.rundgren> I think you read this in big haste.
anders.rundgren> 
anders.rundgren> CA s/w is not equivalent to RP s/w.
anders.rundgren> 
anders.rundgren> Please tell me where I in the latest edition of
anders.rundgren> Outlook Express (I'm indeed a daring guy...), can
anders.rundgren> "tweak" the CA policy trust settings.

That's today.  I believe that to the crowd, awareness of the type of
trust we're discussing here is fairly new (and in many cases so new
they aren't aware yet).  And M$ is fairly well-known for implementing
what it thinks the crowd wants and try to avoid things that could be
seen as complicated ("oh, I should protect my private key with a pass
phrase???"), so pardon me for rejecting that particular example.

I believe that when the crowd becomes a bit more aware of what their
actions mean when done through a computer, compared to the "real
world", they might demand  certain amount of control, and it's
perfectly possible that you will see those kinds of "knobs" sometime
in the future.

anders.rundgren> In case you don't find the "knob", does this in your
anders.rundgren> opinion mean that Microsoft is not
anders.rundgren> standards-compliant w.r.t. policy-OIDs?

Nope, it just means that they have assumed you would always press the
"Accept any policy" knob, and besides, that's all they currently
support, so the knob would be quite lonely in that otherwise empty
space, so they won't bother to put it up yet.

However, if M$ doesn't check for policy OID and mappings and keep
track of those along with the other data while verifying the path,
then they aren't standards-compliant w.r.t. policy OIDs.  As it is
right now, I wouldn't be surprised if they're in good company :-/.

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.
You don't have to be rich, a $10 donation is appreciated!

-- 
Richard Levitte     | http://richard.levitte.org/ | Tunnlandsv. 3
Levitte Programming | http://www.lp.se/           | S-168 36 Bromma
T: [phone] |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9rmib086512 for <[e-mail]>; Fri, 28 Nov 2003 01:53:48 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAS9rmHI086511 for ietf-pkix-bks; Fri, 28 Nov 2003 01:53:48 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from relhubc02-ukbr.tcrelay.net ([217.32.166.20]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9rkib086503 for <[e-mail]>; Fri, 28 Nov 2003 01:53:46 -0800 (PST) (envelope-from [e-mail])
Received: from mail pickup service by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC; Fri, 28 Nov 2003 09:47:52 +0000
Received: from above.proper.com ([208.184.76.39]) by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 26 Nov 2003 16:24:53 +0000
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQEr6ib025318 for <[e-mail]>; Wed, 26 Nov 2003 06:53:06 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQEr6aR025317 for ietf-pkix-bks; Wed, 26 Nov 2003 06:53:06 -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.10/8.12.8) with ESMTP id hAQEr5ib025306 for <[e-mail]>; Wed, 26 Nov 2003 06:53:05 -0800 (PST) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id hAQEqcsj016166; Wed, 26 Nov 2003 09:52:39 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p06010201bbea6cf53279@[128.89.89.75]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Wed, 26 Nov 2003 09:49:16 -0500
To: [e-mail] (Peter Gutmann)
From: Stephen Kent <[e-mail]>
Subject: Re: Certificate Policy Standardization
Cc: [e-mail], [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-OriginalArrivalTime: 26 Nov 2003 16:25:53.0566 (UTC) FILETIME=[F658DBE0:01C3B439]
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 19:07 +1300 11/26/03, Peter Gutmann wrote:
>Stephen Kent <[e-mail]> writes:
>
>>Note that with the advent of 3280, we decided to let protocols that are PKI
>>clients define extended key usage options for themselves.
>
>I recently had to deal with someone who's working with certs from (at least)
>two difference (largeish) public CAs.  One CA turned the eKU into a kind of
>lamp test packet, with every usage they could think of set ("Let's see, what
>have we got here... timestamping, IPsec, encrypted filesystem, Win2K logon,
>and S/MIME, that sounds like a sensible combination of usages for a private
>key").  The other CA didn't populate the eKU at all, justifying it with
>"Everything ignores those anyway, so it doesn't matter what you put in there"
>(obviously they have to ignore them, in order to allow certs like the ones I'm
>describing to function).  In the end after taking legal considerations into
>account the conclusion was to define a new eKU, "doWhatISay", defined as "This
>key may only be used as we say it can be used" (it's not quite worded like
>that in their CPS, that'll take another six months for the lawyers to sort
>out).
>
>I dunno about the situation in the PKIX reality, but in the real world from
>the legal point of view (which is what matters in the end) that's about the
>best way to make use of eKU.
>
>Peter.

Your example is one in which CAs chose to make up their own, private 
EKUs. This is certainly allowed, but it is not what I said we had 
decided to do in the IETF, where we would expect EKU OIDs to be 
standardized by the cognizant WGs for the protocols with which the 
certs are used.

Also, you claim that what matters in the end is what "the legal point 
of view" says.  This is certainly true in some contexts, but not all 
certs are used in ways that have legal ramifications of the sort you 
imply. For example, most certs used with IKE will not be subject to 
some attorney's advice, I suspect.

Steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9rfib086502 for <[e-mail]>; Fri, 28 Nov 2003 01:53:41 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAS9rfvZ086501 for ietf-pkix-bks; Fri, 28 Nov 2003 01:53:41 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from relhubc02-ukbr.tcrelay.net ([217.32.166.20]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9rcid086487 for <[e-mail]>; Fri, 28 Nov 2003 01:53:40 -0800 (PST) (envelope-from [e-mail])
Received: from mail pickup service by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC; Fri, 28 Nov 2003 09:47:50 +0000
Received: from above.proper.com ([208.184.76.39]) by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 26 Nov 2003 16:24:53 +0000
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQFDJib026445 for <[e-mail]>; Wed, 26 Nov 2003 07:13:19 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQFDJpE026444 for ietf-pkix-bks; Wed, 26 Nov 2003 07:13:19 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail4.it-norr.com ([80.244.64.43]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQFDHib026437 for <[e-mail]>; Wed, 26 Nov 2003 07:13:17 -0800 (PST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Received: from HANSTOSHIBA ([217.211.59.248]) by mail4.it-norr.com (IT-NORR Mail Cluster v2003) with ASMTP id DUA74354 for <[e-mail]>; Wed, 26 Nov 2003 16:13:15 +0100
From: "Hans Nilsson" <[e-mail]>
To: <[e-mail]>
Subject: RE: Certificate Policy Standardization
Date: Wed, 26 Nov 2003 16:12:53 +0100
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.2800.1165
thread-index: AcO0KecT/TLEeVeFQcqZodb6XFOSFQABQ0Gw
In-Reply-To: <025b01c3b421$683107b0$0500a8c0@arport>
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-OriginalArrivalTime: 26 Nov 2003 16:25:52.0129 (UTC) FILETIME=[F57D9710:01C3B439]
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 know of at least one CA product (SmartTrust Certificate Manager) which can
supports multiple issuance of certs (with different CPs) per CA root.

I know that this feature also is used by several of SmartTrust's customers,
for example for distinguishing between different issuing procedures and/or
private key storage media.

And when talking about Relying Party software, we do not usually mean
Outlook Express. After all, secure e-mail is not the number 1 PKI
application. 
Instead, RPs are usually servers, validating signatures in e-government and
e-banking applications. And RP software (from MS and others) can pick out
any field of a certificate and make a decision based on that.

Hans

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
On
> Behalf Of Anders Rundgren
> Sent: Wednesday, November 26, 2003 2:30 PM
> To: [e-mail]
> Subject: Re: Certificate Policy Standardization
> 
> 
> Hum,
> 
> I wonder how many times I have to repeat the same very basic
> questions and only getting answers back in "ASN.1"?  Sort of.
> So here we go again...
> 
> 1. Why does practically no shrink-wrap PKI-enabled software
> package support any kind of certificate policy settings?
> 
> 2. And why do few if any commercial CAs support multiple
> issuances (i.e. different CPs) per CA root?
> 
> Because they have understood the problems associated?
> Because they enjoy "violating" standards?
> Because they are ignorant?
> Because their budget is too limited?
> Other?
> 
> Anders
> 
> ----- Original Message -----
> From: "Santosh Chokhani" <[e-mail]>
> To: <[e-mail]>
> Sent: Wednesday, November 26, 2003 12:04
> Subject: RE: Certificate Policy Standardization
> 
> 
> 
> Anders:
> 
> The relying parties are free to ignore the policies and policy related
> extensions altogether and verify paths.  The certification path will
verify
> unless:
> 
> 1.  One or more CAs in the path require that the certification path be
valid
> for a policy; or
> 
> 2.  Make the policy related extensions critical.
> 
> While some may view the two conditions as interoperability problem, I view
> it CA(s) saying that I do not want you to use the certificate unless you
> understand and abide by constraints I impose on the certificates.
> 
> The current X.509 and RFC 3280 permit you build PKI and applications that
do
> not use certificate policies.  So, I do not quite understand your concern
> below.
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
On
> Behalf Of Anders Rundgren
> Sent: Wednesday, November 26, 2003 4:03 AM
> To: Santosh Chokhani; [e-mail]
> Subject: Re: Certificate Policy Standardization
> 
> 
> 
> 
> >I am not what you mean by ".....another useless PKIX bloat extension".
> 
> >If properly used by the CA and relying party systems, the certificate
> >policy OID can be used to provide amount of trust the relying party
> >should place in a certificate.
> 
> What Michael referred to as "bloat" is not policy identifiers themselves
but
> that they need another trust adminstration GUI and associated hassles.
> 
> Policy identifiers used for path validation purposes is indeed a very
> "fancy" thing from a technical point of view (maybe 2% of the people
> subscribed to the PKIX list can understand this part of RFC3280...), but
> from an interoperability point of view they are not that great.
> 
> Hum, there simply must be a reason why practically all commercial CAs have
> selected an entirely different approach.  And that they did this
completely
> on their own without any commitee descision etc.
> 
> I wonder how this really happend.   Could it be...
> 
>     that it sort of feels "natural"?
> 
> /a
> 





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9reib086495 for <[e-mail]>; Fri, 28 Nov 2003 01:53:40 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAS9rdXt086494 for ietf-pkix-bks; Fri, 28 Nov 2003 01:53:39 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from relhubc02-ukbr.tcrelay.net ([217.32.166.20]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9rcib086487 for <[e-mail]>; Fri, 28 Nov 2003 01:53:39 -0800 (PST) (envelope-from [e-mail])
Received: from mail pickup service by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC; Fri, 28 Nov 2003 09:47:44 +0000
Received: from above.proper.com ([208.184.76.39]) by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 26 Nov 2003 16:46:18 +0000
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQFZ3ib027684 for <[e-mail]>; Wed, 26 Nov 2003 07:35:03 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQFZ31R027683 for ietf-pkix-bks; Wed, 26 Nov 2003 07:35:03 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail4.consignia.com (mail4.consignia.com [144.87.143.84]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQFZ2ib027677 for <[e-mail]>; Wed, 26 Nov 2003 07:35:03 -0800 (PST) (envelope-from [e-mail])
Received: from postoffice.co.uk (mta2.int.consignia.com [144.87.146.16]) by mail4.consignia.com (Postfix) with SMTP id 724821221FE; Wed, 26 Nov 2003 15:35:03 +0000 (GMT)
Received: by postoffice.co.uk(Lotus SMTP MTA v4.6.6  (890.1 7-16-1999))  id 00256DEA.00559D17 ; Wed, 26 Nov 2003 15:35:07 +0000
X-Lotus-FromDomain: POSTOFFICE
From: [e-mail]
To: "Anders Rundgren" <[e-mail]>
Cc: [e-mail]
Message-ID: <[e-mail]>
Date: Wed, 26 Nov 2003 15:34:52 +0000
Subject: Re: Certificate Policy Standardization
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-OriginalArrivalTime: 26 Nov 2003 16:47:00.0925 (UTC) FILETIME=[E9C07ED0:01C3B43C]
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>

> 1. Why does practically no shrink-wrap PKI-enabled software
> package support any kind of certificate policy settings?

My experiences with so far 4 different PKI 'systems' are that
all of them could implement CP but only one did so out-of-the-box.
I feel very strongly that the vanilla deployment is one
that supports a homogeneous environment and does not take into
account interop with other PKIs. This is likely to be caused
by a number of factors including a desire to steer the end
user away from competitors, saving money in deploying unrequired
features and keeping the vanilla deployment as simple as possible
(if that is possible with PKI!!!). Given the current lack of
support for CP it does not surprise me that it is not part of
the vanilla deployment.

> 2. And why do few if any commercial CAs support multiple
> issuances (i.e. different CPs) per CA root?

Differentiate between 'cannot' and 'do not'. I would be very
surprised if they all cannot but I am not surprised that they
all do not (if that makes sense). Application of CP is, as you
have already said, a function of RP s/w. Commercial CAs issue
certificates to anyone who wants them yet CP is function of
local, company policy. Why should a commercial CA issue certs
with my CP in them (unless I pay them to do so)? As I see it,
at present a commercial CA will issue a CP which says no more
than 'this is my CP'. Third party s/w has no reason to enforce
this CP because it is private to the CA. When apps become
more security aware I will expect to see them enforce CP issued
from the corporate CA or from other Xcert CAs mapped through
policyMap.

Don't ask me when this will happen, though :-)

Chris




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9rWib086485 for <[e-mail]>; Fri, 28 Nov 2003 01:53:32 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAS9rWig086484 for ietf-pkix-bks; Fri, 28 Nov 2003 01:53:32 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from relhubc02-ukbr.tcrelay.net ([217.32.166.20]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9rUib086478 for <[e-mail]>; Fri, 28 Nov 2003 01:53:31 -0800 (PST) (envelope-from [e-mail])
Received: from mail pickup service by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC; Fri, 28 Nov 2003 09:47:36 +0000
Received: from above.proper.com ([208.184.76.39]) by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 26 Nov 2003 15:05:59 +0000
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQF31ib025846 for <[e-mail]>; Wed, 26 Nov 2003 07:03:01 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQF31Fi025845 for ietf-pkix-bks; Wed, 26 Nov 2003 07:03:01 -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.10/8.12.8) with ESMTP id hAQF30ib025837 for <[e-mail]>; Wed, 26 Nov 2003 07:03:00 -0800 (PST) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id hAQF2tsj016901; Wed, 26 Nov 2003 10:02:56 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p06010204bbea6fb4d743@[128.89.89.75]>
In-Reply-To: <009e01c3b40d$329bed40$0500a8c0@arport>
References: <009e01c3b40d$329bed40$0500a8c0@arport>
Date: Wed, 26 Nov 2003 09:57:09 -0500
To: "Anders Rundgren" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Da Capo: Re: Certificate Policy Standardization
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-OriginalArrivalTime: 26 Nov 2003 15:05:59.0695 (UTC) FILETIME=[CCFA31F0:01C3B42E]
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 +0100 11/26/03, Anders Rundgren wrote:
>  >Policy OIDs might come handy to protect RPs from issuing authorities who
>>might seek to alter their terms arbitrarily without necessarily providing
>>notice to that effect. In practice, ambiguity over the exact content of
>>applicable policy might render that CP unenforceable.
>
>When I read a statement like above, I get really sad and begin
>to completely lose faith in the PKI technology [1], wondering
>if I maybe should go and waste my talent on something useful
>for a change.
>

Promises, promises ...


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9r9ib086469 for <[e-mail]>; Fri, 28 Nov 2003 01:53:09 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAS9r9w4086468 for ietf-pkix-bks; Fri, 28 Nov 2003 01:53:09 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from relhubc02-ukbr.tcrelay.net ([217.32.166.20]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9r7ib086462 for <[e-mail]>; Fri, 28 Nov 2003 01:53:07 -0800 (PST) (envelope-from [e-mail])
Received: from mail pickup service by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC; Fri, 28 Nov 2003 09:47:12 +0000
Received: from above.proper.com ([208.184.76.39]) by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 26 Nov 2003 20:06:25 +0000
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQK2Uib041331 for <[e-mail]>; Wed, 26 Nov 2003 12:02:30 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQK2UGu041330 for ietf-pkix-bks; Wed, 26 Nov 2003 12:02:30 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQK2Sib041323 for <[e-mail]>; Wed, 26 Nov 2003 12:02:28 -0800 (PST) (envelope-from [e-mail])
Received: from MMyersLapTop ([65.39.77.99]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id hAQK2UA79456; Wed, 26 Nov 2003 13:02:30 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: <[e-mail]>
Cc: "Carlisle Adams" <[e-mail]>
Subject: DISCUSS:  MUST  reject in OCSPv1
Date: Wed, 26 Nov 2003 13:04:42 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1106
In-Reply-To: <p06010205bbea7029f2b0@[128.89.89.75]>
Importance: Normal
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-OriginalArrivalTime: 26 Nov 2003 20:06:26.0132 (UTC) FILETIME=[C5923140:01C3B458]
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>

Colleagues,

I recently proposed to the chairs and the AD the following
action plan with respect to nonces in OCSP.  They in turn remain
curious as to working group consensus on the subject with a
particular emphasis on objections.  I had hoped for an ad-hoc
quorum on this in Minneapolis but it never materialized due to
the absence of several key players.

So, once more into the breach.  Who would object and why to the
following action plan (silence WILL be taken as consent):

1.  Regarding v1, clarify per the minutes as
    2560 goes from Proposed to Draft.  The
    operative text of which is that clients
    MUST reject a response that fails to
    incorporate a client's nonce.

2.  Simultaneously, initiate action on a v2
    I-D that will in part address technical
    changes in syntax and processing rules
    related to the use of nonces.

This is not a poll.  It is a request for discussion.  I expect
little disagreement on the intent of the v2 action item. The
core issue on v1 is "MUST reject".

To initiate the v1 discussion, my opinions are as follows.

1.  Nonces were established in OCSP to enable
    client driven prevention of replay attacks.
    Failure to respect a client's nonce is a
    direct denial of a client's request for
    this security service.  A responder that
    does so is contributing to the very security
    risks the requestor is seeking to mitigate.

2.  While 2560 also enables use of pre-produced
    responses, nonces and pre-produced responses
    are by definition mutually exclusive.  This
    effect should be immediately obvious to even
    the most naive of implementors, else they have
    no business writing code against this standard.
    A competent level of technical proficiency
    in implementing secure protocols is assumed.

3.  The "breakage" poll indicates that an
    overwhelming majority of OCSP implementors
    possess this competency.  11 of 12 client-side
    implementors reported no breakage with
    "MUST reject" while 10 of 12 server-side
    implementors responded likewise.

4.  The two server-side breakage points occur
    as a consequence of their use of pre-produced
    responses in a context where they have no
    administrative control over clients' use of
    nonces.  This can be addressed in v2, but in
    a v1 context we have no choice but to clarify
    original intent as ratified by the breakage poll.
    This breakage could also be relieved by relay
    of OCSP requests.

5.  The absence of normative language providing a
    tutorial on the proper use of nonces in a
    security protocol SHOULD NOT be taken up by
    any participant in this WG as an excuse to
    refute sound security principles.  Active
    participants in the Security Area of the IETF
    should be able to assume of their peers a
    superior grasp of and respect for foundational
    principles.

Objections to the "MUST reject" clarification are sought on the
basis of sound security engineering principles rather than
artful readings of ancillary language that enable specious
excuse from adherence to these principles in order to justify
current business models.

We are setting standards that must survive the test of time.  We
are supposed to check our corporate identities at the door.  We
are supposed to be individual engineers chartered to improve
Internet security.  Let us do so and get this problem solved.

My thanks to you all in advance for your patience with the
length of this note.


Mike




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9qRib086449 for <[e-mail]>; Fri, 28 Nov 2003 01:52:27 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAS9qRSS086448 for ietf-pkix-bks; Fri, 28 Nov 2003 01:52:27 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from relhubc02-ukbr.tcrelay.net ([217.32.166.20]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9qOid086434 for <[e-mail]>; Fri, 28 Nov 2003 01:52:25 -0800 (PST) (envelope-from [e-mail])
Received: from mail pickup service by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC; Fri, 28 Nov 2003 09:46:28 +0000
Received: from above.proper.com ([208.184.76.39]) by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 26 Nov 2003 16:45:34 +0000
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQFXXib027570 for <[e-mail]>; Wed, 26 Nov 2003 07:33:33 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQFXXdQ027569 for ietf-pkix-bks; Wed, 26 Nov 2003 07:33:33 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.cs.auckland.ac.nz (csmail.cs.auckland.ac.nz [130.216.33.150]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQFXVib027563 for <[e-mail]>; Wed, 26 Nov 2003 07:33:32 -0800 (PST) (envelope-from [e-mail])
Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id 80B7463C1D; Thu, 27 Nov 2003 04:33:32 +1300 (NZDT)
Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id hAQFa4Y01319; Thu, 27 Nov 2003 04:36:04 +1300
Date: Thu, 27 Nov 2003 04:36:04 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Certificate Policy Standardization
Cc: [e-mail]
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-OriginalArrivalTime: 26 Nov 2003 16:46:13.0129 (UTC) FILETIME=[CD436790:01C3B43C]
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>

Andreas Mitrakas <[e-mail]> writes:

>Especially so in some implementations in Europe where there is a direct link
>between the policy and the law under which certain certs like QC certs are
>issued.

The feeling was that digital signature legislation (following the UNCITRAL
model) is so vaguely worded that this wouldn't be a problem.  Qualified certs
are a bit more problematic, but that's only in Europe.

>A CP becomes part of the parties agreement and binding by means of e.g. a
>subscriber agreement. So it is not unthinkable albeit not necessarily
>desirable, that a courts might  scrutinise policies. --God forbid.

The feeling here was that a ToS-style policy might violate (at least NZ)
consumer protection legislation, however since a number of large organisations
relied on these types of agreements there would probably be a spirited defence
of them in court and/or existing case law upholding them.  See e.g Xtra
(Telecom NZ ISP) terms, which state:

  12. Changes to these Customer Terms

  We may change these Customer Terms by changing or removing existing terms,
  or by adding new ones. Changes may take the form of completely new terms.

  [Notification stuff snipped]

  A copy of our current terms is displayed on our Website. It is your
  responsibility to check these Customer Terms regularly (at least monthly)
  for any modifications or updates. You will be deemed to have accepted the
  changes to these Customer Terms and to have agreed to be bound by the
  revised Customer Terms if you continue to use and/or access the Services
  after the date that the changes are stated to be effective.

  We reserve the right to change any charges or Services, or any Separate
  Terms, at any time without notice. It is your responsibility to check all
  applicable Separate Terms regularly for any modifications or updates.

That's the sort of thing the "policy is what we say it is" that I mentioned
earlier was based on.  Just for reference, here's what Yahoo says:

  Yahoo! provides its service to you, subject to the following Terms of
  Service ("TOS"), which may be updated by us from time to time without notice
  to you. You can review the most current version of the TOS at any time at:
  http://docs.yahoo.com/info/terms/. 
  
  [Snippage]

  Yahoo! reserves the right at any time and from time to time to modify or
  discontinue, temporarily or permanently, the Service (or any part thereof)
  with or without notice. You agree that Yahoo! shall not be liable to you or
  to any third party for any modification, suspension or discontinuance of the
  Service.

The debate then went off on a tangent about whether a PKI was providing a
service of any value to a user (if it doesn't it's not covered by standard
consumer-protection law), and how you'd present that in court.

Disclaimer: IANAL, I just talk to them occasionally.

Peter.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9qPib086441 for <[e-mail]>; Fri, 28 Nov 2003 01:52:25 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAS9qPpZ086440 for ietf-pkix-bks; Fri, 28 Nov 2003 01:52:25 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from relhubc02-ukbr.tcrelay.net ([217.32.166.20]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9qOib086434 for <[e-mail]>; Fri, 28 Nov 2003 01:52:24 -0800 (PST) (envelope-from [e-mail])
Received: from mail pickup service by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC; Fri, 28 Nov 2003 09:46:26 +0000
Received: from above.proper.com ([208.184.76.39]) by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 26 Nov 2003 16:09:46 +0000
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQF31ib025846 for <[e-mail]>; Wed, 26 Nov 2003 07:03:01 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQF31Fi025845 for ietf-pkix-bks; Wed, 26 Nov 2003 07:03:01 -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.10/8.12.8) with ESMTP id hAQF30ib025837 for <[e-mail]>; Wed, 26 Nov 2003 07:03:00 -0800 (PST) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id hAQF2tsj016901; Wed, 26 Nov 2003 10:02:56 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p06010204bbea6fb4d743@[128.89.89.75]>
In-Reply-To: <009e01c3b40d$329bed40$0500a8c0@arport>
References: <009e01c3b40d$329bed40$0500a8c0@arport>
Date: Wed, 26 Nov 2003 09:57:09 -0500
To: "Anders Rundgren" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Da Capo: Re: Certificate Policy Standardization
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-OriginalArrivalTime: 26 Nov 2003 16:09:46.0800 (UTC) FILETIME=[B61C1300:01C3B437]
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 +0100 11/26/03, Anders Rundgren wrote:
>  >Policy OIDs might come handy to protect RPs from issuing authorities who
>>might seek to alter their terms arbitrarily without necessarily providing
>>notice to that effect. In practice, ambiguity over the exact content of
>>applicable policy might render that CP unenforceable.
>
>When I read a statement like above, I get really sad and begin
>to completely lose faith in the PKI technology [1], wondering
>if I maybe should go and waste my talent on something useful
>for a change.
>

Promises, promises ...


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9phib086416 for <[e-mail]>; Fri, 28 Nov 2003 01:51:43 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAS9phE5086415 for ietf-pkix-bks; Fri, 28 Nov 2003 01:51:43 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from relhubc02-ukbr.tcrelay.net ([217.32.166.20]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9pgib086406 for <[e-mail]>; Fri, 28 Nov 2003 01:51:42 -0800 (PST) (envelope-from [e-mail])
Received: from mail pickup service by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC; Fri, 28 Nov 2003 09:45:47 +0000
Received: from above.proper.com ([208.184.76.39]) by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 26 Nov 2003 17:42:26 +0000
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQHbnib034140 for <[e-mail]>; Wed, 26 Nov 2003 09:37:49 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQHbmO8034139 for ietf-pkix-bks; Wed, 26 Nov 2003 09:37:48 -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.10/8.12.8) with ESMTP id hAQHblib034129 for <[e-mail]>; Wed, 26 Nov 2003 09:37:47 -0800 (PST) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id hAQHbesj027338; Wed, 26 Nov 2003 12:37:41 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p06010210bbea90868896@[128.89.89.75]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Wed, 26 Nov 2003 12:33:48 -0500
To: [e-mail] (Peter Gutmann)
From: Stephen Kent <[e-mail]>
Subject: Re: Certificate Policy Standardization
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-OriginalArrivalTime: 26 Nov 2003 17:42:39.0129 (UTC) FILETIME=[AF7A0090:01C3B444]
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 5:59 +1300 11/27/03, Peter Gutmann wrote:
>Stephen Kent <[e-mail]> writes:
>
>>one might ask why the most widely distributed product that claims to
>>implement IPsec  (Windows) does not provide a user/administrator the ability
>>to order SPD entries, as required by RFC 2401. The answer is that the
>>implementors did not understand why this was an important (in the case of
>>IPsec, a critical) aspect of the standard and so the implementors omitted an
>>important management control.
>>
>>what one can learn from this an similar examples is that vendors are a very
>>poor basis for determining the worth of a feature in a standard.
>
>Actually what I learn from this is that complex standards with often
>incomprehensible requirements are just asking for trouble if they don't
>include a rationale.  Even a single sentence explaining the background behind
>the SPD entry ordering would have prevented this in a manner that no amount of
>MUSTs/SHALLs ever can.
>
>Peter.

The SPD is an ordered list for the same reason that ACLs have been 
ordered in operating systems for last 30 years, and in firewalls and 
routers for the last decade.  At what point does one not have to 
provide rationale?

Implementors of a technology ought (MUST/SHALL?) be competent in the 
technology that they are implementing. A standard like IPsec is not a 
"Secure Communication  Protocols for Dummies" document.

Steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9pXib086404 for <[e-mail]>; Fri, 28 Nov 2003 01:51:33 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAS9pXeE086403 for ietf-pkix-bks; Fri, 28 Nov 2003 01:51:33 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from relhubc02-ukbr.tcrelay.net ([217.32.166.20]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9pVib086391 for <[e-mail]>; Fri, 28 Nov 2003 01:51:31 -0800 (PST) (envelope-from [e-mail])
Received: from mail pickup service by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC; Fri, 28 Nov 2003 09:45:36 +0000
Received: from above.proper.com ([208.184.76.39]) by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 26 Nov 2003 16:16:25 +0000
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQFC7ib026381 for <[e-mail]>; Wed, 26 Nov 2003 07:12:07 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQFC7vJ026380 for ietf-pkix-bks; Wed, 26 Nov 2003 07:12:07 -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.10/8.12.8) with ESMTP id hAQFC5ib026372 for <[e-mail]>; Wed, 26 Nov 2003 07:12:06 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (127.0.0.1) by nic.lp.se (MX V5.3 VnHj) with ESMTP; Wed, 26 Nov 2003 16:12:04 +0100
Date: Wed, 26 Nov 2003 16:12:03 +0100 (CET)
Message-ID: <[e-mail]>
To: [e-mail]
CC: [e-mail]
Subject: Re: Certificate Policy Standardization
From: Richard Levitte - VMS Whacker <[e-mail]>
In-Reply-To: <025b01c3b421$683107b0$0500a8c0@arport>
References: <033e01c3b40d$0b962670$[e-mail]> <025b01c3b421$683107b0$0500a8c0@arport>
X-URL: http://www.lp.se/
X-Waved: dead chicken, GNU emacs 21.3.1, Mew version 4.0.60
X-Mew: See http://www.mew.org/
X-Mailer: Mew version 4.0.60 on Emacs 21.3.1 / Mule 5.0 (SAKAKI)
MIME-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-OriginalArrivalTime: 26 Nov 2003 16:17:15.0269 (UTC) FILETIME=[C16B0350:01C3B438]
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 <025b01c3b421$683107b0$0500a8c0@arport> on Wed, 26 Nov 2003 14:30:06 +0100, "Anders Rundgren" <[e-mail]> said:

anders.rundgren> I wonder how many times I have to repeat the same
anders.rundgren> very basic questions and only getting answers back in
anders.rundgren> "ASN.1"?  Sort of.  So here we go again...
anders.rundgren> 
anders.rundgren> 1. Why does practically no shrink-wrap PKI-enabled
anders.rundgren>    software package support any kind of certificate
anders.rundgren>    policy settings?
anders.rundgren> 
anders.rundgren> 2. And why do few if any commercial CAs support
anders.rundgren>    multiple issuances (i.e. different CPs) per CA
anders.rundgren>    root?
anders.rundgren> 
anders.rundgren> Because they have understood the problems associated?
anders.rundgren> Because they enjoy "violating" standards?
anders.rundgren> Because they are ignorant?
anders.rundgren> Because their budget is too limited?
anders.rundgren> Other?

Because they won't bother implementing something that a customer
hasn't asked for specifically.

I have literaly heard the sentence "Yeah, it would probably be useful
and might increase the value of our product, but no customer has said
they wanted or needed this, so we'll wait for that to happen".  And
this was for a product that had a lot to do with security.  It wasn't
about policy OIDs back then, but something similar enough.

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.
You don't have to be rich, a $10 donation is appreciated!

-- 
Richard Levitte     | http://richard.levitte.org/ | Tunnlandsv. 3
Levitte Programming | http://www.lp.se/           | S-168 36 Bromma
T: [phone] |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9oiib086371 for <[e-mail]>; Fri, 28 Nov 2003 01:50:44 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAS9oiCt086370 for ietf-pkix-bks; Fri, 28 Nov 2003 01:50:44 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from relhubc02-ukbr.tcrelay.net ([217.32.166.20]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9ogib086350 for <[e-mail]>; Fri, 28 Nov 2003 01:50:43 -0800 (PST) (envelope-from [e-mail])
Received: from mail pickup service by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC; Fri, 28 Nov 2003 09:44:48 +0000
Received: from above.proper.com ([208.184.76.39]) by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 26 Nov 2003 18:39:05 +0000
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQHbnib034140 for <[e-mail]>; Wed, 26 Nov 2003 09:37:49 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQHbmO8034139 for ietf-pkix-bks; Wed, 26 Nov 2003 09:37:48 -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.10/8.12.8) with ESMTP id hAQHblib034129 for <[e-mail]>; Wed, 26 Nov 2003 09:37:47 -0800 (PST) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id hAQHbesj027338; Wed, 26 Nov 2003 12:37:41 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p06010210bbea90868896@[128.89.89.75]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Wed, 26 Nov 2003 12:33:48 -0500
To: [e-mail] (Peter Gutmann)
From: Stephen Kent <[e-mail]>
Subject: Re: Certificate Policy Standardization
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-OriginalArrivalTime: 26 Nov 2003 18:39:06.0164 (UTC) FILETIME=[924E8740:01C3B44C]
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 5:59 +1300 11/27/03, Peter Gutmann wrote:
>Stephen Kent <[e-mail]> writes:
>
>>one might ask why the most widely distributed product that claims to
>>implement IPsec  (Windows) does not provide a user/administrator the ability
>>to order SPD entries, as required by RFC 2401. The answer is that the
>>implementors did not understand why this was an important (in the case of
>>IPsec, a critical) aspect of the standard and so the implementors omitted an
>>important management control.
>>
>>what one can learn from this an similar examples is that vendors are a very
>>poor basis for determining the worth of a feature in a standard.
>
>Actually what I learn from this is that complex standards with often
>incomprehensible requirements are just asking for trouble if they don't
>include a rationale.  Even a single sentence explaining the background behind
>the SPD entry ordering would have prevented this in a manner that no amount of
>MUSTs/SHALLs ever can.
>
>Peter.

The SPD is an ordered list for the same reason that ACLs have been 
ordered in operating systems for last 30 years, and in firewalls and 
routers for the last decade.  At what point does one not have to 
provide rationale?

Implementors of a technology ought (MUST/SHALL?) be competent in the 
technology that they are implementing. A standard like IPsec is not a 
"Secure Communication  Protocols for Dummies" document.

Steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9mfib086302 for <[e-mail]>; Fri, 28 Nov 2003 01:48:41 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAS9mfdC086301 for ietf-pkix-bks; Fri, 28 Nov 2003 01:48:41 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from relhubc02-ukbr.tcrelay.net ([217.32.166.20]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9meib086296 for <[e-mail]>; Fri, 28 Nov 2003 01:48:40 -0800 (PST) (envelope-from [e-mail])
Received: from mail pickup service by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC; Fri, 28 Nov 2003 09:42:45 +0000
Received: from above.proper.com ([208.184.76.39]) by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 26 Nov 2003 16:29:15 +0000
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQF7kib026184 for <[e-mail]>; Wed, 26 Nov 2003 07:07:46 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQF7kno026183 for ietf-pkix-bks; Wed, 26 Nov 2003 07:07:46 -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.10/8.12.8) with ESMTP id hAQF7jib026174 for <[e-mail]>; Wed, 26 Nov 2003 07:07:45 -0800 (PST) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id hAQF7esj017220; Wed, 26 Nov 2003 10:07:40 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p06010205bbea7029f2b0@[128.89.89.75]>
In-Reply-To: <025b01c3b421$683107b0$0500a8c0@arport>
References: <033e01c3b40d$0b962670$[e-mail]> <025b01c3b421$683107b0$0500a8c0@arport>
Date: Wed, 26 Nov 2003 10:06:41 -0500
To: "Anders Rundgren" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Certificate Policy Standardization
Cc: <[e-mail]>
Content-Type: multipart/alternative; boundary="============_-1142263285==_ma============"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-OriginalArrivalTime: 26 Nov 2003 16:29:55.0363 (UTC) FILETIME=[86782730:01C3B43A]
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>

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

At 14:30 +0100 11/26/03, Anders Rundgren wrote:
>Hum,
>
>I wonder how many times I have to repeat the same very basic
>questions and only getting answers back in "ASN.1"?  Sort of.
>So here we go again...
>
>1. Why does practically no shrink-wrap PKI-enabled software
>package support any kind of certificate policy settings?

one might ask why the most widely distributed product that claims to 
implement IPsec  (Windows) does not provide a user/administrator the 
ability to order SPD entries, as required by RFC 2401. The answer is 
that the implementors did not understand why this was an important 
(in the case of IPsec, a critical) aspect of the standard and so the 
implementors omitted an important management control.

what one can learn from this an similar examples is that vendors are 
a very poor basis for determining the worth of a feature in a 
standard. a very big vendor can screw up an implementation and get 
away with it due to market dominance. other vendors, eager to be 
compatible with the dominant vendor, follow suit.  most users may not 
understand a complex technology and don't know what's missing.

>2. And why do few if any commercial CAs support multiple
>issuances (i.e. different CPs) per CA root?
>
>Because they have understood the problems associated?

sometimes, but rarely, in my experience.

>Because they enjoy "violating" standards?

"enjoy" is probably the wrong term, but "don't care" is accurate.

>Because they are ignorant?

sometimes, yes!

>Because their budget is too limited?

prioritization of development resources, combined with time to market 
pressure is often the reason that a vendor omits certain features.

>Other?

yes, you left out implementors who have decided that in the market 
niche of interest to them, they have a "better" way of implementing a 
capability that is incompatible with the standard and so they pursue 
their proprietary approach.

Steve
--============_-1142263285==_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: Certificate Policy
Standardization</title></head><body>
<div>At 14:30 +0100 11/26/03, Anders Rundgren wrote:</div>
<blockquote type="cite" cite>Hum,<br>
<br>
I wonder how many times I have to repeat the same very basic<br>
questions and only getting answers back in &quot;ASN.1&quot;?&nbsp;
Sort of.<br>
So here we go again...<br>
<br>
1. Why does practically no shrink-wrap PKI-enabled software<br>
package support any kind of certificate policy settings?</blockquote>
<div><br></div>
<div>one might ask why the most widely distributed product that claims
to implement IPsec&nbsp; (Windows) does not provide a
user/administrator the ability to order SPD entries, as required by
RFC 2401. The answer is that the implementors did not understand why
this was an important (in the case of IPsec, a<u> critical</u>) aspect
of the standard and so the implementors omitted an important
management control.</div>
<div><br></div>
<div>what one can learn from this an similar examples is that vendors
are a very poor basis for determining the worth of a feature in a
standard. a very big vendor can screw up an implementation and get
away with it due to market dominance. other vendors, eager to be
compatible with the dominant vendor, follow suit.&nbsp; most users may
not understand a complex technology and don't know what's
missing.</div>
<div><br></div>
<blockquote type="cite" cite>2. And why do few if any commercial CAs
support multiple<br>
issuances (i.e. different CPs) per CA root?<br>
<br>
Because they have understood the problems associated?</blockquote>
<div><br>
sometimes, but rarely, in my experience.<br>
</div>
<blockquote type="cite" cite>Because they enjoy &quot;violating&quot;
standards?</blockquote>
<div><br></div>
<div>&quot;enjoy&quot; is probably the wrong term, but &quot;don't
care&quot; is accurate.</div>
<div><br></div>
<blockquote type="cite" cite>Because they are ignorant?</blockquote>
<div><br></div>
<div>sometimes, yes!</div>
<div><br></div>
<blockquote type="cite" cite>Because their budget is too
limited?</blockquote>
<div><br></div>
<div>prioritization of development resources, combined with time to
market pressure is often the reason that a vendor omits certain
features.</div>
<div><br></div>
<blockquote type="cite" cite>Other?</blockquote>
<div><br></div>
<div>yes, you left out implementors who have decided that in the
market niche of interest to them, they have a &quot;better&quot; way
of implementing a capability that is incompatible with the standard
and so they pursue their proprietary approach.</div>
<div><br></div>
<div>Steve</div>
</body>
</html>
--============_-1142263285==_ma============--


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9mHib086289 for <[e-mail]>; Fri, 28 Nov 2003 01:48:17 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAS9mHhf086288 for ietf-pkix-bks; Fri, 28 Nov 2003 01:48:17 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from relhubc02-ukbr.tcrelay.net ([217.32.166.20]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9mFib086271 for <[e-mail]>; Fri, 28 Nov 2003 01:48:16 -0800 (PST) (envelope-from [e-mail])
Received: from mail pickup service by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC; Fri, 28 Nov 2003 09:42:21 +0000
Received: from above.proper.com ([208.184.76.39]) by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 26 Nov 2003 18:16:22 +0000
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQIBeib035761 for <[e-mail]>; Wed, 26 Nov 2003 10:11:40 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQIBeHC035760 for ietf-pkix-bks; Wed, 26 Nov 2003 10:11:40 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.cs.auckland.ac.nz (csmail.cs.auckland.ac.nz [130.216.33.150]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQIBcib035752 for <[e-mail]>; Wed, 26 Nov 2003 10:11:38 -0800 (PST) (envelope-from [e-mail])
Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id 45A3C63C1D; Thu, 27 Nov 2003 07:11:37 +1300 (NZDT)
Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id hAQIEA202922; Thu, 27 Nov 2003 07:14:10 +1300
Date: Thu, 27 Nov 2003 07:14:10 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Certificate Policy Standardization
Cc: [e-mail]
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-OriginalArrivalTime: 26 Nov 2003 18:16:22.0835 (UTC) FILETIME=[65B30830:01C3B449]
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>

Stephen Kent <[e-mail]> writes:

>Implementors of a technology ought (MUST/SHALL?) be competent in the
>technology that they are implementing. A standard like IPsec is not a "Secure
>Communication  Protocols for Dummies" document.

  The first thing one notices when looking at IPsec is that the documentation
  is very hard to understand. There is no overview or introduction, the reader
  has to assemble all the pieces and build an overview himself. This is a
  highly unsatisfactorily state of affairs; after all, the documentation is
  meant to convey information to the readers. We do not believe it is
  reasonable to expect anyone to learn IPsec from the IPsec documentation.
  Various parts of the IPsec documentation are very hard to read. For ex-
  ample, the ISAKMP specifications [MSST98] contain numerous errors, essential
  explanations are missing, and the document contradicts itself in various
  places.

  [...]
  
  None of the IPsec documentation provides any rationale for any of the
  choices that were made. Although this is somewhat less important than a
  clear statement of the goals, we nevertheless consider it crucial
  information. If a reviewer is to comment on the design (and RFCs are, after
  all, Requests For Comments), he should be told what each option was intended
  to achieve. Without any rationale, the reviewer is left to guess at it, and
  then review the design based on the guessed-at rationale.

  [...]
  
  In our opinion, IPsec is too complex to be secure. The design obviously
  tries to support many different situations with different options. We feel
  very strongly that the resulting system is well beyond the level of
  complexity that can be analysed or properly implemented with current method-
  ologies. Thus, no IPsec system will achieve the goal of providing a high
  level of security.

  [...]

  It is far too complex, and the complexity has lead to a large number of
  ambiguities, contradictions, inefficiencies, and weaknesses. It has been
  very hard work to perform any kind of security analysis; we do not feel that
  we fully understand the system, let alone have fully analyzed it.

Obviously non-dummies can't make much sense of it either.

Peter.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9m6ib086246 for <[e-mail]>; Fri, 28 Nov 2003 01:48:06 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAS9m6Kk086244 for ietf-pkix-bks; Fri, 28 Nov 2003 01:48:06 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from relhubc02-ukbr.tcrelay.net ([217.32.166.20]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9m4ib086205 for <[e-mail]>; Fri, 28 Nov 2003 01:48:05 -0800 (PST) (envelope-from [e-mail])
Received: from mail pickup service by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC; Fri, 28 Nov 2003 09:42:10 +0000
Received: from above.proper.com ([208.184.76.39]) by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 26 Nov 2003 16:50:20 +0000
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQGj9ib031373 for <[e-mail]>; Wed, 26 Nov 2003 08:45:09 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQGj9i0031372 for ietf-pkix-bks; Wed, 26 Nov 2003 08:45:09 -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.10/8.12.8) with ESMTP id hAQGj7ib031367 for <[e-mail]>; Wed, 26 Nov 2003 08:45:07 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (127.0.0.1) by nic.lp.se (MX V5.3 VnHj) with ESMTP; Wed, 26 Nov 2003 17:44:59 +0100
Date: Wed, 26 Nov 2003 17:44:58 +0100 (CET)
Message-ID: <[e-mail]>
To: [e-mail]
CC: [e-mail], [e-mail]
Subject: Re: Certificate Policy Standardization
From: Richard Levitte - VMS Whacker <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
X-URL: http://www.lp.se/
X-Waved: dead chicken, GNU emacs 21.3.1, Mew version 4.0.60
X-Mew: See http://www.mew.org/
X-Mailer: Mew version 4.0.60 on Emacs 21.3.1 / Mule 5.0 (SAKAKI)
MIME-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-OriginalArrivalTime: 26 Nov 2003 16:51:07.0863 (UTC) FILETIME=[7CF03E70:01C3B43D]
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 Thu, 27 Nov 2003 04:13:30 +1300, [e-mail] (Peter Gutmann) said:

pgut001> "Anders Rundgren" <[e-mail]> writes:
pgut001> 
pgut001> >1. Why does practically no shrink-wrap PKI-enabled software package support
pgut001> >any kind of certificate policy settings?
pgut001> 
pgut001> Zero demand.  Heck, it wasn't too long ago that MS PKI
pgut001> software hardcoded the Verisign policy into CryptoAPI, so
pgut001> that no matter what the actual policy was in the cert, what
pgut001> was displayed was the Verisign policy.  That shows how much
pgut001> attention people are paying to the policy stuff.

Let's take note of what Peter says here.  First, M$ did some
hardcoding, which they have subsequently changed (I got that right, I
hope).  That means M$ is capable of change, and does listen to some
concerns.  Sure, that's pretty slow development, but development
still.  A bunch more times with a LART, and even M$ might do policy
checks :-).

pgut001> ...  So the trusted-roots mechanism does what the policy
pgut001> extension is supposed to do,

Which only works as long as the formula CA<=>Policy is true...

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.
You don't have to be rich, a $10 donation is appreciated!

-- 
Richard Levitte     | http://richard.levitte.org/ | Tunnlandsv. 3
Levitte Programming | http://www.lp.se/           | S-168 36 Bromma
T: [phone] |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9lgib086103 for <[e-mail]>; Fri, 28 Nov 2003 01:47:42 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAS9lgg1086101 for ietf-pkix-bks; Fri, 28 Nov 2003 01:47:42 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from relhubc02-ukbr.tcrelay.net ([217.32.166.20]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9leib086064 for <[e-mail]>; Fri, 28 Nov 2003 01:47:41 -0800 (PST) (envelope-from [e-mail])
Received: from mail pickup service by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC; Fri, 28 Nov 2003 09:41:46 +0000
Received: from above.proper.com ([208.184.76.39]) by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 26 Nov 2003 15:38:30 +0000
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQFZ3ib027684 for <[e-mail]>; Wed, 26 Nov 2003 07:35:03 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQFZ31R027683 for ietf-pkix-bks; Wed, 26 Nov 2003 07:35:03 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail4.consignia.com (mail4.consignia.com [144.87.143.84]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQFZ2ib027677 for <[e-mail]>; Wed, 26 Nov 2003 07:35:03 -0800 (PST) (envelope-from [e-mail])
Received: from postoffice.co.uk (mta2.int.consignia.com [144.87.146.16]) by mail4.consignia.com (Postfix) with SMTP id 724821221FE; Wed, 26 Nov 2003 15:35:03 +0000 (GMT)
Received: by postoffice.co.uk(Lotus SMTP MTA v4.6.6  (890.1 7-16-1999))  id 00256DEA.00559D17 ; Wed, 26 Nov 2003 15:35:07 +0000
X-Lotus-FromDomain: POSTOFFICE
From: [e-mail]
To: "Anders Rundgren" <[e-mail]>
Cc: [e-mail]
Message-ID: <[e-mail]>
Date: Wed, 26 Nov 2003 15:34:52 +0000
Subject: Re: Certificate Policy Standardization
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-OriginalArrivalTime: 26 Nov 2003 15:38:31.0179 (UTC) FILETIME=[582705B0:01C3B433]
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>

> 1. Why does practically no shrink-wrap PKI-enabled software
> package support any kind of certificate policy settings?

My experiences with so far 4 different PKI 'systems' are that
all of them could implement CP but only one did so out-of-the-box.
I feel very strongly that the vanilla deployment is one
that supports a homogeneous environment and does not take into
account interop with other PKIs. This is likely to be caused
by a number of factors including a desire to steer the end
user away from competitors, saving money in deploying unrequired
features and keeping the vanilla deployment as simple as possible
(if that is possible with PKI!!!). Given the current lack of
support for CP it does not surprise me that it is not part of
the vanilla deployment.

> 2. And why do few if any commercial CAs support multiple
> issuances (i.e. different CPs) per CA root?

Differentiate between 'cannot' and 'do not'. I would be very
surprised if they all cannot but I am not surprised that they
all do not (if that makes sense). Application of CP is, as you
have already said, a function of RP s/w. Commercial CAs issue
certificates to anyone who wants them yet CP is function of
local, company policy. Why should a commercial CA issue certs
with my CP in them (unless I pay them to do so)? As I see it,
at present a commercial CA will issue a CP which says no more
than 'this is my CP'. Third party s/w has no reason to enforce
this CP because it is private to the CA. When apps become
more security aware I will expect to see them enforce CP issued
from the corporate CA or from other Xcert CAs mapped through
policyMap.

Don't ask me when this will happen, though :-)

Chris




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9krib085829 for <[e-mail]>; Fri, 28 Nov 2003 01:46:53 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAS9krbe085827 for ietf-pkix-bks; Fri, 28 Nov 2003 01:46:53 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from relhubc02-ukbr.tcrelay.net ([217.32.166.20]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9kpib085784 for <[e-mail]>; Fri, 28 Nov 2003 01:46:51 -0800 (PST) (envelope-from [e-mail])
Received: from mail pickup service by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC; Fri, 28 Nov 2003 09:40:56 +0000
Received: from above.proper.com ([208.184.76.39]) by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 26 Nov 2003 17:03:57 +0000
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQGvFib031847 for <[e-mail]>; Wed, 26 Nov 2003 08:57:15 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQGvFPk031846 for ietf-pkix-bks; Wed, 26 Nov 2003 08:57:15 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.cs.auckland.ac.nz (csmail.cs.auckland.ac.nz [130.216.33.150]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQGvEib031841 for <[e-mail]>; Wed, 26 Nov 2003 08:57:14 -0800 (PST) (envelope-from [e-mail])
Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id 5930863C1D; Thu, 27 Nov 2003 05:57:15 +1300 (NZDT)
Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id hAQGxm001648; Thu, 27 Nov 2003 05:59:48 +1300
Date: Thu, 27 Nov 2003 05:59:48 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Certificate Policy Standardization
Cc: [e-mail]
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-OriginalArrivalTime: 26 Nov 2003 17:05:08.0504 (UTC) FILETIME=[71FFE180:01C3B43F]
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>

Stephen Kent <[e-mail]> writes:

>one might ask why the most widely distributed product that claims to
>implement IPsec  (Windows) does not provide a user/administrator the ability
>to order SPD entries, as required by RFC 2401. The answer is that the
>implementors did not understand why this was an important (in the case of
>IPsec, a critical) aspect of the standard and so the implementors omitted an
>important management control.
>
>what one can learn from this an similar examples is that vendors are a very
>poor basis for determining the worth of a feature in a standard. 

Actually what I learn from this is that complex standards with often
incomprehensible requirements are just asking for trouble if they don't
include a rationale.  Even a single sentence explaining the background behind
the SPD entry ordering would have prevented this in a manner that no amount of
MUSTs/SHALLs ever can.

Peter.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9krib085830 for <[e-mail]>; Fri, 28 Nov 2003 01:46:53 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAS9krIb085828 for ietf-pkix-bks; Fri, 28 Nov 2003 01:46:53 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from relhubc02-ukbr.tcrelay.net ([217.32.166.20]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9kpid085784 for <[e-mail]>; Fri, 28 Nov 2003 01:46:52 -0800 (PST) (envelope-from [e-mail])
Received: from mail pickup service by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC; Fri, 28 Nov 2003 09:40:58 +0000
Received: from above.proper.com ([208.184.76.39]) by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 26 Nov 2003 17:03:57 +0000
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQGxOib031953 for <[e-mail]>; Wed, 26 Nov 2003 08:59:24 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQGxOlp031952 for ietf-pkix-bks; Wed, 26 Nov 2003 08:59:24 -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.10/8.12.8) with ESMTP id hAQGxNib031946 for <[e-mail]>; Wed, 26 Nov 2003 08:59:23 -0800 (PST) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Wed, 26 Nov 2003 11:59:18 -0500
From: "David P. Kemp" <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
CC: [e-mail]
Subject: Re: Web-PKI Keygen/Certreq Questions
References: <00e101c39fc2$a59fa200$3a1b40d5@arport> <p06002003bbc83730f4f9@[128.89.89.75]> <[e-mail]> <p0600200bbbc8676a42ac@[128.89.89.75]> <006b01c3ad13$d7ddff60$0500a8c0@arport>
In-Reply-To: <006b01c3ad13$d7ddff60$0500a8c0@arport>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-OriginalArrivalTime: 26 Nov 2003 17:05:08.0504 (UTC) FILETIME=[71FFE180:01C3B43F]
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>

Hopefully the consortium is planning to construct its solution by 
profiling: a) attributes to be included in RFC 2797 messages and b) 
transport of those messages over http, rather than inventing something 
from scratch.

Dave



Anders Rundgren wrote:

> Just to set the record straight: Another consortium has indeed
> [also] found the existings keygen/certreq mechanisms largely
> inferior and will publish a draft solution in a couple of months
> or so.  I just talked to one of the architects, and he confirmed that
> it will support the kind of stuff that most of the proprietary solutions
> already do, such as key-container co-signing, passphrase policy
> control, and multi-key generation.
> 
> /a
> 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9kXib085732 for <[e-mail]>; Fri, 28 Nov 2003 01:46:33 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAS9kX4M085729 for ietf-pkix-bks; Fri, 28 Nov 2003 01:46:33 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from relhubc02-ukbr.tcrelay.net ([217.32.166.20]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9kUid085694 for <[e-mail]>; Fri, 28 Nov 2003 01:46:32 -0800 (PST) (envelope-from [e-mail])
Received: from mail pickup service by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC; Fri, 28 Nov 2003 09:40:40 +0000
Received: from above.proper.com ([208.184.76.39]) by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 26 Nov 2003 16:13:37 +0000
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQF6oib026145 for <[e-mail]>; Wed, 26 Nov 2003 07:06:50 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQF6nTf026144 for ietf-pkix-bks; Wed, 26 Nov 2003 07:06:49 -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.10/8.12.8) with ESMTP id hAQF6mib026135 for <[e-mail]>; Wed, 26 Nov 2003 07:06:48 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (127.0.0.1) by nic.lp.se (MX V5.3 VnHj) with ESMTP; Wed, 26 Nov 2003 16:06:47 +0100
Date: Wed, 26 Nov 2003 16:06:46 +0100 (CET)
Message-ID: <[e-mail]>
To: [e-mail]
CC: [e-mail]
Subject: Re: Certificate Policy Standardization
From: Richard Levitte - VMS Whacker <[e-mail]>
In-Reply-To: <028101c3b424$7dd4b460$0500a8c0@arport>
References: <00e001c3b366$7c1cbc80$0500a8c0@arport> <[e-mail]> <028101c3b424$7dd4b460$0500a8c0@arport>
X-URL: http://www.lp.se/
X-Waved: dead chicken, GNU emacs 21.3.1, Mew version 4.0.60
X-Mew: See http://www.mew.org/
X-Mailer: Mew version 4.0.60 on Emacs 21.3.1 / Mule 5.0 (SAKAKI)
MIME-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-OriginalArrivalTime: 26 Nov 2003 16:14:26.0425 (UTC) FILETIME=[5CC77690:01C3B438]
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 <028101c3b424$7dd4b460$0500a8c0@arport> on Wed, 26 Nov 2003 14:52:10 +0100, "Anders Rundgren" <[e-mail]> said:

anders.rundgren> Richard,

Anders,

anders.rundgren> That external parties to the US e-governments, like
anders.rundgren> various businesses would ever (on a wider scale)
anders.rundgren> bother with cross-certification is unlikely, they
anders.rundgren> will just purchase a TTP-issued "business
anders.rundgren> certificate" for a few hundred dollars, not run CAs.

Wait, weren't you just asking about connecting different PKIs
together, or did I misunderstand you?  Going out shopping "business
certificates" will mean absolutely nothing in terms of PKI connection
unless everyone agrees to shop from the same CA.  I see that
happening, right...

It's true that smaller businesses will most likely not bother running
their own CA (unless they are run by techno-geeks like me, but that's
a different matter :-)).  I'm not so sure about larger ones...

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.
You don't have to be rich, a $10 donation is appreciated!

-- 
Richard Levitte     | http://richard.levitte.org/ | Tunnlandsv. 3
Levitte Programming | http://www.lp.se/           | S-168 36 Bromma
T: [phone] |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9kXib085728 for <[e-mail]>; Fri, 28 Nov 2003 01:46:33 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAS9kXWN085726 for ietf-pkix-bks; Fri, 28 Nov 2003 01:46:33 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from relhubc02-ukbr.tcrelay.net ([217.32.166.20]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9kUib085694 for <[e-mail]>; Fri, 28 Nov 2003 01:46:31 -0800 (PST) (envelope-from [e-mail])
Received: from mail pickup service by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC; Fri, 28 Nov 2003 09:40:36 +0000
Received: from above.proper.com ([208.184.76.39]) by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 26 Nov 2003 19:12:33 +0000
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQIBeib035761 for <[e-mail]>; Wed, 26 Nov 2003 10:11:40 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQIBeHC035760 for ietf-pkix-bks; Wed, 26 Nov 2003 10:11:40 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.cs.auckland.ac.nz (csmail.cs.auckland.ac.nz [130.216.33.150]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQIBcib035752 for <[e-mail]>; Wed, 26 Nov 2003 10:11:38 -0800 (PST) (envelope-from [e-mail])
Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id 45A3C63C1D; Thu, 27 Nov 2003 07:11:37 +1300 (NZDT)
Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id hAQIEA202922; Thu, 27 Nov 2003 07:14:10 +1300
Date: Thu, 27 Nov 2003 07:14:10 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Certificate Policy Standardization
Cc: [e-mail]
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-OriginalArrivalTime: 26 Nov 2003 19:12:34.0382 (UTC) FILETIME=[3F4C46E0:01C3B451]
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>

Stephen Kent <[e-mail]> writes:

>Implementors of a technology ought (MUST/SHALL?) be competent in the
>technology that they are implementing. A standard like IPsec is not a "Secure
>Communication  Protocols for Dummies" document.

  The first thing one notices when looking at IPsec is that the documentation
  is very hard to understand. There is no overview or introduction, the reader
  has to assemble all the pieces and build an overview himself. This is a
  highly unsatisfactorily state of affairs; after all, the documentation is
  meant to convey information to the readers. We do not believe it is
  reasonable to expect anyone to learn IPsec from the IPsec documentation.
  Various parts of the IPsec documentation are very hard to read. For ex-
  ample, the ISAKMP specifications [MSST98] contain numerous errors, essential
  explanations are missing, and the document contradicts itself in various
  places.

  [...]
  
  None of the IPsec documentation provides any rationale for any of the
  choices that were made. Although this is somewhat less important than a
  clear statement of the goals, we nevertheless consider it crucial
  information. If a reviewer is to comment on the design (and RFCs are, after
  all, Requests For Comments), he should be told what each option was intended
  to achieve. Without any rationale, the reviewer is left to guess at it, and
  then review the design based on the guessed-at rationale.

  [...]
  
  In our opinion, IPsec is too complex to be secure. The design obviously
  tries to support many different situations with different options. We feel
  very strongly that the resulting system is well beyond the level of
  complexity that can be analysed or properly implemented with current method-
  ologies. Thus, no IPsec system will achieve the goal of providing a high
  level of security.

  [...]

  It is far too complex, and the complexity has lead to a large number of
  ambiguities, contradictions, inefficiencies, and weaknesses. It has been
  very hard work to perform any kind of security analysis; we do not feel that
  we fully understand the system, let alone have fully analyzed it.

Obviously non-dummies can't make much sense of it either.

Peter.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9jQib085370 for <[e-mail]>; Fri, 28 Nov 2003 01:45:26 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAS9jQ9N085368 for ietf-pkix-bks; Fri, 28 Nov 2003 01:45:26 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from relhubc02-ukbr.tcrelay.net ([217.32.166.20]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9jNid085302 for <[e-mail]>; Fri, 28 Nov 2003 01:45:25 -0800 (PST) (envelope-from [e-mail])
Received: from mail pickup service by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC; Fri, 28 Nov 2003 09:39:33 +0000
Received: from above.proper.com ([208.184.76.39]) by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 26 Nov 2003 16:48:48 +0000
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQFdYib027926 for <[e-mail]>; Wed, 26 Nov 2003 07:39:34 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQFdYCA027925 for ietf-pkix-bks; Wed, 26 Nov 2003 07:39:34 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.cs.auckland.ac.nz (csmail.cs.auckland.ac.nz [130.216.33.150]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQFdWib027920 for <[e-mail]>; Wed, 26 Nov 2003 07:39:33 -0800 (PST) (envelope-from [e-mail])
Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id 8818063C1D; Thu, 27 Nov 2003 04:39:33 +1300 (NZDT)
Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id hAQFg5L01342; Thu, 27 Nov 2003 04:42:05 +1300
Date: Thu, 27 Nov 2003 04:42:05 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Certificate Policy Standardization
Cc: [e-mail], [e-mail]
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-OriginalArrivalTime: 26 Nov 2003 16:49:33.0097 (UTC) FILETIME=[44741990:01C3B43D]
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>

Stephen Kent <[e-mail]> writes:

>For example, most certs used with IKE will not be subject to some attorney's
>advice, I suspect.

Actually now that you mention it one of the three classes of certs that were
going to be used in the situation I mentioned were IKE certs.  I think they
were going to subclass "doWhatISay" into "doWhatISayWithIKE",
"doWhatISayWithSSL", and "doWhatISayWithSMIMESigning"(not sure about the last
one, I have the paperwork downstairs but I'm too lazy to look it up).  All of
them were going to go through the full legal wringer.

Peter.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9jQib085366 for <[e-mail]>; Fri, 28 Nov 2003 01:45:26 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAS9jQj5085362 for ietf-pkix-bks; Fri, 28 Nov 2003 01:45:26 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from relhubc02-ukbr.tcrelay.net ([217.32.166.20]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS9jNib085302 for <[e-mail]>; Fri, 28 Nov 2003 01:45:24 -0800 (PST) (envelope-from [e-mail])
Received: from mail pickup service by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC; Fri, 28 Nov 2003 09:39:26 +0000
Received: from above.proper.com ([208.184.76.39]) by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 26 Nov 2003 19:11:51 +0000
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQGj9ib031373 for <[e-mail]>; Wed, 26 Nov 2003 08:45:09 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQGj9i0031372 for ietf-pkix-bks; Wed, 26 Nov 2003 08:45:09 -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.10/8.12.8) with ESMTP id hAQGj7ib031367 for <[e-mail]>; Wed, 26 Nov 2003 08:45:07 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (127.0.0.1) by nic.lp.se (MX V5.3 VnHj) with ESMTP; Wed, 26 Nov 2003 17:44:59 +0100
Date: Wed, 26 Nov 2003 17:44:58 +0100 (CET)
Message-ID: <[e-mail]>
To: [e-mail]
CC: [e-mail], [e-mail]
Subject: Re: Certificate Policy Standardization
From: Richard Levitte - VMS Whacker <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
X-URL: http://www.lp.se/
X-Waved: dead chicken, GNU emacs 21.3.1, Mew version 4.0.60
X-Mew: See http://www.mew.org/
X-Mailer: Mew version 4.0.60 on Emacs 21.3.1 / Mule 5.0 (SAKAKI)
MIME-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-OriginalArrivalTime: 26 Nov 2003 19:11:52.0023 (UTC) FILETIME=[260CCE70:01C3B451]
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 Thu, 27 Nov 2003 04:13:30 +1300, [e-mail] (Peter Gutmann) said:

pgut001> "Anders Rundgren" <[e-mail]> writes:
pgut001> 
pgut001> >1. Why does practically no shrink-wrap PKI-enabled software package support
pgut001> >any kind of certificate policy settings?
pgut001> 
pgut001> Zero demand.  Heck, it wasn't too long ago that MS PKI
pgut001> software hardcoded the Verisign policy into CryptoAPI, so
pgut001> that no matter what the actual policy was in the cert, what
pgut001> was displayed was the Verisign policy.  That shows how much
pgut001> attention people are paying to the policy stuff.

Let's take note of what Peter says here.  First, M$ did some
hardcoding, which they have subsequently changed (I got that right, I
hope).  That means M$ is capable of change, and does listen to some
concerns.  Sure, that's pretty slow development, but development
still.  A bunch more times with a LART, and even M$ might do policy
checks :-).

pgut001> ...  So the trusted-roots mechanism does what the policy
pgut001> extension is supposed to do,

Which only works as long as the formula CA<=>Policy is true...

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.
You don't have to be rich, a $10 donation is appreciated!

-- 
Richard Levitte     | http://richard.levitte.org/ | Tunnlandsv. 3
Levitte Programming | http://www.lp.se/           | S-168 36 Bromma
T: [phone] |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS90Iib070776 for <[e-mail]>; Fri, 28 Nov 2003 01:00:18 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAS90IVI070774 for ietf-pkix-bks; Fri, 28 Nov 2003 01:00:18 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from www16.your-server.de (IDENT:[e-mail] [213.133.104.16]) by above.proper.com (8.12.10/8.12.8) with SMTP id hAS90Eib070724 for <[e-mail]>; Fri, 28 Nov 2003 01:00:17 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 30347 invoked by uid 1649); 28 Nov 2003 09:00:09 -0000
Date: 28 Nov 2003 09:00:09 -0000
Message-ID: <[e-mail]>
From: "Florian Oelmaier" <[e-mail]>
To: Marc Branchaud <[e-mail]>, [e-mail]
Subject: Re: DISCUSS:  MUST  reject in OCSPv1
References:   <>
In-Reply-To:  <>
X-Mailer: oMail 0.98.2 - http://webmail.omnis.ch
X-IPAddress: 195.212.95.34
X-Sender: [e-mail]
MIME-Version: 1.0
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>

> If the client puts a nonce in a request and doesn't behave differently 
> depending on the presence/absence of the nonce in the response, then why 
> put the nonce in at all?

I agree. But the client behaves differently! It may
- display a warning to the user
- apply another local policy regarding time checking
- add additional measures to ensure freshness if a nonce is not present
- etc.

-- 
Florian Oelmaier
SyTrust



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS8J3ib057201 for <[e-mail]>; Fri, 28 Nov 2003 00:19:03 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAS8J3ZS057200 for ietf-pkix-bks; Fri, 28 Nov 2003 00:19:03 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp2.fre.skanova.net (smtp2.fre.skanova.net [195.67.227.95]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS8J2ib057172 for <[e-mail]>; Fri, 28 Nov 2003 00:19:03 -0800 (PST) (envelope-from [e-mail])
Received: from arport (t11o913p71.telia.com [213.64.28.71]) by smtp2.fre.skanova.net (8.12.10/8.12.10) with SMTP id hAS8Ijok000453; Fri, 28 Nov 2003 09:18:46 +0100 (CET)
Message-ID: <008201c3b587$b72f2b00$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]>
Subject: Conclusion: Certificate Policy Standardization
Date: Fri, 28 Nov 2003 09:13:56 +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>

Thank you folks for giving valuable input on this subject!

After compiling the numerous postings I believe that a number
of things are pretty clear:

1. Standardization of policy identifiers is unlikely to ever happen
    to the extent that policy OIDs can be pre-set in COTS SW [1].

2. The use of policy OIDs in path validation is for the same reason,
   as well as due to the lack of CP OID configuration support [2]
   in COTS SW, limited to "in-house" or "enterprise" type of trust-
   networks, where there are IS-departments that deal with
   "tweaking",  the usually custom RP software, for alignment with
   the trust-network-specific rules.

3. TTP CAs (who essentially compete with "in-house" type of CAs
   of the kind mentioned in #2), have no reason to abandon their
   issuance structure beyond the current CA <=> Policy level [3],
   as they have nothing to gain by doing that, except for numerous 
   commercial, technical, security, and legal problems.  

   Some readers claim that this is holding back "progress", but they
   apparently do not fully grasp the huge difference between running
   something like VeriSign's Web-server CA and an enterprise PKI.
   The short explanation is that the former is "unilateral",  and hardly
   ever engage in cross-certification etc.  To force Mc Donald's into
   recommending "Whoppers" is not going to happen.  For a reason.

Anders Rundgren

1] COTS SW.  Common Off-The Shelf SoftWare.

2] As indicated by Peter Guttman, configuration of CP OIDs is
   by no means ready for wide-scale deployment as many questions
   are still to be answered.  Due to the fact the the IETF is not working
   on this issue, we will essentially have to wait to see what Microsoft
   and other vendors believe is the "right way" to handle this.

3] This scheme also opens completely of new possibilities, like
   using the CA as a holder of meta-data, potentially simplifying
   RP trust administration, as a CA certificate can "describe" the
   issuance before a single EE-certificate has been received.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS4pdib002433 for <[e-mail]>; Thu, 27 Nov 2003 20:51:39 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAS4pdon002431 for ietf-pkix-bks; Thu, 27 Nov 2003 20:51:39 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS4pdib002367 for <[e-mail]>; Thu, 27 Nov 2003 20:51:39 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (h005008001124.ne.client2.attbi.com[66.31.43.88]) by comcast.net (rwcrmhc12) with ESMTP id <200311280451360140074uk2e>; Fri, 28 Nov 2003 04:51:36 +0000
Received: from localhost ([127.0.0.1] helo=corestreet.com ident=dave) by localhost with esmtp (Exim 3.35 #1 (Debian)) id 1APadH-0005yF-00 for <[e-mail]>; Thu, 27 Nov 2003 23:53:31 -0500
Message-ID: <[e-mail]>
Date: Thu, 27 Nov 2003 23:53:30 -0500
From: David Engberg <[e-mail]>
Organization: CoreStreet
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Digression:  nonces prevent replay?
References: <002101c3b53f$869821b0$4228a8c0@hagen> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; 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>

Marc Branchaud wrote:

> Yes, it is just as secure as using CRLs.  CRLs are also vulnerable to 
> replay attacks.  OCSP has a mechanism - nonces - to thwart replay 
> attacks.

The nonce mechanism "thwarts" or "prevents" replay attacks only in the 
most narrowly literal sense.

Imagine that I have a non-trivial PKI with a CA that publishes a 24-hour 
CRL every 6 hours into an LDAP directory.  Each CRL is then retrieved by 
a pair of geographically separate OCSP responders.

A client using nonces protected against the following attack:

   1) An attacker knows her cert will be revoked during one day.

   2) The attacker records a 'valid' OCSP response for her certificate
      at the beginning of the day.

   3) The attacker's cert is revoked and put on a CRL within a few hours.

   4) The attacker performs a signature for a relying party using
      her revoked cert, before the end of that day.

   5) The attacker fully controls networking between that relying
      party and the responder(s), but controls neither the RP or the
      responder.

   6) The relying party makes a request about that cert, the attacker
      intercepts and replays the stored "valid" response.

Basically, the nonce mechanism protects against a short term 
revocation-delaying attack that requires complete takeover of one link 
in the chain:  the network from the relying party to the responder.

(I've tried to come up with a real scenario where it would make sense 
for an attacker to choose this attack and carry it out for some kind of 
gain.  I keep coming up with Homer Simpson's response to a villain's 
plan:  "Of course! It's so simple! No, wait, it's needlessly complicated!")


What about attacks on the other links in the chain?

* CA Denial of Service:  prevent publication of new CRL, revocation is 
delayed (same end result as replay)

* CA -> LDAP network:  prevent distribution of new CRL, delay revocation 
(as replay)

* LDAP DoS:  prevent distribution of new CRL, delay revocation (as replay)

* LDAP -> responder network:  prevent distribution of new CRL, delay 
revocation (as replay)

* Responder intrusion/compromise:  use key to replay old response with 
new nonce (replay), or use key to create responses saying absolutely 
anything you want (reactivate stolen ID card, revoke your boss, etc.). 
No, an HSM doesn't prevent these.

* Reponder DoS:  prevent publication of revocation info, may get by as 
"unknown."  (Guard: "The servers are down again. Well, your badge looks 
good and I saw you this morning ... go ahead.")

* Relying Party intrusion/compromise:  ignore revocation (as replay)


My point is that a nonce only prevents one type of revocation-delaying 
attack.  This needs to be taken in the context of a full security 
analysis of your overall revocation infrastructure rather than assuming 
that nonces automatically confer absolute freshness and correctness.

Nonces may strengthen one link in a long chain, but they achieve this by 
significantly reducing the strength of another link (the responder). 
Nonces require online signing keys on public servers that accept 
thousands of HTTP requests per minute over public networks.  The impact 
of an intrusion/compromise of a key-bearing server is orders of 
magnitude more severe than any revocation delay caused by a replay attack.

We PKI folks may sometimes feel that real-world server security isn't 
our problem as long as the algorithms and protocols are pristine.  Until 
every app and OS is bug-free (and every employee with physical access to 
servers is perfect), we need to account for risks from boring old 
non-PKI server attacks like:

   http://www.cert.org/advisories/CA-2002-29.html




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS25gib096353 for <[e-mail]>; Thu, 27 Nov 2003 18:05:42 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAS25gS8096352 for ietf-pkix-bks; Thu, 27 Nov 2003 18:05:42 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS25fib096347 for <[e-mail]>; Thu, 27 Nov 2003 18:05:41 -0800 (PST) (envelope-from [e-mail])
Received: from mail5.microsoft.com ([157.54.6.156]) by mail4.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 27 Nov 2003 18:05:27 -0800
Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(6.0.3790.1039); Thu, 27 Nov 2003 18:05:38 -0800
Received: from 157.54.8.109 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 27 Nov 2003 18:05:38 -0800
Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 27 Nov 2003 18:04:52 -0800
Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 27 Nov 2003 18:05:41 -0800
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 27 Nov 2003 18:05:56 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.7122.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary"
Subject: RE: DISCUSS:  MUST  reject in OCSPv1
Date: Thu, 27 Nov 2003 18:04:13 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: DISCUSS:  MUST  reject in OCSPv1
Thread-Index: AcO1U6KWUVrs9fc6R3+1Ij2KWP6nNwAAEkqM
From: "Ryan M. Hurst" <[e-mail]>
To: "Marc Branchaud" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 28 Nov 2003 02:05:56.0959 (UTC) FILETIME=[2932EEF0:01C3B554]
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.

--------------InterScan_NT_MIME_Boundary
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3B554.1EC1C1FC"

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

=20
cil

________________________________

From: [e-mail] on behalf of Marc Branchaud
Sent: Thu 11/27/2003 4:23 PM
To: [e-mail]
Subject: Re: DISCUSS: MUST reject in OCSPv1




That's all fine.  Really!

But why would the client not care if the nonce is echoed in the =
response?

The client should only ask for a fresh response if it really wants one.
To make frivolous requests for freshness would unnecessarily tax a
server that actually cares and tries to fulfill the requests.

[rmh] The question is does it want it or does it need it, in the case I =
gave the bookstore.com server would be happy with any response thats not =
expired; maybe the pre-production responder already has one that meets =
that criteria.

In the end, making the requirement anything less that "MUST reject" will
lead to servers simply ignoring the nonce extension altogether.

                M.


Florian Oelmaier wrote:
> Your argument is "nonces are only for replay protection". Thats true.
>
> Now lets discuss WHY a client wants to get replay protection. Seeing
> that we have the three times in the response with a clear semantic, =
the
> client is not harmed by a replay. So why should a client include a =
nonce
> into the request?
>
> There are different reasons for that, but the main reason is: the =
client
> wants a "fresh" response. Following that path Ryans arguments apply as
> he presented it in his previous replies. A client will include a nonce
> into the request to ask for a "fresh" response. If the client does not
> need a fresh response, then replaying is not a problem (then it is a
> feature called "caching").
>
> So if a responder gets a request with a nonce, it not only means "the
> client wants replay protection" - it also means "the client would like
> to get a fresh response". Because otherwise replay attacks would not
> matter.
>



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

<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">=0A=
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">=0A=
<HTML>=0A=
<HEAD>=0A=
=0A=
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7122.0">=0A=
<TITLE>Re: DISCUSS:  MUST  reject in OCSPv1</TITLE>=0A=
</HEAD>=0A=
<BODY>=0A=
<DIV id=3DidOWAReplyText2936 dir=3Dltr>=0A=
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 =
size=3D2></FONT>&nbsp;</DIV></DIV>=0A=
<DIV dir=3Dltr>cil<BR>=0A=
<HR tabIndex=3D-1>=0A=
<FONT face=3DTahoma size=3D2><B>From:</B> [e-mail] =
on behalf of =0A=
Marc Branchaud<BR><B>Sent:</B> Thu 11/27/2003 4:23 PM<BR><B>To:</B> =0A=
[e-mail]<BR><B>Subject:</B> Re: DISCUSS: MUST reject in =0A=
OCSPv1<BR></FONT><BR></DIV>=0A=
<DIV><BR>=0A=
<P><FONT size=3D2>That's all fine.&nbsp; Really!<BR><BR>But why would =
the client =0A=
not care if the nonce is echoed in the response?<BR><BR>The client =
should only =0A=
ask for a fresh response if it really wants one.<BR>To make frivolous =
requests =0A=
for freshness would unnecessarily tax a<BR>server that actually cares =
and tries =0A=
to fulfill the requests.</FONT></P>=0A=
<P><FONT size=3D2>[rmh] The question is does it want it or does it need =
it, in the =0A=
case I gave the bookstore.com server would be happy with any response =
thats not =0A=
expired; maybe the pre-production responder already has one that meets =
that =0A=
criteria.<BR><BR>In the end, making the requirement anything less that =
"MUST =0A=
reject" will<BR>lead to servers simply ignoring the nonce extension =0A=
altogether.<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =0A=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; M.<BR><BR><BR>Florian =
Oelmaier =0A=
wrote:<BR>&gt; Your argument is "nonces are only for replay protection". =
Thats =0A=
true.<BR>&gt;<BR>&gt; Now lets discuss WHY a client wants to get replay =0A=
protection. Seeing<BR>&gt; that we have the three times in the response =
with a =0A=
clear semantic, the<BR>&gt; client is not harmed by a replay. So why =
should a =0A=
client include a nonce<BR>&gt; into the request?<BR>&gt;<BR>&gt; There =
are =0A=
different reasons for that, but the main reason is: the client<BR>&gt; =
wants a =0A=
"fresh" response. Following that path Ryans arguments apply as<BR>&gt; =
he =0A=
presented it in his previous replies. A client will include a =
nonce<BR>&gt; into =0A=
the request to ask for a "fresh" response. If the client does =
not<BR>&gt; need a =0A=
fresh response, then replaying is not a problem (then it is a<BR>&gt; =
feature =0A=
called "caching").<BR>&gt;<BR>&gt; So if a responder gets a request with =
a =0A=
nonce, it not only means "the<BR>&gt; client wants replay protection" - =
it also =0A=
means "the client would like<BR>&gt; to get a fresh response". Because =
otherwise =0A=
replay attacks would not<BR>&gt; =0A=
matter.<BR>&gt;<BR></P></FONT></DIV>=0A=
=0A=
</BODY>=0A=
</HTML>
------_=_NextPart_001_01C3B554.1EC1C1FC--

--------------InterScan_NT_MIME_Boundary--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS0XPib092758 for <[e-mail]>; Thu, 27 Nov 2003 16:33:25 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAS0XPhS092757 for ietf-pkix-bks; Thu, 27 Nov 2003 16:33:25 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from sigurd.x509.com ([199.175.155.2]) by above.proper.com (8.12.10/8.12.8) with SMTP id hAS0XOib092749 for <[e-mail]>; Thu, 27 Nov 2003 16:33:24 -0800 (PST) (envelope-from [e-mail])
Received: from nebula.x509.com by sigurd.x509.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 28 Nov 2003 00:33:26 UT
Received: from crack.x509.com (localhost [127.0.0.1]) by nebula.x509.com (8.12.10/NULL) with ESMTP id hAS0TU6L017398 for <[e-mail]>; Thu, 27 Nov 2003 16:29:30 -0800 (PST)
Received: from exvan01.x509.com (exvan01.x509.com [10.9.22.50]) by crack.x509.com (8.12.10/8.12.10) with ESMTP id hAS0XOY0000273 for <[e-mail]>; Thu, 27 Nov 2003 16:33:24 -0800 (PST)
Received: from rsasecurity.com (mbranchaud2.eng.x509.com [10.7.33.48]) by exvan01.x509.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id VQFWG9HD; Thu, 27 Nov 2003 16:42:15 -0800
Message-ID: <[e-mail]>
Date: Thu, 27 Nov 2003 16:23:47 -0800
X-Sybari-Trust: d594414e 64c784fd c3b38011 00000139
From: Marc Branchaud <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031110
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: DISCUSS:  MUST  reject in OCSPv1
References: <003401c3b544$a6ce5710$4228a8c0@hagen>
In-Reply-To: <003401c3b544$a6ce5710$4228a8c0@hagen>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000405020605020409010402"
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.

--------------ms000405020605020409010402
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit


That's all fine.  Really!

But why would the client not care if the nonce is echoed in the response?

The client should only ask for a fresh response if it really wants one. 
To make frivolous requests for freshness would unnecessarily tax a 
server that actually cares and tries to fulfill the requests.

In the end, making the requirement anything less that "MUST reject" will 
lead to servers simply ignoring the nonce extension altogether.

		M.


Florian Oelmaier wrote:
> Your argument is "nonces are only for replay protection". Thats true.
> 
> Now lets discuss WHY a client wants to get replay protection. Seeing
> that we have the three times in the response with a clear semantic, the
> client is not harmed by a replay. So why should a client include a nonce
> into the request?
> 
> There are different reasons for that, but the main reason is: the client
> wants a "fresh" response. Following that path Ryans arguments apply as
> he presented it in his previous replies. A client will include a nonce
> into the request to ask for a "fresh" response. If the client does not
> need a fresh response, then replaying is not a problem (then it is a
> feature called "caching").
> 
> So if a responder gets a request with a nonce, it not only means "the
> client wants replay protection" - it also means "the client would like
> to get a fresh response". Because otherwise replay attacks would not
> matter.
> 

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISqTCC
AtcwggJAoAMCAQICEFgUQCxch7Sxp7XFFauIqpwwDQYJKoZIhvcNAQEFBQAwbDEaMBgGA1UE
ChMRUlNBIFNlY3VyaXR5IEluYy4xHjAcBgNVBAMTFVJTQSBQdWJsaWMgUm9vdCBDQSB2MTEu
MCwGCSqGSIb3DQEJARYfcnNha2VvbnJvb3RzaWduQHJzYXNlY3VyaXR5LmNvbTAeFw0wMjA5
MDYxNDEzNTJaFw0wNzA5MDYxNDEzNTJaMIGCMRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5j
LjEVMBMGA1UECxMMS0NBIFNlcnZpY2VzMRYwFAYDVQQDEw1SU0EgQ29ycG9yYXRlMRAwDgYD
VQQHEwdCZWRmb3JkMRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMQswCQYDVQQGEwJVUzCBnzAN
BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAqnOw876lPpMTkSqrqzpEON/609PDLEhmWX4tkC19
AHneDaoetL277GtYYXBCggP2E+s66MN1ccWXyApfWjCZkIHepPC08NVI1JRcbViW3kwLzDD2
w5T9QJcyL5V1pN/LQdxahM56TiLeXlPiJekdmTdJoo+5Pw4bQU+MxTqURk8CAwEAAaNjMGEw
HwYDVR0jBBgwFoAU9UwxelEDPyzXi5eZb6hxkKt4PZswHQYDVR0OBBYEFO2RCGt0t1lKkvah
HSJwJp8KrxaSMA8GA1UdEwQIMAYBAf8CAQMwDgYDVR0PAQH/BAQDAgGGMA0GCSqGSIb3DQEB
BQUAA4GBAHiSe1a79hnPr16PuBwUTBWbuNQ4GJNsyfrCXzAswIT2A2WtGZ1Hp1jEAWi9OfAX
IYAdy52Jyv9N87wAEbLUgVmsFEIlYM5mi6ag7YIRGp8JP5UhLAN9O5YHrR9FsrGK4WmSl3sY
W1qAPOXubFcfhTgUDIYzM30izZBP4nwO07FpMIIC+DCCAmGgAwIBAgIQeuiOriTayCwjwpmR
gmdIUjANBgkqhkiG9w0BAQUFADCBgjEaMBgGA1UEChMRUlNBIFNlY3VyaXR5IEluYy4xFTAT
BgNVBAsTDEtDQSBTZXJ2aWNlczEWMBQGA1UEAxMNUlNBIENvcnBvcmF0ZTEQMA4GA1UEBxMH
QmVkZm9yZDEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMwHhcNMDIwOTIz
MTkxMzAzWhcNMDYwOTIzMTUxMzAzWjCBjDEaMBgGA1UEChMRUlNBIFNlY3VyaXR5IEluYy4x
FTATBgNVBAsTDEtDQSBTZXJ2aWNlczEgMB4GA1UEAxMXUlNBIENsYXNzIDIgUGVyc29uYWwg
Q0ExEDAOBgNVBAcTB0JlZGZvcmQxFjAUBgNVBAgTDU1hc3NhY2h1c2V0dHMxCzAJBgNVBAYT
AlVTMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCkR9yiabyRo6+NwC3Sl8wPuUiBD3rP
sENNjXvzSbTAyXA8pDDndnlAa1nLUhSMgvn8g1sYMd0Bp+C1/mI5PFUZ8jukUK95yt+TK26L
hM/M5RUq/EINdDDdWzg9je498K6oGfyWR6ETSJbIrDe5qQcLCABs9E2gVKb7Z/FwFo3C9QID
AQABo2MwYTAPBgNVHRMECDAGAQH/AgECMA4GA1UdDwEB/wQEAwIBhjAfBgNVHSMEGDAWgBTt
kQhrdLdZSpL2oR0icCafCq8WkjAdBgNVHQ4EFgQUxpPuxqX+41WOz4ojH+6Y3iHyn6cwDQYJ
KoZIhvcNAQEFBQADgYEAcdRHBjq8GfdDoutUTJPtSzQd7XsdsQh2KBbu8utl92VQHuI0J5wc
Rc817G8YbmTtCt/xqAzrr6k7fdaoDBr/kBuVHA5FEJ94foPgrOlbT3zdziMATXh5ESSDLMx6
p8ITIsTJNmwszIG5P9AAKJCW48gu1ZZmLXhFbHcYJGf99pwwggMFMIICbqADAgECAhEAvhyf
0s21hKaAc2Nm1WX4LTANBgkqhkiG9w0BAQUFADCBuzEkMCIGA1UEBxMbVmFsaUNlcnQgVmFs
aWRhdGlvbiBOZXR3b3JrMRcwFQYDVQQKEw5WYWxpQ2VydCwgSW5jLjE1MDMGA1UECxMsVmFs
aUNlcnQgQ2xhc3MgMyBQb2xpY3kgVmFsaWRhdGlvbiBBdXRob3JpdHkxITAfBgNVBAMTGGh0
dHA6Ly93d3cudmFsaWNlcnQuY29tLzEgMB4GCSqGSIb3DQEJARYRaW5mb0B2YWxpY2VydC5j
b20wHhcNMDIwNDMwMTUzMDE5WhcNMTkwNDMwMDkyMTU1WjBsMRowGAYDVQQKExFSU0EgU2Vj
dXJpdHkgSW5jLjEeMBwGA1UEAxMVUlNBIFB1YmxpYyBSb290IENBIHYxMS4wLAYJKoZIhvcN
AQkBFh9yc2FrZW9ucm9vdHNpZ25AcnNhc2VjdXJpdHkuY29tMIGfMA0GCSqGSIb3DQEBAQUA
A4GNADCBiQKBgQC0dSVa2EQ740GxqiIKsHATT4f8XYwUU23pzRe5W6IVpt4jkwDWkgnvTcP6
M8PD4OfK6Imal4hAH/c3K/dUIH7YyQZRGAE5Y27G5klZYKidcFlrfautgVES170MLKFmJqym
2FWAfVOibXatRcw7B0S+mP9404jID/MaIpRXkH5JjwIDAQABo1cwVTAMBgNVHRMEBTADAQH/
MA4GA1UdDwEB/wQEAwIBhjAWBgNVHSAEDzANMAsGCSqGSIb3DQUGATAdBgNVHQ4EFgQU9Uwx
elEDPyzXi5eZb6hxkKt4PZswDQYJKoZIhvcNAQEFBQADgYEAKsviXBc1FeBT2hIwyWuGwnPZ
J9ctjrsO7NbVLjsx/EYclFFGwo+pphiwdUTml9yd7fXzfk0D+7LOs9ZA5xhiHVrGusV4OW4i
7hx2KVILkYlcXCN5tDltKwa5+BkGUuvZdyAoIhpyf61h7uKCFguhaJ+VOiNB4DPtsmxI+KxO
E6YwggTYMIIEQaADAgECAhBgzHl9dAoZGu0JMqXovSgdMA0GCSqGSIb3DQEBBQUAMIGMMRow
GAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEVMBMGA1UECxMMS0NBIFNlcnZpY2VzMSAwHgYD
VQQDExdSU0EgQ2xhc3MgMiBQZXJzb25hbCBDQTEQMA4GA1UEBxMHQmVkZm9yZDEWMBQGA1UE
CBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMwHhcNMDMwNzA3MjMwODEzWhcNMDQwNzA3
MjMwODEzWjCBvjETMBEGCgmSJomT8ixkARkWA2NvbTEbMBkGCgmSJomT8ixkARkWC3JzYXNl
Y3VyaXR5MRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEWMBQGA1UECxMNTm9ydGggQW1l
cmljYTEUMBIGA1UECxMLRW5naW5lZXJpbmcxFzAVBgNVBAMTDk1hcmMgQnJhbmNoYXVkMScw
JQYJKoZIhvcNAQkBFhhtYXJjbmFyY0Byc2FzZWN1cml0eS5jb20wggEiMA0GCSqGSIb3DQEB
AQUAA4IBDwAwggEKAoIBAQDg2xoRr+a/dtnuFG+oTHa+tGtzeObFazNhYV2iSLNED4fHRu86
tknBYFgXggcHW5gsyjfkCtVMzP2tCivmbJgvISo36vsCsmAJH6LRnJf8HsvfmWZaD9tzhDpL
QVsBHr88J0ZMdVniRc7MQoYeu/3hYtUBeGO9bGA6T8vTrnXYonnFtVoTqE62SFqPZZk7HpCS
X1n+dM3zSym2ylMFYE14nukF4I9vAhsQVzk3QNpghmzGj8uoEy9xpf3k0o5+neneAGvcSkwo
r1mH5tSqhrEQaZp7vuSA2bvXaZEnjZzZiTpPDzs1oMpn3guzYhU7wMKz6xvwvgEYyAAV+P5n
FWM/AgMBAAGjggGBMIIBfTCBkgYDVR0gBIGKMIGHMIGEBgkqhkiG9w0FBwIwdzAuBggrBgEF
BQcCARYiaHR0cDovL2NhLnJzYXNlY3VyaXR5LmNvbS9DUFMuaHRtbDBFBggrBgEFBQcCAjA5
MBgWEVJTQSBTZWN1cml0eSBJbmMuMAMCAQEaHUNQUyBJbmNvcnBvcmF0ZWQgYnkgcmVmZXJl
bmNlMCkGA1UdJQQiMCAGCisGAQQBgjcUAgIGCCsGAQUFBwMCBggrBgEFBQcDBDAjBgNVHREE
HDAagRhtYXJjbmFyY0Byc2FzZWN1cml0eS5jb20wDgYDVR0PAQH/BAQDAgeAMEYGA1UdHwQ/
MD0wO6A5oDeGNWh0dHA6Ly9jcmwucnNhc2VjdXJpdHkuY29tOjgwL1JTQUNsYXNzMlBlcnNv
bmFsQ0EuY3JsMB8GA1UdIwQYMBaAFMaT7sal/uNVjs+KIx/umN4h8p+nMB0GA1UdDgQWBBQ1
yQ/UrvKb563LjzHqJzBzrZp/ejANBgkqhkiG9w0BAQUFAAOBgQCV82oGGnglQQzklKg/wKhy
evNeJ6FNBZFhLlmZRNlKgqvPFmBcxygfBGpHqIhsHcrt2/AjhJuzAj7UdW1vTVCY5MkZw8P9
6+J6aTc3bNlGbk0jvcvVgDhmM4xYJLwMZKEw92HlRhfuMnj7ah9DTqbKSewmyAyOc+FLpGfd
lu6CgTCCBOkwggRSoAMCAQICEQDqxAXqre9Mr+FeYw3+MQhsMA0GCSqGSIb3DQEBBQUAMIGM
MRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEVMBMGA1UECxMMS0NBIFNlcnZpY2VzMSAw
HgYDVQQDExdSU0EgQ2xhc3MgMiBQZXJzb25hbCBDQTEQMA4GA1UEBxMHQmVkZm9yZDEWMBQG
A1UECBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMwHhcNMDMwNzA3MjMwODI4WhcNMDQw
NzA3MjMwODEzWjCBwjETMBEGCgmSJomT8ixkARkWA2NvbTEbMBkGCgmSJomT8ixkARkWC3Jz
YXNlY3VyaXR5MRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEWMBQGA1UECxMNTm9ydGgg
QW1lcmljYTEUMBIGA1UECxMLRW5naW5lZXJpbmcxGzAZBgNVBAMTEk1hcmMgQnJhbmNoYXVk
LUVuYzEnMCUGCSqGSIb3DQEJARYYbWFyY25hcmNAcnNhc2VjdXJpdHkuY29tMIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwBjNaHTwtCXpdJg+iDxYMkWjuZIF0ic2fRLymZe+
BnZYWPnik0dFmTulx+V8slsLEtBllcc5o1yfIYfeHPinwRxv86kCUSlgfGGXKjJZaIeURgbo
bUbIfDTPlvRUZuiZvTR4C8tEY88Lle66n62B7wjUvDbiwK4EjzlXOkjpcYXLH7FbaFaRLDBB
PlFD5ydDRhQ67t6fjUeS7p7o/l/VHmPC5LFLXZkjEhjGd5pknbQIAbUGACL5UET85NUFPowD
3F47g0GCKEnuOsk2Ra+WHu7honhIxqmOwGnu85V6tW5xscf4dTofWZONQeaD3gSxv8+hcfKN
k9cwjpnUG2xGzwIDAQABo4IBjTCCAYkwNQYDVR0lBC4wLAYKKwYBBAGCNxQCAgYIKwYBBQUH
AwIGCCsGAQUFBwMEBgorBgEEAYI3CgMEMIGSBgNVHSAEgYowgYcwgYQGCSqGSIb3DQUHAjB3
MC4GCCsGAQUFBwIBFiJodHRwOi8vY2EucnNhc2VjdXJpdHkuY29tL0NQUy5odG1sMEUGCCsG
AQUFBwICMDkwGBYRUlNBIFNlY3VyaXR5IEluYy4wAwIBARodQ1BTIEluY29ycG9yYXRlZCBi
eSByZWZlcmVuY2UwIwYDVR0RBBwwGoEYbWFyY25hcmNAcnNhc2VjdXJpdHkuY29tMEYGA1Ud
HwQ/MD0wO6A5oDeGNWh0dHA6Ly9jcmwucnNhc2VjdXJpdHkuY29tOjgwL1JTQUNsYXNzMlBl
cnNvbmFsQ0EuY3JsMB8GA1UdIwQYMBaAFMaT7sal/uNVjs+KIx/umN4h8p+nMB0GA1UdDgQW
BBT/OiMCyY8CPnNBySW1ijJOYhj7ejAOBgNVHQ8BAf8EBAMCAzgwDQYJKoZIhvcNAQEFBQAD
gYEAlchAObA9eVmeiLu0nTU985Fch6v+EZKodUhZUN7dILgd05HorHN9jxBH6XI4/b9ZVvub
Pkpicdc112YbcLYTD2NumVksyNDI7fDaqiszgk1zluXtZJ+HsCt+GIAKCDfOVLECclpGyizq
VjZFEK4Pt9FxPGTnUJEvIKJcAQ24EvgxggPsMIID6AIBATCBoTCBjDEaMBgGA1UEChMRUlNB
IFNlY3VyaXR5IEluYy4xFTATBgNVBAsTDEtDQSBTZXJ2aWNlczEgMB4GA1UEAxMXUlNBIENs
YXNzIDIgUGVyc29uYWwgQ0ExEDAOBgNVBAcTB0JlZGZvcmQxFjAUBgNVBAgTDU1hc3NhY2h1
c2V0dHMxCzAJBgNVBAYTAlVTAhBgzHl9dAoZGu0JMqXovSgdMAkGBSsOAwIaBQCgggIfMBgG
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMTEyODAwMjM0N1ow
IwYJKoZIhvcNAQkEMRYEFIWrbPF5SRs+gv8yFwoeTSvlN5y2MFIGCSqGSIb3DQEJDzFFMEMw
CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G
CCqGSIb3DQMCAgEoMIGzBgkrBgEEAYI3EAQxgaUwgaIwgYwxGjAYBgNVBAoTEVJTQSBTZWN1
cml0eSBJbmMuMRUwEwYDVQQLEwxLQ0EgU2VydmljZXMxIDAeBgNVBAMTF1JTQSBDbGFzcyAy
IFBlcnNvbmFsIENBMRAwDgYDVQQHEwdCZWRmb3JkMRYwFAYDVQQIEw1NYXNzYWNodXNldHRz
MQswCQYDVQQGEwJVUwIRAOrEBeqt70yv4V5jDf4xCGwwgbUGCyqGSIb3DQEJEAILMYGloIGi
MIGMMRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEVMBMGA1UECxMMS0NBIFNlcnZpY2Vz
MSAwHgYDVQQDExdSU0EgQ2xhc3MgMiBQZXJzb25hbCBDQTEQMA4GA1UEBxMHQmVkZm9yZDEW
MBQGA1UECBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMCEQDqxAXqre9Mr+FeYw3+MQhs
MA0GCSqGSIb3DQEBAQUABIIBALQTj8N6uavUf5z2SBJTX9RUYt8lFawGnPiPkPEAH+0/vdjW
4N7nFbuiEjc3jbbU/UbK2r2LFlgXGICEX/VBPW0BtXBs+P4USMyDJAo+QbzmGbUAMw6CnQVd
qQ3eS/vC9gj1A2CrsbrnEBR1q38aiilNG31drbTSroaZKaWqBgR8t1udEsUEzo+pDEVVWkzP
x7337PnhDI5p3tlOsGeL4zryd48OdYfX/VowvC6LJs6HIMW9dVkKn0TRuTpFU8kHCml31phX
+OURiVVcw9RxCl/70Z/76kH5/LibmTzf97Un7PYVrdYTsnjZyzbpwLdMI93+dl9vSMwI+363
4KFRf9YAAAAAAAA=
--------------ms000405020605020409010402--


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS0FAib091923 for <[e-mail]>; Thu, 27 Nov 2003 16:15:10 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAS0FA45091922 for ietf-pkix-bks; Thu, 27 Nov 2003 16:15:10 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout05.sul.t-online.com (mailout05.sul.t-online.com [194.25.134.82]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS0F8ib091912 for <[e-mail]>; Thu, 27 Nov 2003 16:15:08 -0800 (PST) (envelope-from [e-mail])
Received: from fwd05.aul.t-online.de  by mailout05.sul.t-online.com with smtp  id 1APWHk-0001cU-03; Fri, 28 Nov 2003 01:15:00 +0100
Received: from hagen (XLs2xoZYQeK2KZbVNIN7zuE9jOWLj79gD9Q4qHYRaRIZ9oLtwx-Hss@[217.228.232.10]) by fmrl05.sul.t-online.com with esmtp id 1APWHg-28Mqdk0; Fri, 28 Nov 2003 01:14:56 +0100
From: "Florian Oelmaier" <[e-mail]>
To: "'Marc Branchaud'" <[e-mail]>, <[e-mail]>
Subject: RE: DISCUSS:  MUST  reject in OCSPv1
Date: Fri, 28 Nov 2003 01:14:55 +0100
Organization: SyTrust
Message-ID: <003401c3b544$a6ce5710$4228a8c0@hagen>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Seen: false
X-ID: [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>

Your argument is "nonces are only for replay protection". Thats true.

Now lets discuss WHY a client wants to get replay protection. Seeing
that we have the three times in the response with a clear semantic, the
client is not harmed by a replay. So why should a client include a nonce
into the request?

There are different reasons for that, but the main reason is: the client
wants a "fresh" response. Following that path Ryans arguments apply as
he presented it in his previous replies. A client will include a nonce
into the request to ask for a "fresh" response. If the client does not
need a fresh response, then replaying is not a problem (then it is a
feature called "caching").

So if a responder gets a request with a nonce, it not only means "the
client wants replay protection" - it also means "the client would like
to get a fresh response". Because otherwise replay attacks would not
matter.

-- 
Florian Oelmaier
SyTrust




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAS02nib091186 for <[e-mail]>; Thu, 27 Nov 2003 16:02:49 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAS02naM091185 for ietf-pkix-bks; Thu, 27 Nov 2003 16:02:49 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from sigurd.x509.com ([199.175.155.2]) by above.proper.com (8.12.10/8.12.8) with SMTP id hAS02mib091179 for <[e-mail]>; Thu, 27 Nov 2003 16:02:48 -0800 (PST) (envelope-from [e-mail])
Received: from nebula.x509.com by sigurd.x509.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 28 Nov 2003 00:02:50 UT
Received: from crack.x509.com (localhost [127.0.0.1]) by nebula.x509.com (8.12.10/NULL) with ESMTP id hARNws6L017084 for <[e-mail]>; Thu, 27 Nov 2003 15:58:54 -0800 (PST)
Received: from exvan01.x509.com (exvan01.x509.com [10.9.22.50]) by crack.x509.com (8.12.10/8.12.10) with ESMTP id hAS02nY0028932 for <[e-mail]>; Thu, 27 Nov 2003 16:02:49 -0800 (PST)
Received: from rsasecurity.com (mbranchaud2.eng.x509.com [10.7.33.48]) by exvan01.x509.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id VQFWG8ZV; Thu, 27 Nov 2003 16:11:40 -0800
Message-ID: <[e-mail]>
Date: Thu, 27 Nov 2003 15:53:12 -0800
X-Sybari-Trust: d2cce05a 64c784fd c3b38011 00000139
From: Marc Branchaud <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031110
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: DISCUSS:  MUST  reject in OCSPv1
References: <002101c3b53f$869821b0$4228a8c0@hagen>
In-Reply-To: <002101c3b53f$869821b0$4228a8c0@hagen>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020802090503030700060305"
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.

--------------ms020802090503030700060305
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Florian Oelmaier wrote:
> 
>>>I object. It breaks running code in installations.
>>
>>That code is not secure, and did not follow the spec.
> 
> Accept it or not, but even code not using nonces is secure! At least as
> secure as using CRLs. And definitely better than not checking revocation
> at all.

Yes, it is just as secure as using CRLs.  CRLs are also vulnerable to 
replay attacks.  OCSP has a mechanism - nonces - to thwart replay 
attacks.  Code that abuses (or just doesn't use) that mechanism is 
insecure against replay attacks.

> If we follow the path of your arguments, we should make nonce a
> requirement in OCSP.

Not at all.  Many environments are perfectly fine with the risk of 
replay attacks.

> Seeing the TLS OCSP extensions this renders OCSP
> unusable.

I don't see how that follows.

> If we agree that pre-produced responses are reasonable for
> some use-cases, then you cannot argue that code accepting nonce-less
> responses is not secure.

That's not my argument.  The crux is whether a nonce is in the request.

If the request as a nonce, then the response MUST echo the nonce and the 
client MUST reject a nonceless response.  Why?  Because nonces are how 
OCSP prevents replay attacks.  To act any other way fails to prevent 
replay attacks.

However, if the request does _not_ have a nonce, then the client is 
perfectly free to accept nonceless (or nonceful) responses.

> Most clients are concerned about replay attacks.

Not the ones that don't care about nonces in responses.

> But the first priority
> of an OCSP-client is to get secure revocation information (at least the
> same quality as a CRL). If the client is also able to get replay
> protection, fine!

If the client puts a nonce in a request and doesn't behave differently 
depending on the presence/absence of the nonce in the response, then why 
put the nonce in at all?

>>Nearly all protocols out there are insecure.  This is a security WG...
> 
> [A rant?] Tell that to the TLS and the IPSEC guys. Feature-fallback and
> security are not mutually exclusive.

Nonces are not a feature-fallback mechanism.  Nonces prevent replay 
attacks.  If you want feature-fallback, you need to carefully consider 
the mechanism(s) you use.  Overloading the use of nonces as OCSPv1 
progresses up the standards track is wrong, ill-advised and insecure.

		M.

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISqTCC
AtcwggJAoAMCAQICEFgUQCxch7Sxp7XFFauIqpwwDQYJKoZIhvcNAQEFBQAwbDEaMBgGA1UE
ChMRUlNBIFNlY3VyaXR5IEluYy4xHjAcBgNVBAMTFVJTQSBQdWJsaWMgUm9vdCBDQSB2MTEu
MCwGCSqGSIb3DQEJARYfcnNha2VvbnJvb3RzaWduQHJzYXNlY3VyaXR5LmNvbTAeFw0wMjA5
MDYxNDEzNTJaFw0wNzA5MDYxNDEzNTJaMIGCMRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5j
LjEVMBMGA1UECxMMS0NBIFNlcnZpY2VzMRYwFAYDVQQDEw1SU0EgQ29ycG9yYXRlMRAwDgYD
VQQHEwdCZWRmb3JkMRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMQswCQYDVQQGEwJVUzCBnzAN
BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAqnOw876lPpMTkSqrqzpEON/609PDLEhmWX4tkC19
AHneDaoetL277GtYYXBCggP2E+s66MN1ccWXyApfWjCZkIHepPC08NVI1JRcbViW3kwLzDD2
w5T9QJcyL5V1pN/LQdxahM56TiLeXlPiJekdmTdJoo+5Pw4bQU+MxTqURk8CAwEAAaNjMGEw
HwYDVR0jBBgwFoAU9UwxelEDPyzXi5eZb6hxkKt4PZswHQYDVR0OBBYEFO2RCGt0t1lKkvah
HSJwJp8KrxaSMA8GA1UdEwQIMAYBAf8CAQMwDgYDVR0PAQH/BAQDAgGGMA0GCSqGSIb3DQEB
BQUAA4GBAHiSe1a79hnPr16PuBwUTBWbuNQ4GJNsyfrCXzAswIT2A2WtGZ1Hp1jEAWi9OfAX
IYAdy52Jyv9N87wAEbLUgVmsFEIlYM5mi6ag7YIRGp8JP5UhLAN9O5YHrR9FsrGK4WmSl3sY
W1qAPOXubFcfhTgUDIYzM30izZBP4nwO07FpMIIC+DCCAmGgAwIBAgIQeuiOriTayCwjwpmR
gmdIUjANBgkqhkiG9w0BAQUFADCBgjEaMBgGA1UEChMRUlNBIFNlY3VyaXR5IEluYy4xFTAT
BgNVBAsTDEtDQSBTZXJ2aWNlczEWMBQGA1UEAxMNUlNBIENvcnBvcmF0ZTEQMA4GA1UEBxMH
QmVkZm9yZDEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMwHhcNMDIwOTIz
MTkxMzAzWhcNMDYwOTIzMTUxMzAzWjCBjDEaMBgGA1UEChMRUlNBIFNlY3VyaXR5IEluYy4x
FTATBgNVBAsTDEtDQSBTZXJ2aWNlczEgMB4GA1UEAxMXUlNBIENsYXNzIDIgUGVyc29uYWwg
Q0ExEDAOBgNVBAcTB0JlZGZvcmQxFjAUBgNVBAgTDU1hc3NhY2h1c2V0dHMxCzAJBgNVBAYT
AlVTMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCkR9yiabyRo6+NwC3Sl8wPuUiBD3rP
sENNjXvzSbTAyXA8pDDndnlAa1nLUhSMgvn8g1sYMd0Bp+C1/mI5PFUZ8jukUK95yt+TK26L
hM/M5RUq/EINdDDdWzg9je498K6oGfyWR6ETSJbIrDe5qQcLCABs9E2gVKb7Z/FwFo3C9QID
AQABo2MwYTAPBgNVHRMECDAGAQH/AgECMA4GA1UdDwEB/wQEAwIBhjAfBgNVHSMEGDAWgBTt
kQhrdLdZSpL2oR0icCafCq8WkjAdBgNVHQ4EFgQUxpPuxqX+41WOz4ojH+6Y3iHyn6cwDQYJ
KoZIhvcNAQEFBQADgYEAcdRHBjq8GfdDoutUTJPtSzQd7XsdsQh2KBbu8utl92VQHuI0J5wc
Rc817G8YbmTtCt/xqAzrr6k7fdaoDBr/kBuVHA5FEJ94foPgrOlbT3zdziMATXh5ESSDLMx6
p8ITIsTJNmwszIG5P9AAKJCW48gu1ZZmLXhFbHcYJGf99pwwggMFMIICbqADAgECAhEAvhyf
0s21hKaAc2Nm1WX4LTANBgkqhkiG9w0BAQUFADCBuzEkMCIGA1UEBxMbVmFsaUNlcnQgVmFs
aWRhdGlvbiBOZXR3b3JrMRcwFQYDVQQKEw5WYWxpQ2VydCwgSW5jLjE1MDMGA1UECxMsVmFs
aUNlcnQgQ2xhc3MgMyBQb2xpY3kgVmFsaWRhdGlvbiBBdXRob3JpdHkxITAfBgNVBAMTGGh0
dHA6Ly93d3cudmFsaWNlcnQuY29tLzEgMB4GCSqGSIb3DQEJARYRaW5mb0B2YWxpY2VydC5j
b20wHhcNMDIwNDMwMTUzMDE5WhcNMTkwNDMwMDkyMTU1WjBsMRowGAYDVQQKExFSU0EgU2Vj
dXJpdHkgSW5jLjEeMBwGA1UEAxMVUlNBIFB1YmxpYyBSb290IENBIHYxMS4wLAYJKoZIhvcN
AQkBFh9yc2FrZW9ucm9vdHNpZ25AcnNhc2VjdXJpdHkuY29tMIGfMA0GCSqGSIb3DQEBAQUA
A4GNADCBiQKBgQC0dSVa2EQ740GxqiIKsHATT4f8XYwUU23pzRe5W6IVpt4jkwDWkgnvTcP6
M8PD4OfK6Imal4hAH/c3K/dUIH7YyQZRGAE5Y27G5klZYKidcFlrfautgVES170MLKFmJqym
2FWAfVOibXatRcw7B0S+mP9404jID/MaIpRXkH5JjwIDAQABo1cwVTAMBgNVHRMEBTADAQH/
MA4GA1UdDwEB/wQEAwIBhjAWBgNVHSAEDzANMAsGCSqGSIb3DQUGATAdBgNVHQ4EFgQU9Uwx
elEDPyzXi5eZb6hxkKt4PZswDQYJKoZIhvcNAQEFBQADgYEAKsviXBc1FeBT2hIwyWuGwnPZ
J9ctjrsO7NbVLjsx/EYclFFGwo+pphiwdUTml9yd7fXzfk0D+7LOs9ZA5xhiHVrGusV4OW4i
7hx2KVILkYlcXCN5tDltKwa5+BkGUuvZdyAoIhpyf61h7uKCFguhaJ+VOiNB4DPtsmxI+KxO
E6YwggTYMIIEQaADAgECAhBgzHl9dAoZGu0JMqXovSgdMA0GCSqGSIb3DQEBBQUAMIGMMRow
GAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEVMBMGA1UECxMMS0NBIFNlcnZpY2VzMSAwHgYD
VQQDExdSU0EgQ2xhc3MgMiBQZXJzb25hbCBDQTEQMA4GA1UEBxMHQmVkZm9yZDEWMBQGA1UE
CBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMwHhcNMDMwNzA3MjMwODEzWhcNMDQwNzA3
MjMwODEzWjCBvjETMBEGCgmSJomT8ixkARkWA2NvbTEbMBkGCgmSJomT8ixkARkWC3JzYXNl
Y3VyaXR5MRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEWMBQGA1UECxMNTm9ydGggQW1l
cmljYTEUMBIGA1UECxMLRW5naW5lZXJpbmcxFzAVBgNVBAMTDk1hcmMgQnJhbmNoYXVkMScw
JQYJKoZIhvcNAQkBFhhtYXJjbmFyY0Byc2FzZWN1cml0eS5jb20wggEiMA0GCSqGSIb3DQEB
AQUAA4IBDwAwggEKAoIBAQDg2xoRr+a/dtnuFG+oTHa+tGtzeObFazNhYV2iSLNED4fHRu86
tknBYFgXggcHW5gsyjfkCtVMzP2tCivmbJgvISo36vsCsmAJH6LRnJf8HsvfmWZaD9tzhDpL
QVsBHr88J0ZMdVniRc7MQoYeu/3hYtUBeGO9bGA6T8vTrnXYonnFtVoTqE62SFqPZZk7HpCS
X1n+dM3zSym2ylMFYE14nukF4I9vAhsQVzk3QNpghmzGj8uoEy9xpf3k0o5+neneAGvcSkwo
r1mH5tSqhrEQaZp7vuSA2bvXaZEnjZzZiTpPDzs1oMpn3guzYhU7wMKz6xvwvgEYyAAV+P5n
FWM/AgMBAAGjggGBMIIBfTCBkgYDVR0gBIGKMIGHMIGEBgkqhkiG9w0FBwIwdzAuBggrBgEF
BQcCARYiaHR0cDovL2NhLnJzYXNlY3VyaXR5LmNvbS9DUFMuaHRtbDBFBggrBgEFBQcCAjA5
MBgWEVJTQSBTZWN1cml0eSBJbmMuMAMCAQEaHUNQUyBJbmNvcnBvcmF0ZWQgYnkgcmVmZXJl
bmNlMCkGA1UdJQQiMCAGCisGAQQBgjcUAgIGCCsGAQUFBwMCBggrBgEFBQcDBDAjBgNVHREE
HDAagRhtYXJjbmFyY0Byc2FzZWN1cml0eS5jb20wDgYDVR0PAQH/BAQDAgeAMEYGA1UdHwQ/
MD0wO6A5oDeGNWh0dHA6Ly9jcmwucnNhc2VjdXJpdHkuY29tOjgwL1JTQUNsYXNzMlBlcnNv
bmFsQ0EuY3JsMB8GA1UdIwQYMBaAFMaT7sal/uNVjs+KIx/umN4h8p+nMB0GA1UdDgQWBBQ1
yQ/UrvKb563LjzHqJzBzrZp/ejANBgkqhkiG9w0BAQUFAAOBgQCV82oGGnglQQzklKg/wKhy
evNeJ6FNBZFhLlmZRNlKgqvPFmBcxygfBGpHqIhsHcrt2/AjhJuzAj7UdW1vTVCY5MkZw8P9
6+J6aTc3bNlGbk0jvcvVgDhmM4xYJLwMZKEw92HlRhfuMnj7ah9DTqbKSewmyAyOc+FLpGfd
lu6CgTCCBOkwggRSoAMCAQICEQDqxAXqre9Mr+FeYw3+MQhsMA0GCSqGSIb3DQEBBQUAMIGM
MRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEVMBMGA1UECxMMS0NBIFNlcnZpY2VzMSAw
HgYDVQQDExdSU0EgQ2xhc3MgMiBQZXJzb25hbCBDQTEQMA4GA1UEBxMHQmVkZm9yZDEWMBQG
A1UECBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMwHhcNMDMwNzA3MjMwODI4WhcNMDQw
NzA3MjMwODEzWjCBwjETMBEGCgmSJomT8ixkARkWA2NvbTEbMBkGCgmSJomT8ixkARkWC3Jz
YXNlY3VyaXR5MRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEWMBQGA1UECxMNTm9ydGgg
QW1lcmljYTEUMBIGA1UECxMLRW5naW5lZXJpbmcxGzAZBgNVBAMTEk1hcmMgQnJhbmNoYXVk
LUVuYzEnMCUGCSqGSIb3DQEJARYYbWFyY25hcmNAcnNhc2VjdXJpdHkuY29tMIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwBjNaHTwtCXpdJg+iDxYMkWjuZIF0ic2fRLymZe+
BnZYWPnik0dFmTulx+V8slsLEtBllcc5o1yfIYfeHPinwRxv86kCUSlgfGGXKjJZaIeURgbo
bUbIfDTPlvRUZuiZvTR4C8tEY88Lle66n62B7wjUvDbiwK4EjzlXOkjpcYXLH7FbaFaRLDBB
PlFD5ydDRhQ67t6fjUeS7p7o/l/VHmPC5LFLXZkjEhjGd5pknbQIAbUGACL5UET85NUFPowD
3F47g0GCKEnuOsk2Ra+WHu7honhIxqmOwGnu85V6tW5xscf4dTofWZONQeaD3gSxv8+hcfKN
k9cwjpnUG2xGzwIDAQABo4IBjTCCAYkwNQYDVR0lBC4wLAYKKwYBBAGCNxQCAgYIKwYBBQUH
AwIGCCsGAQUFBwMEBgorBgEEAYI3CgMEMIGSBgNVHSAEgYowgYcwgYQGCSqGSIb3DQUHAjB3
MC4GCCsGAQUFBwIBFiJodHRwOi8vY2EucnNhc2VjdXJpdHkuY29tL0NQUy5odG1sMEUGCCsG
AQUFBwICMDkwGBYRUlNBIFNlY3VyaXR5IEluYy4wAwIBARodQ1BTIEluY29ycG9yYXRlZCBi
eSByZWZlcmVuY2UwIwYDVR0RBBwwGoEYbWFyY25hcmNAcnNhc2VjdXJpdHkuY29tMEYGA1Ud
HwQ/MD0wO6A5oDeGNWh0dHA6Ly9jcmwucnNhc2VjdXJpdHkuY29tOjgwL1JTQUNsYXNzMlBl
cnNvbmFsQ0EuY3JsMB8GA1UdIwQYMBaAFMaT7sal/uNVjs+KIx/umN4h8p+nMB0GA1UdDgQW
BBT/OiMCyY8CPnNBySW1ijJOYhj7ejAOBgNVHQ8BAf8EBAMCAzgwDQYJKoZIhvcNAQEFBQAD
gYEAlchAObA9eVmeiLu0nTU985Fch6v+EZKodUhZUN7dILgd05HorHN9jxBH6XI4/b9ZVvub
Pkpicdc112YbcLYTD2NumVksyNDI7fDaqiszgk1zluXtZJ+HsCt+GIAKCDfOVLECclpGyizq
VjZFEK4Pt9FxPGTnUJEvIKJcAQ24EvgxggPsMIID6AIBATCBoTCBjDEaMBgGA1UEChMRUlNB
IFNlY3VyaXR5IEluYy4xFTATBgNVBAsTDEtDQSBTZXJ2aWNlczEgMB4GA1UEAxMXUlNBIENs
YXNzIDIgUGVyc29uYWwgQ0ExEDAOBgNVBAcTB0JlZGZvcmQxFjAUBgNVBAgTDU1hc3NhY2h1
c2V0dHMxCzAJBgNVBAYTAlVTAhBgzHl9dAoZGu0JMqXovSgdMAkGBSsOAwIaBQCgggIfMBgG
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMTEyNzIzNTMxMlow
IwYJKoZIhvcNAQkEMRYEFLW2dYaf1IqBY/ZioLQGJckNxmxhMFIGCSqGSIb3DQEJDzFFMEMw
CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G
CCqGSIb3DQMCAgEoMIGzBgkrBgEEAYI3EAQxgaUwgaIwgYwxGjAYBgNVBAoTEVJTQSBTZWN1
cml0eSBJbmMuMRUwEwYDVQQLEwxLQ0EgU2VydmljZXMxIDAeBgNVBAMTF1JTQSBDbGFzcyAy
IFBlcnNvbmFsIENBMRAwDgYDVQQHEwdCZWRmb3JkMRYwFAYDVQQIEw1NYXNzYWNodXNldHRz
MQswCQYDVQQGEwJVUwIRAOrEBeqt70yv4V5jDf4xCGwwgbUGCyqGSIb3DQEJEAILMYGloIGi
MIGMMRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEVMBMGA1UECxMMS0NBIFNlcnZpY2Vz
MSAwHgYDVQQDExdSU0EgQ2xhc3MgMiBQZXJzb25hbCBDQTEQMA4GA1UEBxMHQmVkZm9yZDEW
MBQGA1UECBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMCEQDqxAXqre9Mr+FeYw3+MQhs
MA0GCSqGSIb3DQEBAQUABIIBAHekN1TmYFMZYaSnXjLIenW+E6g/oEtdeiTaNwLraITq/+1+
5eMEw52yMiljaTQcIAzn/xe3v+vaUmA4doOWyiXJIyrFxnJlSzL9B+aYiCxlDY7p+qRQ9usS
tnn5HHPn1bkUNScFHKEBFrxKEOyjouCQWVaCDLd2A6zjnsjqUoKfIp5wkNRojGjxHgWiRYry
rnQbmnKzlGz6z5NosZz5tMwzu20jsuIBlqlcEjBk85msEiej9VAkbCzd3TMEtnVDj+l8Zj67
X8e8GAe2/YR7K4thCpsxvhYkJYaZ0ZfLruTu8P094K4iR2HWu8wzUsVWPpnLBFXlQ2F7IbfJ
ejbX+GoAAAAAAAA=
--------------ms020802090503030700060305--


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hARNu9ib090669 for <[e-mail]>; Thu, 27 Nov 2003 15:56:09 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hARNu9LA090668 for ietf-pkix-bks; Thu, 27 Nov 2003 15:56:09 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hARNu8ib090663 for <[e-mail]>; Thu, 27 Nov 2003 15:56:08 -0800 (PST) (envelope-from [e-mail])
Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 27 Nov 2003 15:56:08 -0800
Received: from 157.54.8.155 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 27 Nov 2003 15:56:05 -0800
Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 27 Nov 2003 15:56:05 -0800
Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 27 Nov 2003 15:56:23 -0800
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 27 Nov 2003 15:55:54 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.7122.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary"
Subject: RE: DISCUSS:  MUST  reject in OCSPv1
Date: Thu, 27 Nov 2003 15:56:05 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: DISCUSS:  MUST  reject in OCSPv1
Thread-Index: AcO1PgGXau6hplXtTXq1zqzdI/Xq+QAAo6mm
From: "Ryan M. Hurst" <[e-mail]>
To: "Marc Branchaud" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 27 Nov 2003 23:55:54.0764 (UTC) FILETIME=[FEBA74C0:01C3B541]
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.

--------------InterScan_NT_MIME_Boundary
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3B542.050B45F7"

------_=_NextPart_001_01C3B542.050B45F7
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

cil

________________________________

From: [e-mail] on behalf of Marc Branchaud
Sent: Thu 11/27/2003 1:49 PM
To: [e-mail]
Subject: Re: DISCUSS: MUST reject in OCSPv1



Ryan M. Hurst wrote:
>
>> Why can't the client can decide this before making the request?
>
> [rmh] There are several cases; consider this one, bookstore.com
> (server) has a certificate from bigttp.com, client is connecting to
> bookstore.com and both the client and the server in this scenario
> support the new tls extensions allowing a server to provide a client
> a copy of its ocsp response (from bigttp.com). The server would want
> to keep a local copy of the ocsp response, he would also want to
> re-fresh this cached copy before passing it off to the client if he
> knew it was expired or about to be expired. He could when generating
> his OCSP request to bigttp.com include a nonce indicating he wants a
> fresh response (afterall this is implicit when asking for the nonce
> in the response). Since in this case all the server wants is a fresh
> response (he will be caching and replaying afterall) getting back a
> respone without a nonce is OK.

No, it's not OK.

First off, the nonce is _not_ an indication that the server wants a
fresh response.  Like the RFC says, it's an indication that the server
doesn't want to be replayed a previous response.  Even with the nonce,
there's nothing to stop the bigttp.com OCSP server from giving the
server a status value based on yesterday's CRL.
[rmh] Never said that was the explicit intent of the nonce, it is a side =
effect; even if bigttp.com gave a response that was based on a CRL it =
would still be the freshest response possible.


Second, if the server accepts a nonceless response not only is it not
guaranteeing that it gets a "fresh" response, but it's also at risk of
getting a replayed response.  Again, the nonce (or rather, its
absence/presence in the response) does nothing to guanrantee any kind of
"freshness".  By accepting nonceless responses the server could even
accept the same response it already has.  If the server's OK with that,
then there's no point in putting a nonce in the request in the first =
place.
[rmh] Replay is the goal in this scenario, e.g. intermediate caching so =
I am not sure I get your point. As to the guarantees in OCSP the only =
garontees in the protocol (asuming a accepted trust model) is that the =
status in the response given the constraints associated with it (time =
validity, etc.) are truthfull. My point in the scenario above (and I =
imagine this being a VERY common scenario) is that for the likley side =
effect of submiting a nonced request is that you will get the freshes =
informationa availible; no gaurantees but it incredibly likley.


> The alternative with the proposed text would be to make a request
> with the nonce, get denied and make another one; resulting in two
> wire retrievals instead of one like the original version of the RFC
> allowed for.

There's more than one alternative.

A more reasonable approach would for the server to not put a nonce in
the request in the first place.  This results in a single over-the-wire
transaction that meets the security parameters the server is willing to
live with.

[rmh] Sure, if you dont care about the scenario in question that would =
work; the front end server would likley be a pre-produced responder (and =
in this case that is very likley, espectialy if you wanted to scale to =
support internet scale revocation checking); the likley behavior if such =
a responder got a request with a nonce is that it would try to service =
it either by using its own key material to produce a fresh response or =
more likley forward the request to a back end server that would do just =
that.

>> What does the client gain by making a nonced request but accepting
>> a nonceless response?
>
> [rmh] there are several, consider the above; we must remember what
> the nonce means; directly it means I would like to try to protect
> myself from replays; ok, so what is a replay? a stale response; so it
> also means give me the freshest data you have.

No, it doesn't mean that at all.  The OCSP server is still free to
construct a response based on whatever data it sees fit.  All the nonce
does is force the server to sign a new response.  It doesn't say
anything about how "fresh" the data is in that response.

[rmh] I did not say it did, and in this case its not about guarantees.


> If the group wishes to address the use of nonces for more than replay
>  prevention, then I think the only option is to devise a new OCSPv2
> spec.
>
> [rmh] its not necesssary, the current RFC works and by changing the
> semantics you disallow a legitimate use that worked and was
> conformant.

But that use wasn't conformant.  All that RFC2560 wants to use nonces
for is to prevent replay attacks.  Any other use of nonces goes beyond
what RFC2560 says they're for.

[rmh] it absolutley is; find the text that precludes this behavior.

                M.



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

<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">=0A=
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">=0A=
<HTML>=0A=
<HEAD>=0A=
=0A=
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7122.0">=0A=
<TITLE>Re: DISCUSS:  MUST  reject in OCSPv1</TITLE>=0A=
</HEAD>=0A=
<BODY>=0A=
<DIV id=3DidOWAReplyText95022 dir=3Dltr>=0A=
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 =
size=3D2>cil</FONT></DIV></DIV>=0A=
<DIV dir=3Dltr><BR>=0A=
<HR tabIndex=3D-1>=0A=
<FONT face=3DTahoma size=3D2><B>From:</B> [e-mail] =
on behalf of =0A=
Marc Branchaud<BR><B>Sent:</B> Thu 11/27/2003 1:49 PM<BR><B>To:</B> =0A=
[e-mail]<BR><B>Subject:</B> Re: DISCUSS: MUST reject in =0A=
OCSPv1<BR></FONT><BR></DIV>=0A=
<DIV>=0A=
<P><FONT size=3D2>Ryan M. Hurst wrote:<BR>&gt;<BR>&gt;&gt; Why can't the =
client =0A=
can decide this before making the request?<BR>&gt;<BR>&gt; [rmh] There =
are =0A=
several cases; consider this one, bookstore.com<BR>&gt; (server) has a =0A=
certificate from bigttp.com, client is connecting to<BR>&gt; =
bookstore.com and =0A=
both the client and the server in this scenario<BR>&gt; support the new =
tls =0A=
extensions allowing a server to provide a client<BR>&gt; a copy of its =
ocsp =0A=
response (from bigttp.com). The server would want<BR>&gt; to keep a =
local copy =0A=
of the ocsp response, he would also want to<BR>&gt; re-fresh this cached =
copy =0A=
before passing it off to the client if he<BR>&gt; knew it was expired or =
about =0A=
to be expired. He could when generating<BR>&gt; his OCSP request to =
bigttp.com =0A=
include a nonce indicating he wants a<BR>&gt; fresh response (afterall =
this is =0A=
implicit when asking for the nonce<BR>&gt; in the response). Since in =
this case =0A=
all the server wants is a fresh<BR>&gt; response (he will be caching and =0A=
replaying afterall) getting back a<BR>&gt; respone without a nonce is =0A=
OK.<BR><BR>No, it's not OK.<BR><BR>First off, the nonce is _not_ an =
indication =0A=
that the server wants a<BR>fresh response.&nbsp; Like the RFC says, it's =
an =0A=
indication that the server<BR>doesn't want to be replayed a previous =0A=
response.&nbsp; Even with the nonce,<BR>there's nothing to stop the =
bigttp.com =0A=
OCSP server from giving the<BR>server a status value based on =
yesterday's =0A=
CRL.<BR>[rmh] Never said that was the explicit intent of the nonce, it =
is a side =0A=
effect; even if bigttp.com gave a response that was based on a CRL it =
would =0A=
still be the freshest response possible.</FONT></P><FONT size=3D2>=0A=
<P><BR>Second, if the server accepts a nonceless response not only is it =0A=
not<BR>guaranteeing that it gets a "fresh" response, but it's also at =
risk =0A=
of<BR>getting a replayed response.&nbsp; Again, the nonce (or rather, =0A=
its<BR>absence/presence in the response) does nothing to guanrantee any =
kind =0A=
of<BR>"freshness".&nbsp; By accepting nonceless responses the server =
could =0A=
even<BR>accept the same response it already has.&nbsp; If the server's =
OK with =0A=
that,<BR>then there's no point in putting a nonce in the request in the =
first =0A=
place.<BR>[rmh] Replay is the goal in this scenario, e.g. intermediate =
caching =0A=
so I am not sure I get your point. As to the guarantees in OCSP the only =0A=
garontees in the protocol (asuming a accepted trust model) is that =0A=
the&nbsp;status in the response given the constraints associated with it =
(time =0A=
validity, etc.) are truthfull. My point in the scenario above (and I =
imagine =0A=
this being a VERY common scenario) is that for the likley side effect of =0A=
submiting a nonced request is that you will get the freshes informationa =0A=
availible; no gaurantees but it incredibly likley.</P>=0A=
<P><BR>&gt; The alternative with the proposed text would be to make a =0A=
request<BR>&gt; with the nonce, get denied and make another one; =
resulting in =0A=
two<BR>&gt; wire retrievals instead of one like the original version of =
the =0A=
RFC<BR>&gt; allowed for.<BR><BR>There's more than one =
alternative.<BR><BR>A more =0A=
reasonable approach would for the server to not put a nonce in<BR>the =
request in =0A=
the first place.&nbsp; This results in a single =
over-the-wire<BR>transaction =0A=
that meets the security parameters the server is willing to<BR>live =
with.</P>=0A=
<P>[rmh] Sure, if you dont care about the scenario in question that =
would work; =0A=
the front end server would likley be&nbsp;a pre-produced responder (and =
in this =0A=
case that is very likley, espectialy if you wanted to scale to support =
internet =0A=
scale revocation checking); the likley behavior if such a responder got =
a =0A=
request with a nonce is that it would try to service it either by using =
its own =0A=
key material to produce a fresh response or more likley forward the =
request to a =0A=
back end server that would do just that.<BR><BR>&gt;&gt; What does the =
client =0A=
gain by making a nonced request but accepting<BR>&gt;&gt; a nonceless =0A=
response?<BR>&gt;<BR>&gt; [rmh] there are several, consider the above; =
we must =0A=
remember what<BR>&gt; the nonce means; directly it means I would like to =
try to =0A=
protect<BR>&gt; myself from replays; ok, so what is a replay? a stale =
response; =0A=
so it<BR>&gt; also means give me the freshest data you have.<BR><BR>No, =
it =0A=
doesn't mean that at all.&nbsp; The OCSP server is still free =
to<BR>construct a =0A=
response based on whatever data it sees fit.&nbsp; All the nonce<BR>does =
is =0A=
force the server to sign a new response.&nbsp; It doesn't =
say<BR>anything about =0A=
how "fresh" the data is in that response.</P>=0A=
<P>[rmh] I did not say it did, and in this case its not about =0A=
guarantees.<BR><BR><BR>&gt; If the group wishes to address the use of =
nonces for =0A=
more than replay<BR>&gt;&nbsp; prevention, then I think the only option =
is to =0A=
devise a new OCSPv2<BR>&gt; spec.<BR>&gt;<BR>&gt; [rmh] its not =
necesssary, the =0A=
current RFC works and by changing the<BR>&gt; semantics you disallow a =0A=
legitimate use that worked and was<BR>&gt; conformant.<BR><BR>But that =
use =0A=
wasn't conformant.&nbsp; All that RFC2560 wants to use nonces<BR>for is =
to =0A=
prevent replay attacks.&nbsp; Any other use of nonces goes =
beyond<BR>what =0A=
RFC2560 says they're for.</P>=0A=
<P>[rmh] it absolutley is; find the text that precludes this =0A=
behavior.<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =0A=
M.<BR></P></FONT></DIV>=0A=
=0A=
</BODY>=0A=
</HTML>
------_=_NextPart_001_01C3B542.050B45F7--

--------------InterScan_NT_MIME_Boundary--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hARNd3ib089328 for <[e-mail]>; Thu, 27 Nov 2003 15:39:03 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hARNd3jO089327 for ietf-pkix-bks; Thu, 27 Nov 2003 15:39:03 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout07.sul.t-online.com (mailout07.sul.t-online.com [194.25.134.83]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hARNd1ib089322 for <[e-mail]>; Thu, 27 Nov 2003 15:39:01 -0800 (PST) (envelope-from [e-mail])
Received: from fwd05.aul.t-online.de  by mailout07.sul.t-online.com with smtp  id 1APViv-0005FJ-06; Fri, 28 Nov 2003 00:39:01 +0100
Received: from hagen (EB7BNyZpgemyjzEnp3SsPUnBt3a4OCCZ8dHU-iv7MpND3PjRu+cxZ1@[217.228.232.10]) by fmrl05.sul.t-online.com with esmtp id 1APViB-2CQjRI0; Fri, 28 Nov 2003 00:38:15 +0100
From: "Florian Oelmaier" <[e-mail]>
To: "'Marc Branchaud'" <[e-mail]>, <[e-mail]>
Subject: RE: DISCUSS:  MUST  reject in OCSPv1
Date: Fri, 28 Nov 2003 00:38:13 +0100
Organization: SyTrust
Message-ID: <002101c3b53f$869821b0$4228a8c0@hagen>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Seen: false
X-ID: [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>

Hello Marc,

> > I object. It breaks running code in installations.
> 
> That code is not secure, and did not follow the spec.

Accept it or not, but even code not using nonces is secure! At least as
secure as using CRLs. And definitely better than not checking revocation
at all.

If we follow the path of your arguments, we should make nonce a
requirement in OCSP. Seeing the TLS OCSP extensions this renders OCSP
unusable. If we agree that pre-produced responses are reasonable for
some use-cases, then you cannot argue that code accepting nonce-less
responses is not secure.

> > Seeing this it is a very acceptable for a client to TRY to get a 
> > nonce, but to accept answers without nonces as a fallback.
> 
> No, it is not acceptable.  The RFC is very clear: use nonces 
> to prevent 
> replay attacks.  If the client is concerned about replay attacks, it 
> must reject a nonceless response.

Most clients are concerned about replay attacks. But the first priority
of an OCSP-client is to get secure revocation information (at least the
same quality as a CRL). If the client is also able to get replay
protection, fine!

> > It is a "natural"
> > behaviour - I try for all extensions I support, but will 
> fall back to 
> > the very basics of the standard, to the "not extended" 
> behaviour when 
> > I cannot get what I want. This is the usual way of doing things in 
> > nearly all protocols out there, PKIX or not.
> 
> Nearly all protocols out there are insecure.  This is a security WG...

[A rant?] Tell that to the TLS and the IPSEC guys. Feature-fallback and
security are not mutually exclusive.




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hARNQPib088458 for <[e-mail]>; Thu, 27 Nov 2003 15:26:25 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hARNQPAO088457 for ietf-pkix-bks; Thu, 27 Nov 2003 15:26:25 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout08.sul.t-online.com (mailout08.sul.t-online.com [194.25.134.20]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hARNQLib088451 for <[e-mail]>; Thu, 27 Nov 2003 15:26:23 -0800 (PST) (envelope-from [e-mail])
Received: from fwd05.aul.t-online.de  by mailout08.sul.t-online.com with smtp  id 1APVWg-0007l9-01; Fri, 28 Nov 2003 00:26:22 +0100
Received: from hagen (ZYPk1ZZYQeD53rMVSxZxF50HilA6kbaC1zLJbft2wmo9sqqRYc0xra@[217.228.232.10]) by fmrl05.sul.t-online.com with esmtp id 1APVWT-0WEqVU0; Fri, 28 Nov 2003 00:26:09 +0100
From: "Florian Oelmaier" <[e-mail]>
To: "'Michael Myers'" <[e-mail]>, <[e-mail]>
Subject: RE: DISCUSS:  MUST  reject in OCSPv1
Date: Fri, 28 Nov 2003 00:26:07 +0100
Organization: SyTrust
Message-ID: <000b01c3b53d$d5cbed90$4228a8c0@hagen>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Seen: false
X-ID: [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 love it. It will be implemented as soon as possible in our client and
server.

This also opens up a lot of very valuable use-cases in combination with
the TLS OCSP extension!

-- 
Florian Oelmaier
SyTrust


> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Michael Myers
> Sent: Thursday, November 27, 2003 9:32 PM
> To: [e-mail]
> Subject: RE: DISCUSS: MUST reject in OCSPv1
> 
> 
> 
> 
> If anyone objects to the path forward as discussed below, 
> please speak up now.  Concurrence is equally welcome.
> 
> Mike
> 
> 
> > -----Original Message-----
> > From: [e-mail] 
> > [mailto:[e-mail]]On Behalf Of David Engberg
> > Sent: Thursday, November 27, 2003 12:46 PM
> > To: Michael Myers
> > Cc: [e-mail]
> > Subject: Re: DISCUSS: MUST reject in OCSPv1
> >
> >
> >
> >
> > Exactly.  I'd implement this right now if I wasn't so
> > full of turkey.
> >
> >
> > Michael Myers wrote:
> > >
> > > Understand your caching servers MUST send back a caveated 
> response 
> > > which by presence of the caveat may or may not be 
> accepted.  No fair 
> > > sending back plain ones, errors notwithstanding.  Is this 
> > > understood?
> > >
> > > Mike
> > >
> > >
> > >>-----Original Message-----
> > >>From: David Engberg [mailto:[e-mail]]
> > >>Sent: Thursday, November 27, 2003 12:25 PM
> > >>To: Michael Myers
> > >>Cc: [e-mail]
> > >>Subject: Re: DISCUSS: MUST reject in OCSPv1
> > >>
> > >>
> > >>
> > >>I'd add "or return an error [e.g. unauthorized?]" to
> > >>the end of '4' (to
> > >>remain compliant in the presence of requests for
> > >>unknown certs), but it
> > >>is otherwise my dream scenario.
> > >>
> > >>
> > >>Michael Myers wrote:
> > >>
> > >>>Dave,
> > >>>
> > >>>So how about:
> > >>>
> > >>>1. If we can cycle v1 at Proposed (a big if); then
> > >>>
> > >>>2. Define nonceUnsupported extension subject to
> > >>>   the following semantics (I'm squeezing the
> > >>>   words a bit but you'll get the drift)
> > >>>
> > >>>3. Clients that send a nonce:
> > >>>
> > >>>   a. MUST reject a non-nonced response
> > >>>      if that response includes either the
> > >>>      value "good" or "revoked" AND it fails
> > >>>      to include the nonceUnsupported extension;
> > >>>
> > >>>   b. Else, if such response includes the
> > >>>      nonceUnsupported extension, clients
> > >>>      MAY accept the response subject to the
> > >>>      advice in the Security Considerations
> > >>>      section of this document.
> > >>>
> > >>>4. Conversely, if a server receives a nonced
> > >>>   request but is unable to incorporate the
> > >>>   nonce in its response, the server MUST
> > >>>   include the nonceUnsupported extension.
> > >>>
> > >>> Note that I made no distinction between "good",
> > >>> "revoked" or "unknown" in #3.b or #4.  Thus,
> > >>> a plain nonceless response of "good" or
> > >>> "revoked" is non-conformant, while a caveated
> > >>> response is subject to the client's local
> > >>> security policy.
> > >>>
> > >>> Does this seem a fair compromise?  Note well it's 
> highly dependent 
> > >>> on cycling v1 at Proposed.
> > >>>
> > >>> Mike
> > >
> > >
> > >
> >
> 
> 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hARNCZib087425 for <[e-mail]>; Thu, 27 Nov 2003 15:12:35 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hARNCZcM087424 for ietf-pkix-bks; Thu, 27 Nov 2003 15:12:35 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from sigurd.x509.com ([199.175.155.2]) by above.proper.com (8.12.10/8.12.8) with SMTP id hARNCYib087418 for <[e-mail]>; Thu, 27 Nov 2003 15:12:34 -0800 (PST) (envelope-from [e-mail])
Received: from nebula.x509.com by sigurd.x509.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 27 Nov 2003 23:12:36 UT
Received: from crack.x509.com (localhost [127.0.0.1]) by nebula.x509.com (8.12.10/NULL) with ESMTP id hARN8d6L016586 for <[e-mail]>; Thu, 27 Nov 2003 15:08:40 -0800 (PST)
Received: from exvan01.x509.com (exvan01.x509.com [10.9.22.50]) by crack.x509.com (8.12.10/8.12.10) with ESMTP id hARNCZY0025940 for <[e-mail]>; Thu, 27 Nov 2003 15:12:35 -0800 (PST)
Received: from rsasecurity.com (mbranchaud2.eng.x509.com [10.7.33.48]) by exvan01.x509.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id VQFWG7X7; Thu, 27 Nov 2003 15:21:26 -0800
Message-ID: <[e-mail]>
Date: Thu, 27 Nov 2003 15:02:58 -0800
X-Sybari-Trust: 30826219 64c784fd c3b38011 00000139
From: Marc Branchaud <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031110
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: DISCUSS:  MUST  reject in OCSPv1
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000801070905090402020205"
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.

--------------ms000801070905090402020205
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit


Michael Myers wrote:
> 
> If anyone objects to the path forward as discussed below, please
> speak up now.  Concurrence is equally welcome.

I'm indifferent to cycling at Proposed.

I'm not convinced that nonceUnsupported is needed at all.  It seems 
exactly the kind of baroque bloat PKIX is famous for (not that I have 
any new reason for the group to break with that tradition).

		M.

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISqTCC
AtcwggJAoAMCAQICEFgUQCxch7Sxp7XFFauIqpwwDQYJKoZIhvcNAQEFBQAwbDEaMBgGA1UE
ChMRUlNBIFNlY3VyaXR5IEluYy4xHjAcBgNVBAMTFVJTQSBQdWJsaWMgUm9vdCBDQSB2MTEu
MCwGCSqGSIb3DQEJARYfcnNha2VvbnJvb3RzaWduQHJzYXNlY3VyaXR5LmNvbTAeFw0wMjA5
MDYxNDEzNTJaFw0wNzA5MDYxNDEzNTJaMIGCMRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5j
LjEVMBMGA1UECxMMS0NBIFNlcnZpY2VzMRYwFAYDVQQDEw1SU0EgQ29ycG9yYXRlMRAwDgYD
VQQHEwdCZWRmb3JkMRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMQswCQYDVQQGEwJVUzCBnzAN
BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAqnOw876lPpMTkSqrqzpEON/609PDLEhmWX4tkC19
AHneDaoetL277GtYYXBCggP2E+s66MN1ccWXyApfWjCZkIHepPC08NVI1JRcbViW3kwLzDD2
w5T9QJcyL5V1pN/LQdxahM56TiLeXlPiJekdmTdJoo+5Pw4bQU+MxTqURk8CAwEAAaNjMGEw
HwYDVR0jBBgwFoAU9UwxelEDPyzXi5eZb6hxkKt4PZswHQYDVR0OBBYEFO2RCGt0t1lKkvah
HSJwJp8KrxaSMA8GA1UdEwQIMAYBAf8CAQMwDgYDVR0PAQH/BAQDAgGGMA0GCSqGSIb3DQEB
BQUAA4GBAHiSe1a79hnPr16PuBwUTBWbuNQ4GJNsyfrCXzAswIT2A2WtGZ1Hp1jEAWi9OfAX
IYAdy52Jyv9N87wAEbLUgVmsFEIlYM5mi6ag7YIRGp8JP5UhLAN9O5YHrR9FsrGK4WmSl3sY
W1qAPOXubFcfhTgUDIYzM30izZBP4nwO07FpMIIC+DCCAmGgAwIBAgIQeuiOriTayCwjwpmR
gmdIUjANBgkqhkiG9w0BAQUFADCBgjEaMBgGA1UEChMRUlNBIFNlY3VyaXR5IEluYy4xFTAT
BgNVBAsTDEtDQSBTZXJ2aWNlczEWMBQGA1UEAxMNUlNBIENvcnBvcmF0ZTEQMA4GA1UEBxMH
QmVkZm9yZDEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMwHhcNMDIwOTIz
MTkxMzAzWhcNMDYwOTIzMTUxMzAzWjCBjDEaMBgGA1UEChMRUlNBIFNlY3VyaXR5IEluYy4x
FTATBgNVBAsTDEtDQSBTZXJ2aWNlczEgMB4GA1UEAxMXUlNBIENsYXNzIDIgUGVyc29uYWwg
Q0ExEDAOBgNVBAcTB0JlZGZvcmQxFjAUBgNVBAgTDU1hc3NhY2h1c2V0dHMxCzAJBgNVBAYT
AlVTMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCkR9yiabyRo6+NwC3Sl8wPuUiBD3rP
sENNjXvzSbTAyXA8pDDndnlAa1nLUhSMgvn8g1sYMd0Bp+C1/mI5PFUZ8jukUK95yt+TK26L
hM/M5RUq/EINdDDdWzg9je498K6oGfyWR6ETSJbIrDe5qQcLCABs9E2gVKb7Z/FwFo3C9QID
AQABo2MwYTAPBgNVHRMECDAGAQH/AgECMA4GA1UdDwEB/wQEAwIBhjAfBgNVHSMEGDAWgBTt
kQhrdLdZSpL2oR0icCafCq8WkjAdBgNVHQ4EFgQUxpPuxqX+41WOz4ojH+6Y3iHyn6cwDQYJ
KoZIhvcNAQEFBQADgYEAcdRHBjq8GfdDoutUTJPtSzQd7XsdsQh2KBbu8utl92VQHuI0J5wc
Rc817G8YbmTtCt/xqAzrr6k7fdaoDBr/kBuVHA5FEJ94foPgrOlbT3zdziMATXh5ESSDLMx6
p8ITIsTJNmwszIG5P9AAKJCW48gu1ZZmLXhFbHcYJGf99pwwggMFMIICbqADAgECAhEAvhyf
0s21hKaAc2Nm1WX4LTANBgkqhkiG9w0BAQUFADCBuzEkMCIGA1UEBxMbVmFsaUNlcnQgVmFs
aWRhdGlvbiBOZXR3b3JrMRcwFQYDVQQKEw5WYWxpQ2VydCwgSW5jLjE1MDMGA1UECxMsVmFs
aUNlcnQgQ2xhc3MgMyBQb2xpY3kgVmFsaWRhdGlvbiBBdXRob3JpdHkxITAfBgNVBAMTGGh0
dHA6Ly93d3cudmFsaWNlcnQuY29tLzEgMB4GCSqGSIb3DQEJARYRaW5mb0B2YWxpY2VydC5j
b20wHhcNMDIwNDMwMTUzMDE5WhcNMTkwNDMwMDkyMTU1WjBsMRowGAYDVQQKExFSU0EgU2Vj
dXJpdHkgSW5jLjEeMBwGA1UEAxMVUlNBIFB1YmxpYyBSb290IENBIHYxMS4wLAYJKoZIhvcN
AQkBFh9yc2FrZW9ucm9vdHNpZ25AcnNhc2VjdXJpdHkuY29tMIGfMA0GCSqGSIb3DQEBAQUA
A4GNADCBiQKBgQC0dSVa2EQ740GxqiIKsHATT4f8XYwUU23pzRe5W6IVpt4jkwDWkgnvTcP6
M8PD4OfK6Imal4hAH/c3K/dUIH7YyQZRGAE5Y27G5klZYKidcFlrfautgVES170MLKFmJqym
2FWAfVOibXatRcw7B0S+mP9404jID/MaIpRXkH5JjwIDAQABo1cwVTAMBgNVHRMEBTADAQH/
MA4GA1UdDwEB/wQEAwIBhjAWBgNVHSAEDzANMAsGCSqGSIb3DQUGATAdBgNVHQ4EFgQU9Uwx
elEDPyzXi5eZb6hxkKt4PZswDQYJKoZIhvcNAQEFBQADgYEAKsviXBc1FeBT2hIwyWuGwnPZ
J9ctjrsO7NbVLjsx/EYclFFGwo+pphiwdUTml9yd7fXzfk0D+7LOs9ZA5xhiHVrGusV4OW4i
7hx2KVILkYlcXCN5tDltKwa5+BkGUuvZdyAoIhpyf61h7uKCFguhaJ+VOiNB4DPtsmxI+KxO
E6YwggTYMIIEQaADAgECAhBgzHl9dAoZGu0JMqXovSgdMA0GCSqGSIb3DQEBBQUAMIGMMRow
GAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEVMBMGA1UECxMMS0NBIFNlcnZpY2VzMSAwHgYD
VQQDExdSU0EgQ2xhc3MgMiBQZXJzb25hbCBDQTEQMA4GA1UEBxMHQmVkZm9yZDEWMBQGA1UE
CBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMwHhcNMDMwNzA3MjMwODEzWhcNMDQwNzA3
MjMwODEzWjCBvjETMBEGCgmSJomT8ixkARkWA2NvbTEbMBkGCgmSJomT8ixkARkWC3JzYXNl
Y3VyaXR5MRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEWMBQGA1UECxMNTm9ydGggQW1l
cmljYTEUMBIGA1UECxMLRW5naW5lZXJpbmcxFzAVBgNVBAMTDk1hcmMgQnJhbmNoYXVkMScw
JQYJKoZIhvcNAQkBFhhtYXJjbmFyY0Byc2FzZWN1cml0eS5jb20wggEiMA0GCSqGSIb3DQEB
AQUAA4IBDwAwggEKAoIBAQDg2xoRr+a/dtnuFG+oTHa+tGtzeObFazNhYV2iSLNED4fHRu86
tknBYFgXggcHW5gsyjfkCtVMzP2tCivmbJgvISo36vsCsmAJH6LRnJf8HsvfmWZaD9tzhDpL
QVsBHr88J0ZMdVniRc7MQoYeu/3hYtUBeGO9bGA6T8vTrnXYonnFtVoTqE62SFqPZZk7HpCS
X1n+dM3zSym2ylMFYE14nukF4I9vAhsQVzk3QNpghmzGj8uoEy9xpf3k0o5+neneAGvcSkwo
r1mH5tSqhrEQaZp7vuSA2bvXaZEnjZzZiTpPDzs1oMpn3guzYhU7wMKz6xvwvgEYyAAV+P5n
FWM/AgMBAAGjggGBMIIBfTCBkgYDVR0gBIGKMIGHMIGEBgkqhkiG9w0FBwIwdzAuBggrBgEF
BQcCARYiaHR0cDovL2NhLnJzYXNlY3VyaXR5LmNvbS9DUFMuaHRtbDBFBggrBgEFBQcCAjA5
MBgWEVJTQSBTZWN1cml0eSBJbmMuMAMCAQEaHUNQUyBJbmNvcnBvcmF0ZWQgYnkgcmVmZXJl
bmNlMCkGA1UdJQQiMCAGCisGAQQBgjcUAgIGCCsGAQUFBwMCBggrBgEFBQcDBDAjBgNVHREE
HDAagRhtYXJjbmFyY0Byc2FzZWN1cml0eS5jb20wDgYDVR0PAQH/BAQDAgeAMEYGA1UdHwQ/
MD0wO6A5oDeGNWh0dHA6Ly9jcmwucnNhc2VjdXJpdHkuY29tOjgwL1JTQUNsYXNzMlBlcnNv
bmFsQ0EuY3JsMB8GA1UdIwQYMBaAFMaT7sal/uNVjs+KIx/umN4h8p+nMB0GA1UdDgQWBBQ1
yQ/UrvKb563LjzHqJzBzrZp/ejANBgkqhkiG9w0BAQUFAAOBgQCV82oGGnglQQzklKg/wKhy
evNeJ6FNBZFhLlmZRNlKgqvPFmBcxygfBGpHqIhsHcrt2/AjhJuzAj7UdW1vTVCY5MkZw8P9
6+J6aTc3bNlGbk0jvcvVgDhmM4xYJLwMZKEw92HlRhfuMnj7ah9DTqbKSewmyAyOc+FLpGfd
lu6CgTCCBOkwggRSoAMCAQICEQDqxAXqre9Mr+FeYw3+MQhsMA0GCSqGSIb3DQEBBQUAMIGM
MRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEVMBMGA1UECxMMS0NBIFNlcnZpY2VzMSAw
HgYDVQQDExdSU0EgQ2xhc3MgMiBQZXJzb25hbCBDQTEQMA4GA1UEBxMHQmVkZm9yZDEWMBQG
A1UECBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMwHhcNMDMwNzA3MjMwODI4WhcNMDQw
NzA3MjMwODEzWjCBwjETMBEGCgmSJomT8ixkARkWA2NvbTEbMBkGCgmSJomT8ixkARkWC3Jz
YXNlY3VyaXR5MRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEWMBQGA1UECxMNTm9ydGgg
QW1lcmljYTEUMBIGA1UECxMLRW5naW5lZXJpbmcxGzAZBgNVBAMTEk1hcmMgQnJhbmNoYXVk
LUVuYzEnMCUGCSqGSIb3DQEJARYYbWFyY25hcmNAcnNhc2VjdXJpdHkuY29tMIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwBjNaHTwtCXpdJg+iDxYMkWjuZIF0ic2fRLymZe+
BnZYWPnik0dFmTulx+V8slsLEtBllcc5o1yfIYfeHPinwRxv86kCUSlgfGGXKjJZaIeURgbo
bUbIfDTPlvRUZuiZvTR4C8tEY88Lle66n62B7wjUvDbiwK4EjzlXOkjpcYXLH7FbaFaRLDBB
PlFD5ydDRhQ67t6fjUeS7p7o/l/VHmPC5LFLXZkjEhjGd5pknbQIAbUGACL5UET85NUFPowD
3F47g0GCKEnuOsk2Ra+WHu7honhIxqmOwGnu85V6tW5xscf4dTofWZONQeaD3gSxv8+hcfKN
k9cwjpnUG2xGzwIDAQABo4IBjTCCAYkwNQYDVR0lBC4wLAYKKwYBBAGCNxQCAgYIKwYBBQUH
AwIGCCsGAQUFBwMEBgorBgEEAYI3CgMEMIGSBgNVHSAEgYowgYcwgYQGCSqGSIb3DQUHAjB3
MC4GCCsGAQUFBwIBFiJodHRwOi8vY2EucnNhc2VjdXJpdHkuY29tL0NQUy5odG1sMEUGCCsG
AQUFBwICMDkwGBYRUlNBIFNlY3VyaXR5IEluYy4wAwIBARodQ1BTIEluY29ycG9yYXRlZCBi
eSByZWZlcmVuY2UwIwYDVR0RBBwwGoEYbWFyY25hcmNAcnNhc2VjdXJpdHkuY29tMEYGA1Ud
HwQ/MD0wO6A5oDeGNWh0dHA6Ly9jcmwucnNhc2VjdXJpdHkuY29tOjgwL1JTQUNsYXNzMlBl
cnNvbmFsQ0EuY3JsMB8GA1UdIwQYMBaAFMaT7sal/uNVjs+KIx/umN4h8p+nMB0GA1UdDgQW
BBT/OiMCyY8CPnNBySW1ijJOYhj7ejAOBgNVHQ8BAf8EBAMCAzgwDQYJKoZIhvcNAQEFBQAD
gYEAlchAObA9eVmeiLu0nTU985Fch6v+EZKodUhZUN7dILgd05HorHN9jxBH6XI4/b9ZVvub
Pkpicdc112YbcLYTD2NumVksyNDI7fDaqiszgk1zluXtZJ+HsCt+GIAKCDfOVLECclpGyizq
VjZFEK4Pt9FxPGTnUJEvIKJcAQ24EvgxggPsMIID6AIBATCBoTCBjDEaMBgGA1UEChMRUlNB
IFNlY3VyaXR5IEluYy4xFTATBgNVBAsTDEtDQSBTZXJ2aWNlczEgMB4GA1UEAxMXUlNBIENs
YXNzIDIgUGVyc29uYWwgQ0ExEDAOBgNVBAcTB0JlZGZvcmQxFjAUBgNVBAgTDU1hc3NhY2h1
c2V0dHMxCzAJBgNVBAYTAlVTAhBgzHl9dAoZGu0JMqXovSgdMAkGBSsOAwIaBQCgggIfMBgG
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMTEyNzIzMDI1OFow
IwYJKoZIhvcNAQkEMRYEFMn6jdaMSBCJJc/ZuiQgdrnmS6/gMFIGCSqGSIb3DQEJDzFFMEMw
CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G
CCqGSIb3DQMCAgEoMIGzBgkrBgEEAYI3EAQxgaUwgaIwgYwxGjAYBgNVBAoTEVJTQSBTZWN1
cml0eSBJbmMuMRUwEwYDVQQLEwxLQ0EgU2VydmljZXMxIDAeBgNVBAMTF1JTQSBDbGFzcyAy
IFBlcnNvbmFsIENBMRAwDgYDVQQHEwdCZWRmb3JkMRYwFAYDVQQIEw1NYXNzYWNodXNldHRz
MQswCQYDVQQGEwJVUwIRAOrEBeqt70yv4V5jDf4xCGwwgbUGCyqGSIb3DQEJEAILMYGloIGi
MIGMMRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEVMBMGA1UECxMMS0NBIFNlcnZpY2Vz
MSAwHgYDVQQDExdSU0EgQ2xhc3MgMiBQZXJzb25hbCBDQTEQMA4GA1UEBxMHQmVkZm9yZDEW
MBQGA1UECBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMCEQDqxAXqre9Mr+FeYw3+MQhs
MA0GCSqGSIb3DQEBAQUABIIBAI49mdTHT+mSx0WG7qlu5qohLagvEk2mj9s4XVoGGo36VlHf
XRgxPINK2W7uQZvQ0qIz0psVhsc+aHW/isk3jgPWSgM37E/o51e5uRUv2+hjZfMNCIj0PqwK
sRWFiZ/72I2saz7PC2Kzw8TLkeKoWB/UtE6cidO+0hPbHyIFV2JEBUfUrGQnO6D4E1CzieG2
KwCtvb7ck+lN7dFhQg2CMXMAVoM0fMo22iCQpBq9s7K3giLIMe7L2l249uQzTX7F8HxRbGiu
46om2/jTB1fbQplhFLWIMt0Fncxu1IO/pxK79ntHUKPy7IZGzTCcwp5W/qtQNbME8feEurji
1d6s6QEAAAAAAAA=
--------------ms000801070905090402020205--


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hARMMgib085607 for <[e-mail]>; Thu, 27 Nov 2003 14:22:42 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hARMMgTF085606 for ietf-pkix-bks; Thu, 27 Nov 2003 14:22:42 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hARMMfib085601 for <[e-mail]>; Thu, 27 Nov 2003 14:22:41 -0800 (PST) (envelope-from [e-mail])
Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Thu, 27 Nov 2003 14:22:34 -0800
Received: from 157.54.6.150 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 27 Nov 2003 14:22:39 -0800
Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 27 Nov 2003 14:22:52 -0800
Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 27 Nov 2003 14:22:58 -0800
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 27 Nov 2003 14:24:53 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.7122.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary"
Subject: RE: DISCUSS:  MUST  reject in OCSPv1
Date: Thu, 27 Nov 2003 14:21:12 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: DISCUSS:  MUST  reject in OCSPv1
Thread-Index: AcO1NG0hzNRD9rTkQWSgr+oVECamlAAAFbvR
From: "Ryan M. Hurst" <[e-mail]>
To: "Michael Myers" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 27 Nov 2003 22:24:53.0849 (UTC) FILETIME=[47C4F490:01C3B535]
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.

--------------InterScan_NT_MIME_Boundary
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3B534.F77A19EA"

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

I do not support this change for all the reasons called out previously.
=20
Ryan

________________________________

From: [e-mail] on behalf of Michael Myers
Sent: Thu 11/27/2003 12:31 PM
To: [e-mail]
Subject: RE: DISCUSS: MUST reject in OCSPv1





If anyone objects to the path forward as discussed below, please
speak up now.  Concurrence is equally welcome.

Mike


> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of
> David Engberg
> Sent: Thursday, November 27, 2003 12:46 PM
> To: Michael Myers
> Cc: [e-mail]
> Subject: Re: DISCUSS: MUST reject in OCSPv1
>
>
>
>
> Exactly.  I'd implement this right now if I wasn't so
> full of turkey.
>
>
> Michael Myers wrote:
> >
> > Understand your caching servers MUST send back a caveated
> > response which by presence of the caveat may or may not be
> > accepted.  No fair sending back plain ones, errors
> > notwithstanding.  Is this understood?
> >
> > Mike
> >
> >
> >>-----Original Message-----
> >>From: David Engberg [mailto:[e-mail]]
> >>Sent: Thursday, November 27, 2003 12:25 PM
> >>To: Michael Myers
> >>Cc: [e-mail]
> >>Subject: Re: DISCUSS: MUST reject in OCSPv1
> >>
> >>
> >>
> >>I'd add "or return an error [e.g. unauthorized?]" to
> >>the end of '4' (to
> >>remain compliant in the presence of requests for
> >>unknown certs), but it
> >>is otherwise my dream scenario.
> >>
> >>
> >>Michael Myers wrote:
> >>
> >>>Dave,
> >>>
> >>>So how about:
> >>>
> >>>1. If we can cycle v1 at Proposed (a big if); then
> >>>
> >>>2. Define nonceUnsupported extension subject to
> >>>   the following semantics (I'm squeezing the
> >>>   words a bit but you'll get the drift)
> >>>
> >>>3. Clients that send a nonce:
> >>>
> >>>   a. MUST reject a non-nonced response
> >>>      if that response includes either the
> >>>      value "good" or "revoked" AND it fails
> >>>      to include the nonceUnsupported extension;
> >>>
> >>>   b. Else, if such response includes the
> >>>      nonceUnsupported extension, clients
> >>>      MAY accept the response subject to the
> >>>      advice in the Security Considerations
> >>>      section of this document.
> >>>
> >>>4. Conversely, if a server receives a nonced
> >>>   request but is unable to incorporate the
> >>>   nonce in its response, the server MUST
> >>>   include the nonceUnsupported extension.
> >>>
> >>> Note that I made no distinction between "good",
> >>> "revoked" or "unknown" in #3.b or #4.  Thus,
> >>> a plain nonceless response of "good" or
> >>> "revoked" is non-conformant, while a caveated
> >>> response is subject to the client's local
> >>> security policy.
> >>>
> >>> Does this seem a fair compromise?  Note well it's highly
> >>> dependent on cycling v1 at Proposed.
> >>>
> >>> Mike
> >
> >
> >
>




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

<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">=0A=
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">=0A=
<HTML>=0A=
<HEAD>=0A=
=0A=
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7122.0">=0A=
<TITLE>RE: DISCUSS:  MUST  reject in OCSPv1</TITLE>=0A=
</HEAD>=0A=
<BODY>=0A=
<DIV id=3DidOWAReplyText33778 dir=3Dltr>=0A=
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2>I do not =
support this change =0A=
for all the reasons called out previously.</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Ryan</FONT></DIV></DIV>=0A=
<DIV dir=3Dltr><BR>=0A=
<HR tabIndex=3D-1>=0A=
<FONT face=3DTahoma size=3D2><B>From:</B> [e-mail] =
on behalf of =0A=
Michael Myers<BR><B>Sent:</B> Thu 11/27/2003 12:31 PM<BR><B>To:</B> =0A=
[e-mail]<BR><B>Subject:</B> RE: DISCUSS: MUST reject in =0A=
OCSPv1<BR></FONT><BR></DIV>=0A=
<DIV><BR><BR>=0A=
<P><FONT size=3D2>If anyone objects to the path forward as discussed =
below, =0A=
please<BR>speak up now.&nbsp; Concurrence is equally =0A=
welcome.<BR><BR>Mike<BR><BR><BR>&gt; -----Original Message-----<BR>&gt; =
From: =0A=
[e-mail]<BR>&gt; [<A =0A=
href=3D"mailto:[e-mail]">mailto:owner-ietf-pkix@mail.=
imc.org</A>]On =0A=
Behalf Of<BR>&gt; David Engberg<BR>&gt; Sent: Thursday, November 27, =
2003 12:46 =0A=
PM<BR>&gt; To: Michael Myers<BR>&gt; Cc: [e-mail]<BR>&gt; =
Subject: Re: =0A=
DISCUSS: MUST reject in OCSPv1<BR>&gt;<BR>&gt;<BR>&gt;<BR>&gt;<BR>&gt; =0A=
Exactly.&nbsp; I'd implement this right now if I wasn't so<BR>&gt; full =
of =0A=
turkey.<BR>&gt;<BR>&gt;<BR>&gt; Michael Myers wrote:<BR>&gt; =
&gt;<BR>&gt; &gt; =0A=
Understand your caching servers MUST send back a caveated<BR>&gt; &gt; =
response =0A=
which by presence of the caveat may or may not be<BR>&gt; &gt; =
accepted.&nbsp; =0A=
No fair sending back plain ones, errors<BR>&gt; &gt; =
notwithstanding.&nbsp; Is =0A=
this understood?<BR>&gt; &gt;<BR>&gt; &gt; Mike<BR>&gt; &gt;<BR>&gt; =0A=
&gt;<BR>&gt; &gt;&gt;-----Original Message-----<BR>&gt; &gt;&gt;From: =
David =0A=
Engberg [<A =0A=
href=3D"mailto:[e-mail]">mailto:[e-mail]</A>]<BR>&g=
t; =0A=
&gt;&gt;Sent: Thursday, November 27, 2003 12:25 PM<BR>&gt; &gt;&gt;To: =
Michael =0A=
Myers<BR>&gt; &gt;&gt;Cc: [e-mail]<BR>&gt; &gt;&gt;Subject: Re: =0A=
DISCUSS: MUST reject in OCSPv1<BR>&gt; &gt;&gt;<BR>&gt; &gt;&gt;<BR>&gt; =0A=
&gt;&gt;<BR>&gt; &gt;&gt;I'd add "or return an error [e.g. =
unauthorized?]" =0A=
to<BR>&gt; &gt;&gt;the end of '4' (to<BR>&gt; &gt;&gt;remain compliant =
in the =0A=
presence of requests for<BR>&gt; &gt;&gt;unknown certs), but it<BR>&gt; =0A=
&gt;&gt;is otherwise my dream scenario.<BR>&gt; &gt;&gt;<BR>&gt; =0A=
&gt;&gt;<BR>&gt; &gt;&gt;Michael Myers wrote:<BR>&gt; &gt;&gt;<BR>&gt; =0A=
&gt;&gt;&gt;Dave,<BR>&gt; &gt;&gt;&gt;<BR>&gt; &gt;&gt;&gt;So how =
about:<BR>&gt; =0A=
&gt;&gt;&gt;<BR>&gt; &gt;&gt;&gt;1. If we can cycle v1 at Proposed (a =
big if); =0A=
then<BR>&gt; &gt;&gt;&gt;<BR>&gt; &gt;&gt;&gt;2. Define nonceUnsupported =0A=
extension subject to<BR>&gt; &gt;&gt;&gt;&nbsp;&nbsp; the following =
semantics =0A=
(I'm squeezing the<BR>&gt; &gt;&gt;&gt;&nbsp;&nbsp; words a bit but =
you'll get =0A=
the drift)<BR>&gt; &gt;&gt;&gt;<BR>&gt; &gt;&gt;&gt;3. Clients that send =
a =0A=
nonce:<BR>&gt; &gt;&gt;&gt;<BR>&gt; &gt;&gt;&gt;&nbsp;&nbsp; a. MUST =
reject a =0A=
non-nonced response<BR>&gt; &gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
if that =0A=
response includes either the<BR>&gt; =
&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =0A=
value "good" or "revoked" AND it fails<BR>&gt; =0A=
&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; to include the =
nonceUnsupported =0A=
extension;<BR>&gt; &gt;&gt;&gt;<BR>&gt; &gt;&gt;&gt;&nbsp;&nbsp; b. =
Else, if =0A=
such response includes the<BR>&gt; =
&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =0A=
nonceUnsupported extension, clients<BR>&gt; =0A=
&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MAY accept the response =
subject to =0A=
the<BR>&gt; &gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; advice in the =
Security =0A=
Considerations<BR>&gt; &gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
section of =0A=
this document.<BR>&gt; &gt;&gt;&gt;<BR>&gt; &gt;&gt;&gt;4. Conversely, =
if a =0A=
server receives a nonced<BR>&gt; &gt;&gt;&gt;&nbsp;&nbsp; request but is =
unable =0A=
to incorporate the<BR>&gt; &gt;&gt;&gt;&nbsp;&nbsp; nonce in its =
response, the =0A=
server MUST<BR>&gt; &gt;&gt;&gt;&nbsp;&nbsp; include the =
nonceUnsupported =0A=
extension.<BR>&gt; &gt;&gt;&gt;<BR>&gt; &gt;&gt;&gt; Note that I made no =0A=
distinction between "good",<BR>&gt; &gt;&gt;&gt; "revoked" or "unknown" =
in #3.b =0A=
or #4.&nbsp; Thus,<BR>&gt; &gt;&gt;&gt; a plain nonceless response of =
"good" =0A=
or<BR>&gt; &gt;&gt;&gt; "revoked" is non-conformant, while a =
caveated<BR>&gt; =0A=
&gt;&gt;&gt; response is subject to the client's local<BR>&gt; =
&gt;&gt;&gt; =0A=
security policy.<BR>&gt; &gt;&gt;&gt;<BR>&gt; &gt;&gt;&gt; Does this =
seem a fair =0A=
compromise?&nbsp; Note well it's highly<BR>&gt; &gt;&gt;&gt; dependent =
on =0A=
cycling v1 at Proposed.<BR>&gt; &gt;&gt;&gt;<BR>&gt; &gt;&gt;&gt; =
Mike<BR>&gt; =0A=
&gt;<BR>&gt; &gt;<BR>&gt; &gt;<BR>&gt;<BR><BR></FONT></P></DIV>=0A=
=0A=
</BODY>=0A=
</HTML>
------_=_NextPart_001_01C3B534.F77A19EA--

--------------InterScan_NT_MIME_Boundary--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hARLxCib084719 for <[e-mail]>; Thu, 27 Nov 2003 13:59:12 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hARLxCgf084718 for ietf-pkix-bks; Thu, 27 Nov 2003 13:59:12 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from sigurd.x509.com ([199.175.155.2]) by above.proper.com (8.12.10/8.12.8) with SMTP id hARLxBib084712 for <[e-mail]>; Thu, 27 Nov 2003 13:59:11 -0800 (PST) (envelope-from [e-mail])
Received: from nebula.x509.com by sigurd.x509.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 27 Nov 2003 21:59:13 UT
Received: from crack.x509.com (localhost [127.0.0.1]) by nebula.x509.com (8.12.10/NULL) with ESMTP id hARLtH6L015827 for <[e-mail]>; Thu, 27 Nov 2003 13:55:17 -0800 (PST)
Received: from exvan01.x509.com (exvan01.x509.com [10.9.22.50]) by crack.x509.com (8.12.10/8.12.10) with ESMTP id hARLxCY0023028 for <[e-mail]>; Thu, 27 Nov 2003 13:59:12 -0800 (PST)
Received: from rsasecurity.com (mbranchaud2.eng.x509.com [10.7.33.48]) by exvan01.x509.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id VQFWG6Y9; Thu, 27 Nov 2003 14:08:03 -0800
Message-ID: <[e-mail]>
Date: Thu, 27 Nov 2003 13:49:36 -0800
X-Sybari-Trust: 79471e02 64c784fd c3b38011 00000139
From: Marc Branchaud <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031110
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: DISCUSS:  MUST  reject in OCSPv1
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070402050606080700050908"
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.

--------------ms070402050606080700050908
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Ryan M. Hurst wrote:
> 
>> Why can't the client can decide this before making the request?
> 
> [rmh] There are several cases; consider this one, bookstore.com
> (server) has a certificate from bigttp.com, client is connecting to
> bookstore.com and both the client and the server in this scenario
> support the new tls extensions allowing a server to provide a client
> a copy of its ocsp response (from bigttp.com). The server would want
> to keep a local copy of the ocsp response, he would also want to
> re-fresh this cached copy before passing it off to the client if he
> knew it was expired or about to be expired. He could when generating
> his OCSP request to bigttp.com include a nonce indicating he wants a
> fresh response (afterall this is implicit when asking for the nonce
> in the response). Since in this case all the server wants is a fresh
> response (he will be caching and replaying afterall) getting back a
> respone without a nonce is OK.

No, it's not OK.

First off, the nonce is _not_ an indication that the server wants a
fresh response.  Like the RFC says, it's an indication that the server
doesn't want to be replayed a previous response.  Even with the nonce,
there's nothing to stop the bigttp.com OCSP server from giving the
server a status value based on yesterday's CRL.

Second, if the server accepts a nonceless response not only is it not
guaranteeing that it gets a "fresh" response, but it's also at risk of
getting a replayed response.  Again, the nonce (or rather, its
absence/presence in the response) does nothing to guanrantee any kind of
"freshness".  By accepting nonceless responses the server could even
accept the same response it already has.  If the server's OK with that,
then there's no point in putting a nonce in the request in the first place.

> The alternative with the proposed text would be to make a request
> with the nonce, get denied and make another one; resulting in two
> wire retrievals instead of one like the original version of the RFC
> allowed for.

There's more than one alternative.

A more reasonable approach would for the server to not put a nonce in
the request in the first place.  This results in a single over-the-wire
transaction that meets the security parameters the server is willing to
live with.

>> What does the client gain by making a nonced request but accepting
>> a nonceless response?
> 
> [rmh] there are several, consider the above; we must remember what
> the nonce means; directly it means I would like to try to protect
> myself from replays; ok, so what is a replay? a stale response; so it
> also means give me the freshest data you have.

No, it doesn't mean that at all.  The OCSP server is still free to
construct a response based on whatever data it sees fit.  All the nonce
does is force the server to sign a new response.  It doesn't say
anything about how "fresh" the data is in that response.


> If the group wishes to address the use of nonces for more than replay
>  prevention, then I think the only option is to devise a new OCSPv2
> spec.
> 
> [rmh] its not necesssary, the current RFC works and by changing the 
> semantics you disallow a legitimate use that worked and was
> conformant.

But that use wasn't conformant.  All that RFC2560 wants to use nonces
for is to prevent replay attacks.  Any other use of nonces goes beyond
what RFC2560 says they're for.

		M.

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISqTCC
AtcwggJAoAMCAQICEFgUQCxch7Sxp7XFFauIqpwwDQYJKoZIhvcNAQEFBQAwbDEaMBgGA1UE
ChMRUlNBIFNlY3VyaXR5IEluYy4xHjAcBgNVBAMTFVJTQSBQdWJsaWMgUm9vdCBDQSB2MTEu
MCwGCSqGSIb3DQEJARYfcnNha2VvbnJvb3RzaWduQHJzYXNlY3VyaXR5LmNvbTAeFw0wMjA5
MDYxNDEzNTJaFw0wNzA5MDYxNDEzNTJaMIGCMRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5j
LjEVMBMGA1UECxMMS0NBIFNlcnZpY2VzMRYwFAYDVQQDEw1SU0EgQ29ycG9yYXRlMRAwDgYD
VQQHEwdCZWRmb3JkMRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMQswCQYDVQQGEwJVUzCBnzAN
BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAqnOw876lPpMTkSqrqzpEON/609PDLEhmWX4tkC19
AHneDaoetL277GtYYXBCggP2E+s66MN1ccWXyApfWjCZkIHepPC08NVI1JRcbViW3kwLzDD2
w5T9QJcyL5V1pN/LQdxahM56TiLeXlPiJekdmTdJoo+5Pw4bQU+MxTqURk8CAwEAAaNjMGEw
HwYDVR0jBBgwFoAU9UwxelEDPyzXi5eZb6hxkKt4PZswHQYDVR0OBBYEFO2RCGt0t1lKkvah
HSJwJp8KrxaSMA8GA1UdEwQIMAYBAf8CAQMwDgYDVR0PAQH/BAQDAgGGMA0GCSqGSIb3DQEB
BQUAA4GBAHiSe1a79hnPr16PuBwUTBWbuNQ4GJNsyfrCXzAswIT2A2WtGZ1Hp1jEAWi9OfAX
IYAdy52Jyv9N87wAEbLUgVmsFEIlYM5mi6ag7YIRGp8JP5UhLAN9O5YHrR9FsrGK4WmSl3sY
W1qAPOXubFcfhTgUDIYzM30izZBP4nwO07FpMIIC+DCCAmGgAwIBAgIQeuiOriTayCwjwpmR
gmdIUjANBgkqhkiG9w0BAQUFADCBgjEaMBgGA1UEChMRUlNBIFNlY3VyaXR5IEluYy4xFTAT
BgNVBAsTDEtDQSBTZXJ2aWNlczEWMBQGA1UEAxMNUlNBIENvcnBvcmF0ZTEQMA4GA1UEBxMH
QmVkZm9yZDEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMwHhcNMDIwOTIz
MTkxMzAzWhcNMDYwOTIzMTUxMzAzWjCBjDEaMBgGA1UEChMRUlNBIFNlY3VyaXR5IEluYy4x
FTATBgNVBAsTDEtDQSBTZXJ2aWNlczEgMB4GA1UEAxMXUlNBIENsYXNzIDIgUGVyc29uYWwg
Q0ExEDAOBgNVBAcTB0JlZGZvcmQxFjAUBgNVBAgTDU1hc3NhY2h1c2V0dHMxCzAJBgNVBAYT
AlVTMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCkR9yiabyRo6+NwC3Sl8wPuUiBD3rP
sENNjXvzSbTAyXA8pDDndnlAa1nLUhSMgvn8g1sYMd0Bp+C1/mI5PFUZ8jukUK95yt+TK26L
hM/M5RUq/EINdDDdWzg9je498K6oGfyWR6ETSJbIrDe5qQcLCABs9E2gVKb7Z/FwFo3C9QID
AQABo2MwYTAPBgNVHRMECDAGAQH/AgECMA4GA1UdDwEB/wQEAwIBhjAfBgNVHSMEGDAWgBTt
kQhrdLdZSpL2oR0icCafCq8WkjAdBgNVHQ4EFgQUxpPuxqX+41WOz4ojH+6Y3iHyn6cwDQYJ
KoZIhvcNAQEFBQADgYEAcdRHBjq8GfdDoutUTJPtSzQd7XsdsQh2KBbu8utl92VQHuI0J5wc
Rc817G8YbmTtCt/xqAzrr6k7fdaoDBr/kBuVHA5FEJ94foPgrOlbT3zdziMATXh5ESSDLMx6
p8ITIsTJNmwszIG5P9AAKJCW48gu1ZZmLXhFbHcYJGf99pwwggMFMIICbqADAgECAhEAvhyf
0s21hKaAc2Nm1WX4LTANBgkqhkiG9w0BAQUFADCBuzEkMCIGA1UEBxMbVmFsaUNlcnQgVmFs
aWRhdGlvbiBOZXR3b3JrMRcwFQYDVQQKEw5WYWxpQ2VydCwgSW5jLjE1MDMGA1UECxMsVmFs
aUNlcnQgQ2xhc3MgMyBQb2xpY3kgVmFsaWRhdGlvbiBBdXRob3JpdHkxITAfBgNVBAMTGGh0
dHA6Ly93d3cudmFsaWNlcnQuY29tLzEgMB4GCSqGSIb3DQEJARYRaW5mb0B2YWxpY2VydC5j
b20wHhcNMDIwNDMwMTUzMDE5WhcNMTkwNDMwMDkyMTU1WjBsMRowGAYDVQQKExFSU0EgU2Vj
dXJpdHkgSW5jLjEeMBwGA1UEAxMVUlNBIFB1YmxpYyBSb290IENBIHYxMS4wLAYJKoZIhvcN
AQkBFh9yc2FrZW9ucm9vdHNpZ25AcnNhc2VjdXJpdHkuY29tMIGfMA0GCSqGSIb3DQEBAQUA
A4GNADCBiQKBgQC0dSVa2EQ740GxqiIKsHATT4f8XYwUU23pzRe5W6IVpt4jkwDWkgnvTcP6
M8PD4OfK6Imal4hAH/c3K/dUIH7YyQZRGAE5Y27G5klZYKidcFlrfautgVES170MLKFmJqym
2FWAfVOibXatRcw7B0S+mP9404jID/MaIpRXkH5JjwIDAQABo1cwVTAMBgNVHRMEBTADAQH/
MA4GA1UdDwEB/wQEAwIBhjAWBgNVHSAEDzANMAsGCSqGSIb3DQUGATAdBgNVHQ4EFgQU9Uwx
elEDPyzXi5eZb6hxkKt4PZswDQYJKoZIhvcNAQEFBQADgYEAKsviXBc1FeBT2hIwyWuGwnPZ
J9ctjrsO7NbVLjsx/EYclFFGwo+pphiwdUTml9yd7fXzfk0D+7LOs9ZA5xhiHVrGusV4OW4i
7hx2KVILkYlcXCN5tDltKwa5+BkGUuvZdyAoIhpyf61h7uKCFguhaJ+VOiNB4DPtsmxI+KxO
E6YwggTYMIIEQaADAgECAhBgzHl9dAoZGu0JMqXovSgdMA0GCSqGSIb3DQEBBQUAMIGMMRow
GAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEVMBMGA1UECxMMS0NBIFNlcnZpY2VzMSAwHgYD
VQQDExdSU0EgQ2xhc3MgMiBQZXJzb25hbCBDQTEQMA4GA1UEBxMHQmVkZm9yZDEWMBQGA1UE
CBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMwHhcNMDMwNzA3MjMwODEzWhcNMDQwNzA3
MjMwODEzWjCBvjETMBEGCgmSJomT8ixkARkWA2NvbTEbMBkGCgmSJomT8ixkARkWC3JzYXNl
Y3VyaXR5MRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEWMBQGA1UECxMNTm9ydGggQW1l
cmljYTEUMBIGA1UECxMLRW5naW5lZXJpbmcxFzAVBgNVBAMTDk1hcmMgQnJhbmNoYXVkMScw
JQYJKoZIhvcNAQkBFhhtYXJjbmFyY0Byc2FzZWN1cml0eS5jb20wggEiMA0GCSqGSIb3DQEB
AQUAA4IBDwAwggEKAoIBAQDg2xoRr+a/dtnuFG+oTHa+tGtzeObFazNhYV2iSLNED4fHRu86
tknBYFgXggcHW5gsyjfkCtVMzP2tCivmbJgvISo36vsCsmAJH6LRnJf8HsvfmWZaD9tzhDpL
QVsBHr88J0ZMdVniRc7MQoYeu/3hYtUBeGO9bGA6T8vTrnXYonnFtVoTqE62SFqPZZk7HpCS
X1n+dM3zSym2ylMFYE14nukF4I9vAhsQVzk3QNpghmzGj8uoEy9xpf3k0o5+neneAGvcSkwo
r1mH5tSqhrEQaZp7vuSA2bvXaZEnjZzZiTpPDzs1oMpn3guzYhU7wMKz6xvwvgEYyAAV+P5n
FWM/AgMBAAGjggGBMIIBfTCBkgYDVR0gBIGKMIGHMIGEBgkqhkiG9w0FBwIwdzAuBggrBgEF
BQcCARYiaHR0cDovL2NhLnJzYXNlY3VyaXR5LmNvbS9DUFMuaHRtbDBFBggrBgEFBQcCAjA5
MBgWEVJTQSBTZWN1cml0eSBJbmMuMAMCAQEaHUNQUyBJbmNvcnBvcmF0ZWQgYnkgcmVmZXJl
bmNlMCkGA1UdJQQiMCAGCisGAQQBgjcUAgIGCCsGAQUFBwMCBggrBgEFBQcDBDAjBgNVHREE
HDAagRhtYXJjbmFyY0Byc2FzZWN1cml0eS5jb20wDgYDVR0PAQH/BAQDAgeAMEYGA1UdHwQ/
MD0wO6A5oDeGNWh0dHA6Ly9jcmwucnNhc2VjdXJpdHkuY29tOjgwL1JTQUNsYXNzMlBlcnNv
bmFsQ0EuY3JsMB8GA1UdIwQYMBaAFMaT7sal/uNVjs+KIx/umN4h8p+nMB0GA1UdDgQWBBQ1
yQ/UrvKb563LjzHqJzBzrZp/ejANBgkqhkiG9w0BAQUFAAOBgQCV82oGGnglQQzklKg/wKhy
evNeJ6FNBZFhLlmZRNlKgqvPFmBcxygfBGpHqIhsHcrt2/AjhJuzAj7UdW1vTVCY5MkZw8P9
6+J6aTc3bNlGbk0jvcvVgDhmM4xYJLwMZKEw92HlRhfuMnj7ah9DTqbKSewmyAyOc+FLpGfd
lu6CgTCCBOkwggRSoAMCAQICEQDqxAXqre9Mr+FeYw3+MQhsMA0GCSqGSIb3DQEBBQUAMIGM
MRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEVMBMGA1UECxMMS0NBIFNlcnZpY2VzMSAw
HgYDVQQDExdSU0EgQ2xhc3MgMiBQZXJzb25hbCBDQTEQMA4GA1UEBxMHQmVkZm9yZDEWMBQG
A1UECBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMwHhcNMDMwNzA3MjMwODI4WhcNMDQw
NzA3MjMwODEzWjCBwjETMBEGCgmSJomT8ixkARkWA2NvbTEbMBkGCgmSJomT8ixkARkWC3Jz
YXNlY3VyaXR5MRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEWMBQGA1UECxMNTm9ydGgg
QW1lcmljYTEUMBIGA1UECxMLRW5naW5lZXJpbmcxGzAZBgNVBAMTEk1hcmMgQnJhbmNoYXVk
LUVuYzEnMCUGCSqGSIb3DQEJARYYbWFyY25hcmNAcnNhc2VjdXJpdHkuY29tMIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwBjNaHTwtCXpdJg+iDxYMkWjuZIF0ic2fRLymZe+
BnZYWPnik0dFmTulx+V8slsLEtBllcc5o1yfIYfeHPinwRxv86kCUSlgfGGXKjJZaIeURgbo
bUbIfDTPlvRUZuiZvTR4C8tEY88Lle66n62B7wjUvDbiwK4EjzlXOkjpcYXLH7FbaFaRLDBB
PlFD5ydDRhQ67t6fjUeS7p7o/l/VHmPC5LFLXZkjEhjGd5pknbQIAbUGACL5UET85NUFPowD
3F47g0GCKEnuOsk2Ra+WHu7honhIxqmOwGnu85V6tW5xscf4dTofWZONQeaD3gSxv8+hcfKN
k9cwjpnUG2xGzwIDAQABo4IBjTCCAYkwNQYDVR0lBC4wLAYKKwYBBAGCNxQCAgYIKwYBBQUH
AwIGCCsGAQUFBwMEBgorBgEEAYI3CgMEMIGSBgNVHSAEgYowgYcwgYQGCSqGSIb3DQUHAjB3
MC4GCCsGAQUFBwIBFiJodHRwOi8vY2EucnNhc2VjdXJpdHkuY29tL0NQUy5odG1sMEUGCCsG
AQUFBwICMDkwGBYRUlNBIFNlY3VyaXR5IEluYy4wAwIBARodQ1BTIEluY29ycG9yYXRlZCBi
eSByZWZlcmVuY2UwIwYDVR0RBBwwGoEYbWFyY25hcmNAcnNhc2VjdXJpdHkuY29tMEYGA1Ud
HwQ/MD0wO6A5oDeGNWh0dHA6Ly9jcmwucnNhc2VjdXJpdHkuY29tOjgwL1JTQUNsYXNzMlBl
cnNvbmFsQ0EuY3JsMB8GA1UdIwQYMBaAFMaT7sal/uNVjs+KIx/umN4h8p+nMB0GA1UdDgQW
BBT/OiMCyY8CPnNBySW1ijJOYhj7ejAOBgNVHQ8BAf8EBAMCAzgwDQYJKoZIhvcNAQEFBQAD
gYEAlchAObA9eVmeiLu0nTU985Fch6v+EZKodUhZUN7dILgd05HorHN9jxBH6XI4/b9ZVvub
Pkpicdc112YbcLYTD2NumVksyNDI7fDaqiszgk1zluXtZJ+HsCt+GIAKCDfOVLECclpGyizq
VjZFEK4Pt9FxPGTnUJEvIKJcAQ24EvgxggPsMIID6AIBATCBoTCBjDEaMBgGA1UEChMRUlNB
IFNlY3VyaXR5IEluYy4xFTATBgNVBAsTDEtDQSBTZXJ2aWNlczEgMB4GA1UEAxMXUlNBIENs
YXNzIDIgUGVyc29uYWwgQ0ExEDAOBgNVBAcTB0JlZGZvcmQxFjAUBgNVBAgTDU1hc3NhY2h1
c2V0dHMxCzAJBgNVBAYTAlVTAhBgzHl9dAoZGu0JMqXovSgdMAkGBSsOAwIaBQCgggIfMBgG
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMTEyNzIxNDkzNlow
IwYJKoZIhvcNAQkEMRYEFHFqM7nCSZfCXZbcmfiAmPSIEQYmMFIGCSqGSIb3DQEJDzFFMEMw
CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G
CCqGSIb3DQMCAgEoMIGzBgkrBgEEAYI3EAQxgaUwgaIwgYwxGjAYBgNVBAoTEVJTQSBTZWN1
cml0eSBJbmMuMRUwEwYDVQQLEwxLQ0EgU2VydmljZXMxIDAeBgNVBAMTF1JTQSBDbGFzcyAy
IFBlcnNvbmFsIENBMRAwDgYDVQQHEwdCZWRmb3JkMRYwFAYDVQQIEw1NYXNzYWNodXNldHRz
MQswCQYDVQQGEwJVUwIRAOrEBeqt70yv4V5jDf4xCGwwgbUGCyqGSIb3DQEJEAILMYGloIGi
MIGMMRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEVMBMGA1UECxMMS0NBIFNlcnZpY2Vz
MSAwHgYDVQQDExdSU0EgQ2xhc3MgMiBQZXJzb25hbCBDQTEQMA4GA1UEBxMHQmVkZm9yZDEW
MBQGA1UECBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMCEQDqxAXqre9Mr+FeYw3+MQhs
MA0GCSqGSIb3DQEBAQUABIIBAIpT1dSmQwQc3w7q7NQXtJ8B0cFy/A3872B2sbqkVncq7ch/
j1EOuKJ9dd2lWoSZsI8h0rdlqGPyORIIDlJn+vRko/5Jt3KLJddpqpan4BcdxSyqOw33+cFH
lTfZ2TOkM2ZXR+4Fk6fpgHYQMIg1pHJtXJMireXGlNXfZAUACRZ046kdOjYd1kDZ1wncZ/n9
mi1f9nebmVBKMB7v7Z/D7CPLvXePtSIC8Kz2FgJljzOpNigKdHsNEHBFcZzZxZGHGDDTbEf3
B9+cNvcNCMEtiSB89Oex0udc9uz0WVz3RzHx7Cq/qOTvgIyICywiPTHSRcGNKvHa3XC/6p82
lv3XtDUAAAAAAAA=
--------------ms070402050606080700050908--


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hARLLmib082971 for <[e-mail]>; Thu, 27 Nov 2003 13:21:48 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hARLLmv1082970 for ietf-pkix-bks; Thu, 27 Nov 2003 13:21:48 -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.10/8.12.8) with ESMTP id hARLLkib082962 for <[e-mail]>; Thu, 27 Nov 2003 13:21:46 -0800 (PST) (envelope-from [e-mail])
Received: from mail5.microsoft.com ([157.54.6.156]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 27 Nov 2003 13:20:28 -0800
Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(6.0.3790.1039); Thu, 27 Nov 2003 13:21:42 -0800
Received: from 157.54.6.150 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 27 Nov 2003 13:21:44 -0800
Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 27 Nov 2003 13:21:50 -0800
Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 27 Nov 2003 13:21:46 -0800
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 27 Nov 2003 13:23:14 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.7122.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary"
Subject: RE: DISCUSS:  MUST  reject in OCSPv1
Date: Thu, 27 Nov 2003 13:21:44 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: DISCUSS:  MUST  reject in OCSPv1
Thread-Index: AcO1Ifft6VDi+FCaSva5Mqw7mHsdSAACWzbd
From: "Ryan M. Hurst" <[e-mail]>
To: "Marc Branchaud" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 27 Nov 2003 21:23:14.0154 (UTC) FILETIME=[AA944CA0:01C3B52C]
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.

--------------InterScan_NT_MIME_Boundary
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3B52C.750AC865"

------_=_NextPart_001_01C3B52C.750AC865
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

cil

________________________________

From: [e-mail] on behalf of Marc Branchaud
Sent: Thu 11/27/2003 10:40 AM
To: [e-mail]
Subject: Re: DISCUSS: MUST reject in OCSPv1



Ryan M. Hurst wrote:
> I don't think its silly, the client is still protected from the replay
> if the server responds to a nonced request with a un-nonced one as the
> client can decide decide if he wanted the protection or needed it.

Why can't the client can decide this before making the request?


[rmh] There are several cases; consider this one, bookstore.com (server) =
has a certificate from bigttp.com, client is connecting to bookstore.com =
and both the client and the server in this scenario support the new tls =
extensions allowing a server to provide a client a copy of its ocsp =
response (from bigttp.com). The server would want to keep a local copy =
of the ocsp response, he would also want to re-fresh this cached copy =
before passing it off to the client if he knew it was expired or about =
to be expired. He could when generating his OCSP request to bigttp.com =
include a nonce indicating he wants a fresh response (afterall this is =
implicit when asking for the nonce in the response). Since in this case =
all the server wants is a fresh response (he will be caching and =
replaying afterall) getting back a respone without a nonce is OK. The =
alternative with the proposed text would be to make a request with the =
nonce, get denied and make another one; resulting in two wire retrievals =
instead of one like the original version of the RFC allowed for.


What does the client gain by making a nonced request but accepting a
nonceless response?
[rmh] there are several, consider the above; we must remember what the =
nonce means; directly it means I would like to try to protect myself =
from replays; ok, so what is a replay? a stale response; so it also =
means give me the freshest data you have.


> That may sound strange, but nonce has other implications that re-play
> protection; it also implies freshness since pre-produced responses can
> not have the right nonce in it.

If the group wishes to address the use of nonces for more than replay
prevention, then I think the only option is to devise a new OCSPv2 spec.

[rmh] its not necesssary, the current RFC works and by changing the =
semantics you disallow a legitimate use that worked and was conformant.

                M.



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

<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">=0A=
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">=0A=
<HTML>=0A=
<HEAD>=0A=
=0A=
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7122.0">=0A=
<TITLE>Re: DISCUSS:  MUST  reject in OCSPv1</TITLE>=0A=
</HEAD>=0A=
<BODY>=0A=
<DIV id=3DidOWAReplyText77547 dir=3Dltr>=0A=
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 =
size=3D2>cil</FONT></DIV></DIV>=0A=
<DIV dir=3Dltr><BR>=0A=
<HR tabIndex=3D-1>=0A=
<FONT face=3DTahoma size=3D2><B>From:</B> [e-mail] =
on behalf of =0A=
Marc Branchaud<BR><B>Sent:</B> Thu 11/27/2003 10:40 AM<BR><B>To:</B> =0A=
[e-mail]<BR><B>Subject:</B> Re: DISCUSS: MUST reject in =0A=
OCSPv1<BR></FONT><BR></DIV>=0A=
<DIV>=0A=
<P><FONT size=3D2>Ryan M. Hurst wrote:<BR>&gt; I don't think its silly, =
the client =0A=
is still protected from the replay<BR>&gt; if the server responds to a =
nonced =0A=
request with a un-nonced one as the<BR>&gt; client can decide decide if =
he =0A=
wanted the protection or needed it.<BR><BR>Why can't the client can =
decide this =0A=
before making the request?<BR></FONT></P>=0A=
<P><FONT size=3D2>[rmh] There are several cases; consider this one, =
bookstore.com =0A=
(server) has a certificate from bigttp.com, client is connecting to =0A=
bookstore.com and both the client and the server in this scenario =
support the =0A=
new tls extensions allowing a server to provide a client a copy of its =
ocsp =0A=
response (from bigttp.com). The server would want to keep a local copy =
of the =0A=
ocsp response, he would also want to re-fresh this cached copy before =
passing it =0A=
off to the client if he knew it was expired or about to be expired. He =
could =0A=
when generating his OCSP request to bigttp.com include a nonce =
indicating he =0A=
wants a fresh response (afterall this is implicit when asking for the =
nonce in =0A=
the response). Since in this case all the server wants is a fresh =
response (he =0A=
will be caching and replaying afterall) getting back a respone without a =
nonce =0A=
is OK. The alternative with the proposed text would be to make a request =
with =0A=
the nonce, get denied and make another one; resulting in two wire =
retrievals =0A=
instead of one like the original version of the RFC allowed =
for.</FONT></P><FONT =0A=
size=3D2>=0A=
<P><BR>What does the client gain by making a nonced request but =
accepting =0A=
a<BR>nonceless response?<BR>[rmh] there are several, consider the above; =
we must =0A=
remember what the nonce means; directly it means I would like to try to =
protect =0A=
myself from replays; ok, so what is a replay? a stale response; so it =
also means =0A=
give me the freshest data you have.</P>=0A=
<P><BR>&gt; That may sound strange, but nonce has other implications =
that =0A=
re-play<BR>&gt; protection; it also implies freshness since pre-produced =0A=
responses can<BR>&gt; not have the right nonce in it.<BR><BR>If the =
group wishes =0A=
to address the use of nonces for more than replay<BR>prevention, then I =
think =0A=
the only option is to devise a new OCSPv2 spec.</P>=0A=
<P>[rmh] its not necesssary, the current RFC works and by changing the =
semantics =0A=
you&nbsp;disallow a legitimate use that worked and was =0A=
conformant.<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =0A=
M.<BR></P></FONT></DIV>=0A=
=0A=
</BODY>=0A=
</HTML>
------_=_NextPart_001_01C3B52C.750AC865--

--------------InterScan_NT_MIME_Boundary--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hARL8fib082579 for <[e-mail]>; Thu, 27 Nov 2003 13:08:41 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hARL8fr2082578 for ietf-pkix-bks; Thu, 27 Nov 2003 13:08:41 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from nb2.stroeder.com (du-041-193.access.de.clara.net [213.221.64.193]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hARL8bib082570 for <[e-mail]>; Thu, 27 Nov 2003 13:08:39 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (localhost [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id 768EB8AE59; Thu, 27 Nov 2003 16:44:54 +0100 (CET)
Received: from stroeder.com (localhost [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id 57A6D87C4F; Thu, 27 Nov 2003 16:44:53 +0100 (CET)
Message-ID: <[e-mail]>
Date: Thu, 27 Nov 2003 16:44:53 +0100
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007
X-Accept-Language: de-de, de, en-us, en
MIME-Version: 1.0
To: Peter Gutmann <[e-mail]>
Cc: [e-mail]
Subject: Re: Certificate Policy Standardization
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
X-Virus-Scanned: by AMaViS 0.3.12pre8
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id hARL8eib082573
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 Gutmann wrote:
> 
> The feeling here was that a ToS-style policy might violate (at least NZ) 
> consumer protection legislation,

I'm not a lawyer and the terms are for sure used much differently in other
countries. But I also guess that most ToS-style CPs would not withstand a
court trial based on german AGB-Gesetz, the law regulating "Allgemeine
Geschäftsbedingungen" (similar to ToS).

But since PKI did not hit the mass market yet a CA with such a ToS-style CP
can assume that this risk is quite low.
Less RPs => less serious usage => less risks. ;-)

Ciao, Michael.





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hARKTSib081237 for <[e-mail]>; Thu, 27 Nov 2003 12:29:28 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hARKTSGT081236 for ietf-pkix-bks; Thu, 27 Nov 2003 12:29:28 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hARKTRib081231 for <[e-mail]>; Thu, 27 Nov 2003 12:29:27 -0800 (PST) (envelope-from [e-mail])
Received: from MMyersLapTop ([65.39.77.99]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id hARKTTA49635 for <[e-mail]>; Thu, 27 Nov 2003 13:29:29 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: <[e-mail]>
Subject: RE: DISCUSS:  MUST  reject in OCSPv1
Date: Thu, 27 Nov 2003 13:31:40 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <[e-mail]>
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>

If anyone objects to the path forward as discussed below, please
speak up now.  Concurrence is equally welcome.

Mike


> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of
> David Engberg
> Sent: Thursday, November 27, 2003 12:46 PM
> To: Michael Myers
> Cc: [e-mail]
> Subject: Re: DISCUSS: MUST reject in OCSPv1
>
>
>
>
> Exactly.  I'd implement this right now if I wasn't so
> full of turkey.
>
>
> Michael Myers wrote:
> >
> > Understand your caching servers MUST send back a caveated
> > response which by presence of the caveat may or may not be
> > accepted.  No fair sending back plain ones, errors
> > notwithstanding.  Is this understood?
> >
> > Mike
> >
> >
> >>-----Original Message-----
> >>From: David Engberg [mailto:[e-mail]]
> >>Sent: Thursday, November 27, 2003 12:25 PM
> >>To: Michael Myers
> >>Cc: [e-mail]
> >>Subject: Re: DISCUSS: MUST reject in OCSPv1
> >>
> >>
> >>
> >>I'd add "or return an error [e.g. unauthorized?]" to
> >>the end of '4' (to
> >>remain compliant in the presence of requests for
> >>unknown certs), but it
> >>is otherwise my dream scenario.
> >>
> >>
> >>Michael Myers wrote:
> >>
> >>>Dave,
> >>>
> >>>So how about:
> >>>
> >>>1. If we can cycle v1 at Proposed (a big if); then
> >>>
> >>>2. Define nonceUnsupported extension subject to
> >>>   the following semantics (I'm squeezing the
> >>>   words a bit but you'll get the drift)
> >>>
> >>>3. Clients that send a nonce:
> >>>
> >>>   a. MUST reject a non-nonced response
> >>>      if that response includes either the
> >>>      value "good" or "revoked" AND it fails
> >>>      to include the nonceUnsupported extension;
> >>>
> >>>   b. Else, if such response includes the
> >>>      nonceUnsupported extension, clients
> >>>      MAY accept the response subject to the
> >>>      advice in the Security Considerations
> >>>      section of this document.
> >>>
> >>>4. Conversely, if a server receives a nonced
> >>>   request but is unable to incorporate the
> >>>   nonce in its response, the server MUST
> >>>   include the nonceUnsupported extension.
> >>>
> >>> Note that I made no distinction between "good",
> >>> "revoked" or "unknown" in #3.b or #4.  Thus,
> >>> a plain nonceless response of "good" or
> >>> "revoked" is non-conformant, while a caveated
> >>> response is subject to the client's local
> >>> security policy.
> >>>
> >>> Does this seem a fair compromise?  Note well it's highly
> >>> dependent on cycling v1 at Proposed.
> >>>
> >>> Mike
> >
> >
> >
>



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hARJi8ib079389 for <[e-mail]>; Thu, 27 Nov 2003 11:44:08 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hARJi8eM079388 for ietf-pkix-bks; Thu, 27 Nov 2003 11:44:08 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hARJi7ib079382 for <[e-mail]>; Thu, 27 Nov 2003 11:44:07 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (h005008001124.ne.client2.attbi.com[66.31.43.88]) by comcast.net (sccrmhc12) with ESMTP id <2003112719440301200okec4e>; Thu, 27 Nov 2003 19:44:03 +0000
Received: from localhost ([127.0.0.1] helo=corestreet.com ident=dave) by localhost with esmtp (Exim 3.35 #1 (Debian)) id 1APS5O-0005js-00; Thu, 27 Nov 2003 14:45:58 -0500
Message-ID: <[e-mail]>
Date: Thu, 27 Nov 2003 14:45:57 -0500
From: David Engberg <[e-mail]>
Organization: CoreStreet
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Michael Myers <[e-mail]>
CC: [e-mail]
Subject: Re: DISCUSS:  MUST  reject in OCSPv1
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; 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>

Exactly.  I'd implement this right now if I wasn't so full of turkey.


Michael Myers wrote:
> 
> Understand your caching servers MUST send back a caveated
> response which by presence of the caveat may or may not be
> accepted.  No fair sending back plain ones, errors
> notwithstanding.  Is this understood?
> 
> Mike
> 
> 
>>-----Original Message-----
>>From: David Engberg [mailto:[e-mail]]
>>Sent: Thursday, November 27, 2003 12:25 PM
>>To: Michael Myers
>>Cc: [e-mail]
>>Subject: Re: DISCUSS: MUST reject in OCSPv1
>>
>>
>>
>>I'd add "or return an error [e.g. unauthorized?]" to
>>the end of '4' (to
>>remain compliant in the presence of requests for
>>unknown certs), but it
>>is otherwise my dream scenario.
>>
>>
>>Michael Myers wrote:
>>
>>>Dave,
>>>
>>>So how about:
>>>
>>>1. If we can cycle v1 at Proposed (a big if); then
>>>
>>>2. Define nonceUnsupported extension subject to
>>>   the following semantics (I'm squeezing the
>>>   words a bit but you'll get the drift)
>>>
>>>3. Clients that send a nonce:
>>>
>>>   a. MUST reject a non-nonced response
>>>      if that response includes either the
>>>      value "good" or "revoked" AND it fails
>>>      to include the nonceUnsupported extension;
>>>
>>>   b. Else, if such response includes the
>>>      nonceUnsupported extension, clients
>>>      MAY accept the response subject to the
>>>      advice in the Security Considerations
>>>      section of this document.
>>>
>>>4. Conversely, if a server receives a nonced
>>>   request but is unable to incorporate the
>>>   nonce in its response, the server MUST
>>>   include the nonceUnsupported extension.
>>>
>>>Note that I made no distinction between "good", "revoked" or
>>>"unknown" in #3.b or #4.  Thus, a plain nonceless
>>
>>response of
>>
>>>"good" or "revoked" is non-conformant, while a
>>
>>caveated response
>>
>>>is subject to the client's local security policy.
>>>
>>>Does this seem a fair compromise?  Note well it's highly
>>>dependent on cycling v1 at Proposed.
>>>
>>>Mike
> 
> 
> 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hARJdMib079263 for <[e-mail]>; Thu, 27 Nov 2003 11:39:22 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hARJdMKl079262 for ietf-pkix-bks; Thu, 27 Nov 2003 11:39:22 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hARJdLib079257 for <[e-mail]>; Thu, 27 Nov 2003 11:39:21 -0800 (PST) (envelope-from [e-mail])
Received: from MMyersLapTop ([65.39.77.99]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id hARJdLA46693; Thu, 27 Nov 2003 12:39:22 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: "David Engberg" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: DISCUSS:  MUST  reject in OCSPv1
Date: Thu, 27 Nov 2003 12:41:33 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <[e-mail]>
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>

Understand your caching servers MUST send back a caveated
response which by presence of the caveat may or may not be
accepted.  No fair sending back plain ones, errors
notwithstanding.  Is this understood?

Mike

> -----Original Message-----
> From: David Engberg [mailto:[e-mail]]
> Sent: Thursday, November 27, 2003 12:25 PM
> To: Michael Myers
> Cc: [e-mail]
> Subject: Re: DISCUSS: MUST reject in OCSPv1
>
>
>
> I'd add "or return an error [e.g. unauthorized?]" to
> the end of '4' (to
> remain compliant in the presence of requests for
> unknown certs), but it
> is otherwise my dream scenario.
>
>
> Michael Myers wrote:
> > Dave,
> >
> > So how about:
> >
> > 1. If we can cycle v1 at Proposed (a big if); then
> >
> > 2. Define nonceUnsupported extension subject to
> >    the following semantics (I'm squeezing the
> >    words a bit but you'll get the drift)
> >
> > 3. Clients that send a nonce:
> >
> >    a. MUST reject a non-nonced response
> >       if that response includes either the
> >       value "good" or "revoked" AND it fails
> >       to include the nonceUnsupported extension;
> >
> >    b. Else, if such response includes the
> >       nonceUnsupported extension, clients
> >       MAY accept the response subject to the
> >       advice in the Security Considerations
> >       section of this document.
> >
> > 4. Conversely, if a server receives a nonced
> >    request but is unable to incorporate the
> >    nonce in its response, the server MUST
> >    include the nonceUnsupported extension.
> >
> > Note that I made no distinction between "good", "revoked" or
> > "unknown" in #3.b or #4.  Thus, a plain nonceless
> response of
> > "good" or "revoked" is non-conformant, while a
> caveated response
> > is subject to the client's local security policy.
> >
> > Does this seem a fair compromise?  Note well it's highly
> > dependent on cycling v1 at Proposed.
> >
> > Mike



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hARJMpib078704 for <[e-mail]>; Thu, 27 Nov 2003 11:22:51 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hARJMpdI078703 for ietf-pkix-bks; Thu, 27 Nov 2003 11:22:51 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hARJMoib078695 for <[e-mail]>; Thu, 27 Nov 2003 11:22:50 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (h005008001124.ne.client2.attbi.com[66.31.43.88]) by comcast.net (rwcrmhc13) with ESMTP id <2003112719224701500pp63fe>; Thu, 27 Nov 2003 19:22:47 +0000
Received: from localhost ([127.0.0.1] helo=corestreet.com ident=dave) by localhost with esmtp (Exim 3.35 #1 (Debian)) id 1APRkn-0005jT-00; Thu, 27 Nov 2003 14:24:41 -0500
Message-ID: <[e-mail]>
Date: Thu, 27 Nov 2003 14:24:40 -0500
From: David Engberg <[e-mail]>
Organization: CoreStreet
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Michael Myers <[e-mail]>
CC: [e-mail]
Subject: Re: DISCUSS:  MUST  reject in OCSPv1
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; 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>

I'd add "or return an error [e.g. unauthorized?]" to the end of '4' (to 
remain compliant in the presence of requests for unknown certs), but it 
is otherwise my dream scenario.


Michael Myers wrote:
> Dave,
> 
> So how about:
> 
> 1. If we can cycle v1 at Proposed (a big if); then
> 
> 2. Define nonceUnsupported extension subject to
>    the following semantics (I'm squeezing the
>    words a bit but you'll get the drift)
> 
> 3. Clients that send a nonce:
> 
>    a. MUST reject a non-nonced response
>       if that response includes either the
>       value "good" or "revoked" AND it fails
>       to include the nonceUnsupported extension;
> 
>    b. Else, if such response includes the
>       nonceUnsupported extension, clients
>       MAY accept the response subject to the
>       advice in the Security Considerations
>       section of this document.
> 
> 4. Conversely, if a server receives a nonced
>    request but is unable to incorporate the
>    nonce in its response, the server MUST
>    include the nonceUnsupported extension.
> 
> Note that I made no distinction between "good", "revoked" or
> "unknown" in #3.b or #4.  Thus, a plain nonceless response of
> "good" or "revoked" is non-conformant, while a caveated response
> is subject to the client's local security policy.
> 
> Does this seem a fair compromise?  Note well it's highly
> dependent on cycling v1 at Proposed.
> 
> Mike
> 
> 
> 
> 
> 
>>-----Original Message-----
>>From: David Engberg [mailto:[e-mail]]
>>Sent: Thursday, November 27, 2003 10:58 AM
>>To: Michael Myers
>>Cc: [e-mail]
>>Subject: Re: DISCUSS: MUST reject in OCSPv1
>>
>>
>>
>>
>>Michael Myers wrote:
>>
>>>There's a chance we maybe can if we reset 2560 back
>>
>>to Proposed,
>>
>>>still call it v1 and let it cycle there for a
>>
>>while.  I've yet
>>
>>>to hear back from Russ on that one so I've been reluctant to
>>>play that card.  I think what will be the
>>
>>determining factor on
>>
>>>that potential course of action is if we can all
>>
>>agree on the
>>
>>>technical content.  The number of implementors who would be
>>>affected is still quite manageable.
>>
>>This sounds good to me.
>>
>>
>>
>>>I suspect though there still will remain the core issue:
>>>whether or not it is conformant in principle and in
>>
>>the spirit
>>
>>>of the RFC to send a nonceless response to a nonced
>>
>>request.  I
>>
>>>would further refine that by saying any nonceless signed
>>>response containing either "good" or "revoked".  I
>>
>>could accept
>>
>>>"unknown" due to reasons of nonces not being supported as
>>>indicated by a small extension to the protocol.
>>
>>I read the nonce description in the RFC as the client
>>asking for
>>something that it WANTS as opposed to demanding
>>something that it NEEDS.
>>  I.e. a nonce is one element in a list of things
>>like nextUpdate,
>>thisUpdate, producedAt, etc. that a client may use to
>>decide on response
>>acceptance based on the local security policy.
>>
>>The local policy needs to take all of these factors
>>into account, and
>>the absence/presence of a nonce is one factor which
>>may help avoid a
>>specific type of attack.  The default, recommended,
>>behavior is that a
>>nonceless response should be rejected unless the
>>client has a darned
>>good reason for accepting the response based on other
>>factors (e.g. the
>>response comes with a signed letter from the cert's
>>issuer saying it is
>>safe [safer, IMHO, but that's a separate discussion]
>>to accept the
>>nonceless response for its certs).
>>
>>It sounds like your interpretation is that the
>>presence of a nonce is
>>something the client NEEDS and that nonce absence
>>supercedes all other
>>policy considerations.  I don't think this is a
>>horrible interpretation,
>>but it does imply some limitations, as discussed.
>>
>>
> 
> 
> 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hARIoBib076917 for <[e-mail]>; Thu, 27 Nov 2003 10:50:11 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hARIoB9q076916 for ietf-pkix-bks; Thu, 27 Nov 2003 10:50:11 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from sigurd.x509.com ([199.175.155.2]) by above.proper.com (8.12.10/8.12.8) with SMTP id hARIoAib076911 for <[e-mail]>; Thu, 27 Nov 2003 10:50:10 -0800 (PST) (envelope-from [e-mail])
Received: from nebula.x509.com by sigurd.x509.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 27 Nov 2003 18:50:12 UT
Received: from crack.x509.com (localhost [127.0.0.1]) by nebula.x509.com (8.12.10/NULL) with ESMTP id hARIkF6L013804 for <[e-mail]>; Thu, 27 Nov 2003 10:46:16 -0800 (PST)
Received: from exvan01.x509.com (exvan01.x509.com [10.9.22.50]) by crack.x509.com (8.12.10/8.12.10) with ESMTP id hARIoAY0017568 for <[e-mail]>; Thu, 27 Nov 2003 10:50:11 -0800 (PST)
Received: from rsasecurity.com (mbranchaud2.eng.x509.com [10.7.33.48]) by exvan01.x509.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id VQFWG5CY; Thu, 27 Nov 2003 10:59:02 -0800
Message-ID: <[e-mail]>
Date: Thu, 27 Nov 2003 10:40:35 -0800
X-Sybari-Trust: b8320400 64c784fd c3b38011 00000139
From: Marc Branchaud <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031110
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: DISCUSS:  MUST  reject in OCSPv1
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040208080905030407040303"
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.

--------------ms040208080905030407040303
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Ryan M. Hurst wrote:
> I don't think its silly, the client is still protected from the replay 
> if the server responds to a nonced request with a un-nonced one as the 
> client can decide decide if he wanted the protection or needed it.

Why can't the client can decide this before making the request?

What does the client gain by making a nonced request but accepting a 
nonceless response?

> That may sound strange, but nonce has other implications that re-play 
> protection; it also implies freshness since pre-produced responses can 
> not have the right nonce in it.

If the group wishes to address the use of nonces for more than replay 
prevention, then I think the only option is to devise a new OCSPv2 spec.

		M.

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISqTCC
AtcwggJAoAMCAQICEFgUQCxch7Sxp7XFFauIqpwwDQYJKoZIhvcNAQEFBQAwbDEaMBgGA1UE
ChMRUlNBIFNlY3VyaXR5IEluYy4xHjAcBgNVBAMTFVJTQSBQdWJsaWMgUm9vdCBDQSB2MTEu
MCwGCSqGSIb3DQEJARYfcnNha2VvbnJvb3RzaWduQHJzYXNlY3VyaXR5LmNvbTAeFw0wMjA5
MDYxNDEzNTJaFw0wNzA5MDYxNDEzNTJaMIGCMRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5j
LjEVMBMGA1UECxMMS0NBIFNlcnZpY2VzMRYwFAYDVQQDEw1SU0EgQ29ycG9yYXRlMRAwDgYD
VQQHEwdCZWRmb3JkMRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMQswCQYDVQQGEwJVUzCBnzAN
BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAqnOw876lPpMTkSqrqzpEON/609PDLEhmWX4tkC19
AHneDaoetL277GtYYXBCggP2E+s66MN1ccWXyApfWjCZkIHepPC08NVI1JRcbViW3kwLzDD2
w5T9QJcyL5V1pN/LQdxahM56TiLeXlPiJekdmTdJoo+5Pw4bQU+MxTqURk8CAwEAAaNjMGEw
HwYDVR0jBBgwFoAU9UwxelEDPyzXi5eZb6hxkKt4PZswHQYDVR0OBBYEFO2RCGt0t1lKkvah
HSJwJp8KrxaSMA8GA1UdEwQIMAYBAf8CAQMwDgYDVR0PAQH/BAQDAgGGMA0GCSqGSIb3DQEB
BQUAA4GBAHiSe1a79hnPr16PuBwUTBWbuNQ4GJNsyfrCXzAswIT2A2WtGZ1Hp1jEAWi9OfAX
IYAdy52Jyv9N87wAEbLUgVmsFEIlYM5mi6ag7YIRGp8JP5UhLAN9O5YHrR9FsrGK4WmSl3sY
W1qAPOXubFcfhTgUDIYzM30izZBP4nwO07FpMIIC+DCCAmGgAwIBAgIQeuiOriTayCwjwpmR
gmdIUjANBgkqhkiG9w0BAQUFADCBgjEaMBgGA1UEChMRUlNBIFNlY3VyaXR5IEluYy4xFTAT
BgNVBAsTDEtDQSBTZXJ2aWNlczEWMBQGA1UEAxMNUlNBIENvcnBvcmF0ZTEQMA4GA1UEBxMH
QmVkZm9yZDEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMwHhcNMDIwOTIz
MTkxMzAzWhcNMDYwOTIzMTUxMzAzWjCBjDEaMBgGA1UEChMRUlNBIFNlY3VyaXR5IEluYy4x
FTATBgNVBAsTDEtDQSBTZXJ2aWNlczEgMB4GA1UEAxMXUlNBIENsYXNzIDIgUGVyc29uYWwg
Q0ExEDAOBgNVBAcTB0JlZGZvcmQxFjAUBgNVBAgTDU1hc3NhY2h1c2V0dHMxCzAJBgNVBAYT
AlVTMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCkR9yiabyRo6+NwC3Sl8wPuUiBD3rP
sENNjXvzSbTAyXA8pDDndnlAa1nLUhSMgvn8g1sYMd0Bp+C1/mI5PFUZ8jukUK95yt+TK26L
hM/M5RUq/EINdDDdWzg9je498K6oGfyWR6ETSJbIrDe5qQcLCABs9E2gVKb7Z/FwFo3C9QID
AQABo2MwYTAPBgNVHRMECDAGAQH/AgECMA4GA1UdDwEB/wQEAwIBhjAfBgNVHSMEGDAWgBTt
kQhrdLdZSpL2oR0icCafCq8WkjAdBgNVHQ4EFgQUxpPuxqX+41WOz4ojH+6Y3iHyn6cwDQYJ
KoZIhvcNAQEFBQADgYEAcdRHBjq8GfdDoutUTJPtSzQd7XsdsQh2KBbu8utl92VQHuI0J5wc
Rc817G8YbmTtCt/xqAzrr6k7fdaoDBr/kBuVHA5FEJ94foPgrOlbT3zdziMATXh5ESSDLMx6
p8ITIsTJNmwszIG5P9AAKJCW48gu1ZZmLXhFbHcYJGf99pwwggMFMIICbqADAgECAhEAvhyf
0s21hKaAc2Nm1WX4LTANBgkqhkiG9w0BAQUFADCBuzEkMCIGA1UEBxMbVmFsaUNlcnQgVmFs
aWRhdGlvbiBOZXR3b3JrMRcwFQYDVQQKEw5WYWxpQ2VydCwgSW5jLjE1MDMGA1UECxMsVmFs
aUNlcnQgQ2xhc3MgMyBQb2xpY3kgVmFsaWRhdGlvbiBBdXRob3JpdHkxITAfBgNVBAMTGGh0
dHA6Ly93d3cudmFsaWNlcnQuY29tLzEgMB4GCSqGSIb3DQEJARYRaW5mb0B2YWxpY2VydC5j
b20wHhcNMDIwNDMwMTUzMDE5WhcNMTkwNDMwMDkyMTU1WjBsMRowGAYDVQQKExFSU0EgU2Vj
dXJpdHkgSW5jLjEeMBwGA1UEAxMVUlNBIFB1YmxpYyBSb290IENBIHYxMS4wLAYJKoZIhvcN
AQkBFh9yc2FrZW9ucm9vdHNpZ25AcnNhc2VjdXJpdHkuY29tMIGfMA0GCSqGSIb3DQEBAQUA
A4GNADCBiQKBgQC0dSVa2EQ740GxqiIKsHATT4f8XYwUU23pzRe5W6IVpt4jkwDWkgnvTcP6
M8PD4OfK6Imal4hAH/c3K/dUIH7YyQZRGAE5Y27G5klZYKidcFlrfautgVES170MLKFmJqym
2FWAfVOibXatRcw7B0S+mP9404jID/MaIpRXkH5JjwIDAQABo1cwVTAMBgNVHRMEBTADAQH/
MA4GA1UdDwEB/wQEAwIBhjAWBgNVHSAEDzANMAsGCSqGSIb3DQUGATAdBgNVHQ4EFgQU9Uwx
elEDPyzXi5eZb6hxkKt4PZswDQYJKoZIhvcNAQEFBQADgYEAKsviXBc1FeBT2hIwyWuGwnPZ
J9ctjrsO7NbVLjsx/EYclFFGwo+pphiwdUTml9yd7fXzfk0D+7LOs9ZA5xhiHVrGusV4OW4i
7hx2KVILkYlcXCN5tDltKwa5+BkGUuvZdyAoIhpyf61h7uKCFguhaJ+VOiNB4DPtsmxI+KxO
E6YwggTYMIIEQaADAgECAhBgzHl9dAoZGu0JMqXovSgdMA0GCSqGSIb3DQEBBQUAMIGMMRow
GAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEVMBMGA1UECxMMS0NBIFNlcnZpY2VzMSAwHgYD
VQQDExdSU0EgQ2xhc3MgMiBQZXJzb25hbCBDQTEQMA4GA1UEBxMHQmVkZm9yZDEWMBQGA1UE
CBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMwHhcNMDMwNzA3MjMwODEzWhcNMDQwNzA3
MjMwODEzWjCBvjETMBEGCgmSJomT8ixkARkWA2NvbTEbMBkGCgmSJomT8ixkARkWC3JzYXNl
Y3VyaXR5MRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEWMBQGA1UECxMNTm9ydGggQW1l
cmljYTEUMBIGA1UECxMLRW5naW5lZXJpbmcxFzAVBgNVBAMTDk1hcmMgQnJhbmNoYXVkMScw
JQYJKoZIhvcNAQkBFhhtYXJjbmFyY0Byc2FzZWN1cml0eS5jb20wggEiMA0GCSqGSIb3DQEB
AQUAA4IBDwAwggEKAoIBAQDg2xoRr+a/dtnuFG+oTHa+tGtzeObFazNhYV2iSLNED4fHRu86
tknBYFgXggcHW5gsyjfkCtVMzP2tCivmbJgvISo36vsCsmAJH6LRnJf8HsvfmWZaD9tzhDpL
QVsBHr88J0ZMdVniRc7MQoYeu/3hYtUBeGO9bGA6T8vTrnXYonnFtVoTqE62SFqPZZk7HpCS
X1n+dM3zSym2ylMFYE14nukF4I9vAhsQVzk3QNpghmzGj8uoEy9xpf3k0o5+neneAGvcSkwo
r1mH5tSqhrEQaZp7vuSA2bvXaZEnjZzZiTpPDzs1oMpn3guzYhU7wMKz6xvwvgEYyAAV+P5n
FWM/AgMBAAGjggGBMIIBfTCBkgYDVR0gBIGKMIGHMIGEBgkqhkiG9w0FBwIwdzAuBggrBgEF
BQcCARYiaHR0cDovL2NhLnJzYXNlY3VyaXR5LmNvbS9DUFMuaHRtbDBFBggrBgEFBQcCAjA5
MBgWEVJTQSBTZWN1cml0eSBJbmMuMAMCAQEaHUNQUyBJbmNvcnBvcmF0ZWQgYnkgcmVmZXJl
bmNlMCkGA1UdJQQiMCAGCisGAQQBgjcUAgIGCCsGAQUFBwMCBggrBgEFBQcDBDAjBgNVHREE
HDAagRhtYXJjbmFyY0Byc2FzZWN1cml0eS5jb20wDgYDVR0PAQH/BAQDAgeAMEYGA1UdHwQ/
MD0wO6A5oDeGNWh0dHA6Ly9jcmwucnNhc2VjdXJpdHkuY29tOjgwL1JTQUNsYXNzMlBlcnNv
bmFsQ0EuY3JsMB8GA1UdIwQYMBaAFMaT7sal/uNVjs+KIx/umN4h8p+nMB0GA1UdDgQWBBQ1
yQ/UrvKb563LjzHqJzBzrZp/ejANBgkqhkiG9w0BAQUFAAOBgQCV82oGGnglQQzklKg/wKhy
evNeJ6FNBZFhLlmZRNlKgqvPFmBcxygfBGpHqIhsHcrt2/AjhJuzAj7UdW1vTVCY5MkZw8P9
6+J6aTc3bNlGbk0jvcvVgDhmM4xYJLwMZKEw92HlRhfuMnj7ah9DTqbKSewmyAyOc+FLpGfd
lu6CgTCCBOkwggRSoAMCAQICEQDqxAXqre9Mr+FeYw3+MQhsMA0GCSqGSIb3DQEBBQUAMIGM
MRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEVMBMGA1UECxMMS0NBIFNlcnZpY2VzMSAw
HgYDVQQDExdSU0EgQ2xhc3MgMiBQZXJzb25hbCBDQTEQMA4GA1UEBxMHQmVkZm9yZDEWMBQG
A1UECBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMwHhcNMDMwNzA3MjMwODI4WhcNMDQw
NzA3MjMwODEzWjCBwjETMBEGCgmSJomT8ixkARkWA2NvbTEbMBkGCgmSJomT8ixkARkWC3Jz
YXNlY3VyaXR5MRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEWMBQGA1UECxMNTm9ydGgg
QW1lcmljYTEUMBIGA1UECxMLRW5naW5lZXJpbmcxGzAZBgNVBAMTEk1hcmMgQnJhbmNoYXVk
LUVuYzEnMCUGCSqGSIb3DQEJARYYbWFyY25hcmNAcnNhc2VjdXJpdHkuY29tMIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwBjNaHTwtCXpdJg+iDxYMkWjuZIF0ic2fRLymZe+
BnZYWPnik0dFmTulx+V8slsLEtBllcc5o1yfIYfeHPinwRxv86kCUSlgfGGXKjJZaIeURgbo
bUbIfDTPlvRUZuiZvTR4C8tEY88Lle66n62B7wjUvDbiwK4EjzlXOkjpcYXLH7FbaFaRLDBB
PlFD5ydDRhQ67t6fjUeS7p7o/l/VHmPC5LFLXZkjEhjGd5pknbQIAbUGACL5UET85NUFPowD
3F47g0GCKEnuOsk2Ra+WHu7honhIxqmOwGnu85V6tW5xscf4dTofWZONQeaD3gSxv8+hcfKN
k9cwjpnUG2xGzwIDAQABo4IBjTCCAYkwNQYDVR0lBC4wLAYKKwYBBAGCNxQCAgYIKwYBBQUH
AwIGCCsGAQUFBwMEBgorBgEEAYI3CgMEMIGSBgNVHSAEgYowgYcwgYQGCSqGSIb3DQUHAjB3
MC4GCCsGAQUFBwIBFiJodHRwOi8vY2EucnNhc2VjdXJpdHkuY29tL0NQUy5odG1sMEUGCCsG
AQUFBwICMDkwGBYRUlNBIFNlY3VyaXR5IEluYy4wAwIBARodQ1BTIEluY29ycG9yYXRlZCBi
eSByZWZlcmVuY2UwIwYDVR0RBBwwGoEYbWFyY25hcmNAcnNhc2VjdXJpdHkuY29tMEYGA1Ud
HwQ/MD0wO6A5oDeGNWh0dHA6Ly9jcmwucnNhc2VjdXJpdHkuY29tOjgwL1JTQUNsYXNzMlBl
cnNvbmFsQ0EuY3JsMB8GA1UdIwQYMBaAFMaT7sal/uNVjs+KIx/umN4h8p+nMB0GA1UdDgQW
BBT/OiMCyY8CPnNBySW1ijJOYhj7ejAOBgNVHQ8BAf8EBAMCAzgwDQYJKoZIhvcNAQEFBQAD
gYEAlchAObA9eVmeiLu0nTU985Fch6v+EZKodUhZUN7dILgd05HorHN9jxBH6XI4/b9ZVvub
Pkpicdc112YbcLYTD2NumVksyNDI7fDaqiszgk1zluXtZJ+HsCt+GIAKCDfOVLECclpGyizq
VjZFEK4Pt9FxPGTnUJEvIKJcAQ24EvgxggPsMIID6AIBATCBoTCBjDEaMBgGA1UEChMRUlNB
IFNlY3VyaXR5IEluYy4xFTATBgNVBAsTDEtDQSBTZXJ2aWNlczEgMB4GA1UEAxMXUlNBIENs
YXNzIDIgUGVyc29uYWwgQ0ExEDAOBgNVBAcTB0JlZGZvcmQxFjAUBgNVBAgTDU1hc3NhY2h1
c2V0dHMxCzAJBgNVBAYTAlVTAhBgzHl9dAoZGu0JMqXovSgdMAkGBSsOAwIaBQCgggIfMBgG
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMTEyNzE4NDAzNVow
IwYJKoZIhvcNAQkEMRYEFJAfkRiXgoMj7ww2dZxEPOvj5QbmMFIGCSqGSIb3DQEJDzFFMEMw
CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G
CCqGSIb3DQMCAgEoMIGzBgkrBgEEAYI3EAQxgaUwgaIwgYwxGjAYBgNVBAoTEVJTQSBTZWN1
cml0eSBJbmMuMRUwEwYDVQQLEwxLQ0EgU2VydmljZXMxIDAeBgNVBAMTF1JTQSBDbGFzcyAy
IFBlcnNvbmFsIENBMRAwDgYDVQQHEwdCZWRmb3JkMRYwFAYDVQQIEw1NYXNzYWNodXNldHRz
MQswCQYDVQQGEwJVUwIRAOrEBeqt70yv4V5jDf4xCGwwgbUGCyqGSIb3DQEJEAILMYGloIGi
MIGMMRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEVMBMGA1UECxMMS0NBIFNlcnZpY2Vz
MSAwHgYDVQQDExdSU0EgQ2xhc3MgMiBQZXJzb25hbCBDQTEQMA4GA1UEBxMHQmVkZm9yZDEW
MBQGA1UECBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMCEQDqxAXqre9Mr+FeYw3+MQhs
MA0GCSqGSIb3DQEBAQUABIIBABeQjxTNLFQOaUM2us/RzhzIjRtb0DEozvI6cNZxc1+UZjrS
LNIq5XFbhn3j29dZZCmiZKrjqlwyZ7X5feJI3PfnxpwV5HMXpAj87yiLuGmzvdmSuglekgw7
2UPuVldc2UFfRsnNMXAUTftuGh/we6aRa1i7JjtBQQufWTpW0+Jc/fnTVwrU+YVO2YI9ysNu
TWuiOIeDHomxhiobh134vSbU1nkMp5S1/j1AdrUDznUwpYlzIka3A72/Z8d5uUUtYDpqAaoA
sw44yUJNX/jCMCwroIbolGVQXJWz7V6crGEBpKrRD7yfBVZ2tTOVLst2w91A0qUG33vCRhLZ
sgk/bvgAAAAAAAA=
--------------ms040208080905030407040303--


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hARIl9ib076806 for <[e-mail]>; Thu, 27 Nov 2003 10:47:09 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hARIl9UF076805 for ietf-pkix-bks; Thu, 27 Nov 2003 10:47:09 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from sigurd.x509.com ([199.175.155.2]) by above.proper.com (8.12.10/8.12.8) with SMTP id hARIl8ib076799 for <[e-mail]>; Thu, 27 Nov 2003 10:47:08 -0800 (PST) (envelope-from [e-mail])
Received: from nebula.x509.com by sigurd.x509.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 27 Nov 2003 18:47:10 UT
Received: from crack.x509.com (localhost [127.0.0.1]) by nebula.x509.com (8.12.10/NULL) with ESMTP id hARIhD6L013783 for <[e-mail]>; Thu, 27 Nov 2003 10:43:14 -0800 (PST)
Received: from exvan01.x509.com (exvan01.x509.com [10.9.22.50]) by crack.x509.com (8.12.10/8.12.10) with ESMTP id hARIl8Y0017476 for <[e-mail]>; Thu, 27 Nov 2003 10:47:09 -0800 (PST)
Received: from rsasecurity.com (mbranchaud2.eng.x509.com [10.7.33.48]) by exvan01.x509.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id VQFWG5BV; Thu, 27 Nov 2003 10:55:59 -0800
Message-ID: <[e-mail]>
Date: Thu, 27 Nov 2003 10:37:33 -0800
X-Sybari-Trust: 02799f79 64c784fd c3b38011 00000139
From: Marc Branchaud <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031110
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: DISCUSS:  MUST  reject in OCSPv1
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000306080004030900010605"
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.

--------------ms000306080004030900010605
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit


I support Mike's proposal to add "MUST reject" language to v1.  I am 
also fine with the idea of holding back OCSP and crafting a v2 to 
address people's concerns.

Rationale: RFC2560 explicitly states that nonces are used "to prevent 
replay attacks."  The RFC couldn't be more clear.  In order to prevent a 
replay attack, standard security practice is for a client to include a 
nonce in a request and to reject a response that does not echo the nonce.

Therefore, "MUST reject" is completely in line with the original RFC's 
use of the nonce extension.  Any other use of the nonce is going beyond 
the RFC's clear and explicit intentions.

To me, expanding the scope of a specification is something that is more 
appropriately done in a "next-generation" context.  That is, if you want 
to expand the scope you should increment the version number.

So if the goal is to clarify the OCSPv1 spec as it progresses up the 
standards track, the only option is to use the "MUST reject" language.

If, OTOH, the group is willing to delay OCSP's progress and put a 
revised OCSPv2 through the standards process, then expanding the scope 
is perfectly fine.


Assorted comments to several people follow:

Michael Myers wrote:
> 
> (silence WILL be taken as consent)

Mike, that statement was your first mistake!  :)


David Engberg wrote:
> 
> 
> I posit that there is a third local security policy that the MUST 
> language prohibits, and that policy can be achieved under v1 SHOULD 
> language:
> 
>   3) Send a nonce to Acme's server, and accept the response IFF
>      the response contains the nonce OR the server SECURELY signals
>      that it does not supply nonces to anyone.

This is an expansion of OCSP's scope, going beyond the spec's explicit 
statements about the use of nonces.  Support for this should be 
addressed in a v2 spec.  It's inappropriate to try to shoehorn this into v1.

David Engberg also wrote:
> 
> I disagree that we need to intentionally modify the existing RFC 
> language to absolutely prohibit implementors from allowing such optional 
> local security policies using the normal extensions mechanism in v1.

The client is perfectly free to follow the policies you propose by not 
including the nonce.  Clients gain nothing by including a nonce if 
they're willing to accept nonceless responses.

> I don't believe that anyone is condoning any insecure practices.  I 
> believe that there are several secure practices under discussion, and 
> your (legitimate) concern is that those practices were not presented 
> soon enough to be written directly into the v1 standard.  So ... leave 
> them out of the standard, but leave some room for security extensibility.

There is no need to water down the nonce extension to support the 
practices you propose.


Santosh Chokhani wrote:
> 
> When the client does not get the nonce back, it knows either there is a 
> replay or the server is doing pre-production.  But, the client has this 
> knowledge, this Update, Next Update and produced at fields, and the 
> application context to make the determination whether to reject the 
> transaction or not.

This is also an expansion, using the nonce for more than preventing 
replay attacks.  Here you're trying to use the nonce as an optimization 
-- if the nonce is in the response, the client can avoid checking those 
time fields.

Frankly, I find that optimization doesn't really gain much performance. 
  It certainly does not improve security.

If the client is willing to use the time fields to accept or reject the 
response, it has no need or reason in put a nonce in its request.


Florian Oelmaier wrote:
> 
> I object. It breaks running code in installations.

That code is not secure, and did not follow the spec.

> It changes the spirit
> of the protocol as a lot of people understood it (due to the current
> wording in RfC2560).

As I said above, it is exactly in line with the spirit of the protocol. 
  The current wording of the RFC is very clear about what the nonce is 
for.  Implementations that would "break" under Mike's proposal failed to 
read the spec properly.

> And most important, I object as there are better
> solutions already outlined (see more below).

All of the solutions you seem to favour are not in the spirit of the 
protocol, as stated in the RFC.

> Thus most clients do not know if the Responder supports nonces or not
> (e.g. due to caching). How should they, they didnt even knew the URL
> until they read the AIA!
> 
> Seeing this it is a very acceptable for a client to TRY to get a nonce,
> but to accept answers without nonces as a fallback.

No, it is not acceptable.  The RFC is very clear: use nonces to prevent 
replay attacks.  If the client is concerned about replay attacks, it 
must reject a nonceless response.

> It is a "natural"
> behaviour - I try for all extensions I support, but will fall back to
> the very basics of the standard, to the "not extended" behaviour when I
> cannot get what I want. This is the usual way of doing things in nearly
> all protocols out there, PKIX or not.

Nearly all protocols out there are insecure.  This is a security WG...

> So the very basic assumption of your argument is not true at least for
> my client. I use nonces to prevent replay attacks WHERE POSSIBLE. If it
> is not possible, I will not give up and will instead do my best to get a
> revocation information that is as good as the information in a CRL is.

This is a reasonable argument.  However, it is not what OCSPv1 was 
designed to support.  An opportunity to make clarifying changes in 
OCSPv1 as it becomes a standard is not the right time to expand its scope.

> So the very first question is:
> 
> *** IS IT REASONABLE FOR A CLIENT TO ASK FOR A NONCE BUT ALSO TO WORK
> WITH RESPONSES WITHOUT NONCE? ***

(STOP SHOUTING, please.)

> If the answer is "NO", the MUST-REJECT solution to the problem is the
> way to go. 

The answer is no.  This is clear from RFC2560's text.

		M.

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISqTCC
AtcwggJAoAMCAQICEFgUQCxch7Sxp7XFFauIqpwwDQYJKoZIhvcNAQEFBQAwbDEaMBgGA1UE
ChMRUlNBIFNlY3VyaXR5IEluYy4xHjAcBgNVBAMTFVJTQSBQdWJsaWMgUm9vdCBDQSB2MTEu
MCwGCSqGSIb3DQEJARYfcnNha2VvbnJvb3RzaWduQHJzYXNlY3VyaXR5LmNvbTAeFw0wMjA5
MDYxNDEzNTJaFw0wNzA5MDYxNDEzNTJaMIGCMRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5j
LjEVMBMGA1UECxMMS0NBIFNlcnZpY2VzMRYwFAYDVQQDEw1SU0EgQ29ycG9yYXRlMRAwDgYD
VQQHEwdCZWRmb3JkMRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMQswCQYDVQQGEwJVUzCBnzAN
BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAqnOw876lPpMTkSqrqzpEON/609PDLEhmWX4tkC19
AHneDaoetL277GtYYXBCggP2E+s66MN1ccWXyApfWjCZkIHepPC08NVI1JRcbViW3kwLzDD2
w5T9QJcyL5V1pN/LQdxahM56TiLeXlPiJekdmTdJoo+5Pw4bQU+MxTqURk8CAwEAAaNjMGEw
HwYDVR0jBBgwFoAU9UwxelEDPyzXi5eZb6hxkKt4PZswHQYDVR0OBBYEFO2RCGt0t1lKkvah
HSJwJp8KrxaSMA8GA1UdEwQIMAYBAf8CAQMwDgYDVR0PAQH/BAQDAgGGMA0GCSqGSIb3DQEB
BQUAA4GBAHiSe1a79hnPr16PuBwUTBWbuNQ4GJNsyfrCXzAswIT2A2WtGZ1Hp1jEAWi9OfAX
IYAdy52Jyv9N87wAEbLUgVmsFEIlYM5mi6ag7YIRGp8JP5UhLAN9O5YHrR9FsrGK4WmSl3sY
W1qAPOXubFcfhTgUDIYzM30izZBP4nwO07FpMIIC+DCCAmGgAwIBAgIQeuiOriTayCwjwpmR
gmdIUjANBgkqhkiG9w0BAQUFADCBgjEaMBgGA1UEChMRUlNBIFNlY3VyaXR5IEluYy4xFTAT
BgNVBAsTDEtDQSBTZXJ2aWNlczEWMBQGA1UEAxMNUlNBIENvcnBvcmF0ZTEQMA4GA1UEBxMH
QmVkZm9yZDEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMwHhcNMDIwOTIz
MTkxMzAzWhcNMDYwOTIzMTUxMzAzWjCBjDEaMBgGA1UEChMRUlNBIFNlY3VyaXR5IEluYy4x
FTATBgNVBAsTDEtDQSBTZXJ2aWNlczEgMB4GA1UEAxMXUlNBIENsYXNzIDIgUGVyc29uYWwg
Q0ExEDAOBgNVBAcTB0JlZGZvcmQxFjAUBgNVBAgTDU1hc3NhY2h1c2V0dHMxCzAJBgNVBAYT
AlVTMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCkR9yiabyRo6+NwC3Sl8wPuUiBD3rP
sENNjXvzSbTAyXA8pDDndnlAa1nLUhSMgvn8g1sYMd0Bp+C1/mI5PFUZ8jukUK95yt+TK26L
hM/M5RUq/EINdDDdWzg9je498K6oGfyWR6ETSJbIrDe5qQcLCABs9E2gVKb7Z/FwFo3C9QID
AQABo2MwYTAPBgNVHRMECDAGAQH/AgECMA4GA1UdDwEB/wQEAwIBhjAfBgNVHSMEGDAWgBTt
kQhrdLdZSpL2oR0icCafCq8WkjAdBgNVHQ4EFgQUxpPuxqX+41WOz4ojH+6Y3iHyn6cwDQYJ
KoZIhvcNAQEFBQADgYEAcdRHBjq8GfdDoutUTJPtSzQd7XsdsQh2KBbu8utl92VQHuI0J5wc
Rc817G8YbmTtCt/xqAzrr6k7fdaoDBr/kBuVHA5FEJ94foPgrOlbT3zdziMATXh5ESSDLMx6
p8ITIsTJNmwszIG5P9AAKJCW48gu1ZZmLXhFbHcYJGf99pwwggMFMIICbqADAgECAhEAvhyf
0s21hKaAc2Nm1WX4LTANBgkqhkiG9w0BAQUFADCBuzEkMCIGA1UEBxMbVmFsaUNlcnQgVmFs
aWRhdGlvbiBOZXR3b3JrMRcwFQYDVQQKEw5WYWxpQ2VydCwgSW5jLjE1MDMGA1UECxMsVmFs
aUNlcnQgQ2xhc3MgMyBQb2xpY3kgVmFsaWRhdGlvbiBBdXRob3JpdHkxITAfBgNVBAMTGGh0
dHA6Ly93d3cudmFsaWNlcnQuY29tLzEgMB4GCSqGSIb3DQEJARYRaW5mb0B2YWxpY2VydC5j
b20wHhcNMDIwNDMwMTUzMDE5WhcNMTkwNDMwMDkyMTU1WjBsMRowGAYDVQQKExFSU0EgU2Vj
dXJpdHkgSW5jLjEeMBwGA1UEAxMVUlNBIFB1YmxpYyBSb290IENBIHYxMS4wLAYJKoZIhvcN
AQkBFh9yc2FrZW9ucm9vdHNpZ25AcnNhc2VjdXJpdHkuY29tMIGfMA0GCSqGSIb3DQEBAQUA
A4GNADCBiQKBgQC0dSVa2EQ740GxqiIKsHATT4f8XYwUU23pzRe5W6IVpt4jkwDWkgnvTcP6
M8PD4OfK6Imal4hAH/c3K/dUIH7YyQZRGAE5Y27G5klZYKidcFlrfautgVES170MLKFmJqym
2FWAfVOibXatRcw7B0S+mP9404jID/MaIpRXkH5JjwIDAQABo1cwVTAMBgNVHRMEBTADAQH/
MA4GA1UdDwEB/wQEAwIBhjAWBgNVHSAEDzANMAsGCSqGSIb3DQUGATAdBgNVHQ4EFgQU9Uwx
elEDPyzXi5eZb6hxkKt4PZswDQYJKoZIhvcNAQEFBQADgYEAKsviXBc1FeBT2hIwyWuGwnPZ
J9ctjrsO7NbVLjsx/EYclFFGwo+pphiwdUTml9yd7fXzfk0D+7LOs9ZA5xhiHVrGusV4OW4i
7hx2KVILkYlcXCN5tDltKwa5+BkGUuvZdyAoIhpyf61h7uKCFguhaJ+VOiNB4DPtsmxI+KxO
E6YwggTYMIIEQaADAgECAhBgzHl9dAoZGu0JMqXovSgdMA0GCSqGSIb3DQEBBQUAMIGMMRow
GAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEVMBMGA1UECxMMS0NBIFNlcnZpY2VzMSAwHgYD
VQQDExdSU0EgQ2xhc3MgMiBQZXJzb25hbCBDQTEQMA4GA1UEBxMHQmVkZm9yZDEWMBQGA1UE
CBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMwHhcNMDMwNzA3MjMwODEzWhcNMDQwNzA3
MjMwODEzWjCBvjETMBEGCgmSJomT8ixkARkWA2NvbTEbMBkGCgmSJomT8ixkARkWC3JzYXNl
Y3VyaXR5MRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEWMBQGA1UECxMNTm9ydGggQW1l
cmljYTEUMBIGA1UECxMLRW5naW5lZXJpbmcxFzAVBgNVBAMTDk1hcmMgQnJhbmNoYXVkMScw
JQYJKoZIhvcNAQkBFhhtYXJjbmFyY0Byc2FzZWN1cml0eS5jb20wggEiMA0GCSqGSIb3DQEB
AQUAA4IBDwAwggEKAoIBAQDg2xoRr+a/dtnuFG+oTHa+tGtzeObFazNhYV2iSLNED4fHRu86
tknBYFgXggcHW5gsyjfkCtVMzP2tCivmbJgvISo36vsCsmAJH6LRnJf8HsvfmWZaD9tzhDpL
QVsBHr88J0ZMdVniRc7MQoYeu/3hYtUBeGO9bGA6T8vTrnXYonnFtVoTqE62SFqPZZk7HpCS
X1n+dM3zSym2ylMFYE14nukF4I9vAhsQVzk3QNpghmzGj8uoEy9xpf3k0o5+neneAGvcSkwo
r1mH5tSqhrEQaZp7vuSA2bvXaZEnjZzZiTpPDzs1oMpn3guzYhU7wMKz6xvwvgEYyAAV+P5n
FWM/AgMBAAGjggGBMIIBfTCBkgYDVR0gBIGKMIGHMIGEBgkqhkiG9w0FBwIwdzAuBggrBgEF
BQcCARYiaHR0cDovL2NhLnJzYXNlY3VyaXR5LmNvbS9DUFMuaHRtbDBFBggrBgEFBQcCAjA5
MBgWEVJTQSBTZWN1cml0eSBJbmMuMAMCAQEaHUNQUyBJbmNvcnBvcmF0ZWQgYnkgcmVmZXJl
bmNlMCkGA1UdJQQiMCAGCisGAQQBgjcUAgIGCCsGAQUFBwMCBggrBgEFBQcDBDAjBgNVHREE
HDAagRhtYXJjbmFyY0Byc2FzZWN1cml0eS5jb20wDgYDVR0PAQH/BAQDAgeAMEYGA1UdHwQ/
MD0wO6A5oDeGNWh0dHA6Ly9jcmwucnNhc2VjdXJpdHkuY29tOjgwL1JTQUNsYXNzMlBlcnNv
bmFsQ0EuY3JsMB8GA1UdIwQYMBaAFMaT7sal/uNVjs+KIx/umN4h8p+nMB0GA1UdDgQWBBQ1
yQ/UrvKb563LjzHqJzBzrZp/ejANBgkqhkiG9w0BAQUFAAOBgQCV82oGGnglQQzklKg/wKhy
evNeJ6FNBZFhLlmZRNlKgqvPFmBcxygfBGpHqIhsHcrt2/AjhJuzAj7UdW1vTVCY5MkZw8P9
6+J6aTc3bNlGbk0jvcvVgDhmM4xYJLwMZKEw92HlRhfuMnj7ah9DTqbKSewmyAyOc+FLpGfd
lu6CgTCCBOkwggRSoAMCAQICEQDqxAXqre9Mr+FeYw3+MQhsMA0GCSqGSIb3DQEBBQUAMIGM
MRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEVMBMGA1UECxMMS0NBIFNlcnZpY2VzMSAw
HgYDVQQDExdSU0EgQ2xhc3MgMiBQZXJzb25hbCBDQTEQMA4GA1UEBxMHQmVkZm9yZDEWMBQG
A1UECBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMwHhcNMDMwNzA3MjMwODI4WhcNMDQw
NzA3MjMwODEzWjCBwjETMBEGCgmSJomT8ixkARkWA2NvbTEbMBkGCgmSJomT8ixkARkWC3Jz
YXNlY3VyaXR5MRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEWMBQGA1UECxMNTm9ydGgg
QW1lcmljYTEUMBIGA1UECxMLRW5naW5lZXJpbmcxGzAZBgNVBAMTEk1hcmMgQnJhbmNoYXVk
LUVuYzEnMCUGCSqGSIb3DQEJARYYbWFyY25hcmNAcnNhc2VjdXJpdHkuY29tMIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwBjNaHTwtCXpdJg+iDxYMkWjuZIF0ic2fRLymZe+
BnZYWPnik0dFmTulx+V8slsLEtBllcc5o1yfIYfeHPinwRxv86kCUSlgfGGXKjJZaIeURgbo
bUbIfDTPlvRUZuiZvTR4C8tEY88Lle66n62B7wjUvDbiwK4EjzlXOkjpcYXLH7FbaFaRLDBB
PlFD5ydDRhQ67t6fjUeS7p7o/l/VHmPC5LFLXZkjEhjGd5pknbQIAbUGACL5UET85NUFPowD
3F47g0GCKEnuOsk2Ra+WHu7honhIxqmOwGnu85V6tW5xscf4dTofWZONQeaD3gSxv8+hcfKN
k9cwjpnUG2xGzwIDAQABo4IBjTCCAYkwNQYDVR0lBC4wLAYKKwYBBAGCNxQCAgYIKwYBBQUH
AwIGCCsGAQUFBwMEBgorBgEEAYI3CgMEMIGSBgNVHSAEgYowgYcwgYQGCSqGSIb3DQUHAjB3
MC4GCCsGAQUFBwIBFiJodHRwOi8vY2EucnNhc2VjdXJpdHkuY29tL0NQUy5odG1sMEUGCCsG
AQUFBwICMDkwGBYRUlNBIFNlY3VyaXR5IEluYy4wAwIBARodQ1BTIEluY29ycG9yYXRlZCBi
eSByZWZlcmVuY2UwIwYDVR0RBBwwGoEYbWFyY25hcmNAcnNhc2VjdXJpdHkuY29tMEYGA1Ud
HwQ/MD0wO6A5oDeGNWh0dHA6Ly9jcmwucnNhc2VjdXJpdHkuY29tOjgwL1JTQUNsYXNzMlBl
cnNvbmFsQ0EuY3JsMB8GA1UdIwQYMBaAFMaT7sal/uNVjs+KIx/umN4h8p+nMB0GA1UdDgQW
BBT/OiMCyY8CPnNBySW1ijJOYhj7ejAOBgNVHQ8BAf8EBAMCAzgwDQYJKoZIhvcNAQEFBQAD
gYEAlchAObA9eVmeiLu0nTU985Fch6v+EZKodUhZUN7dILgd05HorHN9jxBH6XI4/b9ZVvub
Pkpicdc112YbcLYTD2NumVksyNDI7fDaqiszgk1zluXtZJ+HsCt+GIAKCDfOVLECclpGyizq
VjZFEK4Pt9FxPGTnUJEvIKJcAQ24EvgxggPsMIID6AIBATCBoTCBjDEaMBgGA1UEChMRUlNB
IFNlY3VyaXR5IEluYy4xFTATBgNVBAsTDEtDQSBTZXJ2aWNlczEgMB4GA1UEAxMXUlNBIENs
YXNzIDIgUGVyc29uYWwgQ0ExEDAOBgNVBAcTB0JlZGZvcmQxFjAUBgNVBAgTDU1hc3NhY2h1
c2V0dHMxCzAJBgNVBAYTAlVTAhBgzHl9dAoZGu0JMqXovSgdMAkGBSsOAwIaBQCgggIfMBgG
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMTEyNzE4MzczM1ow
IwYJKoZIhvcNAQkEMRYEFG7NArnIAp4D7uBY5knmGBys+KHoMFIGCSqGSIb3DQEJDzFFMEMw
CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G
CCqGSIb3DQMCAgEoMIGzBgkrBgEEAYI3EAQxgaUwgaIwgYwxGjAYBgNVBAoTEVJTQSBTZWN1
cml0eSBJbmMuMRUwEwYDVQQLEwxLQ0EgU2VydmljZXMxIDAeBgNVBAMTF1JTQSBDbGFzcyAy
IFBlcnNvbmFsIENBMRAwDgYDVQQHEwdCZWRmb3JkMRYwFAYDVQQIEw1NYXNzYWNodXNldHRz
MQswCQYDVQQGEwJVUwIRAOrEBeqt70yv4V5jDf4xCGwwgbUGCyqGSIb3DQEJEAILMYGloIGi
MIGMMRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEVMBMGA1UECxMMS0NBIFNlcnZpY2Vz
MSAwHgYDVQQDExdSU0EgQ2xhc3MgMiBQZXJzb25hbCBDQTEQMA4GA1UEBxMHQmVkZm9yZDEW
MBQGA1UECBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMCEQDqxAXqre9Mr+FeYw3+MQhs
MA0GCSqGSIb3DQEBAQUABIIBABWcoipOx1WQaLj6GW9XBzG4X8qwovkyjepERZDMzDWidH/R
jRFydSneZ78BlsJLgyxHnDgD9TwNqU6GInYJuvpdVFwmLKvVOq4gH6Wu+gdONu+c6UIgRcJw
rTRH+7awOqwczZNEOtbVx8uK1GSrhyw3f8DAy4rQdQNI/xfF+ur5Gkm3DYOC5UpAegflFN3p
7wCJa8MtdV9sGTH9xAH+0T6zPSDan5jHoyuEMi2pAZ3KutvCmtcfgnS5ot7Y9njaDmg8ZIYD
DgoVeLkeNsY+JIxTAG161t5oWt8hwOVeJ4cEecO5YFm6+mr2kCtatJs518Rtjg0wSp5zvD3Y
BcIv6+EAAAAAAAA=
--------------ms000306080004030900010605--


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hARIcrib076586 for <[e-mail]>; Thu, 27 Nov 2003 10:38:53 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hARIcqO5076585 for ietf-pkix-bks; Thu, 27 Nov 2003 10:38:52 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hARIcpib076580 for <[e-mail]>; Thu, 27 Nov 2003 10:38:51 -0800 (PST) (envelope-from [e-mail])
Received: from MMyersLapTop ([65.39.77.99]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id hARIcqA43461; Thu, 27 Nov 2003 11:38:52 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: "David Engberg" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: DISCUSS:  MUST  reject in OCSPv1
Date: Thu, 27 Nov 2003 11:41:03 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <[e-mail]>
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>

Dave,

So how about:

1. If we can cycle v1 at Proposed (a big if); then

2. Define nonceUnsupported extension subject to
   the following semantics (I'm squeezing the
   words a bit but you'll get the drift)

3. Clients that send a nonce:

   a. MUST reject a non-nonced response
      if that response includes either the
      value "good" or "revoked" AND it fails
      to include the nonceUnsupported extension;

   b. Else, if such response includes the
      nonceUnsupported extension, clients
      MAY accept the response subject to the
      advice in the Security Considerations
      section of this document.

4. Conversely, if a server receives a nonced
   request but is unable to incorporate the
   nonce in its response, the server MUST
   include the nonceUnsupported extension.

Note that I made no distinction between "good", "revoked" or
"unknown" in #3.b or #4.  Thus, a plain nonceless response of
"good" or "revoked" is non-conformant, while a caveated response
is subject to the client's local security policy.

Does this seem a fair compromise?  Note well it's highly
dependent on cycling v1 at Proposed.

Mike




> -----Original Message-----
> From: David Engberg [mailto:[e-mail]]
> Sent: Thursday, November 27, 2003 10:58 AM
> To: Michael Myers
> Cc: [e-mail]
> Subject: Re: DISCUSS: MUST reject in OCSPv1
>
>
>
>
> Michael Myers wrote:
> > There's a chance we maybe can if we reset 2560 back
> to Proposed,
> > still call it v1 and let it cycle there for a
> while.  I've yet
> > to hear back from Russ on that one so I've been reluctant to
> > play that card.  I think what will be the
> determining factor on
> > that potential course of action is if we can all
> agree on the
> > technical content.  The number of implementors who would be
> > affected is still quite manageable.
>
> This sounds good to me.
>
>
> > I suspect though there still will remain the core issue:
> > whether or not it is conformant in principle and in
> the spirit
> > of the RFC to send a nonceless response to a nonced
> request.  I
> > would further refine that by saying any nonceless signed
> > response containing either "good" or "revoked".  I
> could accept
> > "unknown" due to reasons of nonces not being supported as
> > indicated by a small extension to the protocol.
>
> I read the nonce description in the RFC as the client
> asking for
> something that it WANTS as opposed to demanding
> something that it NEEDS.
>   I.e. a nonce is one element in a list of things
> like nextUpdate,
> thisUpdate, producedAt, etc. that a client may use to
> decide on response
> acceptance based on the local security policy.
>
> The local policy needs to take all of these factors
> into account, and
> the absence/presence of a nonce is one factor which
> may help avoid a
> specific type of attack.  The default, recommended,
> behavior is that a
> nonceless response should be rejected unless the
> client has a darned
> good reason for accepting the response based on other
> factors (e.g. the
> response comes with a signed letter from the cert's
> issuer saying it is
> safe [safer, IMHO, but that's a separate discussion]
> to accept the
> nonceless response for its certs).
>
> It sounds like your interpretation is that the
> presence of a nonce is
> something the client NEEDS and that nonce absence
> supercedes all other
> policy considerations.  I don't think this is a
> horrible interpretation,
> but it does imply some limitations, as discussed.
>
>



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hARIYfib076398 for <[e-mail]>; Thu, 27 Nov 2003 10:34:41 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hARIYfvw076397 for ietf-pkix-bks; Thu, 27 Nov 2003 10:34:41 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from seguridata1.seguridata.com ([200.57.34.107]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hARIYdib076390 for <[e-mail]>; Thu, 27 Nov 2003 10:34:39 -0800 (PST) (envelope-from [e-mail])
Received: from MarsXP ([200.67.231.235]) by seguridata1.seguridata.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 27 Nov 2003 12:35:32 -0600
From: "Miguel Rodriguez" <[e-mail]>
To: <[e-mail]>
Subject: RE: DISCUSS:  MUST  reject in OCSPv1
Date: Thu, 27 Nov 2003 12:34:27 -0600
Message-ID: <000901c3b515$16bf1cb0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
X-OriginalArrivalTime: 27 Nov 2003 18:35:33.0453 (UTC) FILETIME=[3DEF27D0:01C3B515]
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 think this is the best option. We definitely need a normative on how
nonces relate to pre-produced responses. Meanwhile the discussion must
go on.

Miguel A Rodriguez
SeguriDATA
Mexico

> -----Original Message-----
> From: [e-mail]
[mailto:[e-mail]]
> On Behalf Of Michael Myers
> Sent: Thursday, November 27, 2003 8:19 AM
> To: Florian Oelmaier; [e-mail]
> Subject: RE: DISCUSS: MUST reject in OCSPv1
> 
> 
> 
> Maybe the best thing to do is to reset 2560 back to Proposed,
> drop in a simple little extension like the below or something
> similar, put in some amply unambiguous normative language that
> makes it abundantly clear how nonces relate to pre-produced
> responses (in particular nonceless responses to nonced requests
> are strictly verboten) call it v1 still and let the RFC cycle at
> Proposed for an additional six months.  I could live with that.
> I don't know however if the IESG would let us do that.  Maybe if
> we could all agree on that course of action and ask nicely . . .
> ?
> 
> Mike
> 
> 
> 
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]]On Behalf Of
> > Florian Oelmaier
> > Sent: Wednesday, November 26, 2003 6:33 PM
> > To: 'Michael Myers'; [e-mail]
> > Subject: RE: DISCUSS: MUST reject in OCSPv1
> >
> >
> >
> > > I've chosen not to incorporate your well reasoned argument
> > > due to my business model.  :)
> >
> > hehehehe
> >
> > > How about in v1 we clarify by saying that "clients claiming
> > > conformance to this standard SHALL be capable of
> > rejecting . . . "
> >
> > What about something like:
> >
> > ------
> >
> > Clients including a nonce into the request MUST NOT
> > accept nonce-less
> > responses from responders that are known to be
> > capable of generating
> > nonces. If this is unknown for a certain responder,
> > clients MAY accept
> > the additional risk of accepting the nonce-less response.
> >
> > A responder MAY include the OCSPNonceSupported
> > extension into every
> > response to indicate the capability of producing
> > nonces to the client
> > (even in the case of a replay attack). The
> > OCSPNonceSupported extension
> > will be identified by the object identifier
> > id-pkix-ocsp-noncesupported,
> > while the extnValue is a boolean value indicating if
> > nonces are
> > supported by this responder (TRUE) or not (FALSE).
> >
> > id-pkix-ocsp-noncesupported     OBJECT IDENTIFIER ::=
> > { id-pkix-ocsp 8 }
> >
> > ------
> >





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hARHu1ib074022 for <[e-mail]>; Thu, 27 Nov 2003 09:56:01 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hARHu1Bm074021 for ietf-pkix-bks; Thu, 27 Nov 2003 09:56:01 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hARHu0ib074013 for <[e-mail]>; Thu, 27 Nov 2003 09:56:01 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (h005008001124.ne.client2.attbi.com[66.31.43.88]) by comcast.net (sccrmhc11) with ESMTP id <2003112717555301100np1gte>; Thu, 27 Nov 2003 17:55:57 +0000
Received: from localhost ([127.0.0.1] helo=corestreet.com ident=dave) by localhost with esmtp (Exim 3.35 #1 (Debian)) id 1APQOe-0005hG-00; Thu, 27 Nov 2003 12:57:44 -0500
Message-ID: <[e-mail]>
Date: Thu, 27 Nov 2003 12:57:43 -0500
From: David Engberg <[e-mail]>
Organization: CoreStreet
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Michael Myers <[e-mail]>
CC: [e-mail]
Subject: Re: DISCUSS:  MUST  reject in OCSPv1
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; 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>

Michael Myers wrote:
> There's a chance we maybe can if we reset 2560 back to Proposed,
> still call it v1 and let it cycle there for a while.  I've yet
> to hear back from Russ on that one so I've been reluctant to
> play that card.  I think what will be the determining factor on
> that potential course of action is if we can all agree on the
> technical content.  The number of implementors who would be
> affected is still quite manageable.

This sounds good to me.


> I suspect though there still will remain the core issue:
> whether or not it is conformant in principle and in the spirit
> of the RFC to send a nonceless response to a nonced request.  I
> would further refine that by saying any nonceless signed
> response containing either "good" or "revoked".  I could accept
> "unknown" due to reasons of nonces not being supported as
> indicated by a small extension to the protocol.

I read the nonce description in the RFC as the client asking for 
something that it WANTS as opposed to demanding something that it NEEDS. 
  I.e. a nonce is one element in a list of things like nextUpdate, 
thisUpdate, producedAt, etc. that a client may use to decide on response 
acceptance based on the local security policy.

The local policy needs to take all of these factors into account, and 
the absence/presence of a nonce is one factor which may help avoid a 
specific type of attack.  The default, recommended, behavior is that a 
nonceless response should be rejected unless the client has a darned 
good reason for accepting the response based on other factors (e.g. the 
response comes with a signed letter from the cert's issuer saying it is 
safe [safer, IMHO, but that's a separate discussion] to accept the 
nonceless response for its certs).

It sounds like your interpretation is that the presence of a nonce is 
something the client NEEDS and that nonce absence supercedes all other 
policy considerations.  I don't think this is a horrible interpretation, 
but it does imply some limitations, as discussed.




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hARHAlib071611 for <[e-mail]>; Thu, 27 Nov 2003 09:10:47 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hARHAlC5071610 for ietf-pkix-bks; Thu, 27 Nov 2003 09:10:47 -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.10/8.12.8) with ESMTP id hARHAkib071601 for <[e-mail]>; Thu, 27 Nov 2003 09:10:46 -0800 (PST) (envelope-from [e-mail])
Received: from mail6.microsoft.com ([157.54.6.196]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 27 Nov 2003 09:10:54 -0800
Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 27 Nov 2003 09:10:32 -0800
Received: from 157.54.8.109 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 27 Nov 2003 09:10:41 -0800
Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 27 Nov 2003 09:10:17 -0800
Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 27 Nov 2003 09:10:48 -0800
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 27 Nov 2003 09:11:15 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.7122.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary"
Subject: RE: DISCUSS:  MUST  reject in OCSPv1
Date: Thu, 27 Nov 2003 09:09:25 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: DISCUSS:  MUST  reject in OCSPv1
Thread-Index: AcO1CO6ClQMNrH29TMKIE4aBUYzsrQAAEdMW
From: "Ryan M. Hurst" <[e-mail]>
To: "Michael Myers" <[e-mail]>, "Santosh Chokhani" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 27 Nov 2003 17:11:15.0521 (UTC) FILETIME=[772BFB10:01C3B509]
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.

--------------InterScan_NT_MIME_Boundary
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3B509.62D98421"

------_=_NextPart_001_01C3B509.62D98421
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

My opinion is still that the client should get the un-nonced response =
and then the client should throw it out.
=20
If there is a preceived need for returning a response without a nonce =
return internalError.
=20
Ryan

________________________________

From: Michael Myers [mailto:[e-mail]]
Sent: Thu 11/27/2003 9:09 AM
To: Ryan M. Hurst; Santosh Chokhani; [e-mail]
Subject: RE: DISCUSS: MUST reject in OCSPv1


The more important thing is what a caching server is required to send =
back in the event it can't respond to a nonce.
=20
Mike

	-----Original Message-----
	From: Ryan M. Hurst [mailto:[e-mail]]
	Sent: Thursday, November 27, 2003 9:48 AM
	To: Michael Myers; Santosh Chokhani; [e-mail]
	Subject: RE: DISCUSS: MUST reject in OCSPv1
=09
=09
	I don't think its silly, the client is still protected from the replay =
if the server responds to a nonced request with a un-nonced one as the =
client can decide decide if he wanted the protection or needed it.
	=20
	That may sound strange, but nonce has other implications that re-play =
protection; it also implies freshness since pre-produced responses can =
not have the right nonce in it.
	=20
	I still am not sure anything new is needed, but if it is leveraging =
criticality is probably the right way to go as long as it will not break =
folks; if it would I would fall back to the extension approach.
	=20
	Ryan
=09
	=20


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

<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">=0A=
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">=0A=
<HTML><HEAD><TITLE>RE: DISCUSS: MUST reject in OCSPv1</TITLE>=0A=
=0A=
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR></HEAD>=0A=
<BODY>=0A=
<DIV id=3DidOWAReplyText15729 dir=3Dltr>=0A=
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2>My opinion is =
still that the =0A=
client should get the un-nonced response and then the client should =
throw it =0A=
out.</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>If there is a preceived need =
for returning =0A=
a response without a nonce return internalError.</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Ryan</FONT></DIV></DIV>=0A=
<DIV dir=3Dltr><BR>=0A=
<HR tabIndex=3D-1>=0A=
<FONT face=3DTahoma size=3D2><B>From:</B> Michael Myers =0A=
[mailto:[e-mail]]<BR><B>Sent:</B> Thu 11/27/2003 9:09 =
AM<BR><B>To:</B> =0A=
Ryan M. Hurst; Santosh Chokhani; [e-mail]<BR><B>Subject:</B> =
RE: =0A=
DISCUSS: MUST reject in OCSPv1<BR></FONT><BR></DIV>=0A=
<DIV>=0A=
<DIV><SPAN class=3D139555816-27112003><FONT face=3DArial color=3D#0000ff =
size=3D2>The =0A=
more important thing is what a caching server is required to send back =
in the =0A=
event it can't respond to a nonce.</FONT></SPAN></DIV>=0A=
<DIV><SPAN class=3D139555816-27112003><FONT face=3DArial color=3D#0000ff =0A=
size=3D2></FONT></SPAN>&nbsp;</DIV>=0A=
<DIV><SPAN class=3D139555816-27112003><FONT face=3DArial color=3D#0000ff =0A=
size=3D2>Mike</FONT></SPAN></DIV>=0A=
<BLOCKQUOTE dir=3Dltr =0A=
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">=0A=
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma =0A=
  size=3D2>-----Original Message-----<BR><B>From:</B> Ryan M. Hurst =0A=
  [mailto:[e-mail]]<BR><B>Sent:</B> Thursday, November =
27, 2003 =0A=
  9:48 AM<BR><B>To:</B> Michael Myers; Santosh Chokhani; =0A=
  [e-mail]<BR><B>Subject:</B> RE: DISCUSS: MUST reject in =0A=
  OCSPv1<BR><BR></FONT></DIV>=0A=
  <DIV id=3DidOWAReplyText19203 dir=3Dltr>=0A=
  <DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2>I don't =
think its silly, =0A=
  the client is still protected from the replay if the server responds =
to a =0A=
  nonced request with a un-nonced one as the client can decide decide if =
he =0A=
  wanted the protection or needed it.</FONT></DIV>=0A=
  <DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
  <DIV dir=3Dltr><FONT face=3DArial size=3D2>That may sound strange, but =
nonce has =0A=
  other implications that re-play protection; it also implies freshness =
since =0A=
  pre-produced responses can not have the right nonce in it.</FONT></DIV>=0A=
  <DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
  <DIV dir=3Dltr><FONT face=3DArial size=3D2>I still am not sure =
anything new is =0A=
  needed, but if it is leveraging criticality is probably the right way =
to go as =0A=
  long as it will not break folks; if it would I would fall back to the =0A=
  extension approach.</FONT></DIV>=0A=
  <DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
  <DIV dir=3Dltr><FONT face=3DArial size=3D2>Ryan</FONT></DIV></DIV>=0A=
  <DIV dir=3Dltr><FONT face=3DArial color=3D#0000ff =0A=
size=3D2></FONT><BR>&nbsp;</DIV></BLOCKQUOTE></DIV></BODY></HTML>=0A=

------_=_NextPart_001_01C3B509.62D98421--

--------------InterScan_NT_MIME_Boundary--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hARH7Pib071507 for <[e-mail]>; Thu, 27 Nov 2003 09:07:25 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hARH7PCQ071506 for ietf-pkix-bks; Thu, 27 Nov 2003 09:07:25 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hARH7Nib071501 for <[e-mail]>; Thu, 27 Nov 2003 09:07:24 -0800 (PST) (envelope-from [e-mail])
Received: from MMyersLapTop ([65.39.77.99]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id hARH7NA39055; Thu, 27 Nov 2003 10:07:23 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: "Ryan M. Hurst" <[e-mail]>, "Santosh Chokhani" <[e-mail]>, <[e-mail]>
Subject: RE: DISCUSS:  MUST  reject in OCSPv1
Date: Thu, 27 Nov 2003 10:09:35 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0012_01C3B4CE.8F0C0C60"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <[e-mail]>
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>

This is a multi-part message in MIME format.

------=_NextPart_000_0012_01C3B4CE.8F0C0C60
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

RE: DISCUSS: MUST reject in OCSPv1The more important thing is what a caching
server is required to send back in the event it can't respond to a nonce.

Mike
  -----Original Message-----
  From: Ryan M. Hurst [mailto:[e-mail]]
  Sent: Thursday, November 27, 2003 9:48 AM
  To: Michael Myers; Santosh Chokhani; [e-mail]
  Subject: RE: DISCUSS: MUST reject in OCSPv1


  I don't think its silly, the client is still protected from the replay if
the server responds to a nonced request with a un-nonced one as the client
can decide decide if he wanted the protection or needed it.

  That may sound strange, but nonce has other implications that re-play
protection; it also implies freshness since pre-produced responses can not
have the right nonce in it.

  I still am not sure anything new is needed, but if it is leveraging
criticality is probably the right way to go as long as it will not break
folks; if it would I would fall back to the extension approach.

  Ryan


------=_NextPart_000_0012_01C3B4CE.8F0C0C60
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>RE: DISCUSS: MUST reject in OCSPv1</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D139555816-27112003><FONT face=3DArial color=3D#0000ff =
size=3D2>The=20
more important thing is what a caching server is required to send back =
in the=20
event it can't respond to a nonce.</FONT></SPAN></DIV>
<DIV><SPAN class=3D139555816-27112003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D139555816-27112003><FONT face=3DArial color=3D#0000ff =

size=3D2>Mike</FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> Ryan M. Hurst=20
  [mailto:[e-mail]]<BR><B>Sent:</B> Thursday, November =
27, 2003=20
  9:48 AM<BR><B>To:</B> Michael Myers; Santosh Chokhani;=20
  [e-mail]<BR><B>Subject:</B> RE: DISCUSS: MUST reject in=20
  OCSPv1<BR><BR></FONT></DIV>
  <DIV id=3DidOWAReplyText19203 dir=3Dltr>
  <DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2>I don't =
think its silly,=20
  the client is still protected from the replay if the server responds =
to a=20
  nonced request with a un-nonced one as the client can decide decide if =
he=20
  wanted the protection or needed it.</FONT></DIV>
  <DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV dir=3Dltr><FONT face=3DArial size=3D2>That may sound strange, but =
nonce has=20
  other implications that re-play protection; it also implies freshness =
since=20
  pre-produced responses can not have the right nonce in =
it.</FONT></DIV>
  <DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV dir=3Dltr><FONT face=3DArial size=3D2>I still am not sure =
anything new is=20
  needed, but if it is leveraging criticality is probably the right way =
to go as=20
  long as it will not break folks; if it would I would fall back to the=20
  extension approach.</FONT></DIV>
  <DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV dir=3Dltr><FONT face=3DArial size=3D2>Ryan</FONT></DIV></DIV>
  <DIV dir=3Dltr><FONT face=3DArial color=3D#0000ff=20
size=3D2></FONT><BR>&nbsp;</DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0012_01C3B4CE.8F0C0C60--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hARGpDib070760 for <[e-mail]>; Thu, 27 Nov 2003 08:51:13 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hARGpDhD070759 for ietf-pkix-bks; Thu, 27 Nov 2003 08:51:13 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hARGpBib070750 for <[e-mail]>; Thu, 27 Nov 2003 08:51:11 -0800 (PST) (envelope-from [e-mail])
Received: from mail6.microsoft.com ([157.54.6.196]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 27 Nov 2003 08:51:10 -0800
Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 27 Nov 2003 08:51:00 -0800
Received: from 157.54.8.109 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 27 Nov 2003 08:51:07 -0800
Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 27 Nov 2003 08:50:44 -0800
Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 27 Nov 2003 08:51:26 -0800
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 27 Nov 2003 08:50:57 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.7122.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary"
Subject: RE: DISCUSS:  MUST  reject in OCSPv1
Date: Thu, 27 Nov 2003 08:48:02 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: DISCUSS:  MUST  reject in OCSPv1
Thread-Index: AcO0/aw2qzBkGWAhShOE73FW9Nr2zQACIzyF
From: "Ryan M. Hurst" <[e-mail]>
To: "Michael Myers" <[e-mail]>, "Santosh Chokhani" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 27 Nov 2003 16:50:57.0302 (UTC) FILETIME=[A10E8360:01C3B506]
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.

--------------InterScan_NT_MIME_Boundary
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3B506.A8C16179"

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

I don't think its silly, the client is still protected from the replay =
if the server responds to a nonced request with a un-nonced one as the =
client can decide decide if he wanted the protection or needed it.
=20
That may sound strange, but nonce has other implications that re-play =
protection; it also implies freshness since pre-produced responses can =
not have the right nonce in it.
=20
I still am not sure anything new is needed, but if it is leveraging =
criticality is probably the right way to go as long as it will not break =
folks; if it would I would fall back to the extension approach.
=20
Ryan

________________________________

From: [e-mail] on behalf of Michael Myers
Sent: Thu 11/27/2003 5:49 AM
To: Santosh Chokhani; [e-mail]
Subject: RE: DISCUSS: MUST reject in OCSPv1






> -----Original Message-----
> From: Santosh Chokhani
> Sent: Wednesday, November 26, 2003 9:25 PM
> To: [e-mail]
> Subject: RE: DISCUSS: MUST reject in OCSPv1
>
>
>
> Mike:
>
> Section 4.1.2 and 4.4 of the RFC 2560 support the
> position that the nonce can
> be ignored.  I can not find any statement in the RFC
> that is close to these
> two to support what you are saying.

Yes, extensions are optional.  What's missing is language along
the lines that while optional, if used must be used in the
manner indicated in the extension's definition.

Prior to the first poll, I was reviewing some list traffic on
the subject, I think it was between Florian and Ambarish.  I was
about to advise that 2560 asserts nonces must be respected but
was dismayed to learn that we hadn't done so.

Why the hard line?  Because it just seems rather silly to enable
a client to include a nonce for the purposes of anti-replay but
then leave open a loophole that allows that nonce to be ignored,
this, against all good sense of how a secure protocol should
work.  With a loophole like that, it isn't secure.  I guess we
all figured, well *of course* the nonce would be incorporated.

Mike




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

<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">=0A=
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">=0A=
<HTML>=0A=
<HEAD>=0A=
=0A=
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7122.0">=0A=
<TITLE>RE: DISCUSS:  MUST  reject in OCSPv1</TITLE>=0A=
</HEAD>=0A=
<BODY>=0A=
<DIV id=3DidOWAReplyText19203 dir=3Dltr>=0A=
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2>I don't think =
its silly, the =0A=
client is still protected from the replay if the server responds to a =
nonced =0A=
request with a un-nonced one as the client can decide decide if he =
wanted the =0A=
protection or needed it.</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>That may sound strange, but =
nonce has other =0A=
implications that re-play protection; it also implies freshness since =0A=
pre-produced responses can not have the right nonce in it.</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>I still am not sure anything =
new is needed, =0A=
but if it is leveraging criticality is probably the right way to go as =
long as =0A=
it will not break folks; if it would I would fall back to the extension =0A=
approach.</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Ryan</FONT></DIV></DIV>=0A=
<DIV dir=3Dltr><BR>=0A=
<HR tabIndex=3D-1>=0A=
<FONT face=3DTahoma size=3D2><B>From:</B> [e-mail] =
on behalf of =0A=
Michael Myers<BR><B>Sent:</B> Thu 11/27/2003 5:49 AM<BR><B>To:</B> =
Santosh =0A=
Chokhani; [e-mail]<BR><B>Subject:</B> RE: DISCUSS: MUST reject =
in =0A=
OCSPv1<BR></FONT><BR></DIV>=0A=
<DIV><BR><BR><BR>=0A=
<P><FONT size=3D2>&gt; -----Original Message-----<BR>&gt; From: Santosh =0A=
Chokhani<BR>&gt; Sent: Wednesday, November 26, 2003 9:25 PM<BR>&gt; To: =0A=
[e-mail]<BR>&gt; Subject: RE: DISCUSS: MUST reject in =0A=
OCSPv1<BR>&gt;<BR>&gt;<BR>&gt;<BR>&gt; Mike:<BR>&gt;<BR>&gt; Section =
4.1.2 and =0A=
4.4 of the RFC 2560 support the<BR>&gt; position that the nonce =
can<BR>&gt; be =0A=
ignored.&nbsp; I can not find any statement in the RFC<BR>&gt; that is =
close to =0A=
these<BR>&gt; two to support what you are saying.<BR><BR>Yes, extensions =
are =0A=
optional.&nbsp; What's missing is language along<BR>the lines that while =0A=
optional, if used must be used in the<BR>manner indicated in the =
extension's =0A=
definition.<BR><BR>Prior to the first poll, I was reviewing some list =
traffic =0A=
on<BR>the subject, I think it was between Florian and Ambarish.&nbsp; I =0A=
was<BR>about to advise that 2560 asserts nonces must be respected =
but<BR>was =0A=
dismayed to learn that we hadn't done so.<BR><BR>Why the hard =
line?&nbsp; =0A=
Because it just seems rather silly to enable<BR>a client to include a =
nonce for =0A=
the purposes of anti-replay but<BR>then leave open a loophole that =
allows that =0A=
nonce to be ignored,<BR>this, against all good sense of how a secure =
protocol =0A=
should<BR>work.&nbsp; With a loophole like that, it isn't secure.&nbsp; =
I guess =0A=
we<BR>all figured, well *of course* the nonce would be =0A=
incorporated.<BR><BR>Mike<BR><BR></FONT></P></DIV>=0A=
=0A=
</BODY>=0A=
</HTML>
------_=_NextPart_001_01C3B506.A8C16179--

--------------InterScan_NT_MIME_Boundary--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hARGH3ib069085 for <[e-mail]>; Thu, 27 Nov 2003 08:17:03 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hARGH3PX069083 for ietf-pkix-bks; Thu, 27 Nov 2003 08:17:03 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from main.giknpc.com.ua (backup.adm.dp.ua [212.86.233.14]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hARGGvib069073 for <[e-mail]>; Thu, 27 Nov 2003 08:17:00 -0800 (PST) (envelope-from [e-mail])
Received: (from vf@localhost) by main.giknpc.com.ua (8.11.6/8.11.6) id hARGGpo31435; Thu, 27 Nov 2003 18:16:51 +0200
Date: Thu, 27 Nov 2003 18:16:51 +0200
From: Vadim Fedukovich <[e-mail]>
To: [e-mail]
Cc: David Engberg <[e-mail]>
Subject: Re: DISCUSS:  MUST  reject in OCSPv1
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.1i
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>

On Wed, Nov 26, 2003 at 05:19:48PM -0500, David Engberg wrote:
> ...
> Rationale:
> 
> Imagine an OCSP client who receives signed email with a cert from Acme 
> Certs.  He chains it up (e.g through bridging) to some trusted root, and 
> then finds Acme's responder URL through the cert's AIA field.  The 
> client trusts the cert, but needs to validate its revocation status 
> through OCSP.  With the "MUST" language, the client is limited to two 
> automatically-enforced local security policies:
> 
>   1) Don't send a nonce, whether or not Acme's server supports nonces.
> 
>   2) Send a nonce whether or not Acme's server supports nonces, and
>      fail to perform any validation if it does not.

Maybe announce OCSP responder capability to handle nonces
right in the AIA extension (at the same place the URL is given)?

> 


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hARFbbib066910 for <[e-mail]>; Thu, 27 Nov 2003 07:37:37 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hARFbbM4066908 for ietf-pkix-bks; Thu, 27 Nov 2003 07:37:37 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hARFbZib066884 for <[e-mail]>; Thu, 27 Nov 2003 07:37:35 -0800 (PST) (envelope-from [e-mail])
Received: from MMyersLapTop ([65.39.77.99]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id hARFbYA34747; Thu, 27 Nov 2003 08:37:35 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: "David Engberg" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: DISCUSS:  MUST  reject in OCSPv1
Date: Thu, 27 Nov 2003 08:39:47 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <[e-mail]>
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>

> -----Original Message-----
> From:  David Engberg
> Sent: Wednesday, November 26, 2003 9:40 PM
>
> I accept your determination that we cannot specify a
> single new specific secure signalling mechanism
> (e.g. 'nonceUnsupported' extension) inside
> of the formal OCSP v1.
>

There's a chance we maybe can if we reset 2560 back to Proposed,
still call it v1 and let it cycle there for a while.  I've yet
to hear back from Russ on that one so I've been reluctant to
play that card.  I think what will be the determining factor on
that potential course of action is if we can all agree on the
technical content.  The number of implementors who would be
affected is still quite manageable.

I suspect though there still will remain the core issue:
whether or not it is conformant in principle and in the spirit
of the RFC to send a nonceless response to a nonced request.  I
would further refine that by saying any nonceless signed
response containing either "good" or "revoked".  I could accept
"unknown" due to reasons of nonces not being supported as
indicated by a small extension to the protocol.

What do you think?

Mike




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hARF9Tib064846 for <[e-mail]>; Thu, 27 Nov 2003 07:09:29 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hARF9T0a064845 for ietf-pkix-bks; Thu, 27 Nov 2003 07:09:29 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hARF9Sib064840 for <[e-mail]>; Thu, 27 Nov 2003 07:09:28 -0800 (PST) (envelope-from [e-mail])
Received: from orionsec.com (localhost [127.0.0.1]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id hARF9TB3004076 for <[e-mail]>; Thu, 27 Nov 2003 10:09:29 -0500
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: DISCUSS:  MUST  reject in OCSPv1
Date: Thu, 27 Nov 2003 11:09:29 -0400
Message-Id: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
X-Mailer: Open WebMail 1.81 20021127
X-OriginatingIP: 68.147.139.109 (chokhani)
MIME-Version: 1.0
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>

MIke:

I suggesetd several client side checks to Ambrish (including this one) in 
February 2002.  I was not thinking of pre-production.

As to security problem, as my e-mail denoted,the client is free to reject the 
response, use the three times as guide, or mmight know a priory that the 
Responder does pre-production and hence no nonces.

On Thu, 27 Nov 2003 06:49:06 -0700, Michael Myers wrote
> > -----Original Message-----
> > From: Santosh Chokhani
> > Sent: Wednesday, November 26, 2003 9:25 PM
> > To: [e-mail]
> > Subject: RE: DISCUSS: MUST reject in OCSPv1
> >
> >
> >
> > Mike:
> >
> > Section 4.1.2 and 4.4 of the RFC 2560 support the
> > position that the nonce can
> > be ignored.  I can not find any statement in the RFC
> > that is close to these
> > two to support what you are saying.
> 
> Yes, extensions are optional.  What's missing is language along
> the lines that while optional, if used must be used in the
> manner indicated in the extension's definition.
> 
> Prior to the first poll, I was reviewing some list traffic on
> the subject, I think it was between Florian and Ambarish.  I was
> about to advise that 2560 asserts nonces must be respected but
> was dismayed to learn that we hadn't done so.
> 
> Why the hard line?  Because it just seems rather silly to enable
> a client to include a nonce for the purposes of anti-replay but
> then leave open a loophole that allows that nonce to be ignored,
> this, against all good sense of how a secure protocol should
> work.  With a loophole like that, it isn't secure.  I guess we
> all figured, well *of course* the nonce would be incorporated.
> 
> Mike






Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAREloib063589 for <[e-mail]>; Thu, 27 Nov 2003 06:47:50 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hARElo8N063588 for ietf-pkix-bks; Thu, 27 Nov 2003 06:47:50 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kiki.ssb.it ([192.106.128.1]) by above.proper.com (8.12.10/8.12.8) with SMTP id hARElmib063573 for <[e-mail]>; Thu, 27 Nov 2003 06:47:48 -0800 (PST) (envelope-from [e-mail])
Received: from mail.tsp.it ([192.168.100.243]) by kiki; Thu, 27 Nov 2003 15:47:53 +0100 (CET)
Received: from mail.tsp.it (unknown [192.168.100.244]) by dns.tsp.it (Postfix) with ESMTP id A42E02D55A for <[e-mail]>; Thu, 27 Nov 2003 16:44:33 +0100 (CET)
Subject: remove
To: [e-mail]
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <[e-mail]>
From: "Marco Nicoli" <[e-mail]>
Date: Thu, 27 Nov 2003 15:47:41 +0100
X-MIMETrack: Serialize by Router on Notes/TSP(Release 5.07a |May 14, 2001) at 27/11/2003  15.47.41
MIME-Version: 1.0
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>


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAREV9ib062847 for <[e-mail]>; Thu, 27 Nov 2003 06:31:09 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAREV8N4062846 for ietf-pkix-bks; Thu, 27 Nov 2003 06:31:08 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAREV7ib062841 for <[e-mail]>; Thu, 27 Nov 2003 06:31:07 -0800 (PST) (envelope-from [e-mail])
Received: from MMyersLapTop ([65.39.77.99]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id hAREV5A31721; Thu, 27 Nov 2003 07:31:05 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: "Michael Myers" <[e-mail]>, "Florian Oelmaier" <[e-mail]>, <[e-mail]>
Subject: RE: DISCUSS:  MUST  reject in OCSPv1
Date: Thu, 27 Nov 2003 07:33:17 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <[e-mail]>
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>

I should qualify that:  nonceless "definitive" responses.  I.e.
those a containing a signed indication of either "good" or
"revoked".

Mike

> -----Original Message-----
> From: Michael Myers [mailto:[e-mail]]
> Sent: Thursday, November 27, 2003 7:19 AM
> To: Florian Oelmaier; [e-mail]
> Subject: RE: DISCUSS: MUST reject in OCSPv1
>
>
>
> Maybe the best thing to do is to reset 2560 back to
> Proposed, drop in a simple little extension like the
> below or something similar, put in some amply
> unambiguous normative language that makes it
> abundantly clear how nonces relate to pre-produced
> responses (in particular nonceless responses to
> nonced requests are strictly verboten) call it v1
> still and let the RFC cycle at Proposed for an
> additional six months.  I could live with that.  I
> don't know however if the IESG would let us do that.
> Maybe if we could all agree on that course of action
> and ask nicely . . . ?
>
> Mike



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAREGaib061458 for <[e-mail]>; Thu, 27 Nov 2003 06:16:36 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAREGa8N061457 for ietf-pkix-bks; Thu, 27 Nov 2003 06:16:36 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAREGYib061450 for <[e-mail]>; Thu, 27 Nov 2003 06:16:34 -0800 (PST) (envelope-from [e-mail])
Received: from MMyersLapTop ([65.39.77.99]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id hAREGWA31212; Thu, 27 Nov 2003 07:16:32 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: "Florian Oelmaier" <[e-mail]>, <[e-mail]>
Subject: RE: DISCUSS:  MUST  reject in OCSPv1
Date: Thu, 27 Nov 2003 07:18:45 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <000001c3b486$74cb1730$4228a8c0@hagen>
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>

Maybe the best thing to do is to reset 2560 back to Proposed,
drop in a simple little extension like the below or something
similar, put in some amply unambiguous normative language that
makes it abundantly clear how nonces relate to pre-produced
responses (in particular nonceless responses to nonced requests
are strictly verboten) call it v1 still and let the RFC cycle at
Proposed for an additional six months.  I could live with that.
I don't know however if the IESG would let us do that.  Maybe if
we could all agree on that course of action and ask nicely . . .
?

Mike



> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of
> Florian Oelmaier
> Sent: Wednesday, November 26, 2003 6:33 PM
> To: 'Michael Myers'; [e-mail]
> Subject: RE: DISCUSS: MUST reject in OCSPv1
>
>
>
> > I've chosen not to incorporate your well reasoned argument
> > due to my business model.  :)
>
> hehehehe
>
> > How about in v1 we clarify by saying that "clients claiming
> > conformance to this standard SHALL be capable of
> rejecting . . . "
>
> What about something like:
>
> ------
>
> Clients including a nonce into the request MUST NOT
> accept nonce-less
> responses from responders that are known to be
> capable of generating
> nonces. If this is unknown for a certain responder,
> clients MAY accept
> the additional risk of accepting the nonce-less response.
>
> A responder MAY include the OCSPNonceSupported
> extension into every
> response to indicate the capability of producing
> nonces to the client
> (even in the case of a replay attack). The
> OCSPNonceSupported extension
> will be identified by the object identifier
> id-pkix-ocsp-noncesupported,
> while the extnValue is a boolean value indicating if
> nonces are
> supported by this responder (TRUE) or not (FALSE).
>
> id-pkix-ocsp-noncesupported     OBJECT IDENTIFIER ::=
> { id-pkix-ocsp 8 }
>
> ------
>



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hARE75ib060653 for <[e-mail]>; Thu, 27 Nov 2003 06:07:05 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hARE75Ax060652 for ietf-pkix-bks; Thu, 27 Nov 2003 06:07:05 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp4.hy.skanova.net (smtp4.hy.skanova.net [195.67.199.133]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hARE74ib060647 for <[e-mail]>; Thu, 27 Nov 2003 06:07:05 -0800 (PST) (envelope-from [e-mail])
Received: from arport (t12o913p47.telia.com [213.64.28.167]) by smtp4.hy.skanova.net (8.12.10/8.12.10) with SMTP id hARE6kBZ005296; Thu, 27 Nov 2003 15:06:47 +0100 (CET)
Message-ID: <001301c3b4ef$29ffa8b0$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Peter Gutmann" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: Straw poll: An advice to a commercial CA
Date: Thu, 27 Nov 2003 15:02:56 +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>

>If cryptlib finds constraints in a CA cert it'll apply them down the chain, but
>there's no way for a user to configure the behaviour.  The reason for this is
>that no-one has ever asked for this [0], so I can't even begin to imagine what
>sort of interface it'd require to manage things.  Do users type in a list of
>OIDs from a piece of paper?  Do they click on a CA cert and say "Use the
>policies advertised by this CA"? 

Oh Peter, now you become far too practical for _this_ list!

But it is indeed a real challenge to write a GUI to be used by
ordinary IS administrators, for a mechanism that you need a Phd
or better to grasp!

I guess you can wait with the GUI as long as Microsoft will
wait with a GUI in their products.  That is, forever.

Eureka, I got it!  Since this is black magic anyway, Microsoft
could make this configurable with Regedit!  That's how MSFT
usually treat stuff that you really shouldn't muck around with
at all or only on your own risk.  Finally RFC3280 has found
its true sole-mate.  It was a long journey...

Anders


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hARDkuib058833 for <[e-mail]>; Thu, 27 Nov 2003 05:46:56 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hARDktl0058832 for ietf-pkix-bks; Thu, 27 Nov 2003 05:46:55 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hARDksib058827 for <[e-mail]>; Thu, 27 Nov 2003 05:46:54 -0800 (PST) (envelope-from [e-mail])
Received: from MMyersLapTop ([65.39.77.99]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id hARDkrA30118; Thu, 27 Nov 2003 06:46:54 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: "Santosh Chokhani" <[e-mail]>, <[e-mail]>
Subject: RE: DISCUSS:  MUST  reject in OCSPv1
Date: Thu, 27 Nov 2003 06:49:06 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1106
In-Reply-To: <[e-mail]>
Importance: Normal
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: Santosh Chokhani
> Sent: Wednesday, November 26, 2003 9:25 PM
> To: [e-mail]
> Subject: RE: DISCUSS: MUST reject in OCSPv1
>
>
>
> Mike:
>
> Section 4.1.2 and 4.4 of the RFC 2560 support the
> position that the nonce can
> be ignored.  I can not find any statement in the RFC
> that is close to these
> two to support what you are saying.

Yes, extensions are optional.  What's missing is language along
the lines that while optional, if used must be used in the
manner indicated in the extension's definition.

Prior to the first poll, I was reviewing some list traffic on
the subject, I think it was between Florian and Ambarish.  I was
about to advise that 2560 asserts nonces must be respected but
was dismayed to learn that we hadn't done so.

Why the hard line?  Because it just seems rather silly to enable
a client to include a nonce for the purposes of anti-replay but
then leave open a loophole that allows that nonce to be ignored,
this, against all good sense of how a secure protocol should
work.  With a loophole like that, it isn't secure.  I guess we
all figured, well *of course* the nonce would be incorporated.

Mike



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hARC5Cib054076 for <[e-mail]>; Thu, 27 Nov 2003 04:05:12 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hARC5C4v054075 for ietf-pkix-bks; Thu, 27 Nov 2003 04:05:12 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp4.hy.skanova.net (smtp4.hy.skanova.net [195.67.199.133]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hARC59ib054068 for <[e-mail]>; Thu, 27 Nov 2003 04:05:11 -0800 (PST) (envelope-from [e-mail])
Received: from arport (t7o913p29.telia.com [213.64.26.29]) by smtp4.hy.skanova.net (8.12.10/8.12.10) with SMTP id hARC52BZ010956; Thu, 27 Nov 2003 13:05:08 +0100 (CET)
Message-ID: <00e201c3b4de$2ab65e40$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Joseph Doekbrijder" <[e-mail]>
Cc: <[e-mail]>
References: <01fc01c3b366$8707d760$[e-mail]> <002601c3b3fc$1d25e8a0$0500a8c0@arport> <p06010203bbea6ed9a3e9@[128.89.89.75]> <006601c3b44f$66f98330$0500a8c0@arport> <[e-mail]>
Subject: Re: Straw poll: An advice to a commercial CA
Date: Thu, 27 Nov 2003 13:01:12 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
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>

Doesn't your scheme make an RP trusting the "expensive" CA
also trust the "cheap" CA as they share a common root?

And there could also be just two different "expensive" issuances
that are incompatible like server-side SSL certs and certs for
individuals.

It looks to me that you move potential problems to the RP SW.
Mathematically OK? For sure.  Standards-compliant?  For sure.
But working?  Under strictly monitored conditions only.  Such
conditions are unlikely to be met when you start to count RPs
in the thousands and up.

Anyway. several other folks on the list seem to agree that
such schemes (including policy OID-enhanced path validation)
only work in "managed" or "community" based PKIs.

In my opinion the need for standards is much more evident
in "unmanaged" spaces.

Anders

----- Original Message -----
From: "Joseph Doekbrijder" <[e-mail]>
To: "Anders Rundgren" <[e-mail]>
Cc: "Stephen Kent" <[e-mail]>; <[e-mail]>
Sent: Thursday, November 27, 2003 10:43
Subject: Re: Straw poll: An advice to a commercial CA


Only logical thing to do is a single root, signing the cheap CA which in
its turn signs the expensive CA.
Mathematically correct, includes trust logic, liability levels etc, etc...

This is how we do it. :-)

Cheers

Josh


Anders Rundgren wrote:

>Well,
>Since the list is close to "vibrant" with emotions, why not
>put RFC3280 through the litmus test?
>
>Assume that you as PKI professionals would advice a commercial
>TTP CA on how to configure their issuance for the following:
>1. Free e-mail roundtrip-verification certficates.  Low insurance level
>2. Expensive (high insurance level) multi-usage certificates for individuals
>using strong verification procedures.
>
>Note: the service is to be launched ASAP and has the only
>objective, making money by serving its subscribers well.
>
>Indicate your advice by the word in uppercase.
>
>SINGLE: A single root + possibly some CP OIDs to spice things up
>MULTIPLE: Different roots
>
>Lets rock!
>
>
>
--
Joseph A. Doekbrijder
--------------------------------------------------
SwissSign AG
Löwenstrasse 1, CH-8001 Zürich
Tel: [phone] Mobil: [phone]
www.swisssign.com
--------------------------------------------------




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hARBUtib052291 for <[e-mail]>; Thu, 27 Nov 2003 03:30:55 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hARBUtIQ052290 for ietf-pkix-bks; Thu, 27 Nov 2003 03:30:55 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.cs.auckland.ac.nz (csmail.cs.auckland.ac.nz [130.216.33.150]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hARBUrib052285 for <[e-mail]>; Thu, 27 Nov 2003 03:30:54 -0800 (PST) (envelope-from [e-mail])
Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id E060363C32; Fri, 28 Nov 2003 00:30:53 +1300 (NZDT)
Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id hARBXZq07599; Fri, 28 Nov 2003 00:33:35 +1300
Date: Fri, 28 Nov 2003 00:33:35 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Certificate Policy Standardization
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>

Stephen Kent <[e-mail]> writes:

>Policies could be created on an industry sector basis, for example. The IETF
>could publish the resulting policies and assign OIDs, but PKIX is not a
>suitable forum for the development of such policies.

So what you're saying is that this is an ecumenical matter?

Peter.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hARBOpib052098 for <[e-mail]>; Thu, 27 Nov 2003 03:24:51 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hARBOpId052097 for ietf-pkix-bks; Thu, 27 Nov 2003 03:24:51 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.cs.auckland.ac.nz (csmail.cs.auckland.ac.nz [130.216.33.150]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hARBOjib052091 for <[e-mail]>; Thu, 27 Nov 2003 03:24:50 -0800 (PST) (envelope-from [e-mail])
Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id 51A0D63C38; Fri, 28 Nov 2003 00:24:45 +1300 (NZDT)
Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id hARBRPI07518; Fri, 28 Nov 2003 00:27:25 +1300
Date: Fri, 28 Nov 2003 00:27:25 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Re: Straw poll: An advice to a commercial CA
Cc: [e-mail], [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>

Anders Rundgren <[e-mail]> writes:

>Assume that you as PKI professionals would advice a commercial
>TTP CA on how to configure their issuance for the following:
>1. Free e-mail roundtrip-verification certficates.  Low insurance level
>2. Expensive (high insurance level) multi-usage certificates for individuals
>using strong verification procedures.
>
>Note: the service is to be launched ASAP and has the only
>objective, making money by serving its subscribers well.
>
>Indicate your advice by the word in uppercase.
>
>SINGLE: A single root + possibly some CP OIDs to spice things up
>MULTIPLE: Different roots

I'm going to have to qualify my answer by saying that it'd differ whether I
was acting for the CA or the RP, and whether it's an open or closed
environment.  If it's a closed environment I'd let them do whatever they feel
like and whatever the software supports (that is, find out what their software
will let them do, get them to test it to make sure it really does what the
vendor claims it does, go a few rounds with the vendor to make it actually do
what they claim, and then let them go with what they're comfortable with).
Since they don't have the option of changing the software, they'll have to do
what they can with what they've got.

If it's an open environment then given the almost complete lack of support for
policy restrictions and management (as Anders has pointed out), I'd tell them
to go for multiple CAs and handle it via the trusted-roots mechanism, which
pretty much everything supports.  Oh, and I'd probably have to sit through
interminable discussions with lawyers about how to word the CPS so that they
can do whatever they want to the RP without assuming any liability.

To answer an earlier question about support for policy restrictions, cryptlib
supports these (policy constraints with all its weird variations).  If
cryptlib finds constraints in a CA cert it'll apply them down the chain, but
there's no way for a user to configure the behaviour.  The reason for this is
that no-one has ever asked for this [0], so I can't even begin to imagine what
sort of interface it'd require to manage things.  Do users type in a list of
OIDs from a piece of paper?  Do they click on a CA cert and say "Use the
policies advertised by this CA"?  Can you apply different policies to
different sets of certs?  Do you require the user to have read the policy (via
the URL) via a click-through mechanism before they enable its use?  What if
someone runs a MITM on them when they do this?  (It's most amusing that the
logotype draft has hashes to stop someone changing the inconsequential logo
that they see next to the cert, but there's nothing to prevent someone being
sent a completely bogus legal agreement when they ask for the policy).  If the
cert happens to use HTTPS for the policy (I've seen one or two that do), what
policy do you use for the cert securing the HTTPS transfer?  What happens if
the CA asserts anyPolicy but has a URL pointing to a very specific policy that
isn't anyPolicy?  What about qualifiers, do users have to agree to all of
those as well?  What are the policies applied for qualifiers, given that
there's only a single policy URL present?  Do you have to apply qualifiers
when applying policy constraints?  If not, why are they there?  etc etc etc.

Once all that is clearly defined somewhere, I can add support for it to my
code.  Until then, the policy extension serves best as a legal defence
mechanism for the CA to protect themselves from RPs, as per the legal analysis
I posted a day or two back.

Peter.

[0] Since cryptlib is open-source, it's quite possible that users have made
    custom mods to it to handle this, but I wouldn't hear about it unless they
    have problems.  I know that there are quite a number of customised
    versions in use in Europe to handle national signature law/regulation
    quirks (the fact that no government can resist adding its own incompatible
    changes to the legislation is a great help for OSS PKI software, because
    no commercial vendor can support it out-of-the-box), but no-ones ever come
    to me with questions about policy constraints.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hARA7aib047661 for <[e-mail]>; Thu, 27 Nov 2003 02:07:36 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hARA7akT047660 for ietf-pkix-bks; Thu, 27 Nov 2003 02:07:36 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from main.giknpc.com.ua (backup.adm.dp.ua [212.86.233.14]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hARA7Oib047646 for <[e-mail]>; Thu, 27 Nov 2003 02:07:27 -0800 (PST) (envelope-from [e-mail])
Received: (from vf@localhost) by main.giknpc.com.ua (8.11.6/8.11.6) id hARA72Q18815; Thu, 27 Nov 2003 12:07:02 +0200
Date: Thu, 27 Nov 2003 12:07:02 +0200
From: Vadim Fedukovich <[e-mail]>
To: [e-mail]
Cc: Michael Myers <[e-mail]>
Subject: Re: DISCUSS:  MUST  reject in OCSPv1
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.1i
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>

On Wed, Nov 26, 2003 at 05:24:45PM -0700, Michael Myers wrote:
...
> I should note as well that another of this WG's products, SCVP,
> very clearly respects the underlying principle.  c.f. Section
> 3.4 of
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-scvp-13.txt,
> where it is stated that:
> 
>     "If the client includes a requestNonce value
>     in the request, then the server MUST return the
>     same value in the response."
> 
> So again, it's not like this WG is blind the principle.

Please let me second that protocol designers generally have
quite good understanding of security. Another example might be
nonces in SET specifications.

Book 2, page 67:
SET defines ... "nonces" ... to defeat "playback attack".
The sending entity shall generate a random value and insert this value
into the message. The recipient of the message shall copy this value
into the corresponding response message.

Please also note "shall" wording in SET is actually a quite strong one.
Book 2, page 313 (Cardholder processing PInitRes generated by Merchant):
5. Verify Chall-C against the Chall-C in the transaction record.
If Chall-Cs different:
a) Return an Error message with ErrorCode set to challengeMismatch
b) Stop processing PInitRes

Please note there is no option to ask Cardholder whether it is "Ok"
to accept a response from Merchant without a nonce (Cardholder's Challenge).

..yes, I know, SET is not widely used yet. I believe nonce handling
is not the reason

regards,
Vadim



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAR9rFib047138 for <[e-mail]>; Thu, 27 Nov 2003 01:53:15 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAR9rFl2047137 for ietf-pkix-bks; Thu, 27 Nov 2003 01:53:15 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ddba033.netstream.ch (ddba033.netstream.ch [62.65.128.33]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAR9rDib047132 for <[e-mail]>; Thu, 27 Nov 2003 01:53:13 -0800 (PST) (envelope-from [e-mail])
Received: from [62.65.151.222] (helo=swisssign.com) by ddba033.netstream.ch with esmtp (Exim 4.10) id 1APIpj-0006Bl-00; Thu, 27 Nov 2003 10:53:11 +0100
Message-ID: <[e-mail]>
Date: Thu, 27 Nov 2003 10:53:06 +0100
From: Joseph Doekbrijder <[e-mail]>
Organization: SwissSign AG
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007
X-Accept-Language: de-ch, en-us, en, fr-ch
MIME-Version: 1.0
To: Hans Nilsson <[e-mail]>
CC: [e-mail]
Subject: Re: Certificate Policy Standardization
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070402000705070609050203"
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.

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

I know of another: SwissSign
Here too the features are used by customers to define levels of 
certificates with respect to the registration processes and liability...

Cheers

Josh  

Hans Nilsson wrote:

>I know of at least one CA product (SmartTrust Certificate Manager) which can
>supports multiple issuance of certs (with different CPs) per CA root.
>
>I know that this feature also is used by several of SmartTrust's customers,
>for example for distinguishing between different issuing procedures and/or
>private key storage media.
>
>And when talking about Relying Party software, we do not usually mean
>Outlook Express. After all, secure e-mail is not the number 1 PKI
>application. 
>Instead, RPs are usually servers, validating signatures in e-government and
>e-banking applications. And RP software (from MS and others) can pick out
>any field of a certificate and make a decision based on that.
>
>Hans
>
>  
>
>>-----Original Message-----
>>From: [e-mail] [mailto:[e-mail]]
>>    
>>
>On
>  
>
>>Behalf Of Anders Rundgren
>>Sent: Wednesday, November 26, 2003 2:30 PM
>>To: [e-mail]
>>Subject: Re: Certificate Policy Standardization
>>
>>
>>Hum,
>>
>>I wonder how many times I have to repeat the same very basic
>>questions and only getting answers back in "ASN.1"?  Sort of.
>>So here we go again...
>>
>>1. Why does practically no shrink-wrap PKI-enabled software
>>package support any kind of certificate policy settings?
>>
>>2. And why do few if any commercial CAs support multiple
>>issuances (i.e. different CPs) per CA root?
>>
>>Because they have understood the problems associated?
>>Because they enjoy "violating" standards?
>>Because they are ignorant?
>>Because their budget is too limited?
>>Other?
>>
>>Anders
>>
>>----- Original Message -----
>>From: "Santosh Chokhani" <[e-mail]>
>>To: <[e-mail]>
>>Sent: Wednesday, November 26, 2003 12:04
>>Subject: RE: Certificate Policy Standardization
>>
>>
>>
>>Anders:
>>
>>The relying parties are free to ignore the policies and policy related
>>extensions altogether and verify paths.  The certification path will
>>    
>>
>verify
>  
>
>>unless:
>>
>>1.  One or more CAs in the path require that the certification path be
>>    
>>
>valid
>  
>
>>for a policy; or
>>
>>2.  Make the policy related extensions critical.
>>
>>While some may view the two conditions as interoperability problem, I view
>>it CA(s) saying that I do not want you to use the certificate unless you
>>understand and abide by constraints I impose on the certificates.
>>
>>The current X.509 and RFC 3280 permit you build PKI and applications that
>>    
>>
>do
>  
>
>>not use certificate policies.  So, I do not quite understand your concern
>>below.
>>
>>-----Original Message-----
>>From: [e-mail] [mailto:[e-mail]]
>>    
>>
>On
>  
>
>>Behalf Of Anders Rundgren
>>Sent: Wednesday, November 26, 2003 4:03 AM
>>To: Santosh Chokhani; [e-mail]
>>Subject: Re: Certificate Policy Standardization
>>
>>
>>
>>
>>    
>>
>>>I am not what you mean by ".....another useless PKIX bloat extension".
>>>      
>>>
>>>If properly used by the CA and relying party systems, the certificate
>>>policy OID can be used to provide amount of trust the relying party
>>>should place in a certificate.
>>>      
>>>
>>What Michael referred to as "bloat" is not policy identifiers themselves
>>    
>>
>but
>  
>
>>that they need another trust adminstration GUI and associated hassles.
>>
>>Policy identifiers used for path validation purposes is indeed a very
>>"fancy" thing from a technical point of view (maybe 2% of the people
>>subscribed to the PKIX list can understand this part of RFC3280...), but
>>from an interoperability point of view they are not that great.
>>
>>Hum, there simply must be a reason why practically all commercial CAs have
>>selected an entirely different approach.  And that they did this
>>    
>>
>completely
>  
>
>>on their own without any commitee descision etc.
>>
>>I wonder how this really happend.   Could it be...
>>
>>    that it sort of feels "natural"?
>>
>>/a
>>
>>    
>>
>
>
>
>  
>

-- 
Joseph A. Doekbrijder
--------------------------------------------------
SwissSign AG
Löwenstrasse 1, CH-8001 Zürich
Tel: [phone] Mobil: [phone]
www.swisssign.com
--------------------------------------------------


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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIXbDCC
A6kwggKRoAMCAQICCFyxMno/hKJgMA0GCSqGSIb3DQEBBQUAMGQxHDAaBgNVBAMTE1N3aXNz
U2lnbiBTaWx2ZXIgQ0ExIzAhBgkqhkiG9w0BCQEWFHNpbHZlckBzd2lzc3NpZ24uY29tMRIw
EAYDVQQKEwlTd2lzc1NpZ24xCzAJBgNVBAYTAkNIMB4XDTAzMTAxMjExMzgyMloXDTE1MTAw
NjEzMzY1N1owYDEaMBgGA1UEAxMRU3dpc3NTaWduIEdvbGQgQ0ExITAfBgkqhkiG9w0BCQEW
EmdvbGRAc3dpc3NzaWduLmNvbTESMBAGA1UEChMJU3dpc3NTaWduMQswCQYDVQQGEwJDSDCC
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALLSn8w7oFQMQut0IZfPgpKO0yo4dGjJ
bOqNImHzxOi1PY0RxkRNhchKCOPtxIKLTSFRF+xjk7UFC92Ec5CeeU/7q8zbVg3mnXraJDca
B9Sq2Dm8SLhXksnqRDf0CnDXnZYjasBhd8D6ighp2ueeEHsleOKUYbzR9/oRS9zM902s39sL
ZhP3rfyUgBRVD1n0qq7oFERNRtpGgfaNrbfwRbRI7JUg+NQ/YO53sY74Bw8kSrKGNxaBB3sV
f7bbxWTcxiSezS8IAvOCbwnS4t0bzchn4lp6pI7kXUDqIQLFjSXI5+2qJLAecvyKawY7Ir7W
PywWEO86vknPL/vG3909Zc8CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF
MAMBAf8wHQYDVR0OBBYEFLRs9TBBLMA8kYw0J2P6Vbz857Q/MB8GA1UdIwQYMBaAFBL6DIFb
/3/RJdgeczA1D0YYNrJ1MA0GCSqGSIb3DQEBBQUAA4IBAQAxtKZakF6f0gCYxSWGsatUfty2
g4XhEdSIF2iHpvp6H8HAWgrxD/r5FpBLgcBW7yPe7SpTuqGNVrVZSR25Hx13L0QIr7PFvRG7
kJVyfYNSfmSiW5yPypk8LDWLx4+TwXvfj8LwNaGcEyQxBAUmlHHTsWjcN3HpGu6E3XVl3wFl
IRlw5ktztskx1aL1KxQLIZmBM/a+GEb21M5CmHD9dszrtlJnawjs0lrmthDrkopizLHtNCDi
U5YSTHy/pcujvBtTAO8E6ipEoJw21XtF7DEGJkiWolakpERiFGBO5r5avWCgoLgWdX6Zrqzt
AXlr5s2cWU/+1QY3HzM8EtbWeAngMIIDrjCCApagAwIBAgIIEEgLDERrLUUwDQYJKoZIhvcN
AQEFBQAwYDEaMBgGA1UEAxMRU3dpc3NTaWduIEdvbGQgQ0ExITAfBgkqhkiG9w0BCQEWEmdv
bGRAc3dpc3NzaWduLmNvbTESMBAGA1UEChMJU3dpc3NTaWduMQswCQYDVQQGEwJDSDAeFw0w
MzEwMTIxMTU4MjJaFw0wNjEwMTIxMTU4MjJaMGkxIzAhBgNVBAMTGlN3aXNzU2lnbiBQZXJz
b25hbCBHb2xkIENBMSEwHwYJKoZIhvcNAQkBFhJnb2xkQHN3aXNzc2lnbi5jb20xEjAQBgNV
BAoTCVN3aXNzU2lnbjELMAkGA1UEBhMCQ0gwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK
AoIBAQDGZp1oXB5kPBmQfvbqGcm/i5qlKmEVli+r0hcFjEkHbZ+2jE9M1SNTd+8tiCzefyrq
xud0qJ8YDH8KrMYHQ94yO+8sicLDdGjHQQ6LXC/qV0iapQtYKQ7FR7TCMkLOT6mE8WN7lCVW
wREXISxS7/9lSdIgRl4NNPZcjVVC2vVRXBvxdlBd+GK2pzlgVuDkkKMH9ZCWDV6+AHioaS5z
Yb99P33SDEa4ocoEAj2jCdJ0ABLgVWxUnzlED7zAwwcGCgvsjJHJuUFoJ1RlwHsqwMe5PPqy
j3zW2Kp8ni/WgJ8lDJGJuhbVLGjOSOhzViWOt4H6qj3qaxbqIGTWNUcKtpjTAgMBAAGjYzBh
MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBTyNobPvaTWed8y
mYzQWWkdBZUshjAfBgNVHSMEGDAWgBS0bPUwQSzAPJGMNCdj+lW8/Oe0PzANBgkqhkiG9w0B
AQUFAAOCAQEArhxiYfa9i4inp2LgOCJotU2dGFlQdKNin6Ohw9wj2cGr8j814koTNNDxiKF/
27Pit+j2I9uBOoHae/AeIc6jz+ducFGqQ8v1l/J7q/F263HRMH31svgps+fd2p+18ohZdfMC
AxixpKRqcLTPyYrtkC1LoIVOxIdP4ukdfqFDyxfcGHAdHqGJwwStClhb0xFpCwFmGxeOT1eL
bAV1iPlE0AQfd64HY0GyTcUr+yv5CwEGP5lrPXxdo6eF/PlDLYZtvE5BxO1QKJNJnTGvcd19
WazA5m94o5FMcCYRXsHpYPbzGXXF1B43s8OSfNy+SPGgUJnyiBywxINl1XEFITIvwTCCA8Aw
ggKooAMCAQICCQDo8h6mwbv3LjANBgkqhkiG9w0BAQUFADB2MQswCQYDVQQGEwJDSDESMBAG
A1UEChMJU3dpc3NTaWduMTIwMAYDVQQDEylTd2lzc1NpZ24gQ0EgKFJTQSBJSyBNYXkgNiAx
OTk5IDE4OjAwOjU4KTEfMB0GCSqGSIb3DQEJARYQY2FAU3dpc3NTaWduLmNvbTAeFw0wMzEw
MDYxMzM2NTdaFw0xNTEwMDYxMzM2NTdaMGQxHDAaBgNVBAMTE1N3aXNzU2lnbiBCcm9uemUg
Q0ExIzAhBgkqhkiG9w0BCQEWFGJyb256ZUBzd2lzc3NpZ24uY29tMRIwEAYDVQQKEwlTd2lz
c1NpZ24xCzAJBgNVBAYTAkNIMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwNE7
xmO7xNmdlODqLZd7W+gGTeEj00zeh2DMsy/Tnils5TH58CahM7+Mo5BTHGkra5skTjzJMCxF
nHdxYmsSgZq9Hgjfcm4GboSr0sWH2qnDOUAID6iusgNlkPrIFgFJRB+D3YQlGHfOKnjpbMM8
67W4IFVkLG4fy6E+3nTngSZQ4iB7n5pl05eV+6bBSCJpFiW53oHe34nYUblMTCRdFy3AP/Vm
ic2Q2UphjjUUj/ljs5TP6OMbp4z8CKAlikiKPTTFrSdvWs9Nf03C3oacjI0IO2vjyd8hbZeT
20tuSZu1vSKKSEjTxmM7nIziFSmKPQUORd9pRp/DSZeNfMjbbQIDAQABo2MwYTAOBgNVHQ8B
Af8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUcoCI7Z4LPa+pqGtPWhfi1KGO
ZSQwHwYDVR0jBBgwFoAUltdxzTkq1PyIsYqrU3hp749HfhYwDQYJKoZIhvcNAQEFBQADggEB
AKRX2YzRnkOzrcQjyN5iNa4xdoG8TEzLTHiXmsR9kEibK73CkUNvb9MMwyzJnihUfHdwfDw4
fGqsNiBs9V9xXCJ+wlE3aDrxQhrltEqXbys4Ld0VTqaeBxXHzCupsbm0hwgVen+ugFMsWyvk
r+0acJ9wWegGJ3TM2DBJOiKwL67qyM+odg068BDt6B9RikaWJY5XKIfpihJ72Yrem7xjXC6S
0zGTXvtHZSs8NbhzSPYKrXjap/warpzAwKj3AV+LmdHpuz/2SfPkgAp7M/evkeTElRHqBalk
KEUAMTYI1F08tMWGuHBkanl7Uzv7N5ioAwVpLQhV1NH9JG9CECAZhqgwggP4MIIC4KADAgEC
AgkA3pgncg3bHVUwDQYJKoZIhvcNAQEFBQAwZDEcMBoGA1UEAxMTU3dpc3NTaWduIEJyb256
ZSBDQTEjMCEGCSqGSIb3DQEJARYUYnJvbnplQHN3aXNzc2lnbi5jb20xEjAQBgNVBAoTCVN3
aXNzU2lnbjELMAkGA1UEBhMCQ0gwHhcNMDMxMDEyMTEzNjMyWhcNMTUxMDA2MTMzNjU3WjBk
MRwwGgYDVQQDExNTd2lzc1NpZ24gU2lsdmVyIENBMSMwIQYJKoZIhvcNAQkBFhRzaWx2ZXJA
c3dpc3NzaWduLmNvbTESMBAGA1UEChMJU3dpc3NTaWduMQswCQYDVQQGEwJDSDCCASIwDQYJ
KoZIhvcNAQEBBQADggEPADCCAQoCggEBAMz3QXwh/nvpMabdHEk5CptaSV13UQjSfJq27Dab
l9jtvdKc89XRBewyhQh/pPW5vGKo9SoMoSq7eyaDRlB1vN7FPvI462Bv2T637rAh/uIolWXI
gQrz3TNbdKrz2b1qylWHSG/t7fGkM/Pi9PMxS3ZMRuPTPuHDFubKxAj8uGCd5Cc1a2sK1wTA
HIar4jJ4LMlrisOaleRQPaad+sA7LpiLaGVy9wTrDLFNpYd8/zi4Q6VwOQ/N5oBDlkW6pH0l
smk9ZXCLqDGf1zHU/GoVPtxlp2fDvbUBYNP/0n65U92bKex4cdFxLbLiCkGU67FB40M0fm5P
UZSi890suZ8T0UUCAwEAAaOBrDCBqTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB
/zAdBgNVHQ4EFgQUEvoMgVv/f9El2B5zMDUPRhg2snUwHwYDVR0jBBgwFoAUcoCI7Z4LPa+p
qGtPWhfi1KGOZSQwRgYDVR0fBD8wPTA7oDmgN4Y1aHR0cHM6Ly9zd2lzc3NpZ24ubmV0L2Nn
aS1iaW4vYXV0aG9yaXR5L2NybD9jYT1Ccm9uemUwDQYJKoZIhvcNAQEFBQADggEBAKmlVsVY
uuOGs5sWDTYJZEVQOaRbFN8zeM3qWK4xJmphYBkTrDSmAsH9OnBgx17CcsWc5MxTxhU0ef6U
S6A1pxLhYH5vmulwPak1HnLp/vdPQ5M/BGzZPyrFmhhBvh8TI8J7rHLY3loTt9q0R/gFiVvV
YTUfoIG5BsG1WnUQpWO9+fQoaFk8JMklm9oY02VNwTp6gDmCdkDyoljKxjgzfSaPePoX8XA+
qNPGpOSmP+Qc2uBBC/7G0v6roaAmbIPEwQ+Pinl4G1alPV5Tx5P4KtUU8uPUj5kZEJYMBUr0
EUQA/+aEF92SsYVwFbBGB8hr6grBb11imoLpW+TYzXQ9KckwggP/MIIC56ADAgECAghxv+3S
3YlILDANBgkqhkiG9w0BAQUFADBpMSMwIQYDVQQDExpTd2lzc1NpZ24gUGVyc29uYWwgR29s
ZCBDQTEhMB8GCSqGSIb3DQEJARYSZ29sZEBzd2lzc3NpZ24uY29tMRIwEAYDVQQKEwlTd2lz
c1NpZ24xCzAJBgNVBAYTAkNIMB4XDTAzMTAzMDEwNDAyN1oXDTA0MTAzMDEwNDAyN1owbzEb
MBkGA1UEAxMSSm9zZXBoIERvZWticmlqZGVyMS8wLQYJKoZIhvcNAQkBFiBqb3NlcGguZG9l
a2JyaWpkZXJAc3dpc3NzaWduLmNvbTESMBAGA1UEChMJU3dpc3NTaWduMQswCQYDVQQGEwJD
SDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANxqYj3gyEv57yU1uWzgJ45nMp3C
XPEcnoyT5z1rX9BM35qRMjxqnjOXHTSCi3Jt32WrwKs/mN5ZjVcbEwYCme90FcFSqs8of9I3
5o3WzDc1KlhyF1iyahUBQhU2Ckg2wEsgiEgUmSEjuSPjoCa2ggqI8FkGEwTVbDpgANA+9HSi
mzy33s/6kf38npd2ZlBfw3B9A/+hX28THS+JkvcaF3vQ0fAJ7xjanAjOGLbnJ/n0tT1gzI7Z
cMwrdZqSS5O92DPbNyB+iGyVDhE24C9lGaJNkwMYtCHFc2JIuHW0AhmunTUs6YFN/MIoIFqQ
8y95vAdt25eK/ECCt8aYABnLbrECAwEAAaOBpDCBoTAfBgNVHSMEGDAWgBTyNobPvaTWed8y
mYzQWWkdBZUshjBNBgNVHR8ERjBEMEKgQKA+hjxodHRwczovL3N3aXNzc2lnbi5uZXQvY2dp
LWJpbi9hdXRob3JpdHkvY3JsP2NhPVBlcnNvbmFsK0dvbGQwDgYDVR0PAQH/BAQDAgQwMB8G
A1UdJQQYMBYGCisGAQQBgjcKAwQGCCsGAQUFBwMEMA0GCSqGSIb3DQEBBQUAA4IBAQAE4D7D
QYdUJeZlOJIsLuqtVe6UV9qdBnWP0xtpGP6UNEtsbUlLxsQcUn3yTKT1pS5wXnIPXP6q7Nka
klClJGaqTiUqzgDgvzFZEAE/yn/hJW3FAh1fMI/8mg6TjUGZp9EfRuTRN95Vpx8Fplajj0gb
eq3LCmMhonTBkBDC8xC7MQNeMoNfwMwWV2CwYv/nYd4xQPJV+M6gbosQu8IkLZCwS1At/DGo
ZVIMT2oG9Dod42+BLoSo00hVBf7ZVYWu1kRKGW1Fpo9GKRz950e5wXyioqOsubTl3MawYc9R
5ruN2UpfyieybVgELxFJWctrxUMCbZt40TSU9BKagtPYpmOoMIIERjCCAy6gAwIBAgIJAKmI
07nX+nqHMA0GCSqGSIb3DQEBBQUAMGkxIzAhBgNVBAMTGlN3aXNzU2lnbiBQZXJzb25hbCBH
b2xkIENBMSEwHwYJKoZIhvcNAQkBFhJnb2xkQHN3aXNzc2lnbi5jb20xEjAQBgNVBAoTCVN3
aXNzU2lnbjELMAkGA1UEBhMCQ0gwHhcNMDMxMDMwMTQ0MzE2WhcNMDQxMDMwMTQ0MzE2WjBv
MRswGQYDVQQDExJKb3NlcGggRG9la2JyaWpkZXIxLzAtBgkqhkiG9w0BCQEWIGpvc2VwaC5k
b2VrYnJpamRlckBzd2lzc3NpZ24uY29tMRIwEAYDVQQKEwlTd2lzc1NpZ24xCzAJBgNVBAYT
AkNIMIIBITANBgkqhkiG9w0BAQEFAAOCAQ4AMIIBCQKCAQBtmISHM5pmxmB3GrD4n8ZfA82r
tfHgSAl14N3NV9YT6jsiaav2K/k4n5Hn0ije8gGNhZFP+8Q9edYN0rQ1HR22+YfU27J7qm9C
EyY9saO55F36I9yPj4h57PUu6SWgwgwrcOv1ocAbbdKKB8VRFNr9DhwtcXM5pXYC1yHVGpVc
WKy87qv7401vKtftkB5VaC2cE9H14J/7eMExb1NRDUprj96+THgHU4APqDLiU6DphS+MwBwC
v8P2k3BXn9mD91MHMqrPmI+88bTz/MOXw+ynXD8nIgxKFjh2XajOjMUNxKB3tAVosuh0ny51
vpAQiA7AzOkwUDCtNL2vcNHly0dRAgMBAAGjgeswgegwHwYDVR0jBBgwFoAU8jaGz72k1nnf
MpmM0FlpHQWVLIYwTQYDVR0fBEYwRDBCoECgPoY8aHR0cHM6Ly9zd2lzc3NpZ24ubmV0L2Nn
aS1iaW4vYXV0aG9yaXR5L2NybD9jYT1QZXJzb25hbCtHb2xkMA4GA1UdDwEB/wQEAwIDyDAp
BgNVHSUEIjAgBggrBgEFBQcDBAYIKwYBBQUHAwIGCisGAQQBgjcUAgIwOwYDVR0RBDQwMqAw
BgorBgEEAYI3FAIDoCIMIGpvc2VwaC5kb2VrYnJpamRlckBzd2lzc3NpZ24uY29tMA0GCSqG
SIb3DQEBBQUAA4IBAQAlCsDvsCrsE47twAYZFVAaZ078L3JzZxtK8b4TnwTZp7miqrtD7+sZ
Q0JNkerghgZWhAR9oKo6jdnxAf9KTSFDtQPQhTEU/Pp+17mQAzKPvKCMmfGjr3hxEq5i71TW
bUEvQpwPmIYjQ+bcu+vAQiD9CcQjesOOGRi5gspiP+GVNmUQWYg/DHBpaJj5BkCfmisXsTmY
0i9AlOQc2IPUHw/xUUlnFYfoTkqENjEXIUOkxww2wPUs5Jz0ZL2J15u/TJ0w1eKbQJPQo8zM
qZJpQYJVeJq731+5grJ2WN1BGy0/k8x4mOttUC5SMSseIndd/uLjiqIBkx7PcHjpDLXJ9cxj
MYIDYjCCA14CAQEwdjBpMSMwIQYDVQQDExpTd2lzc1NpZ24gUGVyc29uYWwgR29sZCBDQTEh
MB8GCSqGSIb3DQEJARYSZ29sZEBzd2lzc3NpZ24uY29tMRIwEAYDVQQKEwlTd2lzc1NpZ24x
CzAJBgNVBAYTAkNIAgkAqYjTudf6eocwCQYFKw4DAhoFAKCCAcEwGAYJKoZIhvcNAQkDMQsG
CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDMxMTI3MDk1MzA2WjAjBgkqhkiG9w0BCQQx
FgQUpCV4Wjqe4vk2dDwVJfnWjqc2fucwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAO
BggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgw
gYQGCSsGAQQBgjcQBDF3MHUwaTEjMCEGA1UEAxMaU3dpc3NTaWduIFBlcnNvbmFsIEdvbGQg
Q0ExITAfBgkqhkiG9w0BCQEWEmdvbGRAc3dpc3NzaWduLmNvbTESMBAGA1UEChMJU3dpc3NT
aWduMQswCQYDVQQGEwJDSAIIcb/t0t2JSCwwgYYGCyqGSIb3DQEJEAILMXegdTBpMSMwIQYD
VQQDExpTd2lzc1NpZ24gUGVyc29uYWwgR29sZCBDQTEhMB8GCSqGSIb3DQEJARYSZ29sZEBz
d2lzc3NpZ24uY29tMRIwEAYDVQQKEwlTd2lzc1NpZ24xCzAJBgNVBAYTAkNIAghxv+3S3YlI
LDANBgkqhkiG9w0BAQEFAASCAQBZXqn45J6Te+ZbjwS/Ax69Zb//QzzUJBWX8u3570oLE9A9
tZ3vRp+sy7vOJinH711kUZ8LwndJ7t0mbXeDQQqP+PMeia/dvOINgM781AVgPgEcsVEwadd3
s5Rk401KyVKDjUDOLFIvm1oCgdv9tM6r4wA0cIaE29ME93eoKiJNDDgnRtBOMSAHvOb4g9RS
iAt+xOKp24E/D/gzbibTkXrBRU8gZ/vWQ2LUnhlTVxnft2B8lveP7Xo1tKrYMdHKwQwA0An7
VK/K7GmxE9dfOPgououhgoRI8IZCVtoCyTqe8wZUEdfJzH7p2S9KOTPJ9QGEjZDbTwTCKBQf
+Vttt5D7AAAAAAAA
--------------ms070402000705070609050203--




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAR9iDib045469 for <[e-mail]>; Thu, 27 Nov 2003 01:44:13 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAR9iD7I045468 for ietf-pkix-bks; Thu, 27 Nov 2003 01:44:13 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ddba033.netstream.ch (ddba033.netstream.ch [62.65.128.33]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAR9iBib045433 for <[e-mail]>; Thu, 27 Nov 2003 01:44:11 -0800 (PST) (envelope-from [e-mail])
Received: from [62.65.151.222] (helo=swisssign.com) by ddba033.netstream.ch with esmtp (Exim 4.10) id 1APIgS-0005tb-00; Thu, 27 Nov 2003 10:43:36 +0100
Message-ID: <[e-mail]>
Date: Thu, 27 Nov 2003 10:43:22 +0100
From: Joseph Doekbrijder <[e-mail]>
Organization: SwissSign AG
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007
X-Accept-Language: de-ch, en-us, en, fr-ch
MIME-Version: 1.0
To: Anders Rundgren <[e-mail]>
CC: Stephen Kent <[e-mail]>, [e-mail]
Subject: Re: Straw poll: An advice to a commercial CA
References: <01fc01c3b366$8707d760$[e-mail]> <002601c3b3fc$1d25e8a0$0500a8c0@arport> <p06010203bbea6ed9a3e9@[128.89.89.75]> <006601c3b44f$66f98330$0500a8c0@arport>
In-Reply-To: <006601c3b44f$66f98330$0500a8c0@arport>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030705020108080008040402"
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.

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

Only logical thing to do is a single root, signing the cheap CA which in 
its turn signs the expensive CA.
Mathematically correct, includes trust logic, liability levels etc, etc...

This is how we do it. :-)

Cheers

Josh


Anders Rundgren wrote:

>Well,
>Since the list is close to "vibrant" with emotions, why not
>put RFC3280 through the litmus test?
>
>Assume that you as PKI professionals would advice a commercial
>TTP CA on how to configure their issuance for the following:
>1. Free e-mail roundtrip-verification certficates.  Low insurance level
>2. Expensive (high insurance level) multi-usage certificates for individuals
>using strong verification procedures.
>
>Note: the service is to be launched ASAP and has the only
>objective, making money by serving its subscribers well.
>
>Indicate your advice by the word in uppercase.
>
>SINGLE: A single root + possibly some CP OIDs to spice things up
>MULTIPLE: Different roots
>
>Lets rock!
>
>  
>
-- 
Joseph A. Doekbrijder
--------------------------------------------------
SwissSign AG
Löwenstrasse 1, CH-8001 Zürich
Tel: [phone] Mobil: [phone]
www.swisssign.com
--------------------------------------------------


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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIXbDCC
A6kwggKRoAMCAQICCFyxMno/hKJgMA0GCSqGSIb3DQEBBQUAMGQxHDAaBgNVBAMTE1N3aXNz
U2lnbiBTaWx2ZXIgQ0ExIzAhBgkqhkiG9w0BCQEWFHNpbHZlckBzd2lzc3NpZ24uY29tMRIw
EAYDVQQKEwlTd2lzc1NpZ24xCzAJBgNVBAYTAkNIMB4XDTAzMTAxMjExMzgyMloXDTE1MTAw
NjEzMzY1N1owYDEaMBgGA1UEAxMRU3dpc3NTaWduIEdvbGQgQ0ExITAfBgkqhkiG9w0BCQEW
EmdvbGRAc3dpc3NzaWduLmNvbTESMBAGA1UEChMJU3dpc3NTaWduMQswCQYDVQQGEwJDSDCC
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALLSn8w7oFQMQut0IZfPgpKO0yo4dGjJ
bOqNImHzxOi1PY0RxkRNhchKCOPtxIKLTSFRF+xjk7UFC92Ec5CeeU/7q8zbVg3mnXraJDca
B9Sq2Dm8SLhXksnqRDf0CnDXnZYjasBhd8D6ighp2ueeEHsleOKUYbzR9/oRS9zM902s39sL
ZhP3rfyUgBRVD1n0qq7oFERNRtpGgfaNrbfwRbRI7JUg+NQ/YO53sY74Bw8kSrKGNxaBB3sV
f7bbxWTcxiSezS8IAvOCbwnS4t0bzchn4lp6pI7kXUDqIQLFjSXI5+2qJLAecvyKawY7Ir7W
PywWEO86vknPL/vG3909Zc8CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF
MAMBAf8wHQYDVR0OBBYEFLRs9TBBLMA8kYw0J2P6Vbz857Q/MB8GA1UdIwQYMBaAFBL6DIFb
/3/RJdgeczA1D0YYNrJ1MA0GCSqGSIb3DQEBBQUAA4IBAQAxtKZakF6f0gCYxSWGsatUfty2
g4XhEdSIF2iHpvp6H8HAWgrxD/r5FpBLgcBW7yPe7SpTuqGNVrVZSR25Hx13L0QIr7PFvRG7
kJVyfYNSfmSiW5yPypk8LDWLx4+TwXvfj8LwNaGcEyQxBAUmlHHTsWjcN3HpGu6E3XVl3wFl
IRlw5ktztskx1aL1KxQLIZmBM/a+GEb21M5CmHD9dszrtlJnawjs0lrmthDrkopizLHtNCDi
U5YSTHy/pcujvBtTAO8E6ipEoJw21XtF7DEGJkiWolakpERiFGBO5r5avWCgoLgWdX6Zrqzt
AXlr5s2cWU/+1QY3HzM8EtbWeAngMIIDrjCCApagAwIBAgIIEEgLDERrLUUwDQYJKoZIhvcN
AQEFBQAwYDEaMBgGA1UEAxMRU3dpc3NTaWduIEdvbGQgQ0ExITAfBgkqhkiG9w0BCQEWEmdv
bGRAc3dpc3NzaWduLmNvbTESMBAGA1UEChMJU3dpc3NTaWduMQswCQYDVQQGEwJDSDAeFw0w
MzEwMTIxMTU4MjJaFw0wNjEwMTIxMTU4MjJaMGkxIzAhBgNVBAMTGlN3aXNzU2lnbiBQZXJz
b25hbCBHb2xkIENBMSEwHwYJKoZIhvcNAQkBFhJnb2xkQHN3aXNzc2lnbi5jb20xEjAQBgNV
BAoTCVN3aXNzU2lnbjELMAkGA1UEBhMCQ0gwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK
AoIBAQDGZp1oXB5kPBmQfvbqGcm/i5qlKmEVli+r0hcFjEkHbZ+2jE9M1SNTd+8tiCzefyrq
xud0qJ8YDH8KrMYHQ94yO+8sicLDdGjHQQ6LXC/qV0iapQtYKQ7FR7TCMkLOT6mE8WN7lCVW
wREXISxS7/9lSdIgRl4NNPZcjVVC2vVRXBvxdlBd+GK2pzlgVuDkkKMH9ZCWDV6+AHioaS5z
Yb99P33SDEa4ocoEAj2jCdJ0ABLgVWxUnzlED7zAwwcGCgvsjJHJuUFoJ1RlwHsqwMe5PPqy
j3zW2Kp8ni/WgJ8lDJGJuhbVLGjOSOhzViWOt4H6qj3qaxbqIGTWNUcKtpjTAgMBAAGjYzBh
MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBTyNobPvaTWed8y
mYzQWWkdBZUshjAfBgNVHSMEGDAWgBS0bPUwQSzAPJGMNCdj+lW8/Oe0PzANBgkqhkiG9w0B
AQUFAAOCAQEArhxiYfa9i4inp2LgOCJotU2dGFlQdKNin6Ohw9wj2cGr8j814koTNNDxiKF/
27Pit+j2I9uBOoHae/AeIc6jz+ducFGqQ8v1l/J7q/F263HRMH31svgps+fd2p+18ohZdfMC
AxixpKRqcLTPyYrtkC1LoIVOxIdP4ukdfqFDyxfcGHAdHqGJwwStClhb0xFpCwFmGxeOT1eL
bAV1iPlE0AQfd64HY0GyTcUr+yv5CwEGP5lrPXxdo6eF/PlDLYZtvE5BxO1QKJNJnTGvcd19
WazA5m94o5FMcCYRXsHpYPbzGXXF1B43s8OSfNy+SPGgUJnyiBywxINl1XEFITIvwTCCA8Aw
ggKooAMCAQICCQDo8h6mwbv3LjANBgkqhkiG9w0BAQUFADB2MQswCQYDVQQGEwJDSDESMBAG
A1UEChMJU3dpc3NTaWduMTIwMAYDVQQDEylTd2lzc1NpZ24gQ0EgKFJTQSBJSyBNYXkgNiAx
OTk5IDE4OjAwOjU4KTEfMB0GCSqGSIb3DQEJARYQY2FAU3dpc3NTaWduLmNvbTAeFw0wMzEw
MDYxMzM2NTdaFw0xNTEwMDYxMzM2NTdaMGQxHDAaBgNVBAMTE1N3aXNzU2lnbiBCcm9uemUg
Q0ExIzAhBgkqhkiG9w0BCQEWFGJyb256ZUBzd2lzc3NpZ24uY29tMRIwEAYDVQQKEwlTd2lz
c1NpZ24xCzAJBgNVBAYTAkNIMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwNE7
xmO7xNmdlODqLZd7W+gGTeEj00zeh2DMsy/Tnils5TH58CahM7+Mo5BTHGkra5skTjzJMCxF
nHdxYmsSgZq9Hgjfcm4GboSr0sWH2qnDOUAID6iusgNlkPrIFgFJRB+D3YQlGHfOKnjpbMM8
67W4IFVkLG4fy6E+3nTngSZQ4iB7n5pl05eV+6bBSCJpFiW53oHe34nYUblMTCRdFy3AP/Vm
ic2Q2UphjjUUj/ljs5TP6OMbp4z8CKAlikiKPTTFrSdvWs9Nf03C3oacjI0IO2vjyd8hbZeT
20tuSZu1vSKKSEjTxmM7nIziFSmKPQUORd9pRp/DSZeNfMjbbQIDAQABo2MwYTAOBgNVHQ8B
Af8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUcoCI7Z4LPa+pqGtPWhfi1KGO
ZSQwHwYDVR0jBBgwFoAUltdxzTkq1PyIsYqrU3hp749HfhYwDQYJKoZIhvcNAQEFBQADggEB
AKRX2YzRnkOzrcQjyN5iNa4xdoG8TEzLTHiXmsR9kEibK73CkUNvb9MMwyzJnihUfHdwfDw4
fGqsNiBs9V9xXCJ+wlE3aDrxQhrltEqXbys4Ld0VTqaeBxXHzCupsbm0hwgVen+ugFMsWyvk
r+0acJ9wWegGJ3TM2DBJOiKwL67qyM+odg068BDt6B9RikaWJY5XKIfpihJ72Yrem7xjXC6S
0zGTXvtHZSs8NbhzSPYKrXjap/warpzAwKj3AV+LmdHpuz/2SfPkgAp7M/evkeTElRHqBalk
KEUAMTYI1F08tMWGuHBkanl7Uzv7N5ioAwVpLQhV1NH9JG9CECAZhqgwggP4MIIC4KADAgEC
AgkA3pgncg3bHVUwDQYJKoZIhvcNAQEFBQAwZDEcMBoGA1UEAxMTU3dpc3NTaWduIEJyb256
ZSBDQTEjMCEGCSqGSIb3DQEJARYUYnJvbnplQHN3aXNzc2lnbi5jb20xEjAQBgNVBAoTCVN3
aXNzU2lnbjELMAkGA1UEBhMCQ0gwHhcNMDMxMDEyMTEzNjMyWhcNMTUxMDA2MTMzNjU3WjBk
MRwwGgYDVQQDExNTd2lzc1NpZ24gU2lsdmVyIENBMSMwIQYJKoZIhvcNAQkBFhRzaWx2ZXJA
c3dpc3NzaWduLmNvbTESMBAGA1UEChMJU3dpc3NTaWduMQswCQYDVQQGEwJDSDCCASIwDQYJ
KoZIhvcNAQEBBQADggEPADCCAQoCggEBAMz3QXwh/nvpMabdHEk5CptaSV13UQjSfJq27Dab
l9jtvdKc89XRBewyhQh/pPW5vGKo9SoMoSq7eyaDRlB1vN7FPvI462Bv2T637rAh/uIolWXI
gQrz3TNbdKrz2b1qylWHSG/t7fGkM/Pi9PMxS3ZMRuPTPuHDFubKxAj8uGCd5Cc1a2sK1wTA
HIar4jJ4LMlrisOaleRQPaad+sA7LpiLaGVy9wTrDLFNpYd8/zi4Q6VwOQ/N5oBDlkW6pH0l
smk9ZXCLqDGf1zHU/GoVPtxlp2fDvbUBYNP/0n65U92bKex4cdFxLbLiCkGU67FB40M0fm5P
UZSi890suZ8T0UUCAwEAAaOBrDCBqTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB
/zAdBgNVHQ4EFgQUEvoMgVv/f9El2B5zMDUPRhg2snUwHwYDVR0jBBgwFoAUcoCI7Z4LPa+p
qGtPWhfi1KGOZSQwRgYDVR0fBD8wPTA7oDmgN4Y1aHR0cHM6Ly9zd2lzc3NpZ24ubmV0L2Nn
aS1iaW4vYXV0aG9yaXR5L2NybD9jYT1Ccm9uemUwDQYJKoZIhvcNAQEFBQADggEBAKmlVsVY
uuOGs5sWDTYJZEVQOaRbFN8zeM3qWK4xJmphYBkTrDSmAsH9OnBgx17CcsWc5MxTxhU0ef6U
S6A1pxLhYH5vmulwPak1HnLp/vdPQ5M/BGzZPyrFmhhBvh8TI8J7rHLY3loTt9q0R/gFiVvV
YTUfoIG5BsG1WnUQpWO9+fQoaFk8JMklm9oY02VNwTp6gDmCdkDyoljKxjgzfSaPePoX8XA+
qNPGpOSmP+Qc2uBBC/7G0v6roaAmbIPEwQ+Pinl4G1alPV5Tx5P4KtUU8uPUj5kZEJYMBUr0
EUQA/+aEF92SsYVwFbBGB8hr6grBb11imoLpW+TYzXQ9KckwggP/MIIC56ADAgECAghxv+3S
3YlILDANBgkqhkiG9w0BAQUFADBpMSMwIQYDVQQDExpTd2lzc1NpZ24gUGVyc29uYWwgR29s
ZCBDQTEhMB8GCSqGSIb3DQEJARYSZ29sZEBzd2lzc3NpZ24uY29tMRIwEAYDVQQKEwlTd2lz
c1NpZ24xCzAJBgNVBAYTAkNIMB4XDTAzMTAzMDEwNDAyN1oXDTA0MTAzMDEwNDAyN1owbzEb
MBkGA1UEAxMSSm9zZXBoIERvZWticmlqZGVyMS8wLQYJKoZIhvcNAQkBFiBqb3NlcGguZG9l
a2JyaWpkZXJAc3dpc3NzaWduLmNvbTESMBAGA1UEChMJU3dpc3NTaWduMQswCQYDVQQGEwJD
SDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANxqYj3gyEv57yU1uWzgJ45nMp3C
XPEcnoyT5z1rX9BM35qRMjxqnjOXHTSCi3Jt32WrwKs/mN5ZjVcbEwYCme90FcFSqs8of9I3
5o3WzDc1KlhyF1iyahUBQhU2Ckg2wEsgiEgUmSEjuSPjoCa2ggqI8FkGEwTVbDpgANA+9HSi
mzy33s/6kf38npd2ZlBfw3B9A/+hX28THS+JkvcaF3vQ0fAJ7xjanAjOGLbnJ/n0tT1gzI7Z
cMwrdZqSS5O92DPbNyB+iGyVDhE24C9lGaJNkwMYtCHFc2JIuHW0AhmunTUs6YFN/MIoIFqQ
8y95vAdt25eK/ECCt8aYABnLbrECAwEAAaOBpDCBoTAfBgNVHSMEGDAWgBTyNobPvaTWed8y
mYzQWWkdBZUshjBNBgNVHR8ERjBEMEKgQKA+hjxodHRwczovL3N3aXNzc2lnbi5uZXQvY2dp
LWJpbi9hdXRob3JpdHkvY3JsP2NhPVBlcnNvbmFsK0dvbGQwDgYDVR0PAQH/BAQDAgQwMB8G
A1UdJQQYMBYGCisGAQQBgjcKAwQGCCsGAQUFBwMEMA0GCSqGSIb3DQEBBQUAA4IBAQAE4D7D
QYdUJeZlOJIsLuqtVe6UV9qdBnWP0xtpGP6UNEtsbUlLxsQcUn3yTKT1pS5wXnIPXP6q7Nka
klClJGaqTiUqzgDgvzFZEAE/yn/hJW3FAh1fMI/8mg6TjUGZp9EfRuTRN95Vpx8Fplajj0gb
eq3LCmMhonTBkBDC8xC7MQNeMoNfwMwWV2CwYv/nYd4xQPJV+M6gbosQu8IkLZCwS1At/DGo
ZVIMT2oG9Dod42+BLoSo00hVBf7ZVYWu1kRKGW1Fpo9GKRz950e5wXyioqOsubTl3MawYc9R
5ruN2UpfyieybVgELxFJWctrxUMCbZt40TSU9BKagtPYpmOoMIIERjCCAy6gAwIBAgIJAKmI
07nX+nqHMA0GCSqGSIb3DQEBBQUAMGkxIzAhBgNVBAMTGlN3aXNzU2lnbiBQZXJzb25hbCBH
b2xkIENBMSEwHwYJKoZIhvcNAQkBFhJnb2xkQHN3aXNzc2lnbi5jb20xEjAQBgNVBAoTCVN3
aXNzU2lnbjELMAkGA1UEBhMCQ0gwHhcNMDMxMDMwMTQ0MzE2WhcNMDQxMDMwMTQ0MzE2WjBv
MRswGQYDVQQDExJKb3NlcGggRG9la2JyaWpkZXIxLzAtBgkqhkiG9w0BCQEWIGpvc2VwaC5k
b2VrYnJpamRlckBzd2lzc3NpZ24uY29tMRIwEAYDVQQKEwlTd2lzc1NpZ24xCzAJBgNVBAYT
AkNIMIIBITANBgkqhkiG9w0BAQEFAAOCAQ4AMIIBCQKCAQBtmISHM5pmxmB3GrD4n8ZfA82r
tfHgSAl14N3NV9YT6jsiaav2K/k4n5Hn0ije8gGNhZFP+8Q9edYN0rQ1HR22+YfU27J7qm9C
EyY9saO55F36I9yPj4h57PUu6SWgwgwrcOv1ocAbbdKKB8VRFNr9DhwtcXM5pXYC1yHVGpVc
WKy87qv7401vKtftkB5VaC2cE9H14J/7eMExb1NRDUprj96+THgHU4APqDLiU6DphS+MwBwC
v8P2k3BXn9mD91MHMqrPmI+88bTz/MOXw+ynXD8nIgxKFjh2XajOjMUNxKB3tAVosuh0ny51
vpAQiA7AzOkwUDCtNL2vcNHly0dRAgMBAAGjgeswgegwHwYDVR0jBBgwFoAU8jaGz72k1nnf
MpmM0FlpHQWVLIYwTQYDVR0fBEYwRDBCoECgPoY8aHR0cHM6Ly9zd2lzc3NpZ24ubmV0L2Nn
aS1iaW4vYXV0aG9yaXR5L2NybD9jYT1QZXJzb25hbCtHb2xkMA4GA1UdDwEB/wQEAwIDyDAp
BgNVHSUEIjAgBggrBgEFBQcDBAYIKwYBBQUHAwIGCisGAQQBgjcUAgIwOwYDVR0RBDQwMqAw
BgorBgEEAYI3FAIDoCIMIGpvc2VwaC5kb2VrYnJpamRlckBzd2lzc3NpZ24uY29tMA0GCSqG
SIb3DQEBBQUAA4IBAQAlCsDvsCrsE47twAYZFVAaZ078L3JzZxtK8b4TnwTZp7miqrtD7+sZ
Q0JNkerghgZWhAR9oKo6jdnxAf9KTSFDtQPQhTEU/Pp+17mQAzKPvKCMmfGjr3hxEq5i71TW
bUEvQpwPmIYjQ+bcu+vAQiD9CcQjesOOGRi5gspiP+GVNmUQWYg/DHBpaJj5BkCfmisXsTmY
0i9AlOQc2IPUHw/xUUlnFYfoTkqENjEXIUOkxww2wPUs5Jz0ZL2J15u/TJ0w1eKbQJPQo8zM
qZJpQYJVeJq731+5grJ2WN1BGy0/k8x4mOttUC5SMSseIndd/uLjiqIBkx7PcHjpDLXJ9cxj
MYIDYjCCA14CAQEwdjBpMSMwIQYDVQQDExpTd2lzc1NpZ24gUGVyc29uYWwgR29sZCBDQTEh
MB8GCSqGSIb3DQEJARYSZ29sZEBzd2lzc3NpZ24uY29tMRIwEAYDVQQKEwlTd2lzc1NpZ24x
CzAJBgNVBAYTAkNIAgkAqYjTudf6eocwCQYFKw4DAhoFAKCCAcEwGAYJKoZIhvcNAQkDMQsG
CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDMxMTI3MDk0MzMxWjAjBgkqhkiG9w0BCQQx
FgQUp+OgayqBTxoQwM+ZS4SkfWngtDUwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAO
BggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgw
gYQGCSsGAQQBgjcQBDF3MHUwaTEjMCEGA1UEAxMaU3dpc3NTaWduIFBlcnNvbmFsIEdvbGQg
Q0ExITAfBgkqhkiG9w0BCQEWEmdvbGRAc3dpc3NzaWduLmNvbTESMBAGA1UEChMJU3dpc3NT
aWduMQswCQYDVQQGEwJDSAIIcb/t0t2JSCwwgYYGCyqGSIb3DQEJEAILMXegdTBpMSMwIQYD
VQQDExpTd2lzc1NpZ24gUGVyc29uYWwgR29sZCBDQTEhMB8GCSqGSIb3DQEJARYSZ29sZEBz
d2lzc3NpZ24uY29tMRIwEAYDVQQKEwlTd2lzc1NpZ24xCzAJBgNVBAYTAkNIAghxv+3S3YlI
LDANBgkqhkiG9w0BAQEFAASCAQAJ04lGFaxO5QBLBR1Rv1zG2dYgLNYHRjiERqzSZfIFik16
fcN64DcWcS6/+3PPBJ+HJeHszUmGkVF9EUnl6tGyw6h3FnMzHRgmYA4GL40/bFRxv/dotMEW
DVSJq+AMdFwcf7J5Y+3IoMxJAy8udKSpGyGHRC622HnNrVttMrlDgcwNclWB32zjRnqr2mNi
i6m9+mSBGHJBRi7EySfSY1aXwKxj7RUgOJQLp/OYCcjK9v9B+A1DpRbW9un+C/3A9wLfcdhs
leMkFPJXtYrZUtgZq6Ibbe2yHGdOqnNMFjXkKxtYXmSG6Wmfm3XTPQswRU6TuuvVAb7YzF44
Hc+UMUfmAAAAAAAA
--------------ms030705020108080008040402--




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAR4cbib061011 for <[e-mail]>; Wed, 26 Nov 2003 20:38:37 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAR4cbe5061010 for ietf-pkix-bks; Wed, 26 Nov 2003 20:38:37 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAR4caib060998 for <[e-mail]>; Wed, 26 Nov 2003 20:38:37 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (h005008001124.ne.client2.attbi.com[66.31.43.88]) by comcast.net (sccrmhc11) with ESMTP id <2003112704383401100nnrmde>; Thu, 27 Nov 2003 04:38:34 +0000
Received: from localhost ([127.0.0.1] helo=corestreet.com ident=dave) by localhost with esmtp (Exim 3.35 #1 (Debian)) id 1APDx5-0005Rh-00; Wed, 26 Nov 2003 23:40:27 -0500
Message-ID: <[e-mail]>
Date: Wed, 26 Nov 2003 23:40:26 -0500
From: David Engberg <[e-mail]>
Organization: CoreStreet
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Michael Myers <[e-mail]>
CC: [e-mail]
Subject: Re: DISCUSS:  MUST  reject in OCSPv1
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; 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>

I accept your determination that we cannot specify a single new specific 
secure signalling mechanism (e.g. 'nonceUnsupported' extension) inside 
of the formal OCSP v1.

I disagree that we need to intentionally modify the existing RFC 
language to absolutely prohibit implementors from allowing such optional 
local security policies using the normal extensions mechanism in v1. 
I.e. make the language "SHOULD" to unambiguously convey your intent for 
best practices, but leave room for people to knowingly extend under v1 
when the server, client, and local security administrators all have 
security needs that go past your original design.

I don't believe that anyone is condoning any insecure practices.  I 
believe that there are several secure practices under discussion, and 
your (legitimate) concern is that those practices were not presented 
soon enough to be written directly into the v1 standard.  So ... leave 
them out of the standard, but leave some room for security extensibility.

Thanks


Michael Myers wrote:
> Dave,
> 
> As I hope you realize, I take your point in a v2 context.
> However, in v1, there was no discussion whatsoever regarding
> conditional incorporation of a client's nonce.  This is a new
> requirement, leading to new processing functionality and
> doubtless must be taken up in v2 on that basis.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAR4P9ib060490 for <[e-mail]>; Wed, 26 Nov 2003 20:25:09 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAR4P9fS060489 for ietf-pkix-bks; Wed, 26 Nov 2003 20:25:09 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAR4P8ib060483 for <[e-mail]>; Wed, 26 Nov 2003 20:25:08 -0800 (PST) (envelope-from [e-mail])
Received: from orionsec.com (localhost [127.0.0.1]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id hAR4P8B3023243 for <[e-mail]>; Wed, 26 Nov 2003 23:25:08 -0500
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: DISCUSS:  MUST  reject in OCSPv1
Date: Thu, 27 Nov 2003 00:25:08 -0400
Message-Id: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
X-Mailer: Open WebMail 1.81 20021127
X-OriginatingIP: 68.147.139.109 (chokhani)
MIME-Version: 1.0
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>

Mike:

Section 4.1.2 and 4.4 of the RFC 2560 support the position that the nonce can 
be ignored.  I can not find any statement in the RFC that is close to these 
two to support what you are saying.

I do not understand such a hard position being take on the nonce matter when 
RFC itself lacks that much support for it.

When the client does not get the nonce back, it knows either there is a 
replay or the server is doing pre-production.  But, the client has this 
knowledge, this Update, Next Update and produced at fields, and the 
application context to make the determination whether to reject the 
transaction or not.

Decision insist on rekection is purely arbitarary.

On Wed, 26 Nov 2003 17:24:45 -0700, Michael Myers wrote
> Dave,
> 
> As I hope you realize, I take your point in a v2 context.
> However, in v1, there was no discussion whatsoever regarding
> conditional incorporation of a client's nonce.  This is a new
> requirement, leading to new processing functionality and
> doubtless must be taken up in v2 on that basis.
> 
> Meanwhile I remained disturbed that this WG of the IETF Security
> Area will walk away from this issue tacitly condoning an
> insecure practice by inaction on "MUST reject".  It's a tough
> call, I know, but one that is supported by prior poll and an
> issue that begs clarification before this insecure practice
> finds it way to even more environments.  At least, that's my
> opinion.
> 
> I should note as well that another of this WG's products, SCVP,
> very clearly respects the underlying principle.  c.f. Section
> 3.4 of
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-scvp-13.txt,
> where it is stated that:
> 
>     "If the client includes a requestNonce value
>     in the request, then the server MUST return the
>     same value in the response."
> 
> So again, it's not like this WG is blind the principle.
> 
> If "MUST reject" in v1 causes such pain, then find alternative
> means to signal to the relying party that their use of nonces is
> not acceptable and thus motivate a retry.  Goodness knows, web
> surfers today receive ample notice that cookies must be enabled
> to participate on many sites.
> 
> Mike
> 
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]]On Behalf Of
> > David Engberg
> > Sent: Wednesday, November 26, 2003 3:20 PM
> > To: [e-mail]
> > Subject: Re: DISCUSS: MUST reject in OCSPv1
> >
> >
> >
> >
> > In brief:  I would object to a plan to require that
> > v1-compatible
> > clients MUST reject nonceless responses for nonced
> > requests, regardless
> > of local security policy.  I would favor a plan to
> > strongly recommend
> > that v1-compatible clients SHOULD reject nonceless
> > responses for nonced
> > requests.
> >
> > Rationale:
> >
> > Imagine an OCSP client who receives signed email with
> > a cert from Acme
> > Certs.  He chains it up (e.g through bridging) to
> > some trusted root, and
> > then finds Acme's responder URL through the cert's
> > AIA field.  The
> > client trusts the cert, but needs to validate its
> > revocation status
> > through OCSP.  With the "MUST" language, the client
> > is limited to two
> > automatically-enforced local security policies:
> >
> >    1) Don't send a nonce, whether or not Acme's
> > server supports nonces.
> >
> >    2) Send a nonce whether or not Acme's server
> > supports nonces, and
> >       fail to perform any validation if it does not.
> >
> > These two local security policies are both perfectly
> > valid for many
> > users, but the indirect question being asked is:  Are
> > these the ONLY two
> > security policies that v1 OCSP clients may permit
> > users to choose.
> >
> > I posit that there is a third local security policy
> > that the MUST
> > language prohibits, and that policy can be achieved
> > under v1 SHOULD
> > language:
> >
> >    3) Send a nonce to Acme's server, and accept the
> > response IFF
> >       the response contains the nonce OR the server
> > SECURELY signals
> >       that it does not supply nonces to anyone.
> >
> > There was plenty of discussion around the best way to
> > achieve this
> > secure signalling, but there was overwhelming
> > consensus on this list
> > that this should at least be a theoretical option.
> > By using SHOULD, you
> > permit willing clients and servers to extend RFC2560
> > (that's what
> > extensions are there for?) to adopt such an optional
> > security model,
> > rather than arbitrarily preventing all such extensibility.
> >
> > No one is arguing that this third local security
> > policy must be
> > implemented by every client and server, but by
> > adopting language using
> > SHOULD instead of MUST, you will permit v1-compliant
> > servers and clients
> > to at least consider implementing such a policy
> > before v2-final in a few
> > years.
> >
> >
> >






Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAR1eQib054535 for <[e-mail]>; Wed, 26 Nov 2003 17:40:26 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAR1eQDS054534 for ietf-pkix-bks; Wed, 26 Nov 2003 17:40:26 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout01.sul.t-online.com (mailout01.sul.t-online.com [194.25.134.80]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAR1eOib054529 for <[e-mail]>; Wed, 26 Nov 2003 17:40:24 -0800 (PST) (envelope-from [e-mail])
Received: from fwd01.aul.t-online.de  by mailout01.sul.t-online.com with smtp  id 1APB29-00017v-00; Thu, 27 Nov 2003 02:33:29 +0100
Received: from hagen (VTmqMgZFgeTjPHPmk+0AIdukah0eNctZcEG84BPFsklZTfbB4vg26e@[217.80.246.231]) by fmrl01.sul.t-online.com with esmtp id 1APB26-0o7IeW0; Thu, 27 Nov 2003 02:33:26 +0100
From: "Florian Oelmaier" <[e-mail]>
To: "'Michael Myers'" <[e-mail]>, <[e-mail]>
Subject: RE: DISCUSS:  MUST  reject in OCSPv1
Date: Thu, 27 Nov 2003 02:33:26 +0100
Organization: SyTrust
Message-ID: <000001c3b486$74cb1730$4228a8c0@hagen>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Seen: false
X-ID: [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've chosen not to incorporate your well reasoned argument 
> due to my business model.  :)

hehehehe

> How about in v1 we clarify by saying that "clients claiming 
> conformance to this standard SHALL be capable of rejecting . . . "

What about something like: 

------

Clients including a nonce into the request MUST NOT accept nonce-less
responses from responders that are known to be capable of generating
nonces. If this is unknown for a certain responder, clients MAY accept
the additional risk of accepting the nonce-less response. 

A responder MAY include the OCSPNonceSupported extension into every
response to indicate the capability of producing nonces to the client
(even in the case of a replay attack). The OCSPNonceSupported extension
will be identified by the object identifier id-pkix-ocsp-noncesupported,
while the extnValue is a boolean value indicating if nonces are
supported by this responder (TRUE) or not (FALSE).

id-pkix-ocsp-noncesupported     OBJECT IDENTIFIER ::= { id-pkix-ocsp 8 }

------



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAR0fsib052439 for <[e-mail]>; Wed, 26 Nov 2003 16:41:54 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAR0fsGA052438 for ietf-pkix-bks; Wed, 26 Nov 2003 16:41:54 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAR0fqib052433 for <[e-mail]>; Wed, 26 Nov 2003 16:41:52 -0800 (PST) (envelope-from [e-mail])
Received: from MMyersLapTop ([65.39.77.99]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id hAR0fpA96026; Wed, 26 Nov 2003 17:41:52 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: "Florian Oelmaier" <[e-mail]>, <[e-mail]>
Subject: RE: DISCUSS:  MUST  reject in OCSPv1
Date: Wed, 26 Nov 2003 17:44:04 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1106
In-Reply-To: <000001c3b478$95bc32c0$4228a8c0@hagen>
Importance: Normal
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>

Florian,

I've chosen not to incorporate your well reasoned argument due
to my business model.  :)

More seriously, if we can't agree on "MUST reject" clarification
language in v1, could we possibly agree on some other language
that causes v1 implementors to at least stop and consider the
implications of their actions?  v2 is by no means a foregone
conclusion and meanwhile v1 is just now gaining appreciable
traction.

How about in v1 we clarify by saying that "clients claiming
conformance to this standard SHALL be capable of rejecting . . .
"

Mike



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAR0MXib051732 for <[e-mail]>; Wed, 26 Nov 2003 16:22:33 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAR0MXX5051731 for ietf-pkix-bks; Wed, 26 Nov 2003 16:22:33 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAR0MWib051725 for <[e-mail]>; Wed, 26 Nov 2003 16:22:32 -0800 (PST) (envelope-from [e-mail])
Received: from MMyersLapTop ([65.39.77.99]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id hAR0MXA94975; Wed, 26 Nov 2003 17:22:33 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: "David Engberg" <[e-mail]>, <[e-mail]>
Subject: RE: DISCUSS:  MUST  reject in OCSPv1
Date: Wed, 26 Nov 2003 17:24:45 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1106
In-Reply-To: <[e-mail]>
Importance: Normal
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>

Dave,

As I hope you realize, I take your point in a v2 context.
However, in v1, there was no discussion whatsoever regarding
conditional incorporation of a client's nonce.  This is a new
requirement, leading to new processing functionality and
doubtless must be taken up in v2 on that basis.

Meanwhile I remained disturbed that this WG of the IETF Security
Area will walk away from this issue tacitly condoning an
insecure practice by inaction on "MUST reject".  It's a tough
call, I know, but one that is supported by prior poll and an
issue that begs clarification before this insecure practice
finds it way to even more environments.  At least, that's my
opinion.

I should note as well that another of this WG's products, SCVP,
very clearly respects the underlying principle.  c.f. Section
3.4 of
http://www.ietf.org/internet-drafts/draft-ietf-pkix-scvp-13.txt,
where it is stated that:

    "If the client includes a requestNonce value
    in the request, then the server MUST return the
    same value in the response."

So again, it's not like this WG is blind the principle.

If "MUST reject" in v1 causes such pain, then find alternative
means to signal to the relying party that their use of nonces is
not acceptable and thus motivate a retry.  Goodness knows, web
surfers today receive ample notice that cookies must be enabled
to participate on many sites.


Mike


> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of
> David Engberg
> Sent: Wednesday, November 26, 2003 3:20 PM
> To: [e-mail]
> Subject: Re: DISCUSS: MUST reject in OCSPv1
>
>
>
>
> In brief:  I would object to a plan to require that
> v1-compatible
> clients MUST reject nonceless responses for nonced
> requests, regardless
> of local security policy.  I would favor a plan to
> strongly recommend
> that v1-compatible clients SHOULD reject nonceless
> responses for nonced
> requests.
>
> Rationale:
>
> Imagine an OCSP client who receives signed email with
> a cert from Acme
> Certs.  He chains it up (e.g through bridging) to
> some trusted root, and
> then finds Acme's responder URL through the cert's
> AIA field.  The
> client trusts the cert, but needs to validate its
> revocation status
> through OCSP.  With the "MUST" language, the client
> is limited to two
> automatically-enforced local security policies:
>
>    1) Don't send a nonce, whether or not Acme's
> server supports nonces.
>
>    2) Send a nonce whether or not Acme's server
> supports nonces, and
>       fail to perform any validation if it does not.
>
> These two local security policies are both perfectly
> valid for many
> users, but the indirect question being asked is:  Are
> these the ONLY two
> security policies that v1 OCSP clients may permit
> users to choose.
>
> I posit that there is a third local security policy
> that the MUST
> language prohibits, and that policy can be achieved
> under v1 SHOULD
> language:
>
>    3) Send a nonce to Acme's server, and accept the
> response IFF
>       the response contains the nonce OR the server
> SECURELY signals
>       that it does not supply nonces to anyone.
>
> There was plenty of discussion around the best way to
> achieve this
> secure signalling, but there was overwhelming
> consensus on this list
> that this should at least be a theoretical option.
> By using SHOULD, you
> permit willing clients and servers to extend RFC2560
> (that's what
> extensions are there for?) to adopt such an optional
> security model,
> rather than arbitrarily preventing all such extensibility.
>
> No one is arguing that this third local security
> policy must be
> implemented by every client and server, but by
> adopting language using
> SHOULD instead of MUST, you will permit v1-compliant
> servers and clients
> to at least consider implementing such a policy
> before v2-final in a few
> years.
>
>
>



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQNsUib050053 for <[e-mail]>; Wed, 26 Nov 2003 15:54:30 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQNsUBm050052 for ietf-pkix-bks; Wed, 26 Nov 2003 15:54:30 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout03.sul.t-online.com (mailout03.sul.t-online.com [194.25.134.81]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQNsSib050047 for <[e-mail]>; Wed, 26 Nov 2003 15:54:28 -0800 (PST) (envelope-from [e-mail])
Received: from fwd01.aul.t-online.de  by mailout03.sul.t-online.com with smtp  id 1AP9UA-0000Mo-04; Thu, 27 Nov 2003 00:54:18 +0100
Received: from hagen (ZkgX7wZOweQv0HXMeSprl6ui5s7OWKLdqokfXpIq2oS7tB0AKW12YY@[217.80.246.231]) by fmrl01.sul.t-online.com with esmtp id 1AP9U1-0CFE240; Thu, 27 Nov 2003 00:54:09 +0100
From: "Florian Oelmaier" <[e-mail]>
To: <[e-mail]>, "'Stephen Kent'" <[e-mail]>, "'Carlisle Adams'" <[e-mail]>, "'Michael Myers'" <[e-mail]>
Subject: RE: DISCUSS:  MUST  reject in OCSPv1
Date: Thu, 27 Nov 2003 00:54:09 +0100
Organization: SyTrust
Message-ID: <000001c3b478$95bc32c0$4228a8c0@hagen>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Seen: false
X-ID: [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>

#### Summary, detailed response below ####

I would propose the following process to solve this discussion:

+Find an answer to the question "IS IT REASONABLE FOR A CLIENT 
|  TO ASK FOR A NONCE BUT ALSO TO WORK WITH RESPONSES WITHOUT 
|  NONCE?". 
|
+--- If the answer is "NO": 
|        choose the "MUST-REJECT" proposal. 
|
+--+ If the answer is "YES":
   |
   +--+ choose one of the proposed methods answering the 
   |       questions "HOW CAN THE CLIENT TELL THE RESPONDER, 
   |       HOW IT INTENDS TO HANDLE NONCE-LESS RESPONSES?" 
   |         (proposed methods: critical flag for nonces,
   |          will-accept-nonceless-response extension)
   |
   +--+ choose one of the proposed methods answering the 
           questions "HOW CAN THE CLIENT TELL THE RESPONDER, 
           HOW IT INTENDS TO HANDLE NONCE-LESS RESPONSES?"
             (proposed methods: NonceSupported extension,
              NonceUnsupported extension, server-generated nonces)

#### Detailed response, LONG!!! ####

> 1.  Regarding v1, clarify per the minutes as
>     2560 goes from Proposed to Draft.  The
>     operative text of which is that clients
>     MUST reject a response that fails to
>     incorporate a client's nonce.

I object. It breaks running code in installations. It changes the spirit
of the protocol as a lot of people understood it (due to the current
wording in RfC2560). And most important, I object as there are better
solutions already outlined (see more below).

> To initiate the v1 discussion, my opinions are as follows.
> 
> 1.  Nonces were established in OCSP to enable
>     client driven prevention of replay attacks.
>     Failure to respect a client's nonce is a
>     direct denial of a client's request for
>     this security service.  A responder that
>     does so is contributing to the very security
>     risks the requestor is seeking to mitigate.

The whole AIA system of RfC2560 and 3280 indicates that clients do not
have any knowledge of the remote OCSP-Responder (otherwise there would
be no need to indicate the URL of the responder in the certificate).
Thus most clients do not know if the Responder supports nonces or not
(e.g. due to caching). How should they, they didnt even knew the URL
until they read the AIA!

Seeing this it is a very acceptable for a client to TRY to get a nonce,
but to accept answers without nonces as a fallback. It is a "natural"
behaviour - I try for all extensions I support, but will fall back to
the very basics of the standard, to the "not extended" behaviour when I
cannot get what I want. This is the usual way of doing things in nearly
all protocols out there, PKIX or not.

So the very basic assumption of your argument is not true at least for
my client. I use nonces to prevent replay attacks WHERE POSSIBLE. If it
is not possible, I will not give up and will instead do my best to get a
revocation information that is as good as the information in a CRL is.

So the very first question is:

*** IS IT REASONABLE FOR A CLIENT TO ASK FOR A NONCE BUT ALSO TO WORK
WITH RESPONSES WITHOUT NONCE? ***

If the answer is "NO", the MUST-REJECT solution to the problem is the
way to go. 

If the answer is "YES", the MUST-REJECT solution is not a good way to
go. As outlined above, I think this IS reasonable and there are other
implementors out there thinking that, too. So if the answer is "YES" we
have to answer two additional questions:

The first question is:

*** HOW CAN THE CLIENT TELL THE RESPONDER, HOW IT INTENDS TO HANDLE
NONCE-LESS RESPONSES? ***

Proposals on the table:
- critical-Flag for nonces
- new request extensions

Due to security reasons (an attacker could replay nonce-less responses
from a responder usually supporting nonces) we have a second question to
answer:

*** HOW CAN THE CLIENT TELL THE RESPONDER, HOW IT INTENDS TO HANDLE
NONCE-LESS RESPONSES? ***

Proposals on the table:
- NonceSupported extension
- NonceUnsupported extension
- server generated nonces

So the process forward in my eyes is really simple:
Find an answer to the question "IS IT REASONABLE FOR A CLIENT TO ASK FOR
A NONCE BUT ALSO TO WORK WITH RESPONSES WITHOUT NONCE?". 

If the answer is "NO", choose the "MUST-REJECT" proposal. 

If the answer is "YES", choose one of the proposed methods answering the
questions "HOW CAN THE CLIENT TELL THE RESPONDER, HOW IT INTENDS TO
HANDLE NONCE-LESS RESPONSES?" and "HOW CAN THE CLIENT TELL THE
RESPONDER, HOW IT INTENDS TO HANDLE NONCE-LESS RESPONSES?".


> 2.  While 2560 also enables use of pre-produced
>     responses, nonces and pre-produced responses
>     are by definition mutually exclusive.  This
>     effect should be immediately obvious to even
>     the most naive of implementors, else they have
>     no business writing code against this standard.
>     A competent level of technical proficiency
>     in implementing secure protocols is assumed.

That is correct. A responder will either support nonces or caching. But
that is not the point, because the client DOES NOT KNOW which way the
responder is working.

> 3.  The "breakage" poll indicates that an
>     overwhelming majority of OCSP implementors
>     possess this competency.  11 of 12 client-side
>     implementors reported no breakage with
>     "MUST reject" while 10 of 12 server-side
>     implementors responded likewise.

I will not discuss the breakage poll. It is long superseded by the
discussion. The poll should be: "Does this proposal break installations
or valid use-cases of your software?" 

> 4.  The two server-side breakage points occur
>     as a consequence of their use of pre-produced
>     responses in a context where they have no
>     administrative control over clients' use of
>     nonces.  This can be addressed in v2, but in
>     a v1 context we have no choice but to clarify
>     original intent as ratified by the breakage poll.
>     This breakage could also be relieved by relay
>     of OCSP requests.

We all know we could go that way. But why should we do it? There are
alternate proposals. There are better ways of doing it. Multiple people
pointed out other solutions outwitting this proposal in every aspect. I
agree with you, technically the proposal is possible, but we can do it
another way round without the ugly downsides.



---- for the interested readers, no new arguments behind this line ----

> 5.  The absence of normative language providing a
>     tutorial on the proper use of nonces in a
>     security protocol SHOULD NOT be taken up by
>     any participant in this WG as an excuse to
>     refute sound security principles.  Active
>     participants in the Security Area of the IETF
>     should be able to assume of their peers a
>     superior grasp of and respect for foundational
>     principles.

[A rant?] I agree. I also think that active participants of this WG and
security experts in general should be open-minded, self-critical and
intelligent. I am sure that all people in this WG cultivate these
virtues. And I am sure that you do not intend to indicate that people
objecting to your arguments to not have a grasp and respect for
foundational principles.

> Objections to the "MUST reject" clarification are sought on 
> the basis of sound security engineering principles rather 
> than artful readings of ancillary language that enable 
> specious excuse from adherence to these principles in order 
> to justify current business models.

/agree

But mind: While I dont care for business-models, I care for use-cases.
There is no need to define a standard that is not able to serve the
use-cases needed. So we have to care about reasonable use-cases. If we
dont do that, we should advise people not to use any internet based
communications in security critical environments, as this is the most
secure option. 

> We are setting standards that must survive the test of time.  
> We are supposed to check our corporate identities at the 
> door.  We are supposed to be individual engineers chartered 
> to improve Internet security.  Let us do so and get this 
> problem solved.

/agree

> My thanks to you all in advance for your patience with the 
> length of this note.

I am very glad that you bring this discussion on again. We cannot let
the Certificate Policy OID discussion get more attention as the OCSP
nonce discussion :) /cheer

-- 
Florian Oelmaier
SyTrust



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQNj0ib049743 for <[e-mail]>; Wed, 26 Nov 2003 15:45:02 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQNixWD049742 for ietf-pkix-bks; Wed, 26 Nov 2003 15:44:59 -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.10/8.12.8) with ESMTP id hAQNiwib049736 for <[e-mail]>; Wed, 26 Nov 2003 15:44:58 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (127.0.0.1) by nic.lp.se (MX V5.3 VnHj) with ESMTP; Thu, 27 Nov 2003 00:43:14 +0100
Date: Thu, 27 Nov 2003 00:43:13 +0100 (CET)
Message-ID: <[e-mail]>
To: [e-mail]
CC: [e-mail], [e-mail]
Subject: Re: Straw poll: An advice to a commercial CA
From: Richard Levitte - VMS Whacker <[e-mail]>
In-Reply-To: <006601c3b44f$66f98330$0500a8c0@arport>
References: <002601c3b3fc$1d25e8a0$0500a8c0@arport> <p06010203bbea6ed9a3e9@[128.89.89.75]> <006601c3b44f$66f98330$0500a8c0@arport>
X-URL: http://www.lp.se/
X-Waved: dead chicken, GNU emacs 21.3.1, Mew version 4.0.60
X-Mew: See http://www.mew.org/
X-Mailer: Mew version 4.0.60 on Emacs 21.3.1 / 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 <006601c3b44f$66f98330$0500a8c0@arport> on Wed, 26 Nov 2003 19:59:20 +0100, "Anders Rundgren" <[e-mail]> said:

anders.rundgren> Since the list is close to "vibrant" with emotions,
anders.rundgren> why not put RFC3280 through the litmus test?
anders.rundgren> 
anders.rundgren> Assume that you as PKI professionals would advice a
anders.rundgren> commercial TTP CA on how to configure their issuance
anders.rundgren> for the following: 
anders.rundgren> 1. Free e-mail roundtrip-verification certficates.
anders.rundgren>    Low insurance level
anders.rundgren> 2. Expensive (high insurance level) multi-usage
anders.rundgren>    certificates for individuals using strong
anders.rundgren>    verification procedures.
anders.rundgren> 
anders.rundgren> Note: the service is to be launched ASAP and has the
anders.rundgren> only objective, making money by serving its
anders.rundgren> subscribers well.
anders.rundgren> 
anders.rundgren> Indicate your advice by the word in uppercase.
anders.rundgren> 
anders.rundgren> SINGLE: A single root + possibly some CP OIDs to
anders.rundgren>         spice things up 
anders.rundgren> MULTIPLE: Different roots

Well, it depends on several factors:

 - What's your value for "ASAP"?  Yesterday?  Immediately?  In a
   month?  Within half a year?
 - What does "serving it's subscribers well" mean?

I think I'd go single root with a set of policy OIDs if possible.  I'm
assuming that with current implementations, it wouldn't be too
difficult to set upp a hierarchical PKI that allows such constructs
and have the client software do verification properly, except for the
check on policy OIDs.  Policy OID checking would probably require quite
a bit of hacking for some time.

Note that except for the email-only certificates, the client
certificates are of value to the servers, mostly.  It wouldn't be too
difficult to deploy some kind of gateway that does policy checking
before letting users go on to the stuff they are authorized to view or
handle.  And with time, I'm assuming the servers serving "the stuff"
could handle such things on their own.

Anyhow, I'm a bit tired, so if the above doesn't make sense, I'll
blame it on that and get back tomorrow...

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.
You don't have to be rich, a $10 donation is appreciated!

-- 
Richard Levitte     | http://richard.levitte.org/ | Tunnlandsv. 3
Levitte Programming | http://www.lp.se/           | S-168 36 Bromma
T: [phone] |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQNg8ib049648 for <[e-mail]>; Wed, 26 Nov 2003 15:42:08 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQNg8Bd049647 for ietf-pkix-bks; Wed, 26 Nov 2003 15:42:08 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from gretel.pobox.com (gretel.pobox.com [208.210.125.56]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQNg7ib049642 for <[e-mail]>; Wed, 26 Nov 2003 15:42:07 -0800 (PST) (envelope-from [e-mail])
Received: from texas.pobox.com (texas.pobox.com[64.49.223.111]) by gretel.pobox.com (Postfix) with ESMTP id 03118BE5799; Wed, 26 Nov 2003 18:42:00 -0500 (EST)
Received: from gnosis (12-230-199-189.client.attbi.com [12.230.199.189]) by texas.pobox.com (Postfix) with ESMTP id 8D93F45366; Wed, 26 Nov 2003 18:41:58 -0500 (EST)
From: "L Williams" <[e-mail]>
To: "'Anders Rundgren'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Straw poll: An advice to a commercial CA
Date: Wed, 26 Nov 2003 15:41:57 -0800
Message-ID: <000001c3b476$e2751390$6601a8c0@gnosis>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
Importance: Normal
In-Reply-To: <006601c3b44f$66f98330$0500a8c0@arport>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id hAQNg8ib049643
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'll bite. First, I disagree with your framing of the question. What you
seem to be implying is that you have requirements that dictate two very
different vetting processes. You are essentially saying that the differences
in the vetting process translate to two completely different levels of
trust, and you want a way to communicate that to relying parties. I'm
pointing this out because the use of "e-mail roundtrip verification" in your
statement below is irrelevant.

With that setup, the most practical solution is to use 2 different root CAs.
The reason is that a large number of existing applications (and protocols)
lack support for differentiating between policy OIDs. For example, the TLS
protocol gives you a list of trusted issuers, not trusted issuers and CP
OIDs. I'm not aware of an email client that can differentiate certificate
level based on CP OID.

With that said, it would be a non sequitur to assume that this means that CP
OIDs are irrelevant. They lack practical applicability for this particular
use. They are quite useful in controlled/managed environments, such as large
corporate environments.

Your much bigger problem is going to be determining a way to effectively
signal to the relying parties what types of uses you intended the issued
certificate to be used for. I would consider that to be much more
contentious and problematic than deciding if I need one root or two.

-Laudon



-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Anders Rundgren
Sent: Wednesday, November 26, 2003 10:59 AM
To: Stephen Kent
Cc: [e-mail]
Subject: Straw poll: An advice to a commercial CA


Well,
Since the list is close to "vibrant" with emotions, why not
put RFC3280 through the litmus test?

Assume that you as PKI professionals would advice a commercial
TTP CA on how to configure their issuance for the following:
1. Free e-mail roundtrip-verification certficates.  Low insurance level
2. Expensive (high insurance level) multi-usage certificates for individuals
using strong verification procedures.

Note: the service is to be launched ASAP and has the only
objective, making money by serving its subscribers well.

Indicate your advice by the word in uppercase.

SINGLE: A single root + possibly some CP OIDs to spice things up
MULTIPLE: Different roots

Lets rock!

/a

----- Original Message ----- 
From: "Stephen Kent" <[e-mail]>
To: "Anders Rundgren" <[e-mail]>
Cc: <[e-mail]>
Sent: Wednesday, November 26, 2003 15:55
Subject: Re: Certificate Policy Standardization



At 10:03 +0100 11/26/03, Anders Rundgren wrote:
>  >I am not what you mean by ".....another useless PKIX bloat extension".
>
>>If properly used by the CA and relying party systems, the certificate
policy
>>OID can be used to provide amount of trust the relying party should place
in
>>a certificate.
>
>What Michael referred to as "bloat" is not policy identifiers themselves
>but that they need another trust adminstration GUI and associated hassles.
>
>Policy identifiers used for path validation purposes is indeed a
>very "fancy" thing from a technical point of view (maybe 2% of the
>people subscribed to the PKIX list can understand this part of
>RFC3280...), but from an interoperability point of view they are
>not that great.
>
>Hum, there simply must be a reason why practically all commercial
>CAs have selected an entirely different approach.  And that they did
>this completely on their own without any commitee descision etc.
>
>I wonder how this really happend.   Could it be...
>
>     that it sort of feels "natural"?
>
>/a

could it be because some of them are clueless, as evidenced by 
Peter's collection of non-compliant certs issued by these folks?

could it be because these CAs like to create their own closed 
communities to maintain market share?

there are lots of good reasons for a CA to not use a feature in the 
standards, a few good reasons to choose another way to achieve the 
same effect, and lots of bad reasons to choose another way ...


Steve




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQMJpib046844 for <[e-mail]>; Wed, 26 Nov 2003 14:19:51 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQMJpls046843 for ietf-pkix-bks; Wed, 26 Nov 2003 14:19:51 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from the-humungus.corestreet.com ([68.162.232.130]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQMJoib046834 for <[e-mail]>; Wed, 26 Nov 2003 14:19:50 -0800 (PST) (envelope-from [e-mail])
Received: from corestreet.com (engberg2.corestreet.com [192.168.2.119]) by the-humungus.corestreet.com (8.12.8/8.12.8) with ESMTP id hAQMJlEj031222 for <[e-mail]>; Wed, 26 Nov 2003 17:19:47 -0500
Message-ID: <[e-mail]>
Date: Wed, 26 Nov 2003 17:19:48 -0500
From: David Engberg <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: DISCUSS:  MUST  reject in OCSPv1
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; 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>

In brief:  I would object to a plan to require that v1-compatible 
clients MUST reject nonceless responses for nonced requests, regardless 
of local security policy.  I would favor a plan to strongly recommend 
that v1-compatible clients SHOULD reject nonceless responses for nonced 
requests.

Rationale:

Imagine an OCSP client who receives signed email with a cert from Acme 
Certs.  He chains it up (e.g through bridging) to some trusted root, and 
then finds Acme's responder URL through the cert's AIA field.  The 
client trusts the cert, but needs to validate its revocation status 
through OCSP.  With the "MUST" language, the client is limited to two 
automatically-enforced local security policies:

   1) Don't send a nonce, whether or not Acme's server supports nonces.

   2) Send a nonce whether or not Acme's server supports nonces, and
      fail to perform any validation if it does not.

These two local security policies are both perfectly valid for many 
users, but the indirect question being asked is:  Are these the ONLY two 
security policies that v1 OCSP clients may permit users to choose.

I posit that there is a third local security policy that the MUST 
language prohibits, and that policy can be achieved under v1 SHOULD 
language:

   3) Send a nonce to Acme's server, and accept the response IFF
      the response contains the nonce OR the server SECURELY signals
      that it does not supply nonces to anyone.

There was plenty of discussion around the best way to achieve this 
secure signalling, but there was overwhelming consensus on this list 
that this should at least be a theoretical option.  By using SHOULD, you 
permit willing clients and servers to extend RFC2560 (that's what 
extensions are there for?) to adopt such an optional security model, 
rather than arbitrarily preventing all such extensibility.

No one is arguing that this third local security policy must be 
implemented by every client and server, but by adopting language using 
SHOULD instead of MUST, you will permit v1-compliant servers and clients 
to at least consider implementing such a policy before v2-final in a few 
years.





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQM5eib046331 for <[e-mail]>; Wed, 26 Nov 2003 14:05:40 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQM5e1g046330 for ietf-pkix-bks; Wed, 26 Nov 2003 14:05:40 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQM5cib046325 for <[e-mail]>; Wed, 26 Nov 2003 14:05:39 -0800 (PST) (envelope-from [e-mail])
Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Wed, 26 Nov 2003 14:05:38 -0800
Received: from 157.54.8.23 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 26 Nov 2003 14:05:37 -0800
Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 26 Nov 2003 14:05:35 -0800
Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 26 Nov 2003 14:05:35 -0800
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 26 Nov 2003 14:05:50 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.7122.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: DISCUSS:  MUST  reject in OCSPv1
Date: Wed, 26 Nov 2003 14:05:32 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: DISCUSS:  MUST  reject in OCSPv1
Thread-Index: AcO0aJdnOYDeYy8tQkOFBo9O7K5QbAAAKIMg
From: "Ryan M. Hurst" <[e-mail]>
To: "Michael Myers" <[e-mail]>, <[e-mail]>
Cc: "Carlisle Adams" <[e-mail]>
X-OriginalArrivalTime: 26 Nov 2003 22:05:50.0894 (UTC) FILETIME=[741A1CE0:01C3B469]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id hAQM5dib046326
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 know this isn't a poll, but to be clear MSFT does not support the MUST
reject in v1, nor the creation of a v2 for the nonce reason alone.

Ryan

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Michael Myers
Sent: Wednesday, November 26, 2003 12:05 PM
To: [e-mail]
Cc: Carlisle Adams
Subject: DISCUSS: MUST reject in OCSPv1


Colleagues,

I recently proposed to the chairs and the AD the following
action plan with respect to nonces in OCSP.  They in turn remain
curious as to working group consensus on the subject with a
particular emphasis on objections.  I had hoped for an ad-hoc
quorum on this in Minneapolis but it never materialized due to
the absence of several key players.

So, once more into the breach.  Who would object and why to the
following action plan (silence WILL be taken as consent):

1.  Regarding v1, clarify per the minutes as
    2560 goes from Proposed to Draft.  The
    operative text of which is that clients
    MUST reject a response that fails to
    incorporate a client's nonce.

2.  Simultaneously, initiate action on a v2
    I-D that will in part address technical
    changes in syntax and processing rules
    related to the use of nonces.

This is not a poll.  It is a request for discussion.  I expect
little disagreement on the intent of the v2 action item. The
core issue on v1 is "MUST reject".

To initiate the v1 discussion, my opinions are as follows.

1.  Nonces were established in OCSP to enable
    client driven prevention of replay attacks.
    Failure to respect a client's nonce is a
    direct denial of a client's request for
    this security service.  A responder that
    does so is contributing to the very security
    risks the requestor is seeking to mitigate.

2.  While 2560 also enables use of pre-produced
    responses, nonces and pre-produced responses
    are by definition mutually exclusive.  This
    effect should be immediately obvious to even
    the most naive of implementors, else they have
    no business writing code against this standard.
    A competent level of technical proficiency
    in implementing secure protocols is assumed.

3.  The "breakage" poll indicates that an
    overwhelming majority of OCSP implementors
    possess this competency.  11 of 12 client-side
    implementors reported no breakage with
    "MUST reject" while 10 of 12 server-side
    implementors responded likewise.

4.  The two server-side breakage points occur
    as a consequence of their use of pre-produced
    responses in a context where they have no
    administrative control over clients' use of
    nonces.  This can be addressed in v2, but in
    a v1 context we have no choice but to clarify
    original intent as ratified by the breakage poll.
    This breakage could also be relieved by relay
    of OCSP requests.

5.  The absence of normative language providing a
    tutorial on the proper use of nonces in a
    security protocol SHOULD NOT be taken up by
    any participant in this WG as an excuse to
    refute sound security principles.  Active
    participants in the Security Area of the IETF
    should be able to assume of their peers a
    superior grasp of and respect for foundational
    principles.

Objections to the "MUST reject" clarification are sought on the
basis of sound security engineering principles rather than
artful readings of ancillary language that enable specious
excuse from adherence to these principles in order to justify
current business models.

We are setting standards that must survive the test of time.  We
are supposed to check our corporate identities at the door.  We
are supposed to be individual engineers chartered to improve
Internet security.  Let us do so and get this problem solved.

My thanks to you all in advance for your patience with the
length of this note.


Mike





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQK2Uib041331 for <[e-mail]>; Wed, 26 Nov 2003 12:02:30 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQK2UGu041330 for ietf-pkix-bks; Wed, 26 Nov 2003 12:02:30 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQK2Sib041323 for <[e-mail]>; Wed, 26 Nov 2003 12:02:28 -0800 (PST) (envelope-from [e-mail])
Received: from MMyersLapTop ([65.39.77.99]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id hAQK2UA79456; Wed, 26 Nov 2003 13:02:30 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: <[e-mail]>
Cc: "Carlisle Adams" <[e-mail]>
Subject: DISCUSS:  MUST  reject in OCSPv1
Date: Wed, 26 Nov 2003 13:04:42 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1106
In-Reply-To: <p06010205bbea7029f2b0@[128.89.89.75]>
Importance: Normal
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>

Colleagues,

I recently proposed to the chairs and the AD the following
action plan with respect to nonces in OCSP.  They in turn remain
curious as to working group consensus on the subject with a
particular emphasis on objections.  I had hoped for an ad-hoc
quorum on this in Minneapolis but it never materialized due to
the absence of several key players.

So, once more into the breach.  Who would object and why to the
following action plan (silence WILL be taken as consent):

1.  Regarding v1, clarify per the minutes as
    2560 goes from Proposed to Draft.  The
    operative text of which is that clients
    MUST reject a response that fails to
    incorporate a client's nonce.

2.  Simultaneously, initiate action on a v2
    I-D that will in part address technical
    changes in syntax and processing rules
    related to the use of nonces.

This is not a poll.  It is a request for discussion.  I expect
little disagreement on the intent of the v2 action item. The
core issue on v1 is "MUST reject".

To initiate the v1 discussion, my opinions are as follows.

1.  Nonces were established in OCSP to enable
    client driven prevention of replay attacks.
    Failure to respect a client's nonce is a
    direct denial of a client's request for
    this security service.  A responder that
    does so is contributing to the very security
    risks the requestor is seeking to mitigate.

2.  While 2560 also enables use of pre-produced
    responses, nonces and pre-produced responses
    are by definition mutually exclusive.  This
    effect should be immediately obvious to even
    the most naive of implementors, else they have
    no business writing code against this standard.
    A competent level of technical proficiency
    in implementing secure protocols is assumed.

3.  The "breakage" poll indicates that an
    overwhelming majority of OCSP implementors
    possess this competency.  11 of 12 client-side
    implementors reported no breakage with
    "MUST reject" while 10 of 12 server-side
    implementors responded likewise.

4.  The two server-side breakage points occur
    as a consequence of their use of pre-produced
    responses in a context where they have no
    administrative control over clients' use of
    nonces.  This can be addressed in v2, but in
    a v1 context we have no choice but to clarify
    original intent as ratified by the breakage poll.
    This breakage could also be relieved by relay
    of OCSP requests.

5.  The absence of normative language providing a
    tutorial on the proper use of nonces in a
    security protocol SHOULD NOT be taken up by
    any participant in this WG as an excuse to
    refute sound security principles.  Active
    participants in the Security Area of the IETF
    should be able to assume of their peers a
    superior grasp of and respect for foundational
    principles.

Objections to the "MUST reject" clarification are sought on the
basis of sound security engineering principles rather than
artful readings of ancillary language that enable specious
excuse from adherence to these principles in order to justify
current business models.

We are setting standards that must survive the test of time.  We
are supposed to check our corporate identities at the door.  We
are supposed to be individual engineers chartered to improve
Internet security.  Let us do so and get this problem solved.

My thanks to you all in advance for your patience with the
length of this note.


Mike




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQJpPib040669 for <[e-mail]>; Wed, 26 Nov 2003 11:51:25 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQJpPwG040668 for ietf-pkix-bks; Wed, 26 Nov 2003 11:51:25 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp2.mivlmd.cablespeed.com (smtp2.mivlmd.cablespeed.com [24.35.0.19]) by above.proper.com (8.12.10/8.12.8) with SMTP id hAQJpNib040663 for <[e-mail]>; Wed, 26 Nov 2003 11:51:24 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 3922 invoked by uid 0); 26 Nov 2003 19:50:52 -0000
Received: from unknown (HELO cablespeed.com) (24.35.57.71) by 0 with SMTP; 26 Nov 2003 19:50:52 -0000
Message-ID: <[e-mail]>
Date: Wed, 26 Nov 2003 14:53:01 -0500
From: jim <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Anders Rundgren <[e-mail]>
CC: Stephen Kent <[e-mail]>, [e-mail], [e-mail]
Subject: Re: Straw poll: An advice to a commercial CA
References: <01fc01c3b366$8707d760$[e-mail]> <002601c3b3fc$1d25e8a0$0500a8c0@arport> <p06010203bbea6ed9a3e9@[128.89.89.75]> <006601c3b44f$66f98330$0500a8c0@arport>
Content-Type: multipart/alternative; boundary="------------060903070805070703020909"
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>

--------------060903070805070703020909
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Expensive preferred with mostly multiple is what we hear from our 
potential customer database
Jim Heimberg, ABC, Ph.D.
Secure Course
www.securecourse.com

Anders Rundgren wrote:

>Well,
>Since the list is close to "vibrant" with emotions, why not
>put RFC3280 through the litmus test?
>
>Assume that you as PKI professionals would advice a commercial
>TTP CA on how to configure their issuance for the following:
>1. Free e-mail roundtrip-verification certficates.  Low insurance level
>2. Expensive (high insurance level) multi-usage certificates for individuals
>using strong verification procedures.
>
>Note: the service is to be launched ASAP and has the only
>objective, making money by serving its subscribers well.
>
>Indicate your advice by the word in uppercase.
>
>SINGLE: A single root + possibly some CP OIDs to spice things up
>MULTIPLE: Different roots
>
>Lets rock!
>
>/a
>
>----- Original Message ----- 
>From: "Stephen Kent" <[e-mail]>
>To: "Anders Rundgren" <[e-mail]>
>Cc: <[e-mail]>
>Sent: Wednesday, November 26, 2003 15:55
>Subject: Re: Certificate Policy Standardization
>
>
>
>At 10:03 +0100 11/26/03, Anders Rundgren wrote:
>  
>
>> >I am not what you mean by ".....another useless PKIX bloat extension".
>>
>>    
>>
>>>If properly used by the CA and relying party systems, the certificate policy
>>>OID can be used to provide amount of trust the relying party should place in
>>>a certificate.
>>>      
>>>
>>What Michael referred to as "bloat" is not policy identifiers themselves
>>but that they need another trust adminstration GUI and associated hassles.
>>
>>Policy identifiers used for path validation purposes is indeed a
>>very "fancy" thing from a technical point of view (maybe 2% of the
>>people subscribed to the PKIX list can understand this part of
>>RFC3280...), but from an interoperability point of view they are
>>not that great.
>>
>>Hum, there simply must be a reason why practically all commercial
>>CAs have selected an entirely different approach.  And that they did
>>this completely on their own without any commitee descision etc.
>>
>>I wonder how this really happend.   Could it be...
>>
>>    that it sort of feels "natural"?
>>
>>/a
>>    
>>
>
>could it be because some of them are clueless, as evidenced by 
>Peter's collection of non-compliant certs issued by these folks?
>
>could it be because these CAs like to create their own closed 
>communities to maintain market share?
>
>there are lots of good reasons for a CA to not use a feature in the 
>standards, a few good reasons to choose another way to achieve the 
>same effect, and lots of bad reasons to choose another way ...
>
>
>Steve
>
>
>
>  
>


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

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body>
Expensive preferred with mostly multiple is what we hear from our potential
customer database<br>
Jim Heimberg, ABC, Ph.D.<br>
<b>Secure Course</b><br>
<a class="moz-txt-link-abbreviated" href="http://www.securecourse.com">www.securecourse.com</a><br>
<br>
Anders Rundgren wrote:<br>
<blockquote type="cite" cite="mid006601c3b44f$66f98330$0500a8c0@arport">
  <pre wrap="">Well,
Since the list is close to "vibrant" with emotions, why not
put RFC3280 through the litmus test?

Assume that you as PKI professionals would advice a commercial
TTP CA on how to configure their issuance for the following:
1. Free e-mail roundtrip-verification certficates.  Low insurance level
2. Expensive (high insurance level) multi-usage certificates for individuals
using strong verification procedures.

Note: the service is to be launched ASAP and has the only
objective, making money by serving its subscribers well.

Indicate your advice by the word in uppercase.

SINGLE: A single root + possibly some CP OIDs to spice things up
MULTIPLE: Different roots

Lets rock!

/a

----- Original Message ----- 
From: "Stephen Kent" <a class="moz-txt-link-rfc2396E" href="mailto:[e-mail]">&lt;[e-mail]&gt;</a>
To: "Anders Rundgren" <a class="moz-txt-link-rfc2396E" href="mailto:[e-mail]">&lt;[e-mail]&gt;</a>
Cc: <a class="moz-txt-link-rfc2396E" href="mailto:[e-mail]">&lt;[e-mail]&gt;</a>
Sent: Wednesday, November 26, 2003 15:55
Subject: Re: Certificate Policy Standardization



At 10:03 +0100 11/26/03, Anders Rundgren wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap=""> &gt;I am not what you mean by ".....another useless PKIX bloat extension".

    </pre>
    <blockquote type="cite">
      <pre wrap="">If properly used by the CA and relying party systems, the certificate policy
OID can be used to provide amount of trust the relying party should place in
a certificate.
      </pre>
    </blockquote>
    <pre wrap="">What Michael referred to as "bloat" is not policy identifiers themselves
but that they need another trust adminstration GUI and associated hassles.

Policy identifiers used for path validation purposes is indeed a
very "fancy" thing from a technical point of view (maybe 2% of the
people subscribed to the PKIX list can understand this part of
RFC3280...), but from an interoperability point of view they are
not that great.

Hum, there simply must be a reason why practically all commercial
CAs have selected an entirely different approach.  And that they did
this completely on their own without any commitee descision etc.

I wonder how this really happend.   Could it be...

    that it sort of feels "natural"?

/a
    </pre>
  </blockquote>
  <pre wrap=""><!---->
could it be because some of them are clueless, as evidenced by 
Peter's collection of non-compliant certs issued by these folks?

could it be because these CAs like to create their own closed 
communities to maintain market share?

there are lots of good reasons for a CA to not use a feature in the 
standards, a few good reasons to choose another way to achieve the 
same effect, and lots of bad reasons to choose another way ...


Steve



  </pre>
</blockquote>
<br>
</body>
</html>

--------------060903070805070703020909--




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQJ3Iib038728 for <[e-mail]>; Wed, 26 Nov 2003 11:03:18 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQJ3IdY038727 for ietf-pkix-bks; Wed, 26 Nov 2003 11:03:18 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp4.hy.skanova.net (smtp4.hy.skanova.net [195.67.199.133]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQJ3Hib038722 for <[e-mail]>; Wed, 26 Nov 2003 11:03:17 -0800 (PST) (envelope-from [e-mail])
Received: from arport (t12o913p85.telia.com [213.64.28.205]) by smtp4.hy.skanova.net (8.12.10/8.12.10) with SMTP id hAQJ39BZ023375; Wed, 26 Nov 2003 20:03:10 +0100 (CET)
Message-ID: <006601c3b44f$66f98330$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Stephen Kent" <[e-mail]>
Cc: <[e-mail]>
References: <01fc01c3b366$8707d760$[e-mail]> <002601c3b3fc$1d25e8a0$0500a8c0@arport> <p06010203bbea6ed9a3e9@[128.89.89.75]>
Subject: Straw poll: An advice to a commercial CA
Date: Wed, 26 Nov 2003 19:59:20 +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>

Well,
Since the list is close to "vibrant" with emotions, why not
put RFC3280 through the litmus test?

Assume that you as PKI professionals would advice a commercial
TTP CA on how to configure their issuance for the following:
1. Free e-mail roundtrip-verification certficates.  Low insurance level
2. Expensive (high insurance level) multi-usage certificates for individuals
using strong verification procedures.

Note: the service is to be launched ASAP and has the only
objective, making money by serving its subscribers well.

Indicate your advice by the word in uppercase.

SINGLE: A single root + possibly some CP OIDs to spice things up
MULTIPLE: Different roots

Lets rock!

/a

----- Original Message ----- 
From: "Stephen Kent" <[e-mail]>
To: "Anders Rundgren" <[e-mail]>
Cc: <[e-mail]>
Sent: Wednesday, November 26, 2003 15:55
Subject: Re: Certificate Policy Standardization



At 10:03 +0100 11/26/03, Anders Rundgren wrote:
>  >I am not what you mean by ".....another useless PKIX bloat extension".
>
>>If properly used by the CA and relying party systems, the certificate policy
>>OID can be used to provide amount of trust the relying party should place in
>>a certificate.
>
>What Michael referred to as "bloat" is not policy identifiers themselves
>but that they need another trust adminstration GUI and associated hassles.
>
>Policy identifiers used for path validation purposes is indeed a
>very "fancy" thing from a technical point of view (maybe 2% of the
>people subscribed to the PKIX list can understand this part of
>RFC3280...), but from an interoperability point of view they are
>not that great.
>
>Hum, there simply must be a reason why practically all commercial
>CAs have selected an entirely different approach.  And that they did
>this completely on their own without any commitee descision etc.
>
>I wonder how this really happend.   Could it be...
>
>     that it sort of feels "natural"?
>
>/a

could it be because some of them are clueless, as evidenced by 
Peter's collection of non-compliant certs issued by these folks?

could it be because these CAs like to create their own closed 
communities to maintain market share?

there are lots of good reasons for a CA to not use a feature in the 
standards, a few good reasons to choose another way to achieve the 
same effect, and lots of bad reasons to choose another way ...


Steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQIb4ib036964 for <[e-mail]>; Wed, 26 Nov 2003 10:37:04 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQIb4Zi036963 for ietf-pkix-bks; Wed, 26 Nov 2003 10:37:04 -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.10/8.12.8) with ESMTP id hAQIb3ib036955 for <[e-mail]>; Wed, 26 Nov 2003 10:37:03 -0800 (PST) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id hAQIatsj000610; Wed, 26 Nov 2003 13:36:55 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p06010213bbea9f5500f7@[128.89.89.75]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Wed, 26 Nov 2003 13:35:42 -0500
To: [e-mail] (Peter Gutmann)
From: Stephen Kent <[e-mail]>
Subject: Re: Certificate Policy Standardization
Cc: [e-mail], [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
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,

Citing the critique from the Counterpane analysis of Ipsec and IKE 
from 5 years ago is a nice touch, but you should be aware that the 
non-IKE criticisms were largely refuted in messages on the IPsec 
list. Or, were you aware of that and did you simply choose to not 
share that part of the history with this list?

Unfortunately, the folks who performed the analysis were not protocol 
experts. They made assertions of what was wrong and how it should be 
fixed, and in most instances THEY were wrong. So, in this case, what 
we had were crypto experts offering protocol criticisms that they 
were not qualified to make. I hesitate to use the term "dummies" 
here, but its not all that far off, relative to the expertise that 
one should possess to be a good implementor.  In fact we had a repeat 
of this sort of argument in the last 12 months, when a capable 
cryptographer argued about how to use counter mode in IPsec, but 
without benefit of a deep understanding of assurance issues, FIPS 140 
evaluation, etc. Here too the non-dummy was just wrong in this 
context.

Sorry to spoil you rejoinder, but the facts don't support your 
position, and the cited text is just an example of smart folks who 
are not experts in the area in question getting it wrong.

Steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQIVPib036724 for <[e-mail]>; Wed, 26 Nov 2003 10:31:25 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQIVPnF036723 for ietf-pkix-bks; Wed, 26 Nov 2003 10:31:25 -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.10/8.12.8) with ESMTP id hAQIVNib036718 for <[e-mail]>; Wed, 26 Nov 2003 10:31:24 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (127.0.0.1) by nic.lp.se (MX V5.3 VnHj) with ESMTP; Wed, 26 Nov 2003 19:31:03 +0100
Date: Wed, 26 Nov 2003 19:31:01 +0100 (CET)
Message-ID: <[e-mail]>
To: [e-mail]
CC: [e-mail], [e-mail], [e-mail]
Subject: Re: Certificate Policy Standardization
From: Richard Levitte - VMS Whacker <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
X-URL: http://www.lp.se/
X-Waved: dead chicken, GNU emacs 21.3.1, Mew version 4.0.60
X-Mew: See http://www.mew.org/
X-Mailer: Mew version 4.0.60 on Emacs 21.3.1 / 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>

Peter has an xecellent point here.  I'm all in favor of "The rationale
behind this is..." a little here and there in some RFCs...

In message <[e-mail]> on Thu, 27 Nov 2003 05:59:48 +1300, [e-mail] (Peter Gutmann) said:

pgut001> Actually what I learn from this is that complex standards
pgut001> with often incomprehensible requirements are just asking for
pgut001> trouble if they don't include a rationale.  Even a single
pgut001> sentence explaining the background behind the SPD entry
pgut001> ordering would have prevented this in a manner that no amount
pgut001> of MUSTs/SHALLs ever can.

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.
You don't have to be rich, a $10 donation is appreciated!

-- 
Richard Levitte     | http://richard.levitte.org/ | Tunnlandsv. 3
Levitte Programming | http://www.lp.se/           | S-168 36 Bromma
T: [phone] |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQIBeib035761 for <[e-mail]>; Wed, 26 Nov 2003 10:11:40 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQIBeHC035760 for ietf-pkix-bks; Wed, 26 Nov 2003 10:11:40 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.cs.auckland.ac.nz (csmail.cs.auckland.ac.nz [130.216.33.150]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQIBcib035752 for <[e-mail]>; Wed, 26 Nov 2003 10:11:38 -0800 (PST) (envelope-from [e-mail])
Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id 45A3C63C1D; Thu, 27 Nov 2003 07:11:37 +1300 (NZDT)
Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id hAQIEA202922; Thu, 27 Nov 2003 07:14:10 +1300
Date: Thu, 27 Nov 2003 07:14:10 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Certificate Policy Standardization
Cc: [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>

Stephen Kent <[e-mail]> writes:

>Implementors of a technology ought (MUST/SHALL?) be competent in the
>technology that they are implementing. A standard like IPsec is not a "Secure
>Communication  Protocols for Dummies" document.

  The first thing one notices when looking at IPsec is that the documentation
  is very hard to understand. There is no overview or introduction, the reader
  has to assemble all the pieces and build an overview himself. This is a
  highly unsatisfactorily state of affairs; after all, the documentation is
  meant to convey information to the readers. We do not believe it is
  reasonable to expect anyone to learn IPsec from the IPsec documentation.
  Various parts of the IPsec documentation are very hard to read. For ex-
  ample, the ISAKMP specifications [MSST98] contain numerous errors, essential
  explanations are missing, and the document contradicts itself in various
  places.

  [...]
  
  None of the IPsec documentation provides any rationale for any of the
  choices that were made. Although this is somewhat less important than a
  clear statement of the goals, we nevertheless consider it crucial
  information. If a reviewer is to comment on the design (and RFCs are, after
  all, Requests For Comments), he should be told what each option was intended
  to achieve. Without any rationale, the reviewer is left to guess at it, and
  then review the design based on the guessed-at rationale.

  [...]
  
  In our opinion, IPsec is too complex to be secure. The design obviously
  tries to support many different situations with different options. We feel
  very strongly that the resulting system is well beyond the level of
  complexity that can be analysed or properly implemented with current method-
  ologies. Thus, no IPsec system will achieve the goal of providing a high
  level of security.

  [...]

  It is far too complex, and the complexity has lead to a large number of
  ambiguities, contradictions, inefficiencies, and weaknesses. It has been
  very hard work to perform any kind of security analysis; we do not feel that
  we fully understand the system, let alone have fully analyzed it.

Obviously non-dummies can't make much sense of it either.

Peter.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQHbnib034140 for <[e-mail]>; Wed, 26 Nov 2003 09:37:49 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQHbmO8034139 for ietf-pkix-bks; Wed, 26 Nov 2003 09:37:48 -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.10/8.12.8) with ESMTP id hAQHblib034129 for <[e-mail]>; Wed, 26 Nov 2003 09:37:47 -0800 (PST) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id hAQHbesj027338; Wed, 26 Nov 2003 12:37:41 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p06010210bbea90868896@[128.89.89.75]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Wed, 26 Nov 2003 12:33:48 -0500
To: [e-mail] (Peter Gutmann)
From: Stephen Kent <[e-mail]>
Subject: Re: Certificate Policy Standardization
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
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 5:59 +1300 11/27/03, Peter Gutmann wrote:
>Stephen Kent <[e-mail]> writes:
>
>>one might ask why the most widely distributed product that claims to
>>implement IPsec  (Windows) does not provide a user/administrator the ability
>>to order SPD entries, as required by RFC 2401. The answer is that the
>>implementors did not understand why this was an important (in the case of
>>IPsec, a critical) aspect of the standard and so the implementors omitted an
>>important management control.
>>
>>what one can learn from this an similar examples is that vendors are a very
>>poor basis for determining the worth of a feature in a standard.
>
>Actually what I learn from this is that complex standards with often
>incomprehensible requirements are just asking for trouble if they don't
>include a rationale.  Even a single sentence explaining the background behind
>the SPD entry ordering would have prevented this in a manner that no amount of
>MUSTs/SHALLs ever can.
>
>Peter.

The SPD is an ordered list for the same reason that ACLs have been 
ordered in operating systems for last 30 years, and in firewalls and 
routers for the last decade.  At what point does one not have to 
provide rationale?

Implementors of a technology ought (MUST/SHALL?) be competent in the 
technology that they are implementing. A standard like IPsec is not a 
"Secure Communication  Protocols for Dummies" document.

Steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQHTOib033804 for <[e-mail]>; Wed, 26 Nov 2003 09:29:24 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQHTO9E033803 for ietf-pkix-bks; Wed, 26 Nov 2003 09:29:24 -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.10/8.12.8) with ESMTP id hAQHTNib033796 for <[e-mail]>; Wed, 26 Nov 2003 09:29:23 -0800 (PST) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Wed, 26 Nov 2003 12:29:18 -0500
From: "David P. Kemp" <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Certificate Policy Standardization
References: <[e-mail]>            <[e-mail]>            <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
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>

Michael,

Do you believe any problems are solved by labeling of gasoline octane? 
The issuer of the gasoline advertises that it meets a certain technical 
specification, and each relying party decides what octane is required in 
his particular automobile.

With regard to granularity, some years ago there was a "Sunoco Custom 
Blending Pump" where you could dial up the exact quality of gasoline 
desired.  In my opinion, that's overkill - three grades is plenty. 
(Don't mention the different combinations of additives, which may vary 
by season, required by each of the 50 US states.  If any area cried out 
for policy standardization and granularity reduction, that is it.)

Three, coincidentally, is approximately the number of certificate 
policies actually used by the Department of Defense PKI.  Any number 
greater than two and less than six is a good number :-).

Dave



Michael Ströder wrote:

> Personally I'm not aware of any problems solved with the help of policy 
> OIDs. ;-) Maybe others on this list feel more enlightened.




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQGxOib031953 for <[e-mail]>; Wed, 26 Nov 2003 08:59:24 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQGxOlp031952 for ietf-pkix-bks; Wed, 26 Nov 2003 08:59:24 -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.10/8.12.8) with ESMTP id hAQGxNib031946 for <[e-mail]>; Wed, 26 Nov 2003 08:59:23 -0800 (PST) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Wed, 26 Nov 2003 11:59:18 -0500
From: "David P. Kemp" <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
CC: [e-mail]
Subject: Re: Web-PKI Keygen/Certreq Questions
References: <00e101c39fc2$a59fa200$3a1b40d5@arport> <p06002003bbc83730f4f9@[128.89.89.75]> <[e-mail]> <p0600200bbbc8676a42ac@[128.89.89.75]> <006b01c3ad13$d7ddff60$0500a8c0@arport>
In-Reply-To: <006b01c3ad13$d7ddff60$0500a8c0@arport>
Content-Type: text/plain; charset=us-ascii; 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>

Hopefully the consortium is planning to construct its solution by 
profiling: a) attributes to be included in RFC 2797 messages and b) 
transport of those messages over http, rather than inventing something 
from scratch.

Dave



Anders Rundgren wrote:

> Just to set the record straight: Another consortium has indeed
> [also] found the existings keygen/certreq mechanisms largely
> inferior and will publish a draft solution in a couple of months
> or so.  I just talked to one of the architects, and he confirmed that
> it will support the kind of stuff that most of the proprietary solutions
> already do, such as key-container co-signing, passphrase policy
> control, and multi-key generation.
> 
> /a
> 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQGvFib031847 for <[e-mail]>; Wed, 26 Nov 2003 08:57:15 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQGvFPk031846 for ietf-pkix-bks; Wed, 26 Nov 2003 08:57:15 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.cs.auckland.ac.nz (csmail.cs.auckland.ac.nz [130.216.33.150]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQGvEib031841 for <[e-mail]>; Wed, 26 Nov 2003 08:57:14 -0800 (PST) (envelope-from [e-mail])
Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id 5930863C1D; Thu, 27 Nov 2003 05:57:15 +1300 (NZDT)
Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id hAQGxm001648; Thu, 27 Nov 2003 05:59:48 +1300
Date: Thu, 27 Nov 2003 05:59:48 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Certificate Policy Standardization
Cc: [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>

Stephen Kent <[e-mail]> writes:

>one might ask why the most widely distributed product that claims to
>implement IPsec  (Windows) does not provide a user/administrator the ability
>to order SPD entries, as required by RFC 2401. The answer is that the
>implementors did not understand why this was an important (in the case of
>IPsec, a critical) aspect of the standard and so the implementors omitted an
>important management control.
>
>what one can learn from this an similar examples is that vendors are a very
>poor basis for determining the worth of a feature in a standard. 

Actually what I learn from this is that complex standards with often
incomprehensible requirements are just asking for trouble if they don't
include a rationale.  Even a single sentence explaining the background behind
the SPD entry ordering would have prevented this in a manner that no amount of
MUSTs/SHALLs ever can.

Peter.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQGj9ib031373 for <[e-mail]>; Wed, 26 Nov 2003 08:45:09 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQGj9i0031372 for ietf-pkix-bks; Wed, 26 Nov 2003 08:45:09 -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.10/8.12.8) with ESMTP id hAQGj7ib031367 for <[e-mail]>; Wed, 26 Nov 2003 08:45:07 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (127.0.0.1) by nic.lp.se (MX V5.3 VnHj) with ESMTP; Wed, 26 Nov 2003 17:44:59 +0100
Date: Wed, 26 Nov 2003 17:44:58 +0100 (CET)
Message-ID: <[e-mail]>
To: [e-mail]
CC: [e-mail], [e-mail]
Subject: Re: Certificate Policy Standardization
From: Richard Levitte - VMS Whacker <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
X-URL: http://www.lp.se/
X-Waved: dead chicken, GNU emacs 21.3.1, Mew version 4.0.60
X-Mew: See http://www.mew.org/
X-Mailer: Mew version 4.0.60 on Emacs 21.3.1 / 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 Thu, 27 Nov 2003 04:13:30 +1300, [e-mail] (Peter Gutmann) said:

pgut001> "Anders Rundgren" <[e-mail]> writes:
pgut001> 
pgut001> >1. Why does practically no shrink-wrap PKI-enabled software package support
pgut001> >any kind of certificate policy settings?
pgut001> 
pgut001> Zero demand.  Heck, it wasn't too long ago that MS PKI
pgut001> software hardcoded the Verisign policy into CryptoAPI, so
pgut001> that no matter what the actual policy was in the cert, what
pgut001> was displayed was the Verisign policy.  That shows how much
pgut001> attention people are paying to the policy stuff.

Let's take note of what Peter says here.  First, M$ did some
hardcoding, which they have subsequently changed (I got that right, I
hope).  That means M$ is capable of change, and does listen to some
concerns.  Sure, that's pretty slow development, but development
still.  A bunch more times with a LART, and even M$ might do policy
checks :-).

pgut001> ...  So the trusted-roots mechanism does what the policy
pgut001> extension is supposed to do,

Which only works as long as the formula CA<=>Policy is true...

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.
You don't have to be rich, a $10 donation is appreciated!

-- 
Richard Levitte     | http://richard.levitte.org/ | Tunnlandsv. 3
Levitte Programming | http://www.lp.se/           | S-168 36 Bromma
T: [phone] |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQGbgib031044 for <[e-mail]>; Wed, 26 Nov 2003 08:37:42 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQGbg98031043 for ietf-pkix-bks; Wed, 26 Nov 2003 08:37:42 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp4.hy.skanova.net (smtp4.hy.skanova.net [195.67.199.133]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQGbfib031037 for <[e-mail]>; Wed, 26 Nov 2003 08:37:41 -0800 (PST) (envelope-from [e-mail])
Received: from arport (t12o913p94.telia.com [213.64.28.214]) by smtp4.hy.skanova.net (8.12.10/8.12.10) with SMTP id hAQGbaBZ001358; Wed, 26 Nov 2003 17:37:37 +0100 (CET)
Message-ID: <032b01c3b43b$1306d1b0$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Peter Gutmann" <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: Certificate Policy Standardization
Date: Wed, 26 Nov 2003 17:33:49 +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>

<snip>

>That doesn't mean that RPs don't use a policy-equivalent: The software is
>configured - via trusted roots - to only accept certs from a given set of CAs
>(Anders, that's the policy-configurability you asked for, it's just not called
>that). 

Peter, this is basically what I call de-facto standard.  I.e.

                     CA <==> Policy

>So the trusted-roots mechanism does what the policy extension is
>supposed to do,

Here we approach the core issue.

The problem is that it is fully RCFxxxx-complient to issue
any number of technically- or legally-wise different certificates
(with or without embedded policy OIDs) under a given CA root.

That means, that using [most] existing RP software, you may end-up
"trusting" or processing things that you maybe _did_not_intend_to.
I.e. here we have a standards-sanctioned SECURITY HOLE and a
blatant INTEROPERABILITY DEFICIENCY of great magnitude.

How come this has never been addressed?
Because most PKIs are local and then it is an in-house issue.

The (non in-house) commercial CA sector have since years back
opted not to exploit a feature (multiple issuances/root) that:
- Is legally dangerous (much higher risk)
- Is technically not supported by applications
- Is hard to understand
- Does not solves a single _important_ problem
(that multiple CA keys would be a "problem" is simply ridiculous,
for whom would it be a problem?  Is policy OID config (if there
really was one....) "easier" than installing a root-key?

<snip>

>This is an almost complete inversion of
>what RFC 3280 thinks that the policy extension is meant for:

>  Applications with specific policy requirements are expected to have a list
>  of those policies which they will accept and to compare the policy OIDs in
>  the certificate to that list.

Yes, and I believe all this should be reflected in a MAJOR update of RFC3280.
Not that I expect this to happen.  We'd better cling to the time-proven de-facto
methods, and continue to ignore standards that are not updated in spite of
having huge problems and close to zero acceptance in some very vital areas.

Anders


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQFljib028354 for <[e-mail]>; Wed, 26 Nov 2003 07:47:45 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQFljHg028353 for ietf-pkix-bks; Wed, 26 Nov 2003 07:47:45 -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.10/8.12.8) with ESMTP id hAQFlhib028344 for <[e-mail]>; Wed, 26 Nov 2003 07:47:44 -0800 (PST) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id hAQFlbsj019532; Wed, 26 Nov 2003 10:47:37 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p06010209bbea7aca706d@[128.89.89.75]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Wed, 26 Nov 2003 10:44:51 -0500
To: [e-mail] (Peter Gutmann)
From: Stephen Kent <[e-mail]>
Subject: Re: Certificate Policy Standardization
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
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 4:42 +1300 11/27/03, Peter Gutmann wrote:
>Stephen Kent <[e-mail]> writes:
>
>>For example, most certs used with IKE will not be subject to some attorney's
>>advice, I suspect.
>
>Actually now that you mention it one of the three classes of certs that were
>going to be used in the situation I mentioned were IKE certs.  I think they
>were going to subclass "doWhatISay" into "doWhatISayWithIKE",
>"doWhatISayWithSSL", and "doWhatISayWithSMIMESigning"(not sure about the last
>one, I have the paperwork downstairs but I'm too lazy to look it up).  All of
>them were going to go through the full legal wringer.
>
>Peter.

Well, if people want to be masochistic I can't stop them :-)

Steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQFdYib027926 for <[e-mail]>; Wed, 26 Nov 2003 07:39:34 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQFdYCA027925 for ietf-pkix-bks; Wed, 26 Nov 2003 07:39:34 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.cs.auckland.ac.nz (csmail.cs.auckland.ac.nz [130.216.33.150]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQFdWib027920 for <[e-mail]>; Wed, 26 Nov 2003 07:39:33 -0800 (PST) (envelope-from [e-mail])
Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id 8818063C1D; Thu, 27 Nov 2003 04:39:33 +1300 (NZDT)
Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id hAQFg5L01342; Thu, 27 Nov 2003 04:42:05 +1300
Date: Thu, 27 Nov 2003 04:42:05 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Certificate Policy Standardization
Cc: [e-mail], [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>

Stephen Kent <[e-mail]> writes:

>For example, most certs used with IKE will not be subject to some attorney's
>advice, I suspect.

Actually now that you mention it one of the three classes of certs that were
going to be used in the situation I mentioned were IKE certs.  I think they
were going to subclass "doWhatISay" into "doWhatISayWithIKE",
"doWhatISayWithSSL", and "doWhatISayWithSMIMESigning"(not sure about the last
one, I have the paperwork downstairs but I'm too lazy to look it up).  All of
them were going to go through the full legal wringer.

Peter.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQFZ3ib027684 for <[e-mail]>; Wed, 26 Nov 2003 07:35:03 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQFZ31R027683 for ietf-pkix-bks; Wed, 26 Nov 2003 07:35:03 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail4.consignia.com (mail4.consignia.com [144.87.143.84]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQFZ2ib027677 for <[e-mail]>; Wed, 26 Nov 2003 07:35:03 -0800 (PST) (envelope-from [e-mail])
Received: from postoffice.co.uk (mta2.int.consignia.com [144.87.146.16]) by mail4.consignia.com (Postfix) with SMTP id 724821221FE; Wed, 26 Nov 2003 15:35:03 +0000 (GMT)
Received: by postoffice.co.uk(Lotus SMTP MTA v4.6.6  (890.1 7-16-1999))  id 00256DEA.00559D17 ; Wed, 26 Nov 2003 15:35:07 +0000
X-Lotus-FromDomain: POSTOFFICE
From: [e-mail]
To: "Anders Rundgren" <[e-mail]>
Cc: [e-mail]
Message-ID: <[e-mail]>
Date: Wed, 26 Nov 2003 15:34:52 +0000
Subject: Re: Certificate Policy Standardization
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
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>

> 1. Why does practically no shrink-wrap PKI-enabled software
> package support any kind of certificate policy settings?

My experiences with so far 4 different PKI 'systems' are that
all of them could implement CP but only one did so out-of-the-box.
I feel very strongly that the vanilla deployment is one
that supports a homogeneous environment and does not take into
account interop with other PKIs. This is likely to be caused
by a number of factors including a desire to steer the end
user away from competitors, saving money in deploying unrequired
features and keeping the vanilla deployment as simple as possible
(if that is possible with PKI!!!). Given the current lack of
support for CP it does not surprise me that it is not part of
the vanilla deployment.

> 2. And why do few if any commercial CAs support multiple
> issuances (i.e. different CPs) per CA root?

Differentiate between 'cannot' and 'do not'. I would be very
surprised if they all cannot but I am not surprised that they
all do not (if that makes sense). Application of CP is, as you
have already said, a function of RP s/w. Commercial CAs issue
certificates to anyone who wants them yet CP is function of
local, company policy. Why should a commercial CA issue certs
with my CP in them (unless I pay them to do so)? As I see it,
at present a commercial CA will issue a CP which says no more
than 'this is my CP'. Third party s/w has no reason to enforce
this CP because it is private to the CA. When apps become
more security aware I will expect to see them enforce CP issued
from the corporate CA or from other Xcert CAs mapped through
policyMap.

Don't ask me when this will happen, though :-)

Chris




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQFXXib027570 for <[e-mail]>; Wed, 26 Nov 2003 07:33:33 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQFXXdQ027569 for ietf-pkix-bks; Wed, 26 Nov 2003 07:33:33 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.cs.auckland.ac.nz (csmail.cs.auckland.ac.nz [130.216.33.150]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQFXVib027563 for <[e-mail]>; Wed, 26 Nov 2003 07:33:32 -0800 (PST) (envelope-from [e-mail])
Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id 80B7463C1D; Thu, 27 Nov 2003 04:33:32 +1300 (NZDT)
Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id hAQFa4Y01319; Thu, 27 Nov 2003 04:36:04 +1300
Date: Thu, 27 Nov 2003 04:36:04 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Certificate Policy Standardization
Cc: [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>

Andreas Mitrakas <[e-mail]> writes:

>Especially so in some implementations in Europe where there is a direct link
>between the policy and the law under which certain certs like QC certs are
>issued.

The feeling was that digital signature legislation (following the UNCITRAL
model) is so vaguely worded that this wouldn't be a problem.  Qualified certs
are a bit more problematic, but that's only in Europe.

>A CP becomes part of the parties agreement and binding by means of e.g. a
>subscriber agreement. So it is not unthinkable albeit not necessarily
>desirable, that a courts might  scrutinise policies. --God forbid.

The feeling here was that a ToS-style policy might violate (at least NZ)
consumer protection legislation, however since a number of large organisations
relied on these types of agreements there would probably be a spirited defence
of them in court and/or existing case law upholding them.  See e.g Xtra
(Telecom NZ ISP) terms, which state:

  12. Changes to these Customer Terms

  We may change these Customer Terms by changing or removing existing terms,
  or by adding new ones. Changes may take the form of completely new terms.

  [Notification stuff snipped]

  A copy of our current terms is displayed on our Website. It is your
  responsibility to check these Customer Terms regularly (at least monthly)
  for any modifications or updates. You will be deemed to have accepted the
  changes to these Customer Terms and to have agreed to be bound by the
  revised Customer Terms if you continue to use and/or access the Services
  after the date that the changes are stated to be effective.

  We reserve the right to change any charges or Services, or any Separate
  Terms, at any time without notice. It is your responsibility to check all
  applicable Separate Terms regularly for any modifications or updates.

That's the sort of thing the "policy is what we say it is" that I mentioned
earlier was based on.  Just for reference, here's what Yahoo says:

  Yahoo! provides its service to you, subject to the following Terms of
  Service ("TOS"), which may be updated by us from time to time without notice
  to you. You can review the most current version of the TOS at any time at:
  http://docs.yahoo.com/info/terms/. 
  
  [Snippage]

  Yahoo! reserves the right at any time and from time to time to modify or
  discontinue, temporarily or permanently, the Service (or any part thereof)
  with or without notice. You agree that Yahoo! shall not be liable to you or
  to any third party for any modification, suspension or discontinuance of the
  Service.

The debate then went off on a tangent about whether a PKI was providing a
service of any value to a user (if it doesn't it's not covered by standard
consumer-protection law), and how you'd present that in court.

Disclaimer: IANAL, I just talk to them occasionally.

Peter.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQFDJib026445 for <[e-mail]>; Wed, 26 Nov 2003 07:13:19 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQFDJpE026444 for ietf-pkix-bks; Wed, 26 Nov 2003 07:13:19 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail4.it-norr.com ([80.244.64.43]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQFDHib026437 for <[e-mail]>; Wed, 26 Nov 2003 07:13:17 -0800 (PST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Received: from HANSTOSHIBA ([217.211.59.248]) by mail4.it-norr.com (IT-NORR Mail Cluster v2003) with ASMTP id DUA74354 for <[e-mail]>; Wed, 26 Nov 2003 16:13:15 +0100
From: "Hans Nilsson" <[e-mail]>
To: <[e-mail]>
Subject: RE: Certificate Policy Standardization
Date: Wed, 26 Nov 2003 16:12:53 +0100
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.2800.1165
thread-index: AcO0KecT/TLEeVeFQcqZodb6XFOSFQABQ0Gw
In-Reply-To: <025b01c3b421$683107b0$0500a8c0@arport>
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 know of at least one CA product (SmartTrust Certificate Manager) which can
supports multiple issuance of certs (with different CPs) per CA root.

I know that this feature also is used by several of SmartTrust's customers,
for example for distinguishing between different issuing procedures and/or
private key storage media.

And when talking about Relying Party software, we do not usually mean
Outlook Express. After all, secure e-mail is not the number 1 PKI
application. 
Instead, RPs are usually servers, validating signatures in e-government and
e-banking applications. And RP software (from MS and others) can pick out
any field of a certificate and make a decision based on that.

Hans

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
On
> Behalf Of Anders Rundgren
> Sent: Wednesday, November 26, 2003 2:30 PM
> To: [e-mail]
> Subject: Re: Certificate Policy Standardization
> 
> 
> Hum,
> 
> I wonder how many times I have to repeat the same very basic
> questions and only getting answers back in "ASN.1"?  Sort of.
> So here we go again...
> 
> 1. Why does practically no shrink-wrap PKI-enabled software
> package support any kind of certificate policy settings?
> 
> 2. And why do few if any commercial CAs support multiple
> issuances (i.e. different CPs) per CA root?
> 
> Because they have understood the problems associated?
> Because they enjoy "violating" standards?
> Because they are ignorant?
> Because their budget is too limited?
> Other?
> 
> Anders
> 
> ----- Original Message -----
> From: "Santosh Chokhani" <[e-mail]>
> To: <[e-mail]>
> Sent: Wednesday, November 26, 2003 12:04
> Subject: RE: Certificate Policy Standardization
> 
> 
> 
> Anders:
> 
> The relying parties are free to ignore the policies and policy related
> extensions altogether and verify paths.  The certification path will
verify
> unless:
> 
> 1.  One or more CAs in the path require that the certification path be
valid
> for a policy; or
> 
> 2.  Make the policy related extensions critical.
> 
> While some may view the two conditions as interoperability problem, I view
> it CA(s) saying that I do not want you to use the certificate unless you
> understand and abide by constraints I impose on the certificates.
> 
> The current X.509 and RFC 3280 permit you build PKI and applications that
do
> not use certificate policies.  So, I do not quite understand your concern
> below.
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
On
> Behalf Of Anders Rundgren
> Sent: Wednesday, November 26, 2003 4:03 AM
> To: Santosh Chokhani; [e-mail]
> Subject: Re: Certificate Policy Standardization
> 
> 
> 
> 
> >I am not what you mean by ".....another useless PKIX bloat extension".
> 
> >If properly used by the CA and relying party systems, the certificate
> >policy OID can be used to provide amount of trust the relying party
> >should place in a certificate.
> 
> What Michael referred to as "bloat" is not policy identifiers themselves
but
> that they need another trust adminstration GUI and associated hassles.
> 
> Policy identifiers used for path validation purposes is indeed a very
> "fancy" thing from a technical point of view (maybe 2% of the people
> subscribed to the PKIX list can understand this part of RFC3280...), but
> from an interoperability point of view they are not that great.
> 
> Hum, there simply must be a reason why practically all commercial CAs have
> selected an entirely different approach.  And that they did this
completely
> on their own without any commitee descision etc.
> 
> I wonder how this really happend.   Could it be...
> 
>     that it sort of feels "natural"?
> 
> /a
> 





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQFC7ib026381 for <[e-mail]>; Wed, 26 Nov 2003 07:12:07 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQFC7vJ026380 for ietf-pkix-bks; Wed, 26 Nov 2003 07:12:07 -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.10/8.12.8) with ESMTP id hAQFC5ib026372 for <[e-mail]>; Wed, 26 Nov 2003 07:12:06 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (127.0.0.1) by nic.lp.se (MX V5.3 VnHj) with ESMTP; Wed, 26 Nov 2003 16:12:04 +0100
Date: Wed, 26 Nov 2003 16:12:03 +0100 (CET)
Message-ID: <[e-mail]>
To: [e-mail]
CC: [e-mail]
Subject: Re: Certificate Policy Standardization
From: Richard Levitte - VMS Whacker <[e-mail]>
In-Reply-To: <025b01c3b421$683107b0$0500a8c0@arport>
References: <033e01c3b40d$0b962670$[e-mail]> <025b01c3b421$683107b0$0500a8c0@arport>
X-URL: http://www.lp.se/
X-Waved: dead chicken, GNU emacs 21.3.1, Mew version 4.0.60
X-Mew: See http://www.mew.org/
X-Mailer: Mew version 4.0.60 on Emacs 21.3.1 / 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 <025b01c3b421$683107b0$0500a8c0@arport> on Wed, 26 Nov 2003 14:30:06 +0100, "Anders Rundgren" <[e-mail]> said:

anders.rundgren> I wonder how many times I have to repeat the same
anders.rundgren> very basic questions and only getting answers back in
anders.rundgren> "ASN.1"?  Sort of.  So here we go again...
anders.rundgren> 
anders.rundgren> 1. Why does practically no shrink-wrap PKI-enabled
anders.rundgren>    software package support any kind of certificate
anders.rundgren>    policy settings?
anders.rundgren> 
anders.rundgren> 2. And why do few if any commercial CAs support
anders.rundgren>    multiple issuances (i.e. different CPs) per CA
anders.rundgren>    root?
anders.rundgren> 
anders.rundgren> Because they have understood the problems associated?
anders.rundgren> Because they enjoy "violating" standards?
anders.rundgren> Because they are ignorant?
anders.rundgren> Because their budget is too limited?
anders.rundgren> Other?

Because they won't bother implementing something that a customer
hasn't asked for specifically.

I have literaly heard the sentence "Yeah, it would probably be useful
and might increase the value of our product, but no customer has said
they wanted or needed this, so we'll wait for that to happen".  And
this was for a product that had a lot to do with security.  It wasn't
about policy OIDs back then, but something similar enough.

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.
You don't have to be rich, a $10 donation is appreciated!

-- 
Richard Levitte     | http://richard.levitte.org/ | Tunnlandsv. 3
Levitte Programming | http://www.lp.se/           | S-168 36 Bromma
T: [phone] |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQFB3ib026313 for <[e-mail]>; Wed, 26 Nov 2003 07:11:03 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQFB3OD026312 for ietf-pkix-bks; Wed, 26 Nov 2003 07:11:03 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.cs.auckland.ac.nz (csmail.cs.auckland.ac.nz [130.216.33.150]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQFB0ib026302 for <[e-mail]>; Wed, 26 Nov 2003 07:11:02 -0800 (PST) (envelope-from [e-mail])
Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id A299863C1D; Thu, 27 Nov 2003 04:10:58 +1300 (NZDT)
Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id hAQFDUG01265; Thu, 27 Nov 2003 04:13:30 +1300
Date: Thu, 27 Nov 2003 04:13:30 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Certificate Policy Standardization
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>

"Anders Rundgren" <[e-mail]> writes:

>1. Why does practically no shrink-wrap PKI-enabled software package support
>any kind of certificate policy settings?

Zero demand.  Heck, it wasn't too long ago that MS PKI software hardcoded the
Verisign policy into CryptoAPI, so that no matter what the actual policy was
in the cert, what was displayed was the Verisign policy.  That shows how much
attention people are paying to the policy stuff.

That doesn't mean that RPs don't use a policy-equivalent: The software is
configured - via trusted roots - to only accept certs from a given set of CAs
(Anders, that's the policy-configurability you asked for, it's just not called
that).  So the trusted-roots mechanism does what the policy extension is
supposed to do, and the policy extension becomes a legal self-defence
mechanism for the benefit of the CA.  This is an almost complete inversion of
what RFC 3280 thinks that the policy extension is meant for:

  Applications with specific policy requirements are expected to have a list
  of those policies which they will accept and to compare the policy OIDs in
  the certificate to that list.

Peter.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQF7kib026184 for <[e-mail]>; Wed, 26 Nov 2003 07:07:46 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQF7kno026183 for ietf-pkix-bks; Wed, 26 Nov 2003 07:07:46 -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.10/8.12.8) with ESMTP id hAQF7jib026174 for <[e-mail]>; Wed, 26 Nov 2003 07:07:45 -0800 (PST) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id hAQF7esj017220; Wed, 26 Nov 2003 10:07:40 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p06010205bbea7029f2b0@[128.89.89.75]>
In-Reply-To: <025b01c3b421$683107b0$0500a8c0@arport>
References: <033e01c3b40d$0b962670$[e-mail]> <025b01c3b421$683107b0$0500a8c0@arport>
Date: Wed, 26 Nov 2003 10:06:41 -0500
To: "Anders Rundgren" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Certificate Policy Standardization
Cc: <[e-mail]>
Content-Type: multipart/alternative; boundary="============_-1142263285==_ma============"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
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>

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

At 14:30 +0100 11/26/03, Anders Rundgren wrote:
>Hum,
>
>I wonder how many times I have to repeat the same very basic
>questions and only getting answers back in "ASN.1"?  Sort of.
>So here we go again...
>
>1. Why does practically no shrink-wrap PKI-enabled software
>package support any kind of certificate policy settings?

one might ask why the most widely distributed product that claims to 
implement IPsec  (Windows) does not provide a user/administrator the 
ability to order SPD entries, as required by RFC 2401. The answer is 
that the implementors did not understand why this was an important 
(in the case of IPsec, a critical) aspect of the standard and so the 
implementors omitted an important management control.

what one can learn from this an similar examples is that vendors are 
a very poor basis for determining the worth of a feature in a 
standard. a very big vendor can screw up an implementation and get 
away with it due to market dominance. other vendors, eager to be 
compatible with the dominant vendor, follow suit.  most users may not 
understand a complex technology and don't know what's missing.

>2. And why do few if any commercial CAs support multiple
>issuances (i.e. different CPs) per CA root?
>
>Because they have understood the problems associated?

sometimes, but rarely, in my experience.

>Because they enjoy "violating" standards?

"enjoy" is probably the wrong term, but "don't care" is accurate.

>Because they are ignorant?

sometimes, yes!

>Because their budget is too limited?

prioritization of development resources, combined with time to market 
pressure is often the reason that a vendor omits certain features.

>Other?

yes, you left out implementors who have decided that in the market 
niche of interest to them, they have a "better" way of implementing a 
capability that is incompatible with the standard and so they pursue 
their proprietary approach.

Steve
--============_-1142263285==_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: Certificate Policy
Standardization</title></head><body>
<div>At 14:30 +0100 11/26/03, Anders Rundgren wrote:</div>
<blockquote type="cite" cite>Hum,<br>
<br>
I wonder how many times I have to repeat the same very basic<br>
questions and only getting answers back in &quot;ASN.1&quot;?&nbsp;
Sort of.<br>
So here we go again...<br>
<br>
1. Why does practically no shrink-wrap PKI-enabled software<br>
package support any kind of certificate policy settings?</blockquote>
<div><br></div>
<div>one might ask why the most widely distributed product that claims
to implement IPsec&nbsp; (Windows) does not provide a
user/administrator the ability to order SPD entries, as required by
RFC 2401. The answer is that the implementors did not understand why
this was an important (in the case of IPsec, a<u> critical</u>) aspect
of the standard and so the implementors omitted an important
management control.</div>
<div><br></div>
<div>what one can learn from this an similar examples is that vendors
are a very poor basis for determining the worth of a feature in a
standard. a very big vendor can screw up an implementation and get
away with it due to market dominance. other vendors, eager to be
compatible with the dominant vendor, follow suit.&nbsp; most users may
not understand a complex technology and don't know what's
missing.</div>
<div><br></div>
<blockquote type="cite" cite>2. And why do few if any commercial CAs
support multiple<br>
issuances (i.e. different CPs) per CA root?<br>
<br>
Because they have understood the problems associated?</blockquote>
<div><br>
sometimes, but rarely, in my experience.<br>
</div>
<blockquote type="cite" cite>Because they enjoy &quot;violating&quot;
standards?</blockquote>
<div><br></div>
<div>&quot;enjoy&quot; is probably the wrong term, but &quot;don't
care&quot; is accurate.</div>
<div><br></div>
<blockquote type="cite" cite>Because they are ignorant?</blockquote>
<div><br></div>
<div>sometimes, yes!</div>
<div><br></div>
<blockquote type="cite" cite>Because their budget is too
limited?</blockquote>
<div><br></div>
<div>prioritization of development resources, combined with time to
market pressure is often the reason that a vendor omits certain
features.</div>
<div><br></div>
<blockquote type="cite" cite>Other?</blockquote>
<div><br></div>
<div>yes, you left out implementors who have decided that in the
market niche of interest to them, they have a &quot;better&quot; way
of implementing a capability that is incompatible with the standard
and so they pursue their proprietary approach.</div>
<div><br></div>
<div>Steve</div>
</body>
</html>
--============_-1142263285==_ma============--


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQF6oib026145 for <[e-mail]>; Wed, 26 Nov 2003 07:06:50 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQF6nTf026144 for ietf-pkix-bks; Wed, 26 Nov 2003 07:06:49 -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.10/8.12.8) with ESMTP id hAQF6mib026135 for <[e-mail]>; Wed, 26 Nov 2003 07:06:48 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (127.0.0.1) by nic.lp.se (MX V5.3 VnHj) with ESMTP; Wed, 26 Nov 2003 16:06:47 +0100
Date: Wed, 26 Nov 2003 16:06:46 +0100 (CET)
Message-ID: <[e-mail]>
To: [e-mail]
CC: [e-mail]
Subject: Re: Certificate Policy Standardization
From: Richard Levitte - VMS Whacker <[e-mail]>
In-Reply-To: <028101c3b424$7dd4b460$0500a8c0@arport>
References: <00e001c3b366$7c1cbc80$0500a8c0@arport> <[e-mail]> <028101c3b424$7dd4b460$0500a8c0@arport>
X-URL: http://www.lp.se/
X-Waved: dead chicken, GNU emacs 21.3.1, Mew version 4.0.60
X-Mew: See http://www.mew.org/
X-Mailer: Mew version 4.0.60 on Emacs 21.3.1 / 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 <028101c3b424$7dd4b460$0500a8c0@arport> on Wed, 26 Nov 2003 14:52:10 +0100, "Anders Rundgren" <[e-mail]> said:

anders.rundgren> Richard,

Anders,

anders.rundgren> That external parties to the US e-governments, like
anders.rundgren> various businesses would ever (on a wider scale)
anders.rundgren> bother with cross-certification is unlikely, they
anders.rundgren> will just purchase a TTP-issued "business
anders.rundgren> certificate" for a few hundred dollars, not run CAs.

Wait, weren't you just asking about connecting different PKIs
together, or did I misunderstand you?  Going out shopping "business
certificates" will mean absolutely nothing in terms of PKI connection
unless everyone agrees to shop from the same CA.  I see that
happening, right...

It's true that smaller businesses will most likely not bother running
their own CA (unless they are run by techno-geeks like me, but that's
a different matter :-)).  I'm not so sure about larger ones...

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.
You don't have to be rich, a $10 donation is appreciated!

-- 
Richard Levitte     | http://richard.levitte.org/ | Tunnlandsv. 3
Levitte Programming | http://www.lp.se/           | S-168 36 Bromma
T: [phone] |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQF31ib025846 for <[e-mail]>; Wed, 26 Nov 2003 07:03:01 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQF31Fi025845 for ietf-pkix-bks; Wed, 26 Nov 2003 07:03:01 -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.10/8.12.8) with ESMTP id hAQF30ib025837 for <[e-mail]>; Wed, 26 Nov 2003 07:03:00 -0800 (PST) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id hAQF2tsj016901; Wed, 26 Nov 2003 10:02:56 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p06010204bbea6fb4d743@[128.89.89.75]>
In-Reply-To: <009e01c3b40d$329bed40$0500a8c0@arport>
References: <009e01c3b40d$329bed40$0500a8c0@arport>
Date: Wed, 26 Nov 2003 09:57:09 -0500
To: "Anders Rundgren" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Da Capo: Re: Certificate Policy Standardization
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
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 +0100 11/26/03, Anders Rundgren wrote:
>  >Policy OIDs might come handy to protect RPs from issuing authorities who
>>might seek to alter their terms arbitrarily without necessarily providing
>>notice to that effect. In practice, ambiguity over the exact content of
>>applicable policy might render that CP unenforceable.
>
>When I read a statement like above, I get really sad and begin
>to completely lose faith in the PKI technology [1], wondering
>if I maybe should go and waste my talent on something useful
>for a change.
>

Promises, promises ...


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQF12ib025722 for <[e-mail]>; Wed, 26 Nov 2003 07:01:04 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQF12ud025721 for ietf-pkix-bks; Wed, 26 Nov 2003 07:01:02 -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.10/8.12.8) with ESMTP id hAQF0xib025703 for <[e-mail]>; Wed, 26 Nov 2003 07:01:00 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (127.0.0.1) by nic.lp.se (MX V5.3 VnHj) with ESMTP; Wed, 26 Nov 2003 16:00:57 +0100
Date: Wed, 26 Nov 2003 16:00:56 +0100 (CET)
Message-ID: <[e-mail]>
To: [e-mail]
CC: [e-mail], [e-mail]
Subject: Re: Certificate Policy Standardization
From: Richard Levitte - VMS Whacker <[e-mail]>
In-Reply-To: <014b01c3b416$b6075580$0500a8c0@arport>
References: <[e-mail]> <014b01c3b416$b6075580$0500a8c0@arport>
X-URL: http://www.lp.se/
X-Waved: dead chicken, GNU emacs 21.3.1, Mew version 4.0.60
X-Mew: See http://www.mew.org/
X-Mailer: Mew version 4.0.60 on Emacs 21.3.1 / 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 <014b01c3b416$b6075580$0500a8c0@arport> on Wed, 26 Nov 2003 13:13:32 +0100, "Anders Rundgren" <[e-mail]> said:

anders.rundgren> >I don't see how you can say that, Anders. That's not
anders.rundgren> >how the system is designed to work. No CA s/w that I
anders.rundgren> >have yet to encounter limits certificates to a
anders.rundgren> >single policy, let alone the CA. CertificatePolicies
anders.rundgren> >can be multivalued, is not a mandatory field, does
anders.rundgren> >not get marked as critical and in all except bespoke
anders.rundgren> >applications is currently ignored. Failure on the
anders.rundgren> >part of software developers to meet the agreed
anders.rundgren> >standards does not always indicate a failing of the
anders.rundgren> >standard (granted that in some cases it does).
anders.rundgren> 
anders.rundgren> Well Chris,
anders.rundgren> I think you read this in big haste.
anders.rundgren> 
anders.rundgren> CA s/w is not equivalent to RP s/w.
anders.rundgren> 
anders.rundgren> Please tell me where I in the latest edition of
anders.rundgren> Outlook Express (I'm indeed a daring guy...), can
anders.rundgren> "tweak" the CA policy trust settings.

That's today.  I believe that to the crowd, awareness of the type of
trust we're discussing here is fairly new (and in many cases so new
they aren't aware yet).  And M$ is fairly well-known for implementing
what it thinks the crowd wants and try to avoid things that could be
seen as complicated ("oh, I should protect my private key with a pass
phrase???"), so pardon me for rejecting that particular example.

I believe that when the crowd becomes a bit more aware of what their
actions mean when done through a computer, compared to the "real
world", they might demand  certain amount of control, and it's
perfectly possible that you will see those kinds of "knobs" sometime
in the future.

anders.rundgren> In case you don't find the "knob", does this in your
anders.rundgren> opinion mean that Microsoft is not
anders.rundgren> standards-compliant w.r.t. policy-OIDs?

Nope, it just means that they have assumed you would always press the
"Accept any policy" knob, and besides, that's all they currently
support, so the knob would be quite lonely in that otherwise empty
space, so they won't bother to put it up yet.

However, if M$ doesn't check for policy OID and mappings and keep
track of those along with the other data while verifying the path,
then they aren't standards-compliant w.r.t. policy OIDs.  As it is
right now, I wouldn't be surprised if they're in good company :-/.

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.
You don't have to be rich, a $10 donation is appreciated!

-- 
Richard Levitte     | http://richard.levitte.org/ | Tunnlandsv. 3
Levitte Programming | http://www.lp.se/           | S-168 36 Bromma
T: [phone] |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQEvhib025556 for <[e-mail]>; Wed, 26 Nov 2003 06:57:43 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQEvhJu025555 for ietf-pkix-bks; Wed, 26 Nov 2003 06:57:43 -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.10/8.12.8) with ESMTP id hAQEvgib025546 for <[e-mail]>; Wed, 26 Nov 2003 06:57:42 -0800 (PST) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id hAQEvbsl016518; Wed, 26 Nov 2003 09:57:38 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p06010203bbea6ed9a3e9@[128.89.89.75]>
In-Reply-To: <002601c3b3fc$1d25e8a0$0500a8c0@arport>
References: <01fc01c3b366$8707d760$[e-mail]> <002601c3b3fc$1d25e8a0$0500a8c0@arport>
Date: Wed, 26 Nov 2003 09:55:40 -0500
To: "Anders Rundgren" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Certificate Policy Standardization
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
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 10:03 +0100 11/26/03, Anders Rundgren wrote:
>  >I am not what you mean by ".....another useless PKIX bloat extension".
>
>>If properly used by the CA and relying party systems, the certificate policy
>>OID can be used to provide amount of trust the relying party should place in
>>a certificate.
>
>What Michael referred to as "bloat" is not policy identifiers themselves
>but that they need another trust adminstration GUI and associated hassles.
>
>Policy identifiers used for path validation purposes is indeed a
>very "fancy" thing from a technical point of view (maybe 2% of the
>people subscribed to the PKIX list can understand this part of
>RFC3280...), but from an interoperability point of view they are
>not that great.
>
>Hum, there simply must be a reason why practically all commercial
>CAs have selected an entirely different approach.  And that they did
>this completely on their own without any commitee descision etc.
>
>I wonder how this really happend.   Could it be...
>
>     that it sort of feels "natural"?
>
>/a

could it be because some of them are clueless, as evidenced by 
Peter's collection of non-compliant certs issued by these folks?

could it be because these CAs like to create their own closed 
communities to maintain market share?

there are lots of good reasons for a CA to not use a feature in the 
standards, a few good reasons to choose another way to achieve the 
same effect, and lots of bad reasons to choose another way ...


Steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQEr6ib025318 for <[e-mail]>; Wed, 26 Nov 2003 06:53:06 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQEr6aR025317 for ietf-pkix-bks; Wed, 26 Nov 2003 06:53:06 -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.10/8.12.8) with ESMTP id hAQEr5ib025306 for <[e-mail]>; Wed, 26 Nov 2003 06:53:05 -0800 (PST) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id hAQEqcsj016166; Wed, 26 Nov 2003 09:52:39 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p06010201bbea6cf53279@[128.89.89.75]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Wed, 26 Nov 2003 09:49:16 -0500
To: [e-mail] (Peter Gutmann)
From: Stephen Kent <[e-mail]>
Subject: Re: Certificate Policy Standardization
Cc: [e-mail], [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
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 19:07 +1300 11/26/03, Peter Gutmann wrote:
>Stephen Kent <[e-mail]> writes:
>
>>Note that with the advent of 3280, we decided to let protocols that are PKI
>>clients define extended key usage options for themselves.
>
>I recently had to deal with someone who's working with certs from (at least)
>two difference (largeish) public CAs.  One CA turned the eKU into a kind of
>lamp test packet, with every usage they could think of set ("Let's see, what
>have we got here... timestamping, IPsec, encrypted filesystem, Win2K logon,
>and S/MIME, that sounds like a sensible combination of usages for a private
>key").  The other CA didn't populate the eKU at all, justifying it with
>"Everything ignores those anyway, so it doesn't matter what you put in there"
>(obviously they have to ignore them, in order to allow certs like the ones I'm
>describing to function).  In the end after taking legal considerations into
>account the conclusion was to define a new eKU, "doWhatISay", defined as "This
>key may only be used as we say it can be used" (it's not quite worded like
>that in their CPS, that'll take another six months for the lawyers to sort
>out).
>
>I dunno about the situation in the PKIX reality, but in the real world from
>the legal point of view (which is what matters in the end) that's about the
>best way to make use of eKU.
>
>Peter.

Your example is one in which CAs chose to make up their own, private 
EKUs. This is certainly allowed, but it is not what I said we had 
decided to do in the IETF, where we would expect EKU OIDs to be 
standardized by the cognizant WGs for the protocols with which the 
certs are used.

Also, you claim that what matters in the end is what "the legal point 
of view" says.  This is certainly true in some contexts, but not all 
certs are used in ways that have legal ramifications of the sort you 
imply. For example, most certs used with IKE will not be subject to 
some attorney's advice, I suspect.

Steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQEIPib023318 for <[e-mail]>; Wed, 26 Nov 2003 06:18:25 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQEIPRQ023317 for ietf-pkix-bks; Wed, 26 Nov 2003 06:18:25 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp2.mivlmd.cablespeed.com (smtp2.mivlmd.cablespeed.com [24.35.0.19]) by above.proper.com (8.12.10/8.12.8) with SMTP id hAQEINib023312 for <[e-mail]>; Wed, 26 Nov 2003 06:18:23 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 17480 invoked by uid 0); 26 Nov 2003 14:17:47 -0000
Received: from unknown (HELO cablespeed.com) (24.35.57.71) by 0 with SMTP; 26 Nov 2003 14:17:47 -0000
Message-ID: <[e-mail]>
Date: Wed, 26 Nov 2003 09:19:55 -0500
From: jim <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Certificate Policy Standardization
References: <[e-mail]> <[e-mail]>            <00e001c3b366$7c1cbc80$0500a8c0@arport> <[e-mail]>
Content-Type: text/plain; charset=us-ascii; 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>

Richard brings up an excellent point that should be considered by the 
members of this body.  On the horizon is the implementation of security 
middleware from a number of sources, which will allow for simpler 
PKEnablement of Web applications.  The issue in this regard is going to 
be the identification of how trust can be shared without having to go 
back to the original CA who issued a cert and cross-certifying CAs in 
that regard so that Internet commerce can be accomplished with many uses 
on the fly from disparate PKIs.  Meaningful OIDs offer a lot that can 
increase the success or failure of PK technology adaptation for 
commerce.  In that regard, please everyone, see what you can think of 
that will make this a useful and helpful solution to allow PK technology 
to flourish.

Jim Heimberg, ABC, Ph.D.
Secure Course
www.securecourse.com


Richard Levitte - VMS Whacker wrote:

>In message <00e001c3b366$7c1cbc80$0500a8c0@arport> on Tue, 25 Nov 2003 16:11:57 +0100, "Anders Rundgren" <[e-mail]> said:
>
>anders.rundgren> Policy OIDs may be "perfect" as long as you stay
>anders.rundgren> inside of your "walled garden", but the USs
>anders.rundgren> government PKI will likely find itself up the creek
>anders.rundgren> when they are going to connect to the outside world
>anders.rundgren> who hardly ever use this feature (which I BTW cannot
>anders.rundgren> find a single "knob" for in my W2K system), or even
>anders.rundgren> worse, have settled on another set of OIDs.
>
>Uhmm, especially that last thing about other PKIs having other sets
>of OIDs makes me think you have missed the mechanism called "policy
>mapping".  There's no requirement whatsoever that everyone uses the
>same set of OIDs.  However, if the owner of one PKI decides to do
>business with another PKI owner and have the two PKIs connected, they
>will typically do some cross certification, and those certificates
>will contain the appropriate mappings of policies, as decided by the
>two parties together.
>
>As far as I understand, those kinds of mechanisms are already in use
>and working.  I assume others here will be able to say yay or ney
>about this matter.
>
>Of course, what I said above implies some level of "meshness", about
>which I've read some negative comments from one person...
>
>-----
>Please consider sponsoring my work on free software.
>See http://www.free.lp.se/sponsoring.html for details.
>You don't have to be rich, a $10 donation is appreciated!
>
>  
>





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQEFQib023163 for <[e-mail]>; Wed, 26 Nov 2003 06:15:26 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQEFQ93023162 for ietf-pkix-bks; Wed, 26 Nov 2003 06:15:26 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.be.ubizen.com (batty.be.ubizen.com [212.113.70.10]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQEFPib023150 for <[e-mail]>; Wed, 26 Nov 2003 06:15:25 -0800 (PST) (envelope-from [e-mail])
Received: (from local) by mail.be.ubizen.com id hAQEFPFO018287 for <[e-mail]>; Wed, 26 Nov 2003 15:15:25 +0100
Received: from UNKNOWN(10.0.0.108), claiming to be "amaya.be.ubizen.com" via SMTP by batty.netvision.be, id smtpd18274aaa; Wed Nov 26 14:15:02 2003
Received: (qmail 9386 invoked from network); 26 Nov 2003 14:15:00 -0000
Received: from unknown (HELO ubi) (10.0.0.10) by amaya.be.ubizen.com with SMTP; 26 Nov 2003 14:14:58 -0000
Received: from ubizen.com (por017a.be.ubizen.com [10.0.40.67]) by ubi.be.ubizen.com (#####) with ESMTP id <[e-mail]>; Wed, 26 Nov 2003 15:14:57 +0100 (MET)
Date: Wed, 26 Nov 2003 15:18:12 +0100
From: Andreas Mitrakas <[e-mail]>
Subject: Re: Certificate Policy Standardization
To: Anders Rundgren <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
X-Accept-Language: en
References: <01ec01c3b28f$1abbab40$0500a8c0@arport> <[e-mail]> <[e-mail]> <[e-mail]> <00e001c3b366$7c1cbc80$0500a8c0@arport> <[e-mail]> <007901c3b406$474ce110$0500a8c0@arport>
X-Sanitizer: Out/BE
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 Anders,

> As I wrote I don't object to policy OIDs themselves, but to their use in
> path validation and their configaration in RP applications.

Much like yourself and regardless of preferences, all I am saying is that one
should be apprehensive as to what a CP is all about, since CPs have legal as
well as technical and organisational significance . Especially so in some
implementations in Europe where there is a direct link between the policy and
the law under which certain certs like QC certs are issued. A CP becomes part
of the parties agreement and binding by means of e.g. a subscriber agreement.
So it is not unthinkable albeit not necessarily desirable, that a courts
might  scrutinise policies. --God forbid.

> Regarding your comment I think this is a bit wrong.  What good is
> a CP OID (basically) saying "I come from a good CA"?  "Good" is
> IMHO for others to vouch for.  Uncertified or unverified data is pretty
> useless for trust purposes.

All I am saying is that establishing a trustworthy source of CP information
makes good sense so that RPs are notified of changes in CP versions and they
stand a chance to scan CPs before they are forced to accept the next cert in
the line. An OID can help but it does not necessarily solve the problem of a
trustworthy source for policies because then someone has to manage such a
repository.

andreas



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQDu1ib021994 for <[e-mail]>; Wed, 26 Nov 2003 05:56:01 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQDu1Rd021993 for ietf-pkix-bks; Wed, 26 Nov 2003 05:56:01 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp4.hy.skanova.net (smtp4.hy.skanova.net [195.67.199.133]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQDtxib021987 for <[e-mail]>; Wed, 26 Nov 2003 05:56:00 -0800 (PST) (envelope-from [e-mail])
Received: from arport (t8o913p59.telia.com [213.64.26.179]) by smtp4.hy.skanova.net (8.12.10/8.12.10) with SMTP id hAQDtwBZ009924; Wed, 26 Nov 2003 14:55:58 +0100 (CET)
Message-ID: <028101c3b424$7dd4b460$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Richard Levitte - VMS Whacker" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]> <[e-mail]>            <00e001c3b366$7c1cbc80$0500a8c0@arport> <[e-mail]>
Subject: Re: Certificate Policy Standardization
Date: Wed, 26 Nov 2003 14:52:10 +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>

Richard,
That external parties to the US e-governments, like various
businesses would ever (on a wider scale) bother with cross-
certification is unlikely, they will just purchase a TTP-issued
"business certificate" for a few hundred dollars, not run CAs.

And in the case of the US e-government, they have a much more
serious problem to cater for than CP OIDs and that is that their
business parties, will authenticate messages at the business partner
level, not on employee level (as the latter is incompatible with
all e-business systems I have heard about).  So they probably
have to take down the whole thing and startover anyway.
Or have "gateway" servers do the transformation from their
internal "mess-PKI" (not mesh PKI) to something that works.
Like "flat", "boring", "simple",  you know.  In that world
CP OIDs are mostly unknown.   I have yet to find a CP OID
in my fairly new Thawte SSL certificate.

Anders


----- Original Message -----
From: "Richard Levitte - VMS Whacker" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>
Sent: Wednesday, November 26, 2003 14:30
Subject: Re: Certificate Policy Standardization


In message <00e001c3b366$7c1cbc80$0500a8c0@arport> on Tue, 25 Nov 2003 16:11:57 +0100, "Anders Rundgren" <[e-mail]>
said:

anders.rundgren> Policy OIDs may be "perfect" as long as you stay
anders.rundgren> inside of your "walled garden", but the USs
anders.rundgren> government PKI will likely find itself up the creek
anders.rundgren> when they are going to connect to the outside world
anders.rundgren> who hardly ever use this feature (which I BTW cannot
anders.rundgren> find a single "knob" for in my W2K system), or even
anders.rundgren> worse, have settled on another set of OIDs.

Uhmm, especially that last thing about other PKIs having other sets
of OIDs makes me think you have missed the mechanism called "policy
mapping".  There's no requirement whatsoever that everyone uses the
same set of OIDs.  However, if the owner of one PKI decides to do
business with another PKI owner and have the two PKIs connected, they
will typically do some cross certification, and those certificates
will contain the appropriate mappings of policies, as decided by the
two parties together.

As far as I understand, those kinds of mechanisms are already in use
and working.  I assume others here will be able to say yay or ney
about this matter.

Of course, what I said above implies some level of "meshness", about
which I've read some negative comments from one person...

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.
You don't have to be rich, a $10 donation is appreciated!

--
Richard Levitte     | http://richard.levitte.org/ | Tunnlandsv. 3
Levitte Programming | http://www.lp.se/           | S-168 36 Bromma
T: [phone] |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQDfiib021255 for <[e-mail]>; Wed, 26 Nov 2003 05:41:44 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQDfipC021254 for ietf-pkix-bks; Wed, 26 Nov 2003 05:41:44 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail4.consignia.com (mail4.consignia.com [144.87.143.84]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQDfhib021249 for <[e-mail]>; Wed, 26 Nov 2003 05:41:43 -0800 (PST) (envelope-from [e-mail])
Received: from postoffice.co.uk (mta2.int.consignia.com [144.87.146.16]) by mail4.consignia.com (Postfix) with SMTP id 91A3A1224CB; Wed, 26 Nov 2003 13:41:43 +0000 (GMT)
Received: by postoffice.co.uk(Lotus SMTP MTA v4.6.6  (890.1 7-16-1999))  id 00256DEA.004B3EC7 ; Wed, 26 Nov 2003 13:41:52 +0000
X-Lotus-FromDomain: POSTOFFICE
From: [e-mail]
To: "Anders Rundgren" <[e-mail]>
Cc: [e-mail]
Message-ID: <[e-mail]>
Date: Wed, 26 Nov 2003 13:41:30 +0000
Subject: Re: Certificate Policy Standardization
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
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>

> CA s/w is not equivalent to RP s/w.

Agreed

> Please tell me where I in the latest edition of Outlook Express (I'm
> indeed a daring guy...), can "tweak" the CA policy trust settings.
> In case you don't find the "knob", does this in your opinion mean
> that Microsoft is not standards-compliant w.r.t. policy-OIDs?

Not at all. Like I said, at present it is largely ignored. Reinforced
by it absence from such a widespread COTS application like Outlook
Express. You'd have to ask MS why it doesn't process it but having worked
quite closely with them in this area my guess is that they would argue
that there is no need to include a feature for which there is presently
no demand.

> Also please show me a single commercial CA that uses multiple
> CPs for a certain root.

Personally ? No, I could not.

Chris











Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQDXuib020957 for <[e-mail]>; Wed, 26 Nov 2003 05:33:56 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQDXuxY020956 for ietf-pkix-bks; Wed, 26 Nov 2003 05:33:56 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp4.hy.skanova.net (smtp4.hy.skanova.net [195.67.199.133]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQDXsib020950 for <[e-mail]>; Wed, 26 Nov 2003 05:33:55 -0800 (PST) (envelope-from [e-mail])
Received: from arport (t8o913p59.telia.com [213.64.26.179]) by smtp4.hy.skanova.net (8.12.10/8.12.10) with SMTP id hAQDXrBZ021174 for <[e-mail]>; Wed, 26 Nov 2003 14:33:54 +0100 (CET)
Message-ID: <025b01c3b421$683107b0$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>
References: <033e01c3b40d$0b962670$[e-mail]>
Subject: Re: Certificate Policy Standardization
Date: Wed, 26 Nov 2003 14:30:06 +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>

Hum,

I wonder how many times I have to repeat the same very basic
questions and only getting answers back in "ASN.1"?  Sort of.
So here we go again...

1. Why does practically no shrink-wrap PKI-enabled software
package support any kind of certificate policy settings?

2. And why do few if any commercial CAs support multiple
issuances (i.e. different CPs) per CA root?

Because they have understood the problems associated?
Because they enjoy "violating" standards?
Because they are ignorant?
Because their budget is too limited?
Other?

Anders

----- Original Message ----- 
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Sent: Wednesday, November 26, 2003 12:04
Subject: RE: Certificate Policy Standardization



Anders:

The relying parties are free to ignore the policies and policy related
extensions altogether and verify paths.  The certification path will verify
unless:

1.  One or more CAs in the path require that the certification path be valid
for a policy; or

2.  Make the policy related extensions critical.

While some may view the two conditions as interoperability problem, I view
it CA(s) saying that I do not want you to use the certificate unless you
understand and abide by constraints I impose on the certificates.

The current X.509 and RFC 3280 permit you build PKI and applications that do
not use certificate policies.  So, I do not quite understand your concern
below.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Anders Rundgren
Sent: Wednesday, November 26, 2003 4:03 AM
To: Santosh Chokhani; [e-mail]
Subject: Re: Certificate Policy Standardization




>I am not what you mean by ".....another useless PKIX bloat extension".

>If properly used by the CA and relying party systems, the certificate 
>policy OID can be used to provide amount of trust the relying party 
>should place in a certificate.

What Michael referred to as "bloat" is not policy identifiers themselves but
that they need another trust adminstration GUI and associated hassles.

Policy identifiers used for path validation purposes is indeed a very
"fancy" thing from a technical point of view (maybe 2% of the people
subscribed to the PKIX list can understand this part of RFC3280...), but
from an interoperability point of view they are not that great.

Hum, there simply must be a reason why practically all commercial CAs have
selected an entirely different approach.  And that they did this completely
on their own without any commitee descision etc.

I wonder how this really happend.   Could it be...

    that it sort of feels "natural"?

/a




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQDURib020751 for <[e-mail]>; Wed, 26 Nov 2003 05:30:27 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQDURes020750 for ietf-pkix-bks; Wed, 26 Nov 2003 05:30:27 -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.10/8.12.8) with ESMTP id hAQDUQib020745 for <[e-mail]>; Wed, 26 Nov 2003 05:30:26 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (127.0.0.1) by nic.lp.se (MX V5.3 VnHj) with ESMTP; Wed, 26 Nov 2003 14:30:21 +0100
Date: Wed, 26 Nov 2003 14:30:17 +0100 (CET)
Message-ID: <[e-mail]>
To: [e-mail]
CC: [e-mail], [e-mail]
Subject: Re: Certificate Policy Standardization
From: Richard Levitte - VMS Whacker <[e-mail]>
In-Reply-To: <00e001c3b366$7c1cbc80$0500a8c0@arport>
References: <[e-mail]> <[e-mail]> <00e001c3b366$7c1cbc80$0500a8c0@arport>
X-URL: http://www.lp.se/
X-Waved: dead chicken, GNU emacs 21.3.1, Mew version 4.0.60
X-Mew: See http://www.mew.org/
X-Mailer: Mew version 4.0.60 on Emacs 21.3.1 / 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 <00e001c3b366$7c1cbc80$0500a8c0@arport> on Tue, 25 Nov 2003 16:11:57 +0100, "Anders Rundgren" <[e-mail]> said:

anders.rundgren> Policy OIDs may be "perfect" as long as you stay
anders.rundgren> inside of your "walled garden", but the USs
anders.rundgren> government PKI will likely find itself up the creek
anders.rundgren> when they are going to connect to the outside world
anders.rundgren> who hardly ever use this feature (which I BTW cannot
anders.rundgren> find a single "knob" for in my W2K system), or even
anders.rundgren> worse, have settled on another set of OIDs.

Uhmm, especially that last thing about other PKIs having other sets
of OIDs makes me think you have missed the mechanism called "policy
mapping".  There's no requirement whatsoever that everyone uses the
same set of OIDs.  However, if the owner of one PKI decides to do
business with another PKI owner and have the two PKIs connected, they
will typically do some cross certification, and those certificates
will contain the appropriate mappings of policies, as decided by the
two parties together.

As far as I understand, those kinds of mechanisms are already in use
and working.  I assume others here will be able to say yay or ney
about this matter.

Of course, what I said above implies some level of "meshness", about
which I've read some negative comments from one person...

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.
You don't have to be rich, a $10 donation is appreciated!

-- 
Richard Levitte     | http://richard.levitte.org/ | Tunnlandsv. 3
Levitte Programming | http://www.lp.se/           | S-168 36 Bromma
T: [phone] |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQCHMib016432 for <[e-mail]>; Wed, 26 Nov 2003 04:17:22 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQCHMpE016431 for ietf-pkix-bks; Wed, 26 Nov 2003 04:17:22 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp4.hy.skanova.net (smtp4.hy.skanova.net [195.67.199.133]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQCHKib016424 for <[e-mail]>; Wed, 26 Nov 2003 04:17:21 -0800 (PST) (envelope-from [e-mail])
Received: from arport (t11o913p109.telia.com [213.64.28.109]) by smtp4.hy.skanova.net (8.12.10/8.12.10) with SMTP id hAQCHJBZ008004; Wed, 26 Nov 2003 13:17:20 +0100 (CET)
Message-ID: <014b01c3b416$b6075580$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]>
Subject: Re: Certificate Policy Standardization
Date: Wed, 26 Nov 2003 13:13:32 +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>

>> In case you are advising people setting up CAs, I would (in case the
>> CP OID stuff stays forever in the backburner), also recommend them
>> to only apply one CP per CA root, as anything else is actually
>> incompatible with some 99.9% of existing RP software.

>I don't see how you can say that, Anders. That's not how the system
>is designed to work. No CA s/w that I have yet to encounter limits
>certificates to a single policy, let alone the CA. CertificatePolicies
>can be multivalued, is not a mandatory field, does not get marked as
>critical and in all except bespoke applications is currently ignored.
>Failure on the part of software developers to meet the agreed standards
>does not always indicate a failing of the standard (granted that in
>some cases it does).

Well Chris,
I think you read this in big haste.

CA s/w is not equivalent to RP s/w.

Please tell me where I in the latest edition of Outlook Express (I'm
indeed a daring guy...), can "tweak" the CA policy trust settings.

In case you don't find the "knob", does this in your opinion mean
that Microsoft is not standards-compliant w.r.t. policy-OIDs?

Also please show me a single commercial CA that uses multiple
CPs for a certain root.  Note, multi-valued or not that does not matter,
because that is another thing.

A bit puzzled
Anders







Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQCCfib016155 for <[e-mail]>; Wed, 26 Nov 2003 04:12:41 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQCCfqN016154 for ietf-pkix-bks; Wed, 26 Nov 2003 04:12:41 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.cs.auckland.ac.nz (csmail.cs.auckland.ac.nz [130.216.33.150]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQCCdib016147 for <[e-mail]>; Wed, 26 Nov 2003 04:12:40 -0800 (PST) (envelope-from [e-mail])
Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id 2767E63C2D; Thu, 27 Nov 2003 01:12:40 +1300 (NZDT)
Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id hAQCFAT32676; Thu, 27 Nov 2003 01:15:10 +1300
Date: Thu, 27 Nov 2003 01:15:10 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Da Capo: Re: Certificate Policy Standardization
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>

"Anders Rundgren" <[e-mail]> writes:

>  The "market", "crowd", or whatever we name it will never ever
>  know what a "Certificate Policy" is.  And they are perfectly right!

Actually I think they understand very well what it means, it's a large hammer
that you give to your lawyers so they can go after misbehaving (as defined by
the CA) users.  What the RP makes of the policy doesn't really matter, since
it's written by corporate lawyers acting for the CA, not by ones acting for
the RP or ones who have their interests in mind.

(Incidentally, the previous message that I replied to wasn't actually written
 by Anders, I'd already deleted the mail, then decided that it really needed
 replying to and patched it together from the scrollback buffer, which ended
 up with it misattributed.  Apologies for the confusion).

Peter.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQBrwib015170 for <[e-mail]>; Wed, 26 Nov 2003 03:53:58 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQBrw49015169 for ietf-pkix-bks; Wed, 26 Nov 2003 03:53:58 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail3.consignia.com (mail3.consignia.com [144.87.143.83]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQBrvib015152 for <[e-mail]>; Wed, 26 Nov 2003 03:53:57 -0800 (PST) (envelope-from [e-mail])
Received: from postoffice.co.uk (unknown [144.87.146.16]) by mail3.consignia.com (Postfix) with SMTP id 30F121C0AA2; Wed, 26 Nov 2003 11:53:58 +0000 (GMT)
Received: by postoffice.co.uk(Lotus SMTP MTA v4.6.6  (890.1 7-16-1999))  id 00256DEA.00415FAA ; Wed, 26 Nov 2003 11:54:03 +0000
X-Lotus-FromDomain: POSTOFFICE
From: [e-mail]
To: "Anders Rundgren" <[e-mail]>
Cc: [e-mail]
Message-ID: <[e-mail]>
Date: Wed, 26 Nov 2003 11:53:45 +0000
Subject: Re: Certificate Policy Standardization
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
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 case you are advising people setting up CAs, I would (in case the
> CP OID stuff stays forever in the backburner), also recommend them
> to only apply one CP per CA root, as anything else is actually
> incompatible with some 99.9% of existing RP software.

I don't see how you can say that, Anders. That's not how the system
is designed to work. No CA s/w that I have yet to encounter limits
certificates to a single policy, let alone the CA. CertificatePolicies
can be multivalued, is not a mandatory field, does not get marked as
critical and in all except bespoke applications is currently ignored.
Failure on the part of software developers to meet the agreed standards
does not always indicate a failing of the standard (granted that in
some cases it does).

Chris






Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQBaPib013852 for <[e-mail]>; Wed, 26 Nov 2003 03:36:25 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQBaPrM013851 for ietf-pkix-bks; Wed, 26 Nov 2003 03:36:25 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp4.hy.skanova.net (smtp4.hy.skanova.net [195.67.199.133]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQBaOib013844 for <[e-mail]>; Wed, 26 Nov 2003 03:36:25 -0800 (PST) (envelope-from [e-mail])
Received: from arport (t11o913p109.telia.com [213.64.28.109]) by smtp4.hy.skanova.net (8.12.10/8.12.10) with SMTP id hAQBaMBZ006267; Wed, 26 Nov 2003 12:36:22 +0100 (CET)
Message-ID: <00f901c3b410$fda8f250$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>, "Richard Levitte - VMS Whacker" <[e-mail]>, =?iso-8859-1?Q?Michael_Str=F6der?= <[e-mail]>
References: <[e-mail]>
Subject: Re: Certificate Policy Standardization
Date: Wed, 26 Nov 2003 12:31:19 +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>

>For me, OIDs are yet to have their time. As a concept they are elegant
>but will resist widespread use until security-exploiting applications
>support them. Until then they are destined to stay on the back-burner.

Sure.

>I encourage people to adopt their use, however, if only to future-proof
>themselves and I don't see any harm whatsoever in embedding in a certificate
>some mechanism that links the trust level it represents to a real-world
>legal mechanism, even if at present the software support for such a link
>is absent.

In case you are advicing people setting up CAs, I would (in case the
CP OID stuff stays forever in the backburner), also recommend them
to only apply one CP per CA root, as anyhting else is actually
incompatible with some 99.9% of existing RP software.

/anders



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQB9Gib011832 for <[e-mail]>; Wed, 26 Nov 2003 03:09:16 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQB9GMv011831 for ietf-pkix-bks; Wed, 26 Nov 2003 03:09:16 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp7.hy.skanova.net (smtp7.hy.skanova.net [195.67.199.140]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQB9Fib011823 for <[e-mail]>; Wed, 26 Nov 2003 03:09:15 -0800 (PST) (envelope-from [e-mail])
Received: from arport (t9o913p85.telia.com [213.64.27.85]) by smtp7.hy.skanova.net (8.12.10/8.12.10) with SMTP id hAQB9E1w002054 for <[e-mail]>; Wed, 26 Nov 2003 12:09:14 +0100 (CET)
Message-ID: <009e01c3b40d$329bed40$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>
Subject: Da Capo: Re: Certificate Policy Standardization
Date: Wed, 26 Nov 2003 12:05:26 +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>

>Policy OIDs might come handy to protect RPs from issuing authorities who
>might seek to alter their terms arbitrarily without necessarily providing
>notice to that effect. In practice, ambiguity over the exact content of
>applicable policy might render that CP unenforceable.

When I read a statement like above, I get really sad and begin
to completely lose faith in the PKI technology [1], wondering
if I maybe should go and waste my talent on something useful
for a change.

=================================================
  The "market", "crowd", or whatever we name it will never ever
  know what a "Certificate Policy" is.  And they are perfectly right!
=================================================

If you can spell to the word "Issuer", you are probably a "guru" in their eyes.

Now I feel a little bit better :-)

Anders R

1] or rather in the clueless "high priests" who "guards" it...


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQB4gib011640 for <[e-mail]>; Wed, 26 Nov 2003 03:04:42 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQB4gmS011639 for ietf-pkix-bks; Wed, 26 Nov 2003 03:04:42 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mtiwmhc13.worldnet.att.net (mtiwmhc13.worldnet.att.net [204.127.131.117]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQB4fib011634 for <[e-mail]>; Wed, 26 Nov 2003 03:04:41 -0800 (PST) (envelope-from [e-mail])
Received: from wchokhani (14.st.louis-128-129rs.mo.dial-access.att.net[12.74.151.14]) by worldnet.att.net (mtiwmhc13) with SMTP id <20031126110429113003b724e>; Wed, 26 Nov 2003 11:04:30 +0000
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: Certificate Policy Standardization
Date: Wed, 26 Nov 2003 06:04:14 -0500
Message-ID: <033e01c3b40d$0b962670$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
Importance: Normal
In-Reply-To: <002601c3b3fc$1d25e8a0$0500a8c0@arport>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id hAQB4gib011635
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>

Anders:

The relying parties are free to ignore the policies and policy related
extensions altogether and verify paths.  The certification path will verify
unless:

1.  One or more CAs in the path require that the certification path be valid
for a policy; or

2.  Make the policy related extensions critical.

While some may view the two conditions as interoperability problem, I view
it CA(s) saying that I do not want you to use the certificate unless you
understand and abide by constraints I impose on the certificates.

The current X.509 and RFC 3280 permit you build PKI and applications that do
not use certificate policies.  So, I do not quite understand your concern
below.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Anders Rundgren
Sent: Wednesday, November 26, 2003 4:03 AM
To: Santosh Chokhani; [e-mail]
Subject: Re: Certificate Policy Standardization




>I am not what you mean by ".....another useless PKIX bloat extension".

>If properly used by the CA and relying party systems, the certificate 
>policy OID can be used to provide amount of trust the relying party 
>should place in a certificate.

What Michael referred to as "bloat" is not policy identifiers themselves but
that they need another trust adminstration GUI and associated hassles.

Policy identifiers used for path validation purposes is indeed a very
"fancy" thing from a technical point of view (maybe 2% of the people
subscribed to the PKIX list can understand this part of RFC3280...), but
from an interoperability point of view they are not that great.

Hum, there simply must be a reason why practically all commercial CAs have
selected an entirely different approach.  And that they did this completely
on their own without any commitee descision etc.

I wonder how this really happend.   Could it be...

    that it sort of feels "natural"?

/a




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQArIib010428 for <[e-mail]>; Wed, 26 Nov 2003 02:53:18 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQArIhW010427 for ietf-pkix-bks; Wed, 26 Nov 2003 02:53:18 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.cs.auckland.ac.nz (csmail.cs.auckland.ac.nz [130.216.33.150]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQArEib010385 for <[e-mail]>; Wed, 26 Nov 2003 02:53:16 -0800 (PST) (envelope-from [e-mail])
Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id 2291E63C1E; Wed, 26 Nov 2003 23:53:12 +1300 (NZDT)
Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id hAQAtf632112; Wed, 26 Nov 2003 23:55:41 +1300
Date: Wed, 26 Nov 2003 23:55:41 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Certificate Policy Standardization
Cc: [e-mail], [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>

Anders Rundgren <[e-mail]> writes:

>Policy OIDs might come handy to protect RPs from issuing authorities who
>might seek to alter their terms arbitrarily without necessarily providing
>notice to that effect. In practice, ambiguity over the exact content of
>applicable policy might render that CP unenforceable.

I've seen it used in exactly the opposite way.  If you look at the ToS for any
(well, most I guess, there might actually be some who don't try this) online
service providers (ISP, web/email hosting, online store, e-commerce site, etc
etc) they all say that they can change their ToS at any moment, with or
without notifying their customers, depending on how thorough their lawyers
are.  Yahoo spring to mind as a well-known web/email hosting example, every
now and then (the last time was within the last week or so) they change their
ToS to allow spamming of customers unless you go in and turn all the choices
off again, but since they don't have to notify you of the change most users
never find out about it until it's too late.

So what you do is define a policy OID that points to whatever the policy is
this week, and if you need to change anything you alter your policy, which
customers are expected to check by downloading it from an undocumented
location in an LDAP directory on a server in a locked filing cabinet in a
disused lavatory in the cellar with a sign on the door saying "Beware of the
Leopard", as explained in section 43, subsection 18, clause 4(a).13, paragraph
227.a of said policy.  The policy extension seems almost designed for this
use, it has provisions for specifying an OID and a means of pointing to the
policy of the week, which is just what you need.

The reason why this is approach is used is that if you changed your OID when
your policy changes, you'd have to re-issue all your certs, which no-one wants
to do.  So you define your policy to be a mutable object, push responsibility
for checking for changes onto the user in the standard manner, and you're set.

Peter.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQAJjib008529 for <[e-mail]>; Wed, 26 Nov 2003 02:19:45 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQAJier008528 for ietf-pkix-bks; Wed, 26 Nov 2003 02:19:44 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp7.hy.skanova.net (smtp7.hy.skanova.net [195.67.199.140]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQAJhib008522 for <[e-mail]>; Wed, 26 Nov 2003 02:19:44 -0800 (PST) (envelope-from [e-mail])
Received: from arport (t10o913p72.telia.com [213.64.27.192]) by smtp7.hy.skanova.net (8.12.10/8.12.10) with SMTP id hAQAJg1w012876; Wed, 26 Nov 2003 11:19:42 +0100 (CET)
Message-ID: <007901c3b406$474ce110$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Andreas Mitrakas" <[e-mail]>
Cc: <[e-mail]>
References: <01ec01c3b28f$1abbab40$0500a8c0@arport> <[e-mail]> <[e-mail]> <[e-mail]> <00e001c3b366$7c1cbc80$0500a8c0@arport> <[e-mail]>
Subject: Re: Certificate Policy Standardization
Date: Wed, 26 Nov 2003 11:15:54 +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>

>Policy OIDs might come handy to protect RPs from issuing authorities who
>might seek to alter their terms arbitrarily without necessarily providing
>notice to that effect. In practice, ambiguity over the exact content of
>applicable policy might render that CP unenforceable.

As I wrote I don't object to policy OIDs themselves, but to their use in
path validation and their configaration in RP applications.

Regarding your comment I think this is a bit wrong.  What good is
a CP OID (basically) saying "I come from a good CA"?  "Good" is
IMHO for others to vouch for.  Uncertified or unverified data is pretty
useless for trust purposes.

But if a CP OID says "I am an e-mail certificate" you could probably
use this information.  Assuming that you trust the CA...

This is why I claim that a useful CP OID system should never ever
mix tech-stuff with legal-stuff.  But that has already been done by for
example the US government.  Poor suckers!

Anders


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQ9Vfib001215 for <[e-mail]>; Wed, 26 Nov 2003 01:31:41 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQ9VfA0001214 for ietf-pkix-bks; Wed, 26 Nov 2003 01:31:41 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail3.consignia.com (mail3.consignia.com [144.87.143.83]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQ9Veib001203 for <[e-mail]>; Wed, 26 Nov 2003 01:31:40 -0800 (PST) (envelope-from [e-mail])
Received: from postoffice.co.uk (unknown [144.87.146.16]) by mail3.consignia.com (Postfix) with SMTP id 5B76D1C0ABD; Wed, 26 Nov 2003 09:31:41 +0000 (GMT)
Received: by postoffice.co.uk(Lotus SMTP MTA v4.6.6  (890.1 7-16-1999))  id 00256DEA.00345759 ; Wed, 26 Nov 2003 09:31:42 +0000
X-Lotus-FromDomain: POSTOFFICE
From: [e-mail]
To: Michael =?iso-8859-1?Q?Str=F6der?= <[e-mail]>
Cc: [e-mail], Richard Levitte - VMS Whacker <[e-mail]>
Message-ID: <[e-mail]>
Date: Wed, 26 Nov 2003 09:31:26 +0000
Subject: Re: Certificate Policy Standardization
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
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>

> Personally I'm not aware of any problems solved with the help of policy
> OIDs. ;-) Maybe others on this list feel more enlightened.

For me, OIDs are yet to have their time. As a concept they are elegant
but will resist widespread use until security-exploiting applications
support them. Until then they are destined to stay on the back-burner.
I encourage people to adopt their use, however, if only to future-proof
themselves and I don't see any harm whatsoever in embedding in a certificate
some mechanism that links the trust level it represents to a real-world
legal mechanism, even if at present the software support for such a link
is absent.

Chris




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQ9TAib000340 for <[e-mail]>; Wed, 26 Nov 2003 01:29:10 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQ9TAQN000339 for ietf-pkix-bks; Wed, 26 Nov 2003 01:29:10 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.be.ubizen.com (batty.be.ubizen.com [212.113.70.10]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQ9T8ib000310 for <[e-mail]>; Wed, 26 Nov 2003 01:29:09 -0800 (PST) (envelope-from [e-mail])
Received: (from local) by mail.be.ubizen.com id hAQ9T5YI000563 for <[e-mail]>; Wed, 26 Nov 2003 10:29:05 +0100
Received: from UNKNOWN(10.0.0.108), claiming to be "amaya.be.ubizen.com" via SMTP by batty.netvision.be, id smtpd00543aaa; Wed Nov 26 09:28:41 2003
Received: (qmail 7198 invoked from network); 26 Nov 2003 09:28:41 -0000
Received: from unknown (HELO ubi) (10.0.0.10) by amaya.be.ubizen.com with SMTP; 26 Nov 2003 09:28:38 -0000
Received: from ubizen.com (por017a.be.ubizen.com [10.0.40.67]) by ubi.be.ubizen.com (#####) with ESMTP id <[e-mail]>; Wed, 26 Nov 2003 10:28:38 +0100 (MET)
Date: Wed, 26 Nov 2003 10:31:51 +0100
From: Andreas Mitrakas <[e-mail]>
Subject: Re: Certificate Policy Standardization
To: Anders Rundgren <[e-mail]>
Cc: Steve Hanna <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 8BIT
X-Accept-Language: en
References: <01ec01c3b28f$1abbab40$0500a8c0@arport> <[e-mail]> <[e-mail]> <[e-mail]> <00e001c3b366$7c1cbc80$0500a8c0@arport>
X-Sanitizer: Out/BE
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>

Policy OIDs might come handy to protect RPs from issuing authorities who
might seek to alter their terms arbitrarily without necessarily providing
notice to that effect. In practice, ambiguity over the exact content of
applicable policy might render that CP unenforceable.

The mere fact that ETSI TS 101 456 for example mandates policy OIDs, does
not necessarily mean that the CP that features them is enforceable at all
times, simply because there might be something wrong with the rest of the
terms that voids the whole CP.

The obvious risk for the transacting parties can be unwarranted
transaction that threaten to render unenforceable legitimate practices.

andreas

Anders Rundgren wrote:

> >>Michael Ströder wrote:
> >> Again this boils down to policy OIDs just being
> >> another useless PKIX bloat extension.
>
> >One man's bloat is another man's critical feature.
>
> The problem is that you have two mechanisms for essentially
> doing the same thing with respect to the RP.  Personally I care
> much more about RPs than CAs as RPs usually outnumber
> CAs by a magnitude or more.
>
> Policy OIDs may be "perfect" as long as you stay inside of your
> "walled garden", but the USs government PKI will likely find itself up
> the creek when they are going to connect to the outside world who
> hardly ever use this feature (which I BTW cannot find a single
> "knob" for in my W2K system), or even worse, have settled on
> another set of OIDs.
>
> I would go as far as suggesting that a revised RFC3280 could
> possible even deprecate the policy stuff except for CAs/PKIs
> targetting a restricted "community".
>
> A part from this, I believe the design of the policy system leaves
> quite a bit to be desired, as a useful system should be parameterized
> so that you don't mix technical stuff  like (S/MIME, SSL) with
> more policy-like things like "quality" etc.  Note:  I don't want
> to see such a work, but if I believed in CP OIDs, this is how
> I would do...
>
> Anders



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQ972ib092600 for <[e-mail]>; Wed, 26 Nov 2003 01:07:02 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQ972rp092599 for ietf-pkix-bks; Wed, 26 Nov 2003 01:07:02 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp7.hy.skanova.net (smtp7.hy.skanova.net [195.67.199.140]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQ96wib092573 for <[e-mail]>; Wed, 26 Nov 2003 01:07:01 -0800 (PST) (envelope-from [e-mail])
Received: from arport (t10o913p72.telia.com [213.64.27.192]) by smtp7.hy.skanova.net (8.12.10/8.12.10) with SMTP id hAQ96u1w004818; Wed, 26 Nov 2003 10:06:56 +0100 (CET)
Message-ID: <002601c3b3fc$1d25e8a0$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Santosh Chokhani" <[e-mail]>, <[e-mail]>
References: <01fc01c3b366$8707d760$[e-mail]>
Subject: Re: Certificate Policy Standardization
Date: Wed, 26 Nov 2003 10:03:08 +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>

>I am not what you mean by ".....another useless PKIX bloat extension".

>If properly used by the CA and relying party systems, the certificate policy
>OID can be used to provide amount of trust the relying party should place in
>a certificate.

What Michael referred to as "bloat" is not policy identifiers themselves
but that they need another trust adminstration GUI and associated hassles.

Policy identifiers used for path validation purposes is indeed a
very "fancy" thing from a technical point of view (maybe 2% of the
people subscribed to the PKIX list can understand this part of
RFC3280...), but from an interoperability point of view they are
not that great.

Hum, there simply must be a reason why practically all commercial
CAs have selected an entirely different approach.  And that they did
this completely on their own without any commitee descision etc.

I wonder how this really happend.   Could it be...

    that it sort of feels "natural"?

/a


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQ7dbib062050 for <[e-mail]>; Tue, 25 Nov 2003 23:39:37 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQ7db72062049 for ietf-pkix-bks; Tue, 25 Nov 2003 23:39:37 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from nb2.stroeder.com (lx.yapay.inka.de [193.197.184.188]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQ7dYib061999 for <[e-mail]>; Tue, 25 Nov 2003 23:39:35 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (localhost [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id 4404E33ABF; Tue, 25 Nov 2003 16:48:08 +0100 (CET)
Received: from stroeder.com (localhost [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id 2A7E82C69E; Tue, 25 Nov 2003 16:48:07 +0100 (CET)
Message-ID: <[e-mail]>
Date: Tue, 25 Nov 2003 16:48:06 +0100
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007
X-Accept-Language: de-de, de, en-us, en
MIME-Version: 1.0
To: Richard Levitte - VMS Whacker <[e-mail]>
Cc: [e-mail]
Subject: Re: Certificate Policy Standardization
References: <[e-mail]>            <[e-mail]>            <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
X-Virus-Scanned: by AMaViS 0.3.12pre8
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id hAQ7daib062042
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>

Richard Levitte - VMS Whacker wrote:
> Michael Ströder <[e-mail]> said:
> 
> michael> >  It's not much different
> michael> > from, say, adding another public key to your PGP key ring annd
> michael> > applying trust to it...  It can be done in a cluelessly with no
> michael> > checks, or in a clued-in way with checks.
> michael> 
> michael> But the question raised here was what we will gain with
> michael> certificate policy OIDs.
> 
> Granularity,

Even more granularity? ;-)

> and a resolution to the question "can this certificate be
> used for this $10M transaction" (and other similar questions)...

I'm not a financial specialist. But IMO this kind of assertion cannot be 
generally made in a certificate. E.g. you won't be able to convince a bank 
to vouch for a $10M transaction without explaining the specific business 
case to them. As I learned from a former job shipping goods for $10M from 
Asia to Europe is a complex business process of approx. 20 steps involving 
several banks, lawyers, complicated contracts, tax and trading laws, etc. 
Well, after explaining such a business case to your bank asking for a credit 
you don't need a certificate at all.

That's why I didn't pay any attention to the warranty extension draft. 
There's no real-world use-case for it.

> After all, the problem that was "solved" with policy OIDs was the fact
> that all certificates were assumed to be equal under one (unwritten?)
> policy, correct?

Personally I'm not aware of any problems solved with the help of policy 
OIDs. ;-) Maybe others on this list feel more enlightened.

> just as mesh PKIs aren't really supported by
> quite a lot of software

I consider lack of support for mesh PKIs to be a good thing.

> michael> > michael> Or a browser vendor charging CAs for placing their
> michael> > michael> root CA cert in the default installation. Or...
> michael> > 
> michael> > That's a different story, and an action that generates such
> michael> > feelings in me that I lack words to express them (not happy
> michael> > feelings, I can tell you that).
> michael> 
> michael> Guess what would happen with certificate policy OIDs if
> michael> widely deployed.
> 
> Well, how do you solve that?  If things are this bad (and it's not
> something we know for sure, although guessing it is doesn't feel too
> far-fetched), it will stay that way whatever is invented.

Yes, it will stay this way. There's nothing we can do about this at the 
technical level. That's what security architects should take into account 
more often.

Ciao, Michael.




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQ64pib023679 for <[e-mail]>; Tue, 25 Nov 2003 22:04:51 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQ64puN023677 for ietf-pkix-bks; Tue, 25 Nov 2003 22:04:51 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.cs.auckland.ac.nz (csmail.cs.auckland.ac.nz [130.216.33.150]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQ64nib023641 for <[e-mail]>; Tue, 25 Nov 2003 22:04:49 -0800 (PST) (envelope-from [e-mail])
Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id BC97463C1E; Wed, 26 Nov 2003 19:04:47 +1300 (NZDT)
Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id hAQ67AM30729; Wed, 26 Nov 2003 19:07:10 +1300
Date: Wed, 26 Nov 2003 19:07:10 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Certificate Policy Standardization
Cc: [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>

Stephen Kent <[e-mail]> writes:

>Note that with the advent of 3280, we decided to let protocols that are PKI
>clients define extended key usage options for themselves.

I recently had to deal with someone who's working with certs from (at least)
two difference (largeish) public CAs.  One CA turned the eKU into a kind of
lamp test packet, with every usage they could think of set ("Let's see, what
have we got here... timestamping, IPsec, encrypted filesystem, Win2K logon,
and S/MIME, that sounds like a sensible combination of usages for a private
key").  The other CA didn't populate the eKU at all, justifying it with
"Everything ignores those anyway, so it doesn't matter what you put in there"
(obviously they have to ignore them, in order to allow certs like the ones I'm
describing to function).  In the end after taking legal considerations into
account the conclusion was to define a new eKU, "doWhatISay", defined as "This
key may only be used as we say it can be used" (it's not quite worded like
that in their CPS, that'll take another six months for the lawyers to sort
out).

I dunno about the situation in the PKIX reality, but in the real world from
the legal point of view (which is what matters in the end) that's about the
best way to make use of eKU.

Peter.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQ64Vib023568 for <[e-mail]>; Tue, 25 Nov 2003 22:04:31 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQ64VaT023567 for ietf-pkix-bks; Tue, 25 Nov 2003 22:04:31 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.Mi8.com (onsightmail.mi8.com [63.240.6.44]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQ64Pib023499 for <[e-mail]>; Tue, 25 Nov 2003 22:04:27 -0800 (PST) (envelope-from [e-mail])
Received: from 172.16.1.195 by mail.Mi8.com with ESMTP (Welcome to Mi8 Corporation www.Mi8.com); Wed, 26 Nov 2003 01:01:21 -0500
X-Server-Uuid: 80AAE364-E36E-44A0-9EE3-7F6B7712B6DE
Received: from NYCEXSMTP03.Mi8.com ([172.16.1.194]) by NYCEXSMTP03.Mi8.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 26 Nov 2003 01:00:10 -0500
Received: from mail pickup service by NYCEXSMTP03.Mi8.com with Microsoft SMTPSVC; Wed, 26 Nov 2003 00:59:03 -0500
Received: from mail.Mi8.com ([172.16.1.186]) by NYCEXSMTP03.Mi8.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 25 Nov 2003 11:05:53 -0500
Received: from 68.162.232.130 by mail.Mi8.com with ESMTP (Welcome to Mi8 Corporation www.Mi8.com); Tue, 25 Nov 2003 11:05:44 -0500
X-Server-Uuid: 80AAE364-E36E-44A0-9EE3-7F6B7712B6DE
Received: from above.proper.com (above.proper.com [208.184.76.39]) by the-humungus.corestreet.com (8.12.8/8.12.8) with ESMTP id hAPG5hEj017578; Tue, 25 Nov 2003 11:05:44 -0500
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAPFCWib085942 for <[e-mail]>; Tue, 25 Nov 2003 07:12:32 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com ( 8.12.10/8.12.9/Submit) id hAPFCWY9085941 for ietf-pkix-bks; Tue, 25 Nov 2003 07:12:32 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mtiwmhc11.worldnet.att.net (mtiwmhc11.worldnet.att.net [204.127.131.115]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAPFCVib085930 for <[e-mail]>; Tue, 25 Nov 2003 07:12:32 -0800 (PST) (envelope-from [e-mail])
Received: from wchokhani ( 24.st.louis-31-33rs.mo.dial-access.att.net[12.74.112.24]) by worldnet.att.net (mtiwmhc11) with SMTP id <2003112515122511100qrkohe>; Tue, 25 Nov 2003 15:12:26 +0000
From: "Santosh Chokhani" <[e-mail]>
To: [e-mail]
Subject: RE: Certificate Policy Standardization
Date: Tue, 25 Nov 2003 10:11:59 -0500
Message-ID: <01fc01c3b366$8707d760$[e-mail]>
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id hAPFCWib085937
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-MIME-Autoconverted: from 8bit to quoted-printable by the-humungus.corestreet.com id hAPG5hEj017578
X-WSS-ID: 13DDA25211S592270-01-01
X-OriginalArrivalTime: 25 Nov 2003 16:05:53.0002 (UTC) FILETIME=[005794A0:01C3B36E]
X-WSS-ID: 13DA9E1F160187218-15-01
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 hAQ64Vib023561
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>

Michael:

I am not what you mean by ".....another useless PKIX bloat extension".

If properly used by the CA and relying party systems, the certificate policy
OID can be used to provide amount of trust the relying party should place in
a certificate.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Michael Ströder
Sent: Tuesday, November 25, 2003 2:41 AM
To: Steve Hanna
Cc: Anders Rundgren; [e-mail]
Subject: Re: Certificate Policy Standardization



Steve Hanna wrote:
> Applications can use certificate policy OIDs to make
> trust decisions today. The application just needs to
> have a way for the user or administrator to configure
> the list of acceptable certificate policies (called
> the user-initial-policy-set in RFC 3280).

Which is as bad as the user or administrator installing trusted root CA 
certs. Or a browser vendor charging CAs for placing their root CA cert in 
the default installation. Or...

Again this boils down to policy OIDs just being another useless PKIX bloat 
extension.

Ciao, Michael.







Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQ5Ycib020234 for <[e-mail]>; Tue, 25 Nov 2003 21:34:39 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQ5YYDg020227 for ietf-pkix-bks; Tue, 25 Nov 2003 21:34:35 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.Mi8.com (nycgw01.mi8.com [63.240.6.41]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQ5YQib020007 for <[e-mail]>; Tue, 25 Nov 2003 21:34:31 -0800 (PST) (envelope-from [e-mail])
Received: from 172.16.1.44 by mail.Mi8.com with ESMTP (Welcome to Mi8 Corporation www.Mi8.com (MMS v5.5.3)); Wed, 26 Nov 2003 00:28:16 -0400
Received: from nycexsmtp02.Mi8.com ([172.16.1.180]) by NYCEXSMTP02.Mi8.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 26 Nov 2003 00:27:44 -0500
Received: from mail pickup service by nycexsmtp02.Mi8.com with Microsoft SMTPSVC; Wed, 26 Nov 2003 00:27:43 -0500
Received: from mail.Mi8.com ([172.16.1.185]) by NYCEXSMTP03.Mi8.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 25 Nov 2003 10:28:25 -0500
Received: from 68.162.232.130 by mail.Mi8.com with ESMTP (Welcome to Mi8 Corporation www.Mi8.com (MMS v5.5.3)); Tue, 25 Nov 2003 10:28:17 -0400
Received: from above.proper.com (above.proper.com [208.184.76.39]) by the-humungus.corestreet.com (8.12.8/8.12.8) with ESMTP id hAPFSGEj015548; Tue, 25 Nov 2003 10:28:16 -0500
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAPEv3ib084872 for <[e-mail]>; Tue, 25 Nov 2003 06:57:03 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com ( 8.12.10/8.12.9/Submit) id hAPEv3Uj084871 for ietf-pkix-bks; Tue, 25 Nov 2003 06:57:03 -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.10/8.12.8) with ESMTP id hAPEuxib084863 for <[e-mail]>; Tue, 25 Nov 2003 06:57:02 -0800 (PST) ( envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id hAPEussj017466; Tue, 25 Nov 2003 09:56:54 -0500 (EST)
MIME-Version: 1.0
X-Sender: [e-mail]
Message-ID: <p06010201bbe91c03cb62@[128.89.89.75]>
In-Reply-To: <[e-mail]>
References: <01ec01c3b28f$1abbab40$0500a8c0@arport> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Tue, 25 Nov 2003 09:51:19 -0500
To: "Richard Levitte - VMS Whacker" <[e-mail]>
From: "Stephen Kent" <[e-mail]>
Subject: Re: Certificate Policy Standardization
cc: [e-mail]
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-WSS-ID: 13DDAA9B441023-01-01
X-OriginalArrivalTime: 25 Nov 2003 15:28:25.0410 (UTC) FILETIME=[C4AC4220:01C3B368]
X-WSS-ID: 13DAE65B146967-01-01
Content-Type: text/plain; charset=us-ascii; 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>

>
>
>michael> Again this boils down to policy OIDs just being another
>michael> useless PKIX bloat extension.
>
>Uhmm, I might be historically clueless here: are policy OIDs really a
>PKIX invention?
>
Policy OIDs are part of X.509, not a PKIX invention.  The complaint 
is just the usual carping about standards, with inaccurate 
attribution. In Michael's world view blame can be distributed 
universally, at least in the direction of others :-)

Steve




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQ5Aqib018970 for <[e-mail]>; Tue, 25 Nov 2003 21:10:52 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQ5AqHX018969 for ietf-pkix-bks; Tue, 25 Nov 2003 21:10:52 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.Mi8.com (onsightmail.mi8.com [63.240.6.44]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQ59Zib018940 for <[e-mail]>; Tue, 25 Nov 2003 21:09:35 -0800 (PST) (envelope-from [e-mail])
Received: from 172.16.1.44 by mail.Mi8.com with ESMTP (Welcome to Mi8 Corporation www.Mi8.com); Wed, 26 Nov 2003 00:09:19 -0500
X-Server-Uuid: 80AAE364-E36E-44A0-9EE3-7F6B7712B6DE
Received: from nycexsmtp02.Mi8.com ([172.16.1.180]) by NYCEXSMTP02.Mi8.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 26 Nov 2003 00:09:06 -0500
Received: from mail pickup service by nycexsmtp02.Mi8.com with Microsoft SMTPSVC; Wed, 26 Nov 2003 00:08:29 -0500
Received: from mail.Mi8.com ([172.16.1.186]) by NYCEXSMTP03.Mi8.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 25 Nov 2003 10:20:34 -0500
Received: from 68.162.232.130 by mail.Mi8.com with ESMTP (Welcome to Mi8 Corporation www.Mi8.com); Tue, 25 Nov 2003 10:20:13 -0500
X-Server-Uuid: 80AAE364-E36E-44A0-9EE3-7F6B7712B6DE
Received: from above.proper.com (above.proper.com [208.184.76.39]) by the-humungus.corestreet.com (8.12.8/8.12.8) with ESMTP id hAPFKCEj014857; Tue, 25 Nov 2003 10:20:12 -0500
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAPEgTib084267 for <[e-mail]>; Tue, 25 Nov 2003 06:42:29 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com ( 8.12.10/8.12.9/Submit) id hAPEgTGT084265 for ietf-pkix-bks; Tue, 25 Nov 2003 06:42:29 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13] ) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAPEgSib084253 for <[e-mail]>; Tue, 25 Nov 2003 06:42:28 -0800 (PST) ( envelope-from [e-mail])
Received: from sydney.East.Sun.COM ([129.148.9.16]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id hAPEgNUP028399; Tue, 25 Nov 2003 06:42:23 -0800 (PST)
Received: from sun.com (dhcp-ubur02-75-161 [129.148.75.161]) by sydney.East.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id hAPEgMB08103; Tue, 25 Nov 2003 09:42:22 -0500 (EST)
Message-ID: <[e-mail]>
Date: Tue, 25 Nov 2003 09:41:27 -0500
From: "Steve Hanna" <[e-mail]>
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Michael =?iso-8859-1?Q?Str=F6der?=" <[e-mail]>
cc: "Anders Rundgren" <[e-mail]>, [e-mail]
Subject: Re: Certificate Policy Standardization
References: <01ec01c3b28f$1abbab40$0500a8c0@arport> <[e-mail]> <[e-mail]>
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-WSS-ID: 13DDACA711S576232-01-01
X-OriginalArrivalTime: 25 Nov 2003 15:20:34.0438 (UTC) FILETIME=[ABF3A260:01C3B367]
X-WSS-ID: 13DAEAC8160153673-15-01
Content-Type: multipart/signed; boundary=------------msD0C286071AFEC49362983560; protocol="application/x-pkcs7-signature"; micalg=sha1
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.

--------------msD0C286071AFEC49362983560
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Michael Ströder wrote:
> Again this boils down to policy OIDs just being
> another useless PKIX bloat extension.

One man's bloat is another man's critical feature.

Some user communities don't care much about certificate
policy or have only one policy for their whole PKI.
They don't need policy OIDs. Other user communities
(especially government) want to support multiple
policies within a single PKI. For them, policy OIDs
are perfect.

I'm afraid that your perspective on PKI is too narrow.

Thanks,

Steve
--------------msD0C286071AFEC49362983560
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

MIIIEAYJKoZIhvcNAQcCoIIIATCCB/0CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
BeMwggKjMIICDKADAgECAgMKVAgwDQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlpBMRUw
EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhh
d3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwg
RnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA3MTExMTAxNTFaFw0wNDA3MTAxMTAxNTFa
MGgxDjAMBgNVBAQTBUhhbm5hMRUwEwYDVQQqEwxTdGVwaGVuIFJvc3MxGzAZBgNVBAMTElN0
ZXBoZW4gUm9zcyBIYW5uYTEiMCAGCSqGSIb3DQEJARYTc3RldmUuaGFubmFAc3VuLmNvbTCB
nzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAoxRk/abMPe7Km2EqpD2FZXzjiBGUHhIdNlIO
9W6mdCQro1xMc+sv+93UuVnIzse+XA67Tqx4g5FdoQ+PI8TQYemYSkTD9GitgU563ypu03UV
86zTJA7u9zVkNv/qL2LRKZ9BXy2Smtet+PUh3nYjMh/ZY7LQxQzmdu1Zunue+yECAwEAAaMw
MC4wHgYDVR0RBBcwFYETc3RldmUuaGFubmFAc3VuLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqG
SIb3DQEBBAUAA4GBAHbpX0TKiOFu1vxKc3nAOcUHwoci5kinboYrnjWcl37mMXXbBFntaYRM
9LxpGtHdPm7F4pAviKp8bnFzTU46OyUw3kNUAVGDeWYVQC76f0dDZdA313Tn88UZYa+N6O8W
bO8wjKA2vg+yx79WXJCFDu+TpsG/28NKPdH42w8LEOVHMIIDODCCAqGgAwIBAgIQZkVyt8x0
9c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl
c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3Vs
dGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UE
AxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h
bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgyNzIzNTk1OVow
gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg
VG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEo
MCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzANBgkqhkiG9w0B
AQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUqbXA8+tyu9+50
bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC9tewkd4c6avg
GAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEwwKQYDVR0RBCIw
IKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQIMAYBAf8CAQAw
CwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF151j2YwCYTYoEi
pxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59sogxYjTFCCRFs
sBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TYyWJirQXGMYIB
9TCCAfECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQ
BgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0
ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAID
ClQIMAkGBSsOAwIaBQCggbEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B
CQUxDxcNMDMxMTI1MTQ0MTI3WjAjBgkqhkiG9w0BCQQxFgQU90ml8SXUBjkgZJLdaENvopz+
7h4wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4D
AgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYA4lYA5
O1kD0BChNh7zVrKjNuAS3V1CAgM9jN7QGxUURFGWxn60K4U+5K5T4yeKVkBVdxNLvU4wq6vm
eekkFWCgiRZcB/MPXwHBEEj6snMOjqCeYua5tAVTEDjrEV8XyxzpYhkEyJjfYwEQhqWjKNHE
/iNB1msEK/n2FX9tJjhX5w==
--------------msD0C286071AFEC49362983560--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQ575ib018856 for <[e-mail]>; Tue, 25 Nov 2003 21:07:06 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQ5751A018855 for ietf-pkix-bks; Tue, 25 Nov 2003 21:07:05 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.Mi8.com (nycgw01.mi8.com [63.240.6.41]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQ571ib018846 for <[e-mail]>; Tue, 25 Nov 2003 21:07:03 -0800 (PST) (envelope-from [e-mail])
Received: from 172.16.1.44 by mail.Mi8.com with ESMTP (Welcome to Mi8 Corporation www.Mi8.com (MMS v5.5.3)); Wed, 26 Nov 2003 00:06:08 -0400
Received: from nycexsmtp02.Mi8.com ([172.16.1.180]) by NYCEXSMTP02.Mi8.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 26 Nov 2003 00:01:38 -0500
Received: from mail pickup service by nycexsmtp02.Mi8.com with Microsoft SMTPSVC; Tue, 25 Nov 2003 23:53:33 -0500
Received: from mail.Mi8.com ([172.16.1.186]) by NYCEXSMTP03.Mi8.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 25 Nov 2003 10:20:28 -0500
Received: from 68.162.232.130 by mail.Mi8.com with ESMTP (Welcome to Mi8 Corporation www.Mi8.com); Tue, 25 Nov 2003 10:20:13 -0500
X-Server-Uuid: 80AAE364-E36E-44A0-9EE3-7F6B7712B6DE
Received: from above.proper.com (above.proper.com [208.184.76.39]) by the-humungus.corestreet.com (8.12.8/8.12.8) with ESMTP id hAPFKCEj014858; Tue, 25 Nov 2003 10:20:12 -0500
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAPEl0ib084483 for <[e-mail]>; Tue, 25 Nov 2003 06:47:00 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com ( 8.12.10/8.12.9/Submit) id hAPEl0Xv084482 for ietf-pkix-bks; Tue, 25 Nov 2003 06:47:00 -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.10/8.12.8) with ESMTP id hAPEkuib084459 for <[e-mail]>; Tue, 25 Nov 2003 06:46:59 -0800 (PST) ( envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id hAPEkqsj016851; Tue, 25 Nov 2003 09:46:52 -0500 (EST)
MIME-Version: 1.0
X-Sender: [e-mail]
Message-ID: <p06010200bbe919d7490f@[128.89.89.75]>
In-Reply-To: <000301c3b350$3839e620$010aff0a@tsg>
References: <01ec01c3b28f$1abbab40$0500a8c0@arport> <007d01c3b2a7$60857f30$010aff0a@tsg> <p06010209bbe7f130fc1f@[128.89.89.75]> <000301c3b350$3839e620$010aff0a@tsg>
Date: Tue, 25 Nov 2003 09:43:43 -0500
To: "todd glassey" <[e-mail]>
From: "Stephen Kent" <[e-mail]>
Subject: Re: Certificate Policy Standardization
cc: [e-mail]
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-WSS-ID: 13DDACA711S576227-01-01
X-OriginalArrivalTime: 25 Nov 2003 15:20:28.0328 (UTC) FILETIME=[A84F5280:01C3B367]
X-WSS-ID: 13DAEB84135563-14-01
Content-Type: text/plain; charset=us-ascii; 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>

At 17:56 -0800 11/24/03, todd glassey wrote:
>Charter or not Stephen - its something that is critically missing in all
>eBusiness processes. That being some uniform method of invoking the coverage
>of eSign acts and some method of specifying in the transaction receipt, what
>jurisdiction the specific act is done under.
>
>That you done want this as part of PKIX is also not relevant as to whether
>its needed, only to whether PKIX is allowed to focus on it.
>
>Todd :-)

Todd,

The relevant discussion for this list is whether the formulation of 
such policies, their publication, and assignment of OIDs is a PKIX 
topic.  The answer is NO to all three of these possible activities, 
in the PKIX context.

If you are convinced this is an important problem, take it to a forum 
when you can pursue it.

Steve

P.S.  I am totally unconvinced that we require a standard set of 
policies to be established by a standards organization like the IETF, 
ITU, ASMI, etc.  As others have noted, CAs are free to create their 
own and they usually do. If I were operating an EDI net of some sort 
I might create one for that context and operate a CA for the 
subscribers.  At most one needs to register OIDs to avoid collisions. 
But, reference to a CPS can be effected via out-of-band means, or via 
a proprietary extension; there are lots of ways people deal with this 
issue today.




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAPFtLib088186 for <[e-mail]>; Tue, 25 Nov 2003 07:55:21 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAPFtLI9088185 for ietf-pkix-bks; Tue, 25 Nov 2003 07:55:21 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from seguridata1.seguridata.com ([200.57.34.107]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAPFtKib088174 for <[e-mail]>; Tue, 25 Nov 2003 07:55:20 -0800 (PST) (envelope-from [e-mail])
Received: from MarsXP ([200.67.231.235]) by seguridata1.seguridata.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 25 Nov 2003 09:56:13 -0600
From: "Miguel Rodriguez" <[e-mail]>
To: <[e-mail]>
Subject: RE: TSA certificate content
Date: Tue, 25 Nov 2003 09:56:59 -0600
Message-ID: <000201c3b36c$c894a310$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-OriginalArrivalTime: 25 Nov 2003 15:56:14.0140 (UTC) FILETIME=[A7503FC0:01C3B36C]
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 think key usage is not relevant here, can even be absent. The relevant
one is the EKU extension. That's how we do it in our implementation.

Miguel A Rodriguez
SeguriDATA
Mexico

> -----Original Message-----
> From: [e-mail]
[mailto:[e-mail]]
> On Behalf Of Peter Sylvester
> Sent: Monday, November 24, 2003 7:30 AM
> To: [e-mail]
> Subject: TSA certificate content
> 
> 
> 
> I would like to hear some opinion about the setting
> of the extension keyUsage in a certificate for a
> 3161 TSA.
> 
> The question is whether a certificate contain no
> keyUsage extension at all and only an extended
> key usage with the appropriate key purpose
> is conformant with 3161 and 3280.
> 
> Peter




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAPFkxib087869 for <[e-mail]>; Tue, 25 Nov 2003 07:46:59 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAPFkxFV087868 for ietf-pkix-bks; Tue, 25 Nov 2003 07:46:59 -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.10/8.12.8) with ESMTP id hAPFkwib087859 for <[e-mail]>; Tue, 25 Nov 2003 07:46:58 -0800 (PST) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id hAPFkrsj020591 for <[e-mail]>; Tue, 25 Nov 2003 10:46:54 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p06010208bbe92888baa0@[128.89.89.75]>
Date: Tue, 25 Nov 2003 10:42:30 -0500
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: meeting minutes, slides
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
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 received comments on the draft minutes from several folks, and 
have made the requested corrections.  The final version of the 
minutes has just been sent to the secretariat, and will be available 
on the IETF web site, in December. The slides presented during the 
meeting also have been submitted for posting.

Steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAPFJJib086652 for <[e-mail]>; Tue, 25 Nov 2003 07:19:19 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAPFJJsk086649 for ietf-pkix-bks; Tue, 25 Nov 2003 07:19:19 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAPFJHib086639 for <[e-mail]>; Tue, 25 Nov 2003 07:19:17 -0800 (PST) (envelope-from [e-mail])
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 hAPFIZ19006989; Tue, 25 Nov 2003 10:18:35 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 25 Nov 2003 10:18:09 -0500
To: [e-mail]
From: Tim Polk <[e-mail]>
Subject: WG last call: draft-pkix-acpolicies-extn-03.txt
Cc: [e-mail], [e-mail], Denis Pinkas <[e-mail]>
In-Reply-To: <[e-mail]>
References: <003601c3856d$6c1b6510$[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>

Denis & Chris

I have reviewed the new document and am satisfied that all WG comments have 
been addressed.

The only outstanding issues identified on the list are the ASN.1 reference 
identified by Jim Schaad and inserting the  OIDs  assigned by Russ Housley.

However, I reviewed the "ID nits" (see http://www.ietf.org/ID-nits.html) 
and identified a number of minor issues that also need to be addressed:

(1) The current Abstract needs to be expanded; the requirement is that the 
abstract "be meaningful to someone not versed in the technology".
(2) Please keep RFC 3280 in the Normative References section.  Please 
create an Informative References section and move the ISO X.509 
specification to that section.
(3) Please add an IPR section and include the IPR notices in RFC 2026 
10.4(a) and 10.4(b). (See http://www.ietf.org/rfc/rfc2026.txt for the exact 
text.) [Note: To my knowledge, no IPR claims are known.  If that is not 
correct, please add 10.4(d) and let me know ASAP if we need to get an IPR 
notice filed with the IESG.]
(4) Please give some thoughts to your security considerations.  I believe 
they need to be expanded.  For example, I believe you should re-emphasize 
that trusting policy alone is insufficient.  The relying party must 
determine that the AC has the appropriate policy and was issued by a 
trusted AA.  I believe that all the security considerations for RFC 3281 
still apply, that might be worth adding.

Please submit a new draft that resolves the ASN.1 issues and the four 
issues that I have identified.  That draft will be forwarded to the ADs for 
consideration by the IESG.

Thanks,

Tim Polk



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAPFFtib086280 for <[e-mail]>; Tue, 25 Nov 2003 07:15:55 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAPFFtpT086279 for ietf-pkix-bks; Tue, 25 Nov 2003 07:15:55 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp4.hy.skanova.net (smtp4.hy.skanova.net [195.67.199.133]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAPFFsib086265 for <[e-mail]>; Tue, 25 Nov 2003 07:15:54 -0800 (PST) (envelope-from [e-mail])
Received: from arport (t10o913p22.telia.com [213.64.27.142]) by smtp4.hy.skanova.net (8.12.10/8.12.10) with SMTP id hAPFFjBZ007435; Tue, 25 Nov 2003 16:15:45 +0100 (CET)
Message-ID: <00e001c3b366$7c1cbc80$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Steve Hanna" <[e-mail]>
Cc: <[e-mail]>
References: <01ec01c3b28f$1abbab40$0500a8c0@arport> <[e-mail]> <[e-mail]> <[e-mail]>
Subject: Re: Certificate Policy Standardization
Date: Tue, 25 Nov 2003 16:11:57 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
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>

>>Michael Ströder wrote:
>> Again this boils down to policy OIDs just being
>> another useless PKIX bloat extension.

>One man's bloat is another man's critical feature.

The problem is that you have two mechanisms for essentially
doing the same thing with respect to the RP.  Personally I care
much more about RPs than CAs as RPs usually outnumber
CAs by a magnitude or more.

Policy OIDs may be "perfect" as long as you stay inside of your
"walled garden", but the USs government PKI will likely find itself up
the creek when they are going to connect to the outside world who
hardly ever use this feature (which I BTW cannot find a single
"knob" for in my W2K system), or even worse, have settled on
another set of OIDs.

I would go as far as suggesting that a revised RFC3280 could
possible even deprecate the policy stuff except for CAs/PKIs
targetting a restricted "community".

A part from this, I believe the design of the policy system leaves
quite a bit to be desired, as a useful system should be parameterized
so that you don't mix technical stuff  like (S/MIME, SSL) with
more policy-like things like "quality" etc.  Note:  I don't want
to see such a work, but if I believed in CP OIDs, this is how
I would do...

Anders



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAPFCWib085942 for <[e-mail]>; Tue, 25 Nov 2003 07:12:32 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAPFCWY9085941 for ietf-pkix-bks; Tue, 25 Nov 2003 07:12:32 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mtiwmhc11.worldnet.att.net (mtiwmhc11.worldnet.att.net [204.127.131.115]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAPFCVib085930 for <[e-mail]>; Tue, 25 Nov 2003 07:12:32 -0800 (PST) (envelope-from [e-mail])
Received: from wchokhani (24.st.louis-31-33rs.mo.dial-access.att.net[12.74.112.24]) by worldnet.att.net (mtiwmhc11) with SMTP id <2003112515122511100qrkohe>; Tue, 25 Nov 2003 15:12:26 +0000
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: Certificate Policy Standardization
Date: Tue, 25 Nov 2003 10:11:59 -0500
Message-ID: <01fc01c3b366$8707d760$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id hAPFCWib085937
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>

Michael:

I am not what you mean by ".....another useless PKIX bloat extension".

If properly used by the CA and relying party systems, the certificate policy
OID can be used to provide amount of trust the relying party should place in
a certificate.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Michael Ströder
Sent: Tuesday, November 25, 2003 2:41 AM
To: Steve Hanna
Cc: Anders Rundgren; [e-mail]
Subject: Re: Certificate Policy Standardization



Steve Hanna wrote:
> Applications can use certificate policy OIDs to make
> trust decisions today. The application just needs to
> have a way for the user or administrator to configure
> the list of acceptable certificate policies (called
> the user-initial-policy-set in RFC 3280).

Which is as bad as the user or administrator installing trusted root CA 
certs. Or a browser vendor charging CAs for placing their root CA cert in 
the default installation. Or...

Again this boils down to policy OIDs just being another useless PKIX bloat 
extension.

Ciao, Michael.




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAPEv3ib084872 for <[e-mail]>; Tue, 25 Nov 2003 06:57:03 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAPEv3Uj084871 for ietf-pkix-bks; Tue, 25 Nov 2003 06:57:03 -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.10/8.12.8) with ESMTP id hAPEuxib084863 for <[e-mail]>; Tue, 25 Nov 2003 06:57:02 -0800 (PST) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id hAPEussj017466; Tue, 25 Nov 2003 09:56:54 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p06010201bbe91c03cb62@[128.89.89.75]>
In-Reply-To: <[e-mail]>
References: <01ec01c3b28f$1abbab40$0500a8c0@arport> <[e-mail]>            <[e-mail]> <[e-mail]>
Date: Tue, 25 Nov 2003 09:51:19 -0500
To: Richard Levitte - VMS Whacker <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Certificate Policy Standardization
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
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>

>
>
>michael> Again this boils down to policy OIDs just being another
>michael> useless PKIX bloat extension.
>
>Uhmm, I might be historically clueless here: are policy OIDs really a
>PKIX invention?
>
Policy OIDs are part of X.509, not a PKIX invention.  The complaint 
is just the usual carping about standards, with inaccurate 
attribution. In Michael's world view blame can be distributed 
universally, at least in the direction of others :-)

Steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAPEl0ib084483 for <[e-mail]>; Tue, 25 Nov 2003 06:47:00 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAPEl0Xv084482 for ietf-pkix-bks; Tue, 25 Nov 2003 06:47:00 -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.10/8.12.8) with ESMTP id hAPEkuib084459 for <[e-mail]>; Tue, 25 Nov 2003 06:46:59 -0800 (PST) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id hAPEkqsj016851; Tue, 25 Nov 2003 09:46:52 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p06010200bbe919d7490f@[128.89.89.75]>
In-Reply-To: <000301c3b350$3839e620$010aff0a@tsg>
References: <01ec01c3b28f$1abbab40$0500a8c0@arport> <007d01c3b2a7$60857f30$010aff0a@tsg> <p06010209bbe7f130fc1f@[128.89.89.75]> <000301c3b350$3839e620$010aff0a@tsg>
Date: Tue, 25 Nov 2003 09:43:43 -0500
To: "todd glassey" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Certificate Policy Standardization
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
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 17:56 -0800 11/24/03, todd glassey wrote:
>Charter or not Stephen - its something that is critically missing in all
>eBusiness processes. That being some uniform method of invoking the coverage
>of eSign acts and some method of specifying in the transaction receipt, what
>jurisdiction the specific act is done under.
>
>That you done want this as part of PKIX is also not relevant as to whether
>its needed, only to whether PKIX is allowed to focus on it.
>
>Todd :-)

Todd,

The relevant discussion for this list is whether the formulation of 
such policies, their publication, and assignment of OIDs is a PKIX 
topic.  The answer is NO to all three of these possible activities, 
in the PKIX context.

If you are convinced this is an important problem, take it to a forum 
when you can pursue it.

Steve

P.S.  I am totally unconvinced that we require a standard set of 
policies to be established by a standards organization like the IETF, 
ITU, ASMI, etc.  As others have noted, CAs are free to create their 
own and they usually do. If I were operating an EDI net of some sort 
I might create one for that context and operate a CA for the 
subscribers.  At most one needs to register OIDs to avoid collisions. 
But, reference to a CPS can be effected via out-of-band means, or via 
a proprietary extension; there are lots of ways people deal with this 
issue today.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAPEgTib084267 for <[e-mail]>; Tue, 25 Nov 2003 06:42:29 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAPEgTGT084265 for ietf-pkix-bks; Tue, 25 Nov 2003 06:42:29 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAPEgSib084253 for <[e-mail]>; Tue, 25 Nov 2003 06:42:28 -0800 (PST) (envelope-from [e-mail])
Received: from sydney.East.Sun.COM ([129.148.9.16]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id hAPEgNUP028399; Tue, 25 Nov 2003 06:42:23 -0800 (PST)
Received: from sun.com (dhcp-ubur02-75-161 [129.148.75.161]) by sydney.East.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id hAPEgMB08103; Tue, 25 Nov 2003 09:42:22 -0500 (EST)
Message-ID: <[e-mail]>
Date: Tue, 25 Nov 2003 09:41:27 -0500
From: Steve Hanna <[e-mail]>
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Michael =?iso-8859-1?Q?Str=F6der?= <[e-mail]>
CC: Anders Rundgren <[e-mail]>, [e-mail]
Subject: Re: Certificate Policy Standardization
References: <01ec01c3b28f$1abbab40$0500a8c0@arport> <[e-mail]> <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msD0C286071AFEC49362983560"
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.

--------------msD0C286071AFEC49362983560
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Michael Ströder wrote:
> Again this boils down to policy OIDs just being
> another useless PKIX bloat extension.

One man's bloat is another man's critical feature.

Some user communities don't care much about certificate
policy or have only one policy for their whole PKI.
They don't need policy OIDs. Other user communities
(especially government) want to support multiple
policies within a single PKI. For them, policy OIDs
are perfect.

I'm afraid that your perspective on PKI is too narrow.

Thanks,

Steve
--------------msD0C286071AFEC49362983560
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

MIIIEAYJKoZIhvcNAQcCoIIIATCCB/0CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
BeMwggKjMIICDKADAgECAgMKVAgwDQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlpBMRUw
EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhh
d3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwg
RnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA3MTExMTAxNTFaFw0wNDA3MTAxMTAxNTFa
MGgxDjAMBgNVBAQTBUhhbm5hMRUwEwYDVQQqEwxTdGVwaGVuIFJvc3MxGzAZBgNVBAMTElN0
ZXBoZW4gUm9zcyBIYW5uYTEiMCAGCSqGSIb3DQEJARYTc3RldmUuaGFubmFAc3VuLmNvbTCB
nzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAoxRk/abMPe7Km2EqpD2FZXzjiBGUHhIdNlIO
9W6mdCQro1xMc+sv+93UuVnIzse+XA67Tqx4g5FdoQ+PI8TQYemYSkTD9GitgU563ypu03UV
86zTJA7u9zVkNv/qL2LRKZ9BXy2Smtet+PUh3nYjMh/ZY7LQxQzmdu1Zunue+yECAwEAAaMw
MC4wHgYDVR0RBBcwFYETc3RldmUuaGFubmFAc3VuLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqG
SIb3DQEBBAUAA4GBAHbpX0TKiOFu1vxKc3nAOcUHwoci5kinboYrnjWcl37mMXXbBFntaYRM
9LxpGtHdPm7F4pAviKp8bnFzTU46OyUw3kNUAVGDeWYVQC76f0dDZdA313Tn88UZYa+N6O8W
bO8wjKA2vg+yx79WXJCFDu+TpsG/28NKPdH42w8LEOVHMIIDODCCAqGgAwIBAgIQZkVyt8x0
9c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl
c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3Vs
dGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UE
AxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h
bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgyNzIzNTk1OVow
gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg
VG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEo
MCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzANBgkqhkiG9w0B
AQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUqbXA8+tyu9+50
bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC9tewkd4c6avg
GAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEwwKQYDVR0RBCIw
IKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQIMAYBAf8CAQAw
CwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF151j2YwCYTYoEi
pxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59sogxYjTFCCRFs
sBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TYyWJirQXGMYIB
9TCCAfECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQ
BgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0
ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAID
ClQIMAkGBSsOAwIaBQCggbEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B
CQUxDxcNMDMxMTI1MTQ0MTI3WjAjBgkqhkiG9w0BCQQxFgQU90ml8SXUBjkgZJLdaENvopz+
7h4wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4D
AgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYA4lYA5
O1kD0BChNh7zVrKjNuAS3V1CAgM9jN7QGxUURFGWxn60K4U+5K5T4yeKVkBVdxNLvU4wq6vm
eekkFWCgiRZcB/MPXwHBEEj6snMOjqCeYua5tAVTEDjrEV8XyxzpYhkEyJjfYwEQhqWjKNHE
/iNB1msEK/n2FX9tJjhX5w==
--------------msD0C286071AFEC49362983560--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAPDR9ib079904 for <[e-mail]>; Tue, 25 Nov 2003 05:27:09 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAPDR9QU079903 for ietf-pkix-bks; Tue, 25 Nov 2003 05:27:09 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from firewall.andxor.com (firewall.andxor.it [195.223.2.2]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAPDR4ib079893 for <[e-mail]>; Tue, 25 Nov 2003 05:27:07 -0800 (PST) (envelope-from [e-mail])
Received: from LELLO (lello.andxor.it [195.223.2.223]) by firewall.andxor.com (8.12.6p2/8.12.3) with SMTP id hAPDQvqo083979; Tue, 25 Nov 2003 14:27:01 +0100 (CET) (envelope-from [e-mail])
From: "Ing. Raffaello Galli" <[e-mail]>
To: "Peter Sylvester" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: R: Re[2]: TSA certificate content
Date: Tue, 25 Nov 2003 14:27:45 +0100
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
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->> As the specification actually, I also think that absence of keyUsage is
->> permissible.
->>
->> But I wonder why a certificate do not include keyUsage extension, though
->> the certificate declares extendedKeyUsage.
->> What kind of situation does it apply in?
->>
->> I have no idea about the reason to use only extendedKeyUsage extension
->> for a certificate without using keyUsage extension...
->>
->
->In RFC 3280 page 41 about extendedkeyUsage:
->
->   If the extension is present, then the certificate MUST only be used
->   for one of the purposes indicated.
->
->I understand this as "no need to set anything at all in keyUsage."

No I do not agree,  as I've explained in my previos mail according to the
RFC3161
the extendedkeyUsage (id-kp-timeStamping) MUST be the only one.
This doesn't  mean that the Key Usage should not be set.
In fact in RFC 3280 (page 42) regarding id-kp-timeStamping  says:
"Key usage bits may be consistent: digitalSignature and/or nonRepudiation"

Cheer
Raffaello





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAPCbRib077526 for <[e-mail]>; Tue, 25 Nov 2003 04:37:27 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAPCbR02077525 for ietf-pkix-bks; Tue, 25 Nov 2003 04:37:27 -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.10/8.12.8) with ESMTP id hAPCbPib077512 for <[e-mail]>; Tue, 25 Nov 2003 04:37:25 -0800 (PST) (envelope-from [e-mail])
Received: from tsg (65.san-jose-04-05rs.ca.dial-access.att.net[12.72.193.65]) by worldnet.att.net (mtiwmhc12) with SMTP id <2003112512371811200ro09ge>; Tue, 25 Nov 2003 12:37:19 +0000
Message-ID: <000301c3b350$3839e620$010aff0a@tsg>
Reply-To: "todd glassey" <[e-mail]>
From: "todd glassey" <[e-mail]>
To: "todd glassey" <[e-mail]>, "Stephen Kent" <[e-mail]>
Cc: "Anders Rundgren" <[e-mail]>, <[e-mail]>
References: <01ec01c3b28f$1abbab40$0500a8c0@arport> <007d01c3b2a7$60857f30$010aff0a@tsg> <p06010209bbe7f130fc1f@[128.89.89.75]>
Subject: Re: Certificate Policy Standardization
Date: Mon, 24 Nov 2003 17:56:14 -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 5.50.4927.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200
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>

Charter or not Stephen - its something that is critically missing in all
eBusiness processes. That being some uniform method of invoking the coverage
of eSign acts and some method of specifying in the transaction receipt, what
jurisdiction the specific act is done under.

That you done want this as part of PKIX is also not relevant as to whether
its needed, only to whether PKIX is allowed to focus on it.

Todd :-)


----- Original Message -----
From: "Stephen Kent" <[e-mail]>
To: "todd glassey" <[e-mail]>
Cc: "Anders Rundgren" <[e-mail]>; <[e-mail]>
Sent: Monday, November 24, 2003 9:35 AM
Subject: Re: Certificate Policy Standardization


>
> At 8:23 -0800 11/24/03, todd glassey wrote:
> >----- Original Message -----
> >From: "Anders Rundgren" <[e-mail]>
> >To: <[e-mail]>
> >Sent: Monday, November 24, 2003 5:30 AM
> >Subject: Certificate Policy Standardization
> >
> >
> >>
> >>  Several persons have over the years claimed that applications
> >>  should select to trust (and recognize) certificates depending
> >>  on policy identifiers embedded in the certificates.
> >>
> >>  In order to get this to work, you "only" need to standardize
> >>  such identifiers.
> >
> >I tried to point this out several years ago and got slammed as it was not
> >part of PKIX's focus as to how the real-world was to use its wares. I
> >suggested several interaoperations OID Tables and one in particular for
> >indicating which particular electronic signature act any given
transaction
> >was supposewdly done under.
> >
> >Todd
>
> And this is still not part of the PKIX charter.
>
> Policies could be created on an industry sector basis, for example.
> The IETF could publish the resulting policies and assign OIDs, but
> PKIX is not a suitable forum for the development of such policies.
>
> Steve



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAPBfjib074786 for <[e-mail]>; Tue, 25 Nov 2003 03:41:45 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAPBfjBZ074785 for ietf-pkix-bks; Tue, 25 Nov 2003 03:41:45 -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.10/8.12.8) with ESMTP id hAPBfhib074780 for <[e-mail]>; Tue, 25 Nov 2003 03:41:44 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (127.0.0.1) by nic.lp.se (MX V5.3 VnHj) with ESMTP; Tue, 25 Nov 2003 12:41:40 +0100
Date: Tue, 25 Nov 2003 12:41:38 +0100 (CET)
Message-ID: <[e-mail]>
To: [e-mail]
CC: [e-mail]
Subject: Re: Certificate Policy Standardization
From: Richard Levitte - VMS Whacker <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
X-URL: http://www.lp.se/
X-Waved: dead chicken, GNU emacs 21.3.1, Mew version 4.0.60
X-Mew: See http://www.mew.org/
X-Mailer: Mew version 4.0.60 on Emacs 21.3.1 / Mule 5.0 (SAKAKI)
MIME-Version: 1.0
Content-Type: Text/Plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
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 Tue, 25 Nov 2003 11:50:00 +0100, Michael Ströder <[e-mail]> said:

michael> > as long as the user or
michael> > administrator knows what he/she is doing.
michael> 
michael> Well, the difference between theory and common practice...

*ahem* true...

michael> >  It's not much different
michael> > from, say, adding another public key to your PGP key ring annd
michael> > applying trust to it...  It can be done in a cluelessly with no
michael> > checks, or in a clued-in way with checks.
michael> 
michael> But the question raised here was what we will gain with
michael> certificate policy OIDs.

Granularity, and a resolution to the question "can this certificate be
used for this $10M transaction" (and other similar questions)...
After all, the problem that was "solved" with policy OIDs was the fact
that all certificates were assumed to be equal under one (unwritten?)
policy, correct?

So now, we have a problem with the solution and there are forces to go
back to a "one policy fits all" kind of thing?  I'm not sure how that
is better...  Of course, with Anders' observation that the common
thing is CA <=> Policy, it kind of makes sense.  However, that's the
current state of affairs, just as mesh PKIs aren't really supported by
quite a lot of software (I can name one that I know of :-/), and other
stuff like that.  Who says it's going to stay that way?

michael> > michael> Or a browser vendor charging CAs for placing their
michael> > michael> root CA cert in the default installation. Or...
michael> > 
michael> > That's a different story, and an action that generates such
michael> > feelings in me that I lack words to express them (not happy
michael> > feelings, I can tell you that).
michael> 
michael> Guess what would happen with certificate policy OIDs if
michael> widely deployed.

Well, how do you solve that?  If things are this bad (and it's not
something we know for sure, although guessing it is doesn't feel too
far-fetched), it will stay that way whatever is invented.  People will
always make short-cuts, and software producers will definitely keep
doing so to keep the fingers of their customers clean...  I see no way
out of that short of paying them a visit with a bat and slam some
sense into them.

(OK, I'm a cynic)

michael> > michael> Again this boils down to policy OIDs just being another
michael> > michael> useless PKIX bloat extension.
michael> > 
michael> > Uhmm, I might be historically clueless here: are policy
michael> > OIDs really a PKIX invention?
michael> 
michael> It doesn't really matter whether this extension was invented
michael> in X.509v3 or PKIX.

Point.  I asked merely out of intellectual curiosity.

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.
You don't have to be rich, a $10 donation is appreciated!

-- 
Richard Levitte     | http://richard.levitte.org/ | Tunnlandsv. 3
Levitte Programming | http://www.lp.se/           | S-168 36 Bromma
T: [phone] |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAPB0pib072296 for <[e-mail]>; Tue, 25 Nov 2003 03:00:51 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAPB0pCa072295 for ietf-pkix-bks; Tue, 25 Nov 2003 03:00:51 -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.10/8.12.8) with ESMTP id hAPB0nib072289 for <[e-mail]>; Tue, 25 Nov 2003 03:00:50 -0800 (PST) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id MAA03489; Tue, 25 Nov 2003 12:00:44 +0100 (MET)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.7); Tue, 25 Nov 2003 12:00:45 +0100 (MET)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id hAPB0iv18904; Tue, 25 Nov 2003 12:00:44 +0100 (MET)
Date: Tue, 25 Nov 2003 12:00:44 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Re[2]: TSA certificate content
Cc: [e-mail], [e-mail]
X-Sun-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>

> 
> As the specification actually, I also think that absence of keyUsage is
> permissible.
> 
> But I wonder why a certificate do not include keyUsage extension, though
> the certificate declares extendedKeyUsage.
> What kind of situation does it apply in?
> 
> I have no idea about the reason to use only extendedKeyUsage extension
> for a certificate without using keyUsage extension...
> 

In RFC 3280 page 41 about extendedkeyUsage: 

   If the extension is present, then the certificate MUST only be used
   for one of the purposes indicated. 

I understand this as "no need to set anything at all in keyUsage."  


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAPAo8ib071732 for <[e-mail]>; Tue, 25 Nov 2003 02:50:08 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAPAo8jo071731 for ietf-pkix-bks; Tue, 25 Nov 2003 02:50:08 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from nb2.stroeder.com ([62.80.60.60]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAPAo5ib071725 for <[e-mail]>; Tue, 25 Nov 2003 02:50:06 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (localhost [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id 2F6ED6701D; Tue, 25 Nov 2003 11:50:02 +0100 (CET)
Received: from stroeder.com (localhost [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id 107AE63404; Tue, 25 Nov 2003 11:50:01 +0100 (CET)
Message-ID: <[e-mail]>
Date: Tue, 25 Nov 2003 11:50:00 +0100
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007
X-Accept-Language: de-de, de, en-us, en
MIME-Version: 1.0
To: Richard Levitte - VMS Whacker <[e-mail]>
Cc: [e-mail]
Subject: Re: Certificate Policy Standardization
References: <01ec01c3b28f$1abbab40$0500a8c0@arport> <[e-mail]>            <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
X-Virus-Scanned: by AMaViS 0.3.12pre8
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id hAPAo8ib071727
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>

Richard Levitte - VMS Whacker wrote:
> In message <[e-mail]> on Tue, 25 Nov 2003 08:40:32 +0100, Michael Ströder <[e-mail]> said:
> 
> michael> Steve Hanna wrote:
> michael> > Applications can use certificate policy OIDs to make
> michael> > trust decisions today. The application just needs to
> michael> > have a way for the user or administrator to configure
> michael> > the list of acceptable certificate policies (called
> michael> > the user-initial-policy-set in RFC 3280).
> michael> 
> michael> Which is as bad as the user or administrator installing
> michael> trusted root CA certs.
> 
> I don't see why that's inherently bad,

It's not inherently bad.

> as long as the user or
> administrator knows what he/she is doing.

Well, the difference between theory and common practice...

>  It's not much different
> from, say, adding another public key to your PGP key ring annd
> applying trust to it...  It can be done in a cluelessly with no
> checks, or in a clued-in way with checks.

But the question raised here was what we will gain with
certificate policy OIDs.

> michael> Or a browser vendor charging CAs for placing their root CA
> michael> cert in the default installation. Or...
> 
> That's a different story, and an action that generates such feelings
> in me that I lack words to express them (not happy feelings, I can
> tell you that).

Guess what would happen with certificate policy OIDs if widely deployed.

> michael> Again this boils down to policy OIDs just being another
> michael> useless PKIX bloat extension.
> 
> Uhmm, I might be historically clueless here: are policy OIDs really a
> PKIX invention?

It doesn't really matter whether this extension was invented in X.509v3 or PKIX.

Ciao, Michael.




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAPAefib071240 for <[e-mail]>; Tue, 25 Nov 2003 02:40:41 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAPAef4a071239 for ietf-pkix-bks; Tue, 25 Nov 2003 02:40:41 -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.10/8.12.8) with ESMTP id hAPAedib071230 for <[e-mail]>; Tue, 25 Nov 2003 02:40:40 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (127.0.0.1) by nic.lp.se (MX V5.3 VnHj) with ESMTP; Tue, 25 Nov 2003 11:40:00 +0100
Date: Tue, 25 Nov 2003 11:39:57 +0100 (CET)
Message-ID: <[e-mail]>
To: [e-mail]
CC: [e-mail], [e-mail], [e-mail]
Subject: Re: Certificate Policy Standardization
From: Richard Levitte - VMS Whacker <[e-mail]>
In-Reply-To: <[e-mail]>
References: <01ec01c3b28f$1abbab40$0500a8c0@arport> <[e-mail]> <[e-mail]>
X-URL: http://www.lp.se/
X-Waved: dead chicken, GNU emacs 21.3.1, Mew version 4.0.60
X-Mew: See http://www.mew.org/
X-Mailer: Mew version 4.0.60 on Emacs 21.3.1 / Mule 5.0 (SAKAKI)
MIME-Version: 1.0
Content-Type: Text/Plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
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 Tue, 25 Nov 2003 08:40:32 +0100, Michael Ströder <[e-mail]> said:

michael> 
michael> Steve Hanna wrote:
michael> > Applications can use certificate policy OIDs to make
michael> > trust decisions today. The application just needs to
michael> > have a way for the user or administrator to configure
michael> > the list of acceptable certificate policies (called
michael> > the user-initial-policy-set in RFC 3280).
michael> 
michael> Which is as bad as the user or administrator installing
michael> trusted root CA certs.

I don't see why that's inherently bad, as long as the user or
administrator knows what he/she is doing.  It's not much different
from, say, adding another public key to your PGP key ring annd
applying trust to it...  It can be done in a cluelessly with no
checks, or in a clued-in way with checks.

michael> Or a browser vendor charging CAs for placing their root CA
michael> cert in the default installation. Or...

That's a different story, and an action that generates such feelings
in me that I lack words to express them (not happy feelings, I can
tell you that).

michael> Again this boils down to policy OIDs just being another
michael> useless PKIX bloat extension.

Uhmm, I might be historically clueless here: are policy OIDs really a
PKIX invention?

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.
You don't have to be rich, a $10 donation is appreciated!

-- 
Richard Levitte     | http://richard.levitte.org/ | Tunnlandsv. 3
Levitte Programming | http://www.lp.se/           | S-168 36 Bromma
T: [phone] |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAP9KFib059643 for <[e-mail]>; Tue, 25 Nov 2003 01:20:15 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAP9KFJU059642 for ietf-pkix-bks; Tue, 25 Nov 2003 01:20:15 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from iscan02.secomtrust.net (iscan01.secomtrust.net [61.114.177.102]) by above.proper.com (8.12.10/8.12.8) with SMTP id hAP9KDib059625 for <[e-mail]>; Tue, 25 Nov 2003 01:20:14 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 2028 invoked by alias); 25 Nov 2003 09:20:12 -0000
Delivered-To: [e-mail]@MAP
Received: (qmail 2008 invoked by alias); 25 Nov 2003 09:20:12 -0000
Received: from localhost (HELO mail.secomtrust.net) (127.0.0.1) by localhost with SMTP; 25 Nov 2003 09:20:12 -0000
Received: (qmail 5346 invoked from network); 25 Nov 2003 09:20:11 -0000
Received: from unknown (HELO ?172.30.5.54?) (172.30.5.54) by mail with SMTP; 25 Nov 2003 09:20:11 -0000
Date: Tue, 25 Nov 2003 18:20:50 +0900
From: Masaki SHIMAOKA <[e-mail]>
To: "'Peter Sylvester'" <[e-mail]>
Subject: Re[2]: TSA certificate content
Cc: <[e-mail]>, "Santosh Chokhani" <[e-mail]>
In-Reply-To: <019601c3b2fd$95508ce0$[e-mail]>
References: <[e-mail]> <019601c3b2fd$95508ce0$[e-mail]>
Message-Id: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Becky! ver. 2.06.02
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>

Hi Peter,

As the specification actually, I also think that absence of keyUsage is
permissible.

But I wonder why a certificate do not include keyUsage extension, though
the certificate declares extendedKeyUsage.
What kind of situation does it apply in?

I have no idea about the reason to use only extendedKeyUsage extension
for a certificate without using keyUsage extension...

On Mon, 24 Nov 2003 21:40:56 -0500
"Santosh Chokhani" <[e-mail]> wrote:

> 
> Peter:
> 
> Based on a review of 3280 and 3161, I would say that absence of keyUsage
> extension is permissible.
> 
> 3161 requires extended key usage to be present as well as critical.  It also
> requires only one key purpose in the extension, that for time stamping.
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Peter Sylvester
> Sent: Monday, November 24, 2003 8:30 AM
> To: [e-mail]
> Subject: TSA certificate content
> 
> 
> 
> 
> I would like to hear some opinion about the setting
> of the extension keyUsage in a certificate for a
> 3161 TSA. 
> 
> The question is whether a certificate contain no
> keyUsage extension at all and only an extended
> key usage with the appropriate key purpose
> is conformant with 3161 and 3280. 
> 
> Peter 
> 
> 

-----
Masaki SHIMAOKA

SECOM Trust.net
System Engineering Dpt.
Tel: [phone] (ext.3605)
Fax: [phone]
e-mail: [e-mail]



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAP8s1ib051265 for <[e-mail]>; Tue, 25 Nov 2003 00:54:01 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAP8s151051264 for ietf-pkix-bks; Tue, 25 Nov 2003 00:54:01 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from firewall.andxor.com (firewall.andxor.it [195.223.2.2]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAP8rwib051217 for <[e-mail]>; Tue, 25 Nov 2003 00:53:58 -0800 (PST) (envelope-from [e-mail])
Received: from LELLO (lello.andxor.it [195.223.2.223]) by firewall.andxor.com (8.12.6p2/8.12.3) with SMTP id hAP8reqo075761; Tue, 25 Nov 2003 09:53:47 +0100 (CET) (envelope-from [e-mail])
From: "Ing. Raffaello Galli" <[e-mail]>
To: "Santosh Chokhani" <[e-mail]>, "'Peter Sylvester'" <[e-mail]>, <[e-mail]>
Subject: R: TSA certificate content
Date: Tue, 25 Nov 2003 09:54:29 +0100
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B5_01C3B33A.1E2A7580"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <019601c3b2fd$95508ce0$[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
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_000_00B5_01C3B33A.1E2A7580
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Peter,

According to rfc3161:

   2.3. Identification of the TSA

   The TSA MUST sign each time-stamp message with a key reserved
   specifically for that purpose.  A TSA MAY have distinct private keys,
   e.g., to accommodate different policies, different algorithms,
   different private key sizes or to increase the performance.  The
   corresponding certificate MUST contain only one instance of the
   extended key usage field extension as defined in [RFC2459] Section
   4.2.1.13 with KeyPurposeID having value:

   id-kp-timeStamping.  This extension MUST be critical.
.


According to  rfc3280:


4.2.1.13  Extended Key Usage
...........................
id-kp-timeStamping            OBJECT IDENTIFIER ::= { id-kp 8 }
   -- Binding the hash of an object to a time
   -- Key usage bits that may be consistent: digitalSignature
   -- and/or nonRepudiation


So according to the RFCs the TSA certificate

1)  MUST have only one instance  "extended key usage" extension with the
value
      id-kp-timeStamping  and this must be Critical.

2) The value of the extension "key usage" may be consistent.
     (i.e. digitalSignature e/o nonRepudiation   - Critical it is
recommended
      but not mandatory)

Regards

Raffaello

->-----Messaggio originale-----
->Da: [e-mail]
->[mailto:[e-mail]]Per conto di Santosh Chokhani
->Inviato: Tuesday, November 25, 2003 3:41 AM
->A: 'Peter Sylvester'; [e-mail]
->Oggetto: RE: TSA certificate content
->
->
->
->Peter:
->
->Based on a review of 3280 and 3161, I would say that absence of keyUsage
->extension is permissible.
->
->3161 requires extended key usage to be present as well as
->critical.  It also
->requires only one key purpose in the extension, that for time stamping.
->
->>-----Original Message-----
->>From: [e-mail]
->>[mailto:[e-mail]] On
->>Behalf Of Peter Sylvester
->>Sent: Monday, November 24, 2003 8:30 AM
->>To: [e-mail]
->>Subject: TSA certificate content
->>
->>
->>
->>
->>I would like to hear some opinion about the setting
->>of the extension keyUsage in a certificate for a
->>3161 TSA.
->>
->>The question is whether a certificate contain no
->>keyUsage extension at all and only an extended
->>key usage with the appropriate key purpose
->>is conformant with 3161 and 3280.
->>
->>Peter
->>


------=_NextPart_000_00B5_01C3B33A.1E2A7580
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE></TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1126" name=3DGENERATOR></HEAD>
<BODY>
<P><FONT size=3D2><FONT size=3D3>Peter,<BR><BR>According to=20
rfc3161:<BR></FONT><BR>&nbsp;&nbsp; 2.3. Identification of the=20
TSA<BR><BR>&nbsp;&nbsp; The TSA MUST sign each time-stamp message with a =
key=20
reserved<BR>&nbsp;&nbsp; specifically for that purpose.&nbsp; A TSA MAY =
have=20
distinct private keys,<BR>&nbsp;&nbsp; e.g., to accommodate different =
policies,=20
different algorithms,<BR>&nbsp;&nbsp; different private key sizes or to =
increase=20
the performance.&nbsp; The<BR>&nbsp;&nbsp; corresponding certificate =
MUST=20
contain only one instance of the<BR>&nbsp;&nbsp; extended key usage =
field=20
extension as defined in [RFC2459] Section<BR>&nbsp;&nbsp; 4.2.1.13 with=20
KeyPurposeID having value:<BR><BR>&nbsp;&nbsp; id-kp-timeStamping.&nbsp; =
This=20
extension MUST be critical.<BR>.<BR><BR><BR></FONT><FONT =
size=3D3>According to=20
&nbsp;rfc3280:<BR></FONT></P>
<P><FONT size=3D2>4.2.1.13&nbsp; Extended Key=20
Usage<BR>...........................<BR>id-kp-timeStamping&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
OBJECT IDENTIFIER ::=3D { id-kp 8 }<BR>&nbsp;&nbsp; -- Binding the hash =
of an=20
object to a time<BR>&nbsp;&nbsp; -- Key usage bits that may be =
consistent:=20
digitalSignature<BR>&nbsp;&nbsp; -- and/or =
nonRepudiation<BR><BR></FONT><FONT=20
size=3D2><BR></FONT>So according to the RFCs the TSA certificate </P>
<P>1)&nbsp; MUST have&nbsp;only one instance&nbsp; "extended key usage"=20
extension with the=20
value&nbsp;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;id-kp-timeStamping&nbs=
p; and=20
this must be Critical.</P>
<P><FONT size=3D2><FONT size=3D3>2)&nbsp;The value of the extension "key =
usage" may=20
be consistent.<BR>&nbsp;&nbsp; &nbsp; (i.e. digitalSignature e/o=20
nonRepudiation&nbsp;&nbsp; -&nbsp;Critical it is recommended=20
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; but not mandatory)<BR><BR>Regards=20
</FONT></FONT></P>
<P><FONT size=3D2><FONT =
size=3D3>Raffaello</FONT><BR><BR>-&gt;-----Messaggio=20
originale-----<BR>-&gt;Da: =
[e-mail]<BR>-&gt;[</FONT><A=20
href=3D"mailto:[e-mail]"><FONT=20
size=3D2>mailto:[e-mail]</FONT></A><FONT =
size=3D2>]Per conto di=20
Santosh Chokhani<BR>-&gt;Inviato: Tuesday, November 25, 2003 3:41 =
AM<BR>-&gt;A:=20
'Peter Sylvester'; [e-mail]<BR>-&gt;Oggetto: RE: TSA =
certificate=20
content<BR>-&gt;<BR>-&gt;<BR>-&gt;<BR>-&gt;Peter:<BR>-&gt;<BR>-&gt;Based =
on a=20
review of 3280 and 3161, I would say that absence of =
keyUsage<BR>-&gt;extension=20
is permissible.<BR>-&gt;<BR>-&gt;3161 requires extended key usage to be =
present=20
as well as<BR>-&gt;critical.&nbsp; It also<BR>-&gt;requires only one key =
purpose=20
in the extension, that for time =
stamping.<BR>-&gt;<BR>-&gt;&gt;-----Original=20
Message-----<BR>-&gt;&gt;From:=20
[e-mail]<BR>-&gt;&gt;[</FONT><A=20
href=3D"mailto:[e-mail]"><FONT=20
size=3D2>mailto:[e-mail]</FONT></A><FONT size=3D2>]=20
On<BR>-&gt;&gt;Behalf Of Peter Sylvester<BR>-&gt;&gt;Sent: Monday, =
November 24,=20
2003 8:30 AM<BR>-&gt;&gt;To: [e-mail]<BR>-&gt;&gt;Subject: TSA=20
certificate=20
content<BR>-&gt;&gt;<BR>-&gt;&gt;<BR>-&gt;&gt;<BR>-&gt;&gt;<BR>-&gt;&gt;I=
 would=20
like to hear some opinion about the setting<BR>-&gt;&gt;of the extension =

keyUsage in a certificate for a<BR>-&gt;&gt;3161=20
TSA.<BR>-&gt;&gt;<BR>-&gt;&gt;The question is whether a certificate =
contain=20
no<BR>-&gt;&gt;keyUsage extension at all and only an =
extended<BR>-&gt;&gt;key=20
usage with the appropriate key purpose<BR>-&gt;&gt;is conformant with =
3161 and=20
3280.<BR>-&gt;&gt;<BR>-&gt;&gt;Peter<BR>-&gt;&gt;<BR></P></FONT></BODY></=
HTML>

------=_NextPart_000_00B5_01C3B33A.1E2A7580--




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAP8BSib037310 for <[e-mail]>; Tue, 25 Nov 2003 00:11:28 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAP8BSs6037309 for ietf-pkix-bks; Tue, 25 Nov 2003 00:11:28 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ddba033.netstream.ch (ddba033.netstream.ch [62.65.128.33]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAP8BQib037270 for <[e-mail]>; Tue, 25 Nov 2003 00:11:27 -0800 (PST) (envelope-from [e-mail])
Received: from [62.65.151.222] (helo=swisssign.com) by ddba033.netstream.ch with esmtp (Exim 4.10) id 1AOYI3-0003Qf-00; Tue, 25 Nov 2003 09:11:19 +0100
Message-ID: <[e-mail]>
Date: Tue, 25 Nov 2003 09:11:18 +0100
From: Joseph Doekbrijder <[e-mail]>
Organization: SwissSign AG
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007
X-Accept-Language: de-ch, en-us, en, fr-ch
MIME-Version: 1.0
To: Anders Rundgren <[e-mail]>
CC: [e-mail]
Subject: Re: Certificate Policy Standardization
References: <01ec01c3b28f$1abbab40$0500a8c0@arport>
In-Reply-To: <01ec01c3b28f$1abbab40$0500a8c0@arport>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
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>

Hi Anders

Have a look at http://csp-forum.ch
We are in Switzerland (with partial support of the Swiss government) 
working on a system where indeed trust is based on a certificate level 
or "quality". This work is based on RFC 2527 and soon needs to be 
adapted/changed to RFC 3647   :-)

The presentation 
http://csp-forum.ch/pdf/PKI%20Forum%20meeting%2016-01-03.pdf shows a 
good overview of the idea

ps. the web site is not up-to-date   :-)

Looking forward to your (or anyone's) feedback

 


Anders Rundgren wrote:

>Several persons have over the years claimed that applications
>should select to trust (and recognize) certificates depending
>on policy identifiers embedded in the certificates.
>
>In order to get this to work, you "only" need to standardize
>such identifiers.   My question is bluntly: Is there any such
>work going on on a global scale?  And if so, why have this
>information not reached the PKIX-list?
>
>Anders
>  
>

-- 
Joseph A. Doekbrijder
--------------------------------------------------
SwissSign AG
Löwenstrasse 1, CH-8001 Zürich
Tel: [phone] Mobil: [phone]
www.swisssign.com
--------------------------------------------------





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAP7fOib028105 for <[e-mail]>; Mon, 24 Nov 2003 23:41:24 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAP7fOon028104 for ietf-pkix-bks; Mon, 24 Nov 2003 23:41:24 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from nb2.stroeder.com ([212.82.228.55]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAP7fLib028072 for <[e-mail]>; Mon, 24 Nov 2003 23:41:22 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (localhost [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id D7B762C428; Tue, 25 Nov 2003 08:40:33 +0100 (CET)
Received: from stroeder.com (localhost [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id BDA4B7CB6; Tue, 25 Nov 2003 08:40:32 +0100 (CET)
Message-ID: <[e-mail]>
Date: Tue, 25 Nov 2003 08:40:32 +0100
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007
X-Accept-Language: de-de, de, en-us, en
MIME-Version: 1.0
To: Steve Hanna <[e-mail]>
Cc: Anders Rundgren <[e-mail]>, [e-mail]
Subject: Re: Certificate Policy Standardization
References: <01ec01c3b28f$1abbab40$0500a8c0@arport> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by AMaViS 0.3.12pre8
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>

Steve Hanna wrote:
> Applications can use certificate policy OIDs to make
> trust decisions today. The application just needs to
> have a way for the user or administrator to configure
> the list of acceptable certificate policies (called
> the user-initial-policy-set in RFC 3280).

Which is as bad as the user or administrator installing trusted root CA 
certs. Or a browser vendor charging CAs for placing their root CA cert in 
the default installation. Or...

Again this boils down to policy OIDs just being another useless PKIX bloat 
extension.

Ciao, Michael.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAP2fDkT081709 for <[e-mail]>; Mon, 24 Nov 2003 18:41:13 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAP2fDY9081708 for ietf-pkix-bks; Mon, 24 Nov 2003 18:41:13 -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.10/8.12.8) with ESMTP id hAP2fCkT081702 for <[e-mail]>; Mon, 24 Nov 2003 18:41:13 -0800 (PST) (envelope-from [e-mail])
Received: from wchokhani (199.st.louis-24-25rs.mo.dial-access.att.net[12.74.109.199]) by worldnet.att.net (mtiwmhc12) with SMTP id <2003112502410811200rndf2e>; Tue, 25 Nov 2003 02:41:09 +0000
From: "Santosh Chokhani" <[e-mail]>
To: "'Peter Sylvester'" <[e-mail]>, <[e-mail]>
Subject: RE: TSA certificate content
Date: Mon, 24 Nov 2003 21:40:56 -0500
Message-ID: <019601c3b2fd$95508ce0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id hAP2fDkT081704
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:

Based on a review of 3280 and 3161, I would say that absence of keyUsage
extension is permissible.

3161 requires extended key usage to be present as well as critical.  It also
requires only one key purpose in the extension, that for time stamping.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Peter Sylvester
Sent: Monday, November 24, 2003 8:30 AM
To: [e-mail]
Subject: TSA certificate content




I would like to hear some opinion about the setting
of the extension keyUsage in a certificate for a
3161 TSA. 

The question is whether a certificate contain no
keyUsage extension at all and only an extended
key usage with the appropriate key purpose
is conformant with 3161 and 3280. 

Peter 




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAOMkhkT071058 for <[e-mail]>; Mon, 24 Nov 2003 14:46:43 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAOMkhxn071057 for ietf-pkix-bks; Mon, 24 Nov 2003 14:46:43 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp1.fre.skanova.net (smtp1.fre.skanova.net [195.67.227.94]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAOMkfkT071051 for <[e-mail]>; Mon, 24 Nov 2003 14:46:42 -0800 (PST) (envelope-from [e-mail])
Received: from arport (t10o913p62.telia.com [213.64.27.182]) by smtp1.fre.skanova.net (8.12.10/8.12.10) with SMTP id hAOMkXAU026557; Mon, 24 Nov 2003 23:46:33 +0100 (CET)
Message-ID: <006e01c3b2dc$4c36e0c0$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Hans Nilsson" <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: Certificate Policy Standardization
Date: Mon, 24 Nov 2003 23:42:47 +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>

>Besides these, I do not think we ever will se any such CP OIDs. Every CA
>usually wants to state its own highlights and limitations. 

>Sorry. Go fight some other windmill :-)

But dear Hans, you are just confirming what I have tried to say
a zillions times before: To build global-scale PKI using CP OIDs
as application trust selection mechanism is not a good idea. 

I do though see a "de-facto" standard among commercial CAs
and that is simply making:

              CA <==> Policy

This scheme has a number of advantages over using the
RFC3280 policy stuff, including:

- It works on any scale

- It can be explained to just about anybody ranging from an
  ASN.1 guru to a lawyer.

That this breaks away from PKI rule #1, i.e.  "everything must be
utterly complicated otherwise it cannot be secure", is at least
something I can live with.

Anders


----- Original Message ----- 
From: "Hans Nilsson" <[e-mail]>
To: <[e-mail]>
Sent: Monday, November 24, 2003 20:39
Subject: RE: Certificate Policy Standardization



Anders,

The only "standardized" and "public" CP OID that exists are the two ones
defined by ETSI for Qualified Certificates:

"The identifiers for the qualified certificate policies specified in the
present document are:

a) QCP public + SSCD: a certificate policy for qualified certificates issued
to the public, requiring use of secure signature-creation devices
itu-t(0) identified-organization(4) etsi(0)
qualified-certificate-policies(1456)
policy-identifiers(1) qcp-public-with-sscd (1)

b) QCP public: a certificate policy for qualified certificates issued to the
public
itu-t(0) identified-organization(4) etsi(0)
qualified-certificate-policies(1456)
policy-identifiers(1) qcp-public (2)"

Besides these, I do not think we ever will se any such CP OIDs. Every CA
usually wants to state its own highlights and limitations. 

Sorry. Go fight some other windmill :-)

Hans

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
On
> Behalf Of Anders Rundgren
> Sent: Monday, November 24, 2003 7:10 PM
> To: [e-mail]
> Subject: Re: Certificate Policy Standardization
> 
> 
> >I am unaware of any such standardization.  Some organizations have
> >developed and published their own CPs.  I find that recent CPs have
> >copied liberally from the earlier ones.
> 
> To cut and paste text from various sources seems like a rather
> different activity than defining common CPs and associated OIDs.
> 
> /a





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAOMM7kT070098 for <[e-mail]>; Mon, 24 Nov 2003 14:22:07 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAOMM7WA070097 for ietf-pkix-bks; Mon, 24 Nov 2003 14:22:07 -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.10/8.12.8) with ESMTP id hAOMM6kT070089 for <[e-mail]>; Mon, 24 Nov 2003 14:22:06 -0800 (PST) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id hAOMM2sj016724; Mon, 24 Nov 2003 17:22:03 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p06010211bbe833988c84@[128.89.89.75]>
In-Reply-To: <[e-mail]>
References: <p06010209bbe7f130fc1f@[128.89.89.75]> <[e-mail]>
Date: Mon, 24 Nov 2003 17:20:05 -0500
To: "Terry Hayes" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Certificate Policy Standardization
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
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:08 -0800 11/24/03, Terry Hayes wrote:
>Stephen Kent wrote on 11/24/2003, 9:35 AM:
>>  ...
>>  And this is still not part of the PKIX charter.
>>
>>  Policies could be created on an industry sector basis, for example.
>>  The IETF could publish the resulting policies and assign OIDs, but
>>  PKIX is not a suitable forum for the development of such policies.
>>
>
>I believe that there are at least three "industry sectors" where the 
>IETF would be an appropriate forum for developing certificate 
>policies.  They are SSL/TLS host (server) certificates, email 
>(S/MIME used for email) certificates and IPSEC certificates. All 
>three of these areas have protocols defined by the IETF that uses 
>certificates to establish identities.

these are protocols, not industry sectors. One might make an argument 
for protocol-based policies as well, but it would be a different 
argument.

>In my opinion, the IETF should define a CP and corresponding OID for 
>each of these areas.  The policy would need to be fairly general in 
>many areas (such as protection of key material).  However, the 
>policy should be spell out certificate content and authentication 
>procedures that should be followed to allow most applications to 
>accept the certificate.  For example, for TLS host certificates, the 
>CA must do a reasonable check that the DNS in the certificate 
>belongs to the one requesting the certificate.

This is not going to be done in PKIX. I leave it to Russ to indicate 
whether he thinks this might be done in a follow on WG, or whether it 
is the province of the WGs for the protocols you mention. Note that 
with the advent of 3280, we decided to let protocols that are PKI 
clients define extended key usage options for themselves. If one 
argued for protocol-specific policies, then the same reasoning might 
apply here too.

>It may not be part of the PKIX charter to define these policies and 
>OIDs, but I think it is within the scope of the TLS, S/MIME and 
>IPSEC working groups to do so.

Yep, they might, if they agree with the concept that this is a 
protocol-specific policy matter, vs. an industry sector matter, etc.

Steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAOKO9kT063927 for <[e-mail]>; Mon, 24 Nov 2003 12:24:09 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAOKO9os063926 for ietf-pkix-bks; Mon, 24 Nov 2003 12:24:09 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAOKO7kT063917 for <[e-mail]>; Mon, 24 Nov 2003 12:24:07 -0800 (PST) (envelope-from [e-mail])
Received: from mail6.microsoft.com ([157.54.6.196]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Mon, 24 Nov 2003 12:24:05 -0800
Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Mon, 24 Nov 2003 12:25:21 -0800
Received: from 157.54.8.23 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 24 Nov 2003 12:24:04 -0800
Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 24 Nov 2003 12:24:00 -0800
Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 24 Nov 2003 12:24:12 -0800
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Mon, 24 Nov 2003 12:24:25 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.7097.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Subject: RE: OCSPv1 and nonces (RE: draft meeting minutes)
Date: Mon, 24 Nov 2003 12:25:00 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: OCSPv1 and nonces (RE: draft meeting minutes)
thread-index: AcOyyFmZlI1az+eqSB+4gNoEjsBOwQAAGVYw
From: "Ryan M. Hurst" <[e-mail]>
To: "Marc Branchaud" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 24 Nov 2003 20:24:25.0789 (UTC) FILETIME=[F44546D0:01C3B2C8]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id hAOKO8kT063920
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 suspect that many server implementations don't have appropriate
handling of critically marked extensions, even for known once like the
nonce due to the way the RFC is written.

That's not to say that if I am right their behavior would be correct,
but this is something we all experienced with the early days of X509
support.

Ryan

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Marc Branchaud
Sent: Monday, November 24, 2003 9:13 AM
To: [e-mail]
Subject: Re: OCSPv1 and nonces (RE: draft meeting minutes)


Ryan M. Hurst wrote:
> You are right, should not does mean not recomended however the likley 
> impact is that clients that do this will not be able to interoperate 
> with the existing servers out there.

They'll only be uninteroperable with servers that don't support nonces, 
which is exactly what we want.

The client would in any case be free to resend the query without the 
nonce, and the client could retain the fact that the server doesn't 
support nonces.

		M.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAOK9GkT063125 for <[e-mail]>; Mon, 24 Nov 2003 12:09:16 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAOK9GwR063124 for ietf-pkix-bks; Mon, 24 Nov 2003 12:09:16 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from imo-r06.mx.aol.com (imo-r06.mx.aol.com [152.163.225.102]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAOK9EkT063114 for <[e-mail]>; Mon, 24 Nov 2003 12:09:14 -0800 (PST) (envelope-from [e-mail])
Received: from [e-mail] by imo-r06.mx.aol.com (mail_out_v36_r1.1.) id 3.1a3.1d681a31 (16099); Mon, 24 Nov 2003 15:08:50 -0500 (EST)
Received: from  pc655301.nscp.aoltw.net (h-10-169-149-81.nscp.aoltw.net [10.169.149.81]) by air-id11.mx.aol.com (v97.8) with ESMTP id MAILINID113-3ee33fc265502d0; Mon, 24 Nov 2003 15:08:50 -0500
Date: Mon, 24 Nov 2003 12:08:46 -0800
From: "Terry Hayes" <[e-mail]>
Subject: Re: Certificate Policy Standardization
To: [e-mail]
cc: [e-mail], [e-mail], [e-mail]
In-Reply-To: <p06010209bbe7f130fc1f@[128.89.89.75]>
Message-ID: <[e-mail]>
References: <p06010209bbe7f130fc1f@[128.89.89.75]>
X-Mailer: AOL Communicator (20031113.4 Win)
Organization: AOL
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=us-ascii
X-AOL-IP: 10.169.149.81
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>

Stephen Kent wrote on 11/24/2003, 9:35 AM:
> ...
> And this is still not part of the PKIX charter. 
> 
> Policies could be created on an industry sector basis, for example. 
> The IETF could publish the resulting policies and assign OIDs, but 
> PKIX is not a suitable forum for the development of such policies. 
> 

I believe that there are at least three "industry sectors" where the IETF would be an appropriate forum for developing certificate policies.  They are SSL/TLS host (server) certificates, email (S/MIME used for email) certificates and IPSEC certificates. All three of these areas have protocols defined by the IETF that uses certificates to establish identities.

In my opinion, the IETF should define a CP and corresponding OID for each of these areas.  The policy would need to be fairly general in many areas (such as protection of key material).  However, the policy should be spell out certificate content and authentication procedures that should be followed to allow most applications to accept the certificate.  For example, for TLS host certificates, the CA must do a reasonable check that the DNS in the certificate belongs to the one requesting the certificate.

It may not be part of the PKIX charter to define these policies and OIDs, but I think it is within the scope of the TLS, S/MIME and IPSEC working groups to do so.

Terry Hayes


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAOJdskT061705 for <[e-mail]>; Mon, 24 Nov 2003 11:39:54 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAOJdsVK061704 for ietf-pkix-bks; Mon, 24 Nov 2003 11:39:54 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail4.it-norr.com ([80.244.64.43]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAOJdqkT061694 for <[e-mail]>; Mon, 24 Nov 2003 11:39:53 -0800 (PST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Received: from HANSTOSHIBA ([217.211.59.248]) by mail4.it-norr.com (IT-NORR Mail Cluster v2003) with ASMTP id DUA74354 for <[e-mail]>; Mon, 24 Nov 2003 20:39:49 +0100
From: "Hans Nilsson" <[e-mail]>
To: <[e-mail]>
Subject: RE: Certificate Policy Standardization
Date: Mon, 24 Nov 2003 20:39:34 +0100
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.2800.1165
Thread-Index: AcOyvVFbK35ZaNc6QoyII4zSow1S4wABKpgw
In-Reply-To: <005301c3b2b6$3be4aca0$0500a8c0@arport>
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>

Anders,

The only "standardized" and "public" CP OID that exists are the two ones
defined by ETSI for Qualified Certificates:

"The identifiers for the qualified certificate policies specified in the
present document are:

a) QCP public + SSCD: a certificate policy for qualified certificates issued
to the public, requiring use of secure signature-creation devices
itu-t(0) identified-organization(4) etsi(0)
qualified-certificate-policies(1456)
policy-identifiers(1) qcp-public-with-sscd (1)

b) QCP public: a certificate policy for qualified certificates issued to the
public
itu-t(0) identified-organization(4) etsi(0)
qualified-certificate-policies(1456)
policy-identifiers(1) qcp-public (2)"

Besides these, I do not think we ever will se any such CP OIDs. Every CA
usually wants to state its own highlights and limitations. 

Sorry. Go fight some other windmill :-)

Hans

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
On
> Behalf Of Anders Rundgren
> Sent: Monday, November 24, 2003 7:10 PM
> To: [e-mail]
> Subject: Re: Certificate Policy Standardization
> 
> 
> >I am unaware of any such standardization.  Some organizations have
> >developed and published their own CPs.  I find that recent CPs have
> >copied liberally from the earlier ones.
> 
> To cut and paste text from various sources seems like a rather
> different activity than defining common CPs and associated OIDs.
> 
> /a





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAOJQ4kT060716 for <[e-mail]>; Mon, 24 Nov 2003 11:26:04 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAOJQ4qM060714 for ietf-pkix-bks; Mon, 24 Nov 2003 11:26:04 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAOJQ3kT060708 for <[e-mail]>; Mon, 24 Nov 2003 11:26:04 -0800 (PST) (envelope-from [e-mail])
Received: from ROMANS (unknown [209.20.132.237]) by smtp1.pacifier.net (Postfix) with ESMTP id 6C0337046D; Mon, 24 Nov 2003 11:26:04 -0800 (PST)
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Denis Pinkas'" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: RE: WG last call re draft-pkix-acpolicies-extn-03.txt
Date: Mon, 24 Nov 2003 11:28:37 -0800
Message-ID: <005701c3b2c1$28dd2640$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
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>

Denis,

I just found a minor issue.

In the ASN.1 module you are referencing [PROFILE] rather than [RFC3280].

jim



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAOIEBkT056850 for <[e-mail]>; Mon, 24 Nov 2003 10:14:11 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAOIEBHh056849 for ietf-pkix-bks; Mon, 24 Nov 2003 10:14:11 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp5.hy.skanova.net (smtp5.hy.skanova.net [195.67.199.134]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAOIE9kT056844 for <[e-mail]>; Mon, 24 Nov 2003 10:14:10 -0800 (PST) (envelope-from [e-mail])
Received: from arport (t7o913p20.telia.com [213.64.26.20]) by smtp5.hy.skanova.net (8.12.10/8.12.10) with SMTP id hAOIE3uO011215 for <[e-mail]>; Mon, 24 Nov 2003 19:14:09 +0100 (CET)
Message-ID: <005301c3b2b6$3be4aca0$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>
References: <[e-mail]>
Subject: Re: Certificate Policy Standardization
Date: Mon, 24 Nov 2003 19:10:19 +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>

>I am unaware of any such standardization.  Some organizations have 
>developed and published their own CPs.  I find that recent CPs have
>copied liberally from the earlier ones.

To cut and paste text from various sources seems like a rather
different activity than defining common CPs and associated OIDs.

/a



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAOHb9kT054694 for <[e-mail]>; Mon, 24 Nov 2003 09:37:09 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAOHb9wj054693 for ietf-pkix-bks; Mon, 24 Nov 2003 09:37:09 -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.10/8.12.8) with ESMTP id hAOHb7kT054687 for <[e-mail]>; Mon, 24 Nov 2003 09:37:08 -0800 (PST) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id hAOHb3sj028513; Mon, 24 Nov 2003 12:37:03 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p06010209bbe7f130fc1f@[128.89.89.75]>
In-Reply-To: <007d01c3b2a7$60857f30$010aff0a@tsg>
References: <01ec01c3b28f$1abbab40$0500a8c0@arport> <007d01c3b2a7$60857f30$010aff0a@tsg>
Date: Mon, 24 Nov 2003 12:35:25 -0500
To: "todd glassey" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Certificate Policy Standardization
Cc: "Anders Rundgren" <[e-mail]>, <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
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 8:23 -0800 11/24/03, todd glassey wrote:
>----- Original Message -----
>From: "Anders Rundgren" <[e-mail]>
>To: <[e-mail]>
>Sent: Monday, November 24, 2003 5:30 AM
>Subject: Certificate Policy Standardization
>
>
>>
>>  Several persons have over the years claimed that applications
>>  should select to trust (and recognize) certificates depending
>>  on policy identifiers embedded in the certificates.
>>
>>  In order to get this to work, you "only" need to standardize
>>  such identifiers.
>
>I tried to point this out several years ago and got slammed as it was not
>part of PKIX's focus as to how the real-world was to use its wares. I
>suggested several interaoperations OID Tables and one in particular for
>indicating which particular electronic signature act any given transaction
>was supposewdly done under.
>
>Todd

And this is still not part of the PKIX charter.

Policies could be created on an industry sector basis, for example. 
The IETF could publish the resulting policies and assign OIDs, but 
PKIX is not a suitable forum for the development of such policies.

Steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAOHLvkT054022 for <[e-mail]>; Mon, 24 Nov 2003 09:21:57 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAOHLvdQ054021 for ietf-pkix-bks; Mon, 24 Nov 2003 09:21:57 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from sigurd.x509.com ([199.175.155.2]) by above.proper.com (8.12.10/8.12.8) with SMTP id hAOHLukT054011 for <[e-mail]>; Mon, 24 Nov 2003 09:21:56 -0800 (PST) (envelope-from [e-mail])
Received: from nebula.x509.com by sigurd.x509.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 24 Nov 2003 17:21:57 UT
Received: from crack.x509.com (localhost [127.0.0.1]) by nebula.x509.com (8.12.10/NULL) with ESMTP id hAOHI56L023923 for <[e-mail]>; Mon, 24 Nov 2003 09:18:05 -0800 (PST)
Received: from exvan01.x509.com (exvan01.x509.com [10.9.22.50]) by crack.x509.com (8.12.10/8.12.10) with ESMTP id hAOHLuY0013749 for <[e-mail]>; Mon, 24 Nov 2003 09:21:56 -0800 (PST)
Received: from rsasecurity.com (mbranchaud2.eng.x509.com [10.7.33.48]) by exvan01.x509.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id VQFWGD1R; Mon, 24 Nov 2003 09:30:45 -0800
Message-ID: <[e-mail]>
Date: Mon, 24 Nov 2003 09:12:33 -0800
X-Sybari-Trust: dcb9064e 64c784fd 0d23202c 00000139
From: Marc Branchaud <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5b) Gecko/20030903
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: OCSPv1 and nonces (RE: draft meeting minutes)
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050105060906050608070004"
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.

--------------ms050105060906050608070004
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit


Ryan M. Hurst wrote:
> You are right, should not does mean not recomended however the likley 
> impact is that clients that do this will not be able to interoperate 
> with the existing servers out there.

They'll only be uninteroperable with servers that don't support nonces, 
which is exactly what we want.

The client would in any case be free to resend the query without the 
nonce, and the client could retain the fact that the server doesn't 
support nonces.

		M.

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISqTCC
AtcwggJAoAMCAQICEFgUQCxch7Sxp7XFFauIqpwwDQYJKoZIhvcNAQEFBQAwbDEaMBgGA1UE
ChMRUlNBIFNlY3VyaXR5IEluYy4xHjAcBgNVBAMTFVJTQSBQdWJsaWMgUm9vdCBDQSB2MTEu
MCwGCSqGSIb3DQEJARYfcnNha2VvbnJvb3RzaWduQHJzYXNlY3VyaXR5LmNvbTAeFw0wMjA5
MDYxNDEzNTJaFw0wNzA5MDYxNDEzNTJaMIGCMRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5j
LjEVMBMGA1UECxMMS0NBIFNlcnZpY2VzMRYwFAYDVQQDEw1SU0EgQ29ycG9yYXRlMRAwDgYD
VQQHEwdCZWRmb3JkMRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMQswCQYDVQQGEwJVUzCBnzAN
BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAqnOw876lPpMTkSqrqzpEON/609PDLEhmWX4tkC19
AHneDaoetL277GtYYXBCggP2E+s66MN1ccWXyApfWjCZkIHepPC08NVI1JRcbViW3kwLzDD2
w5T9QJcyL5V1pN/LQdxahM56TiLeXlPiJekdmTdJoo+5Pw4bQU+MxTqURk8CAwEAAaNjMGEw
HwYDVR0jBBgwFoAU9UwxelEDPyzXi5eZb6hxkKt4PZswHQYDVR0OBBYEFO2RCGt0t1lKkvah
HSJwJp8KrxaSMA8GA1UdEwQIMAYBAf8CAQMwDgYDVR0PAQH/BAQDAgGGMA0GCSqGSIb3DQEB
BQUAA4GBAHiSe1a79hnPr16PuBwUTBWbuNQ4GJNsyfrCXzAswIT2A2WtGZ1Hp1jEAWi9OfAX
IYAdy52Jyv9N87wAEbLUgVmsFEIlYM5mi6ag7YIRGp8JP5UhLAN9O5YHrR9FsrGK4WmSl3sY
W1qAPOXubFcfhTgUDIYzM30izZBP4nwO07FpMIIC+DCCAmGgAwIBAgIQeuiOriTayCwjwpmR
gmdIUjANBgkqhkiG9w0BAQUFADCBgjEaMBgGA1UEChMRUlNBIFNlY3VyaXR5IEluYy4xFTAT
BgNVBAsTDEtDQSBTZXJ2aWNlczEWMBQGA1UEAxMNUlNBIENvcnBvcmF0ZTEQMA4GA1UEBxMH
QmVkZm9yZDEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMwHhcNMDIwOTIz
MTkxMzAzWhcNMDYwOTIzMTUxMzAzWjCBjDEaMBgGA1UEChMRUlNBIFNlY3VyaXR5IEluYy4x
FTATBgNVBAsTDEtDQSBTZXJ2aWNlczEgMB4GA1UEAxMXUlNBIENsYXNzIDIgUGVyc29uYWwg
Q0ExEDAOBgNVBAcTB0JlZGZvcmQxFjAUBgNVBAgTDU1hc3NhY2h1c2V0dHMxCzAJBgNVBAYT
AlVTMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCkR9yiabyRo6+NwC3Sl8wPuUiBD3rP
sENNjXvzSbTAyXA8pDDndnlAa1nLUhSMgvn8g1sYMd0Bp+C1/mI5PFUZ8jukUK95yt+TK26L
hM/M5RUq/EINdDDdWzg9je498K6oGfyWR6ETSJbIrDe5qQcLCABs9E2gVKb7Z/FwFo3C9QID
AQABo2MwYTAPBgNVHRMECDAGAQH/AgECMA4GA1UdDwEB/wQEAwIBhjAfBgNVHSMEGDAWgBTt
kQhrdLdZSpL2oR0icCafCq8WkjAdBgNVHQ4EFgQUxpPuxqX+41WOz4ojH+6Y3iHyn6cwDQYJ
KoZIhvcNAQEFBQADgYEAcdRHBjq8GfdDoutUTJPtSzQd7XsdsQh2KBbu8utl92VQHuI0J5wc
Rc817G8YbmTtCt/xqAzrr6k7fdaoDBr/kBuVHA5FEJ94foPgrOlbT3zdziMATXh5ESSDLMx6
p8ITIsTJNmwszIG5P9AAKJCW48gu1ZZmLXhFbHcYJGf99pwwggMFMIICbqADAgECAhEAvhyf
0s21hKaAc2Nm1WX4LTANBgkqhkiG9w0BAQUFADCBuzEkMCIGA1UEBxMbVmFsaUNlcnQgVmFs
aWRhdGlvbiBOZXR3b3JrMRcwFQYDVQQKEw5WYWxpQ2VydCwgSW5jLjE1MDMGA1UECxMsVmFs
aUNlcnQgQ2xhc3MgMyBQb2xpY3kgVmFsaWRhdGlvbiBBdXRob3JpdHkxITAfBgNVBAMTGGh0
dHA6Ly93d3cudmFsaWNlcnQuY29tLzEgMB4GCSqGSIb3DQEJARYRaW5mb0B2YWxpY2VydC5j
b20wHhcNMDIwNDMwMTUzMDE5WhcNMTkwNDMwMDkyMTU1WjBsMRowGAYDVQQKExFSU0EgU2Vj
dXJpdHkgSW5jLjEeMBwGA1UEAxMVUlNBIFB1YmxpYyBSb290IENBIHYxMS4wLAYJKoZIhvcN
AQkBFh9yc2FrZW9ucm9vdHNpZ25AcnNhc2VjdXJpdHkuY29tMIGfMA0GCSqGSIb3DQEBAQUA
A4GNADCBiQKBgQC0dSVa2EQ740GxqiIKsHATT4f8XYwUU23pzRe5W6IVpt4jkwDWkgnvTcP6
M8PD4OfK6Imal4hAH/c3K/dUIH7YyQZRGAE5Y27G5klZYKidcFlrfautgVES170MLKFmJqym
2FWAfVOibXatRcw7B0S+mP9404jID/MaIpRXkH5JjwIDAQABo1cwVTAMBgNVHRMEBTADAQH/
MA4GA1UdDwEB/wQEAwIBhjAWBgNVHSAEDzANMAsGCSqGSIb3DQUGATAdBgNVHQ4EFgQU9Uwx
elEDPyzXi5eZb6hxkKt4PZswDQYJKoZIhvcNAQEFBQADgYEAKsviXBc1FeBT2hIwyWuGwnPZ
J9ctjrsO7NbVLjsx/EYclFFGwo+pphiwdUTml9yd7fXzfk0D+7LOs9ZA5xhiHVrGusV4OW4i
7hx2KVILkYlcXCN5tDltKwa5+BkGUuvZdyAoIhpyf61h7uKCFguhaJ+VOiNB4DPtsmxI+KxO
E6YwggTYMIIEQaADAgECAhBgzHl9dAoZGu0JMqXovSgdMA0GCSqGSIb3DQEBBQUAMIGMMRow
GAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEVMBMGA1UECxMMS0NBIFNlcnZpY2VzMSAwHgYD
VQQDExdSU0EgQ2xhc3MgMiBQZXJzb25hbCBDQTEQMA4GA1UEBxMHQmVkZm9yZDEWMBQGA1UE
CBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMwHhcNMDMwNzA3MjMwODEzWhcNMDQwNzA3
MjMwODEzWjCBvjETMBEGCgmSJomT8ixkARkWA2NvbTEbMBkGCgmSJomT8ixkARkWC3JzYXNl
Y3VyaXR5MRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEWMBQGA1UECxMNTm9ydGggQW1l
cmljYTEUMBIGA1UECxMLRW5naW5lZXJpbmcxFzAVBgNVBAMTDk1hcmMgQnJhbmNoYXVkMScw
JQYJKoZIhvcNAQkBFhhtYXJjbmFyY0Byc2FzZWN1cml0eS5jb20wggEiMA0GCSqGSIb3DQEB
AQUAA4IBDwAwggEKAoIBAQDg2xoRr+a/dtnuFG+oTHa+tGtzeObFazNhYV2iSLNED4fHRu86
tknBYFgXggcHW5gsyjfkCtVMzP2tCivmbJgvISo36vsCsmAJH6LRnJf8HsvfmWZaD9tzhDpL
QVsBHr88J0ZMdVniRc7MQoYeu/3hYtUBeGO9bGA6T8vTrnXYonnFtVoTqE62SFqPZZk7HpCS
X1n+dM3zSym2ylMFYE14nukF4I9vAhsQVzk3QNpghmzGj8uoEy9xpf3k0o5+neneAGvcSkwo
r1mH5tSqhrEQaZp7vuSA2bvXaZEnjZzZiTpPDzs1oMpn3guzYhU7wMKz6xvwvgEYyAAV+P5n
FWM/AgMBAAGjggGBMIIBfTCBkgYDVR0gBIGKMIGHMIGEBgkqhkiG9w0FBwIwdzAuBggrBgEF
BQcCARYiaHR0cDovL2NhLnJzYXNlY3VyaXR5LmNvbS9DUFMuaHRtbDBFBggrBgEFBQcCAjA5
MBgWEVJTQSBTZWN1cml0eSBJbmMuMAMCAQEaHUNQUyBJbmNvcnBvcmF0ZWQgYnkgcmVmZXJl
bmNlMCkGA1UdJQQiMCAGCisGAQQBgjcUAgIGCCsGAQUFBwMCBggrBgEFBQcDBDAjBgNVHREE
HDAagRhtYXJjbmFyY0Byc2FzZWN1cml0eS5jb20wDgYDVR0PAQH/BAQDAgeAMEYGA1UdHwQ/
MD0wO6A5oDeGNWh0dHA6Ly9jcmwucnNhc2VjdXJpdHkuY29tOjgwL1JTQUNsYXNzMlBlcnNv
bmFsQ0EuY3JsMB8GA1UdIwQYMBaAFMaT7sal/uNVjs+KIx/umN4h8p+nMB0GA1UdDgQWBBQ1
yQ/UrvKb563LjzHqJzBzrZp/ejANBgkqhkiG9w0BAQUFAAOBgQCV82oGGnglQQzklKg/wKhy
evNeJ6FNBZFhLlmZRNlKgqvPFmBcxygfBGpHqIhsHcrt2/AjhJuzAj7UdW1vTVCY5MkZw8P9
6+J6aTc3bNlGbk0jvcvVgDhmM4xYJLwMZKEw92HlRhfuMnj7ah9DTqbKSewmyAyOc+FLpGfd
lu6CgTCCBOkwggRSoAMCAQICEQDqxAXqre9Mr+FeYw3+MQhsMA0GCSqGSIb3DQEBBQUAMIGM
MRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEVMBMGA1UECxMMS0NBIFNlcnZpY2VzMSAw
HgYDVQQDExdSU0EgQ2xhc3MgMiBQZXJzb25hbCBDQTEQMA4GA1UEBxMHQmVkZm9yZDEWMBQG
A1UECBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMwHhcNMDMwNzA3MjMwODI4WhcNMDQw
NzA3MjMwODEzWjCBwjETMBEGCgmSJomT8ixkARkWA2NvbTEbMBkGCgmSJomT8ixkARkWC3Jz
YXNlY3VyaXR5MRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEWMBQGA1UECxMNTm9ydGgg
QW1lcmljYTEUMBIGA1UECxMLRW5naW5lZXJpbmcxGzAZBgNVBAMTEk1hcmMgQnJhbmNoYXVk
LUVuYzEnMCUGCSqGSIb3DQEJARYYbWFyY25hcmNAcnNhc2VjdXJpdHkuY29tMIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwBjNaHTwtCXpdJg+iDxYMkWjuZIF0ic2fRLymZe+
BnZYWPnik0dFmTulx+V8slsLEtBllcc5o1yfIYfeHPinwRxv86kCUSlgfGGXKjJZaIeURgbo
bUbIfDTPlvRUZuiZvTR4C8tEY88Lle66n62B7wjUvDbiwK4EjzlXOkjpcYXLH7FbaFaRLDBB
PlFD5ydDRhQ67t6fjUeS7p7o/l/VHmPC5LFLXZkjEhjGd5pknbQIAbUGACL5UET85NUFPowD
3F47g0GCKEnuOsk2Ra+WHu7honhIxqmOwGnu85V6tW5xscf4dTofWZONQeaD3gSxv8+hcfKN
k9cwjpnUG2xGzwIDAQABo4IBjTCCAYkwNQYDVR0lBC4wLAYKKwYBBAGCNxQCAgYIKwYBBQUH
AwIGCCsGAQUFBwMEBgorBgEEAYI3CgMEMIGSBgNVHSAEgYowgYcwgYQGCSqGSIb3DQUHAjB3
MC4GCCsGAQUFBwIBFiJodHRwOi8vY2EucnNhc2VjdXJpdHkuY29tL0NQUy5odG1sMEUGCCsG
AQUFBwICMDkwGBYRUlNBIFNlY3VyaXR5IEluYy4wAwIBARodQ1BTIEluY29ycG9yYXRlZCBi
eSByZWZlcmVuY2UwIwYDVR0RBBwwGoEYbWFyY25hcmNAcnNhc2VjdXJpdHkuY29tMEYGA1Ud
HwQ/MD0wO6A5oDeGNWh0dHA6Ly9jcmwucnNhc2VjdXJpdHkuY29tOjgwL1JTQUNsYXNzMlBl
cnNvbmFsQ0EuY3JsMB8GA1UdIwQYMBaAFMaT7sal/uNVjs+KIx/umN4h8p+nMB0GA1UdDgQW
BBT/OiMCyY8CPnNBySW1ijJOYhj7ejAOBgNVHQ8BAf8EBAMCAzgwDQYJKoZIhvcNAQEFBQAD
gYEAlchAObA9eVmeiLu0nTU985Fch6v+EZKodUhZUN7dILgd05HorHN9jxBH6XI4/b9ZVvub
Pkpicdc112YbcLYTD2NumVksyNDI7fDaqiszgk1zluXtZJ+HsCt+GIAKCDfOVLECclpGyizq
VjZFEK4Pt9FxPGTnUJEvIKJcAQ24EvgxggPsMIID6AIBATCBoTCBjDEaMBgGA1UEChMRUlNB
IFNlY3VyaXR5IEluYy4xFTATBgNVBAsTDEtDQSBTZXJ2aWNlczEgMB4GA1UEAxMXUlNBIENs
YXNzIDIgUGVyc29uYWwgQ0ExEDAOBgNVBAcTB0JlZGZvcmQxFjAUBgNVBAgTDU1hc3NhY2h1
c2V0dHMxCzAJBgNVBAYTAlVTAhBgzHl9dAoZGu0JMqXovSgdMAkGBSsOAwIaBQCgggIfMBgG
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMTEyNDE3MTIzM1ow
IwYJKoZIhvcNAQkEMRYEFA2QSzX6kqHMsMZ0pkCuBGlntngLMFIGCSqGSIb3DQEJDzFFMEMw
CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G
CCqGSIb3DQMCAgEoMIGzBgkrBgEEAYI3EAQxgaUwgaIwgYwxGjAYBgNVBAoTEVJTQSBTZWN1
cml0eSBJbmMuMRUwEwYDVQQLEwxLQ0EgU2VydmljZXMxIDAeBgNVBAMTF1JTQSBDbGFzcyAy
IFBlcnNvbmFsIENBMRAwDgYDVQQHEwdCZWRmb3JkMRYwFAYDVQQIEw1NYXNzYWNodXNldHRz
MQswCQYDVQQGEwJVUwIRAOrEBeqt70yv4V5jDf4xCGwwgbUGCyqGSIb3DQEJEAILMYGloIGi
MIGMMRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEVMBMGA1UECxMMS0NBIFNlcnZpY2Vz
MSAwHgYDVQQDExdSU0EgQ2xhc3MgMiBQZXJzb25hbCBDQTEQMA4GA1UEBxMHQmVkZm9yZDEW
MBQGA1UECBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMCEQDqxAXqre9Mr+FeYw3+MQhs
MA0GCSqGSIb3DQEBAQUABIIBAKFVmvdtLTq7jdVe6fn3vWAUQulTLKT8OJ/bqmyFbii/RSjJ
rJL/W/WxgrVpxgR2EXIA6JobtOlMzoGKgW6zWja3x4UQoxYI1vP/8G347U9vk0+YrIZSLK+P
u/9I5K1CS0jvaGUuVvgLEGFSn0mckQfdrFhGYnIdVQcA0MsmlHVdHRCpdP42781ZFYIz79VP
AokF36IeFE/aKSgiWvBacTBK41SOpw8Jkaf0nQ1GGfcZ7aA9SjpoH0o2ELhUXNvtcFFEBQDw
FkwKad0SOWsUUKoubuyKB5o5OP/+Sli2J7ky4yv2H4FQA5vGDFvfbmkN+mck8MRH751vFv/K
EclqDKsAAAAAAAA=
--------------ms050105060906050608070004--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAOGmHkT051928 for <[e-mail]>; Mon, 24 Nov 2003 08:48:17 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAOGmHsL051927 for ietf-pkix-bks; Mon, 24 Nov 2003 08:48:17 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAOGmGkT051920 for <[e-mail]>; Mon, 24 Nov 2003 08:48:16 -0800 (PST) (envelope-from [e-mail])
Received: from sydney.East.Sun.COM ([129.148.9.16]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id hAOGmGPh020167; Mon, 24 Nov 2003 09:48:16 -0700 (MST)
Received: from sun.com (dhcp-ubur02-75-161 [129.148.75.161]) by sydney.East.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id hAOGmGB08184; Mon, 24 Nov 2003 11:48:16 -0500 (EST)
Message-ID: <[e-mail]>
Date: Mon, 24 Nov 2003 11:47:25 -0500
From: Steve Hanna <[e-mail]>
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Anders Rundgren <[e-mail]>
CC: [e-mail]
Subject: Re: Certificate Policy Standardization
References: <01ec01c3b28f$1abbab40$0500a8c0@arport>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msD584A57CC3BDF3C041F7008A"
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.

--------------msD584A57CC3BDF3C041F7008A
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Applications can use certificate policy OIDs to make
trust decisions today. The application just needs to
have a way for the user or administrator to configure
the list of acceptable certificate policies (called
the user-initial-policy-set in RFC 3280).

There is something to be said for attempting to
develop standard certificate policies and corresponding
OIDs. There may be some efforts underway to do so, but
I'm not an expert in this area. However, applications
and users don't need to wait for such standards to arrive
in order to use certificate policy OIDs in making trust
decisions. Of course, there's no need to do this if all
the CAs in your PKI only support one certificate policy!

Thanks,

Steve

Anders Rundgren wrote:
> 
> Several persons have over the years claimed that applications
> should select to trust (and recognize) certificates depending
> on policy identifiers embedded in the certificates.
> 
> In order to get this to work, you "only" need to standardize
> such identifiers.   My question is bluntly: Is there any such
> work going on on a global scale?  And if so, why have this
> information not reached the PKIX-list?
> 
> Anders
--------------msD584A57CC3BDF3C041F7008A
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

MIIIEAYJKoZIhvcNAQcCoIIIATCCB/0CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
BeMwggKjMIICDKADAgECAgMKVAgwDQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlpBMRUw
EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhh
d3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwg
RnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA3MTExMTAxNTFaFw0wNDA3MTAxMTAxNTFa
MGgxDjAMBgNVBAQTBUhhbm5hMRUwEwYDVQQqEwxTdGVwaGVuIFJvc3MxGzAZBgNVBAMTElN0
ZXBoZW4gUm9zcyBIYW5uYTEiMCAGCSqGSIb3DQEJARYTc3RldmUuaGFubmFAc3VuLmNvbTCB
nzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAoxRk/abMPe7Km2EqpD2FZXzjiBGUHhIdNlIO
9W6mdCQro1xMc+sv+93UuVnIzse+XA67Tqx4g5FdoQ+PI8TQYemYSkTD9GitgU563ypu03UV
86zTJA7u9zVkNv/qL2LRKZ9BXy2Smtet+PUh3nYjMh/ZY7LQxQzmdu1Zunue+yECAwEAAaMw
MC4wHgYDVR0RBBcwFYETc3RldmUuaGFubmFAc3VuLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqG
SIb3DQEBBAUAA4GBAHbpX0TKiOFu1vxKc3nAOcUHwoci5kinboYrnjWcl37mMXXbBFntaYRM
9LxpGtHdPm7F4pAviKp8bnFzTU46OyUw3kNUAVGDeWYVQC76f0dDZdA313Tn88UZYa+N6O8W
bO8wjKA2vg+yx79WXJCFDu+TpsG/28NKPdH42w8LEOVHMIIDODCCAqGgAwIBAgIQZkVyt8x0
9c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl
c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3Vs
dGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UE
AxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h
bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgyNzIzNTk1OVow
gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg
VG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEo
MCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzANBgkqhkiG9w0B
AQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUqbXA8+tyu9+50
bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC9tewkd4c6avg
GAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEwwKQYDVR0RBCIw
IKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQIMAYBAf8CAQAw
CwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF151j2YwCYTYoEi
pxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59sogxYjTFCCRFs
sBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TYyWJirQXGMYIB
9TCCAfECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQ
BgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0
ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAID
ClQIMAkGBSsOAwIaBQCggbEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B
CQUxDxcNMDMxMTI0MTY0NzI1WjAjBgkqhkiG9w0BCQQxFgQUczlnIxB3vWhcMIUfCD4LnsoB
cUUwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4D
AgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYChHRmo
x8wsuD4fY8QB/28H+Rnw3lpA29K71XxT+vQ2kgQSCOzlN5lKfwv5pd++M96DnTdS3imBHfJr
1Tf4gIJYBZYurOahu/W5KvJqHPH1FTrz5rlos0HdYi+RbedW2U2IVHzeJtzn1syhQAg2Ycvt
cLFjfRr+FdxAKEtHCaW7tg==
--------------msD584A57CC3BDF3C041F7008A--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAOGSnkT050944 for <[e-mail]>; Mon, 24 Nov 2003 08:28:49 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAOGSnZQ050943 for ietf-pkix-bks; Mon, 24 Nov 2003 08:28:49 -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.10/8.12.8) with ESMTP id hAOGSlkT050937 for <[e-mail]>; Mon, 24 Nov 2003 08:28:47 -0800 (PST) (envelope-from [e-mail])
Received: from tsg (73.san-jose-04-05rs.ca.dial-access.att.net[12.72.193.73]) by worldnet.att.net (mtiwmhc12) with SMTP id <2003112416283311200dlql8e>; Mon, 24 Nov 2003 16:28:38 +0000
Message-ID: <007d01c3b2a7$60857f30$010aff0a@tsg>
Reply-To: "todd glassey" <[e-mail]>
From: "todd glassey" <[e-mail]>
To: "Anders Rundgren" <[e-mail]>, <[e-mail]>
References: <01ec01c3b28f$1abbab40$0500a8c0@arport>
Subject: Re: Certificate Policy Standardization
Date: Mon, 24 Nov 2003 08:23:16 -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 5.50.4927.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200
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: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>
Sent: Monday, November 24, 2003 5:30 AM
Subject: Certificate Policy Standardization


>
> Several persons have over the years claimed that applications
> should select to trust (and recognize) certificates depending
> on policy identifiers embedded in the certificates.
>
> In order to get this to work, you "only" need to standardize
> such identifiers.

I tried to point this out several years ago and got slammed as it was not
part of PKIX's focus as to how the real-world was to use its wares. I
suggested several interaoperations OID Tables and one in particular for
indicating which particular electronic signature act any given transaction
was supposewdly done under.

Todd


>  My question is bluntly: Is there any such
> work going on on a global scale?  And if so, why have this
> information not reached the PKIX-list?
>
> Anders



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAOFuwkT049593 for <[e-mail]>; Mon, 24 Nov 2003 07:56:58 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAOFuwGf049592 for ietf-pkix-bks; Mon, 24 Nov 2003 07:56:58 -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.240.3]) by above.proper.com (8.12.10/8.12.8) with SMTP id hAOFuvkT049584 for <[e-mail]>; Mon, 24 Nov 2003 07:56:57 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 32534 invoked by uid 0); 24 Nov 2003 15:56:39 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.97.56) by woodstock.binhost.com with SMTP; 24 Nov 2003 15:56:39 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Mon, 24 Nov 2003 10:56:09 -0500
To: "Anders Rundgren" <[e-mail]>, <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: Certificate Policy Standardization
In-Reply-To: <01ec01c3b28f$1abbab40$0500a8c0@arport>
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 am unaware of any such standardization.  Some organizations have 
developed and published their own CPs.  I find that recend CPs have copied 
liberally from the earlier ones.

Russ

At 02:30 PM 11/24/2003 +0100, Anders Rundgren wrote:

>Several persons have over the years claimed that applications
>should select to trust (and recognize) certificates depending
>on policy identifiers embedded in the certificates.
>
>In order to get this to work, you "only" need to standardize
>such identifiers.   My question is bluntly: Is there any such
>work going on on a global scale?  And if so, why have this
>information not reached the PKIX-list?
>
>Anders



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAODY6kT043116 for <[e-mail]>; Mon, 24 Nov 2003 05:34:06 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAODY6tg043115 for ietf-pkix-bks; Mon, 24 Nov 2003 05:34:06 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp7.hy.skanova.net (smtp7.hy.skanova.net [195.67.199.140]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAODY4kT043110 for <[e-mail]>; Mon, 24 Nov 2003 05:34:05 -0800 (PST) (envelope-from [e-mail])
Received: from arport (t9o913p84.telia.com [213.64.27.84]) by smtp7.hy.skanova.net (8.12.10/8.12.10) with SMTP id hAODXw1w027247 for <[e-mail]>; Mon, 24 Nov 2003 14:34:03 +0100 (CET)
Message-ID: <01ec01c3b28f$1abbab40$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>
Subject: Certificate Policy Standardization
Date: Mon, 24 Nov 2003 14:30:13 +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>

Several persons have over the years claimed that applications
should select to trust (and recognize) certificates depending
on policy identifiers embedded in the certificates.

In order to get this to work, you "only" need to standardize
such identifiers.   My question is bluntly: Is there any such
work going on on a global scale?  And if so, why have this
information not reached the PKIX-list?

Anders


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAODUMkT042994 for <[e-mail]>; Mon, 24 Nov 2003 05:30:22 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAODUM8k042993 for ietf-pkix-bks; Mon, 24 Nov 2003 05:30:22 -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.10/8.12.8) with ESMTP id hAODUKkT042979 for <[e-mail]>; Mon, 24 Nov 2003 05:30:21 -0800 (PST) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id OAA27055 for <[e-mail]>; Mon, 24 Nov 2003 14:30:11 +0100 (MET)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.7); Mon, 24 Nov 2003 14:30:11 +0100 (MET)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id hAODU5t16565 for [e-mail]; Mon, 24 Nov 2003 14:30:05 +0100 (MET)
Date: Mon, 24 Nov 2003 14:30:05 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: TSA certificate content
X-Sun-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>

I would like to hear some opinion about the setting
of the extension keyUsage in a certificate for a
3161 TSA. 

The question is whether a certificate contain no
keyUsage extension at all and only an extended
key usage with the appropriate key purpose
is conformant with 3161 and 3280. 

Peter 


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAM3dikT001545 for <[e-mail]>; Fri, 21 Nov 2003 19:39:44 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAM3divP001544 for ietf-pkix-bks; Fri, 21 Nov 2003 19:39:44 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mtiwmhc13.worldnet.att.net (mtiwmhc13.worldnet.att.net [204.127.131.117]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAM3dhkT001538 for <[e-mail]>; Fri, 21 Nov 2003 19:39:44 -0800 (PST) (envelope-from [e-mail])
Received: from wchokhani (86.washington-28rh16rt.dc.dial-access.att.net[12.77.43.86]) by worldnet.att.net (mtiwmhc13) with SMTP id <2003112203392711300rjqjne>; Sat, 22 Nov 2003 03:39:27 +0000
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: OCSPv1 and nonces (RE: draft meeting minutes)
Date: Fri, 21 Nov 2003 22:39:23 -0500
MIME-Version: 1.0
Message-ID: <009101c3b0aa$39803be0$[e-mail]>
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
Content-Type: multipart/signed; boundary="----=_NextPart_000_008D_01C3B07F.74650AE0"; protocol="application/x-pkcs7-signature"; micalg=SHA1
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
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_000_008D_01C3B07F.74650AE0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Russ:

I also think Marc's proposal may be the best way forward given the way the
RFC is written.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Marc Branchaud
Sent: Friday, November 21, 2003 5:41 PM
To: Russ Housley
Cc: [e-mail]
Subject: Re: OCSPv1 and nonces (RE: draft meeting minutes)


Russ Housley wrote:
>
> Section 4.1.2  of RFC 2560 says:
>
>    Support for any specific extension is OPTIONAL. The critical flag
>    SHOULD NOT be set for any of them.

I think that allowing critical nonces in requests is perfectly
compatible with that SHOULD NOT statement.

RFC2119 sez:

4. SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean that
    there may exist valid reasons in particular circumstances when the
    particular behavior is acceptable or even useful, but the full
    implications should be understood and the case carefully weighed
    before implementing any behavior described with this label.

I think that we have a valid reason to use the critical flag here.

		M.

------=_NextPart_000_008D_01C3B07F.74650AE0
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUqTCCA9Yw
ggK+oAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwVTELMAkGA1UEBhMCVVMxITAfBgNVBAoTGE9yaW9u
IFNlY3VyaXR5IFNvbHV0aW9uczELMAkGA1UECxMCSFExFjAUBgNVBAMTDU9yaW9uIFJvb3QgQ0Ew
HhcNMDMwODEzMTcwMTI0WhcNMTMwODEwMTcwMTI0WjBVMQswCQYDVQQGEwJVUzEhMB8GA1UEChMY
T3Jpb24gU2VjdXJpdHkgU29sdXRpb25zMQswCQYDVQQLEwJIUTEWMBQGA1UEAxMNT3Jpb24gUm9v
dCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOd3fg/nIELr3rAuxpkcxiAn7ayU
/30RPxYBMgcvn0BJbBXBXIkTHgm3jh0TwHGQk76nqTSo1fUqpkkEcSSwEtfz1jF0QCKPHoQvNxza
5ffqH2gBSTgjpwqLA34RDxFDwcdNibIG/s6Zj2PpVDDWVBYxMbLrhKluMAfufhOMT6uyYxw+XPcU
ndqy4bRo08BONIoLdoUoOsvOwHla+zPYsBnTncMEL26lnKgCQgJpcFfrQRLrM84Rlc9EmvPbU+tO
5jRfdnvJpCm8LbIcTvAwQLiM+5qr4GPTg73S+9ZMAjlaZWG/VGe5b+KtQCgDu2TPB+wtiz2csG5q
YN14mFpKMdMCAwEAAaOBsDCBrTAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNV
HQ4EFgQUvpoqeR5tpH+G2bn1P06LoHH9Mq0wHwYDVR0jBBgwFoAUvpoqeR5tpH+G2bn1P06LoHH9
Mq0wEQYJYIZIAYb4QgEBBAQDAgAHMDcGA1UdHwQwMC4wLKAqoCiGJmh0dHA6Ly93d3cub3Jpb25z
ZWMuY29tL29yaW9uX3Jvb3QuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAch1imNzh8/wx6Ym3ti6FI
LyJMsktilc4I5zJ6ZRrZUMye/3v9XJDIutBPb472wOwQT+OR3DTbWX8loNybf3Ew3wWzZg+D14kQ
d/+rm3ZAJ3EeX67/g9XevAkrv951Q7QSucZMbbzrLqIWSkgjxJbcujNdeQsSlUz5I2Q9qYdAhg6G
85gf+GaStpaGlR5siWwJAQ/KeWrntfwNbh1P81Vmq/MovUQWPNKeM80FHcqHVVpQWasPTkGb0eW2
NOBsxGBCSQjc5QQdxPIMIuxmyVX42kGTK3O/IxI2O2QBK+pmFHEm4o+p+ekxxHekZTowPSeFXFYQ
SrnpmJyfcHa2vLTpMIID1zCCAr+gAwIBAgIBAjANBgkqhkiG9w0BAQUFADBVMQswCQYDVQQGEwJV
UzEhMB8GA1UEChMYT3Jpb24gU2VjdXJpdHkgU29sdXRpb25zMQswCQYDVQQLEwJIUTEWMBQGA1UE
AxMNT3Jpb24gUm9vdCBDQTAeFw0wMzA4MTQxNjQ4MzZaFw0wNDA4MTMxNjQ4MzZaMFYxCzAJBgNV
BAYTAlVTMSEwHwYDVQQKExhPcmlvbiBTZWN1cml0eSBTb2x1dGlvbnMxCzAJBgNVBAsTAkhRMRcw
FQYDVQQDEw5PcmlvbiBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL65
aM5ISSZ1ERaIjEaBDvZJ+U1iEEvdLoILkmuwzqrN0DMNhBwLUPJSYjGZ6xlGE5sRmDbUcFhRX0Dt
p/t0lKBl0zajquPRbO5t3whqhb0h5IgIRP19NOZ9Mo/XWML2eCVmDyy6lqK5NC+Uvdhf8SjjH+P2
WCk68KmELfqXSfHoKy9gKMEH9IFyL1EqbE8DTUuFmUzg3ZIpR9UMX0Yorx4YdQRyblH4fEUDNfUu
PHvRTZkyfAm8nrpsWCqOY0Q3Vl6OsfMqBaVYOORA9fDPLZLXvYc7Im3LDTAXvy+DTki2cR3rjLrO
+p3POH/SoH8/9eHhNk4fX/w4FvQMv9hIonECAwEAAaOBsDCBrTAPBgNVHRMBAf8EBTADAQH/MA4G
A1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQU+NvSaD0SiHYB9QkgqlK4n+fFAKEwHwYDVR0jBBgwFoAU
vpoqeR5tpH+G2bn1P06LoHH9Mq0wEQYJYIZIAYb4QgEBBAQDAgAHMDcGA1UdHwQwMC4wLKAqoCiG
Jmh0dHA6Ly93d3cub3Jpb25zZWMuY29tL29yaW9uX3Jvb3QuY3JsMA0GCSqGSIb3DQEBBQUAA4IB
AQDPS+PvtkWJ6V235n4Ntn5xWFgvS+GVMI3tBVid/DW2h3AxDWzKctlybc/FhO0sj7nlLXE5CQfm
ocx7m3mf1DcEz83b3BJNO9Dwa0U1kNL0kAFSXb9i+jaL3ovNoZlXxOcl73dK77eEohYbioUOtglM
HwXXOdbpbOPH1tX0fUr70Zp4KBczNdsQnSrbnHIe2zdNPKY5VPYonB6gxJTNxlbqcHYg56abe0En
Ad0C5IoMEG13CbHfDCm9uhRC5yHfylEZMOYA644+2d73FUsIstAdwK+pyeWXSaWGwN/xgLAGE5S1
Ryihlql/q4BXxqqU8RPm90g+2aj1e+PlnlXHxLWCMIID2jCCAsKgAwIBAgIBADANBgkqhkiG9w0B
AQUFADBVMQswCQYDVQQGEwJVUzEhMB8GA1UEChMYT3Jpb24gU2VjdXJpdHkgU29sdXRpb25zMQsw
CQYDVQQLEwJIUTEWMBQGA1UEAxMNT3Jpb24gUm9vdCBDQTAeFw0wMzA2MDUxNDI4NTlaFw0wNDA2
MDQxNDI4NTlaMFYxCzAJBgNVBAYTAlVTMSEwHwYDVQQKExhPcmlvbiBTZWN1cml0eSBTb2x1dGlv
bnMxCzAJBgNVBAsTAkhRMRcwFQYDVQQDEw5PcmlvbiBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEB
BQADggEPADCCAQoCggEBAL65aM5ISSZ1ERaIjEaBDvZJ+U1iEEvdLoILkmuwzqrN0DMNhBwLUPJS
YjGZ6xlGE5sRmDbUcFhRX0Dtp/t0lKBl0zajquPRbO5t3whqhb0h5IgIRP19NOZ9Mo/XWML2eCVm
Dyy6lqK5NC+Uvdhf8SjjH+P2WCk68KmELfqXSfHoKy9gKMEH9IFyL1EqbE8DTUuFmUzg3ZIpR9UM
X0Yorx4YdQRyblH4fEUDNfUuPHvRTZkyfAm8nrpsWCqOY0Q3Vl6OsfMqBaVYOORA9fDPLZLXvYc7
Im3LDTAXvy+DTki2cR3rjLrO+p3POH/SoH8/9eHhNk4fX/w4FvQMv9hIonECAwEAAaOBszCBsDAS
BgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQU+NvSaD0SiHYB9Qkg
qlK4n+fFAKEwHwYDVR0jBBgwFoAUvpoqeR5tpH+G2bn1P06LoHH9Mq0wEQYJYIZIAYb4QgEBBAQD
AgAHMDcGA1UdHwQwMC4wLKAqoCiGJmh0dHA6Ly93d3cub3Jpb25zZWMuY29tL29yaW9uX3Jvb3Qu
Y3JsMA0GCSqGSIb3DQEBBQUAA4IBAQCxgp0tv87jUcjW/N8p+FgFn6+vBZQ80DhtLSYfi1KGBgQn
kjXk1dgr6zPiBtfow/eyXCn7C2kErJIwwXbNv93s7N3ntpgh7DMD9A6I69zKTeMvzn4K2SCQ718s
Hhk9mTKceIj7joDG6KZ7lw2COiFx/oEUehRF6i601u9h8mHJ5HPpoAD+QyzBHfkmN6njulLYmY5W
8omXRl4fPZdWu3TNRPemxY859PrZiqrVjogqXOH7ceBttkQ1PnjLxZV0PKgyiAhzgBwWf+dkjWxq
NJtwJjGLntm+vVYpTbXuyY63U41rzEckGNOWdMoR8zwupTGmT1j5cNXkccGExpqnf2pbMIIEdzCC
A1+gAwIBAgIBIjANBgkqhkiG9w0BAQUFADBWMQswCQYDVQQGEwJVUzEhMB8GA1UEChMYT3Jpb24g
U2VjdXJpdHkgU29sdXRpb25zMQswCQYDVQQLEwJIUTEXMBUGA1UEAxMOT3Jpb24gRW1haWwgQ0Ew
HhcNMDMwODE1MTgyMDM3WhcNMDQwODE0MTgyMDM3WjB+MQswCQYDVQQGEwJVUzEhMB8GA1UEChMY
T3Jpb24gU2VjdXJpdHkgU29sdXRpb25zMQswCQYDVQQLEwJIUTEZMBcGA1UEAxMQU2FudG9zaCBD
aG9raGFuaTEkMCIGCSqGSIb3DQEJARYVY2hva2hhbmlAb3Jpb25zZWMuY29tMIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0EadobvmWyC1UbtEuos8DmEK7vsk72z3USFc4MF4I71ctasT
uT7n3eY0RsXK5NSrGNufwwup7ksdZAo/a6GPxiGMDOaQtJi8VaACzPUyqzZZJEKtaolcD4fS8V6O
FyBdMmdMBebd0GrcNVmabvgVIm3h5Oe3sUzZxqkduueAkjMstGnBtUWG431HzM3vOTzkbHzkMoNT
FgMEayhHrklyecveHOgiqhOypAiKSv5acM2vgzreh5gbHEJfqOfS56+exTAz/MrpdzvXmv0kmrwM
BOtTM1rOYhyjw2yzM07lBxstBMR0DIeqpf2dZN1IHOnnGWxSqql2Gdjn9bpplVN2EQIDAQABo4IB
JjCCASIwHQYDVR0OBBYEFPQLCXgNtykUjPyCwMO9MWrT0A86MB8GA1UdIwQYMBaAFPjb0mg9Eoh2
AfUJIKpSuJ/nxQChMDcGA1UdHwQwMC4wLKAqoCiGJmh0dHA6Ly93d3cub3Jpb25zZWMuY29tL29y
aW9uX21haWwuY3JsMAkGA1UdEwQCMAAwQgYIKwYBBQUHAQEENjA0MDIGCCsGAQUFBzAChiZodHRw
Oi8vd3d3Lm9yaW9uc2VjLmNvbS9vcmlvbl9tYWlsLmRlcjAOBgNVHQ8BAf8EBAMCBDAwEwYDVR0l
BAwwCgYIKwYBBQUHAwQwEQYJYIZIAYb4QgEBBAQDAgWgMCAGA1UdEQQZMBeBFWNob2toYW5pQG9y
aW9uc2VjLmNvbTANBgkqhkiG9w0BAQUFAAOCAQEAOMNwcRoKaH2+5wC7MWhDrG98bOyphlE51btw
mPHS9Ob5XpJMJMlZI2kb2/4A71riaZZPcuFypMqxGIjaH7Y/Gi0aHsk7iWRMEMXiaCT2fq0WM1Wq
/sDgwMYVCvOjU8s5x+4i7y4tvS/eP01qcmqz5RABM85bmZ45qypM+JV246LxYRkVpESl62+iSkcg
U8hmtruiV7C8CX3yUZj//uwPH9F+7iwvSEAmH6vm4MxGxrMbo2yThsvJ6KNZ1XVlT3jtA66AhoKB
h++f7KfuqJbWUaQXVuvGESCHI79DCtXVUK7YFdHQxLU1Y63NkqRYTncrHtJlqzY2kxq5B/0vnPhg
1zCCBJcwggN/oAMCAQICASEwDQYJKoZIhvcNAQEFBQAwVjELMAkGA1UEBhMCVVMxITAfBgNVBAoT
GE9yaW9uIFNlY3VyaXR5IFNvbHV0aW9uczELMAkGA1UECxMCSFExFzAVBgNVBAMTDk9yaW9uIEVt
YWlsIENBMB4XDTAzMDgxNTE4MjAxN1oXDTA0MDgxNDE4MjAxN1owfjELMAkGA1UEBhMCVVMxITAf
BgNVBAoTGE9yaW9uIFNlY3VyaXR5IFNvbHV0aW9uczELMAkGA1UECxMCSFExGTAXBgNVBAMTEFNh
bnRvc2ggQ2hva2hhbmkxJDAiBgkqhkiG9w0BCQEWFWNob2toYW5pQG9yaW9uc2VjLmNvbTCCASIw
DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMLUZwZhoWYVw7zKNe5KLxQfXo0dKMKkph9MA+fN
X9YPW/LEbsjqdofCRJ1F8VZalpBrlz61ITyJ7/y+W1My0n0oOJhwvdhqRxE2QUv+bOP80i7BGqIm
4/wd35ZyABDG2mt5Jj2anwXUIK1KENCo1pYxhroil3qLhtd9xPiOOjUZ2wAmNEgFwxDcQE1xsNJt
J3Ro1O3VfceF53AxomEIZM300usixqnUSKbk8D8oVwUNBnMXdj+7K/0G/YJ9EPJFF5orwI1j9LE3
tdWBVY9a7WY1+ygHDMXaeYAnM2TkAuVGtWqTHTGmdNuyxsapFY7UFLtRjItA2oFb3bs/ho1tKrUC
AwEAAaOCAUYwggFCMB0GA1UdDgQWBBQSo0Fab6xpwZ5BxERoEuUigr/N2zAfBgNVHSMEGDAWgBT4
29JoPRKIdgH1CSCqUrif58UAoTA3BgNVHR8EMDAuMCygKqAohiZodHRwOi8vd3d3Lm9yaW9uc2Vj
LmNvbS9vcmlvbl9tYWlsLmNybDAJBgNVHRMEAjAAMEIGCCsGAQUFBwEBBDYwNDAyBggrBgEFBQcw
AoYmaHR0cDovL3d3dy5vcmlvbnNlYy5jb20vb3Jpb25fbWFpbC5kZXIwDgYDVR0PAQH/BAQDAgbA
MDMGA1UdJQQsMCoGCCsGAQUFBwMCBggrBgEFBQcDBAYIKwYBBQUHAwcGCisGAQQBgjcUAgIwEQYJ
YIZIAYb4QgEBBAQDAgWgMCAGA1UdEQQZMBeBFWNob2toYW5pQG9yaW9uc2VjLmNvbTANBgkqhkiG
9w0BAQUFAAOCAQEAmnUXuCAU2nzNbCAaRmH0JE1bFUr/bNPUoOHU7ATGfmk/QhiGPxaApPSU+CC8
JNgGOs6z6o/WCfKMj4srMkWjBKcFHNASw7oxsLdEj/JvIAcPVPwfV4RUBY7SU3svNPQILSYdD0LU
uhryAqMlNePrDPi5LWSyJ1q4ftRtZZlJdu50UjBSPwJcOhrn4CJAzu4DHRAWNLvVZ91m7c/E6LF4
Ajj1QC8Sd2HWpgc0iQf7XAN58+7Y9fF+F6VebVeuLws2IZNPfdTvq+1kHTOCVYasbh2IqdM7ryyr
z3rL0l3LOySD73mv/YU4Dt1brScFXq4hA5IcXNGvyn1gUw3HD8/cbjGCAyYwggMiAgEBMFswVjEL
MAkGA1UEBhMCVVMxITAfBgNVBAoTGE9yaW9uIFNlY3VyaXR5IFNvbHV0aW9uczELMAkGA1UECxMC
SFExFzAVBgNVBAMTDk9yaW9uIEVtYWlsIENBAgEhMAkGBSsOAwIaBQCgggGgMBgGCSqGSIb3DQEJ
AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMTEyMjAzMzMxNVowIwYJKoZIhvcNAQkE
MRYEFAqg66s29sqTPAHRMAUB7KVE3XC6MGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwBwYF
Kw4DAhowDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC
AgEoMAoGCCqGSIb3DQIFMGoGCSsGAQQBgjcQBDFdMFswVjELMAkGA1UEBhMCVVMxITAfBgNVBAoT
GE9yaW9uIFNlY3VyaXR5IFNvbHV0aW9uczELMAkGA1UECxMCSFExFzAVBgNVBAMTDk9yaW9uIEVt
YWlsIENBAgEiMGwGCyqGSIb3DQEJEAILMV2gWzBWMQswCQYDVQQGEwJVUzEhMB8GA1UEChMYT3Jp
b24gU2VjdXJpdHkgU29sdXRpb25zMQswCQYDVQQLEwJIUTEXMBUGA1UEAxMOT3Jpb24gRW1haWwg
Q0ECASIwDQYJKoZIhvcNAQEBBQAEggEAokPoJaVTKbPafBQIihCKCqESdrzNXeZHoyiDWmAa5i3B
793TTlnph3CUWmVWHo+pwRY0AZ9u7L6eFFA4y45DBJP9+JIXL9cQwbaADA7sBizfh4MFmzCG+UUs
a9piQrJqomDceMs3AyL96JeySnt/jmd0wcEN159xz0RGwT9ZmOeLqwU9s25FRmIhUNe7a42w5x3n
rtlgGMX25iqiueDeCXWs7kWcKWuR8IBRVXmFRx9d1Go8gP218Ne9juQHOkk8oTy2Y7SPTBzQ1fJ+
cd+udmg4GmKUg7bxl6FhB9nMWW6yrF273ugdnlvtjI5OOWxfJkBXDAM99rKQlGtxEFMqNQAAAAAA
AA==

------=_NextPart_000_008D_01C3B07F.74650AE0--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAM2vKkT099472 for <[e-mail]>; Fri, 21 Nov 2003 18:57:20 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAM2vKsP099471 for ietf-pkix-bks; Fri, 21 Nov 2003 18:57:20 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAM2vIkT099460 for <[e-mail]>; Fri, 21 Nov 2003 18:57:18 -0800 (PST) (envelope-from [e-mail])
Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 21 Nov 2003 18:57:46 -0800
Received: from 157.54.6.150 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 21 Nov 2003 18:57:16 -0800
Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 21 Nov 2003 18:57:23 -0800
Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Fri, 21 Nov 2003 18:57:20 -0800
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Fri, 21 Nov 2003 18:57:16 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.7097.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary"
Subject: RE: OCSPv1 and nonces (RE: draft meeting minutes)
Date: Fri, 21 Nov 2003 18:55:50 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: OCSPv1 and nonces (RE: draft meeting minutes)
Thread-Index: AcOwkuBBhDOz+Wn1SCWuYwgyc80cDQAEULZW
From: "Ryan M. Hurst" <[e-mail]>
To: "Marc Branchaud" <[e-mail]>, "Russ Housley" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 22 Nov 2003 02:57:16.0105 (UTC) FILETIME=[5608D390:01C3B0A4]
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.

--------------InterScan_NT_MIME_Boundary
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3B0A4.54BCB1A5"

------_=_NextPart_001_01C3B0A4.54BCB1A5
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

You are right, should not does mean not recomended however the likley =
impact is that clients that do this will not be able to interoperate =
with the existing servers out there.
=20
Maybe we should do a straw pole to determin what servers will do if they =
get the nonce marked critical.
=20
Ryan

________________________________

From: [e-mail] on behalf of Marc Branchaud
Sent: Fri 11/21/2003 2:41 PM
To: Russ Housley
Cc: [e-mail]
Subject: Re: OCSPv1 and nonces (RE: draft meeting minutes)



Russ Housley wrote:
>
> Section 4.1.2  of RFC 2560 says:
>
>    Support for any specific extension is OPTIONAL. The critical flag
>    SHOULD NOT be set for any of them.

I think that allowing critical nonces in requests is perfectly
compatible with that SHOULD NOT statement.

RFC2119 sez:

4. SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean that
    there may exist valid reasons in particular circumstances when the
    particular behavior is acceptable or even useful, but the full
    implications should be understood and the case carefully weighed
    before implementing any behavior described with this label.

I think that we have a valid reason to use the critical flag here.

                M.



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

<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">=0A=
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">=0A=
<HTML>=0A=
<HEAD>=0A=
=0A=
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7097.0">=0A=
<TITLE>Re: OCSPv1 and nonces (RE: draft meeting minutes)</TITLE>=0A=
</HEAD>=0A=
<BODY>=0A=
<DIV id=3DidOWAReplyText78044 dir=3Dltr>=0A=
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2>You are =
right, should not =0A=
does mean not recomended however the likley impact is that clients that =
do this =0A=
will not be able to interoperate with the existing servers out =0A=
there.</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Maybe we should do a straw =
pole to determin =0A=
what servers will do if they get the nonce marked critical.</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Ryan</FONT></DIV></DIV>=0A=
<DIV dir=3Dltr><BR>=0A=
<HR tabIndex=3D-1>=0A=
<FONT face=3DTahoma size=3D2><B>From:</B> [e-mail] =
on behalf of =0A=
Marc Branchaud<BR><B>Sent:</B> Fri 11/21/2003 2:41 PM<BR><B>To:</B> Russ =0A=
Housley<BR><B>Cc:</B> [e-mail]<BR><B>Subject:</B> Re: OCSPv1 =
and nonces =0A=
(RE: draft meeting minutes)<BR></FONT><BR></DIV>=0A=
<DIV>=0A=
<P><FONT size=3D2>Russ Housley wrote:<BR>&gt;<BR>&gt; Section =
4.1.2&nbsp; of RFC =0A=
2560 says:<BR>&gt;<BR>&gt;&nbsp;&nbsp;&nbsp; Support for any specific =
extension =0A=
is OPTIONAL. The critical flag<BR>&gt;&nbsp;&nbsp;&nbsp; SHOULD NOT be =
set for =0A=
any of them.<BR><BR>I think that allowing critical nonces in requests is =0A=
perfectly<BR>compatible with that SHOULD NOT statement.<BR><BR>RFC2119 =0A=
sez:<BR><BR>4. SHOULD NOT&nbsp;&nbsp; This phrase, or the phrase "NOT =0A=
RECOMMENDED" mean that<BR>&nbsp;&nbsp;&nbsp; there may exist valid =
reasons in =0A=
particular circumstances when the<BR>&nbsp;&nbsp;&nbsp; particular =
behavior is =0A=
acceptable or even useful, but the full<BR>&nbsp;&nbsp;&nbsp; =
implications =0A=
should be understood and the case carefully =
weighed<BR>&nbsp;&nbsp;&nbsp; before =0A=
implementing any behavior described with this label.<BR><BR>I think that =
we have =0A=
a valid reason to use the critical flag =0A=
here.<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =0A=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; M.<BR></FONT></P></DIV>=0A=
=0A=
</BODY>=0A=
</HTML>
------_=_NextPart_001_01C3B0A4.54BCB1A5--

--------------InterScan_NT_MIME_Boundary--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hALN1DkT089184 for <[e-mail]>; Fri, 21 Nov 2003 15:01:13 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hALN1DwX089183 for ietf-pkix-bks; Fri, 21 Nov 2003 15:01:13 -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.240.3]) by above.proper.com (8.12.10/8.12.8) with SMTP id hALN1CkT089178 for <[e-mail]>; Fri, 21 Nov 2003 15:01:12 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 22742 invoked by uid 0); 21 Nov 2003 23:00:56 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.34.72) by woodstock.binhost.com with SMTP; 21 Nov 2003 23:00:56 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Fri, 21 Nov 2003 18:01:10 -0500
To: Denis Pinkas <[e-mail]>, [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: WG last call re draft-pkix-acpolicies-extn-03.txt
Cc: [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
References: <003601c3856d$6c1b6510$[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>

These two OIDs have been assigned.

Russ

At 04:37 PM 11/21/2003 +0100, Denis Pinkas wrote:
>     Russ, as the custodian of the PKIX OID, would you assign these two new
>     OIDs to acps and acunotice ?
>
>     id-qt-acps       OBJECT IDENTIFIER ::=  { id-qt 4 }
>     id-qt-acunotice  OBJECT IDENTIFIER ::=  { id-qt 5 }



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hALMoCkT088765 for <[e-mail]>; Fri, 21 Nov 2003 14:50:12 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hALMoCkk088764 for ietf-pkix-bks; Fri, 21 Nov 2003 14:50:12 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from sigurd.x509.com ([199.175.155.2]) by above.proper.com (8.12.10/8.12.8) with SMTP id hALMoAkT088759 for <[e-mail]>; Fri, 21 Nov 2003 14:50:11 -0800 (PST) (envelope-from [e-mail])
Received: from nebula.x509.com by sigurd.x509.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 21 Nov 2003 22:50:13 UT
Received: from crack.x509.com (localhost [127.0.0.1]) by nebula.x509.com (8.12.10/NULL) with ESMTP id hALMkN6L022310; Fri, 21 Nov 2003 14:46:23 -0800 (PST)
Received: from exvan01.x509.com (exvan01.x509.com [10.9.22.50]) by crack.x509.com (8.12.10/8.12.10) with ESMTP id hALMoBY0003655; Fri, 21 Nov 2003 14:50:11 -0800 (PST)
Received: from rsasecurity.com (mbranchaud2.eng.x509.com [10.7.33.48]) by exvan01.x509.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id VQFWF8QR; Fri, 21 Nov 2003 14:58:59 -0800
Message-ID: <[e-mail]>
Date: Fri, 21 Nov 2003 14:41:00 -0800
X-Sybari-Trust: db514e99 64c784fd 0d23202c 00000139
From: Marc Branchaud <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5b) Gecko/20030903
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Russ Housley <[e-mail]>
CC: [e-mail]
Subject: Re: OCSPv1 and nonces (RE: draft meeting minutes)
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010202070803040302080102"
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.

--------------ms010202070803040302080102
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Russ Housley wrote:
> 
> Section 4.1.2  of RFC 2560 says:
> 
>    Support for any specific extension is OPTIONAL. The critical flag
>    SHOULD NOT be set for any of them.

I think that allowing critical nonces in requests is perfectly 
compatible with that SHOULD NOT statement.

RFC2119 sez:

4. SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean that
    there may exist valid reasons in particular circumstances when the
    particular behavior is acceptable or even useful, but the full
    implications should be understood and the case carefully weighed
    before implementing any behavior described with this label.

I think that we have a valid reason to use the critical flag here.

		M.

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISqTCC
AtcwggJAoAMCAQICEFgUQCxch7Sxp7XFFauIqpwwDQYJKoZIhvcNAQEFBQAwbDEaMBgGA1UE
ChMRUlNBIFNlY3VyaXR5IEluYy4xHjAcBgNVBAMTFVJTQSBQdWJsaWMgUm9vdCBDQSB2MTEu
MCwGCSqGSIb3DQEJARYfcnNha2VvbnJvb3RzaWduQHJzYXNlY3VyaXR5LmNvbTAeFw0wMjA5
MDYxNDEzNTJaFw0wNzA5MDYxNDEzNTJaMIGCMRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5j
LjEVMBMGA1UECxMMS0NBIFNlcnZpY2VzMRYwFAYDVQQDEw1SU0EgQ29ycG9yYXRlMRAwDgYD
VQQHEwdCZWRmb3JkMRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMQswCQYDVQQGEwJVUzCBnzAN
BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAqnOw876lPpMTkSqrqzpEON/609PDLEhmWX4tkC19
AHneDaoetL277GtYYXBCggP2E+s66MN1ccWXyApfWjCZkIHepPC08NVI1JRcbViW3kwLzDD2
w5T9QJcyL5V1pN/LQdxahM56TiLeXlPiJekdmTdJoo+5Pw4bQU+MxTqURk8CAwEAAaNjMGEw
HwYDVR0jBBgwFoAU9UwxelEDPyzXi5eZb6hxkKt4PZswHQYDVR0OBBYEFO2RCGt0t1lKkvah
HSJwJp8KrxaSMA8GA1UdEwQIMAYBAf8CAQMwDgYDVR0PAQH/BAQDAgGGMA0GCSqGSIb3DQEB
BQUAA4GBAHiSe1a79hnPr16PuBwUTBWbuNQ4GJNsyfrCXzAswIT2A2WtGZ1Hp1jEAWi9OfAX
IYAdy52Jyv9N87wAEbLUgVmsFEIlYM5mi6ag7YIRGp8JP5UhLAN9O5YHrR9FsrGK4WmSl3sY
W1qAPOXubFcfhTgUDIYzM30izZBP4nwO07FpMIIC+DCCAmGgAwIBAgIQeuiOriTayCwjwpmR
gmdIUjANBgkqhkiG9w0BAQUFADCBgjEaMBgGA1UEChMRUlNBIFNlY3VyaXR5IEluYy4xFTAT
BgNVBAsTDEtDQSBTZXJ2aWNlczEWMBQGA1UEAxMNUlNBIENvcnBvcmF0ZTEQMA4GA1UEBxMH
QmVkZm9yZDEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMwHhcNMDIwOTIz
MTkxMzAzWhcNMDYwOTIzMTUxMzAzWjCBjDEaMBgGA1UEChMRUlNBIFNlY3VyaXR5IEluYy4x
FTATBgNVBAsTDEtDQSBTZXJ2aWNlczEgMB4GA1UEAxMXUlNBIENsYXNzIDIgUGVyc29uYWwg
Q0ExEDAOBgNVBAcTB0JlZGZvcmQxFjAUBgNVBAgTDU1hc3NhY2h1c2V0dHMxCzAJBgNVBAYT
AlVTMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCkR9yiabyRo6+NwC3Sl8wPuUiBD3rP
sENNjXvzSbTAyXA8pDDndnlAa1nLUhSMgvn8g1sYMd0Bp+C1/mI5PFUZ8jukUK95yt+TK26L
hM/M5RUq/EINdDDdWzg9je498K6oGfyWR6ETSJbIrDe5qQcLCABs9E2gVKb7Z/FwFo3C9QID
AQABo2MwYTAPBgNVHRMECDAGAQH/AgECMA4GA1UdDwEB/wQEAwIBhjAfBgNVHSMEGDAWgBTt
kQhrdLdZSpL2oR0icCafCq8WkjAdBgNVHQ4EFgQUxpPuxqX+41WOz4ojH+6Y3iHyn6cwDQYJ
KoZIhvcNAQEFBQADgYEAcdRHBjq8GfdDoutUTJPtSzQd7XsdsQh2KBbu8utl92VQHuI0J5wc
Rc817G8YbmTtCt/xqAzrr6k7fdaoDBr/kBuVHA5FEJ94foPgrOlbT3zdziMATXh5ESSDLMx6
p8ITIsTJNmwszIG5P9AAKJCW48gu1ZZmLXhFbHcYJGf99pwwggMFMIICbqADAgECAhEAvhyf
0s21hKaAc2Nm1WX4LTANBgkqhkiG9w0BAQUFADCBuzEkMCIGA1UEBxMbVmFsaUNlcnQgVmFs
aWRhdGlvbiBOZXR3b3JrMRcwFQYDVQQKEw5WYWxpQ2VydCwgSW5jLjE1MDMGA1UECxMsVmFs
aUNlcnQgQ2xhc3MgMyBQb2xpY3kgVmFsaWRhdGlvbiBBdXRob3JpdHkxITAfBgNVBAMTGGh0
dHA6Ly93d3cudmFsaWNlcnQuY29tLzEgMB4GCSqGSIb3DQEJARYRaW5mb0B2YWxpY2VydC5j
b20wHhcNMDIwNDMwMTUzMDE5WhcNMTkwNDMwMDkyMTU1WjBsMRowGAYDVQQKExFSU0EgU2Vj
dXJpdHkgSW5jLjEeMBwGA1UEAxMVUlNBIFB1YmxpYyBSb290IENBIHYxMS4wLAYJKoZIhvcN
AQkBFh9yc2FrZW9ucm9vdHNpZ25AcnNhc2VjdXJpdHkuY29tMIGfMA0GCSqGSIb3DQEBAQUA
A4GNADCBiQKBgQC0dSVa2EQ740GxqiIKsHATT4f8XYwUU23pzRe5W6IVpt4jkwDWkgnvTcP6
M8PD4OfK6Imal4hAH/c3K/dUIH7YyQZRGAE5Y27G5klZYKidcFlrfautgVES170MLKFmJqym
2FWAfVOibXatRcw7B0S+mP9404jID/MaIpRXkH5JjwIDAQABo1cwVTAMBgNVHRMEBTADAQH/
MA4GA1UdDwEB/wQEAwIBhjAWBgNVHSAEDzANMAsGCSqGSIb3DQUGATAdBgNVHQ4EFgQU9Uwx
elEDPyzXi5eZb6hxkKt4PZswDQYJKoZIhvcNAQEFBQADgYEAKsviXBc1FeBT2hIwyWuGwnPZ
J9ctjrsO7NbVLjsx/EYclFFGwo+pphiwdUTml9yd7fXzfk0D+7LOs9ZA5xhiHVrGusV4OW4i
7hx2KVILkYlcXCN5tDltKwa5+BkGUuvZdyAoIhpyf61h7uKCFguhaJ+VOiNB4DPtsmxI+KxO
E6YwggTYMIIEQaADAgECAhBgzHl9dAoZGu0JMqXovSgdMA0GCSqGSIb3DQEBBQUAMIGMMRow
GAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEVMBMGA1UECxMMS0NBIFNlcnZpY2VzMSAwHgYD
VQQDExdSU0EgQ2xhc3MgMiBQZXJzb25hbCBDQTEQMA4GA1UEBxMHQmVkZm9yZDEWMBQGA1UE
CBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMwHhcNMDMwNzA3MjMwODEzWhcNMDQwNzA3
MjMwODEzWjCBvjETMBEGCgmSJomT8ixkARkWA2NvbTEbMBkGCgmSJomT8ixkARkWC3JzYXNl
Y3VyaXR5MRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEWMBQGA1UECxMNTm9ydGggQW1l
cmljYTEUMBIGA1UECxMLRW5naW5lZXJpbmcxFzAVBgNVBAMTDk1hcmMgQnJhbmNoYXVkMScw
JQYJKoZIhvcNAQkBFhhtYXJjbmFyY0Byc2FzZWN1cml0eS5jb20wggEiMA0GCSqGSIb3DQEB
AQUAA4IBDwAwggEKAoIBAQDg2xoRr+a/dtnuFG+oTHa+tGtzeObFazNhYV2iSLNED4fHRu86
tknBYFgXggcHW5gsyjfkCtVMzP2tCivmbJgvISo36vsCsmAJH6LRnJf8HsvfmWZaD9tzhDpL
QVsBHr88J0ZMdVniRc7MQoYeu/3hYtUBeGO9bGA6T8vTrnXYonnFtVoTqE62SFqPZZk7HpCS
X1n+dM3zSym2ylMFYE14nukF4I9vAhsQVzk3QNpghmzGj8uoEy9xpf3k0o5+neneAGvcSkwo
r1mH5tSqhrEQaZp7vuSA2bvXaZEnjZzZiTpPDzs1oMpn3guzYhU7wMKz6xvwvgEYyAAV+P5n
FWM/AgMBAAGjggGBMIIBfTCBkgYDVR0gBIGKMIGHMIGEBgkqhkiG9w0FBwIwdzAuBggrBgEF
BQcCARYiaHR0cDovL2NhLnJzYXNlY3VyaXR5LmNvbS9DUFMuaHRtbDBFBggrBgEFBQcCAjA5
MBgWEVJTQSBTZWN1cml0eSBJbmMuMAMCAQEaHUNQUyBJbmNvcnBvcmF0ZWQgYnkgcmVmZXJl
bmNlMCkGA1UdJQQiMCAGCisGAQQBgjcUAgIGCCsGAQUFBwMCBggrBgEFBQcDBDAjBgNVHREE
HDAagRhtYXJjbmFyY0Byc2FzZWN1cml0eS5jb20wDgYDVR0PAQH/BAQDAgeAMEYGA1UdHwQ/
MD0wO6A5oDeGNWh0dHA6Ly9jcmwucnNhc2VjdXJpdHkuY29tOjgwL1JTQUNsYXNzMlBlcnNv
bmFsQ0EuY3JsMB8GA1UdIwQYMBaAFMaT7sal/uNVjs+KIx/umN4h8p+nMB0GA1UdDgQWBBQ1
yQ/UrvKb563LjzHqJzBzrZp/ejANBgkqhkiG9w0BAQUFAAOBgQCV82oGGnglQQzklKg/wKhy
evNeJ6FNBZFhLlmZRNlKgqvPFmBcxygfBGpHqIhsHcrt2/AjhJuzAj7UdW1vTVCY5MkZw8P9
6+J6aTc3bNlGbk0jvcvVgDhmM4xYJLwMZKEw92HlRhfuMnj7ah9DTqbKSewmyAyOc+FLpGfd
lu6CgTCCBOkwggRSoAMCAQICEQDqxAXqre9Mr+FeYw3+MQhsMA0GCSqGSIb3DQEBBQUAMIGM
MRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEVMBMGA1UECxMMS0NBIFNlcnZpY2VzMSAw
HgYDVQQDExdSU0EgQ2xhc3MgMiBQZXJzb25hbCBDQTEQMA4GA1UEBxMHQmVkZm9yZDEWMBQG
A1UECBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMwHhcNMDMwNzA3MjMwODI4WhcNMDQw
NzA3MjMwODEzWjCBwjETMBEGCgmSJomT8ixkARkWA2NvbTEbMBkGCgmSJomT8ixkARkWC3Jz
YXNlY3VyaXR5MRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEWMBQGA1UECxMNTm9ydGgg
QW1lcmljYTEUMBIGA1UECxMLRW5naW5lZXJpbmcxGzAZBgNVBAMTEk1hcmMgQnJhbmNoYXVk
LUVuYzEnMCUGCSqGSIb3DQEJARYYbWFyY25hcmNAcnNhc2VjdXJpdHkuY29tMIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwBjNaHTwtCXpdJg+iDxYMkWjuZIF0ic2fRLymZe+
BnZYWPnik0dFmTulx+V8slsLEtBllcc5o1yfIYfeHPinwRxv86kCUSlgfGGXKjJZaIeURgbo
bUbIfDTPlvRUZuiZvTR4C8tEY88Lle66n62B7wjUvDbiwK4EjzlXOkjpcYXLH7FbaFaRLDBB
PlFD5ydDRhQ67t6fjUeS7p7o/l/VHmPC5LFLXZkjEhjGd5pknbQIAbUGACL5UET85NUFPowD
3F47g0GCKEnuOsk2Ra+WHu7honhIxqmOwGnu85V6tW5xscf4dTofWZONQeaD3gSxv8+hcfKN
k9cwjpnUG2xGzwIDAQABo4IBjTCCAYkwNQYDVR0lBC4wLAYKKwYBBAGCNxQCAgYIKwYBBQUH
AwIGCCsGAQUFBwMEBgorBgEEAYI3CgMEMIGSBgNVHSAEgYowgYcwgYQGCSqGSIb3DQUHAjB3
MC4GCCsGAQUFBwIBFiJodHRwOi8vY2EucnNhc2VjdXJpdHkuY29tL0NQUy5odG1sMEUGCCsG
AQUFBwICMDkwGBYRUlNBIFNlY3VyaXR5IEluYy4wAwIBARodQ1BTIEluY29ycG9yYXRlZCBi
eSByZWZlcmVuY2UwIwYDVR0RBBwwGoEYbWFyY25hcmNAcnNhc2VjdXJpdHkuY29tMEYGA1Ud
HwQ/MD0wO6A5oDeGNWh0dHA6Ly9jcmwucnNhc2VjdXJpdHkuY29tOjgwL1JTQUNsYXNzMlBl
cnNvbmFsQ0EuY3JsMB8GA1UdIwQYMBaAFMaT7sal/uNVjs+KIx/umN4h8p+nMB0GA1UdDgQW
BBT/OiMCyY8CPnNBySW1ijJOYhj7ejAOBgNVHQ8BAf8EBAMCAzgwDQYJKoZIhvcNAQEFBQAD
gYEAlchAObA9eVmeiLu0nTU985Fch6v+EZKodUhZUN7dILgd05HorHN9jxBH6XI4/b9ZVvub
Pkpicdc112YbcLYTD2NumVksyNDI7fDaqiszgk1zluXtZJ+HsCt+GIAKCDfOVLECclpGyizq
VjZFEK4Pt9FxPGTnUJEvIKJcAQ24EvgxggPsMIID6AIBATCBoTCBjDEaMBgGA1UEChMRUlNB
IFNlY3VyaXR5IEluYy4xFTATBgNVBAsTDEtDQSBTZXJ2aWNlczEgMB4GA1UEAxMXUlNBIENs
YXNzIDIgUGVyc29uYWwgQ0ExEDAOBgNVBAcTB0JlZGZvcmQxFjAUBgNVBAgTDU1hc3NhY2h1
c2V0dHMxCzAJBgNVBAYTAlVTAhBgzHl9dAoZGu0JMqXovSgdMAkGBSsOAwIaBQCgggIfMBgG
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMTEyMTIyNDEwMFow
IwYJKoZIhvcNAQkEMRYEFBC1vY9v9WZBUZQ/PfPZZmDTY5i2MFIGCSqGSIb3DQEJDzFFMEMw
CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G
CCqGSIb3DQMCAgEoMIGzBgkrBgEEAYI3EAQxgaUwgaIwgYwxGjAYBgNVBAoTEVJTQSBTZWN1
cml0eSBJbmMuMRUwEwYDVQQLEwxLQ0EgU2VydmljZXMxIDAeBgNVBAMTF1JTQSBDbGFzcyAy
IFBlcnNvbmFsIENBMRAwDgYDVQQHEwdCZWRmb3JkMRYwFAYDVQQIEw1NYXNzYWNodXNldHRz
MQswCQYDVQQGEwJVUwIRAOrEBeqt70yv4V5jDf4xCGwwgbUGCyqGSIb3DQEJEAILMYGloIGi
MIGMMRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEVMBMGA1UECxMMS0NBIFNlcnZpY2Vz
MSAwHgYDVQQDExdSU0EgQ2xhc3MgMiBQZXJzb25hbCBDQTEQMA4GA1UEBxMHQmVkZm9yZDEW
MBQGA1UECBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMCEQDqxAXqre9Mr+FeYw3+MQhs
MA0GCSqGSIb3DQEBAQUABIIBAGxhYrM+qcsMCEZGV6CbO94g0CKwC3xoLwKTkQHM66TRhS0x
dJobH2vKoEjt/TYkhbKBlwZcl9fnYDrBhEJiQnvRmPg7TRzTt/QJP6iZgKgFJeGptWnmTfFz
beOl1/OJN2BAfbTf7205dNEtG9EN/Mrld480cNZ/4RQAbyd0oBAu+MlPR4+dGAclk9klnThd
CuHmS7VBz/1BsE2IfPU9vt4acCIatHEuHixXwvwsf6i4U9M8aNhHBQy0Pw7yZu2KiLKf2Nin
88ROxA/kI4j9Riim2FKrMxgbT933F/ymxVnQlRQheTxLusM3TDM6n8PsWNTOrbUVLX0WSsp0
18EeAysAAAAAAAA=
--------------ms010202070803040302080102--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hALMVRkT088207 for <[e-mail]>; Fri, 21 Nov 2003 14:31:27 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hALMVR6M088206 for ietf-pkix-bks; Fri, 21 Nov 2003 14:31:27 -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.240.3]) by above.proper.com (8.12.10/8.12.8) with SMTP id hALMVQkT088201 for <[e-mail]>; Fri, 21 Nov 2003 14:31:26 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 19283 invoked by uid 0); 21 Nov 2003 22:30:55 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.34.72) by woodstock.binhost.com with SMTP; 21 Nov 2003 22:30:55 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Fri, 21 Nov 2003 17:31:08 -0500
To: Marc Branchaud <[e-mail]>, [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: OCSPv1 and nonces (RE: draft meeting minutes) 
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>

Marc:

I considered this approach too.  And right now, it may be the best way 
forward, but it does still have an impact on the specification.

Section 4.1.2  of RFC 2560 says:

    Support for any specific extension is OPTIONAL. The critical flag
    SHOULD NOT be set for any of them.

Russ


At 10:43 AM 11/21/2003 -0800, Marc Branchaud wrote:

>It seems to me that we could simply allow clients to make the nonce 
>extension critical.
>
>
>If the client makes nonce critical, it is essentially telling the server 
>that it will not accept a nonceless (cached) response.
>
>
>OTOH, if the client is willing to accept nonceless responses, it simply 
>makes the request's nonce extension non-critical.
>
>
>Responders that don't support nonces (e.g. caching or pre-generating 
>responders) have to return an error (internalError?) if the request has a 
>critical nonce extension.
>
>
>This approach doesn't add any new MUSTs or SHOULDs.  It just gives clients 
>the ability to ensure that their local policies are followed.
>
>
>                 M.
>
>
> >
>List-ID: <ietf-pkix.imc.org>
>List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
>X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on woodstock
>X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.60
>X-Spam-Level:
>
><file://c:\program files\qualcomm\eudora\attach\Re OCSPv1 and nonces (RE 
>draf.ems <0265.0002>>Re OCSPv1 and nonces (RE draf.ems



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hALLwKkT087164 for <[e-mail]>; Fri, 21 Nov 2003 13:58:20 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hALLwK2a087163 for ietf-pkix-bks; Fri, 21 Nov 2003 13:58:20 -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.10/8.12.8) with ESMTP id hALLwJkT087156 for <[e-mail]>; Fri, 21 Nov 2003 13:58:19 -0800 (PST) (envelope-from [e-mail])
Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 21 Nov 2003 13:57:31 -0800
Received: from 157.54.5.25 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 21 Nov 2003 13:58:15 -0800
Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 21 Nov 2003 13:58:14 -0800
Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Fri, 21 Nov 2003 13:57:22 -0800
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Fri, 21 Nov 2003 13:58:09 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.7097.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: OCSPv1 and nonces (RE: draft meeting minutes)
Date: Fri, 21 Nov 2003 13:59:03 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: OCSPv1 and nonces (RE: draft meeting minutes)
Thread-Index: AcOweIxZUGV3n2GDTcqSLEPpygN1nwAAc4nQ
From: "Ryan M. Hurst" <[e-mail]>
To: "Marc Branchaud" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 21 Nov 2003 21:58:09.0850 (UTC) FILETIME=[8D3BA1A0:01C3B07A]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id hALLwJkT087159
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 this seems like a simple approach however the OCSP RFC
(http://ietf.org/rfc/rfc2560.txt?number=2560 ) states that extensions
SHOULD NOT be critical; the concern here is that using this scheme to
communicate this policy would be a violation of that statement and make
folks incompatible.

Ryan

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Marc Branchaud
Sent: Friday, November 21, 2003 11:35 AM
To: [e-mail]
Subject: Re: OCSPv1 and nonces (RE: draft meeting minutes)


Marc Branchaud wrote:
> 
> OTOH, if the client is willing to accept nonceless responses, it
simply 
> makes the request's nonce extension non-critical.

I also should've explicitly pointed out that it would be OK for a 
caching server to return a nonceless response in this case (i.e. to a 
request with a non-critical nonce).

		M.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hALJiLkT080866 for <[e-mail]>; Fri, 21 Nov 2003 11:44:21 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hALJiLGU080865 for ietf-pkix-bks; Fri, 21 Nov 2003 11:44:21 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from sigurd.x509.com ([199.175.155.2]) by above.proper.com (8.12.10/8.12.8) with SMTP id hALJiKkT080860 for <[e-mail]>; Fri, 21 Nov 2003 11:44:20 -0800 (PST) (envelope-from [e-mail])
Received: from nebula.x509.com by sigurd.x509.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 21 Nov 2003 19:44:22 UT
Received: from crack.x509.com (localhost [127.0.0.1]) by nebula.x509.com (8.12.10/NULL) with ESMTP id hALJeW6L017795 for <[e-mail]>; Fri, 21 Nov 2003 11:40:32 -0800 (PST)
Received: from exvan01.x509.com (exvan01.x509.com [10.9.22.50]) by crack.x509.com (8.12.10/8.12.10) with ESMTP id hALJiKY0028286 for <[e-mail]>; Fri, 21 Nov 2003 11:44:20 -0800 (PST)
Received: from rsasecurity.com (mbranchaud2.eng.x509.com [10.7.33.48]) by exvan01.x509.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id VQFWF7B2; Fri, 21 Nov 2003 11:53:07 -0800
Message-ID: <[e-mail]>
Date: Fri, 21 Nov 2003 11:35:09 -0800
X-Sybari-Trust: abbd0542 64c784fd 0d23202c 00000139
From: Marc Branchaud <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5b) Gecko/20030903
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: OCSPv1 and nonces (RE: draft meeting minutes)
References: <Pine.WNT.4.58.0311191446300.5344@mnystrom-lap> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090800080805040505010609"
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.

--------------ms090800080805040505010609
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit


Marc Branchaud wrote:
> 
> OTOH, if the client is willing to accept nonceless responses, it simply 
> makes the request's nonce extension non-critical.

I also should've explicitly pointed out that it would be OK for a 
caching server to return a nonceless response in this case (i.e. to a 
request with a non-critical nonce).

		M.

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISqTCC
AtcwggJAoAMCAQICEFgUQCxch7Sxp7XFFauIqpwwDQYJKoZIhvcNAQEFBQAwbDEaMBgGA1UE
ChMRUlNBIFNlY3VyaXR5IEluYy4xHjAcBgNVBAMTFVJTQSBQdWJsaWMgUm9vdCBDQSB2MTEu
MCwGCSqGSIb3DQEJARYfcnNha2VvbnJvb3RzaWduQHJzYXNlY3VyaXR5LmNvbTAeFw0wMjA5
MDYxNDEzNTJaFw0wNzA5MDYxNDEzNTJaMIGCMRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5j
LjEVMBMGA1UECxMMS0NBIFNlcnZpY2VzMRYwFAYDVQQDEw1SU0EgQ29ycG9yYXRlMRAwDgYD
VQQHEwdCZWRmb3JkMRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMQswCQYDVQQGEwJVUzCBnzAN
BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAqnOw876lPpMTkSqrqzpEON/609PDLEhmWX4tkC19
AHneDaoetL277GtYYXBCggP2E+s66MN1ccWXyApfWjCZkIHepPC08NVI1JRcbViW3kwLzDD2
w5T9QJcyL5V1pN/LQdxahM56TiLeXlPiJekdmTdJoo+5Pw4bQU+MxTqURk8CAwEAAaNjMGEw
HwYDVR0jBBgwFoAU9UwxelEDPyzXi5eZb6hxkKt4PZswHQYDVR0OBBYEFO2RCGt0t1lKkvah
HSJwJp8KrxaSMA8GA1UdEwQIMAYBAf8CAQMwDgYDVR0PAQH/BAQDAgGGMA0GCSqGSIb3DQEB
BQUAA4GBAHiSe1a79hnPr16PuBwUTBWbuNQ4GJNsyfrCXzAswIT2A2WtGZ1Hp1jEAWi9OfAX
IYAdy52Jyv9N87wAEbLUgVmsFEIlYM5mi6ag7YIRGp8JP5UhLAN9O5YHrR9FsrGK4WmSl3sY
W1qAPOXubFcfhTgUDIYzM30izZBP4nwO07FpMIIC+DCCAmGgAwIBAgIQeuiOriTayCwjwpmR
gmdIUjANBgkqhkiG9w0BAQUFADCBgjEaMBgGA1UEChMRUlNBIFNlY3VyaXR5IEluYy4xFTAT
BgNVBAsTDEtDQSBTZXJ2aWNlczEWMBQGA1UEAxMNUlNBIENvcnBvcmF0ZTEQMA4GA1UEBxMH
QmVkZm9yZDEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMwHhcNMDIwOTIz
MTkxMzAzWhcNMDYwOTIzMTUxMzAzWjCBjDEaMBgGA1UEChMRUlNBIFNlY3VyaXR5IEluYy4x
FTATBgNVBAsTDEtDQSBTZXJ2aWNlczEgMB4GA1UEAxMXUlNBIENsYXNzIDIgUGVyc29uYWwg
Q0ExEDAOBgNVBAcTB0JlZGZvcmQxFjAUBgNVBAgTDU1hc3NhY2h1c2V0dHMxCzAJBgNVBAYT
AlVTMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCkR9yiabyRo6+NwC3Sl8wPuUiBD3rP
sENNjXvzSbTAyXA8pDDndnlAa1nLUhSMgvn8g1sYMd0Bp+C1/mI5PFUZ8jukUK95yt+TK26L
hM/M5RUq/EINdDDdWzg9je498K6oGfyWR6ETSJbIrDe5qQcLCABs9E2gVKb7Z/FwFo3C9QID
AQABo2MwYTAPBgNVHRMECDAGAQH/AgECMA4GA1UdDwEB/wQEAwIBhjAfBgNVHSMEGDAWgBTt
kQhrdLdZSpL2oR0icCafCq8WkjAdBgNVHQ4EFgQUxpPuxqX+41WOz4ojH+6Y3iHyn6cwDQYJ
KoZIhvcNAQEFBQADgYEAcdRHBjq8GfdDoutUTJPtSzQd7XsdsQh2KBbu8utl92VQHuI0J5wc
Rc817G8YbmTtCt/xqAzrr6k7fdaoDBr/kBuVHA5FEJ94foPgrOlbT3zdziMATXh5ESSDLMx6
p8ITIsTJNmwszIG5P9AAKJCW48gu1ZZmLXhFbHcYJGf99pwwggMFMIICbqADAgECAhEAvhyf
0s21hKaAc2Nm1WX4LTANBgkqhkiG9w0BAQUFADCBuzEkMCIGA1UEBxMbVmFsaUNlcnQgVmFs
aWRhdGlvbiBOZXR3b3JrMRcwFQYDVQQKEw5WYWxpQ2VydCwgSW5jLjE1MDMGA1UECxMsVmFs
aUNlcnQgQ2xhc3MgMyBQb2xpY3kgVmFsaWRhdGlvbiBBdXRob3JpdHkxITAfBgNVBAMTGGh0
dHA6Ly93d3cudmFsaWNlcnQuY29tLzEgMB4GCSqGSIb3DQEJARYRaW5mb0B2YWxpY2VydC5j
b20wHhcNMDIwNDMwMTUzMDE5WhcNMTkwNDMwMDkyMTU1WjBsMRowGAYDVQQKExFSU0EgU2Vj
dXJpdHkgSW5jLjEeMBwGA1UEAxMVUlNBIFB1YmxpYyBSb290IENBIHYxMS4wLAYJKoZIhvcN
AQkBFh9yc2FrZW9ucm9vdHNpZ25AcnNhc2VjdXJpdHkuY29tMIGfMA0GCSqGSIb3DQEBAQUA
A4GNADCBiQKBgQC0dSVa2EQ740GxqiIKsHATT4f8XYwUU23pzRe5W6IVpt4jkwDWkgnvTcP6
M8PD4OfK6Imal4hAH/c3K/dUIH7YyQZRGAE5Y27G5klZYKidcFlrfautgVES170MLKFmJqym
2FWAfVOibXatRcw7B0S+mP9404jID/MaIpRXkH5JjwIDAQABo1cwVTAMBgNVHRMEBTADAQH/
MA4GA1UdDwEB/wQEAwIBhjAWBgNVHSAEDzANMAsGCSqGSIb3DQUGATAdBgNVHQ4EFgQU9Uwx
elEDPyzXi5eZb6hxkKt4PZswDQYJKoZIhvcNAQEFBQADgYEAKsviXBc1FeBT2hIwyWuGwnPZ
J9ctjrsO7NbVLjsx/EYclFFGwo+pphiwdUTml9yd7fXzfk0D+7LOs9ZA5xhiHVrGusV4OW4i
7hx2KVILkYlcXCN5tDltKwa5+BkGUuvZdyAoIhpyf61h7uKCFguhaJ+VOiNB4DPtsmxI+KxO
E6YwggTYMIIEQaADAgECAhBgzHl9dAoZGu0JMqXovSgdMA0GCSqGSIb3DQEBBQUAMIGMMRow
GAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEVMBMGA1UECxMMS0NBIFNlcnZpY2VzMSAwHgYD
VQQDExdSU0EgQ2xhc3MgMiBQZXJzb25hbCBDQTEQMA4GA1UEBxMHQmVkZm9yZDEWMBQGA1UE
CBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMwHhcNMDMwNzA3MjMwODEzWhcNMDQwNzA3
MjMwODEzWjCBvjETMBEGCgmSJomT8ixkARkWA2NvbTEbMBkGCgmSJomT8ixkARkWC3JzYXNl
Y3VyaXR5MRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEWMBQGA1UECxMNTm9ydGggQW1l
cmljYTEUMBIGA1UECxMLRW5naW5lZXJpbmcxFzAVBgNVBAMTDk1hcmMgQnJhbmNoYXVkMScw
JQYJKoZIhvcNAQkBFhhtYXJjbmFyY0Byc2FzZWN1cml0eS5jb20wggEiMA0GCSqGSIb3DQEB
AQUAA4IBDwAwggEKAoIBAQDg2xoRr+a/dtnuFG+oTHa+tGtzeObFazNhYV2iSLNED4fHRu86
tknBYFgXggcHW5gsyjfkCtVMzP2tCivmbJgvISo36vsCsmAJH6LRnJf8HsvfmWZaD9tzhDpL
QVsBHr88J0ZMdVniRc7MQoYeu/3hYtUBeGO9bGA6T8vTrnXYonnFtVoTqE62SFqPZZk7HpCS
X1n+dM3zSym2ylMFYE14nukF4I9vAhsQVzk3QNpghmzGj8uoEy9xpf3k0o5+neneAGvcSkwo
r1mH5tSqhrEQaZp7vuSA2bvXaZEnjZzZiTpPDzs1oMpn3guzYhU7wMKz6xvwvgEYyAAV+P5n
FWM/AgMBAAGjggGBMIIBfTCBkgYDVR0gBIGKMIGHMIGEBgkqhkiG9w0FBwIwdzAuBggrBgEF
BQcCARYiaHR0cDovL2NhLnJzYXNlY3VyaXR5LmNvbS9DUFMuaHRtbDBFBggrBgEFBQcCAjA5
MBgWEVJTQSBTZWN1cml0eSBJbmMuMAMCAQEaHUNQUyBJbmNvcnBvcmF0ZWQgYnkgcmVmZXJl
bmNlMCkGA1UdJQQiMCAGCisGAQQBgjcUAgIGCCsGAQUFBwMCBggrBgEFBQcDBDAjBgNVHREE
HDAagRhtYXJjbmFyY0Byc2FzZWN1cml0eS5jb20wDgYDVR0PAQH/BAQDAgeAMEYGA1UdHwQ/
MD0wO6A5oDeGNWh0dHA6Ly9jcmwucnNhc2VjdXJpdHkuY29tOjgwL1JTQUNsYXNzMlBlcnNv
bmFsQ0EuY3JsMB8GA1UdIwQYMBaAFMaT7sal/uNVjs+KIx/umN4h8p+nMB0GA1UdDgQWBBQ1
yQ/UrvKb563LjzHqJzBzrZp/ejANBgkqhkiG9w0BAQUFAAOBgQCV82oGGnglQQzklKg/wKhy
evNeJ6FNBZFhLlmZRNlKgqvPFmBcxygfBGpHqIhsHcrt2/AjhJuzAj7UdW1vTVCY5MkZw8P9
6+J6aTc3bNlGbk0jvcvVgDhmM4xYJLwMZKEw92HlRhfuMnj7ah9DTqbKSewmyAyOc+FLpGfd
lu6CgTCCBOkwggRSoAMCAQICEQDqxAXqre9Mr+FeYw3+MQhsMA0GCSqGSIb3DQEBBQUAMIGM
MRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEVMBMGA1UECxMMS0NBIFNlcnZpY2VzMSAw
HgYDVQQDExdSU0EgQ2xhc3MgMiBQZXJzb25hbCBDQTEQMA4GA1UEBxMHQmVkZm9yZDEWMBQG
A1UECBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMwHhcNMDMwNzA3MjMwODI4WhcNMDQw
NzA3MjMwODEzWjCBwjETMBEGCgmSJomT8ixkARkWA2NvbTEbMBkGCgmSJomT8ixkARkWC3Jz
YXNlY3VyaXR5MRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEWMBQGA1UECxMNTm9ydGgg
QW1lcmljYTEUMBIGA1UECxMLRW5naW5lZXJpbmcxGzAZBgNVBAMTEk1hcmMgQnJhbmNoYXVk
LUVuYzEnMCUGCSqGSIb3DQEJARYYbWFyY25hcmNAcnNhc2VjdXJpdHkuY29tMIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwBjNaHTwtCXpdJg+iDxYMkWjuZIF0ic2fRLymZe+
BnZYWPnik0dFmTulx+V8slsLEtBllcc5o1yfIYfeHPinwRxv86kCUSlgfGGXKjJZaIeURgbo
bUbIfDTPlvRUZuiZvTR4C8tEY88Lle66n62B7wjUvDbiwK4EjzlXOkjpcYXLH7FbaFaRLDBB
PlFD5ydDRhQ67t6fjUeS7p7o/l/VHmPC5LFLXZkjEhjGd5pknbQIAbUGACL5UET85NUFPowD
3F47g0GCKEnuOsk2Ra+WHu7honhIxqmOwGnu85V6tW5xscf4dTofWZONQeaD3gSxv8+hcfKN
k9cwjpnUG2xGzwIDAQABo4IBjTCCAYkwNQYDVR0lBC4wLAYKKwYBBAGCNxQCAgYIKwYBBQUH
AwIGCCsGAQUFBwMEBgorBgEEAYI3CgMEMIGSBgNVHSAEgYowgYcwgYQGCSqGSIb3DQUHAjB3
MC4GCCsGAQUFBwIBFiJodHRwOi8vY2EucnNhc2VjdXJpdHkuY29tL0NQUy5odG1sMEUGCCsG
AQUFBwICMDkwGBYRUlNBIFNlY3VyaXR5IEluYy4wAwIBARodQ1BTIEluY29ycG9yYXRlZCBi
eSByZWZlcmVuY2UwIwYDVR0RBBwwGoEYbWFyY25hcmNAcnNhc2VjdXJpdHkuY29tMEYGA1Ud
HwQ/MD0wO6A5oDeGNWh0dHA6Ly9jcmwucnNhc2VjdXJpdHkuY29tOjgwL1JTQUNsYXNzMlBl
cnNvbmFsQ0EuY3JsMB8GA1UdIwQYMBaAFMaT7sal/uNVjs+KIx/umN4h8p+nMB0GA1UdDgQW
BBT/OiMCyY8CPnNBySW1ijJOYhj7ejAOBgNVHQ8BAf8EBAMCAzgwDQYJKoZIhvcNAQEFBQAD
gYEAlchAObA9eVmeiLu0nTU985Fch6v+EZKodUhZUN7dILgd05HorHN9jxBH6XI4/b9ZVvub
Pkpicdc112YbcLYTD2NumVksyNDI7fDaqiszgk1zluXtZJ+HsCt+GIAKCDfOVLECclpGyizq
VjZFEK4Pt9FxPGTnUJEvIKJcAQ24EvgxggPsMIID6AIBATCBoTCBjDEaMBgGA1UEChMRUlNB
IFNlY3VyaXR5IEluYy4xFTATBgNVBAsTDEtDQSBTZXJ2aWNlczEgMB4GA1UEAxMXUlNBIENs
YXNzIDIgUGVyc29uYWwgQ0ExEDAOBgNVBAcTB0JlZGZvcmQxFjAUBgNVBAgTDU1hc3NhY2h1
c2V0dHMxCzAJBgNVBAYTAlVTAhBgzHl9dAoZGu0JMqXovSgdMAkGBSsOAwIaBQCgggIfMBgG
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMTEyMTE5MzUwOVow
IwYJKoZIhvcNAQkEMRYEFMDbkrCfHozcPCewt9X73Vj9wQJWMFIGCSqGSIb3DQEJDzFFMEMw
CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G
CCqGSIb3DQMCAgEoMIGzBgkrBgEEAYI3EAQxgaUwgaIwgYwxGjAYBgNVBAoTEVJTQSBTZWN1
cml0eSBJbmMuMRUwEwYDVQQLEwxLQ0EgU2VydmljZXMxIDAeBgNVBAMTF1JTQSBDbGFzcyAy
IFBlcnNvbmFsIENBMRAwDgYDVQQHEwdCZWRmb3JkMRYwFAYDVQQIEw1NYXNzYWNodXNldHRz
MQswCQYDVQQGEwJVUwIRAOrEBeqt70yv4V5jDf4xCGwwgbUGCyqGSIb3DQEJEAILMYGloIGi
MIGMMRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEVMBMGA1UECxMMS0NBIFNlcnZpY2Vz
MSAwHgYDVQQDExdSU0EgQ2xhc3MgMiBQZXJzb25hbCBDQTEQMA4GA1UEBxMHQmVkZm9yZDEW
MBQGA1UECBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMCEQDqxAXqre9Mr+FeYw3+MQhs
MA0GCSqGSIb3DQEBAQUABIIBAIjfERZ3DOMZ1evmCYxdvxlaK7YfZupXuqVgevGA8n08sO9x
fEC94Qk7FoKaEnk6grVsJcbcZ7XLJmxspvbXlPAYXah+pX00n2hHbXWQ7oraTeJ5bxgnVpGJ
tsEAE2GgqS9YCzKeoyv9waUMawaoT+YkhrWatXb4+yKAJZQS2BAGNCM7LVwWjiPAz8H0Qd5i
NCEuqFAIQ0npKRH3D42lGTCH6V1j4wKn7yoZFSmC8DfQkCI+HAwszvBCmrBDDrVhiYr4BXHo
5u1QHqQieOkFudZuCtzxgf9YLtOeHpUp7Qo3VJVhyz4jIVDHfDFIDbyveruwBiM12lDbYRWk
TekjnWYAAAAAAAA=
--------------ms090800080805040505010609--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hALIqjkT078782 for <[e-mail]>; Fri, 21 Nov 2003 10:52:45 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hALIqjLN078781 for ietf-pkix-bks; Fri, 21 Nov 2003 10:52:45 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from sigurd.x509.com ([199.175.155.2]) by above.proper.com (8.12.10/8.12.8) with SMTP id hALIqhkT078775 for <[e-mail]>; Fri, 21 Nov 2003 10:52:44 -0800 (PST) (envelope-from [e-mail])
Received: from nebula.x509.com by sigurd.x509.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 21 Nov 2003 18:52:45 UT
Received: from crack.x509.com (localhost [127.0.0.1]) by nebula.x509.com (8.12.10/NULL) with ESMTP id hALImu6L016987 for <[e-mail]>; Fri, 21 Nov 2003 10:48:56 -0800 (PST)
Received: from exvan01.x509.com (exvan01.x509.com [10.9.22.50]) by crack.x509.com (8.12.10/8.12.10) with ESMTP id hALIqiY0026223 for <[e-mail]>; Fri, 21 Nov 2003 10:52:44 -0800 (PST)
Received: from rsasecurity.com (mbranchaud2.eng.x509.com [10.7.33.48]) by exvan01.x509.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id VQFWF6L6; Fri, 21 Nov 2003 11:01:31 -0800
Message-ID: <[e-mail]>
Date: Fri, 21 Nov 2003 10:43:33 -0800
X-Sybari-Trust: dea73b29 64c784fd 0d23202c 00000139
From: Marc Branchaud <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5b) Gecko/20030903
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: OCSPv1 and nonces (RE: draft meeting minutes)
References: <Pine.WNT.4.58.0311191446300.5344@mnystrom-lap>
In-Reply-To: <Pine.WNT.4.58.0311191446300.5344@mnystrom-lap>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070407050708060301040609"
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.

--------------ms070407050708060301040609
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit


It seems to me that we could simply allow clients to make the nonce 
extension critical.

If the client makes nonce critical, it is essentially telling the server 
that it will not accept a nonceless (cached) response.

OTOH, if the client is willing to accept nonceless responses, it simply 
makes the request's nonce extension non-critical.

Responders that don't support nonces (e.g. caching or pre-generating 
responders) have to return an error (internalError?) if the request has 
a critical nonce extension.

This approach doesn't add any new MUSTs or SHOULDs.  It just gives 
clients the ability to ensure that their local policies are followed.

		M.


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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISqTCC
AtcwggJAoAMCAQICEFgUQCxch7Sxp7XFFauIqpwwDQYJKoZIhvcNAQEFBQAwbDEaMBgGA1UE
ChMRUlNBIFNlY3VyaXR5IEluYy4xHjAcBgNVBAMTFVJTQSBQdWJsaWMgUm9vdCBDQSB2MTEu
MCwGCSqGSIb3DQEJARYfcnNha2VvbnJvb3RzaWduQHJzYXNlY3VyaXR5LmNvbTAeFw0wMjA5
MDYxNDEzNTJaFw0wNzA5MDYxNDEzNTJaMIGCMRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5j
LjEVMBMGA1UECxMMS0NBIFNlcnZpY2VzMRYwFAYDVQQDEw1SU0EgQ29ycG9yYXRlMRAwDgYD
VQQHEwdCZWRmb3JkMRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMQswCQYDVQQGEwJVUzCBnzAN
BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAqnOw876lPpMTkSqrqzpEON/609PDLEhmWX4tkC19
AHneDaoetL277GtYYXBCggP2E+s66MN1ccWXyApfWjCZkIHepPC08NVI1JRcbViW3kwLzDD2
w5T9QJcyL5V1pN/LQdxahM56TiLeXlPiJekdmTdJoo+5Pw4bQU+MxTqURk8CAwEAAaNjMGEw
HwYDVR0jBBgwFoAU9UwxelEDPyzXi5eZb6hxkKt4PZswHQYDVR0OBBYEFO2RCGt0t1lKkvah
HSJwJp8KrxaSMA8GA1UdEwQIMAYBAf8CAQMwDgYDVR0PAQH/BAQDAgGGMA0GCSqGSIb3DQEB
BQUAA4GBAHiSe1a79hnPr16PuBwUTBWbuNQ4GJNsyfrCXzAswIT2A2WtGZ1Hp1jEAWi9OfAX
IYAdy52Jyv9N87wAEbLUgVmsFEIlYM5mi6ag7YIRGp8JP5UhLAN9O5YHrR9FsrGK4WmSl3sY
W1qAPOXubFcfhTgUDIYzM30izZBP4nwO07FpMIIC+DCCAmGgAwIBAgIQeuiOriTayCwjwpmR
gmdIUjANBgkqhkiG9w0BAQUFADCBgjEaMBgGA1UEChMRUlNBIFNlY3VyaXR5IEluYy4xFTAT
BgNVBAsTDEtDQSBTZXJ2aWNlczEWMBQGA1UEAxMNUlNBIENvcnBvcmF0ZTEQMA4GA1UEBxMH
QmVkZm9yZDEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMwHhcNMDIwOTIz
MTkxMzAzWhcNMDYwOTIzMTUxMzAzWjCBjDEaMBgGA1UEChMRUlNBIFNlY3VyaXR5IEluYy4x
FTATBgNVBAsTDEtDQSBTZXJ2aWNlczEgMB4GA1UEAxMXUlNBIENsYXNzIDIgUGVyc29uYWwg
Q0ExEDAOBgNVBAcTB0JlZGZvcmQxFjAUBgNVBAgTDU1hc3NhY2h1c2V0dHMxCzAJBgNVBAYT
AlVTMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCkR9yiabyRo6+NwC3Sl8wPuUiBD3rP
sENNjXvzSbTAyXA8pDDndnlAa1nLUhSMgvn8g1sYMd0Bp+C1/mI5PFUZ8jukUK95yt+TK26L
hM/M5RUq/EINdDDdWzg9je498K6oGfyWR6ETSJbIrDe5qQcLCABs9E2gVKb7Z/FwFo3C9QID
AQABo2MwYTAPBgNVHRMECDAGAQH/AgECMA4GA1UdDwEB/wQEAwIBhjAfBgNVHSMEGDAWgBTt
kQhrdLdZSpL2oR0icCafCq8WkjAdBgNVHQ4EFgQUxpPuxqX+41WOz4ojH+6Y3iHyn6cwDQYJ
KoZIhvcNAQEFBQADgYEAcdRHBjq8GfdDoutUTJPtSzQd7XsdsQh2KBbu8utl92VQHuI0J5wc
Rc817G8YbmTtCt/xqAzrr6k7fdaoDBr/kBuVHA5FEJ94foPgrOlbT3zdziMATXh5ESSDLMx6
p8ITIsTJNmwszIG5P9AAKJCW48gu1ZZmLXhFbHcYJGf99pwwggMFMIICbqADAgECAhEAvhyf
0s21hKaAc2Nm1WX4LTANBgkqhkiG9w0BAQUFADCBuzEkMCIGA1UEBxMbVmFsaUNlcnQgVmFs
aWRhdGlvbiBOZXR3b3JrMRcwFQYDVQQKEw5WYWxpQ2VydCwgSW5jLjE1MDMGA1UECxMsVmFs
aUNlcnQgQ2xhc3MgMyBQb2xpY3kgVmFsaWRhdGlvbiBBdXRob3JpdHkxITAfBgNVBAMTGGh0
dHA6Ly93d3cudmFsaWNlcnQuY29tLzEgMB4GCSqGSIb3DQEJARYRaW5mb0B2YWxpY2VydC5j
b20wHhcNMDIwNDMwMTUzMDE5WhcNMTkwNDMwMDkyMTU1WjBsMRowGAYDVQQKExFSU0EgU2Vj
dXJpdHkgSW5jLjEeMBwGA1UEAxMVUlNBIFB1YmxpYyBSb290IENBIHYxMS4wLAYJKoZIhvcN
AQkBFh9yc2FrZW9ucm9vdHNpZ25AcnNhc2VjdXJpdHkuY29tMIGfMA0GCSqGSIb3DQEBAQUA
A4GNADCBiQKBgQC0dSVa2EQ740GxqiIKsHATT4f8XYwUU23pzRe5W6IVpt4jkwDWkgnvTcP6
M8PD4OfK6Imal4hAH/c3K/dUIH7YyQZRGAE5Y27G5klZYKidcFlrfautgVES170MLKFmJqym
2FWAfVOibXatRcw7B0S+mP9404jID/MaIpRXkH5JjwIDAQABo1cwVTAMBgNVHRMEBTADAQH/
MA4GA1UdDwEB/wQEAwIBhjAWBgNVHSAEDzANMAsGCSqGSIb3DQUGATAdBgNVHQ4EFgQU9Uwx
elEDPyzXi5eZb6hxkKt4PZswDQYJKoZIhvcNAQEFBQADgYEAKsviXBc1FeBT2hIwyWuGwnPZ
J9ctjrsO7NbVLjsx/EYclFFGwo+pphiwdUTml9yd7fXzfk0D+7LOs9ZA5xhiHVrGusV4OW4i
7hx2KVILkYlcXCN5tDltKwa5+BkGUuvZdyAoIhpyf61h7uKCFguhaJ+VOiNB4DPtsmxI+KxO
E6YwggTYMIIEQaADAgECAhBgzHl9dAoZGu0JMqXovSgdMA0GCSqGSIb3DQEBBQUAMIGMMRow
GAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEVMBMGA1UECxMMS0NBIFNlcnZpY2VzMSAwHgYD
VQQDExdSU0EgQ2xhc3MgMiBQZXJzb25hbCBDQTEQMA4GA1UEBxMHQmVkZm9yZDEWMBQGA1UE
CBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMwHhcNMDMwNzA3MjMwODEzWhcNMDQwNzA3
MjMwODEzWjCBvjETMBEGCgmSJomT8ixkARkWA2NvbTEbMBkGCgmSJomT8ixkARkWC3JzYXNl
Y3VyaXR5MRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEWMBQGA1UECxMNTm9ydGggQW1l
cmljYTEUMBIGA1UECxMLRW5naW5lZXJpbmcxFzAVBgNVBAMTDk1hcmMgQnJhbmNoYXVkMScw
JQYJKoZIhvcNAQkBFhhtYXJjbmFyY0Byc2FzZWN1cml0eS5jb20wggEiMA0GCSqGSIb3DQEB
AQUAA4IBDwAwggEKAoIBAQDg2xoRr+a/dtnuFG+oTHa+tGtzeObFazNhYV2iSLNED4fHRu86
tknBYFgXggcHW5gsyjfkCtVMzP2tCivmbJgvISo36vsCsmAJH6LRnJf8HsvfmWZaD9tzhDpL
QVsBHr88J0ZMdVniRc7MQoYeu/3hYtUBeGO9bGA6T8vTrnXYonnFtVoTqE62SFqPZZk7HpCS
X1n+dM3zSym2ylMFYE14nukF4I9vAhsQVzk3QNpghmzGj8uoEy9xpf3k0o5+neneAGvcSkwo
r1mH5tSqhrEQaZp7vuSA2bvXaZEnjZzZiTpPDzs1oMpn3guzYhU7wMKz6xvwvgEYyAAV+P5n
FWM/AgMBAAGjggGBMIIBfTCBkgYDVR0gBIGKMIGHMIGEBgkqhkiG9w0FBwIwdzAuBggrBgEF
BQcCARYiaHR0cDovL2NhLnJzYXNlY3VyaXR5LmNvbS9DUFMuaHRtbDBFBggrBgEFBQcCAjA5
MBgWEVJTQSBTZWN1cml0eSBJbmMuMAMCAQEaHUNQUyBJbmNvcnBvcmF0ZWQgYnkgcmVmZXJl
bmNlMCkGA1UdJQQiMCAGCisGAQQBgjcUAgIGCCsGAQUFBwMCBggrBgEFBQcDBDAjBgNVHREE
HDAagRhtYXJjbmFyY0Byc2FzZWN1cml0eS5jb20wDgYDVR0PAQH/BAQDAgeAMEYGA1UdHwQ/
MD0wO6A5oDeGNWh0dHA6Ly9jcmwucnNhc2VjdXJpdHkuY29tOjgwL1JTQUNsYXNzMlBlcnNv
bmFsQ0EuY3JsMB8GA1UdIwQYMBaAFMaT7sal/uNVjs+KIx/umN4h8p+nMB0GA1UdDgQWBBQ1
yQ/UrvKb563LjzHqJzBzrZp/ejANBgkqhkiG9w0BAQUFAAOBgQCV82oGGnglQQzklKg/wKhy
evNeJ6FNBZFhLlmZRNlKgqvPFmBcxygfBGpHqIhsHcrt2/AjhJuzAj7UdW1vTVCY5MkZw8P9
6+J6aTc3bNlGbk0jvcvVgDhmM4xYJLwMZKEw92HlRhfuMnj7ah9DTqbKSewmyAyOc+FLpGfd
lu6CgTCCBOkwggRSoAMCAQICEQDqxAXqre9Mr+FeYw3+MQhsMA0GCSqGSIb3DQEBBQUAMIGM
MRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEVMBMGA1UECxMMS0NBIFNlcnZpY2VzMSAw
HgYDVQQDExdSU0EgQ2xhc3MgMiBQZXJzb25hbCBDQTEQMA4GA1UEBxMHQmVkZm9yZDEWMBQG
A1UECBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMwHhcNMDMwNzA3MjMwODI4WhcNMDQw
NzA3MjMwODEzWjCBwjETMBEGCgmSJomT8ixkARkWA2NvbTEbMBkGCgmSJomT8ixkARkWC3Jz
YXNlY3VyaXR5MRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEWMBQGA1UECxMNTm9ydGgg
QW1lcmljYTEUMBIGA1UECxMLRW5naW5lZXJpbmcxGzAZBgNVBAMTEk1hcmMgQnJhbmNoYXVk
LUVuYzEnMCUGCSqGSIb3DQEJARYYbWFyY25hcmNAcnNhc2VjdXJpdHkuY29tMIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwBjNaHTwtCXpdJg+iDxYMkWjuZIF0ic2fRLymZe+
BnZYWPnik0dFmTulx+V8slsLEtBllcc5o1yfIYfeHPinwRxv86kCUSlgfGGXKjJZaIeURgbo
bUbIfDTPlvRUZuiZvTR4C8tEY88Lle66n62B7wjUvDbiwK4EjzlXOkjpcYXLH7FbaFaRLDBB
PlFD5ydDRhQ67t6fjUeS7p7o/l/VHmPC5LFLXZkjEhjGd5pknbQIAbUGACL5UET85NUFPowD
3F47g0GCKEnuOsk2Ra+WHu7honhIxqmOwGnu85V6tW5xscf4dTofWZONQeaD3gSxv8+hcfKN
k9cwjpnUG2xGzwIDAQABo4IBjTCCAYkwNQYDVR0lBC4wLAYKKwYBBAGCNxQCAgYIKwYBBQUH
AwIGCCsGAQUFBwMEBgorBgEEAYI3CgMEMIGSBgNVHSAEgYowgYcwgYQGCSqGSIb3DQUHAjB3
MC4GCCsGAQUFBwIBFiJodHRwOi8vY2EucnNhc2VjdXJpdHkuY29tL0NQUy5odG1sMEUGCCsG
AQUFBwICMDkwGBYRUlNBIFNlY3VyaXR5IEluYy4wAwIBARodQ1BTIEluY29ycG9yYXRlZCBi
eSByZWZlcmVuY2UwIwYDVR0RBBwwGoEYbWFyY25hcmNAcnNhc2VjdXJpdHkuY29tMEYGA1Ud
HwQ/MD0wO6A5oDeGNWh0dHA6Ly9jcmwucnNhc2VjdXJpdHkuY29tOjgwL1JTQUNsYXNzMlBl
cnNvbmFsQ0EuY3JsMB8GA1UdIwQYMBaAFMaT7sal/uNVjs+KIx/umN4h8p+nMB0GA1UdDgQW
BBT/OiMCyY8CPnNBySW1ijJOYhj7ejAOBgNVHQ8BAf8EBAMCAzgwDQYJKoZIhvcNAQEFBQAD
gYEAlchAObA9eVmeiLu0nTU985Fch6v+EZKodUhZUN7dILgd05HorHN9jxBH6XI4/b9ZVvub
Pkpicdc112YbcLYTD2NumVksyNDI7fDaqiszgk1zluXtZJ+HsCt+GIAKCDfOVLECclpGyizq
VjZFEK4Pt9FxPGTnUJEvIKJcAQ24EvgxggPsMIID6AIBATCBoTCBjDEaMBgGA1UEChMRUlNB
IFNlY3VyaXR5IEluYy4xFTATBgNVBAsTDEtDQSBTZXJ2aWNlczEgMB4GA1UEAxMXUlNBIENs
YXNzIDIgUGVyc29uYWwgQ0ExEDAOBgNVBAcTB0JlZGZvcmQxFjAUBgNVBAgTDU1hc3NhY2h1
c2V0dHMxCzAJBgNVBAYTAlVTAhBgzHl9dAoZGu0JMqXovSgdMAkGBSsOAwIaBQCgggIfMBgG
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMTEyMTE4NDMzM1ow
IwYJKoZIhvcNAQkEMRYEFFZbs094wID4kbOzpaHCGddUYqGbMFIGCSqGSIb3DQEJDzFFMEMw
CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G
CCqGSIb3DQMCAgEoMIGzBgkrBgEEAYI3EAQxgaUwgaIwgYwxGjAYBgNVBAoTEVJTQSBTZWN1
cml0eSBJbmMuMRUwEwYDVQQLEwxLQ0EgU2VydmljZXMxIDAeBgNVBAMTF1JTQSBDbGFzcyAy
IFBlcnNvbmFsIENBMRAwDgYDVQQHEwdCZWRmb3JkMRYwFAYDVQQIEw1NYXNzYWNodXNldHRz
MQswCQYDVQQGEwJVUwIRAOrEBeqt70yv4V5jDf4xCGwwgbUGCyqGSIb3DQEJEAILMYGloIGi
MIGMMRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEVMBMGA1UECxMMS0NBIFNlcnZpY2Vz
MSAwHgYDVQQDExdSU0EgQ2xhc3MgMiBQZXJzb25hbCBDQTEQMA4GA1UEBxMHQmVkZm9yZDEW
MBQGA1UECBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMCEQDqxAXqre9Mr+FeYw3+MQhs
MA0GCSqGSIb3DQEBAQUABIIBANtVipotcJVIUZ6oamDsCJHrcYh6iWuuWfSg9nm+D01bpLph
igxRc6Uzw3j7I5d8/m4rWUilbCkaLMfkiDoxJV6NKpbDOrlz2s8acpVYqCOQlydYcEE294MI
+vB3yVXOJRYtRv1UxZ5z2jCGLKRSxTeDjy8doCFZ5j/ogWBIAd9EEMUN592oUH/+yxZk4asZ
MzON6gYrQHdv0ef6PBiJwkhzqyxPtC7HqFYWM2PeCc3G/YxviSHTXUa/ql6VdfVXYcsjYgNc
wCbmEOwc4U6wz3EGGKH6JUSwmnVXUhq5dCw5IlkHUTNfAZbZETylfCXxRleZPv8J7S/zg5YE
54l0sGAAAAAAAAA=
--------------ms070407050708060301040609--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hALGP5kT071061 for <[e-mail]>; Fri, 21 Nov 2003 08:25:05 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hALGP5ph071060 for ietf-pkix-bks; Fri, 21 Nov 2003 08:25:05 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from the-humungus.corestreet.com ([68.162.232.130]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hALGP3kT071045 for <[e-mail]>; Fri, 21 Nov 2003 08:25:04 -0800 (PST) (envelope-from [e-mail])
Received: from the-humungus.corestreet.com (localhost.localdomain [127.0.0.1]) by the-humungus.corestreet.com (8.12.8/8.12.8) with ESMTP id hALGOx8K004989 for <[e-mail]>; Fri, 21 Nov 2003 11:24:59 -0500
Received: from localhost (dave@localhost) by the-humungus.corestreet.com (8.12.8/8.12.8/Submit) with ESMTP id hALGOwEC004979 for <[e-mail]>; Fri, 21 Nov 2003 11:24:59 -0500
X-Authentication-Warning: the-humungus.corestreet.com: dave owned process doing -bs
Date: Fri, 21 Nov 2003 11:24:31 -0500 (EST)
From: Dave Engberg <[e-mail]>
To: [e-mail]
Subject: Re: OCSPv1 and nonces (RE: draft meeting minutes)
Message-ID: <[e-mail]>
MIME-Version: 1.0
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>

Ok, we can accept that adding new extension declarations to v1 is 
out of scope.

Adding new mandatory rejection requirements (MUST) at the client and 
server based on the non-critical nonce extension does, however, prevent 
any willing v1-compatible clients and servers from choosing other security 
policies (e.g. based on other extensions) before v2.

Could we just change the new language from MUST to SHOULD for the client 
and the server?  This allows you to convey your intended semantics, but  
doesn't prevent the exploration of alternate security policies by willing 
client/server pairs before v2-final ...

Basically:  "Clients who send a nonce to a server and receive a response 
without a nonce SHOULD reject that response.  Servers who receive a 
request with a nonce who are unwilling or unable to supply a response with 
a nonce SHOULD return an 'unauthorized' error code."  (or somesuch)



Michael Myers wrote:
> Earlier today Steve wrote:  "I believe Russ's statement sets the
> parameters for how we clarify this issue within the bounds of
> OCSP v1."  Thus we need to determine, in part and if possible,
> what a v1-based caching server MUST send back to a nonced
> request using only the ASN.1 syntax defined by RFC 2560 as
> written.  Your proposed nonceUnsupported, while a candidate for
> v2 consideration, is clearly not within that v1 scope.




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hALFbgkT068299 for <[e-mail]>; Fri, 21 Nov 2003 07:37:42 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hALFbf9B068297 for ietf-pkix-bks; Fri, 21 Nov 2003 07:37:41 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hALFbdkT068285 for <[e-mail]>; Fri, 21 Nov 2003 07:37:40 -0800 (PST) (envelope-from [e-mail])
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA29934; Fri, 21 Nov 2003 16:44:14 +0100
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id QAA25049; Fri, 21 Nov 2003 16:39:47 +0100
Message-ID: <[e-mail]>
Date: Fri, 21 Nov 2003 16:37:33 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail], [e-mail]
Subject: Re: WG last call re draft-pkix-acpolicies-extn-03.txt
References: <003601c3856d$6c1b6510$[e-mail]>
Content-Type: text/plain; charset=us-ascii; 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>

Jim,

Thank you for your very valuable comments.

A updated document is now available on the server :
http://www.ietf.org/internet-drafts/draft-ietf-pkix-acpolicies-extn-04.txt

You will find hereafter a disposition of your comments.

The document should now be ready for the IESG last call.


Denis
Lead editor of draft-pkix-acpolicies-extn

Note for Russ: two new OIDs will need to be assigned.

=========================================================================

Gentlemen,

No judgement on good or badness of concept however the following present
implementation issues:

1.  Section 2.3 says that this document defines two policies which are
SIMILAR to those for public keys and then appears to use the save value.
Is this intended and if so then the text should be cleaned up.

The text has been fixed in the following way

     The policy qualifiers are similar but indeed different since they
     relate to an Attribute Certificate instead of a Public Key Certificate.
     To this respect two new OIDs will be needed in the id-qt arc and the
     updated document has been using two next one available in that category.

     Russ, as the custodian of the PKIX OID, would you assign these two new
     OIDs to acps and acunotice ?

     id-qt-acps       OBJECT IDENTIFIER ::=  { id-qt 4 }
     id-qt-acunotice  OBJECT IDENTIFIER ::=  { id-qt 5 }

2.  What is the correct behavior if the extension is non-critical, the
extension is recognized, but none of the policy identifiers are recognized?

The following sentence has been added:

"If none of the AC policy identifiers is adequate for the application,
then the AC MUST be rejected."


ASN Module:

1.  Need to uncomment the imports statement.
Done

2.  need to add a semi-colon following the import of PolicyQualifiedId
OK

3.  PolicyQualifiedId needs to be imported form PKIXImplicit88.
It is defined both in PKIXExplicit88 and in PKIXImplicit88.

4.  id-pkix needs to be imported.
id-pe is now directly imported instead.

5.  ac-policies does needs to have "SYNTAX" and "IDENTIFIED BY" changed
as this is not correct 1988 syntax.
Done

6.  EXTENSION is not an identified type.
Done

7.  ac-policiesSyntax should start with an upper case letter as it is a type.
Done

8.  acPolicyId should start with an upper case letter as it is a type.
Done

   ... and many thanks for these comments.

In addition:

1 - The introduction has been changed to state:

The purpose of this document is to define an AC policies extension
able to explicitly state the AC policies that apply to a given AC,
but not the AC policies themselves"

2 - id-pe-ac-policies has been changed into id-pe-acPolicies

3 - The name of the ASN.1 module is now :
AcPolicies instead of PKIXac-policies

Jim


 > Gentlemen,
 >
 > No judgement on good or badness of concept however the following present
 > implementation issues:
 >
 > 1.  Section 2.3 says that this document defines two policies which are
 > SIMILAR to those for public keys and then appears to use the save value.
 > Is this intended and if so then the text should be cleaned up.
 >
 > 2.  What is the correct behavior if the extension is non-criticial, the
 > extension is recognized, but none of the policy identifiers are
 > recognized?
 >
 >
 >
 > ASN Module:
 >
 > 1.  Need to uncomment the imports statement
 >
 > 2.  need to add a semi-colon following the import of PolicyQualifiedId
 >
 > 3.  PolicyQualifiedId needs to be imported form PKIXImplicit88.
 >
 > 4.  id-pkix needs to be imported.
 >
 > 5.  ac-policies does needs to have "SYNTAX" and "IDENTIFIED BY" changed
 > as this is not correct 1988 syntax.
 >
 > 6.  EXTENSION is not an identified type.
 >
 > 7.  ac-policiesSyntax should start with an upper case letter as it is a
 > type.
 >
 > 8.  acPolicyId should start with an upper case letter as it is a type.
 >
 >
 > Jim






Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hALBFrkT056770 for <[e-mail]>; Fri, 21 Nov 2003 03:15:53 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hALBFrWY056769 for ietf-pkix-bks; Fri, 21 Nov 2003 03:15:53 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from www16.your-server.de (IDENT:[e-mail] [213.133.104.16]) by above.proper.com (8.12.10/8.12.8) with SMTP id hALBFpkT056764 for <[e-mail]>; Fri, 21 Nov 2003 03:15:51 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 18729 invoked by uid 1649); 21 Nov 2003 11:15:50 -0000
Date: 21 Nov 2003 11:15:50 -0000
Message-ID: <[e-mail]>
From: "Florian Oelmaier" <[e-mail]>
To: [e-mail]
Subject: RE: OCSPv1 and nonces (RE: draft meeting minutes)
References: 
In-Reply-To: 
X-Mailer: oMail 0.98.2 - http://webmail.omnis.ch
X-IPAddress: 195.212.95.34
X-Sender: [e-mail]
MIME-Version: 1.0
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>

> I'm not surprised at your result.  Server-unilateral nonces are
> arguably consistent with standing 2560 syntax. However, this
> practice is not identified in the standard.  

/agree. Please note that if you dont like that, you have to clarfiy that, too! But as I stated in a former message, I would prefer an explicit extension as proposed by David or Tom.

But my comment regarding extensions was not targeted towards server-generated nonces. While OpenValidation.org uses server-generated nonces, most (98%+) requests we get contain nonces. Please mind: this does not mean that the client would not accept a non-nonced answer, as most clients out there do not know if openvalidation.org does caching or not. 

In my comment I was speaking about another extension (a private extension used by OpenValidation.org to deliver additional information to the clients). This is ongoing work, the idea is to deliver additional background information about the CA that can be presented to the user.

In the end I just wanted to stress the fact that adding a new responseExtension in a separate RfC does not necessarily mean we need to increment the OCSP-version number. But I think we all agree on that.

> More importantly,
> is it not responsive to client-driven prevention of replay
> attacks.

I think it is. As the responder never signs a response without nonce, it is semantically the same as a "NonceSupported=true" Extension. This method  reliably protects clients sending "nonced" requests but accepting "non-nonced" responses.

But either way: as stated above, I would prefer the proposal of Tom or David.  So no need to discuss the server-generated nonce proposal any further - at least not from my side.

> As to the likelihood of clarifying 2560 as it goes from Proposed
> to Draft with the guidance provided us by our Area Director, see
> RFC 2026.  The "MUST reject" clarification is amply supported by
> the breakage poll.
> 
> If you disagree with Russ's guidance, take it up with Steve or
> Russ.

I think both follow the discussion here. I am here to give my point of view - at the end of the day it is not my decision what to put into the standard. And as for the poll I agree with several others here that if you would ask now, clearly worded and with all implications on the table, the result may be different. 

If the proposed change really goes through I will add an option to my client where the users can decide between three settings:

#1 standard compliance with normal security (works with all responders)

[Technically: will use requests without nonce ]

#2 standard compliance with high security (does not work with all responders)

[Technically: will use requests with nonce and will not accept responses without nonce]

#3 high security with some responders/normal security with most (works with all responders and improves security with some. While technically 100% compatible this is not compliant to the RfC!)

[Technically: will use requests with nonce but will accept responses without nonce. This is the former default behaviour of my client but as it will not be standard compliant anymore, I will warn the user explicitly that he leaves the holy ground with that decision. 
Additionally I have to introduce a second round-trip without nonce if I get an error message (as I may have got this error message due to missing nonce support by a caching responder). But I think most caching responders will include an "old version compatibility" mode and simply send back a non-nonced response to a nonced request. This is arguably consistent even with the changed RfC as extension processing is optional.]


I hope this clarifies why I am so unhappy with the outlined "decision". But I have not yet given up hope that I can change #3 to something like Toms extension proposal (NonceSupported):

#3 high security with new responders (normal security for all older responders, high security for all responders compliant to RfCxxxx)

[Technically: requests with nonce, will accept responses without nonce but will NOT accept responses without nonce if NonceSupported=True extension is set]

or Davids proposal (NonceUnsupported):
 
#3 high security with fallback (works with all responders except older caching responders)

[Technically: requests with nonce, will accept responses without nonce only if NonceUnsupported extension is present]

While also solving the problem, both alternatives are technically superior, easier to understand and more straightforward to implement. But this has been laid out several times now, maybe its time to let the matter rest here  and see what the market will do. 

-- 
Florian Oelmaier
SyTrust



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAKKQxkT051220 for <[e-mail]>; Thu, 20 Nov 2003 12:26:59 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAKKQxO8051219 for ietf-pkix-bks; Thu, 20 Nov 2003 12:26:59 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAKKQwkT051214 for <[e-mail]>; Thu, 20 Nov 2003 12:26:58 -0800 (PST) (envelope-from [e-mail])
Received: from MMyersLapTop ([65.39.77.99]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id hAKKQxA82415 for <[e-mail]>; Thu, 20 Nov 2003 13:26:59 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: <[e-mail]>
Subject: RE: OCSPv1 and nonces (RE: draft meeting minutes)
Date: Thu, 20 Nov 2003 12:29:40 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <[e-mail]>
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>

Florian,

I'm not surprised at your result.  Server-unilateral nonces are
arguably consistent with standing 2560 syntax. However, this
practice is not identified in the standard.  More importantly,
is it not responsive to client-driven prevention of replay
attacks.

As to the likelihood of clarifying 2560 as it goes from Proposed
to Draft with the guidance provided us by our Area Director, see
RFC 2026.  The "MUST reject" clarification is amply supported by
the breakage poll.

If you disagree with Russ's guidance, take it up with Steve or
Russ.

Mike




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAKIKakT045775 for <[e-mail]>; Thu, 20 Nov 2003 10:20:36 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAKIKah6045774 for ietf-pkix-bks; Thu, 20 Nov 2003 10:20:36 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from www16.your-server.de (IDENT:[e-mail] [213.133.104.16]) by above.proper.com (8.12.10/8.12.8) with SMTP id hAKIKYkT045765 for <[e-mail]>; Thu, 20 Nov 2003 10:20:35 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 7175 invoked by uid 1649); 20 Nov 2003 18:20:30 -0000
Date: 20 Nov 2003 18:20:30 -0000
Message-ID: <[e-mail]>
From: "Florian Oelmaier" <[e-mail]>
To: [e-mail]
Subject: RE: OCSPv1 and nonces (RE: draft meeting minutes)
References:   <>
In-Reply-To:  <>
X-Mailer: oMail 0.98.2 - http://webmail.omnis.ch
X-IPAddress: 195.212.95.34
X-Sender: [e-mail]
MIME-Version: 1.0
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>

> The version number will be updated since legacy clients that are
> merrily going along parsing against v == 0 will very likely
> choke when they see bits on the wire they weren't expecting.

Seeing that the alternative proposal is a "responseExtension", clients will NOT choke. OpenValidation.org adds such an extension to every OCSP-Response for more than 6 months now. During this time we had thousands of requests sent by more than 45 clients (http://www.openvalidation.org/en/kontakt/ocsp_stats.html#browrep). 

The extenstion system in OCSP works and is fully compatible. No client will "choke". 

If you push the MUST reject "solution" through, I expect it to be the other way round: you may change the spec, but a lot of clients and servers will simply not adhere to it, as it is not compatible to some use-cases out there.

> Meanwhile, 2560 is going from Proposed to Draft.  We are allowed
> to and already have performed minor amendments.  The "MUST
> reject" clarification will be another.

Seeing the text size it will be a "minor" amendment, seeing the implications it is a HUGE change.

As this will change the specification very significantly, I wonder if the IESG will recommend that the revision be treated as a new document, reentering the standards track at the beginning.

-- 
Florian Oelmaier
SyTrust



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAKFBXkT035353 for <[e-mail]>; Thu, 20 Nov 2003 07:11:33 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAKFBXvl035352 for ietf-pkix-bks; Thu, 20 Nov 2003 07:11:33 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAKFBVkT035347 for <[e-mail]>; Thu, 20 Nov 2003 07:11:31 -0800 (PST) (envelope-from [e-mail])
Received: from MMyersLapTop ([65.39.77.99]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id hAKFBWA58363 for <[e-mail]>; Thu, 20 Nov 2003 08:11:32 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: <[e-mail]>
Subject: RE: OCSPv1 and nonces (RE: draft meeting minutes)
Date: Thu, 20 Nov 2003 07:14:14 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <[e-mail]>
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>

The version number will be updated since legacy clients that are
merrily going along parsing against v == 0 will very likely
choke when they see bits on the wire they weren't expecting.
One hopes today's clients will are today sufficiently robust in
their implementation, e.g.:

if( buf->v == 0 ) proceed( buf ) else fail( BADVERSION );

such that, upon receipt of a value for v other than 0 (i.e. v1),
they will fail( ) with grace rather than proceed( ) in good
faith and choke.

Given a version number roll, we would be remiss if we didn't
also take the time to consider other v2 issues unrelated to the
use of nonces.  This is all going to take some time.

Further, we're nowhere near ready to recommend to Steve and Tim
a technical resolution.  We haven't fully discussed all possible
options.  Among these is the option of including some type of
value in a responder's certificate that enables a priori client
side nonce capability discovery.

Meanwhile, 2560 is going from Proposed to Draft.  We are allowed
to and already have performed minor amendments.  The "MUST
reject" clarification will be another.

Mike


> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Terry Hayes
> Sent: Wednesday, November 19, 2003 5:04 PM
> To: [e-mail]
> Cc: [e-mail]
> Subject: RE: OCSPv1 and nonces (RE: draft meeting minutes)
>
>
>
> Florian Oelmaier wrote on 11/19/2003, 4:29 PM:
> >
> > MY OPINION is to leave OCSPv1 as it is and draft an
> additional RfC
> > providing the extensions needed. Eventually we
> should add a short link
> > pointing to this OCSP-extension-RfC into RfC2560.
> >
>
> I also believe that this is the correct approach.
> Notice that the new extension(s)
> most likely will work in the OCSP v1 framework.
> There is no need to change
> OCSP to v2, or wait for a OCSP v2 to define this extension.
>
> Terry Hayes
>
>




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAK31EkT027492 for <[e-mail]>; Wed, 19 Nov 2003 19:01:14 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAK31EPT027491 for ietf-pkix-bks; Wed, 19 Nov 2003 19:01:14 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.cs.auckland.ac.nz (csmail.cs.auckland.ac.nz [130.216.33.150]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAK31BkT027484 for <[e-mail]>; Wed, 19 Nov 2003 19:01:13 -0800 (PST) (envelope-from [e-mail])
Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id 0A0E263C19 for <[e-mail]>; Thu, 20 Nov 2003 16:01:13 +1300 (NZDT)
Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id hAK32VG17099 for [e-mail]; Thu, 20 Nov 2003 16:02:31 +1300
Date: Thu, 20 Nov 2003 16:02:31 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Duplicates
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>

Am I the onky one getting two copies of most messages posted to the list?

Peter.

Am I the onky one getting two copies of most messages posted to the list?

Peter.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAK14GkT021409 for <[e-mail]>; Wed, 19 Nov 2003 17:04:16 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAK14Grg021406 for ietf-pkix-bks; Wed, 19 Nov 2003 17:04:16 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from imo-r06.mx.aol.com (imo-r06.mx.aol.com [152.163.225.102]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAK14EkT021375 for <[e-mail]>; Wed, 19 Nov 2003 17:04:14 -0800 (PST) (envelope-from [e-mail])
Received: from [e-mail] by imo-r06.mx.aol.com (mail_out_v36_r1.1.) id 2.188.21be3597 (16086); Wed, 19 Nov 2003 20:03:36 -0500 (EST)
Received: from  pc655301.nscp.aoltw.net (h-10-169-25-91.nscp.aoltw.net [10.169.25.91]) by air-id10.mx.aol.com (v97.8) with ESMTP id MAILINID103-3ed63fbc12e626b; Wed, 19 Nov 2003 20:03:35 -0500
Date: Wed, 19 Nov 2003 17:03:32 -0800
From: "Terry Hayes" <[e-mail]>
Subject: RE: OCSPv1 and nonces (RE: draft meeting minutes)
To: [e-mail]
cc: [e-mail]
In-Reply-To: <000501c3aefd$61540100$4228a8c0@hagen>
Message-ID: <[e-mail]>
References: <000501c3aefd$61540100$4228a8c0@hagen>
X-Mailer: AOL Communicator (20031113.4 Win)
Organization: AOL
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=us-ascii
X-AOL-IP: 10.169.25.91
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>

Florian Oelmaier wrote on 11/19/2003, 4:29 PM:
> 
> MY OPINION is to leave OCSPv1 as it is and draft an additional RfC 
> providing the extensions needed. Eventually we should add a short link 
> pointing to this OCSP-extension-RfC into RfC2560. 
> 

I also believe that this is the correct approach.  Notice that the new extension(s)
most likely will work in the OCSP v1 framework.  There is no need to change
OCSP to v2, or wait for a OCSP v2 to define this extension.

Terry Hayes


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAK116kT021019 for <[e-mail]>; Wed, 19 Nov 2003 17:01:06 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAK116MR021018 for ietf-pkix-bks; Wed, 19 Nov 2003 17:01:06 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from imo-m07.mx.aol.com (imo-m07.mx.aol.com [64.12.136.162]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAK114kT020998 for <[e-mail]>; Wed, 19 Nov 2003 17:01:05 -0800 (PST) (envelope-from [e-mail])
Received: from [e-mail] by imo-m07.mx.aol.com (mail_out_v36_r1.1.) id 7.1f0.13b7f21d (16112) for <[e-mail]>; Wed, 19 Nov 2003 20:00:54 -0500 (EST)
Received: from  pc655301.nscp.aoltw.net (h-10-169-25-91.nscp.aoltw.net [10.169.25.91]) by air-id12.mx.aol.com (v97.8) with ESMTP id MAILINID124-3ef03fbc12459d; Wed, 19 Nov 2003 20:00:54 -0500
Date: Wed, 19 Nov 2003 17:00:51 -0800
From: "Terry Hayes" <[e-mail]>
Subject: RE: OCSPv1 and nonces (RE: draft meeting minutes)
To: [e-mail]
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]>
X-Mailer: AOL Communicator (20031113.4 Win)
Organization: AOL
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=us-ascii
X-AOL-IP: 10.169.25.91
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 prefer option 2.

A server that receives a request that includes an extension that it does not support should respond as
if that extension was not present in the request.  This is allowed by the processing rules for extensions.

A server that does not support the nonce extension should respond as if it was missing.  It should
send back a non-nonced response.

This position is not in conflict with the "client MUST reject" consensus.  It does conflict with the "MUST
incorporate" woding that has been proposed.  However I do not believe that there is any consensus on 
that part of the proposal.

Terry Hayes

Michael Myers wrote on 11/19/2003, 12:21 PM:
> 
> Terry, 
> 
> My comments embedded below largely revolve around what in your 
> opinion a *v1* caching server MUST send back in the event it 
> receives a nonced request but by system design is unable to 
> incorporate that nonce in a response. 
> 
> There are four options for v1: 
> 
> 1. Go silent and send back nothing; 
> 
> 2. Send back a non-nonced response anyway; 
> 
> 3. Signal back anything other than a definitive 
>    "good" or "revoked",  where "anything other" 
>    must be selected from 2560 as it is written; 
> 
> 4. Or the IETF and this WG does nothing and lets 
>    the market decide. 
> 
> Which of these v1 options do you prefer?  Extensions will lead 
> us to v2 and thus are excluded from the solution space. 
> 
> I will tell you my opinion: 
> 
> #1 opens the door to a needless sequence of retries 
>    that will lead PKI-using communities to further 
>    complain that PKI doesn't work. 
> 
> #2 is in direct conflict with the "MUST reject" 
>    consensus.  It flies in the face of the sound 
>    security principles ratified by the initial 
>    poll and as reiterated by our Area Director in 
>    his guidance to the WG. 
> 
> #3 could work if we could only agree on what 
>    that signal is with respect to running code. 
> 
> #4 is only included for completeness, else why are 
>    we even bothering to debate the issue. 
> 
> Mike 
> 
> 
> 
> 
> > -----Original Message----- 
> > From: Terry Hayes [mailto:[e-mail]] 
> > Sent: Wednesday, November 19, 2003 10:43 AM 
> > To: [e-mail] 
> > Cc: [e-mail] 
> > Subject: RE: OCSPv1 and nonces (RE: draft meeting minutes) 
> > 
> > 
> > I also diagree with the "decision" recorded in the 
> > minutes of the WG meeting. 
> 
> We didn't decide so much as confirm the rough consensus of the 
> initial poll.  Clients MUST reject. 
> 
> > 
> > The OCSP RFC clearly states that extensions are 
> > optional, and need not be processed by either the 
> > client or the responder.  This proposal makes a 
> > significant change in the standard by requiring 
> > special-case processing for the nonce extension. 
> > This will cause existing implementations of 
> > responders to be non-conformant. 
> 
> The minutes do not propose an extension.  All is says is that 
> clients MUST reject. 
> 
> > I do not believe that the current RFC is broken in 
> > any way. 
> 
> Agree, it's not broken.  But it could use a little clarification 
> in this one area. 
> 
> > It provides a method for a client to 
> > request a fresh OCSP response, and a method for 
> > checking that an appropriate response was generated. 
> > This is the goal of this portion of the RFC, and it 
> > is satisfied by the existing extension and the 
> > existing processing requirements for extensions.  I 
> > agree that additional text that describes the 
> > processing by the client would make this clearer, but 
> > it seems to have been correctly interpreted by anyone 
> > hat has implemented a client based on the current wording. 
> 
> Strongly agree with your last point. 
> 
> > The current discussion seems to be motivated by an 
> > additional requirement that was not addressed in the 
> > original RFC.  This new requirement is to allow a 
> > client to accept a response that does not included a 
> > matching nonce, if the client can determine that the 
> > responder never includes nonces (such as a caching 
> > server). 
> 
> Yes, this is a new requirement, but perhaps better worded as 
> "nonce capability discovery". 
> 
> > There was an extension proposed on the list 
> > that would allow this requirment to be satisfied. 
> > This new extension would be compatible with the 
> > current wording for extension processing in the OCSP 
> > RFC, and could be defined within the current OCSP v1 
> > framework. 
> 
> Many ideas have been proposed and I'm sure we'll consider them 
> all in due course against a possible v2. Meanwhile there remains 
> this unresolved issue about what a v1 caching server MUST send 
> back to a nonced request. 
> 
> 
> > I think the concensus of the list was to leave the 
> > current RFC intact, and to work on defining an 
> > additional extension to handle the new requirement. 
> 
> All this discussion clearly indicates a need to at least clarify 
> the intended semantics of the nonce extension and a strong 
> consensus via the {MUST reject, MUST incoporate} poll as to what 
> that clarification should say. 
> 
> > 
> > Terry Hayes 


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAK0U2kT019446 for <[e-mail]>; Wed, 19 Nov 2003 16:30:02 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAK0U2UA019445 for ietf-pkix-bks; Wed, 19 Nov 2003 16:30:02 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout07.sul.t-online.com (mailout07.sul.t-online.com [194.25.134.83]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAK0TwkT019434 for <[e-mail]>; Wed, 19 Nov 2003 16:30:01 -0800 (PST) (envelope-from [e-mail])
Received: from fwd08.aul.t-online.de  by mailout07.sul.t-online.com with smtp  id 1AMchk-0003RJ-00; Thu, 20 Nov 2003 01:29:52 +0100
Received: from hagen (TlzuQMZOgea7eAwKr2apKFb3PJYoJUgfwHdYXKgHs4cZDtmZFVNAwz@[80.128.79.199]) by fmrl08.sul.t-online.com with esmtp id 1AMchV-16fpHU0; Thu, 20 Nov 2003 01:29:37 +0100
From: "Florian Oelmaier" <[e-mail]>
To: <[e-mail]>
Subject: RE: OCSPv1 and nonces (RE: draft meeting minutes)
Date: Thu, 20 Nov 2003 01:29:36 +0100
Organization: SyTrust
Message-ID: <000501c3aefd$61540100$4228a8c0@hagen>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Seen: false
X-ID: [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>

Hello all,

you all know my position regarding this issue: I agree with Terry Hayes,
Miguel Rodriguez, James Manger, Magnus Nystrom, Ryan M.Hurst and all the
others argumenting along that line in the discussion a few weeks ago. 

I strongly believe that the first poll on this issue does not help us in
deciding this issue (as stated by Miguel).

THE PROBLEM is that some clients want to support both types of
responders: caching responders (or better cached responses) and "live"
responders without knowing what type of responder they are talking to
beforehand. To allow for a client-policy driven decision regarding
trustworthiness while simultaneous maintaining technical
interoperability these clients want to get nonces where possible but
will accept nonce-less responses, too (if the local policy is met:
timeout for freshness, confirmation of a warning dialog by the user,
etc.). 

THE STATUS QUO is that the clients described above can be tricked by an
attacker to accept replies without nonces from a responder that would
support nonces. This problem is not intrinsic to the system but could be
solved using the protocol. At least one solution (see 4) is already
applied in the market.

THE SOLUTIONS. After a lot of discussion on this list, we have a set of
proposed solutions. In my eyes, all of these solutions would solve the
problem described above. Allow me to try and summarize the options
presented:

1) Proposal of Russ Housely et al at IETF Meeting:
Clients MUST reject replies without nonces to requests with nonces.
Servers MUST reply with an error to requests with nonce if they are not
able to generate nonces.

2) Proposal of Tom Gindin
(http://www.imc.org/ietf-pkix/mail-archive/msg07000.html): 
All responders (especially those supporting nonces) should add a boolean
NonceSupported extension 

3) Proposal of David Engberg
(http://www.imc.org/ietf-pkix/mail-archive/msg06838.html): 
All responders not supporting nonces should add a NonceUnsupported
extension

4) Proposal of Florian Oelmaier
(http://www.imc.org/ietf-pkix/mail-archive/msg06766.html): 
All responders supporting nonces should add a server generated nonces to
the response if there is no nonce in the request


IN MY OPINION solution 1 is neither rough consesus in the WG nor based
on running code. With proposal 1 clients will loose a lot of
configuration flexibility and within some the default configuration will
break. With proposal 1 servers will loose a lot of configuration
flexibility and some installations will break. With proposal 1 the RfC
contradicts itself regarding OPTIONAL extension handling at the server. 
All other options are perfectly acceptable from my point of view. I like
the idea of adding an extension (proposal 2 or 3) as it is clearly
defined, easily understandable and due to the extension system
completely in line with all running code and with the wording of the
RfC.

MY OPINION is to leave OCSPv1 as it is and draft an additional RfC
providing the extensions needed. Eventually we should add a short link
pointing to this OCSP-extension-RfC into RfC2560.

-- 
Florian Oelmaier
SyTrust

PS: ADDITIONALLY within the discussion a second idea was floating
around: Upon receiving a request with nonce, a "caching" responder
eventually wants to forward the request to a "live" responder in the
background. To decide this, the responder would like to know if the
client would accept a response without nonce or not. While this is not a
security issue, it may be important in some environments. Seeing the
discussion above, this could be solved simultaneous. There are also some
proposals to solve this problem: 
- critical flag for nonces in the request
- WillAcceptNoncelessResponse extension
- WillNotAcceptNoncelessResponse extension 




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAJM76kT014346 for <[e-mail]>; Wed, 19 Nov 2003 14:07:06 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAJM75Dk014345 for ietf-pkix-bks; Wed, 19 Nov 2003 14:07:05 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAJM74kT014340 for <[e-mail]>; Wed, 19 Nov 2003 14:07:04 -0800 (PST) (envelope-from [e-mail])
Received: from MMyersLapTop ([65.39.77.99]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id hAJM73A08742; Wed, 19 Nov 2003 15:07:03 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: "David Engberg" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: OCSPv1 and nonces (RE: draft meeting minutes)
Date: Wed, 19 Nov 2003 14:09:41 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
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: David Engberg [mailto:[e-mail]]
> Sent: Wednesday, November 19, 2003 12:57 PM
>
> My preference would be a slight variant on Mike's #2:
> send back a  non-nonced response with a response
> extension indicating "nonceUnsupported".
>
> I think Mike's analysis for #2 is incomplete.  The
> original concensus was around the current behavior
> of clients in absence of this extension.

Dave,

Earlier today Steve wrote:  "I believe Russ's statement sets the
parameters for how we clarify this issue within the bounds of
OCSP v1."  Thus we need to determine, in part and if possible,
what a v1-based caching server MUST send back to a nonced
request using only the ASN.1 syntax defined by RFC 2560 as
written.  Your proposed nonceUnsupported, while a candidate for
v2 consideration, is clearly not within that v1 scope.

In v2, should it come to pass, we will no doubt entertain
ourselves to the point of exhaustion with all the proposals
currently on the table.  But in a v1 only context, we have four
options for an IETF standard governing OCSP caching server
action in the presence of a nonced request:  1) sever goes
silent; 2)ignore the nonce and send a non-nonced response
anyway; 3)send anything other than "good" or "revoked" as
selected from 2560's existing syntax; or 4) the WG does nothing
and lets the market sort it out.

v1 only, no new extensions.  How MUST a v1 caching server
respond to a nonced request?  Given the constrained solution
space, I prefer #3 using a non-nonced yet signed response value
of "unknown".

Mike









Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAJKRNkT010388 for <[e-mail]>; Wed, 19 Nov 2003 12:27:23 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAJKRNuv010387 for ietf-pkix-bks; Wed, 19 Nov 2003 12:27:23 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAJKRIkT010377 for <[e-mail]>; Wed, 19 Nov 2003 12:27:22 -0800 (PST) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09652; Wed, 19 Nov 2003 15:27:06 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-acpolicies-extn-04.txt
Date: Wed, 19 Nov 2003 15:27:05 -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		: Attribute Certificate Policies extension
	Author(s)	: C. Francis, D. Pinkas
	Filename	: draft-ietf-pkix-acpolicies-extn-04.txt
	Pages		: 8
	Date		: 2003-11-19
	
This document describes one certificate extension to explicitly 
state the Attribute Certificate (AC) policies that apply to a given 
Attribute Certificate.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-acpolicies-extn-04.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-acpolicies-extn-04.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-acpolicies-extn-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-acpolicies-extn-04.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 [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAJKIkkT010071 for <[e-mail]>; Wed, 19 Nov 2003 12:18:46 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAJKIk76010070 for ietf-pkix-bks; Wed, 19 Nov 2003 12:18:46 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAJKIjkT010064 for <[e-mail]>; Wed, 19 Nov 2003 12:18:45 -0800 (PST) (envelope-from [e-mail])
Received: from MMyersLapTop ([65.39.77.99]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id hAJKIkA01443 for <[e-mail]>; Wed, 19 Nov 2003 13:18:46 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: <[e-mail]>
Subject: RE: OCSPv1 and nonces (RE: draft meeting minutes)
Date: Wed, 19 Nov 2003 12:21:24 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
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>

Terry,

My comments embedded below largely revolve around what in your
opinion a *v1* caching server MUST send back in the event it
receives a nonced request but by system design is unable to
incorporate that nonce in a response.

There are four options for v1:

1. Go silent and send back nothing;

2. Send back a non-nonced response anyway;

3. Signal back anything other than a definitive
   "good" or "revoked",  where "anything other"
   must be selected from 2560 as it is written;

4. Or the IETF and this WG does nothing and lets
   the market decide.

Which of these v1 options do you prefer?  Extensions will lead
us to v2 and thus are excluded from the solution space.

I will tell you my opinion:

#1 opens the door to a needless sequence of retries
   that will lead PKI-using communities to further
   complain that PKI doesn't work.

#2 is in direct conflict with the "MUST reject"
   consensus.  It flies in the face of the sound
   security principles ratified by the initial
   poll and as reiterated by our Area Director in
   his guidance to the WG.

#3 could work if we could only agree on what
   that signal is with respect to running code.

#4 is only included for completeness, else why are
   we even bothering to debate the issue.

Mike




> -----Original Message-----
> From: Terry Hayes [mailto:[e-mail]]
> Sent: Wednesday, November 19, 2003 10:43 AM
> To: [e-mail]
> Cc: [e-mail]
> Subject: RE: OCSPv1 and nonces (RE: draft meeting minutes)
>
>
> I also diagree with the "decision" recorded in the
> minutes of the WG meeting.

We didn't decide so much as confirm the rough consensus of the
initial poll.  Clients MUST reject.

>
> The OCSP RFC clearly states that extensions are
> optional, and need not be processed by either the
> client or the responder.  This proposal makes a
> significant change in the standard by requiring
> special-case processing for the nonce extension.
> This will cause existing implementations of
> responders to be non-conformant.

The minutes do not propose an extension.  All is says is that
clients MUST reject.

> I do not believe that the current RFC is broken in
> any way.

Agree, it's not broken.  But it could use a little clarification
in this one area.

> It provides a method for a client to
> request a fresh OCSP response, and a method for
> checking that an appropriate response was generated.
> This is the goal of this portion of the RFC, and it
> is satisfied by the existing extension and the
> existing processing requirements for extensions.  I
> agree that additional text that describes the
> processing by the client would make this clearer, but
> it seems to have been correctly interpreted by anyone
> hat has implemented a client based on the current wording.

Strongly agree with your last point.

> The current discussion seems to be motivated by an
> additional requirement that was not addressed in the
> original RFC.  This new requirement is to allow a
> client to accept a response that does not included a
> matching nonce, if the client can determine that the
> responder never includes nonces (such as a caching
> server).

Yes, this is a new requirement, but perhaps better worded as
"nonce capability discovery".

> There was an extension proposed on the list
> that would allow this requirment to be satisfied.
> This new extension would be compatible with the
> current wording for extension processing in the OCSP
> RFC, and could be defined within the current OCSP v1
> framework.

Many ideas have been proposed and I'm sure we'll consider them
all in due course against a possible v2. Meanwhile there remains
this unresolved issue about what a v1 caching server MUST send
back to a nonced request.


> I think the concensus of the list was to leave the
> current RFC intact, and to work on defining an
> additional extension to handle the new requirement.

All this discussion clearly indicates a need to at least clarify
the intended semantics of the nonce extension and a strong
consensus via the {MUST reject, MUST incoporate} poll as to what
that clarification should say.

>
> Terry Hayes




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAJIh4kT006534 for <[e-mail]>; Wed, 19 Nov 2003 10:43:04 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAJIh4A9006533 for ietf-pkix-bks; Wed, 19 Nov 2003 10:43:04 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from imo-r02.mx.aol.com (imo-r02.mx.aol.com [152.163.225.98]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAJIh2kT006525 for <[e-mail]>; Wed, 19 Nov 2003 10:43:02 -0800 (PST) (envelope-from [e-mail])
Received: from [e-mail] by imo-r02.mx.aol.com (mail_out_v36_r1.1.) id 6.18.384df85b (16112); Wed, 19 Nov 2003 13:42:45 -0500 (EST)
Received: from  pc655301.nscp.aoltw.net (h-10-169-25-91.nscp.aoltw.net [10.169.25.91]) by air-id12.mx.aol.com (v97.8) with ESMTP id MAILINID124-3ef03fbbb9a4140; Wed, 19 Nov 2003 13:42:45 -0500
Date: Wed, 19 Nov 2003 10:42:40 -0800
From: "Terry Hayes" <[e-mail]>
Subject: RE: OCSPv1 and nonces (RE: draft meeting minutes)
To: [e-mail]
cc: [e-mail]
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]>
X-Mailer: AOL Communicator (20031113.4 Win)
Organization: AOL
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=us-ascii
X-AOL-IP: 10.169.25.91
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 also diagree with the "decision" recorded in the minutes of the WG meeting.

The OCSP RFC clearly states that extensions are optional, and need not be processed by either the client or the responder.  This proposal makes a significant change in the standard by requiring special-case processing for the nonce extension.  This will cause existing implementations of responders to be non-conformant.

I do not believe that the current RFC is broken in any way.  It provides a method for a client to request a fresh OCSP response, and a method for checking that an appropriate response was generated.  This is the goal of this portion of the RFC, and it is satisfied by the existing extension and the existing processing requirements for extensions.  I agree that additional text that describes the processing by the client would make this clearer, but it seems to have been correctly interpreted by anyone that has implemented a client based on the current wording.

The current discussion seems to be motivated by an additional requirement that was not addressed in the original RFC.  This new requirement is to allow a client to accept a response that does not included a matching nonce, if the client can determine that the responder never includes nonces (such as a caching server).  There was an extension proposed on the list that would allow this requirment to be satisfied.  This new extension would be compatible with the current wording for extension processing in the OCSP RFC, and could be defined within the current OCSP v1 framework.

I think the concensus of the list was to leave the current RFC intact, and to work on defining an additional extension to handle the new requirement.

Terry Hayes

> 
> The core question is, how does the responder signal failure in a 
> way that enables closure of the protocol? 


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAJGQIkT098847 for <[e-mail]>; Wed, 19 Nov 2003 08:26:18 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAJGQH7k098846 for ietf-pkix-bks; Wed, 19 Nov 2003 08:26:17 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAJGQGkT098841 for <[e-mail]>; Wed, 19 Nov 2003 08:26:16 -0800 (PST) (envelope-from [e-mail])
Received: from MMyersLapTop ([65.39.77.99]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id hAJGQHA68242 for <[e-mail]>; Wed, 19 Nov 2003 09:26:17 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: <[e-mail]>
Subject: RE: OCSPv1 and nonces  (RE: draft meeting minutes)
Date: Wed, 19 Nov 2003 08:29:00 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <p06010201bbe1327653f4@[128.89.89.75]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
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: Stephen Kent
> Sent: Wednesday, November 19, 2003 6:56 AM
>
> . . .
>
> I believe Russ's statement sets the parameters
> for how we clarify this issue, within the bounds
> of OCSP v1.


At the risk of adding to my collection of PKIX battle
memorabilia yet more sticks, stones, arrows and flame residue,
what if caching servers send back a signed "unknown"?  It's
signed, cacheable and already in standing v1 codebases (or so
one presumes).

The only downside is that a client will have to retain state in
order to distinguish a true "unknown" from an "unknown due to
nonce" and thus trigger a non-nonced retry if so configured.

This would be in addition to "MUST reject", which protects the
client in the event it receives a non-nonced response anyway.

Mike




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAJFrdkT097314 for <[e-mail]>; Wed, 19 Nov 2003 07:53:39 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAJFrdIv097313 for ietf-pkix-bks; Wed, 19 Nov 2003 07:53:39 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAJFrckT097307 for <[e-mail]>; Wed, 19 Nov 2003 07:53:38 -0800 (PST) (envelope-from [e-mail])
Received: from MMyersLapTop ([65.39.77.99]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id hAJFrdA64983 for <[e-mail]>; Wed, 19 Nov 2003 08:53:39 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: <[e-mail]>
Subject: RE: OCSPv1 and nonces (RE: draft meeting minutes)
Date: Wed, 19 Nov 2003 07:56:22 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <Pine.WNT.4.58.0311191446300.5344@mnystrom-lap>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
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: Nystrom, Magnus
> Sent: Wednesday, November 19, 2003 6:16 AM
>
> . . .
>
> It seems to me that if any change is to be
> done on the responder side it would be better
> to state that a responder which receives a
> request with a critical nonce extension will
> have to provide a response back including that
> nonce or fail.

The core question is, how does the responder signal failure in a
way that enables closure of the protocol?




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAJFfBkT096744 for <[e-mail]>; Wed, 19 Nov 2003 07:41:11 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAJFfBVU096743 for ietf-pkix-bks; Wed, 19 Nov 2003 07:41:11 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from seguridata1.seguridata.com ([200.57.34.107]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAJFf9kT096732 for <[e-mail]>; Wed, 19 Nov 2003 07:41:09 -0800 (PST) (envelope-from [e-mail])
Received: from MarsXP ([200.67.231.235]) by seguridata1.seguridata.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 19 Nov 2003 09:42:01 -0600
From: "Miguel Rodriguez" <[e-mail]>
To: <[e-mail]>
Subject: RE: OCSPv1 and nonces  (RE: draft meeting minutes)
Date: Wed, 19 Nov 2003 09:43:00 -0600
Message-ID: <000401c3aeb3$da4611b0$[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C3AE81.8FADEBA0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
X-OriginalArrivalTime: 19 Nov 2003 15:42:02.0812 (UTC) FILETIME=[AD6767C0:01C3AEB3]
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_000_0005_01C3AE81.8FADEBA0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

My understanding about the poll is that is was about how many client
implementations would break as a consequence of the normative:
 
"Clients that elect to include a request nonce
     SHALL reject responses that fail to include
     the client's nonce from the associated request."
 
   "Correspondingly, upon receipt of a request
     containing a nonce, a responder SHALL include
     the value of such nonce in the production of
     the associated response."
 
A majority responded "no breakage". After that the discussion turned to
the point Ryan mentions, that is, how clients can decide what to do when
receiving a nonceless response to a request with a nonce. There were
several proposals here, but this was not the purpose of the poll. Of
course one possibility is to always reject such responses. I think our
discussion, and the attention it got, showed that this issue is
important to the PKI community. I'd like to continue the discussion,
since we were getting good proposals.
 
My two cents,
 
Miguel A Rodriguez
SeguriDATA
Mexico
 
-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Ryan M. Hurst
Sent: Wednesday, November 19, 2003 12:30 AM
To: Stephen Kent; Deacon, Alex
Cc: [e-mail]
Subject: RE: OCSPv1 and nonces (RE: draft meeting minutes)
 
Stephen - I agree with what you have written, however the statement in
question does not say that a client "SHOULD" or ought to reject it, it
mandates it my specifying it as a "MUST".
 
Since it is the client that requests the nonce and is the only one who
benefits from when it is used, it should be up to the client to decide
what to do with the response with or without it.
 
Ryan
 
  _____  

From: [e-mail] on behalf of Stephen Kent
Sent: Tue 11/18/2003 4:10 PM
To: Deacon, Alex
Cc: [e-mail]
Subject: Re: OCSPv1 and nonces (RE: draft meeting minutes)
 
At 14:44 -0800 11/18/03, Deacon, Alex wrote:
>Hi,
>
>I was surprised to read about the decision made at the PKIX meeting
last
>week in MN regarding the action to update OCSPv1 to require servers to
>include the nonce in the response or return an error.  (See excerpts
below
>from both the draft minutes sent by Steve and from the WG summary sent
by
>Tim)
>
>Let me summarize the reasons I feel this decision is a bad idea:
>
>1) It will cause currently conformant OCSPv1 implementations to be
>non-conformant.
>
>2) It will cause OCSP profiles defined in other standards bodies to be
>non-conformant.  
>
>3) It seems to be contrary to the "rough consensus" I thought was clear
>based on the various polls Mike Myers posted to the list on this
subject in
>mid October.
>
>Its to late in the game to make such a large change to basic OCSPv1
>behavior.  Keep OCSPv1 as it is.
>

Alex,

There is a clear feeling that when a server returns a canned
(nonceless) response to a client request that included a nonce, that
this is not conforming to the spirit of OCSP, even if the RFC did not
spell out this case in excruciating detail. Russ Housely reaffirmed
this in the quote I included in the minutes.

The question of what a server should do when it receives a request
with a nonce and is unable to comply is still up in the air, in my
opinion.  The list has discussed the merits and shortcomings of
having a server send an (unsigned) error message. Not sending any
response is certainly another option. A good fix to this problem may
have to await a revision of OCSP. But, in any case, a client that
sent a request with a nonce ought to reject a canned response, as
Russ said.

I don't see this clarification as changing the OCSPv1 spec.
Moreover, my reading of the responses to Mike's poll suggests that
the vast majority of servers and clients operate in an appropriate
manner in this regard, given the level of guidance provided in the
RFC.

There is no suggestion here that servers that issue only canned
responses are  bad. OCSP specifically allows for canned responses.
The issue is that a server should not issue a canned response to a
request that clearly requests a response that contains a nonce.

Steve

------=_NextPart_000_0005_01C3AE81.8FADEBA0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">


<meta name=3DProgId content=3DWord.Document>
<meta name=3DGenerator content=3D"Microsoft Word 10">
<meta name=3DOriginator content=3D"Microsoft Word 10">
<link rel=3DFile-List href=3D"cid:filelist.xml@01C3AE81.852207C0">
<link rel=3DEdit-Time-Data href=3D"cid:editdata.mso@01C3AE81.852207C0">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<title>Re: OCSPv1 and nonces (RE: draft meeting minutes)</title>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"country-region"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"place"/>
<!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
  <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
 </w:WordDocument>
</xml><![endif]--><!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;
	mso-font-charset:0;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:1627421319 -2147483648 8 0 66047 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0cm;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;
	text-underline:single;}
p
	{mso-margin-top-alt:auto;
	margin-right:0cm;
	mso-margin-bottom-alt:auto;
	margin-left:0cm;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
span.EmailStyle18
	{mso-style-type:personal-reply;
	mso-style-noshow:yes;
	mso-ansi-font-size:10.0pt;
	mso-bidi-font-size:10.0pt;
	font-family:Arial;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:navy;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;
	mso-header-margin:35.4pt;
	mso-footer-margin:35.4pt;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 10]>
<style>
 /* Style Definitions */=20
 table.MsoNormalTable
	{mso-style-name:"Table Normal";
	mso-tstyle-rowband-size:0;
	mso-tstyle-colband-size:0;
	mso-style-noshow:yes;
	mso-style-parent:"";
	mso-padding-alt:0cm 5.4pt 0cm 5.4pt;
	mso-para-margin:0cm;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Times New Roman";}
</style>
<![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple =
style=3D'tab-interval:36.0pt'>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>My understanding about the poll is =
that is
was about how many client implementations would break as a consequence =
of the normative:<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal =
style=3D'mso-layout-grid-align:none;text-autospace:none'><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier New"'>&quot;Clients
that elect to include a request nonce<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'mso-layout-grid-align:none;text-autospace:none'><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier New"'><span
style=3D'mso-spacerun:yes'>&nbsp;&nbsp;&nbsp;&nbsp; </span>SHALL reject =
responses
that fail to include<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'mso-layout-grid-align:none;text-autospace:none'><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier New"'><span
style=3D'mso-spacerun:yes'>&nbsp;&nbsp;&nbsp;&nbsp; </span>the client's =
nonce
from the associated request.&quot;<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'mso-layout-grid-align:none;text-autospace:none'><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'mso-layout-grid-align:none;text-autospace:none'><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier New"'><span
style=3D'mso-spacerun:yes'>&nbsp;&nbsp; </span>&quot;Correspondingly, =
upon
receipt of a request<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'mso-layout-grid-align:none;text-autospace:none'><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier New"'><span
style=3D'mso-spacerun:yes'>&nbsp;&nbsp;&nbsp;&nbsp; </span>containing a =
nonce, a
responder SHALL include<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'mso-layout-grid-align:none;text-autospace:none'><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier New"'><span
style=3D'mso-spacerun:yes'>&nbsp;&nbsp;&nbsp;&nbsp; </span>the value of =
such
nonce in the production of<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'mso-layout-grid-align:none;text-autospace:none'><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier New"'><span
style=3D'mso-spacerun:yes'>&nbsp;&nbsp;&nbsp;&nbsp; </span>the =
associated
response.&quot;<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>A majority responded &#8220;no =
breakage&#8221;.
After that the discussion turned to the point Ryan mentions, that is, =
how clients
can decide what to do when receiving a nonceless response to a request =
with a
nonce. There were several proposals here, but this was not the purpose =
of the
poll. Of course one possibility is to always reject such responses. I =
think our
discussion, and the attention it got, showed that this issue is =
important to
the PKI community. I&#8217;d like to continue the discussion, since we =
were
getting good proposals.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>My two =
cents,<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Miguel A =
Rodriguez<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><st1:country-region><st1:place><font size=3D2 =
color=3Dnavy
  face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Mexico</span></fo=
nt></st1:place></st1:country-region><font
size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:navy'><o:p></o:p></span></font></p>

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

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

<p class=3DMsoNormal><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma'>-----Original Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> =
[e-mail]
[mailto:[e-mail]] <b><span =
style=3D'font-weight:bold'>On
Behalf Of </span></b>Ryan M. Hurst<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Wednesday, November =
19, 2003
12:30 AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Stephen Kent; Deacon, =
Alex<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> [e-mail]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: OCSPv1 and =
nonces
(RE: draft meeting minutes)</span></font></p>

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

<div id=3DidOWAReplyText5388>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:black'>Stephen - I agree with what you =
have
written, however the statement in question does not say that a client
&quot;SHOULD&quot; or ought to reject it, it mandates it my specifying =
it as a
&quot;MUST&quot;.</span></font><o:p></o:p></p>

</div>

<div>

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

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Since it is the client that requests the nonce and is =
the
only one who&nbsp;benefits from when it is used, it should be up to the =
client
to decide what to do with the response with or without =
it.</span></font><o:p></o:p></p>

</div>

<div>

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

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Ryan</span></font><o:p></o:p></p>

</div>

</div>

<div>

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

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

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

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

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><b><font size=3D2 =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma;font-weight:bold'>From:</spa=
n></font></b><font
size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma'>
[e-mail] on behalf of Stephen Kent<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Tue 11/18/2003 4:10 =
PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Deacon, Alex<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> [e-mail]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> Re: OCSPv1 and =
nonces
(RE: draft meeting minutes)</span></font><o:p></o:p></p>

</div>

<div>

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

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>At 14:44
-0800 11/18/03, Deacon, Alex wrote:<br>
&gt;Hi,<br>
&gt;<br>
&gt;I was surprised to read about the decision made at the PKIX meeting =
last<br>
&gt;week in MN regarding the action to update OCSPv1 to require servers =
to<br>
&gt;include the nonce in the response or return an error.&nbsp; (See =
excerpts
below<br>
&gt;from both the draft minutes sent by Steve and from the WG summary =
sent by<br>
&gt;Tim)<br>
&gt;<br>
&gt;Let me summarize the reasons I feel this decision is a bad idea:<br>
&gt;<br>
&gt;1) It will cause currently conformant OCSPv1 implementations to =
be<br>
&gt;non-conformant.<br>
&gt;<br>
&gt;2) It will cause OCSP profiles defined in other standards bodies to =
be<br>
&gt;non-conformant.&nbsp;&nbsp;<br>
&gt;<br>
&gt;3) It seems to be contrary to the &quot;rough consensus&quot; I =
thought was
clear<br>
&gt;based on the various polls Mike Myers posted to the list on this =
subject in<br>
&gt;mid October.<br>
&gt;<br>
&gt;Its to late in the game to make such a large change to basic =
OCSPv1<br>
&gt;behavior.&nbsp; Keep OCSPv1 as it is.<br>
&gt;<br>
<br>
Alex,<br>
<br>
There is a clear feeling that when a server returns a canned<br>
(nonceless) response to a client request that included a nonce, that<br>
this is not conforming to the spirit of OCSP, even if the RFC did =
not<br>
spell out this case in excruciating detail. Russ Housely reaffirmed<br>
this in the quote I included in the minutes.<br>
<br>
The question of what a server should do when it receives a request<br>
with a nonce and is unable to comply is still up in the air, in my<br>
opinion.&nbsp; The list has discussed the merits and shortcomings of<br>
having a server send an (unsigned) error message. Not sending any<br>
response is certainly another option. A good fix to this problem may<br>
have to await a revision of OCSP. But, in any case, a client that<br>
sent a request with a nonce ought to reject a canned response, as<br>
Russ said.<br>
<br>
I don't see this clarification as changing the OCSPv1 spec.<br>
Moreover, my reading of the responses to Mike's poll suggests that<br>
the vast majority of servers and clients operate in an appropriate<br>
manner in this regard, given the level of guidance provided in the<br>
RFC.<br>
<br>
There is no suggestion here that servers that issue only canned<br>
responses are&nbsp; bad. OCSP specifically allows for canned =
responses.<br>
The issue is that a server should not issue a canned response to a<br>
request that clearly requests a response that contains a nonce.<br>
<br>
Steve</span></font><o:p></o:p></p>

</div>

</div>

</div>

</body>

</html>

------=_NextPart_000_0005_01C3AE81.8FADEBA0--




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAJFcrkT096625 for <[e-mail]>; Wed, 19 Nov 2003 07:38:53 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAJFcrcT096624 for ietf-pkix-bks; Wed, 19 Nov 2003 07:38:53 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAJFcpkT096619 for <[e-mail]>; Wed, 19 Nov 2003 07:38:52 -0800 (PST) (envelope-from [e-mail])
Received: from MMyersLapTop ([65.39.77.99]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id hAJFcqA63740 for <[e-mail]>; Wed, 19 Nov 2003 08:38:52 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: <[e-mail]>
Subject: RE: OCSPv1 and nonces  (RE: draft meeting minutes)
Date: Wed, 19 Nov 2003 07:41:35 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
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: Manger, James H
> Sent: Tuesday, November 18, 2003 7:16 PM
>
> . . .
>
> Michael Myers initiated a poll about adding an error
> code that responders would use when they could not
> copy a nonce from a request to a response.  The poll
> was overwhelmingly rejected: something like 1 Yes, 20
> No.  Clearly a new error code cannot be added.
> Trying to add text that a client must always reject a
> response missing a nonce cannot be added as it would
> be against the spirit of the overwhelming poll result.

Yet the preceding poll (clients MUST reject and servers MUST
incorporate) established no breakage in an overwhelming majority
of implemented cases.  Implemented, mind you: running code,
rough consensus and all that.

Thus in the case of "MUST reject", the clarification as recorded
in the minutes simply codifies what has already been done
correctly even in the absence of a tutorial in normative
language on the proper use of nonces in a security protocol.

The only issue that emerged following the first poll was that
two out of twelve server side implementations would be unable to
comply with "MUST incorporate" due to their reliance on
pre-produced responses to achieve cache-based cost efficiency.

This led to "SHOULD incorporate but if can't, then SHALL <X>".
A variety of syntax, semantics and rules of behavior regarding X
were and continue to be discussed.

Read the minutes carefully and note that the language recorded
there does NOT call for an error code.  It simply asserts in
normative language a fundamental principle of security
engineering that seems to have been better understood than it
was documented.

So, that leaves us with yet having to determine a value for X.
The error code poll asked us to consider one such idea.  It did
NOT seek an implicit repudiation of the poll that preceded it,
wherein "MUST reject" was very clearly established.

Mike




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAJEwbkT095171 for <[e-mail]>; Wed, 19 Nov 2003 06:58:37 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAJEwbrq095170 for ietf-pkix-bks; Wed, 19 Nov 2003 06:58:37 -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.10/8.12.8) with ESMTP id hAJEwakT095164 for <[e-mail]>; Wed, 19 Nov 2003 06:58:36 -0800 (PST) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id hAJEwS9i025313; Wed, 19 Nov 2003 09:58:29 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p06010201bbe1327653f4@[128.89.89.75]>
In-Reply-To:  <[e-mail].a u>
References:  <[e-mail].a u>
Date: Wed, 19 Nov 2003 09:55:55 -0500
To: "Manger, James H" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: OCSPv1 and nonces  (RE: draft meeting minutes)
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
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 13:15 +1000 11/19/03, Manger, James H wrote:
>I agree with Alex Deacon (& Ryan), not Stephen Kent, on this issue.
>
>Michael Myers initiated a poll about adding an error code that 
>responders would use when they could not copy a nonce from a request 
>to a response.  The poll was overwhelmingly rejected: something like 
>1 Yes, 20 No.  Clearly a new error code cannot be added.  Trying to 
>add text that a client must always reject a response missing a nonce 
>cannot be added as it would be against the spirit of the 
>overwhelming poll result.

James,

My comments addressed the question of proper behavior of clients and 
servers when there is a mismatch between the type of request offered 
and the capability of the server to respond consistent with the 
request type.  The poll I alluded too, perhaps not precisely enough, 
was on that topic.  I was not referring to the question of whether we 
should send an error message.

>Alex might not have to worry as the minutes did not actually say a 
>new version of OCSPv1 would be produced (apparently Tim Polk's "WG 
>summary" did but I have not seen that).  The previous poll shows it 
>would not be supported - and I don't think you are allowed to go 
>straight from editor to area director, bypassing the working group.

My comments did not suggest that we would change OCSPv1 to impose a 
new requirement to send new messages, etc. But there is certainly 
room to clarify what some folks see as an ambiguous area of the state 
machine.

>P.S. Russ Housley's quote fails to accommodate an OCSP client that 
>puts a nonce in an OCSP request because the client **prefers** to 
>get replay protection, though may be willing to forgo that 
>protection for the sake of a more scalable system if only cached 
>responses are available.  It would be ok to add text saying "a 
>client requiring replay detection can include a nonce in the request 
>and reject a nonce-less response".

Your comment immediately above assumes a possible motivation on the 
part of some clients who insert a nonce in a request. I can't rule 
out the possibility that some clients may behave in this fashion, but 
this assumption cannot generally be inferred from the OCSP spec.

We recognize now that the spec does not accommodate all the possible 
ways that a client and a server might interact, when the server 
supports only canned responses. To fix this problem completely will 
probably require a revised OCSP, probably with a new version number. 
Howeverm in the interim, it is reasonable to clarify what clients and 
servers should do under these circumstances, without changing the 
bits on the wire, and without introducing vulnerabilities of the sort 
that the use of nonces is designed to avoid. I believe Russ's 
statement sets the parameters for how we clarify this issue, within 
the bounds of OCSP v1.

Steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAJEFrkT093555 for <[e-mail]>; Wed, 19 Nov 2003 06:15:53 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAJEFrqj093554 for ietf-pkix-bks; Wed, 19 Nov 2003 06:15:53 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130]) by above.proper.com (8.12.10/8.12.8) with SMTP id hAJEFpkT093546 for <[e-mail]>; Wed, 19 Nov 2003 06:15:51 -0800 (PST) (envelope-from [e-mail])
Received: from ebola.securitydynamics.com by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 19 Nov 2003 14:15:52 UT
Received: from sdtihq24.securid.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.12.10/NULL) with ESMTP id hAJEB5R6011013 for <[e-mail]>; Wed, 19 Nov 2003 09:11:05 -0500 (EST)
Received: from exna00.securitydynamics.com (exna00.securitydynamics.com [10.100.8.217]) by sdtihq24.securid.com (8.12.10/8.12.9) with ESMTP id hAJEFpsj004234 for <[e-mail]>; Wed, 19 Nov 2003 09:15:51 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2657.72) id <W335CM3A>; Wed, 19 Nov 2003 09:15:43 -0500
Received: from sornholt-lap.eu.rsa.net (MNYSTROM-LAP [10.129.13.12]) by exrsa01.rsa.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id W4Q48CSR; Wed, 19 Nov 2003 06:15:48 -0800
From: "Nystrom, Magnus" <[e-mail]>
Reply-To: "Nystrom, Magnus" <[e-mail]>
To: [e-mail]
Date: Wed, 19 Nov 2003 15:15:53 +0100 (W. Europe Standard Time)
Subject: RE: OCSPv1 and nonces (RE: draft meeting minutes)
Message-ID: <Pine.WNT.4.58.0311191446300.5344@mnystrom-lap>
X-X-Sender: [e-mail]
MIME-Version: 1.0
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>

James Manger wrote:

[...]
> P.S. Russ Housley's quote fails to accommodate an OCSP client that puts
> a nonce in an OCSP request because the client **prefers** to get replay
> protection, though may be willing to forgo that protection for the sake
> of a more scalable system if only cached responses are available.  It
> would be ok to add text saying "a client requiring replay detection can
> include a nonce in the request and reject a nonce-less response".

Exactly. Nonces are extensions, and 2560 says that its extension model is
"based on the extension model employed in X.509 version 3 certificates see
[RFC2459]. Support for all extensions is optional for both clients and
responders." As we know, the semantics for any non-critical extension is
"a non-critical extension MAY be ignored" [RFC3280].

Hence, as I see it, an OCSP responder is free to ignore any non-critical
OCSP extensions, including nonces, and yet be completely compliant. RFC
2560 does not say anything about the nonce extension being critical (in
fact, it recommends it to not be), and this is reflected in the behavior
of - currently conformant - OCSP responders. . It seems to me that if any
change is to be done on the responder side it would be better to state
that a responder which receives a request with a critical nonce extension
will have to provide a response back including that nonce or fail.

-- Magnus


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAJ8BxkT050041 for <[e-mail]>; Wed, 19 Nov 2003 00:11:59 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAJ8BwF7050032 for ietf-pkix-bks; Wed, 19 Nov 2003 00:11:58 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAJ8BskT049966 for <[e-mail]>; Wed, 19 Nov 2003 00:11:55 -0800 (PST) (envelope-from [e-mail])
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id JAA25790; Wed, 19 Nov 2003 09:18:26 +0100
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id JAA17149; Wed, 19 Nov 2003 09:14:03 +0100
Message-ID: <[e-mail]>
Date: Wed, 19 Nov 2003 09:11:51 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Alice Sturgeon <[e-mail]>
CC: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-warranty-extn-04.txt
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; 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>

Alice,

Does this new document addresses the issues I raised to the IESG during the 
last call ?

If yes, would you please provide a resolution for my comments.

Denis


> 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 Warranty Certificate Extension
> 	Author(s)	: D. Linsenbardt, S. Pontius, A. Sturgeon
> 	Filename	: draft-ietf-pkix-warranty-extn-04.txt
> 	Pages		: 8
> 	Date		: 2003-11-18
> 	
> This document describes a certificate extension to explicitly state
> the warranty offered by a Certificate Authority (CA) for a the
> certificate containing the extension.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-warranty-extn-04.txt
> 
> To remove yourself from the IETF Announcement list, send a message to 
> ietf-announce-request with the word unsubscribe in the body of the message.
> 
> 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-warranty-extn-04.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-warranty-extn-04.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 [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAJ6WOkT013043 for <[e-mail]>; Tue, 18 Nov 2003 22:32:24 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAJ6WOUH013041 for ietf-pkix-bks; Tue, 18 Nov 2003 22:32:24 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAJ6WNkT012971 for <[e-mail]>; Tue, 18 Nov 2003 22:32:23 -0800 (PST) (envelope-from [e-mail])
Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 18 Nov 2003 22:32:13 -0800
Received: from 157.54.8.155 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 18 Nov 2003 22:32:30 -0800
Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 18 Nov 2003 22:32:20 -0800
Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 18 Nov 2003 22:32:22 -0800
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 18 Nov 2003 22:32:18 -0800
x-mimeole: Produced By Microsoft Exchange V6.5.7097.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary"
Subject: RE: OCSPv1 and nonces  (RE: draft meeting minutes)
Date: Tue, 18 Nov 2003 22:29:45 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: OCSPv1 and nonces  (RE: draft meeting minutes)
Thread-Index: AcOuQ6SQashqY1dURr+s7RD5AT89gAAIuFYR
From: "Ryan M. Hurst" <[e-mail]>
To: "Stephen Kent" <[e-mail]>, "Deacon, Alex" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 19 Nov 2003 06:32:18.0830 (UTC) FILETIME=[E16B2AE0:01C3AE66]
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.

--------------InterScan_NT_MIME_Boundary
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3AE66.E1185F7E"

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

Stephen - I agree with what you have written, however the statement in =
question does not say that a client "SHOULD" or ought to reject it, it =
mandates it my specifying it as a "MUST".
=20
Since it is the client that requests the nonce and is the only one who =
benefits from when it is used, it should be up to the client to decide =
what to do with the response with or without it.
=20
Ryan

________________________________

From: [e-mail] on behalf of Stephen Kent
Sent: Tue 11/18/2003 4:10 PM
To: Deacon, Alex
Cc: [e-mail]
Subject: Re: OCSPv1 and nonces (RE: draft meeting minutes)




At 14:44 -0800 11/18/03, Deacon, Alex wrote:
>Hi,
>
>I was surprised to read about the decision made at the PKIX meeting =
last
>week in MN regarding the action to update OCSPv1 to require servers to
>include the nonce in the response or return an error.  (See excerpts =
below
>from both the draft minutes sent by Steve and from the WG summary sent =
by
>Tim)
>
>Let me summarize the reasons I feel this decision is a bad idea:
>
>1) It will cause currently conformant OCSPv1 implementations to be
>non-conformant.
>
>2) It will cause OCSP profiles defined in other standards bodies to be
>non-conformant. =20
>
>3) It seems to be contrary to the "rough consensus" I thought was clear
>based on the various polls Mike Myers posted to the list on this =
subject in
>mid October.
>
>Its to late in the game to make such a large change to basic OCSPv1
>behavior.  Keep OCSPv1 as it is.
>

Alex,

There is a clear feeling that when a server returns a canned
(nonceless) response to a client request that included a nonce, that
this is not conforming to the spirit of OCSP, even if the RFC did not
spell out this case in excruciating detail. Russ Housely reaffirmed
this in the quote I included in the minutes.

The question of what a server should do when it receives a request
with a nonce and is unable to comply is still up in the air, in my
opinion.  The list has discussed the merits and shortcomings of
having a server send an (unsigned) error message. Not sending any
response is certainly another option. A good fix to this problem may
have to await a revision of OCSP. But, in any case, a client that
sent a request with a nonce ought to reject a canned response, as
Russ said.

I don't see this clarification as changing the OCSPv1 spec.
Moreover, my reading of the responses to Mike's poll suggests that
the vast majority of servers and clients operate in an appropriate
manner in this regard, given the level of guidance provided in the
RFC.

There is no suggestion here that servers that issue only canned
responses are  bad. OCSP specifically allows for canned responses.
The issue is that a server should not issue a canned response to a
request that clearly requests a response that contains a nonce.

Steve



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

<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">=0A=
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">=0A=
<HTML>=0A=
<HEAD>=0A=
=0A=
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7097.0">=0A=
<TITLE>Re: OCSPv1 and nonces  (RE: draft meeting minutes)</TITLE>=0A=
</HEAD>=0A=
<BODY>=0A=
<DIV id=3DidOWAReplyText5388 dir=3Dltr>=0A=
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2>Stephen - I =
agree with what =0A=
you have written, however the statement in question does not say that a =
client =0A=
"SHOULD" or ought to reject it, it mandates it my specifying it as a =0A=
"MUST".</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Since it is the client that =
requests the =0A=
nonce and is the only one who&nbsp;benefits from when it is used, it =
should be =0A=
up to the client to decide what to do with the response with or without =0A=
it.</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Ryan</FONT></DIV></DIV>=0A=
<DIV dir=3Dltr><BR>=0A=
<HR tabIndex=3D-1>=0A=
<FONT face=3DTahoma size=3D2><B>From:</B> [e-mail] =
on behalf of =0A=
Stephen Kent<BR><B>Sent:</B> Tue 11/18/2003 4:10 PM<BR><B>To:</B> =
Deacon, =0A=
Alex<BR><B>Cc:</B> [e-mail]<BR><B>Subject:</B> Re: OCSPv1 and =
nonces =0A=
(RE: draft meeting minutes)<BR></FONT><BR></DIV>=0A=
<DIV><BR>=0A=
<P><FONT size=3D2>At 14:44 -0800 11/18/03, Deacon, Alex =0A=
wrote:<BR>&gt;Hi,<BR>&gt;<BR>&gt;I was surprised to read about the =
decision made =0A=
at the PKIX meeting last<BR>&gt;week in MN regarding the action to =
update OCSPv1 =0A=
to require servers to<BR>&gt;include the nonce in the response or return =
an =0A=
error.&nbsp; (See excerpts below<BR>&gt;from both the draft minutes sent =
by =0A=
Steve and from the WG summary sent by<BR>&gt;Tim)<BR>&gt;<BR>&gt;Let me =0A=
summarize the reasons I feel this decision is a bad =
idea:<BR>&gt;<BR>&gt;1) It =0A=
will cause currently conformant OCSPv1 implementations to =0A=
be<BR>&gt;non-conformant.<BR>&gt;<BR>&gt;2) It will cause OCSP profiles =
defined =0A=
in other standards bodies to =0A=
be<BR>&gt;non-conformant.&nbsp;&nbsp;<BR>&gt;<BR>&gt;3) It seems to be =
contrary =0A=
to the "rough consensus" I thought was clear<BR>&gt;based on the various =
polls =0A=
Mike Myers posted to the list on this subject in<BR>&gt;mid =0A=
October.<BR>&gt;<BR>&gt;Its to late in the game to make such a large =
change to =0A=
basic OCSPv1<BR>&gt;behavior.&nbsp; Keep OCSPv1 as it =0A=
is.<BR>&gt;<BR><BR>Alex,<BR><BR>There is a clear feeling that when a =
server =0A=
returns a canned<BR>(nonceless) response to a client request that =
included a =0A=
nonce, that<BR>this is not conforming to the spirit of OCSP, even if the =
RFC did =0A=
not<BR>spell out this case in excruciating detail. Russ Housely =0A=
reaffirmed<BR>this in the quote I included in the minutes.<BR><BR>The =
question =0A=
of what a server should do when it receives a request<BR>with a nonce =
and is =0A=
unable to comply is still up in the air, in my<BR>opinion.&nbsp; The =
list has =0A=
discussed the merits and shortcomings of<BR>having a server send an =
(unsigned) =0A=
error message. Not sending any<BR>response is certainly another option. =
A good =0A=
fix to this problem may<BR>have to await a revision of OCSP. But, in any =
case, a =0A=
client that<BR>sent a request with a nonce ought to reject a canned =
response, =0A=
as<BR>Russ said.<BR><BR>I don't see this clarification as changing the =
OCSPv1 =0A=
spec.<BR>Moreover, my reading of the responses to Mike's poll suggests =0A=
that<BR>the vast majority of servers and clients operate in an =0A=
appropriate<BR>manner in this regard, given the level of guidance =
provided in =0A=
the<BR>RFC.<BR><BR>There is no suggestion here that servers that issue =
only =0A=
canned<BR>responses are&nbsp; bad. OCSP specifically allows for canned =0A=
responses.<BR>The issue is that a server should not issue a canned =
response to =0A=
a<BR>request that clearly requests a response that contains a =0A=
nonce.<BR><BR>Steve<BR></FONT></P></DIV>=0A=
=0A=
</BODY>=0A=
</HTML>
------_=_NextPart_001_01C3AE66.E1185F7E--

--------------InterScan_NT_MIME_Boundary--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAJ3G7kT095135 for <[e-mail]>; Tue, 18 Nov 2003 19:16:07 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAJ3G7ar095134 for ietf-pkix-bks; Tue, 18 Nov 2003 19:16:07 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailao.ntcif.telstra.com.au ([202.12.233.17]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAJ3G5kT095109 for <[e-mail]>; Tue, 18 Nov 2003 19:16:06 -0800 (PST) (envelope-from [e-mail])
Received: from mailbi.ntcif.telstra.com.au (mailbi.ntcif.telstra.com.au [202.12.162.19]) by mailao.ntcif.telstra.com.au (Postfix) with ESMTP id BB6E420711 for <[e-mail]>; Wed, 19 Nov 2003 14:15:58 +1100 (EST)
Received: from mail.cdn.telstra.com.au (localhost [127.0.0.1]) by mailbi.ntcif.telstra.com.au (Postfix) with ESMTP id 3636412985 for <[e-mail]>; Wed, 19 Nov 2003 14:15:58 +1100 (EST)
Received: from WSMSG0004.srv.dir.telstra.com (wsmsg0004.srv.dir.telstra.com [192.74.168.133]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id OAA08627 for <[e-mail]>; Wed, 19 Nov 2003 14:15:57 +1100 (EST)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Subject: RE: OCSPv1 and nonces  (RE: draft meeting minutes)
Date: Wed, 19 Nov 2003 13:15:33 +1000
Message-ID: <[e-mail]>
Thread-Topic: OCSPv1 and nonces  (RE: draft meeting minutes)
Thread-Index: AcOuQhy4qr50J86UQ3qBd0aL1/t6HgAAWbrA
From: "Manger, James H" <[e-mail]>
To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id hAJ3G6kT095130
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 Alex Deacon (& Ryan), not Stephen Kent, on this issue.

Michael Myers initiated a poll about adding an error code that responders would use when they could not copy a nonce from a request to a response.  The poll was overwhelmingly rejected: something like 1 Yes, 20 No.  Clearly a new error code cannot be added.  Trying to add text that a client must always reject a response missing a nonce cannot be added as it would be against the spirit of the overwhelming poll result.

Alex might not have to worry as the minutes did not actually say a new version of OCSPv1 would be produced (apparently Tim Polk's "WG summary" did but I have not seen that).  The previous poll shows it would not be supported - and I don't think you are allowed to go straight from editor to area director, bypassing the working group.


P.S. Russ Housley's quote fails to accommodate an OCSP client that puts a nonce in an OCSP request because the client **prefers** to get replay protection, though may be willing to forgo that protection for the sake of a more scalable system if only cached responses are available.  It would be ok to add text saying "a client requiring replay detection can include a nonce in the request and reject a nonce-less response".



-----Original Message-----
From: Stephen Kent [mailto:[e-mail]]
Sent: Wednesday, 19 November 2003 11:11 AM
To: Deacon, Alex
Cc: [e-mail]
Subject: Re: OCSPv1 and nonces (RE: draft meeting minutes)



At 14:44 -0800 11/18/03, Deacon, Alex wrote:
>Hi,
>
>I was surprised to read about the decision made at the PKIX meeting last
>week in MN regarding the action to update OCSPv1 to require servers to
>include the nonce in the response or return an error.  (See excerpts below
>from both the draft minutes sent by Steve and from the WG summary sent by
>Tim) 
>
>Let me summarize the reasons I feel this decision is a bad idea:
>
>1) It will cause currently conformant OCSPv1 implementations to be
>non-conformant.
>
>2) It will cause OCSP profiles defined in other standards bodies to be
>non-conformant.   
>
>3) It seems to be contrary to the "rough consensus" I thought was clear
>based on the various polls Mike Myers posted to the list on this subject in
>mid October. 
>
>Its to late in the game to make such a large change to basic OCSPv1
>behavior.  Keep OCSPv1 as it is.
>

Alex,

There is a clear feeling that when a server returns a canned 
(nonceless) response to a client request that included a nonce, that 
this is not conforming to the spirit of OCSP, even if the RFC did not 
spell out this case in excruciating detail. Russ Housely reaffirmed 
this in the quote I included in the minutes.

The question of what a server should do when it receives a request 
with a nonce and is unable to comply is still up in the air, in my 
opinion.  The list has discussed the merits and shortcomings of 
having a server send an (unsigned) error message. Not sending any 
response is certainly another option. A good fix to this problem may 
have to await a revision of OCSP. But, in any case, a client that 
sent a request with a nonce ought to reject a canned response, as 
Russ said.

I don't see this clarification as changing the OCSPv1 spec. 
Moreover, my reading of the responses to Mike's poll suggests that 
the vast majority of servers and clients operate in an appropriate 
manner in this regard, given the level of guidance provided in the 
RFC.

There is no suggestion here that servers that issue only canned 
responses are  bad. OCSP specifically allows for canned responses. 
The issue is that a server should not issue a canned response to a 
request that clearly requests a response that contains a nonce.

Steve



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAJ2ePkT093787 for <[e-mail]>; Tue, 18 Nov 2003 18:40:25 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAJ2ePqb093786 for ietf-pkix-bks; Tue, 18 Nov 2003 18:40:25 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAJ2eOkT093781 for <[e-mail]>; Tue, 18 Nov 2003 18:40:24 -0800 (PST) (envelope-from [e-mail])
Received: from MMyersLapTop ([65.39.77.99]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id hAJ2eRA23239 for <[e-mail]>; Tue, 18 Nov 2003 19:40:27 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: <[e-mail]>
Subject: RE: OCSPv1 and nonces  (RE: draft meeting minutes)
Date: Tue, 18 Nov 2003 18:43:10 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
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 initial poll I sent out on 9/24/03 was worded as follows:

[Who] would break as a consequence of the following normative
language:

    "Clients that elect to include a request nonce
     SHALL reject responses that fail to include
     the client's nonce from the associated request."

    "Correspondingly, upon receipt of a request
     containing a nonce, a responder SHALL include
     the value of such nonce in the production of
     the associated response."

11 of 12 client side implementors and 10 of 12 server side
implementors responded "no breakage".

Mike




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAJ12qkT090198 for <[e-mail]>; Tue, 18 Nov 2003 17:02:52 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAJ12qaM090197 for ietf-pkix-bks; Tue, 18 Nov 2003 17:02:52 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAJ12pkT090188 for <[e-mail]>; Tue, 18 Nov 2003 17:02:51 -0800 (PST) (envelope-from [e-mail])
Received: from mail5.microsoft.com ([157.54.6.156]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Tue, 18 Nov 2003 17:02:52 -0800
Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(6.0.3790.1039); Tue, 18 Nov 2003 17:02:58 -0800
Received: from 157.54.8.109 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 18 Nov 2003 17:02:47 -0800
Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 18 Nov 2003 17:02:47 -0800
Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 18 Nov 2003 17:02:36 -0800
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.82]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 18 Nov 2003 17:02:45 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.7097.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: OCSPv1 and nonces  (RE: draft meeting minutes)
Date: Tue, 18 Nov 2003 17:03:20 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: OCSPv1 and nonces  (RE: draft meeting minutes)
Thread-Index: AcOuOBWuEZcCOz/ySBCLd9hfQRTEMgAALskw
From: "Ryan M. Hurst" <[e-mail]>
To: "Deacon, Alex" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 19 Nov 2003 01:02:45.0286 (UTC) FILETIME=[D777CC60:01C3AE38]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id hAJ12pkT090191
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 this, in-fact it appears to be in conflict with the earlier
discussions on the thread on the same topic.

Ryan

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Deacon, Alex
Sent: Tuesday, November 18, 2003 2:44 PM
To: [e-mail]
Subject: OCSPv1 and nonces (RE: draft meeting minutes)


Hi,

I was surprised to read about the decision made at the PKIX meeting last
week in MN regarding the action to update OCSPv1 to require servers to
include the nonce in the response or return an error.  (See excerpts
below
from both the draft minutes sent by Steve and from the WG summary sent
by
Tim)  

Let me summarize the reasons I feel this decision is a bad idea:

1) It will cause currently conformant OCSPv1 implementations to be
non-conformant. 

2) It will cause OCSP profiles defined in other standards bodies to be
non-conformant.    

3) It seems to be contrary to the "rough consensus" I thought was clear
based on the various polls Mike Myers posted to the list on this subject
in
mid October.  

Its to late in the game to make such a large change to basic OCSPv1
behavior.  Keep OCSPv1 as it is.  

Alex


========================

>From the WG summary
> 3. OCSP v1 will be revised to specify the server and client
> processing requirements where the client included a nonce in 
> the request.  The revised document will require servers to include
> the nonce in the response or return an error.


>From the Draft Meeting Minutes  
> OCSPv1 problem - Mike Meyers (Traceroute)
> 	OCSP has a facility in which a client may include a nonce in 
> a request, to detect and reject replays of responses. Unfortunately, 
> the RFC did not make perfectly clear that a client MUST reject a 
> response that did not include a nonce, if the client included a nonce 
> in the request. Similarly, the RFC did not make clear what a server 
> should do if it receives a request with a nonce, but is incapable of 
> generating a response containing a nonce, i.e., a server that deals 
> only with pre-signed responses.
> 	A straw poll indicated that the vast majority of clients deal 
> with these issues properly, but not all. OCSP servers that rely on 
> caching do not generate a unique response for each request, so they 
> omit nonces.  An error could be returned by a server to indicate the 
> inability to respond properly to a request with a nonce, but errors 
> are not signed, so this does not address the security concern.
> 	Russ Housley, the cognizant AD made the following observation 
> re this issue. "When an OCSP Client puts a nonce in an OCSP Request, 
> replay protection is expected. Therefore, the OCSP Responder MUST 
> include the same nonce value in the OCSP Response.  If the OCSP 
> Client receives an OCSP Response that fails to include the correct 
> nonce value, it MUST be rejected."



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAJ0CCkT088424 for <[e-mail]>; Tue, 18 Nov 2003 16:12:12 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAJ0CCw2088423 for ietf-pkix-bks; Tue, 18 Nov 2003 16:12:12 -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.10/8.12.8) with ESMTP id hAJ0CBkT088416 for <[e-mail]>; Tue, 18 Nov 2003 16:12:11 -0800 (PST) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id hAJ0C59i024908; Tue, 18 Nov 2003 19:12:05 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p06010208bbe0625d80ce@[128.89.89.75]>
In-Reply-To:  <[e-mail]>
References:  <[e-mail]>
Date: Tue, 18 Nov 2003 19:10:50 -0500
To: "Deacon, Alex" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: OCSPv1 and nonces  (RE: draft meeting minutes)
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
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 14:44 -0800 11/18/03, Deacon, Alex wrote:
>Hi,
>
>I was surprised to read about the decision made at the PKIX meeting last
>week in MN regarding the action to update OCSPv1 to require servers to
>include the nonce in the response or return an error.  (See excerpts below
>from both the draft minutes sent by Steve and from the WG summary sent by
>Tim) 
>
>Let me summarize the reasons I feel this decision is a bad idea:
>
>1) It will cause currently conformant OCSPv1 implementations to be
>non-conformant.
>
>2) It will cause OCSP profiles defined in other standards bodies to be
>non-conformant.   
>
>3) It seems to be contrary to the "rough consensus" I thought was clear
>based on the various polls Mike Myers posted to the list on this subject in
>mid October. 
>
>Its to late in the game to make such a large change to basic OCSPv1
>behavior.  Keep OCSPv1 as it is.
>

Alex,

There is a clear feeling that when a server returns a canned 
(nonceless) response to a client request that included a nonce, that 
this is not conforming to the spirit of OCSP, even if the RFC did not 
spell out this case in excruciating detail. Russ Housely reaffirmed 
this in the quote I included in the minutes.

The question of what a server should do when it receives a request 
with a nonce and is unable to comply is still up in the air, in my 
opinion.  The list has discussed the merits and shortcomings of 
having a server send an (unsigned) error message. Not sending any 
response is certainly another option. A good fix to this problem may 
have to await a revision of OCSP. But, in any case, a client that 
sent a request with a nonce ought to reject a canned response, as 
Russ said.

I don't see this clarification as changing the OCSPv1 spec. 
Moreover, my reading of the responses to Mike's poll suggests that 
the vast majority of servers and clients operate in an appropriate 
manner in this regard, given the level of guidance provided in the 
RFC.

There is no suggestion here that servers that issue only canned 
responses are  bad. OCSP specifically allows for canned responses. 
The issue is that a server should not issue a canned response to a 
request that clearly requests a response that contains a nonce.

Steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAIMiHkT085541 for <[e-mail]>; Tue, 18 Nov 2003 14:44:17 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAIMiHLM085539 for ietf-pkix-bks; Tue, 18 Nov 2003 14:44:17 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAIMiHkT085534 for <[e-mail]>; Tue, 18 Nov 2003 14:44:17 -0800 (PST) (envelope-from [e-mail])
Received: from mou1wnexc01.vcorp.ad.vrsn.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.10/) with ESMTP id hAIMiISh024891 for <[e-mail]>; Tue, 18 Nov 2003 14:44:18 -0800 (PST)
Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2653.19) id <XDC2P8WT>; Tue, 18 Nov 2003 14:44:18 -0800
Message-ID: <[e-mail]>
From: "Deacon, Alex" <[e-mail]>
To: [e-mail]
Subject: OCSPv1 and nonces  (RE: draft meeting minutes)
Date: Tue, 18 Nov 2003 14:44:12 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
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>

Hi,

I was surprised to read about the decision made at the PKIX meeting last
week in MN regarding the action to update OCSPv1 to require servers to
include the nonce in the response or return an error.  (See excerpts below
from both the draft minutes sent by Steve and from the WG summary sent by
Tim)  

Let me summarize the reasons I feel this decision is a bad idea:

1) It will cause currently conformant OCSPv1 implementations to be
non-conformant. 

2) It will cause OCSP profiles defined in other standards bodies to be
non-conformant.    

3) It seems to be contrary to the "rough consensus" I thought was clear
based on the various polls Mike Myers posted to the list on this subject in
mid October.  

Its to late in the game to make such a large change to basic OCSPv1
behavior.  Keep OCSPv1 as it is.  

Alex


========================

>From the WG summary
> 3. OCSP v1 will be revised to specify the server and client
> processing requirements where the client included a nonce in 
> the request.  The revised document will require servers to include
> the nonce in the response or return an error.


>From the Draft Meeting Minutes  
> OCSPv1 problem - Mike Meyers (Traceroute)
> 	OCSP has a facility in which a client may include a nonce in 
> a request, to detect and reject replays of responses. Unfortunately, 
> the RFC did not make perfectly clear that a client MUST reject a 
> response that did not include a nonce, if the client included a nonce 
> in the request. Similarly, the RFC did not make clear what a server 
> should do if it receives a request with a nonce, but is incapable of 
> generating a response containing a nonce, i.e., a server that deals 
> only with pre-signed responses.
> 	A straw poll indicated that the vast majority of clients deal 
> with these issues properly, but not all. OCSP servers that rely on 
> caching do not generate a unique response for each request, so they 
> omit nonces.  An error could be returned by a server to indicate the 
> inability to respond properly to a request with a nonce, but errors 
> are not signed, so this does not address the security concern.
> 	Russ Housley, the cognizant AD made the following observation 
> re this issue. "When an OCSP Client puts a nonce in an OCSP Request, 
> replay protection is expected. Therefore, the OCSP Responder MUST 
> include the same nonce value in the OCSP Response.  If the OCSP 
> Client receives an OCSP Response that fails to include the correct 
> nonce value, it MUST be rejected."


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAIKA7kT079898 for <[e-mail]>; Tue, 18 Nov 2003 12:10:07 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAIKA7On079897 for ietf-pkix-bks; Tue, 18 Nov 2003 12:10:07 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAIKA5kT079892 for <[e-mail]>; Tue, 18 Nov 2003 12:10:06 -0800 (PST) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11490; Tue, 18 Nov 2003 15:09:53 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-warranty-extn-04.txt
Date: Tue, 18 Nov 2003 15:09:53 -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 Warranty Certificate Extension
	Author(s)	: D. Linsenbardt, S. Pontius, A. Sturgeon
	Filename	: draft-ietf-pkix-warranty-extn-04.txt
	Pages		: 8
	Date		: 2003-11-18
	
This document describes a certificate extension to explicitly state
the warranty offered by a Certificate Authority (CA) for a the
certificate containing the extension.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-warranty-extn-04.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-warranty-extn-04.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-warranty-extn-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-warranty-extn-04.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 [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAHLChkT047297 for <[e-mail]>; Mon, 17 Nov 2003 13:12:43 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAHLCheY047296 for ietf-pkix-bks; Mon, 17 Nov 2003 13:12:43 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAHLCgkT047291 for <[e-mail]>; Mon, 17 Nov 2003 13:12:42 -0800 (PST) (envelope-from [e-mail])
Received: from apache by asgard.ietf.org with local (Exim 4.14) id 1ALqXe-0006Xp-Fx; Mon, 17 Nov 2003 16:04:14 -0500
X-test-idtracker: no
To: IETF-Announce :;
Cc: [e-mail]
From: The IESG <[e-mail]>
Subject: Last Call: 'Internet X.509 Public Key Infrastructure Proxy  Certificate Profile' to Proposed Standard 
Reply-to: [e-mail]
Message-Id: <[e-mail]>
Date: Mon, 17 Nov 2003 16:04:14 -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:

- 'Internet X.509 Public Key Infrastructure Proxy Certificate Profile '
   <draft-ietf-pkix-proxy-09.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[e-mail] or [e-mail] mailing lists by 2003-12-01.

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



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAHG7GkT035559 for <[e-mail]>; Mon, 17 Nov 2003 08:07:16 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAHG7GJT035558 for ietf-pkix-bks; Mon, 17 Nov 2003 08:07:16 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAHG7FkT035551 for <[e-mail]>; Mon, 17 Nov 2003 08:07:15 -0800 (PST) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18004; Mon, 17 Nov 2003 11:07:02 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-proxy-09.txt
Date: Mon, 17 Nov 2003 11:07: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 Proxy Certificate Profile
	Author(s)	: S. Tuecke
	Filename	: draft-ietf-pkix-proxy-09.txt
	Pages		: 46
	Date		: 2003-11-11
	
This document forms a certificate profile for Proxy Certificates, 
based on X.509 Public Key Infrastructure (PKI) certificates as 
defined in RFC 3280, for use in the Internet.  The term Proxy 
Certificate is used to describe a certificate that is derived from, 
and signed by, a normal X.509 Public Key End Entity Certificate or 
by another Proxy Certificate for the purpose of providing 
restricted proxying and delegation within a PKI based 
authentication system.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-proxy-09.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-proxy-09.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-proxy-09.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-proxy-09.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 [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAHE92kT027484 for <[e-mail]>; Mon, 17 Nov 2003 06:09:02 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAHE92e6027483 for ietf-pkix-bks; Mon, 17 Nov 2003 06:09:02 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp7.hy.skanova.net (smtp7.hy.skanova.net [195.67.199.140]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAHE90kT027476 for <[e-mail]>; Mon, 17 Nov 2003 06:09:01 -0800 (PST) (envelope-from [e-mail])
Received: from arport (t12o913p51.telia.com [213.64.28.171]) by smtp7.hy.skanova.net (8.12.10/8.12.10) with SMTP id hAHE8n1w022919 for <[e-mail]>; Mon, 17 Nov 2003 15:08:55 +0100 (CET)
Message-ID: <006b01c3ad13$d7ddff60$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>
References: <00e101c39fc2$a59fa200$3a1b40d5@arport> <p06002003bbc83730f4f9@[128.89.89.75]> <[e-mail]> <p0600200bbbc8676a42ac@[128.89.89.75]>
Subject: Re: Web-PKI Keygen/Certreq Questions
Date: Mon, 17 Nov 2003 15:05:17 +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>

Just to set the record straight: Another consortium has indeed
[also] found the existings keygen/certreq mechanisms largely
inferior and will publish a draft solution in a couple of months
or so.  I just talked to one of the architects, and he confirmed that
it will support the kind of stuff that most of the proprietary solutions
already do, such as key-container co-signing, passphrase policy
control, and multi-key generation.

/a


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAH8DSkT083818 for <[e-mail]>; Mon, 17 Nov 2003 00:13:28 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAH8DSAS083817 for ietf-pkix-bks; Mon, 17 Nov 2003 00:13:28 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAH8DPkT083796 for <[e-mail]>; Mon, 17 Nov 2003 00:13:26 -0800 (PST) (envelope-from [e-mail])
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id JAA33040; Mon, 17 Nov 2003 09:19:54 +0100
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id JAA14484; Mon, 17 Nov 2003 09:15:32 +0100
Message-ID: <[e-mail]>
Date: Mon, 17 Nov 2003 09:13:22 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Santosh Chokhani <[e-mail]>
CC: [e-mail]
Subject: Re: Comments on draft-ietf-pkix-sim-01
References: <000b01c3ac43$b20a9490$[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id hAH8DRkT083812
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,

> Denis:
> 
> "R" also helps with adversary finding out some SII when an off-line,
> exhaustive dictionary attack is conducted.  With "R" in there, the adversary
> has to attack each certificate.  Without "R", the adversary can try random
> SII and if it matches a certificate, he has accomplished something.

As I said, this depends of the length of the SII, i.e. the difficulty to 
guess it. So R should be optional.

Denis


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Denis Pinkas
> Sent: Friday, November 14, 2003 4:32 AM
> To: Jongwook, Park
> Cc: [e-mail]; [e-mail]; Russ Housley; [e-mail]; Bill
> Burr; [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> Subject: Re: Comments on draft-ietf-pkix-sim-01
> 
> 
> 
> Park,
> 
> Thank you for the explanations.
> 
> 
>>Denis:
>>
>>I think you catch on the basic idea of this draft exactly. Generally,
>>the DN in the 'subject' or 'subjectAltName' extension must be unique 
>>for each person. However, it is very difficult to identify that the 
>>subject of certificates is in fact the right person issued by CA since 
>>many people often have the same name.
>>
>>To solve the above problem, this document don't use the DN for
>>including the non-public data since the information in DN can't meet 
>>the requirement and is likely to disclosing private data. 
>>Alternatively, this draft proposes the PII(Privacy Identification 
>>Information) structure which is encrypted form of any sensitive 
>>identifier and finally put into the 'subjectAltName' 'GeneralizedName' 
>>'otherName' field. This way can be regarded as a complementary method 
>>for the shortcoming of the DN.
>>
>>PII structure is defined as follows :
>>
>>PII = H(R || SIItype || H (R || P || SII))
>>where R : 160-bit random number, P : Password, SII : Sensitive
>>Identification Identifier and H : Cryptographically secure hash 
>>function such as SHA-1, not MD2 or MD5.
>>
>>PII structure can be applied to the various situations in different
>>ways in accordance with the RP's security environments. Please refer 
>>to the section 5. Example Usage of PII of the draft for details. As a 
>>first example, let us suppose the RP already know the SII of the 
>>certificate holder via out of band. In this case, certificate holder 
>>should send R, P and his certificate containing the PII. Then RP can 
>>figure out if the PII in cert and another PII' calculated itself from 
>>R, P and SII already obtained are identical or not. It is definitely 
>>clear that R and P should be transmitted in a secure channel.
> 
> 
> R is only needed, if the SII is too short, to optionnally hide the value of 
> SII by preventing guessing attacks. If the SII value is long enough, then R 
> is no more needed. So R should be optional.
> 
> In the ASN.1 description of the SIM :
> 
>   - 1°  the SIItype field is missing,
>   - 2°  R should be OPTIONAL,
>   - 3°  an indicator should added to say whether or not
>         a password is required in the computation.
> 
> Note: if neither R and P are present and the SII is long enough, then we 
> have the proposal I made in my previous e-mail:
> 
> Include in the certificate a hash of "personal information" that can be
> revealed by the certificate holder and thus any relying party to which this
> information is disclosed can verify it (usually once).
> 
> Denis
> 
> 
> 
> 
>>For another example, suppose such context where some people don't
>>really want to divulge any hint of his sensitive identifier to RPs. 
>>Maybe it's a kind of same case why we need the Proof of Possession 
>>(POP) in RFC2510. Anyway, please note the PII is the double-hashed 
>>structure. That is to say, the subject send only intermediate value, 
>>H(R || P || SII) to RP without disclosing the SII. Then relying party 
>>can calculates H ( R || SIItype || intermediate value) and verifies 
>>whether this value is equal to the PII in the certificate. Finally, RP 
>>can guess the certificate holder has right certificate even if it 
>>doesn't know the value of SII itself.
>>
>>Alike the above procedures, the certificate holder should be send R,
>>P, SII and PII in a cert if the RP doesn't have any information about 
>>the certificate holder. The rest of the verification is similar to the 
>>first two cases.
>>
>>In conclusion, PII structure is cryptographically secure and efficient
>>scheme to protect personal information although it seems to be 
>>complicated at a glance.
>>
>>Best regards,
>>Park.
>>
>>
>>-----Original Message-----
>>From: [e-mail]
>>[mailto:[e-mail]] On Behalf Of Denis Pinkas
>>Sent: Friday, November 07, 2003 3:39 AM
>>To: pkix
>>Subject: Comments on draft-ietf-pkix-sim-01
>>
>>I have always wondered about the goal of this document, since it is
>>not crystal clear.
>>
>>It seems that the goal is to allow a relying party to determine
>>whether the subject of a particular certificate is the right person. 
>>This is currently difficult since there might be not enough 
>>information in the DN and disclosing more information in the DN would 
>>be against privacy.
>>
>>Is it the basic motivation of this document ?
>>
>>There is however an additional property of the "solution" (or is it a
>>real requirement ?) :
>>
>>    Furthermore, the subject can prove to the
>>    relying party that they are associated with a valid identification
>>    with out disclosing the identifier.
>>
>>This requirement is not crystal clear. What is a valid identification
>>? If it is a bank account number, is it a number with the right Luhn 
>>code computation in it and an existing bank identification number in 
>>it ?
>>
>>Now the solution is rather complicated and it can be seen that an
>>encryption channel is required. A high level view of the goal(s?) and 
>>the advantages of the solution is currently missing.
>>
>>There might be a much simpler solution to solve the basic problem that
>>is trying to be solved:
>>
>>Include in the certificate a hash of "personal information" that can
>>be revealed by the certifcate holder and thus any relying party to 
>>which this information is disclosed can verify it (usually once).
>>
>>
>>Denis
>>
>>
>>
>>
>>
> 
> 
> 
> 
> 





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAGFbJkT003549 for <[e-mail]>; Sun, 16 Nov 2003 07:37:19 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAGFbJfp003548 for ietf-pkix-bks; Sun, 16 Nov 2003 07:37:19 -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.10/8.12.8) with ESMTP id hAGFbIkT003542 for <[e-mail]>; Sun, 16 Nov 2003 07:37:18 -0800 (PST) (envelope-from [e-mail])
Received: from wchokhani (18.washington-43rh15rt.dc.dial-access.att.net[12.77.65.18]) by worldnet.att.net (mtiwmhc12) with SMTP id <2003111615370711200coq40e>; Sun, 16 Nov 2003 15:37:07 +0000
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: Comments on draft-ietf-pkix-sim-01
Date: Sun, 16 Nov 2003 10:36:48 -0500
Message-ID: <002401c3ac57$7d42fc20$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
In-Reply-To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id hAGFbJkT003544
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>

Vadim:

This seems secure.  However, if the various certificate issuers used the
same p, q, and g for creating the public value of a given SII, it may offer
an opportunity to link different pseudo identities via the attribute to the
same person.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Vadim Fedukovich
Sent: Saturday, November 15, 2003 9:18 AM
To: Jongwook, Park
Cc: 'Denis Pinkas'; [e-mail]; [e-mail]; Russ Housley;
[e-mail]; Bill Burr; [e-mail]; [e-mail];
[e-mail]; [e-mail]; [e-mail]
Subject: Re: Comments on draft-ietf-pkix-sim-01



Dear Park,

yes PII suggested makes it unpractical trying to learn protected data unless
the password was disclosured to some party to let it verify the binding.
Once sent out, no control is here anymore and the password could be sent
further to other parties, to prove the binding. Maybe one can use proofs of
knowledge instead to stay in control of sensitive information. That is, run
proofs yourself using non-X.509 tools and only include proofs-bootstrapping
data in certificates issued.

For example, to prove the number SII is bound to ID certified one can choose
a new fresh random nonce t and send (C, T) to the verifier:
     C = Hash(ID, p, g, (g^{t * SII} mod p))
     T = g^t mod p
where ID is name/locality/country from the certificate and g is a generator
over prime filed (mod p).

The verifier could test that (T^{SII} mod p) corresponds to C, ID, g, p
Given strong hash function and hard discrete logarithm problem such a prof
should be convincing for the verifier.

Yes, the basic prof above could be running by anyone for any ID so one
should include some (private exponent) number in the verification equation
and include corresponding public value (g^{private} mod p) in the
certificate issued.

One can elaborate providing the whole idea looks acceptable

regards,
Vadim

On Fri, Nov 07, 2003 at 09:27:31PM +0900, Jongwook, Park wrote:
> 
> 
> Denis:
> 
> I think you catch on the basic idea of this draft exactly. Generally, 
> the DN in the 'subject' or 'subjectAltName' extension must be unique 
> for each person. However, it is very difficult to identify that the 
> subject of certificates is in fact the right person issued by CA since 
> many people often have the same name.
> 
> To solve the above problem, this document don't use the DN for 
> including the non-public data since the information in DN can't meet 
> the requirement and is likely to disclosing private data. 
> Alternatively, this draft proposes the PII(Privacy Identification 
> Information) structure which is encrypted form of any sensitive 
> identifier and finally put into the 'subjectAltName' 'GeneralizedName' 
> 'otherName' field. This way can be regarded as a complementary method 
> for the shortcoming of the DN.
> 
> PII structure is defined as follows :
> 
> PII = H(R || SIItype || H (R || P || SII))
> where R : 160-bit random number, P : Password, SII : Sensitive 
> Identification Identifier and H : Cryptographically secure hash 
> function such as SHA-1, not MD2 or MD5.
> 
> PII structure can be applied to the various situations in different 
> ways in accordance with the RP's security environments. Please refer 
> to the section 5. Example Usage of PII of the draft for details. As a 
> first example, let us suppose the RP already know the SII of the 
> certificate holder via out of band. In this case, certificate holder 
> should send R, P and his certificate containing the PII. Then RP can 
> figure out if the PII in cert and another PII' calculated itself from 
> R, P and SII already obtained are identical or not. It is definitely 
> clear that R and P should be transmitted in a secure channel.
> 
> For another example, suppose such context where some people don't 
> really want to divulge any hint of his sensitive identifier to RPs. 
> Maybe it's a kind of same case why we need the Proof of Possession 
> (POP) in RFC2510. Anyway, please note the PII is the double-hashed 
> structure. That is to say, the subject send only intermediate value, 
> H(R || P || SII) to RP without disclosing the SII. Then relying party 
> can calculates H ( R || SIItype || intermediate value) and verifies 
> whether this value is equal to the PII in the certificate. Finally, RP 
> can guess the certificate holder has right certificate even if it 
> doesn't know the value of SII itself.
> 
> Alike the above procedures, the certificate holder should be send R, 
> P, SII and PII in a cert if the RP doesn't have any information about 
> the certificate holder. The rest of the verification is similar to the 
> first two cases.
> 
> In conclusion, PII structure is cryptographically secure and efficient 
> scheme to protect personal information although it seems to be 
> complicated at a glance.
> 
> Best regards,
> Park.
> 
> 
> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Denis Pinkas
> Sent: Friday, November 07, 2003 3:39 AM
> To: pkix
> Subject: Comments on draft-ietf-pkix-sim-01
> 
> I have always wondered about the goal of this document, since it is 
> not crystal clear.
> 
> It seems that the goal is to allow a relying party to determine 
> whether the subject of a particular certificate is the right person. 
> This is currently difficult since there might be not enough 
> information in the DN and disclosing more information in the DN would 
> be against privacy.
> 
> Is it the basic motivation of this document ?
> 
> There is however an additional property of the "solution" (or is it a 
> real requirement ?) :
> 
>     Furthermore, the subject can prove to the
>     relying party that they are associated with a valid identification
>     with out disclosing the identifier.
> 
> This requirement is not crystal clear. What is a valid identification 
> ? If it is a bank account number, is it a number with the right Luhn 
> code computation in it and an existing bank identification number in 
> it ?
> 
> Now the solution is rather complicated and it can be seen that an 
> encryption channel is required. A high level view of the goal(s?) and 
> the advantages of the solution is currently missing.
> 
> There might be a much simpler solution to solve the basic problem that 
> is trying to be solved:
> 
> Include in the certificate a hash of "personal information" that can 
> be revealed by the certifcate holder and thus any relying party to 
> which this information is disclosed can verify it (usually once).
> 
> 
> Denis
> 
> 
> 

-- 
Naina library: http://www.unity.net/~vf/naina_r1.tgz




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAGDFmkT098358 for <[e-mail]>; Sun, 16 Nov 2003 05:15:48 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAGDFmT1098357 for ietf-pkix-bks; Sun, 16 Nov 2003 05:15:48 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mtiwmhc13.worldnet.att.net (mtiwmhc13.worldnet.att.net [204.127.131.117]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAGDFlkT098350 for <[e-mail]>; Sun, 16 Nov 2003 05:15:47 -0800 (PST) (envelope-from [e-mail])
Received: from wchokhani (174.washington-28rh16rt.dc.dial-access.att.net[12.77.43.174]) by worldnet.att.net (mtiwmhc13) with SMTP id <2003111613152311300e21h5e>; Sun, 16 Nov 2003 13:15:24 +0000
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: Comments on draft-ietf-pkix-sim-01
Date: Sun, 16 Nov 2003 08:15:11 -0500
Message-ID: <000b01c3ac43$b20a9490$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
In-Reply-To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id hAGDFlkT098353
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>

Denis:

"R" also helps with adversary finding out some SII when an off-line,
exhaustive dictionary attack is conducted.  With "R" in there, the adversary
has to attack each certificate.  Without "R", the adversary can try random
SII and if it matches a certificate, he has accomplished something.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Denis Pinkas
Sent: Friday, November 14, 2003 4:32 AM
To: Jongwook, Park
Cc: [e-mail]; [e-mail]; Russ Housley; [e-mail]; Bill
Burr; [e-mail]; [e-mail]; [e-mail];
[e-mail]; [e-mail]
Subject: Re: Comments on draft-ietf-pkix-sim-01



Park,

Thank you for the explanations.

> Denis:
> 
> I think you catch on the basic idea of this draft exactly. Generally,
> the DN in the 'subject' or 'subjectAltName' extension must be unique 
> for each person. However, it is very difficult to identify that the 
> subject of certificates is in fact the right person issued by CA since 
> many people often have the same name.
> 
> To solve the above problem, this document don't use the DN for
> including the non-public data since the information in DN can't meet 
> the requirement and is likely to disclosing private data. 
> Alternatively, this draft proposes the PII(Privacy Identification 
> Information) structure which is encrypted form of any sensitive 
> identifier and finally put into the 'subjectAltName' 'GeneralizedName' 
> 'otherName' field. This way can be regarded as a complementary method 
> for the shortcoming of the DN.
> 
> PII structure is defined as follows :
> 
> PII = H(R || SIItype || H (R || P || SII))
> where R : 160-bit random number, P : Password, SII : Sensitive
> Identification Identifier and H : Cryptographically secure hash 
> function such as SHA-1, not MD2 or MD5.
> 
> PII structure can be applied to the various situations in different
> ways in accordance with the RP's security environments. Please refer 
> to the section 5. Example Usage of PII of the draft for details. As a 
> first example, let us suppose the RP already know the SII of the 
> certificate holder via out of band. In this case, certificate holder 
> should send R, P and his certificate containing the PII. Then RP can 
> figure out if the PII in cert and another PII' calculated itself from 
> R, P and SII already obtained are identical or not. It is definitely 
> clear that R and P should be transmitted in a secure channel.

R is only needed, if the SII is too short, to optionnally hide the value of 
SII by preventing guessing attacks. If the SII value is long enough, then R 
is no more needed. So R should be optional.

In the ASN.1 description of the SIM :

  - 1°  the SIItype field is missing,
  - 2°  R should be OPTIONAL,
  - 3°  an indicator should added to say whether or not
        a password is required in the computation.

Note: if neither R and P are present and the SII is long enough, then we 
have the proposal I made in my previous e-mail:

Include in the certificate a hash of "personal information" that can be
revealed by the certificate holder and thus any relying party to which this
information is disclosed can verify it (usually once).

Denis



> For another example, suppose such context where some people don't
> really want to divulge any hint of his sensitive identifier to RPs. 
> Maybe it's a kind of same case why we need the Proof of Possession 
> (POP) in RFC2510. Anyway, please note the PII is the double-hashed 
> structure. That is to say, the subject send only intermediate value, 
> H(R || P || SII) to RP without disclosing the SII. Then relying party 
> can calculates H ( R || SIItype || intermediate value) and verifies 
> whether this value is equal to the PII in the certificate. Finally, RP 
> can guess the certificate holder has right certificate even if it 
> doesn't know the value of SII itself.
> 
> Alike the above procedures, the certificate holder should be send R,
> P, SII and PII in a cert if the RP doesn't have any information about 
> the certificate holder. The rest of the verification is similar to the 
> first two cases.
> 
> In conclusion, PII structure is cryptographically secure and efficient
> scheme to protect personal information although it seems to be 
> complicated at a glance.
> 
> Best regards,
> Park.
> 
> 
> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]] On Behalf Of Denis Pinkas
> Sent: Friday, November 07, 2003 3:39 AM
> To: pkix
> Subject: Comments on draft-ietf-pkix-sim-01
> 
> I have always wondered about the goal of this document, since it is
> not crystal clear.
> 
> It seems that the goal is to allow a relying party to determine
> whether the subject of a particular certificate is the right person. 
> This is currently difficult since there might be not enough 
> information in the DN and disclosing more information in the DN would 
> be against privacy.
> 
> Is it the basic motivation of this document ?
> 
> There is however an additional property of the "solution" (or is it a
> real requirement ?) :
> 
>     Furthermore, the subject can prove to the
>     relying party that they are associated with a valid identification
>     with out disclosing the identifier.
> 
> This requirement is not crystal clear. What is a valid identification
> ? If it is a bank account number, is it a number with the right Luhn 
> code computation in it and an existing bank identification number in 
> it ?
> 
> Now the solution is rather complicated and it can be seen that an
> encryption channel is required. A high level view of the goal(s?) and 
> the advantages of the solution is currently missing.
> 
> There might be a much simpler solution to solve the basic problem that
> is trying to be solved:
> 
> Include in the certificate a hash of "personal information" that can
> be revealed by the certifcate holder and thus any relying party to 
> which this information is disclosed can verify it (usually once).
> 
> 
> Denis
> 
> 
> 
> 
> 






Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAFDF2kT063493 for <[e-mail]>; Sat, 15 Nov 2003 05:15:02 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAFDF2VI063492 for ietf-pkix-bks; Sat, 15 Nov 2003 05:15:02 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from localhost.intranet (cl0.unity.net [195.24.141.128]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAFDDmkT063440 for <[e-mail]>; Sat, 15 Nov 2003 05:14:11 -0800 (PST) (envelope-from [e-mail])
Received: (from vf@localhost) by localhost.intranet (8.9.3/8.8.8/Debian/GNU) id QAA01322; Sat, 15 Nov 2003 16:18:28 +0200
Date: Sat, 15 Nov 2003 16:18:27 +0200
From: Vadim Fedukovich <[e-mail]>
To: "Jongwook, Park" <[e-mail]>
Cc: "'Denis Pinkas'" <[e-mail]>, [e-mail], [e-mail], Russ Housley <[e-mail]>, [e-mail], Bill Burr <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: Comments on draft-ietf-pkix-sim-01
Message-ID: <[e-mail]>
Mail-Followup-To: "Jongwook, Park" <[e-mail]>, 'Denis Pinkas' <[e-mail]>, [e-mail], [e-mail], Russ Housley <[e-mail]>, [e-mail], Bill Burr <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <[e-mail]>; from [e-mail] on Fri, Nov 07, 2003 at 09:27:31PM +0900
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>

Dear Park,

yes PII suggested makes it unpractical trying to learn protected data
unless the password was disclosured to some party to let it verify
the binding. Once sent out, no control is here anymore and the password
could be sent further to other parties, to prove the binding.
Maybe one can use proofs of knowledge instead to stay in control
of sensitive information. That is, run proofs yourself
using non-X.509 tools and only include proofs-bootstrapping data
in certificates issued.

For example, to prove the number SII is bound to ID certified
one can choose a new fresh random nonce t and send (C, T) to the verifier:
     C = Hash(ID, p, g, (g^{t * SII} mod p))
     T = g^t mod p
where ID is name/locality/country from the certificate and g is
a generator over prime filed (mod p).

The verifier could test that (T^{SII} mod p) corresponds to C, ID, g, p
Given strong hash function and hard discrete logarithm problem such a prof
should be convincing for the verifier.

Yes, the basic prof above could be running by anyone for any ID
so one should include some (private exponent) number in the verification
equation and include corresponding public value (g^{private} mod p)
in the certificate issued.

One can elaborate providing the whole idea looks acceptable

regards,
Vadim

On Fri, Nov 07, 2003 at 09:27:31PM +0900, Jongwook, Park wrote:
> 
> 
> Denis:
> 
> I think you catch on the basic idea of this draft exactly. Generally, the DN
> in the 'subject' or 'subjectAltName' extension must be unique for each
> person. However, it is very difficult to identify that the subject of
> certificates is in fact the right person issued by CA since many people
> often have the same name. 
> 
> To solve the above problem, this document don't use the DN for including the
> non-public data since the information in DN can't meet the requirement and
> is likely to disclosing private data. Alternatively, this draft proposes the
> PII(Privacy Identification Information) structure which is encrypted form of
> any sensitive identifier and finally put into the 'subjectAltName'
> 'GeneralizedName' 'otherName' field. This way can be regarded as a
> complementary method for the shortcoming of the DN. 
> 
> PII structure is defined as follows :
> 
> PII = H(R || SIItype || H (R || P || SII))
> where R : 160-bit random number, P : Password, SII : Sensitive
> Identification Identifier and H : Cryptographically secure hash function
> such as SHA-1, not MD2 or MD5.
> 
> PII structure can be applied to the various situations in different ways in
> accordance with the RP's security environments. Please refer to the section
> 5. Example Usage of PII of the draft for details.
> As a first example, let us suppose the RP already know the SII of the
> certificate holder via out of band. In this case, certificate holder should
> send R, P and his certificate containing the PII. Then RP can figure out if
> the PII in cert and another PII' calculated itself from R, P and SII already
> obtained are identical or not. It is definitely clear that R and P should be
> transmitted in a secure channel. 
> 
> For another example, suppose such context where some people don't really
> want to divulge any hint of his sensitive identifier to RPs. Maybe it's a
> kind of same case why we need the Proof of Possession (POP) in RFC2510.
> Anyway, please note the PII is the double-hashed structure. That is to say,
> the subject send only intermediate value, H(R || P || SII) to RP without
> disclosing the SII. Then relying party can calculates H ( R || SIItype ||
> intermediate value) and verifies whether this value is equal to the PII in
> the certificate. Finally, RP can guess the certificate holder has right
> certificate even if it doesn't know the value of SII itself. 
> 
> Alike the above procedures, the certificate holder should be send R, P, SII
> and PII in a cert if the RP doesn't have any information about the
> certificate holder. The rest of the verification is similar to the first two
> cases. 
> 
> In conclusion, PII structure is cryptographically secure and efficient
> scheme to protect personal information although it seems to be complicated
> at a glance.
> 
> Best regards,
> Park.  
> 
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Denis Pinkas
> Sent: Friday, November 07, 2003 3:39 AM
> To: pkix
> Subject: Comments on draft-ietf-pkix-sim-01
> 
> I have always wondered about the goal of this document, since it is not
> crystal clear.
> 
> It seems that the goal is to allow a relying party to determine whether the
> subject of a particular certificate is the right person. This is currently
> difficult since there might be not enough information in the DN and
> disclosing more information in the DN would be against privacy.
> 
> Is it the basic motivation of this document ?
> 
> There is however an additional property of the "solution" (or is it a real
> requirement ?) :
> 
>     Furthermore, the subject can prove to the
>     relying party that they are associated with a valid identification
>     with out disclosing the identifier.
> 
> This requirement is not crystal clear. What is a valid identification ?
> If it is a bank account number, is it a number with the right Luhn code
> computation in it and an existing bank identification number in it ?
> 
> Now the solution is rather complicated and it can be seen that an encryption
> channel is required. A high level view of the goal(s?) and the advantages of
> the solution is currently missing.
> 
> There might be a much simpler solution to solve the basic problem that is
> trying to be solved:
> 
> Include in the certificate a hash of "personal information" that can be
> revealed by the certifcate holder and thus any relying party to which this
> information is disclosed can verify it (usually once).
> 
> 
> Denis
> 
> 
> 

-- 
Naina library: http://www.unity.net/~vf/naina_r1.tgz


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAEM8akT040082 for <[e-mail]>; Fri, 14 Nov 2003 14:08:36 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAEM8aqn040081 for ietf-pkix-bks; Fri, 14 Nov 2003 14:08:36 -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.10/8.12.8) with ESMTP id hAEM8ZkT040070 for <[e-mail]>; Fri, 14 Nov 2003 14:08:35 -0800 (PST) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id hAEM8U9k022914 for <[e-mail]>; Fri, 14 Nov 2003 17:08:31 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p0601020cbbdb01e6dde2@[128.89.89.75]>
Date: Fri, 14 Nov 2003 17:07:32 -0500
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: draft meeting minutes
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
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>

Folks,

here are draft minutes from this week's PKIX WG meeting at the 58th IETF.

Please provide comments next week, so that I can submit a final 
version before Thanksgiving.  (that's Nov 27th, for non Turkey 
eaters).

Steve
------------------

PKIX WG Meeting 11/9/03

Edited by Steve Kent

Chairs: Stephen Kent <[e-mail]>, Tim Polk <[e-mail]>

The PKIX WG met once during the 58th IETF. A total of approximately 
73 individuals participated in the meeting.


Agenda review and document status - Tim Polk (NIST)
	There are a number of WG documents in various stages in the 
process. Two RFcs (3628 & 3647) were issued since the last IETF 
meeting.  Three documents (Permanent Identifiers, CMP and CRMF) will 
be revised based on IESG comments. The Logotypes I-D has been revised 
in response to IESG comments and should be approved soon. The Proxy 
Certificates and IP Addresses & AS Identifiers I-Ds are in the hands 
of the IESG. Five documents are close to emerging from the WG. SCVP 
is being revised to reflect WSG last call comments. Attribute 
Certificate Policies is in WG last call, but there is some about re 
support for the document. A straw poll on the document indicated a 
little support for progressing the I-D, but mostly just indifference. 
Qualified certificates will enter WG last call after the meeting. The 
EEC "NIST Curves" I-D and the path building I-D also will be forward 
to the ADs by January.

	Ongoing work items include Subject Identification Method 
(SIM), PK algorithms, LDAP specs, OCSPv2, and progression of 
3279/3280. the only new work item is a name comparison spec (to 
address international name issues), an initial draft of which is 
slated for the Seoul meeting. [slides]


PKIX WG Specifications

SIM - Jongwook Park (KISA) & Tim Polk (NIST)
	This specification is still in early stages of development. 
Current efforts are concentrating on formalizing security goals and 
requirements.  The implementation details are still being revised, 
and in some cases appear as a TBD in the current draft. Unresolved 
issues include where to put the hash value, e.g., as an extension vs. 
as an otherName, and some details of the two-pass hashing function. 
[slides]

RFC 3039bis (Qualified Certificates) - Stefan Santesson (Microsoft)
	The QC document is technically stable and incorporates he 
required changes for 3280 alignment.  Minor issues remain for the 
ASN.1 in the document; the AD has provided clear guidance for 
resolution. Three issues raised on the list (regarding the document 
name, timeline for progression, and its relationship to RFC 3039) 
were also discussed. The WG chairs and the AD indicated that WG Last 
Call is appropriate at this time, and that the new specification 
should obsolete RFC 3039.

Certificate Path Building  - Peter Hesse (Orion Security)
       This document, intended to become an informational RFC, was 
written to provide guidance and recommendations to developers 
building X.509 public-key certification paths within their 
applications, based on experience gained in several contexts. The 
document describes different PKI structures, considerations for 
forward vs. reverse path construction, tree pruning, etc. emphasis on 
value of disallowing repeated name/key combination in a path. 
Guidance is based on experience with various products, but must 
describe processes that are consistent with PKIX RFCs. This is just 
an advisory document, not proscriptive, and so there will be no 
MUSTs, SHOULDS, etc. Plan to release another version of the document 
by the end of this month, then proceed to WG last call. [slides]

OCSPv1 problem - Mike Meyers (Traceroute)
	OCSP has a facility in which a client may include a nonce in 
a request, to detect and reject replays of responses. Unfortunately, 
the RFC did not make perfectly clear that a client MUST reject a 
response that did not include a nonce, if the client included a nonce 
in the request. Similarly, the RFC did not make clear what a server 
should do if it receives a request with a nonce, but is incapable of 
generating a response containing a nonce, i.e., a server that deals 
only with pre-signed responses.
	A straw poll indicated that the vast majority of clients deal 
with these issues properly, but not all. OCSP servers that rely on 
caching do not generate a unique response for each request, so they 
omit nonces.  An error could be returned by a server to indicate the 
inability to respond properly to a request with a nonce, but errors 
are not signed, so this does not address the security concern.
	Russ Housley, the cognizant AD made the following observation 
re this issue. "When an OCSP Client puts a nonce in an OCSP Request, 
replay protection is expected. Therefore, the OCSP Responder MUST 
include the same nonce value in the OCSP Response.  If the OCSP 
Client receives an OCSP Response that fails to include the correct 
nonce value, it MUST be rejected."


Liaison/Related Projects

IPsec PKI Profile - Brian Korver (Xythos Software)
	Announcement of a BOF on this topic on Thursday, 9 AM.

Steve Hanna (Sun) - OASIS PKI Obstacles Survey Report
	Steve is the co-chair of the OASIS PKI technical committee. 
Effort is trying to determine obstacles to successful PKI deployment 
and adoption, and to recommend ways to eliminate these obstacles. 
Survey generated 200 responses. Most significant obstacles include:
- lack of application support
- high costs
- complexity, lack of understanding
- interoperability problems

Suggested fixes include:
- free software
- cookbook deployment guidance
- path validation guidance
- too many standards for some function, too general, not enough 
standards for other functions

Action plan now available for public review. [slides]


Path Validation Conformance Tests - Tim Polk [NIST]
	A suite of tests has been developed by NIST and several 
contractors, designed to ensure that products implement RFC 3280 
properly. It is an extensive suite of tests. NIST's goals are to 
encourage vendors to submit products for testing, and for users to 
demand products that pass the tests. Common Criteria Protection 
Profiles have been created, based on these tests, in an effort to 
achieve the goal noted above. These profiles should be validated and 
available for use by the end of 2003.  [slides]




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAEJAgkT028390 for <[e-mail]>; Fri, 14 Nov 2003 11:10:42 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAEJAgd6028389 for ietf-pkix-bks; Fri, 14 Nov 2003 11:10:42 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from vahqex2.gfgsi.com (netva01.getronicsgov.com [67.105.229.98]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAEJAYkT028335; Fri, 14 Nov 2003 11:10:34 -0800 (PST) (envelope-from [e-mail])
Received: from digitalnet.com ([158.189.2.70]) by vahqex2.gfgsi.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 14 Nov 2003 14:10:36 -0500
Message-ID: <[e-mail]>
Date: Fri, 14 Nov 2003 14:10:35 -0500
From: Matt Bertapelle <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: imc-cml <[e-mail]>, imc-sfl <[e-mail]>, [e-mail]
Subject: v2.3 Certificate Management Library (CML) Now Available
Content-Type: multipart/alternative; boundary="------------040902040404060909050006"
X-OriginalArrivalTime: 14 Nov 2003 19:10:36.0110 (UTC) FILETIME=[FBD866E0:01C3AAE2]
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.
--------------040902040404060909050006
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

All,

DigitalNet Government Solutions has delivered the Version 2.3 Certificate Management Library (CML) for Microsoft Windows, Sun Solaris and Linux.  The v2.3 CML and documentation is freely available at:
<http://www.digitalnet.com/knowledge/cml_home.htm>.  

Applications requiring Public Key Infrastructure (PKI) security 
services can use the CML to meet their X.509 certificate and 
Certificate Revocation List (CRL) processing requirements.  
The v2.3 CML is described in the v2.3 CML Application Programming
Interface (API) document.  It implements the 2000 X.509 Recommendation
certification path verification processing rules and SDN.706 profile.
It meets the majority of the IETF PKIX RFC 3280 Certificate/CRL Profile
requirements.  There are some unsupported features such as 
Delta CRLs.  The v2.3 CML Abstract Syntax Notation One (ASN.1)
decodes X.509 Certificates and CRLs.  It requires the v1.6
Enhanced SNACC ASN.1 software that is freely available from:
<http://www.digitalnet.com/knowledge/snacc_home.htm>.

The CML provides robust certification path building capabilities such
as using cross certificates.  The CML uses the accompanying Storage 
and Retrieval Library (SRL) (optionally) to provide local certificate
and CRL storage management functions.  The SRL (optionally) provides 
remote directory retrieval capabilities using the Lightweight
Directory Access Protocol (LDAP).

The CML has been thoroughly tested including validating X.509 
Certificates and CRLs created by a variety of Certification 
Authority (CA) products, and signed using the Digital Signature
Algorithm (DSA) and RSA algorithms.  Further enhancements, 
ports and testing of the CML are still in process.  Further
releases of the CML will be provided as significant 
capabilities are added. 

CML v2.3 includes the following enhancements (compared to v2.2 
CML release):

1) Added optional bitmask field to the InitSettings_struct to allow the application to specify which CTILs the CML should load during CM_CreateSessionExt().  The application can use this bitmask field rather than pass in a pointer to a valid CTIL::CSM_CtilMgr object in the pTokenObj field of the InitSettings_struct. 


2) Created new C++ function, CML::SetTrustAnchors(), to allow an 
application to specify the trusted public keys for a CML session even 
when the trusted keys don't appear in certificates.

3) Created new C++ class, TrustAnchor, that allows the the application 
to optionally specify additional path validation constraints on each 
trust anchor when calling CML::SetTrustAnchors().  The additional 
constraints that may be specified are the maximum path length to accept 
and the name constraints to apply. 

4) Enhanced the CML cache and session code to be thread-safe.  
Applications may now safely share a single CML session amongst multiple 
threads. 

5) Enhanced CML to check name constraints of email addresses included in 
DNs.

6) Optimized CML path building algorithm for use with the Federal Bridge 
Certification Authority (FBCA) hierarchy.

7) Added two new fields to the C++ CertMatchData structure, canSignCerts 
and canSignCrls.  These new fields enable callers of the 
CML::RequestCerts() C++ function to optionally restrict the certificates 
returned to having those key usage privileges.

8) Fixed bug in the policy mapping processing of path validation.  The 
CML wasn't properly rejecting paths when the special /any-policy/ value 
appeared in a policy mappings extension.

9) Enhanced CRL retrieval and validation code so the CML will now 
retrieve and validate multiple CRLs if necessary to check all revocation 
reasons, even when no distribution point is present in the certificate.  
Previous versions of the CML would only check a single complete CRL if 
no distribution point was present.

10) Added ECDSA-with-SHA256 and ECDSA-with-SHA384 to list of CML 
supported signature algorithms.


v2.3 SRL includes the following enhancements (compared to v2.2 SRL release):

1) Enhanced SRL to perform HTTP and FTP URL retrievals.

2) Removed SRL code that caused some UNIX systems to hang
under certain circumstances when performing an LDAP bind.  With the
removal of the offending code, the SRL now relies completely on the LDAP
library to timeout when an LDAP server is unreachable during a bind
operation.  During testing, some LDAP libraries would take up to 3 minutes
to return from an LDAP bind when the server was down or unreachable.


All source code for the CML is being provided at no cost and with no financial limitations regarding its use and distribution. Organizations can use the CML without paying any royalties or licensing fees.  The CML was originally developed by the U.S. Government.  DigitalNet is enhancing and supporting the CML under contract to the U.S. Government.  The U.S. Government is furnishing the CML software at no cost to the vendor subject to the conditions of the CML Public License provided with the CML software.  

The CML makes calls to an algorithm-independent CTIL API that provides
access to a variety of external crypto libraries. There is a CTIL for
each crypto library that maps the generic CTIL API calls to the
specific calls for that crypto library. DigitalNet provides CTILs for
the Microsoft CAPI v2.0, Crypto++, RSA BSAFE, Spyrus SPEX/ and
FORTEZZA Cryptologic Interface libraries. DigitalNet also provides a
PKCS #11 CTIL that enables PKCS #11-compliant libraries to be used
with the CML. The underlying, external crypto libraries are not
distributed as part of the CML software.


The CML has been successfully tested with the v2.3 S/MIME Freeware
Library (SFL) that is freely available from
<http://www.DigitalNet.com/knowledge/sfl_home.htm>.

The CML has been successfully tested with the v2.3 Access Control
Library (ACL) that is freely available to everyone from:
<http://www.DigitalNet.com/knowledge/acl_home.htm>.

The CML has been successfully used to build and verify
certificate paths used in the Bridge Certification Authority (BCA)
demonstration which includes cross-certified hierarchical and non-
hierarchical PKIs. The BCA Interoperability Test Suite (BITS)
is a free and openly available test resource provided to
facilitate vendor development of secure, interoperable Public
Key Enabled applications. The CML has been used to successfully
develop and verify the BITS X.509 certification paths available
from <http://bcatest.atl.DigitalNet.com>.

The National Institute of Standards and Technology (NIST) is
providing a standard test suite of X.509 certificate paths
<http://csrc.nist.gov/pki/testing/x509paths.html> that can be
used for testing applications against RFC 2459. The CML was
used to successfully process the NIST test data.

The CML meets the requirements stated in the SDN.706 Certificate/
CRL Profile required by the U.S. Defense Message System (DMS)
project.

The Internet Mail Consortium (IMC) has established a CML web page
<http://www.imc.org/imc-cml> and a CML mail list which is used to:
distribute information regarding CML releases; discuss CML-related
issues; and allow CML users to provide feedback, comments, bug
reports, etc. Subscription information for the imc-cml mailing list
is at the IMC web site listed above.

All comments regarding the CML source code and documents are welcome.
This CML release announcement was sent to several mail lists, but
please send all messages regarding the CML to the imc-cml mail list
ONLY. Please do not send messages regarding the CML to any of the IETF
mail lists. We will respond to all messages sent to the imc-cml mail
list.

-- 
Matthew J. Bertapelle
DigitalNet Government Solution, LLC
www.DigitalNet.com


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

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
<pre wrap="">All,

DigitalNet Government Solutions has delivered the Version 2.3 Certificate Management Library (CML) for Microsoft Windows, Sun Solaris and Linux.  The v2.3 CML and documentation is freely available at:
<a class="moz-txt-link-rfc2396E"
 href="http://www.digitalnet.com/hot/cml_home.htm">&lt;http://www.digitalnet.com/knowledge/cml_home.htm&gt;</a>.  

Applications requiring Public Key Infrastructure (PKI) security 
services can use the CML to meet their X.509 certificate and 
Certificate Revocation List (CRL) processing requirements.  
The v2.3 CML is described in the v2.3 CML Application Programming
Interface (API) document.  It implements the 2000 X.509 Recommendation
certification path verification processing rules and SDN.706 profile.
It meets the majority of the IETF PKIX RFC 3280 Certificate/CRL Profile
requirements.  There are some unsupported features such as 
Delta CRLs.  The v2.3 CML Abstract Syntax Notation One (ASN.1)
decodes X.509 Certificates and CRLs.  It requires the v1.6
Enhanced SNACC ASN.1 software that is freely available from:
<a class="moz-txt-link-rfc2396E"
 href="http://www.digitalnet.com/hot/snacc_home.htm">&lt;http://www.digitalnet.com/knowledge/snacc_home.htm&gt;</a>.

The CML provides robust certification path building capabilities such
as using cross certificates.  The CML uses the accompanying Storage 
and Retrieval Library (SRL) (optionally) to provide local certificate
and CRL storage management functions.  The SRL (optionally) provides 
remote directory retrieval capabilities using the Lightweight
Directory Access Protocol (LDAP).

The CML has been thoroughly tested including validating X.509 
Certificates and CRLs created by a variety of Certification 
Authority (CA) products, and signed using the Digital Signature
Algorithm (DSA) and RSA algorithms.  Further enhancements, 
ports and testing of the CML are still in process.  Further
releases of the CML will be provided as significant 
capabilities are added. 

CML v2.3 includes the following enhancements (compared to v2.2 
CML release):
<tt>
</tt>1) Added optional bitmask field to the InitSettings_struct to allow the application to specify which CTILs the CML should load during CM_CreateSessionExt().&nbsp; The application can use this bitmask field rather than pass in a pointer to a valid CTIL::CSM_CtilMgr object in the pTokenObj field of the InitSettings_struct. 
</pre>
<tt><o:p></o:p><br>
2) Created new C++ function, CML::SetTrustAnchors(), to
allow an application to specify the trusted public keys for a CML
session even
when the trusted keys don't appear in certificates. <o:p></o:p><br>
<o:p></o:p><br>
3) Created new C++ class, TrustAnchor, that allows the the
application to optionally specify additional path validation
constraints on
each trust anchor when calling CML::SetTrustAnchors().&nbsp; The additional
constraints that may be specified are the maximum path length to accept
and the
name constraints to apply.&nbsp;<o:p></o:p><br>
<o:p></o:p><br>
4) Enhanced the CML cache and session code to be thread-safe.&nbsp;
Applications may now safely share a single CML session amongst multiple
threads.&nbsp;<br>
<o:p></o:p><br>
5) Enhanced CML to check name constraints of email addresses
included in DNs. <o:p></o:p><br>
<o:p></o:p><br>
6) Optimized CML path building algorithm for use with the
Federal Bridge Certification Authority (FBCA) hierarchy.<o:p><br>
</o:p><br>
<o:p></o:p>7) Added two new fields to the C++ CertMatchData structure,
canSignCerts and canSignCrls.&nbsp; These new fields enable callers of the
CML::RequestCerts() C++ function to optionally restrict the
certificates
returned to having those key usage privileges.<o:p></o:p>
<br>
<o:p></o:p><br>
8) Fixed bug in the policy mapping processing of path
validation.&nbsp; The CML wasn't properly rejecting paths when the special <i>any-policy</i>
value appeared in a policy mappings extension.<o:p><br>
</o:p><br>
<o:p></o:p>9) Enhanced CRL retrieval and validation code so the CML
will now retrieve and validate multiple CRLs if necessary to check all
revocation reasons, even when no distribution point is present in the
certificate.&nbsp; Previous versions of the CML would only check a single
complete CRL if no distribution point was present.<o:p><br>
</o:p><br>
<o:p></o:p>10) Added ECDSA-with-SHA256 and ECDSA-with-SHA384 to list of
CML supported signature algorithms.<o:p></o:p>
<br>
<o:p><br>
</o:p><br>
<o:p></o:p>v2.3 SRL includes the following enhancements (compared to
v2.2 SRL release):<br>
</tt>
<pre wrap=""><tt></tt><tt>1) Enhanced SRL to perform HTTP and FTP URL retrievals.<o:p></o:p>
<o:p></o:p>
2) Removed SRL code that caused some UNIX systems to hang
under certain circumstances when performing an LDAP bind.&nbsp; With the
removal of the offending code, the SRL now relies completely on the LDAP
library to timeout when an LDAP server is unreachable during a bind
operation.&nbsp; During testing, some LDAP libraries would take up to 3 minutes
to return from an LDAP bind when the server was down or unreachable.<o:p></o:p>
</tt>

All source code for the CML is being provided at no cost and with no<tt> </tt>financial limitations regarding its use and distribution. Organizations can use the CML without paying any royalties or licensing fees.  The CML was originally developed by the U.S. Government.  DigitalNet is enhancing and supporting the CML under contract to the U.S. Government.  The U.S. Government is furnishing the CML software at no cost to the vendor subject to the conditions of the CML Public License provided with the CML software.  
</pre>
<tt>The CML makes calls to an algorithm-independent CTIL API that
provides<br>
access to a variety of external crypto libraries. There is a CTIL for <br>
each crypto library that maps the generic CTIL API calls to the <br>
specific calls for that crypto library. DigitalNet provides CTILs for<br>
the Microsoft CAPI v2.0, Crypto++, RSA BSAFE, Spyrus SPEX/ and <br>
FORTEZZA Cryptologic Interface libraries. DigitalNet also provides a <br>
PKCS #11 CTIL that enables PKCS #11-compliant libraries to be used <br>
with the CML. The underlying, external crypto libraries are not <br>
distributed as part of the CML software. <br>
<br>
<br>
The CML has been successfully tested with the v2.3 S/MIME Freeware <br>
Library (SFL) that is freely available from <br>
<a class="moz-txt-link-rfc2396E"
 href="http://www.DigitalNet.com/hot/sfl_home.htm">&lt;http://www.DigitalNet.com/knowledge/sfl_home.htm&gt;</a>.
<br>
<br>
The CML has been successfully tested with the v2.3 Access Control <br>
Library (ACL) that is freely available to everyone from: <br>
<a class="moz-txt-link-rfc2396E"
 href="http://www.DigitalNet.com/hot/acl_home.htm">&lt;http://www.DigitalNet.com/</a><a
 href="http://www.DigitalNet.com/hot/sfl_home.htm"
 class="moz-txt-link-rfc2396E">knowledge/</a><a
 class="moz-txt-link-rfc2396E"
 href="http://www.DigitalNet.com/hot/acl_home.htm">acl_home.htm&gt;</a>.<br>
<br>
The CML has been successfully used to build and verify <br>
certificate paths used in the Bridge Certification Authority (BCA)<br>
demonstration which includes cross-certified hierarchical and non-<br>
hierarchical PKIs. The BCA Interoperability Test Suite (BITS)<br>
is a free and openly available test resource provided to <br>
facilitate vendor development of secure, interoperable Public<br>
Key Enabled applications. The CML has been used to successfully<br>
develop and verify the BITS X.509 certification paths available<br>
from <a class="moz-txt-link-rfc2396E"
 href="http://bcatest.atl.DigitalNet.com">&lt;http://bcatest.atl.DigitalNet.com&gt;</a>.
<br>
<br>
The National Institute of Standards and Technology (NIST) is <br>
providing a standard test suite of X.509 certificate paths<br>
<a class="moz-txt-link-rfc2396E"
 href="http://csrc.nist.gov/pki/testing/x509paths.html">&lt;http://csrc.nist.gov/pki/testing/x509paths.html&gt;</a>
that can be<br>
used for testing applications against RFC 2459. The CML was <br>
used to successfully process the NIST test data.<br>
<br>
The CML meets the requirements stated in the SDN.706 Certificate/<br>
CRL Profile required by the U.S. Defense Message System (DMS) <br>
project.<br>
<br>
The Internet Mail Consortium (IMC) has established a CML web page<br>
<a class="moz-txt-link-rfc2396E" href="http://www.imc.org/imc-cml">&lt;http://www.imc.org/imc-cml&gt;</a>
and a CML mail list which is used to: <br>
distribute information regarding CML releases; discuss CML-related <br>
issues; and allow CML users to provide feedback, comments, bug <br>
reports, etc. Subscription information for the imc-cml mailing list <br>
is at the IMC web site listed above. <br>
<br>
All comments regarding the CML source code and documents are welcome. <br>
This CML release announcement was sent to several mail lists, but<br>
please send all messages regarding the CML to the imc-cml mail list<br>
ONLY. Please do not send messages regarding the CML to any of the IETF<br>
mail lists. We will respond to all messages sent to the imc-cml mail <br>
list.</tt>
<pre cols="72" class="moz-signature">-- 
Matthew J. Bertapelle
DigitalNet Government Solution, LLC
<a class="moz-txt-link-abbreviated" href="http://www.DigitalNet.com">www.DigitalNet.com</a></pre>
</body>
</html>

--------------040902040404060909050006--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAE9WYkT085996 for <[e-mail]>; Fri, 14 Nov 2003 01:32:34 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAE9WXGf085995 for ietf-pkix-bks; Fri, 14 Nov 2003 01:32:33 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAE9WUkT085965 for <[e-mail]>; Fri, 14 Nov 2003 01:32:31 -0800 (PST) (envelope-from [e-mail])
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id KAA30070; Fri, 14 Nov 2003 10:38:22 +0100
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id KAA20743; Fri, 14 Nov 2003 10:33:54 +0100
Message-ID: <[e-mail]>
Date: Fri, 14 Nov 2003 10:31:47 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: "Jongwook, Park" <[e-mail]>
CC: [e-mail], [e-mail], Russ Housley <[e-mail]>, [e-mail], Bill Burr <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: Comments on draft-ietf-pkix-sim-01
References: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id hAE9WWkT085980
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>

Park,

Thank you for the explanations.

> Denis:
> 
> I think you catch on the basic idea of this draft exactly. Generally, the DN
> in the 'subject' or 'subjectAltName' extension must be unique for each
> person. However, it is very difficult to identify that the subject of
> certificates is in fact the right person issued by CA since many people
> often have the same name. 
> 
> To solve the above problem, this document don't use the DN for including the
> non-public data since the information in DN can't meet the requirement and
> is likely to disclosing private data. Alternatively, this draft proposes the
> PII(Privacy Identification Information) structure which is encrypted form of
> any sensitive identifier and finally put into the 'subjectAltName'
> 'GeneralizedName' 'otherName' field. This way can be regarded as a
> complementary method for the shortcoming of the DN. 
> 
> PII structure is defined as follows :
> 
> PII = H(R || SIItype || H (R || P || SII))
> where R : 160-bit random number, P : Password, SII : Sensitive
> Identification Identifier and H : Cryptographically secure hash function
> such as SHA-1, not MD2 or MD5.
> 
> PII structure can be applied to the various situations in different ways in
> accordance with the RP's security environments. Please refer to the section
> 5. Example Usage of PII of the draft for details.
> As a first example, let us suppose the RP already know the SII of the
> certificate holder via out of band. In this case, certificate holder should
> send R, P and his certificate containing the PII. Then RP can figure out if
> the PII in cert and another PII' calculated itself from R, P and SII already
> obtained are identical or not. It is definitely clear that R and P should be
> transmitted in a secure channel. 

R is only needed, if the SII is too short, to optionnally hide the value of 
SII by preventing guessing attacks. If the SII value is long enough, then R 
is no more needed. So R should be optional.

In the ASN.1 description of the SIM :

  - 1°  the SIItype field is missing,
  - 2°  R should be OPTIONAL,
  - 3°  an indicator should added to say whether or not
        a password is required in the computation.

Note: if neither R and P are present and the SII is long enough, then we 
have the proposal I made in my previous e-mail:

Include in the certificate a hash of "personal information" that can be
revealed by the certificate holder and thus any relying party to which this
information is disclosed can verify it (usually once).

Denis



> For another example, suppose such context where some people don't really
> want to divulge any hint of his sensitive identifier to RPs. Maybe it's a
> kind of same case why we need the Proof of Possession (POP) in RFC2510.
> Anyway, please note the PII is the double-hashed structure. That is to say,
> the subject send only intermediate value, H(R || P || SII) to RP without
> disclosing the SII. Then relying party can calculates H ( R || SIItype ||
> intermediate value) and verifies whether this value is equal to the PII in
> the certificate. Finally, RP can guess the certificate holder has right
> certificate even if it doesn't know the value of SII itself. 
> 
> Alike the above procedures, the certificate holder should be send R, P, SII
> and PII in a cert if the RP doesn't have any information about the
> certificate holder. The rest of the verification is similar to the first two
> cases. 
> 
> In conclusion, PII structure is cryptographically secure and efficient
> scheme to protect personal information although it seems to be complicated
> at a glance.
> 
> Best regards,
> Park.  
> 
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Denis Pinkas
> Sent: Friday, November 07, 2003 3:39 AM
> To: pkix
> Subject: Comments on draft-ietf-pkix-sim-01
> 
> I have always wondered about the goal of this document, since it is not
> crystal clear.
> 
> It seems that the goal is to allow a relying party to determine whether the
> subject of a particular certificate is the right person. This is currently
> difficult since there might be not enough information in the DN and
> disclosing more information in the DN would be against privacy.
> 
> Is it the basic motivation of this document ?
> 
> There is however an additional property of the "solution" (or is it a real
> requirement ?) :
> 
>     Furthermore, the subject can prove to the
>     relying party that they are associated with a valid identification
>     with out disclosing the identifier.
> 
> This requirement is not crystal clear. What is a valid identification ?
> If it is a bank account number, is it a number with the right Luhn code
> computation in it and an existing bank identification number in it ?
> 
> Now the solution is rather complicated and it can be seen that an encryption
> channel is required. A high level view of the goal(s?) and the advantages of
> the solution is currently missing.
> 
> There might be a much simpler solution to solve the basic problem that is
> trying to be solved:
> 
> Include in the certificate a hash of "personal information" that can be
> revealed by the certifcate holder and thus any relying party to which this
> information is disclosed can verify it (usually once).
> 
> 
> Denis
> 
> 
> 
> 
> 





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hADDYpkT056638 for <[e-mail]>; Thu, 13 Nov 2003 05:34:51 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hADDYp25056637 for ietf-pkix-bks; Thu, 13 Nov 2003 05:34:51 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from iscan01.secomtrust.net (iscan01.secomtrust.net [61.114.177.102]) by above.proper.com (8.12.10/8.12.8) with SMTP id hADDYmkT056631 for <[e-mail]>; Thu, 13 Nov 2003 05:34:49 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 2818 invoked by alias); 13 Nov 2003 13:34:47 -0000
Delivered-To: [e-mail]@MAP
Received: (qmail 2810 invoked by alias); 13 Nov 2003 13:34:47 -0000
Received: from localhost (HELO mail.secomtrust.net) (127.0.0.1) by localhost with SMTP; 13 Nov 2003 13:34:47 -0000
Received: (qmail 24008 invoked from network); 13 Nov 2003 13:34:46 -0000
Received: from unknown (HELO ?130.129.68.231?) (172.30.253.102) by mail with SMTP; 13 Nov 2003 13:34:46 -0000
Date: Thu, 13 Nov 2003 22:35:11 +0900
From: Masaki SHIMAOKA <[e-mail]>
To: Tim Polk <[e-mail]>, IETF-PKIX <[e-mail]>
Subject: [I-D] Revised multi-domain PKI interoperability
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Message-Id: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Becky! ver. 2.06.02
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>

Tim and all,

I revised my personal I-D "Memorandum for multi-domain PKI
interoperability". Sorry for my late announcement.

Major changes are the following:
- Add the figures
    + Structure of multi-domain PKI
    + Each PKI model
- Terminology and Assumptions
    + Modify some terminology
    + Assumptions for Repository
- Define PKI Domain 
    + Add new section
- Modify a definition of some PKI model
    + Cross-Certification model
    + Subordination model
    + Hub model
- Consider for trusted third CA
    + Trusted Third CA in Hub model and Super domain model
- Security Considerations
    + Certificate and CRL Profile
    + Some asymmetric problem

The I-D has already published on IETF repository, and it can be also
obtained from our JNSA web site with the detail ChangeLog.

Please refer the following URLs:
Our website:
    http://www.jnsa.org/mpki/
Newest I-D:
    http://www.jnsa.org/mpki/draft-shimaoka-multidomain-pki-01.txt
ChangeLog:
    http://www.jnsa.org/mpki/ChangeLog-en20031027r1.ppt
Original Presentation on 57thIETF:
    http://www.ietf.org/proceedings/03jul/slides/pkix-9/index.html

When I revise some minor issues like typo, I will update to our site.
And next major revise (update it in IETF repository) will be by the end
of December.

If you are interested in this, please let me know.
Thanks in advance for any comments.


Abstract of this I-D is shown as below.

	Title		: Memorandum for multi-domain PKI Interoperability
	Author(s)	: M. Shimaoka
	Filename	: draft-shimaoka-multidomain-pki-01.txt
	Pages		: 26
	Date		: October 2003

===== Abstract =====
This memo is used to share the awareness necessary to deployment of
multi-domain PKI. Scope of this memo is to establish trust
relationship and interoperability between plural PKI domains.  Both
single-domain PKI and multi-domain PKI are established by the trust
relationships between Certification Authorities (CAs).  Typical and
primitive PKI models are specified as single-domain PKI.  Multi-
domain PKI established by plural single-domain PKI is categorized as
multi-trust point model and single-trust point model. Multi-trust
point model is based on trust list model, and single-trust point
model is based on cross-certification.
===== Abstract =====

Rgds,
shima

-----
Masaki SHIMAOKA

SECOM Trust.net
System Engineering Dpt.
Tel: [phone] (ext.3605)
Fax: [phone]
e-mail: [e-mail]



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hACKGPkT041157 for <[e-mail]>; Wed, 12 Nov 2003 12:16:25 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hACKGPqN041156 for ietf-pkix-bks; Wed, 12 Nov 2003 12:16:25 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hACKGOkT041149 for <[e-mail]>; Wed, 12 Nov 2003 12:16:24 -0800 (PST) (envelope-from [e-mail])
Received: from ROMANS (dyn070-253.ietf58.ietf.org [130.129.70.253]) by smtp2.pacifier.net (Postfix) with ESMTP id 1D0066ADD2; Wed, 12 Nov 2003 12:16:13 -0800 (PST)
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: <[e-mail]>, "Tim Polk" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Last Call: Qualified Certificates
Date: Wed, 12 Nov 2003 14:18:41 -0600
Message-ID: <004c01c3a95a$342ad940$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
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>

Comments on this draft are as follows:

1.  Section 1 para 3;  I object to the phrase "private extensions".
This document does not defined private extensions even if they exist in
the id-pe arc.  These are now public extensions. -- Remove the word
private.

2.  Section 1 para 3: Remove all references to 1993 ASN.1

3.  New section 1.1 is required to be added stating the differences
between this document and 3039

4.  Section 2, para 2:   
 	The text "where the certificate meet some qualification
requirements" should be imported to either "certificates meet" or
"certificate meets"

5.  Section 2, bullet item 3:  Suggest new text of  
 	"-  Definition of usage for the key usage extension in Qualified
      Certificates.."

6.  Section 3.2.1 - DateOfBirth SHOULD state the proper encoding to be
used.  I.E. are we looking for seconds, minutes or hours or just DATE in
the GeneralTime field?

7.  Section 3.2.1 - countryOfResidence and countryOfCitizenship - If you
have multiple countrys to be listed, should this be a multi-value item
or should there be two distinct attributes? (Alternatively should this
be restricted back to a single attribute with a single value - i.e you
can only list one of your countries of citizenship.)

8.  Section 3.2.4 - This is something that I have no experence with.  If
you look at a jpeg, bitmap or other type if image, who defines what is
considred to be a label and what is considered to be the image data?
What is done in this case about different sized images?

9.  Section 3.2.5.1 - I would like to know the reason that qcstatement-1
has not been updated to a new OID.  This is a new draft document with
some different semantics than 3039.  Are these changes all suffiently
small that a new policy is not needed?

10. Sectin 3.2.5.1 - I have decided to put the predefined statement into
my QC.  After reading this document I understand that what I want
stearts as follows:

	EXTENSION { id-pe-qcStatements,
			{ id-qcs-pkixQCSyntax-v1, {ABSENT, ? }}
In this case I don't have asemanticsIdentifier created by the document,
so I must be incoluding the NameRegistrationAuthorities otion.  However
I don't know if what goes here is the pkix working group name or some
other value.

11.  Sectin A.1 - I suggest changing the pretty name to
PKIXqualified88-03 to distinquish from rfc3039.



jim



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hABKP2kT019612 for <[e-mail]>; Tue, 11 Nov 2003 12:25:02 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hABKP23x019611 for ietf-pkix-bks; Tue, 11 Nov 2003 12:25:02 -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.240.3]) by above.proper.com (8.12.10/8.12.8) with SMTP id hABKP1kT019606 for <[e-mail]>; Tue, 11 Nov 2003 12:25:01 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 20637 invoked by uid 0); 11 Nov 2003 20:24:48 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (130.129.131.250) by woodstock.binhost.com with SMTP; 11 Nov 2003 20:24:48 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Tue, 11 Nov 2003 15:04:09 -0500
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: Last Call: Qualified Certificates
In-Reply-To: <[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 have 4 comments:

1.  In section 2.1, the 1st and 2nd bullets do not have periods.

2.  In section 2.1, 2nd bullet: s/2.3/section 2.3/

3.  In section 3, change the 1st sentence to: "This section defines the 
certificate profile for Qualified Certificates."

4.  ASN.1 syntax is a problem.  Since RFC 3280 does not have a '97 syntax 
module to IMPORT stuff from, I do not see how this document can include a 
'97 syntax.  I think A.2 should be removed.

Russ



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hABGS2kT008630 for <[e-mail]>; Tue, 11 Nov 2003 08:28:02 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hABGS22h008629 for ietf-pkix-bks; Tue, 11 Nov 2003 08:28:02 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hABGS1kT008624 for <[e-mail]>; Tue, 11 Nov 2003 08:28:01 -0800 (PST) (envelope-from [e-mail])
Received: from calendar.nist.gov (calendar-ether.nist.gov [129.6.16.10]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id hABGRj18029761; Tue, 11 Nov 2003 11:27:45 -0500 (EST)
Received: from calendar.nist.gov (localhost [127.0.0.1]) by calendar.nist.gov (8.12.9-20030924/8.12.9) with ESMTP id hABGRiSm026558; Tue, 11 Nov 2003 11:27:44 -0500 (EST)
Received: (from nobody@localhost) by calendar.nist.gov (8.12.9-20030924/8.12.9/Submit) id hABGRifS026557; Tue, 11 Nov 2003 11:27:44 -0500 (EST)
Received: from 130.129.132.51 ( [130.129.132.51]) as user [e-mail] by imp.nist.gov with HTTP; Tue, 11 Nov 2003 11:27:44 -0500
Message-ID: <[e-mail]>
Date: Tue, 11 Nov 2003 11:27:44 -0500
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: Last Call: Qualified Certificates
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 8bit
User-Agent: Internet Messaging Program (IMP) 2.3.7-cvs
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>

Folks,


This message initiates working group Last Call for the Qualified Certificates 
specification. This is a two week Last Call and is expected to close November 
25. 

** Do not count on any extension to Last Call!!! **

To keep our efforts coordinated with ETSI's schedule, we need to forward this 
document to the ADs as soon as possible.

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

The current draft has two known technical issues: (1) the module number for the 
1988 ASN.1 module was incomplete; and (2) the document includes both 1988 and 
1993 ASN.1 syntax.  The module was incomplete, as it did not have a module 
number which prevents compilation.  The 1993 and 1988 syntax ASN.1 were not in 
synch; th 1993 ASN.1 module referenced the 93 ASN.1 syntax from RFC 2459 while 
the 1988 ASN.1 module references RFC 3280.  

Please note that both of these issues have been resolved.  An OID has now been 
assigned, correcting the first issue. The AD has directed the editors to remove 
the '93 ASN.1 module and specify all ASN.1 using the '88 syntax, as in 3280.  
This resolves the second issue.


Thanks,


Tim Polk



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAB3gNkT009172 for <[e-mail]>; Mon, 10 Nov 2003 19:42:23 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAB3gN5J009171 for ietf-pkix-bks; Mon, 10 Nov 2003 19:42:23 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lakemtao02.cox.net (lakemtao02.cox.net [68.1.17.243]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAB3gIkT009150; Mon, 10 Nov 2003 19:42:19 -0800 (PST) (envelope-from [e-mail])
Received: from WJJCUSCLANGSTO1 ([68.101.35.22]) by lakemtao02.cox.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with SMTP id <20031111034205.OWO2297.lakemtao02.cox.net@WJJCUSCLANGSTO1>; Mon, 10 Nov 2003 22:42:05 -0500
Message-ID: <001101c3a805$c5b5ba70$[e-mail]>
From: "Peter Hesse" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: request for change in son-of-rfc2633
Date: Mon, 10 Nov 2003 22:41:52 -0500
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_000D_01C3A7DB.D5E6B950"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
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_000_000D_01C3A7DB.D5E6B950
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

All,

I have recently run into a problem with signed emails not being able to be
verified, because of the presence of the word "From" in the first columns of
a line of the email message.  This email will serve as an example of this
potential problem.  If your email client sees this message as signed but the
signature is invalid, the next paragraph should start with the word
"From"--see if it has been modified.

>From appearing as the first characters after a blank line will result in
some email delivery agents (such as sendmail or exim) escaping the
word--"From" is replaced with ">From".   The reason for this behavior has to
do with the UNIX mbox mail storage file format.  The mbox format stores
multiple messages in one file, and the messages are separated by the word
"From" as the first characters following a blank line.  Some mail delivery
agents do not have this problem (i.e. Exchange), because they do not store
messages in the mbox format.  Many do, however, resulting in a modification
of the message and the signature being invalidated.

I would like to request that this issue be more directly dealt with in
son-of-RFC2633.  (Currently, it is mentioned in the example MIME-encoded
message, but nowhere in the text.)  One recommendation might be to borrow
from RFC2015 (MIME Security with PGP), which states:
   Though not required, it is generally a good idea to use Quoted-
   Printable encoding in the first step (writing out the data to be
   signed in MIME canonical format) if any of the lines in the data
   begin with "From ", and encode the "F".  This will avoid an MTA
   inserting a ">" in front of the line, thus invalidating the
   signature!

Perhaps this might even be a SHOULD, although I will ask the group to weigh
in on that.

Thanks,

--Peter



------=_NextPart_000_000D_01C3A7DB.D5E6B950
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIF1zCCAokw
ggHyoAMCAQICAQAwDQYJKoZIhvcNAQEEBQAwWzELMAkGA1UEBhMCVVMxKDAmBgNVBAoTH0dlbWlu
aSBTZWN1cml0eSBTb2x1dGlvbnMsIEluYy4xIjAgBgNVBAMTGUdTUyBDZXJ0aWZpY2F0ZSBBdXRo
b3JpdHkwHhcNMDIwNDI1MjE1NjI3WhcNMDUwMjEyMjE1NjI3WjBbMQswCQYDVQQGEwJVUzEoMCYG
A1UEChMfR2VtaW5pIFNlY3VyaXR5IFNvbHV0aW9ucywgSW5jLjEiMCAGA1UEAxMZR1NTIENlcnRp
ZmljYXRlIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAtl3UwxhHyP05YqIF
kyfkWt8669gO/VKxC51PhJaV+hb9swwtaMVtJ9k8WjfQLt3fZpaNCNKB7V61KHxY1K1JCP67AwBy
W4TRuGRwEb+PXu5XdpNs3kxKtunlR4/WPsrrvuMx9/R/Fx9ld3TUqXCJ/JN7Zg68IappkcMy9S3w
koECAwEAAaNdMFswHQYDVR0OBBYEFJpr3UY3Hh5dngW5n9h72/GKMy7GMB8GA1UdIwQYMBaAFJpr
3UY3Hh5dngW5n9h72/GKMy7GMAwGA1UdEwQFMAMBAf8wCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEB
BAUAA4GBAHSd4BGG4le+QZBw/6bCq6mGpr4aJAE7UuXEW/I5YXqlQs1CkAzEHV8UnnXgDd0xONTQ
CdznbzCBNAE1EoxL14Kdp5I6omEeNulMd/tGAvxdw0qbbSaT9LolqtnPL2RbnI3j0JsQlncN1+l2
Dzx8Ka39NU4Gb/P6qo/PKa5+YRHSMIIDRjCCAq+gAwIBAgIBCzANBgkqhkiG9w0BAQUFADBbMQsw
CQYDVQQGEwJVUzEoMCYGA1UEChMfR2VtaW5pIFNlY3VyaXR5IFNvbHV0aW9ucywgSW5jLjEiMCAG
A1UEAxMZR1NTIENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw0wMjA4MDUxODIxMTZaFw0wNDA4MDQx
ODIxMTZaMIGNMQswCQYDVQQGEwJVUzEnMCUGA1UEChMeR2VtaW5pIFNlY3VyaXR5IFNvbHV0aW9u
cyBJbmMuMRQwEgYDVQQLEwtEZXZlbG9wbWVudDEUMBIGA1UEAxMLUGV0ZXIgSGVzc2UxKTAnBgkq
hkiG9w0BCQEWGnBtaGVzc2VAZ2VtaW5pc2VjdXJpdHkuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQCvREu1eU1kCNW+lz+ZV9xvljBC7O6iESK10wzKPlrgnhL87+V5/joAbnwsXt25NsmP
8MIY6tuRxCbZzZn3bFTyPerhIOENWrA/HVdIP29TXfHL1YZn7bqBRHyjKcNdYS02GCw4gR4Fr5QS
SQzy62WbLcaoSG/wnhBqBesLxZMsOwIDAQABo4HmMIHjMAkGA1UdEwQCMAAwEQYJYIZIAYb4QgEB
BAQDAgSwMAsGA1UdDwQEAwIE8DAdBgNVHQ4EFgQUG8pDjEsHMZVS4/sJThNbtamIzEswHwYDVR0j
BBgwFoAUmmvdRjceHl2eBbmf2Hvb8YozLsYwJQYDVR0RBB4wHIEacG1oZXNzZUBnZW1pbmlzZWN1
cml0eS5jb20wNwYDVR0fBDAwLjAsoCqgKIYmaHR0cDovL3d3dy5nZW1pbmlzZWN1cml0eS5jb20v
cm9vdC5jcmwwFgYDVR0gBA8wDTALBgkrBgEEAe8oAQEwDQYJKoZIhvcNAQEFBQADgYEABOIVgnmX
5u4gHHRMsIG5H9WAbMqUeqjhGiFMxDjFXoS2Fkk6eVS6wLJZiS54mWrT1NLA9UOcqfvX8pdpp+pw
IpCwK9ywIco4mrqRdJ5Ja7vuxiO0e0J236mWdTQqPXWxZCOYumBtLkqoOcDFQYjuM4ZPLKSbFiMs
j1OYuQnyz6cxggHDMIIBvwIBATBgMFsxCzAJBgNVBAYTAlVTMSgwJgYDVQQKEx9HZW1pbmkgU2Vj
dXJpdHkgU29sdXRpb25zLCBJbmMuMSIwIAYDVQQDExlHU1MgQ2VydGlmaWNhdGUgQXV0aG9yaXR5
AgELMAkGBSsOAwIaBQCggbowGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx
DxcNMDMxMTExMDM0MTUyWjAjBgkqhkiG9w0BCQQxFgQUiwZyw+XEkLYZTGXX7PJ5QjnYr/0wWwYJ
KoZIhvcNAQkPMU4wTDAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw
BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwBwYFKw4DAh0wDQYJKoZIhvcNAQEBBQAEgYCfsEWDj+Vi
HEn1kAAVx6yfGTkolRIR7uuC0KS1d4zrT1omaUnVTTKET9QBY7QUqdfb2gcvw9pZuRb4bBtYir0W
Rfnmfuob1NwKXaPPSv6inoySZ2/j/LR3nHsMd2GWYQFI5Q9LGyhqahQcyEWV/vSe9YSd0yUl9hSS
cL3sbEfE6AAAAAAAAA==

------=_NextPart_000_000D_01C3A7DB.D5E6B950--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAANdYkT098381 for <[e-mail]>; Mon, 10 Nov 2003 15:39:34 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAANdXla098380 for ietf-pkix-bks; Mon, 10 Nov 2003 15:39:33 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.173]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAANdWkT098375 for <[e-mail]>; Mon, 10 Nov 2003 15:39:32 -0800 (PST) (envelope-from [e-mail])
Received: from ROMANS (dyn070-253.ietf58.ietf.org [130.129.70.253]) by smtp3.pacifier.net (Postfix) with ESMTP id 4A9B56D700; Mon, 10 Nov 2003 15:39:23 -0800 (PST)
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "Trevor Freeman" <[e-mail]>
Cc: "'pkix group'" <[e-mail]>
Subject: RE: SCVP asn.1 module comments
Date: Mon, 10 Nov 2003 17:41:52 -0600
Message-ID: <000001c3a7e4$3978dc70$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
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>

Trevor,

I think I already gave you these, but people are talking about a real
soon last call and I want to make sure that they don't get dropped on
the floor.

Jim

Additional ASN.1 module comments:

1.  GeneralNames is defined in PKIX1Implicit88 not PKIX1Explicit88

2.  Personal preference would be to keep UTF8String defined in this
document rather than importing it.

3.  d:\ietf\asn\scvp-13.asn(91) : warning 2004: Field name
'KeyPurposeId' should start with lower letter.

4.  d:\ietf\asn\scvp-13.asn(92) : warning 2004: Field name
'ValidationName' should start with lower letter.

5.  d:\ietf\asn\scvp-13.asn(235) : warning 2004: Field name
'DefaultPolicyID' should start with lower letter.

6.  d:\ietf\asn\scvp-13.asn(285) : error 1019: Type symbol
ValidationAlgorithm never resolved. (--- DUP OF BELOW)

7.  d:\ietf\asn\scvp-13.asn(285) : warning 4001: The imported symbol
'SubjectPublicKeyInfo' is never referenced.

8.  d:\ietf\asn\scvp-13.asn(285) : warning 4002: The symbol
'NameValidationAlg' is never referenced.

9.  Add following text (DUP OF BELOW)
         OCSPResponse FROM OCSP
  {iso(1) identified-organization(3)
  dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
  id-mod-ocsp(14)}

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]] On Behalf Of Bryan Pitcher
> Sent: Friday, November 07, 2003 9:32 AM
> To: pkix group
> Subject: SCVP asn.1 module comments
> 
> 
> 
> 
> Hi,
> 
> In reviewing draft-ietf-pkix-scvp-13.txt, I have noticed a
> few issues with the ASN.1 module definition.
> 
> 1.  The constant FullRequestRefUnsuported under ENUMERATION
> SCVPStatusCode is currently defined as 
> 'FullRequestRefUnsuported (51},'.  The '}' character to the 
> right of the 51 should be ')' instead (change the curly brace 
> to a paran).
> 
> 2.  The Query structure has a reference to a structure
> 'ValidationAlgorithm'.  'ValidationAlgorithm isn't imported 
> or defined anywhere in the module.  I assume this is meant to 
> refererence the 'ValidationArg' structure.  
> 
> 3.  The OCSPResponse structure is used in the RevocationInfo
> CHOICE, but not imported.  This is most likely because 
> RFC2560 doesn't define a module identifier in it's ASN.1 
> syntax.  What is generally done in cases like this?
> 
> Thanks,
> Bryan Pitcher
> 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAAMcnkT096251 for <[e-mail]>; Mon, 10 Nov 2003 14:38:49 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAAMcnft096250 for ietf-pkix-bks; Mon, 10 Nov 2003 14:38:49 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAAMcmkT096245 for <[e-mail]>; Mon, 10 Nov 2003 14:38:48 -0800 (PST) (envelope-from [e-mail])
Received: from wchokhani (dpvc-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id hAAMcoPJ029839 for <[e-mail]>; Mon, 10 Nov 2003 17:38:50 -0500
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: Comments on draft-ietf-pkix-sim-01
Date: Mon, 10 Nov 2003 17:38:45 -0500
Message-ID: <003901c3a7db$698312e0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
In-Reply-To: <p06010205bbd5c17a0310@[130.129.139.103]>
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

-----Original Message-----
From: Stephen Kent [mailto:[e-mail]] 
Sent: Monday, November 10, 2003 5:33 PM
To: Santosh Chokhani
Cc: [e-mail]
Subject: RE: Comments on draft-ietf-pkix-sim-01


At 15:20 -0500 11/10/03, Santosh Chokhani wrote:
>Steve:
>
>Do you think there is some benefit to the SIM discussing privacy and 
>linking issues?
>
>I can see that if the same user name (say DN) was issued different 
>certificates with different attributes by the same CA or different CAs, 
>it will be easy to link the identities represented by the various 
>attributes.

I think this is an issue for a CA/RA and for a user. A CA/RA ought 
not facilitate linkage but putting multiple personal identifiers into 
the same cert, or by issuing multiple certs under the same DN, with 
different, personal identifiers. But, it is also the responsibility 
of a user to not request certs from multiple CAs with the same 
subject DN, with distinct personal identifiers.

Steve



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAAMXkkT095677 for <[e-mail]>; Mon, 10 Nov 2003 14:33:46 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAAMXk0c095676 for ietf-pkix-bks; Mon, 10 Nov 2003 14:33:46 -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.10/8.12.8) with ESMTP id hAAMXjkT095668 for <[e-mail]>; Mon, 10 Nov 2003 14:33:45 -0800 (PST) (envelope-from [e-mail])
Received: from [130.129.139.103] (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id hAAMXf9i001638; Mon, 10 Nov 2003 17:33:41 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@localhost
Message-Id: <p06010205bbd5c17a0310@[130.129.139.103]>
In-Reply-To: <001701c3a7c8$20a1d380$[e-mail]>
References: <001701c3a7c8$20a1d380$[e-mail]>
Date: Mon, 10 Nov 2003 17:32:56 -0500
To: "Santosh Chokhani" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: Comments on draft-ietf-pkix-sim-01
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
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 15:20 -0500 11/10/03, Santosh Chokhani wrote:
>Steve:
>
>Do you think there is some benefit to the SIM discussing privacy and linking
>issues?
>
>I can see that if the same user name (say DN) was issued different
>certificates with different attributes by the same CA or different CAs, it
>will be easy to link the identities represented by the various attributes.

I think this is an issue for a CA/RA and for a user. A CA/RA ought 
not facilitate linkage but putting multiple personal identifiers into 
the same cert, or by issuing multiple certs under the same DN, with 
different, personal identifiers. But, it is also the responsibility 
of a user to not request certs from multiple CAs with the same 
subject DN, with distinct personal identifiers.

Steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAAKKlkT090910 for <[e-mail]>; Mon, 10 Nov 2003 12:20:47 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAAKKlgF090909 for ietf-pkix-bks; Mon, 10 Nov 2003 12:20:47 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAAKKkkT090902 for <[e-mail]>; Mon, 10 Nov 2003 12:20:46 -0800 (PST) (envelope-from [e-mail])
Received: from wchokhani (dpvc-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id hAAKKlPJ007588 for <[e-mail]>; Mon, 10 Nov 2003 15:20:47 -0500
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: Comments on draft-ietf-pkix-sim-01
Date: Mon, 10 Nov 2003 15:20:42 -0500
Message-ID: <001701c3a7c8$20a1d380$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
In-Reply-To: <p06010200bbd44a8084ae@[192.168.0.100]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id hAAKKlkT090905
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>

Steve:

Do you think there is some benefit to the SIM discussing privacy and linking
issues?

I can see that if the same user name (say DN) was issued different
certificates with different attributes by the same CA or different CAs, it
will be easy to link the identities represented by the various attributes.

Should this be a guidance to the subject, RA or both.  It could not be CA
since the CA does not vet these values.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Stephen Kent
Sent: Sunday, November 09, 2003 5:32 PM
To: Santosh Chokhani
Cc: [e-mail]
Subject: RE: Comments on draft-ietf-pkix-sim-01



At 10:12 -0500 11/8/03, Santosh Chokhani wrote:
>Steve:
>
>I agree that putting multiple sensitive attributes in one location is
>inviting trouble.

Sanosh,

The issue the NRC report addresses is not the fact that these 
attributes are "sensitive" pre se. Rather, each attribute of the sort 
you noted is an identifier from a different identity system. The 
report argues that it is a bad idea to bind multiple identity 
attributes in the same cert.

>However, when you look at the details of the protocol, the CA and the
>certificate are not the points of attack since they do not contain 
>sensitive information.  The likely points of attack are the hash, 
>password, subject workstation, relying party workstation, and RA 
>workstation.
>
>Whether you hold single attribute in a certificate or hold multiple
>attributes in various certificates (so that you can present the 
>required attribute to the relying party), the relying party should only 
>see the
>attribute(s) it must.  Thus, putting multiple attributes in the certificate
>is not going to change the relying party workstation vulnerability.

Again, the argument made is the report is not about disclosure of 
these identifies to an RA or CA, but rather the bundling of multiple 
identifiers in a single cert.  The hashes representing the different 
identities, by their combined presence in a single cert, would make 
it easy to link disparate user identities to the same underlying 
individual, a privacy concern.  So, I suggest that we not try to make 
any provision to represent multiple identifies of this sort in a 
single cert.

Steve




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAAFGnkT077494 for <[e-mail]>; Mon, 10 Nov 2003 07:16:49 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAAFGnNr077493 for ietf-pkix-bks; Mon, 10 Nov 2003 07:16:49 -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.10/8.12.8) with ESMTP id hAAFGmkT077487 for <[e-mail]>; Mon, 10 Nov 2003 07:16:48 -0800 (PST) (envelope-from [e-mail])
Received: from [130.129.139.103] (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id hAAFGf9i005828; Mon, 10 Nov 2003 10:16:43 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@localhost
Message-Id: <p06010200bbd44a8084ae@[192.168.0.100]>
In-Reply-To: <000901c3a60a$ba7eecf0$[e-mail]>
References: <000901c3a60a$ba7eecf0$[e-mail]>
Date: Sun, 9 Nov 2003 17:32:24 -0500
To: "Santosh Chokhani" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: Comments on draft-ietf-pkix-sim-01
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
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 10:12 -0500 11/8/03, Santosh Chokhani wrote:
>Steve:
>
>I agree that putting multiple sensitive attributes in one location is
>inviting trouble.

Sanosh,

The issue the NRC report addresses is not the fact that these 
attributes are "sensitive" pre se. Rather, each attribute of the sort 
you noted is an identifier from a different identity system. The 
report argues that it is a bad idea to bind multiple identity 
attributes in the same cert.

>However, when you look at the details of the protocol, the CA and the
>certificate are not the points of attack since they do not contain sensitive
>information.  The likely points of attack are the hash, password, subject
>workstation, relying party workstation, and RA workstation.
>
>Whether you hold single attribute in a certificate or hold multiple
>attributes in various certificates (so that you can present the required
>attribute to the relying party), the relying party should only see the
>attribute(s) it must.  Thus, putting multiple attributes in the certificate
>is not going to change the relying party workstation vulnerability.

Again, the argument made is the report is not about disclosure of 
these identifies to an RA or CA, but rather the bundling of multiple 
identifiers in a single cert.  The hashes representing the different 
identities, by their combined presence in a single cert, would make 
it easy to link disparate user identities to the same underlying 
individual, a privacy concern.  So, I suggest that we not try to make 
any provision to represent multiple identifies of this sort in a 
single cert.

Steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA9FoIkT029834 for <[e-mail]>; Sun, 9 Nov 2003 07:50:18 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA9FoIbx029833 for ietf-pkix-bks; Sun, 9 Nov 2003 07:50:18 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mtiwmhc13.worldnet.att.net (mtiwmhc13.worldnet.att.net [204.127.131.117]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA9FoHkT029826 for <[e-mail]>; Sun, 9 Nov 2003 07:50:18 -0800 (PST) (envelope-from [e-mail])
Received: from wchokhani (186.washington-27rh15rt.dc.dial-access.att.net[12.77.41.186]) by worldnet.att.net (mtiwmhc13) with SMTP id <20031109155005113008546ge>; Sun, 9 Nov 2003 15:50:06 +0000
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: Comments on draft-ietf-pkix-sim-01
Date: Sun, 9 Nov 2003 10:49:49 -0500
Message-ID: <005501c3a6d9$2160c550$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
In-Reply-To: <006d01c3a6c0$85c2e5a0$0500a8c0@arport>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id hA9FoIkT029829
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>

Anders:

If I understand correctly, the SIM approach may be more flexible as more
secure than some of the items listed below since the CA need not hold all
the sensitive information and become a target of attack.

The attractive part of SIM is that even at the RA, sensitive information
needs to be there at the most during registration and after that it is
hashed.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Anders Rundgren
Sent: Sunday, November 09, 2003 7:54 AM
To: Santosh Chokhani; [e-mail]
Subject: Re: Comments on draft-ietf-pkix-sim-01



Santosh,
I agree with your vulnerability analysis.
The real problem is rather to get broad support for SIM due to the numerous
other ways to achive the same functionality.  Most of the alternatives are
supported by existing standards.

>From an upgraded earlier posting of mine:

Korean citizens (as well as Swedish citizens) have a citizen number that is
more or less "secret" as it contains date-of-birth and gender.  To put this
number in clear in a generic ID-certificate would limit the certificate's
usability as only some relying parties (typically government-associated)
need this information.  To cope with this, you propose a method where a user
in a safe and selective way can transfer this number to an RP that can
verify its authenticity.

Actually the scope of this problem touches a more fundamental issue that I
have spent some time studying: How to combine PKI with "information"
concering the subject.   Therefore, I took the liberty to describe some
completely different methods to achieve "approximately" the same goal.

FINLAND'S SOLUTION
----------------------------
Assign a unique electronic ID (number) to each citizen and supply this
information together with the semi-secret citizen-ID to the RPs that have
the proper authority to handle the secret ID. The electronic ID has no usage
except in on-line usage using certificates but is still usable even for RPs
that do not have or need the secret ID. 

ON-LINE ASSERTIONS
-----------------------------
The following method allows *any* data to be given to RPs, and without
deploying secrets in certificates:

1. The user surfs to an on-line service that needs some additional CA-
   registered information regarding the user
2. The user is authenticated using SSL/TLS client-authentication 3. The
service automatically redirects the user to a CA URL which is deducted  from
the issuer of the certificate 4. The user is authenticated by the CA using
SSL/TLS client-authentication 5. The CA application informs the user that
"Service XYX wants the following
   user attributes, do you agree?"
6. The user hits OK and is automatically redirected back to the service with

   an SAML "ticket" containing the requested attributes signed by the CA

Although looking complex, it is just a couple of mouse-clicks + two
authentication PIN-code-operations for the user to perform. 

If the RP also saves the received ticket, it will not have to repeat the
request a second time, which makes this scheme both very flexible and
user-friendly.

OFF-LINE ASSERTIONS
----------------------------
A user may also surf to a CA, and after being authenticated, request that
the CA sends a CA-signed message with user-attributes to a selected RP.  To
make this a viable scheme, the user-certificate should contain a unique and
static ID in the CAs issuing-domain, in order to to not have to repeat this
process for each certificate renewal.

AUTHENTICATED RP LOOKUP
--------------------------------------
Another solution is that the service authenticates to the CA and gets this
information directly based on user certificate as input.  This solution is
based on that the CAs must "know" the RPs and their needs which is a
drawback.

MULTIPLE CERTIFICATES
---------------------------------
Multiple client-certificates (with and without the number in clear), is of
course another possible solution that has the advantage that nothing special
has to be built.  Requires a little bit more knowledge on the user's part
though and is entirely static with respect to user-attributes.

cheers,
Anders Rundgren



----- Original Message ----- 
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Sent: Saturday, November 08, 2003 16:12
Subject: RE: Comments on draft-ietf-pkix-sim-01



Steve:

I agree that putting multiple sensitive attributes in one location is
inviting trouble.

However, when you look at the details of the protocol, the CA and the
certificate are not the points of attack since they do not contain sensitive
information.  The likely points of attack are the hash, password, subject
workstation, relying party workstation, and RA workstation.

Whether you hold single attribute in a certificate or hold multiple
attributes in various certificates (so that you can present the required
attribute to the relying party), the relying party should only see the
attribute(s) it must.  Thus, putting multiple attributes in the certificate
is not going to change the relying party workstation vulnerability.

Similarly, the subject is likely to use the same workstation for carrying
out the transactions and hence subject workstation threat will not change.

The hash algorithm and passwords could have the same diversity whether the
attributes are vetted in one certificate or multiple certificates.

This leaves the RA workstation threat.  If the RA workstation is used to
enter and say hash the attributes, its security compromise could lead to
compromising a set of attributes rather than a single attributes.  However,
using the current I-D, an RA could vet multiple attributes for the same
subject using a single CA or multiple CAs, resulting in the same
vulnerability.

Thus, as a minimum, the RFC Authors should be encouraged to beef up the
security section to discuss the issue of RA protecting the attributes.

I think the best approach may be to add appropriate caution in the Security
Considerations section, discourage the vetting of multiple attributes by an
RA if the RA system has to process those attributes, but permit the
certificate syntax to carry multiple attributes in case there is a need for
it.

-----Original Message-----
From: Stephen Kent [mailto:[e-mail]] 
Sent: Friday, November 07, 2003 10:14 AM
To: Santosh Chokhani
Cc: [e-mail]; [e-mail]
Subject: RE: Comments on draft-ietf-pkix-sim-01


At 9:49 -0500 11/7/03, Santosh Chokhani wrote:
>Tim and Park:
>
>Some more comments:
>
>2.  It is not clear from the document whether SIM is a new extension or 
>it goes in the subject alternative name field.
>
>3.  Was there some consideration given to add PII for multiple SIIType 
>in the certificate.  Seems that it could be useful to bind SSN, 
>driver's license, and say credit card number all in one certificate so 
>that different relying parties can use the same certificate.  In that 
>case, SIM syntax needs to change and needs to explicitly include 
>SIIType.  If that were done, there does not appear to be a security 
>problem with it.
>

I would argue against binding multiple types of identifiers in the 
same cert.  I refer you to the NAS Committee report "Who Goes There? 
Authentication Through the Lens of Privacy" for a lengthy discussion 
of why such bundling is not a good idea from both a security and 
privacy perspective.

Steve





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA9CvHkT024950 for <[e-mail]>; Sun, 9 Nov 2003 04:57:17 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA9CvHuV024949 for ietf-pkix-bks; Sun, 9 Nov 2003 04:57:17 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp1.fre.skanova.net (smtp1.fre.skanova.net [195.67.227.94]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA9CvFkT024944 for <[e-mail]>; Sun, 9 Nov 2003 04:57:16 -0800 (PST) (envelope-from [e-mail])
Received: from arport (t9o913p30.telia.com [213.64.27.30]) by smtp1.fre.skanova.net (8.12.10/8.12.10) with SMTP id hA9Cv5Uk026519; Sun, 9 Nov 2003 13:57:06 +0100 (CET)
Message-ID: <006d01c3a6c0$85c2e5a0$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Santosh Chokhani" <[e-mail]>, <[e-mail]>
References: <000901c3a60a$ba7eecf0$[e-mail]>
Subject: Re: Comments on draft-ietf-pkix-sim-01
Date: Sun, 9 Nov 2003 13:53:43 +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>

Santosh,
I agree with your vulnerability analysis.
The real problem is rather to get broad support for SIM due to the
numerous other ways to achive the same functionality.  Most of the
alternatives are supported by existing standards.

>From an upgraded earlier posting of mine:

Korean citizens (as well as Swedish citizens) have a citizen number that
is more or less "secret" as it contains date-of-birth and gender.  To put
this number in clear in a generic ID-certificate would limit the certificate's
usability as only some relying parties (typically government-associated)
need this information.  To cope with this, you propose a method where
a user in a safe and selective way can transfer this number to an RP
that can verify its authenticity.

Actually the scope of this problem touches a more fundamental issue that
I have spent some time studying: How to combine PKI with "information"
concering the subject.   Therefore, I took the liberty to describe some
completely different methods to achieve "approximately" the same goal.

FINLAND'S SOLUTION
----------------------------
Assign a unique electronic ID (number) to each citizen and supply this
information together with the semi-secret citizen-ID
to the RPs that have the proper authority to handle the secret ID.
The electronic ID has no usage except in on-line usage using
certificates but is still usable even for RPs that do not have
or need the secret ID. 

ON-LINE ASSERTIONS
-----------------------------
The following method allows *any* data to be given to RPs, and without
deploying secrets in certificates:

1. The user surfs to an on-line service that needs some additional CA-
   registered information regarding the user
2. The user is authenticated using SSL/TLS client-authentication
3. The service automatically redirects the user to a CA URL which is deducted
 from the issuer of the certificate
4. The user is authenticated by the CA using SSL/TLS client-authentication
5. The CA application informs the user that "Service XYX wants the following
   user attributes, do you agree?"
6. The user hits OK and is automatically redirected back to the service with 
   an SAML "ticket" containing the requested attributes signed by the CA

Although looking complex, it is just a couple of mouse-clicks + two
authentication PIN-code-operations for the user to perform. 

If the RP also saves the received ticket, it will not have to repeat the
request a second time, which makes this scheme both very flexible
and user-friendly.

OFF-LINE ASSERTIONS
----------------------------
A user may also surf to a CA, and after being authenticated, request
that the CA sends a CA-signed message with user-attributes to a
selected RP.  To make this a viable scheme, the user-certificate should
contain a unique and static ID in the CAs issuing-domain, in order to
to not have to repeat this process for each certificate renewal.

AUTHENTICATED RP LOOKUP
--------------------------------------
Another solution is that the service authenticates to the CA and gets
this information directly based on user certificate as input.  This
solution is based on that the CAs must "know" the RPs and their
needs which is a drawback.

MULTIPLE CERTIFICATES
---------------------------------
Multiple client-certificates (with and without the number in clear), is of
course another possible solution that has the advantage that nothing
special has to be built.  Requires a little bit more knowledge on the
user's part though and is entirely static with respect to user-attributes.

cheers,
Anders Rundgren



----- Original Message ----- 
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Sent: Saturday, November 08, 2003 16:12
Subject: RE: Comments on draft-ietf-pkix-sim-01



Steve:

I agree that putting multiple sensitive attributes in one location is
inviting trouble.

However, when you look at the details of the protocol, the CA and the
certificate are not the points of attack since they do not contain sensitive
information.  The likely points of attack are the hash, password, subject
workstation, relying party workstation, and RA workstation.

Whether you hold single attribute in a certificate or hold multiple
attributes in various certificates (so that you can present the required
attribute to the relying party), the relying party should only see the
attribute(s) it must.  Thus, putting multiple attributes in the certificate
is not going to change the relying party workstation vulnerability.

Similarly, the subject is likely to use the same workstation for carrying
out the transactions and hence subject workstation threat will not change.

The hash algorithm and passwords could have the same diversity whether the
attributes are vetted in one certificate or multiple certificates.

This leaves the RA workstation threat.  If the RA workstation is used to
enter and say hash the attributes, its security compromise could lead to
compromising a set of attributes rather than a single attributes.  However,
using the current I-D, an RA could vet multiple attributes for the same
subject using a single CA or multiple CAs, resulting in the same
vulnerability.

Thus, as a minimum, the RFC Authors should be encouraged to beef up the
security section to discuss the issue of RA protecting the attributes.

I think the best approach may be to add appropriate caution in the Security
Considerations section, discourage the vetting of multiple attributes by an
RA if the RA system has to process those attributes, but permit the
certificate syntax to carry multiple attributes in case there is a need for
it.

-----Original Message-----
From: Stephen Kent [mailto:[e-mail]] 
Sent: Friday, November 07, 2003 10:14 AM
To: Santosh Chokhani
Cc: [e-mail]; [e-mail]
Subject: RE: Comments on draft-ietf-pkix-sim-01


At 9:49 -0500 11/7/03, Santosh Chokhani wrote:
>Tim and Park:
>
>Some more comments:
>
>2.  It is not clear from the document whether SIM is a new extension or
>it goes in the subject alternative name field.
>
>3.  Was there some consideration given to add PII for multiple SIIType
>in the certificate.  Seems that it could be useful to bind SSN, 
>driver's license, and say credit card number all in one certificate so 
>that different relying parties can use the same certificate.  In that 
>case, SIM syntax needs to change and needs to explicitly include 
>SIIType.  If that were done, there does not appear to be a security 
>problem with it.
>

I would argue against binding multiple types of identifiers in the 
same cert.  I refer you to the NAS Committee report "Who Goes There? 
Authentication Through the Lens of Privacy" for a lengthy discussion 
of why such bundling is not a good idea from both a security and 
privacy perspective.

Steve




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA8FCdkT088549 for <[e-mail]>; Sat, 8 Nov 2003 07:12:39 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA8FCdDV088548 for ietf-pkix-bks; Sat, 8 Nov 2003 07:12:39 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mtiwmhc13.worldnet.att.net (mtiwmhc13.worldnet.att.net [204.127.131.117]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA8FCckT088541 for <[e-mail]>; Sat, 8 Nov 2003 07:12:38 -0800 (PST) (envelope-from [e-mail])
Received: from wchokhani (117.washington-41rh15-16rt.dc.dial-access.att.net[12.77.62.117]) by worldnet.att.net (mtiwmhc13) with SMTP id <200311081512321130086ndbe>; Sat, 8 Nov 2003 15:12:32 +0000
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: Comments on draft-ietf-pkix-sim-01
Date: Sat, 8 Nov 2003 10:12:27 -0500
Message-ID: <000901c3a60a$ba7eecf0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
In-Reply-To: <p06002001bbd16699c7ed@[128.89.89.75]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id hA8FCckT088544
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>

Steve:

I agree that putting multiple sensitive attributes in one location is
inviting trouble.

However, when you look at the details of the protocol, the CA and the
certificate are not the points of attack since they do not contain sensitive
information.  The likely points of attack are the hash, password, subject
workstation, relying party workstation, and RA workstation.

Whether you hold single attribute in a certificate or hold multiple
attributes in various certificates (so that you can present the required
attribute to the relying party), the relying party should only see the
attribute(s) it must.  Thus, putting multiple attributes in the certificate
is not going to change the relying party workstation vulnerability.

Similarly, the subject is likely to use the same workstation for carrying
out the transactions and hence subject workstation threat will not change.

The hash algorithm and passwords could have the same diversity whether the
attributes are vetted in one certificate or multiple certificates.

This leaves the RA workstation threat.  If the RA workstation is used to
enter and say hash the attributes, its security compromise could lead to
compromising a set of attributes rather than a single attributes.  However,
using the current I-D, an RA could vet multiple attributes for the same
subject using a single CA or multiple CAs, resulting in the same
vulnerability.

Thus, as a minimum, the RFC Authors should be encouraged to beef up the
security section to discuss the issue of RA protecting the attributes.

I think the best approach may be to add appropriate caution in the Security
Considerations section, discourage the vetting of multiple attributes by an
RA if the RA system has to process those attributes, but permit the
certificate syntax to carry multiple attributes in case there is a need for
it.

-----Original Message-----
From: Stephen Kent [mailto:[e-mail]] 
Sent: Friday, November 07, 2003 10:14 AM
To: Santosh Chokhani
Cc: [e-mail]; [e-mail]
Subject: RE: Comments on draft-ietf-pkix-sim-01


At 9:49 -0500 11/7/03, Santosh Chokhani wrote:
>Tim and Park:
>
>Some more comments:
>
>2.  It is not clear from the document whether SIM is a new extension or
>it goes in the subject alternative name field.
>
>3.  Was there some consideration given to add PII for multiple SIIType
>in the certificate.  Seems that it could be useful to bind SSN, 
>driver's license, and say credit card number all in one certificate so 
>that different relying parties can use the same certificate.  In that 
>case, SIM syntax needs to change and needs to explicitly include 
>SIIType.  If that were done, there does not appear to be a security 
>problem with it.
>

I would argue against binding multiple types of identifiers in the 
same cert.  I refer you to the NAS Committee report "Who Goes There? 
Authentication Through the Lens of Privacy" for a lengthy discussion 
of why such bundling is not a good idea from both a security and 
privacy perspective.

Steve




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA7KCKkT051274 for <[e-mail]>; Fri, 7 Nov 2003 12:12:20 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA7KCKmK051273 for ietf-pkix-bks; Fri, 7 Nov 2003 12:12:20 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rhea.salford.ac.uk (rhea.salford.ac.uk [146.87.255.99]) by above.proper.com (8.12.10/8.12.8) with SMTP id hA7KCFkT051264 for <[e-mail]>; Fri, 7 Nov 2003 12:12:16 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 83375 invoked by uid 1236); 7 Nov 2003 20:12:16 -0000
Received: from [e-mail] by pan.salford.ac.uk by uid 401 with qmail-scanner-1.20rc4  (clamuko: 0.60. uvscan: v4.2.40/v4302. spamassassin: 2.60.  Clear:RC:1:.  Processed in 0.335416 secs); 07 Nov 2003 20:12:16 -0000
Received: from [146.87.80.150] (HELO salford.ac.uk) (146.87.80.150) by rhea.salford.ac.uk (qpsmtpd/0.27-dev) with ESMTP; Fri, 07 Nov 2003 20:12:15 +0000
Message-ID: <[e-mail]>
Date: Fri, 07 Nov 2003 20:12:14 +0000
From: "D.W.Chadwick" <[e-mail]>
Organization: University of Salford
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: PKIX <[e-mail]>, Steven Legg <[e-mail]>
Subject: LDAP issues
Content-Type: multipart/mixed; boundary="------------7DAFE0E45C1ADEE80D67E89E"
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.
--------------7DAFE0E45C1ADEE80D67E89E
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Dear All

the LDAP work that still needs to be progressed within PKIX is

i) LDAPv3 profile for X.509
ii) LDAPv3 schema and syntaxes for X.509 PKI and PMI attributes (using
component matching)
iii) LDAPv3 schema for PKCs, ACs and CRLs (using attribute
decomposition)
iv) DN strings for use with PKIs
v) subject certificate access extension

The IDs for the first three topics have currently expired but are still
active for the last two. There has been very little discussion on any of
the above since the last meeting, but we do plan to issue updates in due
course (very few changes are now needed to the first three sets of IDs).
Unfortunately I cant be at the next meeting to answer any queries on the
above, but Steven Legg will be present and has kindly offered to field
any questions that are raised. The mailing list can also be used for
those not attending the meeting, or who want everyone to be involved in
the discussions.

regards

david



*****************************************************************

David W. Chadwick, BSc PhD
Professor of Information Systems Security
IS Institute, University of Salford, Salford M5 4WT
Tel: [phone]  Fax [phone]
Mobile: [phone]
Email: [e-mail]
Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
Research Web site: http://sec.isi.salford.ac.uk
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************
--------------7DAFE0E45C1ADEE80D67E89E
Content-Type: text/x-vcard; charset=us-ascii;
 name="d.w.chadwick.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for David Chadwick
Content-Disposition: attachment;
 filename="d.w.chadwick.vcf"

begin:vcard 
n:Chadwick;David
tel;cell:[phone]
tel;fax:[phone]
tel;home:[phone]
tel;work:[phone]
x-mozilla-html:FALSE
url:http://sec.isi.salford.ac.uk
org:University of Salford;IS Institute
version:2.1
email;internet:[e-mail]
title:Professor of Information Security
adr;quoted-printable:;;The Crescent=0D=0A;Salford;Greater Manchester;M5 4WT;England
note;quoted-printable:Research Projects: http://sec.isi.salford.ac.uk=0D=0A=0D=0AEntrust key validation string: CJ94-LKWD-BSXB ...........=0D=0A=0D=0APGP Key ID is 0xBC238DE5
x-mozilla-cpt:;-18752
fn:David Chadwick
end:vcard

--------------7DAFE0E45C1ADEE80D67E89E--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA7FY4kT039967 for <[e-mail]>; Fri, 7 Nov 2003 07:34:04 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA7FY3VR039966 for ietf-pkix-bks; Fri, 7 Nov 2003 07:34:03 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mout.perfora.net (mout.perfora.net [217.160.230.41]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA7FY3kT039961 for <[e-mail]>; Fri, 7 Nov 2003 07:34:03 -0800 (PST) (envelope-from [e-mail])
Received: from [217.160.230.52] (helo=smtp.perfora.net) by mout.perfora.net with esmtp (Exim 3.35 #1) id 1AI8cd-0001uK-00; Fri, 07 Nov 2003 10:34:03 -0500
Received: from [172.23.4.129] (helo=togal2.1and1.com) by smtp.perfora.net with esmtp (Exim 3.35 #1) id 1AI8cd-0003Dx-00; Fri, 07 Nov 2003 10:34:03 -0500
To: =?iso-8859-1?Q?pkix_group?= <[e-mail]>
Subject: SCVP asn.1 module comments
From: =?iso-8859-1?Q?Bryan_Pitcher?= <[e-mail]>
X-Binford: 6100 (more power)
X-Originating-From: 28141299
X-Mailer: Webmail
X-Received: from config2 by 24.2.84.84 with HTTP id 28141299 for [e-mail]; Fri,  7 Nov 2003 16:32:01 +0100
Content-Type: text/plain; charset="iso-8859-1"
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Priority: 3
Date: Fri,  7 Nov 2003 16:32:01 +0100
Message-Id: <[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>

Hi,

In reviewing draft-ietf-pkix-scvp-13.txt, I have noticed a few issues
with the ASN.1 module definition.

1.  The constant FullRequestRefUnsuported under ENUMERATION
SCVPStatusCode is currently defined as 'FullRequestRefUnsuported (51},'.
 The '}' character to the right of the 51 should be ')' instead (change
the curly brace to a paran).

2.  The Query structure has a reference to a structure
'ValidationAlgorithm'.  'ValidationAlgorithm isn't imported or defined
anywhere in the module.  I assume this is meant to refererence the
'ValidationArg' structure.  

3.  The OCSPResponse structure is used in the RevocationInfo CHOICE, but
not imported.  This is most likely because RFC2560 doesn't define a
module identifier in it's ASN.1 syntax.  What is generally done in cases
like this?

Thanks,
Bryan Pitcher


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA7FIokT039444 for <[e-mail]>; Fri, 7 Nov 2003 07:18:50 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA7FIoMd039443 for ietf-pkix-bks; Fri, 7 Nov 2003 07:18:50 -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.10/8.12.8) with ESMTP id hA7FImkT039434 for <[e-mail]>; Fri, 7 Nov 2003 07:18:49 -0800 (PST) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id hA7FIiPd017183; Fri, 7 Nov 2003 10:18:44 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p06002001bbd16699c7ed@[128.89.89.75]>
In-Reply-To: <005201c3a53e$6a4e0800$[e-mail]>
References: <005201c3a53e$6a4e0800$[e-mail]>
Date: Fri, 7 Nov 2003 10:13:33 -0500
To: "Santosh Chokhani" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: Comments on draft-ietf-pkix-sim-01
Cc: <[e-mail]>, <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
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 9:49 -0500 11/7/03, Santosh Chokhani wrote:
>Tim and Park:
>
>Some more comments:
>
>2.  It is not clear from the document whether SIM is a new extension or it
>goes in the subject alternative name field.
>
>3.  Was there some consideration given to add PII for multiple SIIType in
>the certificate.  Seems that it could be useful to bind SSN, driver's
>license, and say credit card number all in one certificate so that different
>relying parties can use the same certificate.  In that case, SIM syntax
>needs to change and needs to explicitly include SIIType.  If that were done,
>there does not appear to be a security problem with it.
>

I would argue against binding multiple types of identifiers in the 
same cert.  I refer you to the NAS Committee report "Who Goes There? 
Authentication Through the Lens of Privacy" for a lengthy discussion 
of why such bundling is not a good idea from both a security and 
privacy perspective.

Steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA7EnxkT038357 for <[e-mail]>; Fri, 7 Nov 2003 06:49:59 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA7EnxRK038356 for ietf-pkix-bks; Fri, 7 Nov 2003 06:49:59 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA7EnwkT038350 for <[e-mail]>; Fri, 7 Nov 2003 06:49:58 -0800 (PST) (envelope-from [e-mail])
Received: from wchokhani (dpvc-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id hA7EnwPJ025872; Fri, 7 Nov 2003 09:49:58 -0500
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Cc: "Tim Polk" <[e-mail]>, <[e-mail]>
Subject: RE: Comments on draft-ietf-pkix-sim-01
Date: Fri, 7 Nov 2003 09:49:53 -0500
Message-ID: <005201c3a53e$6a4e0800$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
In-Reply-To: 
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id hA7EnwkT038352
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>

Tim and Park:

Some more comments:

2.  It is not clear from the document whether SIM is a new extension or it
goes in the subject alternative name field.

3.  Was there some consideration given to add PII for multiple SIIType in
the certificate.  Seems that it could be useful to bind SSN, driver's
license, and say credit card number all in one certificate so that different
relying parties can use the same certificate.  In that case, SIM syntax
needs to change and needs to explicitly include SIIType.  If that were done,
there does not appear to be a security problem with it.

-----Original Message-----
From: Santosh Chokhani [mailto:[e-mail]] 
Sent: Friday, November 07, 2003 9:23 AM
To: '[e-mail]'
Subject: RE: Comments on draft-ietf-pkix-sim-01


I agree with Park.  I found the document easy to read and follow.  I did not
find the protocol difficult.  It is also easy to see why there are two
stages of hashing.

The document can use some editing.  I did not note my editorial comments as
I was reading it.

I have only one substantive comment.  The document should address how
SIIType is communicated between the subject and the relying party.  I did
not find a mention of it.  May be I simply missed it.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Jongwook, Park
Sent: Friday, November 07, 2003 7:28 AM
To: 'Denis Pinkas'
Cc: [e-mail]; [e-mail]; Russ Housley; [e-mail]; Bill
Burr; [e-mail]; [e-mail]; [e-mail];
[e-mail]; [e-mail]
Subject: RE: Comments on draft-ietf-pkix-sim-01




Denis:

I think you catch on the basic idea of this draft exactly. Generally, the DN
in the 'subject' or 'subjectAltName' extension must be unique for each
person. However, it is very difficult to identify that the subject of
certificates is in fact the right person issued by CA since many people
often have the same name. 

To solve the above problem, this document don't use the DN for including the
non-public data since the information in DN can't meet the requirement and
is likely to disclosing private data. Alternatively, this draft proposes the
PII(Privacy Identification Information) structure which is encrypted form of
any sensitive identifier and finally put into the 'subjectAltName'
'GeneralizedName' 'otherName' field. This way can be regarded as a
complementary method for the shortcoming of the DN. 

PII structure is defined as follows :

PII = H(R || SIItype || H (R || P || SII))
where R : 160-bit random number, P : Password, SII : Sensitive
Identification Identifier and H : Cryptographically secure hash function
such as SHA-1, not MD2 or MD5.

PII structure can be applied to the various situations in different ways in
accordance with the RP's security environments. Please refer to the section
5. Example Usage of PII of the draft for details. As a first example, let us
suppose the RP already know the SII of the certificate holder via out of
band. In this case, certificate holder should send R, P and his certificate
containing the PII. Then RP can figure out if the PII in cert and another
PII' calculated itself from R, P and SII already obtained are identical or
not. It is definitely clear that R and P should be transmitted in a secure
channel. 

For another example, suppose such context where some people don't really
want to divulge any hint of his sensitive identifier to RPs. Maybe it's a
kind of same case why we need the Proof of Possession (POP) in RFC2510.
Anyway, please note the PII is the double-hashed structure. That is to say,
the subject send only intermediate value, H(R || P || SII) to RP without
disclosing the SII. Then relying party can calculates H ( R || SIItype ||
intermediate value) and verifies whether this value is equal to the PII in
the certificate. Finally, RP can guess the certificate holder has right
certificate even if it doesn't know the value of SII itself. 

Alike the above procedures, the certificate holder should be send R, P, SII
and PII in a cert if the RP doesn't have any information about the
certificate holder. The rest of the verification is similar to the first two
cases. 

In conclusion, PII structure is cryptographically secure and efficient
scheme to protect personal information although it seems to be complicated
at a glance.

Best regards,
Park.  


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Denis Pinkas
Sent: Friday, November 07, 2003 3:39 AM
To: pkix
Subject: Comments on draft-ietf-pkix-sim-01

I have always wondered about the goal of this document, since it is not
crystal clear.

It seems that the goal is to allow a relying party to determine whether the
subject of a particular certificate is the right person. This is currently
difficult since there might be not enough information in the DN and
disclosing more information in the DN would be against privacy.

Is it the basic motivation of this document ?

There is however an additional property of the "solution" (or is it a real
requirement ?) :

    Furthermore, the subject can prove to the
    relying party that they are associated with a valid identification
    with out disclosing the identifier.

This requirement is not crystal clear. What is a valid identification ? If
it is a bank account number, is it a number with the right Luhn code
computation in it and an existing bank identification number in it ?

Now the solution is rather complicated and it can be seen that an encryption
channel is required. A high level view of the goal(s?) and the advantages of
the solution is currently missing.

There might be a much simpler solution to solve the basic problem that is
trying to be solved:

Include in the certificate a hash of "personal information" that can be
revealed by the certifcate holder and thus any relying party to which this
information is disclosed can verify it (usually once).


Denis







Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA7EMckT037174 for <[e-mail]>; Fri, 7 Nov 2003 06:22:38 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA7EMcmZ037173 for ietf-pkix-bks; Fri, 7 Nov 2003 06:22:38 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA7EMbkT037168 for <[e-mail]>; Fri, 7 Nov 2003 06:22:37 -0800 (PST) (envelope-from [e-mail])
Received: from wchokhani (dpvc-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id hA7EMbPJ022728 for <[e-mail]>; Fri, 7 Nov 2003 09:22:37 -0500
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: Comments on draft-ietf-pkix-sim-01
Date: Fri, 7 Nov 2003 09:22:31 -0500
Message-ID: <005001c3a53a$97cff3a0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
In-Reply-To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id hA7EMckT037169
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 Park.  I found the document easy to read and follow.  I did not
find the protocol difficult.  It is also easy to see why there are two
stages of hashing.

The document can use some editing.  I did not note my editorial comments as
I was reading it.

I have only one substantive comment.  The document should address how
SIIType is communicated between the subject and the relying party.  I did
not find a mention of it.  May be I simply missed it.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Jongwook, Park
Sent: Friday, November 07, 2003 7:28 AM
To: 'Denis Pinkas'
Cc: [e-mail]; [e-mail]; Russ Housley; [e-mail]; Bill
Burr; [e-mail]; [e-mail]; [e-mail];
[e-mail]; [e-mail]
Subject: RE: Comments on draft-ietf-pkix-sim-01




Denis:

I think you catch on the basic idea of this draft exactly. Generally, the DN
in the 'subject' or 'subjectAltName' extension must be unique for each
person. However, it is very difficult to identify that the subject of
certificates is in fact the right person issued by CA since many people
often have the same name. 

To solve the above problem, this document don't use the DN for including the
non-public data since the information in DN can't meet the requirement and
is likely to disclosing private data. Alternatively, this draft proposes the
PII(Privacy Identification Information) structure which is encrypted form of
any sensitive identifier and finally put into the 'subjectAltName'
'GeneralizedName' 'otherName' field. This way can be regarded as a
complementary method for the shortcoming of the DN. 

PII structure is defined as follows :

PII = H(R || SIItype || H (R || P || SII))
where R : 160-bit random number, P : Password, SII : Sensitive
Identification Identifier and H : Cryptographically secure hash function
such as SHA-1, not MD2 or MD5.

PII structure can be applied to the various situations in different ways in
accordance with the RP's security environments. Please refer to the section
5. Example Usage of PII of the draft for details. As a first example, let us
suppose the RP already know the SII of the certificate holder via out of
band. In this case, certificate holder should send R, P and his certificate
containing the PII. Then RP can figure out if the PII in cert and another
PII' calculated itself from R, P and SII already obtained are identical or
not. It is definitely clear that R and P should be transmitted in a secure
channel. 

For another example, suppose such context where some people don't really
want to divulge any hint of his sensitive identifier to RPs. Maybe it's a
kind of same case why we need the Proof of Possession (POP) in RFC2510.
Anyway, please note the PII is the double-hashed structure. That is to say,
the subject send only intermediate value, H(R || P || SII) to RP without
disclosing the SII. Then relying party can calculates H ( R || SIItype ||
intermediate value) and verifies whether this value is equal to the PII in
the certificate. Finally, RP can guess the certificate holder has right
certificate even if it doesn't know the value of SII itself. 

Alike the above procedures, the certificate holder should be send R, P, SII
and PII in a cert if the RP doesn't have any information about the
certificate holder. The rest of the verification is similar to the first two
cases. 

In conclusion, PII structure is cryptographically secure and efficient
scheme to protect personal information although it seems to be complicated
at a glance.

Best regards,
Park.  


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Denis Pinkas
Sent: Friday, November 07, 2003 3:39 AM
To: pkix
Subject: Comments on draft-ietf-pkix-sim-01

I have always wondered about the goal of this document, since it is not
crystal clear.

It seems that the goal is to allow a relying party to determine whether the
subject of a particular certificate is the right person. This is currently
difficult since there might be not enough information in the DN and
disclosing more information in the DN would be against privacy.

Is it the basic motivation of this document ?

There is however an additional property of the "solution" (or is it a real
requirement ?) :

    Furthermore, the subject can prove to the
    relying party that they are associated with a valid identification
    with out disclosing the identifier.

This requirement is not crystal clear. What is a valid identification ? If
it is a bank account number, is it a number with the right Luhn code
computation in it and an existing bank identification number in it ?

Now the solution is rather complicated and it can be seen that an encryption
channel is required. A high level view of the goal(s?) and the advantages of
the solution is currently missing.

There might be a much simpler solution to solve the basic problem that is
trying to be solved:

Include in the certificate a hash of "personal information" that can be
revealed by the certifcate holder and thus any relying party to which this
information is disclosed can verify it (usually once).


Denis







Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA7CSAkT030600 for <[e-mail]>; Fri, 7 Nov 2003 04:28:10 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA7CSAsZ030599 for ietf-pkix-bks; Fri, 7 Nov 2003 04:28:10 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from center.kisa.or.kr ([211.252.150.11]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA7CS6kT030590 for <[e-mail]>; Fri, 7 Nov 2003 04:28:07 -0800 (PST) (envelope-from [e-mail])
Received: from khoprivaio (localhost [127.0.0.1]) by center.kisa.or.kr (8.11.7p1+Sun/8.11.1) with ESMTP id hA7CLVc19539; Fri, 7 Nov 2003 21:21:31 +0900 (KST)
Message-Id: <[e-mail]>
From: "Jongwook, Park" <[e-mail]>
To: "'Denis Pinkas'" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, "Russ Housley" <[e-mail]>, <[e-mail]>, "Bill Burr" <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: Comments on draft-ietf-pkix-sim-01
Date: Fri, 7 Nov 2003 21:27:31 +0900
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.2800.1165
In-Reply-To: <[e-mail]>
Thread-Index: AcOkovzVs90SaY34R7u9qWJ2nbE2GQAQ4ZHA
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>

Denis:

I think you catch on the basic idea of this draft exactly. Generally, the DN
in the 'subject' or 'subjectAltName' extension must be unique for each
person. However, it is very difficult to identify that the subject of
certificates is in fact the right person issued by CA since many people
often have the same name. 

To solve the above problem, this document don't use the DN for including the
non-public data since the information in DN can't meet the requirement and
is likely to disclosing private data. Alternatively, this draft proposes the
PII(Privacy Identification Information) structure which is encrypted form of
any sensitive identifier and finally put into the 'subjectAltName'
'GeneralizedName' 'otherName' field. This way can be regarded as a
complementary method for the shortcoming of the DN. 

PII structure is defined as follows :

PII = H(R || SIItype || H (R || P || SII))
where R : 160-bit random number, P : Password, SII : Sensitive
Identification Identifier and H : Cryptographically secure hash function
such as SHA-1, not MD2 or MD5.

PII structure can be applied to the various situations in different ways in
accordance with the RP's security environments. Please refer to the section
5. Example Usage of PII of the draft for details.
As a first example, let us suppose the RP already know the SII of the
certificate holder via out of band. In this case, certificate holder should
send R, P and his certificate containing the PII. Then RP can figure out if
the PII in cert and another PII' calculated itself from R, P and SII already
obtained are identical or not. It is definitely clear that R and P should be
transmitted in a secure channel. 

For another example, suppose such context where some people don't really
want to divulge any hint of his sensitive identifier to RPs. Maybe it's a
kind of same case why we need the Proof of Possession (POP) in RFC2510.
Anyway, please note the PII is the double-hashed structure. That is to say,
the subject send only intermediate value, H(R || P || SII) to RP without
disclosing the SII. Then relying party can calculates H ( R || SIItype ||
intermediate value) and verifies whether this value is equal to the PII in
the certificate. Finally, RP can guess the certificate holder has right
certificate even if it doesn't know the value of SII itself. 

Alike the above procedures, the certificate holder should be send R, P, SII
and PII in a cert if the RP doesn't have any information about the
certificate holder. The rest of the verification is similar to the first two
cases. 

In conclusion, PII structure is cryptographically secure and efficient
scheme to protect personal information although it seems to be complicated
at a glance.

Best regards,
Park.  


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Denis Pinkas
Sent: Friday, November 07, 2003 3:39 AM
To: pkix
Subject: Comments on draft-ietf-pkix-sim-01

I have always wondered about the goal of this document, since it is not
crystal clear.

It seems that the goal is to allow a relying party to determine whether the
subject of a particular certificate is the right person. This is currently
difficult since there might be not enough information in the DN and
disclosing more information in the DN would be against privacy.

Is it the basic motivation of this document ?

There is however an additional property of the "solution" (or is it a real
requirement ?) :

    Furthermore, the subject can prove to the
    relying party that they are associated with a valid identification
    with out disclosing the identifier.

This requirement is not crystal clear. What is a valid identification ?
If it is a bank account number, is it a number with the right Luhn code
computation in it and an existing bank identification number in it ?

Now the solution is rather complicated and it can be seen that an encryption
channel is required. A high level view of the goal(s?) and the advantages of
the solution is currently missing.

There might be a much simpler solution to solve the basic problem that is
trying to be solved:

Include in the certificate a hash of "personal information" that can be
revealed by the certifcate holder and thus any relying party to which this
information is disclosed can verify it (usually once).


Denis






Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6M5nkT032248 for <[e-mail]>; Thu, 6 Nov 2003 14:05:49 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA6M5nAR032247 for ietf-pkix-bks; Thu, 6 Nov 2003 14:05:49 -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.10/8.12.8) with ESMTP id hA6M5mkT032237 for <[e-mail]>; Thu, 6 Nov 2003 14:05:48 -0800 (PST) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id hA6M5CPf014502; Thu, 6 Nov 2003 17:05:13 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p06002019bbd074164ae8@[128.89.89.75]>
In-Reply-To:  <[e-mail].c om>
References:  <[e-mail].c om>
Date: Thu, 6 Nov 2003 17:01:20 -0500
To: "Stefan Santesson" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: Comments on draft-ietf-pkix-sonof3039-02
Cc: "Denis Pinkas" <[e-mail]>, "pkix" <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
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 21:46 +0000 11/6/03, Stefan Santesson wrote:
>This whole thing is a misunderstanding.
>
>Son of RFC 3039 has yet to go through WG last call.
>It has not been requested to be considered by IESG by the authors.
>
>/Stefan
>

Stefan is right.  My error. I was thinking of the Logotype I-D.

Sorry,

Steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6Lv2kT031899 for <[e-mail]>; Thu, 6 Nov 2003 13:57:02 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA6Lv22V031898 for ietf-pkix-bks; Thu, 6 Nov 2003 13:57:02 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-lul.microsoft.com (mail-lul.microsoft.com [212.157.154.44]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6LuxkT031887 for <[e-mail]>; Thu, 6 Nov 2003 13:57:00 -0800 (PST) (envelope-from [e-mail])
Received: from lul-imc-01.europe.corp.microsoft.com ([65.53.188.37]) by mail-lul.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 6 Nov 2003 22:57:06 +0100
Received: from 65.53.188.37 by lul-imc-01.europe.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 06 Nov 2003 22:57:06 +0100
Received: from EUR-MSG-03.europe.corp.microsoft.com ([65.53.192.44]) by lul-imc-01.europe.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 6 Nov 2003 22:57:06 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: Comments on draft-ietf-pkix-sonof3039-02
Date: Thu, 6 Nov 2003 21:56:50 -0000
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Comments on draft-ietf-pkix-sonof3039-02
Thread-Index: AcOkncsLTyimLl9NRm2MWvTbXeL9VgAEglxg
From: "Stefan Santesson" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>, "pkix" <[e-mail]>
X-OriginalArrivalTime: 06 Nov 2003 21:57:06.0373 (UTC) FILETIME=[EB338F50:01C3A4B0]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id hA6Lv0kT031894
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>

Denis,

I see that you have 2 objections and 1 concern,

The document title, key usage and whether it would obsolete RFC 3039.

The title is of minor interest right now. If the community would like to
change it then fine by me. Personally I think it would be a mistake and
not worth the trouble and confusion though.

It MUST however obsolete RFC 3039. We can't have both out there defining
the same extensions, attributes and semantics

Last, this document does NOT deal with the meaning of the key usage
bits. I suggest you take that discussion in relation with ITU X.509 and
RFC 3280 where that is handled.

Recommendations on which key usages to use relative to EU Qualified
Certificates is handled by ETSI TS 102280 and should be discussed there.
I see no value to regulate that in this profile.

I'm sorry that you won't be in Minneapolis for a face to face dialogue
on this.

/Stefan
 

> -----Original Message-----
> From: [e-mail]
[mailto:[e-mail]]
> On Behalf Of Denis Pinkas
> Sent: den 6 november 2003 19:11
> To: pkix
> Subject: Comments on draft-ietf-pkix-sonof3039-02
> 
> 
> Tim, Magnus and Stephan,
> 
> I have several MAJOR concerns:
> 
> I wonder if the title of this document is still appropriate:
> "Qualified Certificates Profile"
> 
> The scope is now (extract from the abstract):
> 
>     This document forms a certificate profile, based on RFC 3280, for
>     identity certificates issued to physical persons.
> 
> A more appropriate title would now be:
> 
> "Profile for identity certificates issued to physical persons"
> 
> There has been much confusion from the origin with the title which is
> ambiguous because some people think it is only related to Qualified
> Certificates according to the European Directive on Electronic
Signatures,
> while some others think the opposite. It is now clear that the
document
> does
> not only relate to this European Directive, hence why a change is the
> title
> is needed.
> 
> The wordings "qualified certificates" and "Qualified Certificates"
should
> be
> dropped from the document.
> 
> There is other argument where an implementation conforming to this
profile
> would not conform anymore to this European Directive. The issue
relates to
> the ability to identify the country where the CA is located using the
> country attribute of the DN, if DCs are used.
> 
> The other MAJOR issue has to do with the text about the DS and NR
bits.
> 
> I am asking Steve Kent as co-chair (since Tim Polk is one of the co-
> editors,
> I cannot ask him), to freeze this document until a "clarification"
about
> the
> meaning of these two bits is agreed at the ISO level and reflected in
a
> draft of son-of-RFC3280.
> 
> Finally, since I am also part of the ETSI ESI group dealing with
Qualified
> certificates, I can provide my personal view on this matter: there is
no
> need to issue a new document for RFC 3039. We need some stability.
> 
> So the final question would be whether this proposed document replaces
or
> not RFC 3039. If it gets a different title, then we have no need to
make
> RFC
> 3039 obsolete when/it this document is published.
> 
> Since I will not be at the Minneapolis meeting, I would appreciate
that my
> position is mentionned when this point will be discussed.
> 
> Denis
> 





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6LkikT031555 for <[e-mail]>; Thu, 6 Nov 2003 13:46:44 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA6LkiI0031554 for ietf-pkix-bks; Thu, 6 Nov 2003 13:46:44 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-lul.microsoft.com (mail-lul.microsoft.com [212.157.154.44]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6LkfkT031547 for <[e-mail]>; Thu, 6 Nov 2003 13:46:42 -0800 (PST) (envelope-from [e-mail])
Received: from lul-imc-01.europe.corp.microsoft.com ([65.53.188.37]) by mail-lul.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 6 Nov 2003 22:46:50 +0100
Received: from 65.53.188.37 by lul-imc-01.europe.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 06 Nov 2003 22:46:50 +0100
Received: from EUR-MSG-03.europe.corp.microsoft.com ([65.53.192.44]) by lul-imc-01.europe.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 6 Nov 2003 22:46:50 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: Comments on draft-ietf-pkix-sonof3039-02
Date: Thu, 6 Nov 2003 21:46:37 -0000
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Comments on draft-ietf-pkix-sonof3039-02
Thread-Index: AcOkrrRQsZwkVL5DR0iOeSxuWuZjvwAAH0Tw
From: "Stefan Santesson" <[e-mail]>
To: "Stephen Kent" <[e-mail]>, "Denis Pinkas" <[e-mail]>
Cc: "pkix" <[e-mail]>
X-OriginalArrivalTime: 06 Nov 2003 21:46:50.0343 (UTC) FILETIME=[7C04D770:01C3A4AF]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id hA6LkgkT031550
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 whole thing is a misunderstanding.

Son of RFC 3039 has yet to go through WG last call.
It has not been requested to be considered by IESG by the authors.

/Stefan
 

> -----Original Message-----
> From: [e-mail]
[mailto:[e-mail]]
> On Behalf Of Stephen Kent
> Sent: den 6 november 2003 21:21
> To: Denis Pinkas
> Cc: pkix
> Subject: Re: Comments on draft-ietf-pkix-sonof3039-02
> 
> 
> Denis,
> 
> Your comments are duly noted.  Steve Bellovin and I corresponded on
> this topic earlier today and agreed to wait until after the PKIX WG
> meeting next week before the IEGS would consider the document.
> 
> Stefan, please examine Denis' comments and respond by then.
> 
> Thanks,
> 
> Steve





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6KPskT028620 for <[e-mail]>; Thu, 6 Nov 2003 12:25:54 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA6KPs3H028619 for ietf-pkix-bks; Thu, 6 Nov 2003 12:25:54 -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.10/8.12.8) with ESMTP id hA6KPqkT028611 for <[e-mail]>; Thu, 6 Nov 2003 12:25:53 -0800 (PST) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id hA6KPHPd008556; Thu, 6 Nov 2003 15:25:17 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p06002013bbd05d4af305@[128.89.89.75]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Thu, 6 Nov 2003 15:20:47 -0500
To: Denis Pinkas <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Comments on draft-ietf-pkix-sonof3039-02
Cc: pkix <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
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>

Denis,

Your comments are duly noted.  Steve Bellovin and I corresponded on 
this topic earlier today and agreed to wait until after the PKIX WG 
meeting next week before the IEGS would consider the document.

Stefan, please examine Denis' comments and respond by then.

Thanks,

Steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6IeYkT023948 for <[e-mail]>; Thu, 6 Nov 2003 10:40:34 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA6IeY9B023947 for ietf-pkix-bks; Thu, 6 Nov 2003 10:40:34 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6IeXkT023940 for <[e-mail]>; Thu, 6 Nov 2003 10:40:33 -0800 (PST) (envelope-from [e-mail])
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id TAA14370 for <[e-mail]>; Thu, 6 Nov 2003 19:46:55 +0100
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id TAA08980 for <[e-mail]>; Thu, 6 Nov 2003 19:42:33 +0100
Message-ID: <[e-mail]>
Date: Thu, 06 Nov 2003 19:40:34 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: pkix <[e-mail]>
Subject: Comments on draft-ietf-pkix-certpathbuild-01
Content-Type: text/plain; charset=us-ascii; 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>

My comments about the way to find out the location of the repositories 
containing elements of the certification path have certainly been taken into 
consideration, ... but I cannot found additional text to reflect this.

Denis.




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6IcukT023910 for <[e-mail]>; Thu, 6 Nov 2003 10:38:56 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA6IcuZ0023909 for ietf-pkix-bks; Thu, 6 Nov 2003 10:38:56 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6IctkT023903 for <[e-mail]>; Thu, 6 Nov 2003 10:38:55 -0800 (PST) (envelope-from [e-mail])
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id TAA29384 for <[e-mail]>; Thu, 6 Nov 2003 19:45:17 +0100
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id TAA08819 for <[e-mail]>; Thu, 6 Nov 2003 19:40:55 +0100
Message-ID: <[e-mail]>
Date: Thu, 06 Nov 2003 19:38:56 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: pkix <[e-mail]>
Subject: Comments on draft-ietf-pkix-sim-01
Content-Type: text/plain; charset=us-ascii; 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>

I have always wondered about the goal of this document, since it is not 
crystal clear.

It seems that the goal is to allow a relying party to determine whether the 
subject of a particular certificate is the right person. This is currently 
difficult since there might be not enough information in the DN and 
disclosing more information in the DN would be against privacy.

Is it the basic motivation of this document ?

There is however an additional property of the "solution" (or is it a real 
requirement ?) :

    Furthermore, the subject can prove to the
    relying party that they are associated with a valid identification
    with out disclosing the identifier.

This requirement is not crystal clear. What is a valid identification ?
If it is a bank account number, is it a number with the right Luhn code 
computation in it and an existing bank identification number in it ?

Now the solution is rather complicated and it can be seen that an encryption 
channel is required. A high level view of the goal(s?) and the advantages of 
the solution is currently missing.

There might be a much simpler solution to solve the basic problem that is 
trying to be solved:

Include in the certificate a hash of "personal information" that can be 
revealed by the certifcate holder and thus any relying party to which this 
information is disclosed can verify it (usually once).


Denis





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6IApkT022450 for <[e-mail]>; Thu, 6 Nov 2003 10:10:51 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA6IApA3022449 for ietf-pkix-bks; Thu, 6 Nov 2003 10:10:51 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6IAokT022440 for <[e-mail]>; Thu, 6 Nov 2003 10:10:50 -0800 (PST) (envelope-from [e-mail])
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id TAA18818 for <[e-mail]>; Thu, 6 Nov 2003 19:17:11 +0100
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id TAA06522 for <[e-mail]>; Thu, 6 Nov 2003 19:12:49 +0100
Message-ID: <[e-mail]>
Date: Thu, 06 Nov 2003 19:10:51 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: pkix <[e-mail]>
Subject: Comments on draft-ietf-pkix-sonof3039-02
Content-Type: text/plain; charset=us-ascii; 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>

Tim, Magnus and Stephan,

I have several MAJOR concerns:

I wonder if the title of this document is still appropriate:
"Qualified Certificates Profile"

The scope is now (extract from the abstract):

    This document forms a certificate profile, based on RFC 3280, for
    identity certificates issued to physical persons.

A more appropriate title would now be:

"Profile for identity certificates issued to physical persons"

There has been much confusion from the origin with the title which is 
ambiguous because some people think it is only related to Qualified 
Certificates according to the European Directive on Electronic Signatures, 
while some others think the opposite. It is now clear that the document does 
not only relate to this European Directive, hence why a change is the title 
is needed.

The wordings "qualified certificates" and "Qualified Certificates" should be 
dropped from the document.

There is other argument where an implementation conforming to this profile 
would not conform anymore to this European Directive. The issue relates to 
the ability to identify the country where the CA is located using the 
country attribute of the DN, if DCs are used.

The other MAJOR issue has to do with the text about the DS and NR bits.

I am asking Steve Kent as co-chair (since Tim Polk is one of the co-editors, 
I cannot ask him), to freeze this document until a "clarification" about the 
meaning of these two bits is agreed at the ISO level and reflected in a 
draft of son-of-RFC3280.

Finally, since I am also part of the ETSI ESI group dealing with Qualified 
certificates, I can provide my personal view on this matter: there is no 
need to issue a new document for RFC 3039. We need some stability.

So the final question would be whether this proposed document replaces or 
not RFC 3039. If it gets a different title, then we have no need to make RFC 
3039 obsolete when/it this document is published.

Since I will not be at the Minneapolis meeting, I would appreciate that my 
position is mentionned when this point will be discussed.

Denis



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6FlFkT015251 for <[e-mail]>; Thu, 6 Nov 2003 07:47:15 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA6FlFi1015249 for ietf-pkix-bks; Thu, 6 Nov 2003 07:47:15 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mystic2.trustcenter.de (mystic2.trustcenter.de [193.194.157.50]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6FlDkT015235 for <[e-mail]>; Thu, 6 Nov 2003 07:47:14 -0800 (PST) (envelope-from [e-mail])
Received: (from uucp@localhost) by mystic2.trustcenter.de (8.11.7+Sun/8.11.7) id hA6Fl8T03704 for <[e-mail]>; Thu, 6 Nov 2003 16:47:09 +0100 (MET)
Received: from venus.trustcenter.de(192.168.202.4) by mystic2.trustcenter.de via csmap (V6.0) id srcAAA9Ea4oh; Thu, 6 Nov 03 16:47:07 +0100
Received: from trustcenter.de (titan.trustcenter.de [192.168.200.244]) by venus.trustcenter.de (8.12.9/TC TrustCenter Mailserver) with ESMTP id hA6Fl7Mu026980 for <[e-mail]>; Thu, 6 Nov 2003 16:47:07 +0100
Message-ID: <[e-mail]>
Date: Thu, 06 Nov 2003 16:47:07 +0100
From: Juergen Brauckmann <[e-mail]>
Organization: TC TrustCenter AG
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.3.1) Gecko/20030425
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Question on use of AIA extension
Content-Type: text/plain; charset=us-ascii; 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>

Hi.

I'm trying to understand the semantics of the Authority Info Access 
extension with id-ad-caIssuers access method. The wording in RFC3280 
seems to say that the accessLocation must point to any certificate in 
the cert chain that is at least two levels above the certificate which 
contains the AIA extension:

	"The id-ad-caIssuers OID is used when the additional information
	lists CAs that have issued certificates superior to the CA that
	issued the certificate containing this extension"

However, chapter 6.2 of draft-ietf-pkix-certpathbuild-01.txt states that 
an id-ad-caIssuers may point to a certificate for the issuer of the 
certificate containing the extension.

The question was already raised last year; it would be nice if someone 
could confirm which interpretation is correct.

Thanks a lot,
     Juergen

>     * To: "PKIX" <ietf-pkix@xxxxxxx>
>     * Subject: Question on use of AIA extension
>     * From: "Sarbari Gupta" <sarbari@xxxxxxxxxxxxxxxxxxx>
>     * Date: Fri, 22 Nov 2002 12:32:18 -0500
> 
> I was reviewing the description for the AIA extension in RFC 3280, and
> noticed the following text:
> 
> 	"The id-ad-caIssuers OID is used when the additional information
> 	lists CAs that have issued certificates superior to the CA that
> 	issued the certificate containing this extension"
> 
> The above seems to imply that the AIA extension (if populated) within an EE
> cert, should point to the "grandparent certificate" rather than the "parent
> certificate". Am I interpreting this correctly?
> 
> I was under the impression that CA vendors who make use of this extension
> (such as Microsoft) use the AIA extension to point to the "parent
> certificate". Is this consistent with the RFC 3280 specification?
> 
> Can someone please clarify.
> 
> ==============================
> Sarbari Gupta
> Electrosoft Services, Inc.
> 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6FgBkT014986 for <[e-mail]>; Thu, 6 Nov 2003 07:42:11 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA6FgBew014985 for ietf-pkix-bks; Thu, 6 Nov 2003 07:42:11 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6FgAkT014979 for <[e-mail]>; Thu, 6 Nov 2003 07:42:10 -0800 (PST) (envelope-from [e-mail])
Received: from wchokhani (dpvc-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id hA6FcXPJ006442; Thu, 6 Nov 2003 10:38:33 -0500
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>, "'OSI Directory List'" <[e-mail]>
Cc: "Tim Polk" <[e-mail]>, "Russell Brown" <[e-mail]>
Subject: RE: CRL Certification Path
Date: Thu, 6 Nov 2003 10:38:28 -0500
Message-ID: <004701c3a47c$099cb230$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id hA6FgBkT014981
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>

Denis:

My reading of X.509 and RFC 3280 is that "the delegation" is referring to
the Indirect CRL Issuer name assertion in the CRL Distribution Point
extension of the certificate.  It does not imply or mandate that the CA
issue a certificate to the CRL issuer.

I would like RFC 3280 editors' view on this.

In terms of delegation to only an upper CA, you are misinterpreting my
text..  The reason I said "whichever terminates first" is to accommodate
your scenario of the certificate issuing CA issuing a certificate to
Indirect CRL issuer.

-----Original Message-----
From: Denis Pinkas [mailto:[e-mail]] 
Sent: Thursday, November 06, 2003 10:23 AM
To: Santosh Chokhani
Cc: [e-mail]; 'OSI Directory List'
Subject: Re: CRL Certification Path


Santosh,

> Denis:

> Rules 1 through 3 are only when certificate issuer is the same as the 
> CRL issuer.
> 
> My original post had a single rule for indirect CRL (it emanate from 
> the same trust anchor.  The rule you propose is secure, but much more 
> restrictive and represents a change in both X.509 and RFC 3280.
                                ^^^^^^
I would say a clarification.

RFC 3280 states:

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

I do not believe that this means an upper CA in the chain, but *the* CA 
which isues certificates and is responsible to provide revocation status 
information using either CRLs or OCSP responses.

RFC 3280 states:

    However, a CA may delegate this responsibility to
    another trusted authority.  Whenever the CRL issuer is not the CA
    that issued the certificates, the CRL is referred to as an indirect
    CRL.

When CRLs are used, CAs are also responsible to place the location of the 
CRL issuer in the CRL DP extension for the certificates they issue. It is 
thus not an upper CA that is responsible for this, as your proposed text 
would permit for this.

Your text below is thus not appriopriate.

Denis


 > Neither
> require certificate based delegation of the indirect CRL issuer by the 
> certificate issuer.  This change in the standard may cause backward 
> compatibility problem (I know at least one PKI that does Indirect CRL, 
> but without certificate based delegation by the certificate issuer.  I 
> think the following is appropriate for the Indirect CRL:
> 
> 1.	Certification path for the Indirect CRL shall begin with the same
> trust anchor as the certification path for the certificate whose 
> status is being checked
> 
> 2.	The issuer names in the certification path for the CRL shall match
> one for one with the issuer names in the certification path for the 
> certificate, starting with the trust anchor and ending with the 
> certificate issued to the Indirect CRL issuer or the certificate 
> issuer, whichever terminates first.  During name matching, all 
> self-issued certificates in both paths shall be ignored.
> 
> 3.	Certification path for the CRL shall be valid for at least one of
> the certificate policies acceptable to the relying party.
> 
> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: Wednesday, November 05, 2003 12:17 PM
> To: Santosh Chokhani
> Cc: Tim Polk; Russell Housley; Laura Boyer; Steve Kent; [e-mail];
> 'OSI Directory List'
> Subject: Re: CRL Certification Path
> 
> 
> Santosh,
> 
> Thank you for raising the issue.
> 
> I agree that the current text is too vague.
> 
> 
>>Editors of 3280 and X.509:
>>
>>There is a security hole in the X.509 and RFC 3280 certification path 
>>validation for CRL, which can be exploited or result in undesirable 
>>behavior when global name uniqueness among various PKI is not assured.
>>
>>The problem manifests itself when a relying party can not verify 
>>signature on a CRL using the certificate issuer public key and thus 
>>needs to build a certification path for the CRL.  This could occur 
>>when a CA has re-keyed after the certificate whose revocation status 
>>is being checked, was issued.
>>
>>Neither RFC 3280 nor X.509 require that the certification path for the 
>>CRL have some semblance to the certification path for the certificate 
>>whose status is being checked.  For example, Section 6.3.3 Step ?f? of 
>>RFC 3280 states only the following for the certification path for the 
>>CRL:
>>
>>?Obtain and validate the certification path for the complete CRL 
>>issuer.  If a key usage extension is present in the CRL issuer's 
>>certificate, verify that the cRLSign bit is set.?
> 
> 
>>A set of rules along the following lines should be added to RFC 3280
>>and
>>to X.509:
>>
>>      1.      Certification path for the CRL shall begin with the same
>>      trust anchor as the certification path for the certificate whose
>>      status is being checked
>>
>>      2.      The issuer names in the certification path for the CRL
>>      shall match one for one with the issuer names in the certification
>>      path for the certificate, starting with the trust anchor and
>>      ending with the last certificate in the certification path for the
>>      CRL.  During name matching, all self-issued certificates in both
>>      paths shall be ignored.
> 
> 
> This text is not sufficient.
> 
> The CA can nominate a CRL Issuer for the management of the revocation 
> status
> 
> of the certificates that it issues and thus the path is one leg 
> longer,
> since the Issuing CA issues a certificate to nominate the CRL issuer. The 
> text above does not capture this point.
> 
> Denis
> 
> 
> 
> 
>>      3.      Certification path for the CRL shall be valid for at least
>>      one of the certificate policies acceptable to the relying party.
>>
>>Rule 3 above is less restrictive and more appropriate rule would be
>>
>>Alternative rule 3: Certification path for the CRL shall be valid for
>>at
>>least the same certificate policies that the certification path for the 
>>certificate is valid for.  This comparison shall be performed by 
>>converting the policies to the relying party domain.
>>
>>An obvious question comes to mind:
>>
>>      §       What about Indirect CRL?
>>
>>Requiring that the Indirect CRL Issuer be from the trust domain as the 
>>certificate is a good idea and not overly restrictive given that we 
>>can not guarantee global name uniqueness among all the PKIs trusted by 
>>a relying party.
>>
>>Another alternative to all of the above pontification is to require
>>the
>>relying parties to ensure that all trust anchors are constrained to 
>>disjoint name spaces, i.e.,  intersection between the permitted name 
>>spaces for any two trust anchors is null.
>>
>>
>>Santosh Chokhani
>>Orion Security Solutions, Inc.
>>1489 Chain Bridge Road, Suite 300
>>McLean, Virginia 22101
>>[phone]  Ext. 35(voice)
>>[phone] (Fax)
>>[e-mail]
>>Visit our Web site
>>http://www.orionsec.com
>>
>>
> 
> 
> 
> 
> 






Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6FN1kT014110 for <[e-mail]>; Thu, 6 Nov 2003 07:23:01 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA6FN1JG014109 for ietf-pkix-bks; Thu, 6 Nov 2003 07:23:01 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6FMxkT014103 for <[e-mail]>; Thu, 6 Nov 2003 07:23:00 -0800 (PST) (envelope-from [e-mail])
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA26968; Thu, 6 Nov 2003 16:29:18 +0100
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id QAA25092; Thu, 6 Nov 2003 16:24:56 +0100
Message-ID: <[e-mail]>
Date: Thu, 06 Nov 2003 16:22:57 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Santosh Chokhani <[e-mail]>
CC: [e-mail], "'OSI Directory List'" <[e-mail]>
Subject: Re: CRL Certification Path
References: <000201c3a466$80731130$[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id hA6FN1kT014105
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,

> Denis:

> Rules 1 through 3 are only when certificate issuer is the same as the CRL
> issuer.
> 
> My original post had a single rule for indirect CRL (it emanate from the
> same trust anchor.  The rule you propose is secure, but much more
> restrictive and represents a change in both X.509 and RFC 3280.  
                                ^^^^^^
I would say a clarification.

RFC 3280 states:

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

I do not believe that this means an upper CA in the chain, but *the* CA 
which isues certificates and is responsible to provide revocation status 
information using either CRLs or OCSP responses.

RFC 3280 states:

    However, a CA may delegate this responsibility to
    another trusted authority.  Whenever the CRL issuer is not the CA
    that issued the certificates, the CRL is referred to as an indirect
    CRL.

When CRLs are used, CAs are also responsible to place the location of the 
CRL issuer in the CRL DP extension for the certificates they issue. It is 
thus not an upper CA that is responsible for this, as your proposed text 
would permit for this.

Your text below is thus not appriopriate.

Denis


 > Neither
> require certificate based delegation of the indirect CRL issuer by the
> certificate issuer.  This change in the standard may cause backward
> compatibility problem (I know at least one PKI that does Indirect CRL, but
> without certificate based delegation by the certificate issuer.  I think the
> following is appropriate for the Indirect CRL:
> 
> 1.	Certification path for the Indirect CRL shall begin with the same
> trust anchor as the certification path for the certificate whose status is
> being checked
> 
> 2.	The issuer names in the certification path for the CRL shall match
> one for one with the issuer names in the certification path for the
> certificate, starting with the trust anchor and ending with the certificate
> issued to the Indirect CRL issuer or the certificate issuer, whichever
> terminates first.  During name matching, all self-issued certificates in
> both paths shall be ignored.
> 
> 3.	Certification path for the CRL shall be valid for at least one of
> the certificate policies acceptable to the relying party.
> 
> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]] 
> Sent: Wednesday, November 05, 2003 12:17 PM
> To: Santosh Chokhani
> Cc: Tim Polk; Russell Housley; Laura Boyer; Steve Kent; [e-mail];
> 'OSI Directory List'
> Subject: Re: CRL Certification Path
> 
> 
> Santosh,
> 
> Thank you for raising the issue.
> 
> I agree that the current text is too vague.
> 
> 
>>Editors of 3280 and X.509:
>>
>>There is a security hole in the X.509 and RFC 3280 certification path
>>validation for CRL, which can be exploited or result in undesirable 
>>behavior when global name uniqueness among various PKI is not assured.
>>
>>The problem manifests itself when a relying party can not verify
>>signature on a CRL using the certificate issuer public key and thus 
>>needs to build a certification path for the CRL.  This could occur when 
>>a CA has re-keyed after the certificate whose revocation status is being 
>>checked, was issued.
>>
>>Neither RFC 3280 nor X.509 require that the certification path for the
>>CRL have some semblance to the certification path for the certificate 
>>whose status is being checked.  For example, Section 6.3.3 Step ?f? of 
>>RFC 3280 states only the following for the certification path for the CRL:
>>
>>?Obtain and validate the certification path for the complete CRL
>>issuer.  If a key usage extension is present in the CRL issuer's 
>>certificate, verify that the cRLSign bit is set.?
> 
> 
>>A set of rules along the following lines should be added to RFC 3280 
>>and
>>to X.509:
>>
>>      1.      Certification path for the CRL shall begin with the same
>>      trust anchor as the certification path for the certificate whose
>>      status is being checked
>>
>>      2.      The issuer names in the certification path for the CRL
>>      shall match one for one with the issuer names in the certification
>>      path for the certificate, starting with the trust anchor and
>>      ending with the last certificate in the certification path for the
>>      CRL.  During name matching, all self-issued certificates in both
>>      paths shall be ignored.
> 
> 
> This text is not sufficient.
> 
> The CA can nominate a CRL Issuer for the management of the revocation status
> 
> of the certificates that it issues and thus the path is one leg longer, 
> since the Issuing CA issues a certificate to nominate the CRL issuer. The 
> text above does not capture this point.
> 
> Denis
> 
> 
> 
> 
>>      3.      Certification path for the CRL shall be valid for at least
>>      one of the certificate policies acceptable to the relying party.
>>
>>Rule 3 above is less restrictive and more appropriate rule would be
>>
>>Alternative rule 3: Certification path for the CRL shall be valid for 
>>at
>>least the same certificate policies that the certification path for the 
>>certificate is valid for.  This comparison shall be performed by 
>>converting the policies to the relying party domain.
>>
>>An obvious question comes to mind:
>>
>>      §       What about Indirect CRL?
>>
>>Requiring that the Indirect CRL Issuer be from the trust domain as the
>>certificate is a good idea and not overly restrictive given that we can 
>>not guarantee global name uniqueness among all the PKIs trusted by a 
>>relying party.
>>
>>Another alternative to all of the above pontification is to require 
>>the
>>relying parties to ensure that all trust anchors are constrained to 
>>disjoint name spaces, i.e.,  intersection between the permitted name 
>>spaces for any two trust anchors is null.
>>
>>
>>Santosh Chokhani
>>Orion Security Solutions, Inc.
>>1489 Chain Bridge Road, Suite 300
>>McLean, Virginia 22101
>>[phone]  Ext. 35(voice)
>>[phone] (Fax)
>>[e-mail]
>>Visit our Web site
>>http://www.orionsec.com
>>
>>
> 
> 
> 
> 
> 





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6D90kT008654 for <[e-mail]>; Thu, 6 Nov 2003 05:09:00 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA6D906R008653 for ietf-pkix-bks; Thu, 6 Nov 2003 05:09:00 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6D8xkT008648 for <[e-mail]>; Thu, 6 Nov 2003 05:09:00 -0800 (PST) (envelope-from [e-mail])
Received: from wchokhani (dpvc-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id hA6D5oPJ021511; Thu, 6 Nov 2003 08:05:50 -0500
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: RE: CRL Certification Path
Date: Thu, 6 Nov 2003 08:05:45 -0500
Message-ID: <000301c3a466$b3dc6210$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
Importance: Normal
In-Reply-To: 
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id hA6D90kT008649
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>

Thomas:

Generally, trust anchor is revoked using out of band means such as manually
deleting it.  Neither X.509 nor RFC 3280 require revocation status checking
of a trust anchor.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] 
Sent: Thursday, November 06, 2003 4:27 AM
To: [e-mail]; [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail];
[e-mail]; [e-mail]; [e-mail]
Subject: AW: CRL Certification Path


Denis, Santosh,

there is another reason why the trust anchor for the certificates
verification path should be different to the trust anchor for the CRLs
verification path. What happens when the certificates trust anchor has to be
revoked? If the root (trust anchor) signs the CRL containing its own
certificate the CRLs verification path becomes invalid.

Regards

Thomas Beckmann
 -------------------------------------
 Thomas Beckmann
 Fachgruppenleiter PKI und Trustcenter
 
 SchlumbergerSema  -
 Competence Center Informatik GmbH 
 Lohberg 10
 D-49716 Meppen
 
 Tel:[phone]
 Mobil: [phone]  
 Fax: [phone]

 EMail: [e-mail]
 Internet: www.SchlumbergerSema.de


> -----Ursprüngliche Nachricht-----
> Von: Denis Pinkas [mailto:[e-mail]]
> Gesendet: Mittwoch, 5. November 2003 18:17
> An: Santosh Chokhani
> Cc: Tim Polk; Russell Housley; Laura Boyer; Steve Kent;
> [e-mail]; 'OSI Directory List'
> Betreff: Re: CRL Certification Path
> 
> 
> 
> Santosh,
> 
> Thank you for raising the issue.
> 
> I agree that the current text is too vague.
> 
> > Editors of 3280 and X.509:
> > 
> > There is a security hole in the X.509 and RFC 3280
> certification path
> > validation for CRL, which can be exploited or result in undesirable 
> > behavior when global name uniqueness among various PKI is
> not assured.
> > 
> > The problem manifests itself when a relying party can not verify 
> > signature on a CRL using the certificate issuer public key and thus 
> > needs to build a certification path for the CRL.  This
> could occur when
> > a CA has re-keyed after the certificate whose revocation
> status is being
> > checked, was issued.
> > 
> > Neither RFC 3280 nor X.509 require that the certification
> path for the
> > CRL have some semblance to the certification path for the
> certificate
> > whose status is being checked.  For example, Section 6.3.3
> Step ?f? of
> > RFC 3280 states only the following for the certification
> path for the CRL:
> > 
> > ?Obtain and validate the certification path for the complete CRL 
> > issuer.  If a key usage extension is present in the CRL issuer's 
> > certificate, verify that the cRLSign bit is set.?
> 
> > A set of rules along the following lines should be added to
> RFC 3280 and
> > to X.509:
> > 
> >       1.      Certification path for the CRL shall begin 
> with the same
> >       trust anchor as the certification path for the
> certificate whose
> >       status is being checked
> > 
> >       2.      The issuer names in the certification path for the CRL
> >       shall match one for one with the issuer names in the
> certification
> >       path for the certificate, starting with the trust anchor and
> >       ending with the last certificate in the certification
> path for the
> >       CRL.  During name matching, all self-issued
> certificates in both
> >       paths shall be ignored.
> 
> This text is not sufficient.
> 
> The CA can nominate a CRL Issuer for the management of the revocation 
> status of the certificates that it issues and thus the path is one
> leg longer, 
> since the Issuing CA issues a certificate to nominate the CRL 
> issuer. The 
> text above does not capture this point.
> 
> Denis
> 
> 
> 
> >       3.      Certification path for the CRL shall be valid 
> for at least
> >       one of the certificate policies acceptable to the
> relying party.
> > 
> > Rule 3 above is less restrictive and more appropriate rule would be
> > 
> > Alternative rule 3: Certification path for the CRL shall be
> valid for at
> > least the same certificate policies that the certification
> path for the
> > certificate is valid for.  This comparison shall be performed by 
> > converting the policies to the relying party domain.
> > 
> > An obvious question comes to mind:
> > 
> >       §       What about Indirect CRL?
> > 
> > Requiring that the Indirect CRL Issuer be from the trust
> domain as the
> > certificate is a good idea and not overly restrictive given
> that we can
> > not guarantee global name uniqueness among all the PKIs
> trusted by a
> > relying party.
> > 
> > Another alternative to all of the above pontification is to
> require the
> > relying parties to ensure that all trust anchors are constrained to 
> > disjoint name spaces, i.e.,  intersection between the
> permitted name
> > spaces for any two trust anchors is null.
> > 
> > 
> > Santosh Chokhani
> > Orion Security Solutions, Inc.
> > 1489 Chain Bridge Road, Suite 300
> > McLean, Virginia 22101
> > [phone]  Ext. 35(voice)
> > [phone] (Fax)
> > [e-mail]
> > Visit our Web site
> > http://www.orionsec.com
> > 
> > 
> 
> 
> 
> 




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6D7akT008620 for <[e-mail]>; Thu, 6 Nov 2003 05:07:36 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA6D7ave008619 for ietf-pkix-bks; Thu, 6 Nov 2003 05:07:36 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6D7ZkT008613 for <[e-mail]>; Thu, 6 Nov 2003 05:07:35 -0800 (PST) (envelope-from [e-mail])
Received: from wchokhani (dpvc-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id hA6D4OPJ021155; Thu, 6 Nov 2003 08:04:24 -0500
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>, "'OSI Directory List'" <[e-mail]>
Subject: RE: CRL Certification Path
Date: Thu, 6 Nov 2003 08:04:19 -0500
Message-ID: <000201c3a466$80731130$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id hA6D7akT008614
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>

Denis:

Rules 1 through 3 are only when certificate issuer is the same as the CRL
issuer.

My original post had a single rule for indirect CRL (it emanate from the
same trust anchor.  The rule you propose is secure, but much more
restrictive and represents a change in both X.509 and RFC 3280.  Neither
require certificate based delegation of the indirect CRL issuer by the
certificate issuer.  This change in the standard may cause backward
compatibility problem (I know at least one PKI that does Indirect CRL, but
without certificate based delegation by the certificate issuer.  I think the
following is appropriate for the Indirect CRL:

1.	Certification path for the Indirect CRL shall begin with the same
trust anchor as the certification path for the certificate whose status is
being checked

2.	The issuer names in the certification path for the CRL shall match
one for one with the issuer names in the certification path for the
certificate, starting with the trust anchor and ending with the certificate
issued to the Indirect CRL issuer or the certificate issuer, whichever
terminates first.  During name matching, all self-issued certificates in
both paths shall be ignored.

3.	Certification path for the CRL shall be valid for at least one of
the certificate policies acceptable to the relying party.

-----Original Message-----
From: Denis Pinkas [mailto:[e-mail]] 
Sent: Wednesday, November 05, 2003 12:17 PM
To: Santosh Chokhani
Cc: Tim Polk; Russell Housley; Laura Boyer; Steve Kent; [e-mail];
'OSI Directory List'
Subject: Re: CRL Certification Path


Santosh,

Thank you for raising the issue.

I agree that the current text is too vague.

> Editors of 3280 and X.509:
> 
> There is a security hole in the X.509 and RFC 3280 certification path
> validation for CRL, which can be exploited or result in undesirable 
> behavior when global name uniqueness among various PKI is not assured.
> 
> The problem manifests itself when a relying party can not verify
> signature on a CRL using the certificate issuer public key and thus 
> needs to build a certification path for the CRL.  This could occur when 
> a CA has re-keyed after the certificate whose revocation status is being 
> checked, was issued.
> 
> Neither RFC 3280 nor X.509 require that the certification path for the
> CRL have some semblance to the certification path for the certificate 
> whose status is being checked.  For example, Section 6.3.3 Step ?f? of 
> RFC 3280 states only the following for the certification path for the CRL:
> 
> ?Obtain and validate the certification path for the complete CRL
> issuer.  If a key usage extension is present in the CRL issuer's 
> certificate, verify that the cRLSign bit is set.?

> A set of rules along the following lines should be added to RFC 3280 
> and
> to X.509:
> 
>       1.      Certification path for the CRL shall begin with the same
>       trust anchor as the certification path for the certificate whose
>       status is being checked
> 
>       2.      The issuer names in the certification path for the CRL
>       shall match one for one with the issuer names in the certification
>       path for the certificate, starting with the trust anchor and
>       ending with the last certificate in the certification path for the
>       CRL.  During name matching, all self-issued certificates in both
>       paths shall be ignored.

This text is not sufficient.

The CA can nominate a CRL Issuer for the management of the revocation status

of the certificates that it issues and thus the path is one leg longer, 
since the Issuing CA issues a certificate to nominate the CRL issuer. The 
text above does not capture this point.

Denis



>       3.      Certification path for the CRL shall be valid for at least
>       one of the certificate policies acceptable to the relying party.
> 
> Rule 3 above is less restrictive and more appropriate rule would be
> 
> Alternative rule 3: Certification path for the CRL shall be valid for 
> at
> least the same certificate policies that the certification path for the 
> certificate is valid for.  This comparison shall be performed by 
> converting the policies to the relying party domain.
> 
> An obvious question comes to mind:
> 
>       §       What about Indirect CRL?
> 
> Requiring that the Indirect CRL Issuer be from the trust domain as the
> certificate is a good idea and not overly restrictive given that we can 
> not guarantee global name uniqueness among all the PKIs trusted by a 
> relying party.
> 
> Another alternative to all of the above pontification is to require 
> the
> relying parties to ensure that all trust anchors are constrained to 
> disjoint name spaces, i.e.,  intersection between the permitted name 
> spaces for any two trust anchors is null.
> 
> 
> Santosh Chokhani
> Orion Security Solutions, Inc.
> 1489 Chain Bridge Road, Suite 300
> McLean, Virginia 22101
> [phone]  Ext. 35(voice)
> [phone] (Fax)
> [e-mail]
> Visit our Web site
> http://www.orionsec.com
> 
> 






Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA62WLkT013077 for <[e-mail]>; Wed, 5 Nov 2003 18:32:21 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA62WLrN013076 for ietf-pkix-bks; Wed, 5 Nov 2003 18:32:21 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from hotmail.com (bay7-dav53.bay7.hotmail.com [64.4.10.46]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA62WJkT013069 for <[e-mail]>; Wed, 5 Nov 2003 18:32:19 -0800 (PST) (envelope-from [e-mail])
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 5 Nov 2003 18:32:17 -0800
Received: from 202.196.53.252 by bay7-dav53.bay7.hotmail.com with DAV; Thu, 06 Nov 2003 02:32:17 +0000
X-Originating-IP: [202.196.53.252]
X-Originating-Email: [[e-mail]]
From: "=?GB2312?Q?=D0=A1=D0=C2?=" <[e-mail]>
To: "[e-mail]" <[e-mail]>
Subject: 
X-mailer: Foxmail 4.2 [cn]
Mime-Version: 1.0
Content-Type: text/plain; charset="GB2312"
Date: Thu, 6 Nov 2003 10:36:4 +0800
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 06 Nov 2003 02:32:17.0553 (UTC) FILETIME=[3237F010:01C3A40E]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id hA62WJkT013072
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>

ietf-pkix
	ÓÃopensslÉêÇëÖ¤Ê飬³É¹¦ºóÖ»²úÉúÒ»¶Ô¹«Ë½Ô¿£¬²¢ÇÒÊÇ×Ô¼ºÇ©Êð×Ô¼ºµÄ£¬ÇëÎÊÕâºÍÊý×ÖÇ©ÃûÓÐʲôÇø±ðÂð£¿




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5JAtkT095653 for <[e-mail]>; Wed, 5 Nov 2003 11:10:55 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA5JAtQh095652 for ietf-pkix-bks; Wed, 5 Nov 2003 11:10:55 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5JArkT095646 for <[e-mail]>; Wed, 5 Nov 2003 11:10:53 -0800 (PST) (envelope-from [e-mail])
Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id hA5JAsW15828; Wed, 5 Nov 2003 11:10:54 -0800 (PST)
Message-Id: <[e-mail]>
To: IETF-Announce: ;
Subject: RFC 3647 on Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework
Cc: [e-mail], [e-mail]
From: [e-mail]
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Wed, 05 Nov 2003 11:10:53 -0800
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 Request for Comments is now available in online RFC libraries.


        RFC 3647

        Title:      Internet X.509 Public Key Infrastructure
                    Certificate Policy and Certification Practices
                    Framework
        Author(s):  S. Chokhani, W. Ford, R. Sabett, C. Merrill, S. Wu
        Status:     Informational
        Date:       November 2003
        Mailbox:    [e-mail], [e-mail],
                    [e-mail], [e-mail],
                    [e-mail]
        Pages:      94
        Characters: 228124
        Obsoletes:  2527

        I-D Tag:    draft-ietf-pkix-ipki-new-rfc2527-02.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3647.txt


This document presents a framework to assist the writers of
certificate policies or certification practice statements for
participants within public key infrastructures, such as
certification authorities, policy authorities, and communities of
interest that wish to rely on certificates.  In particular, the
framework provides a comprehensive list of topics that potentially
(at the writer's discretion) need to be covered in a certificate
policy or a certification practice statement.  This document
supersedes RFC 2527.

This document is a product of the Public-Key Infrastructure (X.509)
Working Group of the IETF.

This memo provides information for the Internet community.  It does
not specify an Internet standard of any kind.  Distribution of this
memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [e-mail].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [e-mail].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [e-mail] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [e-mail]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
[e-mail].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.

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

RETRIEVE: rfc
DOC-ID: rfc3647

--OtherAccess
Content-Type:   Message/External-body;
        name="rfc3647.txt";
        site="ftp.isi.edu";
        access-type="anon-ftp";
        directory="in-notes"

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

--OtherAccess--
--NextPart--


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5J8TkT095515 for <[e-mail]>; Wed, 5 Nov 2003 11:08:29 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA5J8T8h095514 for ietf-pkix-bks; Wed, 5 Nov 2003 11:08:29 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5J8SkT095509 for <[e-mail]>; Wed, 5 Nov 2003 11:08:28 -0800 (PST) (envelope-from [e-mail])
Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id hA5J8TW14588; Wed, 5 Nov 2003 11:08:29 -0800 (PST)
Message-Id: <[e-mail]>
To: IETF-Announce: ;
Subject: RFC 3628 on Policy Requirements for Time-Stamping Authorities (TSAs)
Cc: [e-mail], [e-mail]
From: [e-mail]
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Wed, 05 Nov 2003 11:08:28 -0800
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 Request for Comments is now available in online RFC libraries.


        RFC 3628

        Title:      Policy Requirements for Time-Stamping Authorities
                    (TSAs)
        Author(s):  D. Pinkas, N. Pope, J. Ross
        Status:     Informational
        Date:       November 2003
        Mailbox:    [e-mail], [e-mail],
                    [e-mail]
        Pages:      43
        Characters: 92941
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-pkix-pr-tsa-05.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3628.txt


This document defines requirements for a baseline time-stamp policy
for Time-Stamping Authorities (TSAs) issuing time-stamp tokens,
supported by public key certificates, with an accuracy of one
second or better.  A TSA may define its own policy which enhances
the policy defined in this document.  Such a policy shall
incorporate or further constrain the requirements identified in this
document.

This memo provides information for the Internet community.  It does
not specify an Internet standard of any kind.  Distribution of this
memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [e-mail].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [e-mail].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [e-mail] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [e-mail]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
[e-mail].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.

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

RETRIEVE: rfc
DOC-ID: rfc3628

--OtherAccess
Content-Type:   Message/External-body;
        name="rfc3628.txt";
        site="ftp.isi.edu";
        access-type="anon-ftp";
        directory="in-notes"

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

--OtherAccess--
--NextPart--


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5HHOkT090437 for <[e-mail]>; Wed, 5 Nov 2003 09:17:24 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA5HHOZr090436 for ietf-pkix-bks; Wed, 5 Nov 2003 09:17:24 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5HHLkT090429 for <[e-mail]>; Wed, 5 Nov 2003 09:17:22 -0800 (PST) (envelope-from [e-mail])
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id SAA81474; Wed, 5 Nov 2003 18:23:36 +0100
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id SAA04814; Wed, 5 Nov 2003 18:19:13 +0100
Message-ID: <[e-mail]>
Date: Wed, 05 Nov 2003 18:17:14 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Santosh Chokhani <[e-mail]>
CC: Tim Polk <[e-mail]>, Russell Housley <[e-mail]>, Laura Boyer <[e-mail]>, Steve Kent <[e-mail]>, [e-mail], "'OSI Directory List'" <[e-mail]>
Subject: Re: CRL Certification Path
References: <006101c3a2e8$254d2130$[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id hA5HHNkT090432
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,

Thank you for raising the issue.

I agree that the current text is too vague.

> Editors of 3280 and X.509:
> 
> There is a security hole in the X.509 and RFC 3280 certification path 
> validation for CRL, which can be exploited or result in undesirable 
> behavior when global name uniqueness among various PKI is not assured.
> 
> The problem manifests itself when a relying party can not verify 
> signature on a CRL using the certificate issuer public key and thus 
> needs to build a certification path for the CRL.  This could occur when 
> a CA has re-keyed after the certificate whose revocation status is being 
> checked, was issued.
> 
> Neither RFC 3280 nor X.509 require that the certification path for the 
> CRL have some semblance to the certification path for the certificate 
> whose status is being checked.  For example, Section 6.3.3 Step ?f? of 
> RFC 3280 states only the following for the certification path for the CRL:
> 
> ?Obtain and validate the certification path for the complete CRL 
> issuer.  If a key usage extension is present in the CRL issuer's 
> certificate, verify that the cRLSign bit is set.?

> A set of rules along the following lines should be added to RFC 3280 and 
> to X.509:
> 
>       1.      Certification path for the CRL shall begin with the same
>       trust anchor as the certification path for the certificate whose
>       status is being checked
> 
>       2.      The issuer names in the certification path for the CRL
>       shall match one for one with the issuer names in the certification
>       path for the certificate, starting with the trust anchor and
>       ending with the last certificate in the certification path for the
>       CRL.  During name matching, all self-issued certificates in both
>       paths shall be ignored.

This text is not sufficient.

The CA can nominate a CRL Issuer for the management of the revocation status 
of the certificates that it issues and thus the path is one leg longer, 
since the Issuing CA issues a certificate to nominate the CRL issuer. The 
text above does not capture this point.

Denis



>       3.      Certification path for the CRL shall be valid for at least
>       one of the certificate policies acceptable to the relying party.
> 
> Rule 3 above is less restrictive and more appropriate rule would be
> 
> Alternative rule 3: Certification path for the CRL shall be valid for at 
> least the same certificate policies that the certification path for the 
> certificate is valid for.  This comparison shall be performed by 
> converting the policies to the relying party domain.
> 
> An obvious question comes to mind:
> 
>       §       What about Indirect CRL?
> 
> Requiring that the Indirect CRL Issuer be from the trust domain as the 
> certificate is a good idea and not overly restrictive given that we can 
> not guarantee global name uniqueness among all the PKIs trusted by a 
> relying party.
> 
> Another alternative to all of the above pontification is to require the 
> relying parties to ensure that all trust anchors are constrained to 
> disjoint name spaces, i.e.,  intersection between the permitted name 
> spaces for any two trust anchors is null.
> 
> 
> Santosh Chokhani
> Orion Security Solutions, Inc.
> 1489 Chain Bridge Road, Suite 300
> McLean, Virginia 22101
> [phone]  Ext. 35(voice)
> [phone] (Fax)
> [e-mail]
> Visit our Web site
> http://www.orionsec.com
> 
> 





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA53elkT085445 for <[e-mail]>; Tue, 4 Nov 2003 19:40:47 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA53el1A085443 for ietf-pkix-bks; Tue, 4 Nov 2003 19:40:47 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA53ejkT085433 for <[e-mail]>; Tue, 4 Nov 2003 19:40:46 -0800 (PST) (envelope-from [e-mail])
Received: from calendar.nist.gov (calendar-ether.nist.gov [129.6.16.10]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id hA53eY0T020709; Tue, 4 Nov 2003 22:40:34 -0500 (EST)
Received: from calendar.nist.gov (localhost [127.0.0.1]) by calendar.nist.gov (8.12.9-20030924/8.12.9) with ESMTP id hA53eYSm025714; Tue, 4 Nov 2003 22:40:34 -0500 (EST)
Received: (from nobody@localhost) by calendar.nist.gov (8.12.9-20030924/8.12.9/Submit) id hA53eYKp025713; Tue, 4 Nov 2003 22:40:34 -0500 (EST)
Received: from 138.88.200.126 ( [138.88.200.126]) as user [e-mail] by imp.nist.gov with HTTP; Tue,  4 Nov 2003 22:40:34 -0500
Message-ID: <[e-mail]>
Date: Tue,  4 Nov 2003 22:40:34 -0500
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: PKIX WG Agenda for 58th IETF
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 8bit
User-Agent: Internet Messaging Program (IMP) 2.3.7-cvs
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>

PKIX WG (pkix-wg) 


MONDAY, November 10, 2003 1530-1730 

================================= 


CHAIR Stephen Kent <[e-mail]>, Tim Polk <[e-mail]> 


AGENDA 


1. WG Status and Direction 

1.1 Document Status Review [Tim Polk (NIST)] 

       The working group has a number of Internet-Drafts.  Many 
       documents are with the ADs or in various stages of WG Last Call. 
       Several others are ready for Last Call. (10 min.) 

1.2 Proposed WG Milestones [Tim Polk (NIST)] 

       The working group milestones are out of date.  New milestones are 
       needed; these milestones need to satisfy IESG direction for an orderly 
       closeout of WG activities. (10 min.) 

2. PKIX WG Specifications 

    2.1  Subject Identification Method  [TBD] 

       http://www.ietf.org/internet-drafts/draft-ietf-pkix-sim-01.txt 

       The current SIM draft introduces a number of new parameters. 
       While these parameters add additional complexity, they were 
       required to satisfy the draft's security requirements.  The
       presentation will focus on the security requirements and
       proposed solution. Open issues will also be identified.  (10 min.) 

    2.2 LDAP Schemas, String Values, and more 
                                - Peter Gietz 

       The WG has a suite of LDAP-PKIX drafts forming a comprehensive solution 
       for LDAP based PKI information distribution.  New drafts will be 
       published soon after this meeting; the presenter will discuss changes 
       that will appear in the new drafts.  (15 min.) 


    2.3 Qualified Certificates             Stefan Santesson 

       http://www.ietf.org/internet-drafts/draft-ietf-pkix-sonof3039-02.txt 

       Work on the QC document has continued in both PKIX and ETSI. 
       At least one more draft is envisioned; this presentation will describe 
       planned updates and propose a path for completion of the QC document. 
       (10 min.) 

    2.4 Certification Path Building        Peter Hesse (Gemini Security) 

       http://www.ietf.org/internet-drafts/draft-ietf-pkix-certpathbuild-
01.txt 

       This document was written to provide guidance and 
       recommendations to developers building X.509 public-key certification 
       paths within their applications.  The next draft is aimed for WG Last 
       Call; the presenter will discuss changes since -00 and additional 
       changes projected for the forthcoming -02 draft. (10 min.) 

    2.5  OCSP                               Mike Myers (TraceRoute) 

       http://www.ietf.org/rfc/rfc2560.txt


       A number of issues regarding OCSP have resurfaced on the mailing 
       list.  The presenter will summarize the issues from the mailing 
       list and present a way forward.  (5 min.) 

3. Liaison/Related Projects 

    The following specifications will update the WG on related activities. 


    3.1 OASIS PKI survey                        Steve Hanna (Sun) 

       The OASIS Public Key Infrastructure Technical Committee 
       conducted a web-based survey to identify the key barriers to PKI
       deployment and usage.  The TC is currently developing an Action Plan
       to address these barriers.  The presentation will address the survey 
       results and preview the action plan. (15 min.) 

    3.2 Path Validation Protection Profiles     Tim Polk (NIST) 

       NIST is currently performing the interoperability testing for RFC 3280. 
       One aspect of that effort is the RFC 3280 path validation test suite 
       developed jointly by NIST, DigitalNet, and NSA.  To promote independnet 
       testing based on the test suite, NIST has submitted protection profiles 
       for path validation modules for NIAP validation. (10 min.) 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA4MuTkT076093 for <[e-mail]>; Tue, 4 Nov 2003 14:56:29 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA4MuSe4076092 for ietf-pkix-bks; Tue, 4 Nov 2003 14:56:28 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA4MuRkT076087 for <[e-mail]>; Tue, 4 Nov 2003 14:56:27 -0800 (PST) (envelope-from [e-mail])
Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e3.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id hA4MuNYJ270264; Tue, 4 Nov 2003 17:56:23 -0500
Received: from d01ml062.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hA4MuLkb067468; Tue, 4 Nov 2003 17:56:22 -0500
To: "David P. Kemp" <[e-mail]>
Cc: [e-mail]
MIME-Version: 1.0
Subject: Re: AKI and SKI problem with RFC 3280?
X-Mailer: Lotus Notes Release 5.0.11   July 24, 2002
From: Tom Gindin <[e-mail]>
Message-ID: <[e-mail]>
Date: Tue, 4 Nov 2003 17:56:20 -0500
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 6.0.2CF2 IGS_HF9|October 28, 2003) at 11/04/2003 17:56:22, Serialize complete at 11/04/2003 17:56:22
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>

        David:

        Banning sequential ID's and having the issuer calculate the key ID 
doesn't seem to help much.  If the subject CA uses method 1 (in section 
4.2.1.2 of RFC 3280) and the issuer uses method 2, the key ID's won't 
match.  Short of requiring a SINGLE calculation method for CA key ID's, 
there seems to be no substitute for communication - having the subject CA 
include the key ID in the request.
        If we agree that in the general case the subject CA should assign 
its own key ID, how does the issuing CA find out which value that is?  The 
two most usual methods for the subject CA to tell the issuing CA anything 
are probably CRMF and PKCS#10.  In CRMF you can just put the SubjectKeyID 
extension into CertTemplate's Extensions field.    In PKCS#10 the same 
extension goes into the PKCS#9 ExtensionRequest attribute.

                Tom Gindin





"David P. Kemp" <[e-mail]>
Sent by: [e-mail]
10/26/2003 11:36 AM

 
        To:     [e-mail]
        cc: 
        Subject:        Re: AKI and SKI problem with RFC 3280?




Oops, now I understand the scenario Steve Hanna was referring to:
   1. Subject CA picks it's own AKI using a computation
      technique, assuming issing CAs will use the same value
      for SKI (as they should).
   2. Issuing CA issues a cross-cert with an SKI using a different
      computation technique, blindly assuming that subject CA will
      take what he has been given to use as AKI as if subject were
      a child in issuer's hierarchy.

Sorry, Steve for my rant.  A working system has to have a common
set of assumptions, such as SKIs flow from the top down (works only
for hierarchies), or SKIs flow from the subject CAs to the issuers
(works in any topology), or every CA uses the same SKI computation
technique (works in any topology).  I didn't consider the situation
where the issuing CA and subject CA operate using different concepts
of who does what to whom.  Thanks, Stefan, for pointing out that
some CAs that were designed for use only in hierarchies are being
misused to issue cross certificates.

Dave



Stefan Santesson wrote:

> The problem is that RFC 3280 in practice require a CA, issuing a CA
> certs, to ask the subordinate CA for its preferred SKI rather than
> generating it.
> 
> To my knowledge there is no CA software that has implemented that
> behavior. If I'm not wrong they are all counting on that subordinate CAs
> will adopt the SKI generated by the parent CA, as the AKI placed in
> issued certs.
> 
> This works for strict hierarchical structures but not for generic cross
> certification (such as Bridge CA) unless CAs use the same SKI generation
> algorithm.
> 
> /Stefan
> 
> 
> 
>>-----Original Message-----
>>From: [e-mail]
> 
> [mailto:[e-mail]]
> 
>>On Behalf Of David P. Kemp
>>Sent: den 25 oktober 2003 00:54
>>To: [e-mail]
>>Subject: Re: AKI and SKI problem with RFC 3280?
>>
>>
>>Santosh,
>>
>>I agree that Section 4.2.1.2 of 3280 unambiguously states
>>that an "issuing CA" that does not populate SKI with the value
>>of AKI used by the "subject CA" is not compliant.
>>
>>It appeared that Steve Hanna was referring to non-3280-compliant
>>CAs, where
>>   "the CA certificate may have been issued by a CA that uses
>>    a different AKI/SKI computation technique than the CA
>>    who's the subject of the CA certificate."
>>
>>A compliant "subject CA" may have an AKI computation technique,
>>but a compliant "issuing CA" must not have an SKI computation
>>technique for CA certs - it must import the subject CA's AKI.
>>
>>Outside the realm of 3280 compliance, where the situation
>>of N different SKIs might occur and AKI/SKI don't necessarily
>>chain, the chaining problem occurs when two issuing CAs use
>>two different computation techniques to assign SKIs to the
>>subject, *not* when the issuing CA uses a different technique
>>than the subject CA.  The subject CA's techniques for choosing
>>an AKI for itself and SKIs to go in its issued certs is
>>completely irrelevant.
>>
>>Dave
>>
>>
>>Santosh Chokhani wrote:
>>
>>>David:
>>>
>>>Some of us are interpreting 3280 (specifically Section
> 
> 4.2.1.2,Subject
> 
>>Key
>>
>>>Identifier) to state that all N SKI should be the same and match the
> 
> AKI
> 
>>>used by the subject CA in the certificates it issues.  If not, the
> 
> CAs
> 
>>that
>>
>>>do not populate the
>>>SKI, may not be RFC 3280 compliant.
>>>
>>>Thus, your suggestion of the subject CA using one of the SKI is a
> 
> more
> 
>>>liberal interpretation of 3280 and is covered by our interpretation
> 
> of
> 
>>3280.
>>
>>>At the risk of being redundant, if all CAs are 3280 compliant all N
> 
> SKI
> 
>>in N
>>
>>>certificates issued to a CA for the same SPKI X == AKI in all
>>
>>certificates
>>
>>>signed by the CA, where the signature can be verified using X
>>>
>>>-----Original Message-----
>>>From: [e-mail]
> 
> [mailto:[e-mail]]
> 
>>On
>>
>>>Behalf Of David P. Kemp
>>>Sent: Friday, October 24, 2003 12:19 PM
>>>To: [e-mail]
>>>Subject: Re: AKI and SKI problem with RFC 3280?
>>>
>>>
>>>
>>>Isn't the raison d'etre of AKI/SKI to allow a verifier
>>>to select the correct CA cert when multiple certs of the
>>>same issuer with different public keys are available
>>>(i.e. during rollover)?
>>>
>>>A CA may use any computation technique to populate the
>>>SKI of certs that it issues, but it MUST chain its own
>>>SKI into the AKI of certs that it issues.  Otherwise
>>>what's the point of populating AKI at all?
>>>
>>>The reason AKI/SKI chaining MUST NOT be enforced during
>>>path validation is because one CA could have one
>>>signing public key identified by N different SKIs
>>>in N different certs. (That's a bad thang, and cross-certificates
> 
> should
> 
>>>follow precedent rather than using a different SKI for the same
> 
> public
> 
>>key.)
>>
>>>But the CA MUST choose one of it's N SKIs to use as AKI, not make up
>>
>>some
>>
>>>different N+1th value. If it picks one of the N, then AKI is helpful
>>
>>1/Nth
>>
>>>of the time.  If it picks something else, then AKI can never be
> 
> helpful.
> 
>>>Dave
>>>
>>>
>>>Steve Hanna wrote:
>>>
>>>
>>>
>>>>Note also that AKI/SKI chaining SHOULD NOT be checked
>>>>during path validation. To be more explicit, it's
>>>>NOT true that the SKI of a CA certificate must match
>>>>the AKI of a certificate signed by that CA. Why?
>>>>Because the CA certificate may have been issued by
>>>>a CA that uses a different AKI/SKI computation technique
>>>>than the CA who's the subject of the CA certificate.
>>>
>>>
>>>
>>>
> 
> 






Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA4FVgkT059615 for <[e-mail]>; Tue, 4 Nov 2003 07:31:42 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA4FVgun059614 for ietf-pkix-bks; Tue, 4 Nov 2003 07:31:42 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA4FVfkT059609 for <[e-mail]>; Tue, 4 Nov 2003 07:31:41 -0800 (PST) (envelope-from [e-mail])
Received: from wchokhani (dpvc-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id hA4FRnFb003948; Tue, 4 Nov 2003 10:27:49 -0500
From: "Santosh Chokhani" <[e-mail]>
To: "Tim Polk" <[e-mail]>, "Russell Housley" <[e-mail]>, "Laura Boyer" <[e-mail]>
Cc: "Steve Kent" <[e-mail]>, <[e-mail]>, "'OSI Directory List'" <[e-mail]>
Subject: CRL Certification Path
Date: Tue, 4 Nov 2003 10:27:43 -0500
Message-ID: <006601c3a2e8$340856e0$[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0067_01C3A2BE.4B324EE0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
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_000_0067_01C3A2BE.4B324EE0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Editors of 3280 and X.509:

There is a security hole in the X.509 and RFC 3280 certification path
validation for CRL, which can be exploited or result in undesirable =
behavior
when global name uniqueness among various PKI is not assured.

The problem manifests itself when a relying party can not verify =
signature
on a CRL using the certificate issuer public key and thus needs to build =
a
certification path for the CRL.  This could occur when a CA has re-keyed
after the certificate whose revocation status is being checked, was =
issued.

Neither RFC 3280 nor X.509 require that the certification path for the =
CRL
have some semblance to the certification path for the certificate whose
status is being checked.  For example, Section 6.3.3 Step =93f=94 of RFC =
3280
states only the following for the certification path for the CRL:

=93Obtain and validate the certification path for the complete CRL =
issuer.  If
a key usage extension is present in the CRL issuer's certificate, verify
that the cRLSign bit is set.=94

A set of rules along the following lines should be added to RFC 3280 and =
to
X.509:

	1.	Certification path for the CRL shall begin with the same
trust anchor as the certification path for the certificate whose status =
is
being checked

	2.	The issuer names in the certification path for the CRL shall
match one for one with the issuer names in the certification path for =
the
certificate, starting with the trust anchor and ending with the last
certificate in the certification path for the CRL.  During name =
matching,
all self-issued certificates in both paths shall be ignored.

	3.	Certification path for the CRL shall be valid for at least
one of the certificate policies acceptable to the relying party.

Rule 3 above is less restrictive and more appropriate rule would be

Alternative rule 3: Certification path for the CRL shall be valid for at
least the same certificate policies that the certification path for the
certificate is valid for.  This comparison shall be performed by =
converting
the policies to the relying party domain.

An obvious question comes to mind:

	=A7	What about Indirect CRL?

Requiring that the Indirect CRL Issuer be from the trust domain as the
certificate is a good idea and not overly restrictive given that we can =
not
guarantee global name uniqueness among all the PKIs trusted by a relying
party.

Another alternative to all of the above pontification is to require the
relying parties to ensure that all trust anchors are constrained to =
disjoint
name spaces, i.e.,  intersection between the permitted name spaces for =
any
two trust anchors is null.


Santosh Chokhani
Orion Security Solutions, Inc.
1489 Chain Bridge Road, Suite 300
McLean, Virginia 22101
[phone]  Ext. 35(voice)
[phone] (Fax)
[e-mail]
Visit our Web site
http://www.orionsec.com



------=_NextPart_000_0067_01C3A2BE.4B324EE0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.0.4630.0">
<TITLE>CRL Certification Path</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P><FONT SIZE=3D2 FACE=3D"Arial">Editors of 3280 and X.509:</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">There is a security hole in the X.509 =
and RFC 3280 certification path validation for CRL, which can be =
exploited or result in undesirable behavior when global name uniqueness =
among various PKI is not assured.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The problem manifests itself when a =
relying party can not verify signature on a CRL using the certificate =
issuer public key and thus needs to build a certification path for the =
CRL.&nbsp; This could occur when a CA has re-keyed after the certificate =
whose revocation status is being checked, was issued.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Neither RFC 3280 nor X.509 require that =
the certification path for the CRL have some semblance to the =
certification path for the certificate whose status is being =
checked.&nbsp; For example, Section 6.3.3 Step &#8220;f&#8221; of RFC =
3280 states only the following for the certification path for the =
CRL:</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&#8220;Obtain and validate the =
certification path for the complete CRL issuer.&nbsp; If a key usage =
extension is present in the CRL issuer's certificate, verify that the =
cRLSign bit is set.&#8221;</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">A set of rules along the following =
lines should be added to RFC 3280 and to X.509:</FONT>
</P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">1.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Certification path for the CRL shall begin with the same trust anchor as =
the certification path for the certificate whose status is being =
checked</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">2.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The =
issuer names in the certification path for the CRL shall match one for =
one with the issuer names in the certification path for the certificate, =
starting with the trust anchor and ending with the last certificate in =
the certification path for the CRL.&nbsp; During name matching, all =
self-issued certificates in both paths shall be ignored.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">3.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Certification path for the CRL shall be valid for at least one of the =
certificate policies acceptable to the relying party.</FONT></P>
</UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">Rule 3 above is less restrictive and =
more appropriate rule would be</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Alternative rule 3: Certification path =
for the CRL shall be valid for at least the same certificate policies =
that the certification path for the certificate is valid for.&nbsp; This =
comparison shall be performed by converting the policies to the relying =
party domain.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">An obvious question comes to =
mind:</FONT>
</P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">=A7&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
What about Indirect CRL?</FONT>
</P>
</UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">Requiring that the Indirect CRL Issuer =
be from the trust domain as the certificate is a good idea and not =
overly restrictive given that we can not guarantee global name =
uniqueness among all the PKIs trusted by a relying party.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Another alternative to all of the above =
pontification is to require the relying parties to ensure that all trust =
anchors are constrained to disjoint name spaces, i.e.,&nbsp; =
intersection between the permitted name spaces for any two trust anchors =
is null.</FONT></P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">Santosh Chokhani</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Orion Security Solutions, Inc.</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">1489 Chain Bridge Road, Suite =
300</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">McLean, Virginia 22101</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">(703)</FONT> <FONT SIZE=3D2 =
FACE=3D"Arial">917</FONT><FONT SIZE=3D2 FACE=3D"Arial">-</FONT><FONT =
SIZE=3D2 FACE=3D"Arial">0060</FONT><FONT SIZE=3D2 =
FACE=3D"Arial"></FONT>&nbsp;<FONT SIZE=3D2 FACE=3D"Arial"> </FONT><FONT =
COLOR=3D"#FF0000" SIZE=3D2 FACE=3D"Arial">Ext. 35</FONT><FONT SIZE=3D2 =
FACE=3D"Arial">(</FONT><FONT SIZE=3D2 FACE=3D"Arial">voice</FONT><FONT =
SIZE=3D2 FACE=3D"Arial">)</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">(703)</FONT> <FONT SIZE=3D2 =
FACE=3D"Arial">917</FONT><FONT SIZE=3D2 FACE=3D"Arial">-</FONT><FONT =
SIZE=3D2 FACE=3D"Arial">0260</FONT><FONT SIZE=3D2 FACE=3D"Arial"> =
(Fax)</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">[e-mail]</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Visit our Web site</FONT>

<BR><A HREF=3D"http://www.orionsec.com"><U><FONT COLOR=3D"#0000FF" =
SIZE=3D2 FACE=3D"Arial">http://www.orionsec.com</FONT></U></A>
</P>
<BR>

</BODY>
</HTML>
------=_NextPart_000_0067_01C3A2BE.4B324EE0--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA4FVVkT059604 for <[e-mail]>; Tue, 4 Nov 2003 07:31:31 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA4FVVDk059603 for ietf-pkix-bks; Tue, 4 Nov 2003 07:31:31 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA4FVUkT059598 for <[e-mail]>; Tue, 4 Nov 2003 07:31:30 -0800 (PST) (envelope-from [e-mail])
Received: from wchokhani (dpvc-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id hA4FQxFb003769; Tue, 4 Nov 2003 10:27:10 -0500
From: "Santosh Chokhani" <[e-mail]>
To: "Tim Polk" <[e-mail]>, "Russell Housley" <[e-mail]>, "Laura Boyer" <[e-mail]>
Cc: "Steve Kent" <[e-mail]>, <[e-mail]>, "'OSI Directory List'" <[e-mail]>
Subject: CRL Certification Path
Date: Tue, 4 Nov 2003 10:26:44 -0500
Message-ID: <006101c3a2e8$254d2130$[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0062_01C3A2BE.3C771930"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
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_000_0062_01C3A2BE.3C771930
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Editors of 3280 and X.509:

There is a security hole in the X.509 and RFC 3280 certification path
validation for CRL, which can be exploited or result in undesirable =
behavior
when global name uniqueness among various PKI is not assured.

The problem manifests itself when a relying party can not verify =
signature
on a CRL using the certificate issuer public key and thus needs to build =
a
certification path for the CRL.  This could occur when a CA has re-keyed
after the certificate whose revocation status is being checked, was =
issued.

Neither RFC 3280 nor X.509 require that the certification path for the =
CRL
have some semblance to the certification path for the certificate whose
status is being checked.  For example, Section 6.3.3 Step =93f=94 of RFC =
3280
states only the following for the certification path for the CRL:

=93Obtain and validate the certification path for the complete CRL =
issuer.  If
a key usage extension is present in the CRL issuer's certificate, verify
that the cRLSign bit is set.=94

A set of rules along the following lines should be added to RFC 3280 and =
to
X.509:

	1.	Certification path for the CRL shall begin with the same
trust anchor as the certification path for the certificate whose status =
is
being checked

	2.	The issuer names in the certification path for the CRL shall
match one for one with the issuer names in the certification path for =
the
certificate, starting with the trust anchor and ending with the last
certificate in the certification path for the CRL.  During name =
matching,
all self-issued certificates in both paths shall be ignored.

	3.	Certification path for the CRL shall be valid for at least
one of the certificate policies acceptable to the relying party.

Rule 3 above is less restrictive and more appropriate rule would be

Alternative rule 3: Certification path for the CRL shall be valid for at
least the same certificate policies that the certification path for the
certificate is valid for.  This comparison shall be performed by =
converting
the policies to the relying party domain.

An obvious question comes to mind:

	=A7	What about Indirect CRL?

Requiring that the Indirect CRL Issuer be from the trust domain as the
certificate is a good idea and not overly restrictive given that we can =
not
guarantee global name uniqueness among all the PKIs trusted by a relying
party.

Another alternative to all of the above pontification is to require the
relying parties to ensure that all trust anchors are constrained to =
disjoint
name spaces, i.e.,  intersection between the permitted name spaces for =
any
two trust anchors is null.


Santosh Chokhani
Orion Security Solutions, Inc.
1489 Chain Bridge Road, Suite 300
McLean, Virginia 22101
[phone]  Ext. 35(voice)
[phone] (Fax)
[e-mail]
Visit our Web site
http://www.orionsec.com



------=_NextPart_000_0062_01C3A2BE.3C771930
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.0.4630.0">
<TITLE>CRL Certification Path</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P><FONT SIZE=3D2 FACE=3D"Arial">Editors of 3280 and X.509:</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">There is a security hole in the X.509 =
and RFC 3280 certification path validation for CRL, which can be =
exploited or result in undesirable behavior when global name uniqueness =
among various PKI is not assured.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The problem manifests itself when a =
relying party can not verify signature on a CRL using the certificate =
issuer public key and thus needs to build a certification path for the =
CRL.&nbsp; This could occur when a CA has re-keyed after the certificate =
whose revocation status is being checked, was issued.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Neither RFC 3280 nor X.509 require that =
the certification path for the CRL have some semblance to the =
certification path for the certificate whose status is being =
checked.&nbsp; For example, Section 6.3.3 Step &#8220;f&#8221; of RFC =
3280 states only the following for the certification path for the =
CRL:</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&#8220;Obtain and validate the =
certification path for the complete CRL issuer.&nbsp; If a key usage =
extension is present in the CRL issuer's certificate, verify that the =
cRLSign bit is set.&#8221;</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">A set of rules along the following =
lines should be added to RFC 3280 and to X.509:</FONT>
</P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">1.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Certification path for the CRL shall begin with the same trust anchor as =
the certification path for the certificate whose status is being =
checked</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">2.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The =
issuer names in the certification path for the CRL shall match one for =
one with the issuer names in the certification path for the certificate, =
starting with the trust anchor and ending with the last certificate in =
the certification path for the CRL.&nbsp; During name matching, all =
self-issued certificates in both paths shall be ignored.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">3.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Certification path for the CRL shall be valid for at least one of the =
certificate policies acceptable to the relying party.</FONT></P>
</UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">Rule 3 above is less restrictive and =
more appropriate rule would be</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Alternative rule 3: Certification path =
for the CRL shall be valid for at least the same certificate policies =
that the certification path for the certificate is valid for.&nbsp; This =
comparison shall be performed by converting the policies to the relying =
party domain.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">An obvious question comes to =
mind:</FONT>
</P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">=A7&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
What about Indirect CRL?</FONT>
</P>
</UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">Requiring that the Indirect CRL Issuer =
be from the trust domain as the certificate is a good idea and not =
overly restrictive given that we can not guarantee global name =
uniqueness among all the PKIs trusted by a relying party.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Another alternative to all of the above =
pontification is to require the relying parties to ensure that all trust =
anchors are constrained to disjoint name spaces, i.e.,&nbsp; =
intersection between the permitted name spaces for any two trust anchors =
is null.</FONT></P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">Santosh Chokhani</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Orion Security Solutions, Inc.</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">1489 Chain Bridge Road, Suite =
300</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">McLean, Virginia 22101</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">(703)</FONT> <FONT SIZE=3D2 =
FACE=3D"Arial">917</FONT><FONT SIZE=3D2 FACE=3D"Arial">-</FONT><FONT =
SIZE=3D2 FACE=3D"Arial">0060</FONT><FONT SIZE=3D2 =
FACE=3D"Arial"></FONT>&nbsp;<FONT SIZE=3D2 FACE=3D"Arial"> </FONT><FONT =
COLOR=3D"#FF0000" SIZE=3D2 FACE=3D"Arial">Ext. 35</FONT><FONT SIZE=3D2 =
FACE=3D"Arial">(</FONT><FONT SIZE=3D2 FACE=3D"Arial">voice</FONT><FONT =
SIZE=3D2 FACE=3D"Arial">)</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">(703)</FONT> <FONT SIZE=3D2 =
FACE=3D"Arial">917</FONT><FONT SIZE=3D2 FACE=3D"Arial">-</FONT><FONT =
SIZE=3D2 FACE=3D"Arial">0260</FONT><FONT SIZE=3D2 FACE=3D"Arial"> =
(Fax)</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">[e-mail]</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Visit our Web site</FONT>

<BR><A HREF=3D"http://www.orionsec.com"><U><FONT COLOR=3D"#0000FF" =
SIZE=3D2 FACE=3D"Arial">http://www.orionsec.com</FONT></U></A>
</P>
<BR>

</BODY>
</HTML>
------=_NextPart_000_0062_01C3A2BE.3C771930--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA4EOFkT056725 for <[e-mail]>; Tue, 4 Nov 2003 06:24:15 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA4EOFk5056724 for ietf-pkix-bks; Tue, 4 Nov 2003 06:24:15 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.33.151]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA4EOCkT056719 for <[e-mail]>; Tue, 4 Nov 2003 06:24:13 -0800 (PST) (envelope-from [e-mail])
Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9-20030924/8.12.9) with ESMTP id hA4EOBo9032427; Wed, 5 Nov 2003 03:24:11 +1300
Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id hA4ERcj06550; Wed, 5 Nov 2003 03:27:38 +1300
Date: Wed, 5 Nov 2003 03:27:38 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail]
Subject: Re: Good certificate renewal practice
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>

=?iso-8859-1?Q?Fr=E9d=E9ric_Giudicelli?= <[e-mail]> writes:

>So I guess that all the earlier-suggested renewal methods are okay.

Yup, if your policy allows it.  For example the answer to the question:

  should we revoke the previous certificate and after which delay?

in my code would be that the cert will get revoked once its replacement is
created since to have two otherwise identical certs existing at the same time
will violate the CA database integrity constraints (the CA transaction
engine's ACID properties won't allow this to happen).  Note that the private
key isn't affected (you can still use it, for example, to decrypt data long
after the cert has expired), only the publicly visible CA statement about the
public portion of the key.

However, that's just one particular interpretation.  Everyone else is free to
apply whatever interpretation they choose.

>In any event is there any PKIX draft, that explicit those renewal policies?
>I'm having a hard time believing that the WG let some much room for personal
>appreciation :)

It was a in-joke, a reference to the fact that anything that no-one can really
agree on is made a policy matter, which means that someone else has to take
care of it.

Peter.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA4A8JkT045895 for <[e-mail]>; Tue, 4 Nov 2003 02:08:19 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA4A8ITw045894 for ietf-pkix-bks; Tue, 4 Nov 2003 02:08:18 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.33.151]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA4A8GkT045889; Tue, 4 Nov 2003 02:08:17 -0800 (PST) (envelope-from [e-mail])
Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9-20030924/8.12.9) with ESMTP id hA4A8Go9028250; Tue, 4 Nov 2003 23:08:16 +1300
Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id hA4ABfi05617; Tue, 4 Nov 2003 23:11:41 +1300
Date: Tue, 4 Nov 2003 23:11:41 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Request change in son-of-rfc2633
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 wrote:

>Mozilla (and no doubt some others that didn't get any publicity) did the same
>thing, and I'm sure they didn't get asked to do that by customers.

Actually that's not right, I thought Mozilla (or at least some apps that used
the Mozilla/Gecko/NSS/whatever code base) were vulnerable because Konqueror
was vulnerable, but it turns out that this was Konqueror with khtml rather
than with kmozilla, with OpenSSL supplying the crypto.  Apologies for the
mixup.

Before this gets read as "OpenSSL is vulnerable", that isn't the case either.
OpenSSL provides application-defined callbacks that can be used to override
some checks (used to handle, as one source aptly described it, "the mass of
broken certs out there").  Some apps provide callbacks that ignore all errors,
which apparently is what happened here.  Standard OpenSSL doesn't have this
problem.

Peter.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA3JwdkT048771 for <[e-mail]>; Mon, 3 Nov 2003 11:58:39 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA3JwdBo048770 for ietf-pkix-bks; Mon, 3 Nov 2003 11:58:39 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA3JwckT048763 for <[e-mail]>; Mon, 3 Nov 2003 11:58:38 -0800 (PST) (envelope-from [e-mail])
Received: from sydney.East.Sun.COM ([129.148.9.16]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id hA3JwYxA026663 for <[e-mail]>; Mon, 3 Nov 2003 11:58:34 -0800 (PST)
Received: from sun.com (dhcp-ubur02-75-161 [129.148.75.161]) by sydney.East.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id hA3JwXB16674; Mon, 3 Nov 2003 14:58:33 -0500 (EST)
Message-ID: <[e-mail]>
Date: Mon, 03 Nov 2003 14:57:53 -0500
From: Steve Hanna <[e-mail]>
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: PKIX List <[e-mail]>
Subject: Draft PKI Action Plan Posted for Review and Comment
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msF72986030010465915965733"
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.

--------------msF72986030010465915965733
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

The OASIS Public Key Infrastructure Technical Committee
(the OASIS PKI TC) has posted a draft PKI Action Plan for
public review, inviting comments and support from PKI
customers, vendors, experts, and others. This plan is
designed to address obstacles to PKI deployment and usage
identified through surveys conducted earlier this year.

The draft PKI Action Plan is available for review at
http://www.oasis-open.org/committees/pki/pkiactionplan.pdf
The survey results are available at these locations
http://www.oasis-open.org/committees/pki/pkiobstaclesjune2003surveyreport.pdf
http://www.oasis-open.org/committees/pki/pkiobstaclesaugust2003surveyreport.pdf

Comments on the plan should be submitted by clicking the
"Send a Comment" button on the PKI TC's web page at
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=pki

At the PKIX meeting next week, I will briefly summarize
the survey results and the draft PKI Action Plan.
However, I encourage you to review these documents in
detail and submit your comments to the PKI TC.

Note that the PKI TC recognizes that most of the actions
described in the draft PKI Action Plan must be undertaken
not by the PKI TC, but by others (vendors, standards groups,
users, etc.) and that some of these efforts are already
under way. The PKI TC does not intend to usurp these efforts,
but to serve as a catalyst encouraging and accelerating efforts.

Thanks,

Steve Hanna
OASIS PKI TC Co-chair
--------------msF72986030010465915965733
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

MIIIEAYJKoZIhvcNAQcCoIIIATCCB/0CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
BeMwggKjMIICDKADAgECAgMKVAgwDQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlpBMRUw
EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhh
d3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwg
RnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA3MTExMTAxNTFaFw0wNDA3MTAxMTAxNTFa
MGgxDjAMBgNVBAQTBUhhbm5hMRUwEwYDVQQqEwxTdGVwaGVuIFJvc3MxGzAZBgNVBAMTElN0
ZXBoZW4gUm9zcyBIYW5uYTEiMCAGCSqGSIb3DQEJARYTc3RldmUuaGFubmFAc3VuLmNvbTCB
nzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAoxRk/abMPe7Km2EqpD2FZXzjiBGUHhIdNlIO
9W6mdCQro1xMc+sv+93UuVnIzse+XA67Tqx4g5FdoQ+PI8TQYemYSkTD9GitgU563ypu03UV
86zTJA7u9zVkNv/qL2LRKZ9BXy2Smtet+PUh3nYjMh/ZY7LQxQzmdu1Zunue+yECAwEAAaMw
MC4wHgYDVR0RBBcwFYETc3RldmUuaGFubmFAc3VuLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqG
SIb3DQEBBAUAA4GBAHbpX0TKiOFu1vxKc3nAOcUHwoci5kinboYrnjWcl37mMXXbBFntaYRM
9LxpGtHdPm7F4pAviKp8bnFzTU46OyUw3kNUAVGDeWYVQC76f0dDZdA313Tn88UZYa+N6O8W
bO8wjKA2vg+yx79WXJCFDu+TpsG/28NKPdH42w8LEOVHMIIDODCCAqGgAwIBAgIQZkVyt8x0
9c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl
c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3Vs
dGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UE
AxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h
bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgyNzIzNTk1OVow
gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg
VG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEo
MCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzANBgkqhkiG9w0B
AQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUqbXA8+tyu9+50
bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC9tewkd4c6avg
GAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEwwKQYDVR0RBCIw
IKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQIMAYBAf8CAQAw
CwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF151j2YwCYTYoEi
pxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59sogxYjTFCCRFs
sBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TYyWJirQXGMYIB
9TCCAfECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQ
BgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0
ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAID
ClQIMAkGBSsOAwIaBQCggbEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B
CQUxDxcNMDMxMTAzMTk1NzUzWjAjBgkqhkiG9w0BCQQxFgQUj+NJZZO2XGwRExfcmgBhhBRo
YfkwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4D
AgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYA2MKYN
b+jOgT59QtLSyfNSmDWD05NejGlbplN75rifDjuSUox6XylWC/pSur9gl5d9hNV1h1m2lQaL
vxtEof8valUbnQFJgkRQDVaZR4y0DIsXG1/7MMe+Ju4ZJVs8Nc+neCIVEg5fQ2essJB8rrk2
L2g9wrXfY9Q/3DVDZ/H8eA==
--------------msF72986030010465915965733--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA37lukT091988 for <[e-mail]>; Sun, 2 Nov 2003 23:47:56 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA37luVu091986 for ietf-pkix-bks; Sun, 2 Nov 2003 23:47:56 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp1.fre.skanova.net (smtp1.fre.skanova.net [195.67.227.94]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA37lskT091961 for <[e-mail]>; Sun, 2 Nov 2003 23:47:55 -0800 (PST) (envelope-from [e-mail])
Received: from arport (t9o913p1.telia.com [213.64.27.1]) by smtp1.fre.skanova.net (8.12.10/8.12.10) with SMTP id hA37lk7U006282; Mon, 3 Nov 2003 08:47:47 +0100 (CET)
Message-ID: <008101c3a1de$57442040$011b40d5@arport>
From: "Anders Rundgren" <[e-mail]>
To: =?iso-8859-1?Q?Fr=E9d=E9ric_Giudicelli?= <[e-mail]>, <[e-mail]>
References: <006f01c3a1c6$3db89790$0200000a@station1>
Subject: Re: Good certificate renewal practice
Date: Mon, 3 Nov 2003 08:44:35 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
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>

I believe this is outside of standards.
But I am sure it should conceptually work as it does for credit-cards,
passports etc.   I.e. you receive (automatically or on your own
responsibility) a new card etc. before the existing has expired.
There are no technical needs for revoking as far as I can see.
In an on-line PKI I would assume that the old certificate would
be replaced by the new one automatically.  But on-line certification
is not standardized, and everyone makes their own "pudding"
and assign their own policy.

>From a recent message of mine:

=============================================
   Practically every piece of client-side Web-PKI, ranging
   from on-line certification support to on-line (web-form)
   signing, is currently entirely vendor-dependent
=============================================

I will check out newpki.org!

Anders

----- Original Message -----
From: "Frédéric Giudicelli" <[e-mail]>
To: <[e-mail]>
Sent: Monday, November 03, 2003 05:51
Subject: Good certificate renewal practice



Hello,
After reviewing "pkix-roadmap" and "rfc2510bis" I found no details on how
PKIs should handle certificates renewal.
Can a user request a renewal even if his/her certificate is not about to
expiry? If yes, should we revoke the previous certificate and after which
delay?
Can a user request a renewal even if his/her certificate has expired?
I'm just lost on how implementing certificate renewal in my PKI.

Thanks,
Frédéric Giudicelli
http://www.newpki.org



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA36WTkT062437 for <[e-mail]>; Sun, 2 Nov 2003 22:32:29 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA36WTrK062436 for ietf-pkix-bks; Sun, 2 Nov 2003 22:32:29 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.newpki.org (ATuileries-102-1-3-88.w217-128.abo.wanadoo.fr [217.128.76.88]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA36WRkT062395 for <[e-mail]>; Sun, 2 Nov 2003 22:32:28 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (localhost [127.0.0.1]) by smtp.newpki.org (Postfix) with ESMTP id 0DB93B817; Mon,  3 Nov 2003 07:33:09 +0100 (CET)
Received: from smtp.newpki.org (localhost [127.0.0.1]) by localhost (AvMailGate-2.0.1.16) id 32216-4C6A6409; Mon, 03 Nov 2003 07:32:09 +0100
Received: from station1 (unknown [10.0.0.2]) by smtp.newpki.org (Postfix) with SMTP id 35C6FB816; Mon,  3 Nov 2003 07:32:09 +0100 (CET)
Message-ID: <00be01c3a1d3$df98a480$0200000a@station1>
From: =?iso-8859-1?Q?Fr=E9d=E9ric_Giudicelli?= <[e-mail]>
To: "Peter Gutmann" <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: Good certificate renewal practice
Date: Mon, 3 Nov 2003 07:29:45 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-AntiVirus: checked by AntiVir MailGate (version: 2.0.1.16; AVE: 6.22.0.1; VDF: 6.22.0.24; host: server-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>

So I guess that all the earlier-suggested renewal methods are okay.
In any event is there any PKIX draft, that explicit those renewal policies?
I'm having a hard time believing that the WG let some much room for personal
appreciation :)

Frédéric Giudicelli
http://www.newpki.org

(Are you trying to say that you would be rich by now?)


----- Original Message ----- 
From: "Peter Gutmann" <[e-mail]>
To: <[e-mail]>; <[e-mail]>
Sent: Monday, November 03, 2003 7:14 AM
Subject: Re: Good certificate renewal practice


> =?iso-8859-1?Q?Fr=E9d=E9ric_Giudicelli?= <[e-mail]> writes:
>
> >After reviewing "pkix-roadmap" and "rfc2510bis" I found no details on how
> >PKIs should handle certificates renewal.
>
> That's a policy matter.
>
> >Can a user request a renewal even if his/her certificate is not about to
> >expiry?
>
> That's a policy matter.
>
> >If yes, should we revoke the previous certificate and after which delay?
>
> That's a policy matter.
>
> >Can a user request a renewal even if his/her certificate has expired?
>
> Th.... well, you get the idea.
>
> Peter.
>
> (Incidentally, the person who originally suggested the ecumenical/policy
>  comment has since expressed regret that he didn't trademark it or
something
>  :-).
>



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA36BXkT055651 for <[e-mail]>; Sun, 2 Nov 2003 22:11:33 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA36BXeG055650 for ietf-pkix-bks; Sun, 2 Nov 2003 22:11:33 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.33.151]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA36BSkT055620 for <[e-mail]>; Sun, 2 Nov 2003 22:11:31 -0800 (PST) (envelope-from [e-mail])
Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9-20030924/8.12.9) with ESMTP id hA36BVo9023528; Mon, 3 Nov 2003 19:11:31 +1300
Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id hA36Eft13227; Mon, 3 Nov 2003 19:14:41 +1300
Date: Mon, 3 Nov 2003 19:14:41 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Good certificate renewal practice
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>

=?iso-8859-1?Q?Fr=E9d=E9ric_Giudicelli?= <[e-mail]> writes:

>After reviewing "pkix-roadmap" and "rfc2510bis" I found no details on how
>PKIs should handle certificates renewal.

That's a policy matter.

>Can a user request a renewal even if his/her certificate is not about to
>expiry?

That's a policy matter.

>If yes, should we revoke the previous certificate and after which delay?

That's a policy matter.

>Can a user request a renewal even if his/her certificate has expired?

Th.... well, you get the idea.

Peter.

(Incidentally, the person who originally suggested the ecumenical/policy
 comment has since expressed regret that he didn't trademark it or something
 :-).


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA34skkT050108 for <[e-mail]>; Sun, 2 Nov 2003 20:54:46 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA34sknR050107 for ietf-pkix-bks; Sun, 2 Nov 2003 20:54:46 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.newpki.org (ATuileries-102-1-3-88.w217-128.abo.wanadoo.fr [217.128.76.88]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA34sikT050100 for <[e-mail]>; Sun, 2 Nov 2003 20:54:45 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (localhost [127.0.0.1]) by smtp.newpki.org (Postfix) with ESMTP id D2F68B817 for <[e-mail]>; Mon,  3 Nov 2003 05:55:21 +0100 (CET)
Received: from smtp.newpki.org (localhost [127.0.0.1]) by localhost (AvMailGate-2.0.1.16) id 31954-3179637D; Mon, 03 Nov 2003 05:54:34 +0100
Received: from station1 (unknown [10.0.0.2]) by smtp.newpki.org (Postfix) with SMTP id 3A769B816 for <[e-mail]>; Mon,  3 Nov 2003 05:54:34 +0100 (CET)
Message-ID: <006f01c3a1c6$3db89790$0200000a@station1>
From: =?iso-8859-1?Q?Fr=E9d=E9ric_Giudicelli?= <[e-mail]>
To: <[e-mail]>
Subject: Good certificate renewal practice
Date: Mon, 3 Nov 2003 05:51:22 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-AntiVirus: checked by AntiVir MailGate (version: 2.0.1.16; AVE: 6.22.0.1; VDF: 6.22.0.24; host: server-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>

Hello,
After reviewing "pkix-roadmap" and "rfc2510bis" I found no details on how
PKIs should handle certificates renewal.
Can a user request a renewal even if his/her certificate is not about to
expiry? If yes, should we revoke the previous certificate and after which
delay?
Can a user request a renewal even if his/her certificate has expired?
I'm just lost on how implementing certificate renewal in my PKI.

Thanks,
Frédéric Giudicelli
http://www.newpki.org



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA33FKkT046270 for <[e-mail]>; Sun, 2 Nov 2003 19:15:20 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA33FKG0046269 for ietf-pkix-bks; Sun, 2 Nov 2003 19:15:20 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.33.151]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA33FGkT046261; Sun, 2 Nov 2003 19:15:19 -0800 (PST) (envelope-from [e-mail])
Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9-20030924/8.12.9) with ESMTP id hA33F3o9019410; Mon, 3 Nov 2003 16:15:03 +1300
Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id hA33ICW12346; Mon, 3 Nov 2003 16:18:12 +1300
Date: Mon, 3 Nov 2003 16:18:12 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Request change in son-of-rfc2633
Cc: [e-mail], [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>

Dale Gustafson <[e-mail]> writes:

>The issues raised re: creative ways to insert a "shim DLL" between a secure
>application and CryptoAPI (or any other security library using the common DLL
>form-factor) are most interesting and apply irrespective of use/non-use of
>SSL client authentication.  Anyone know of other recent work in this same
>area?

I look at it in chapter 6 of my book, "Cryptographic security architecture
design and verification".  There are a million ways to do this under Windows,
you can hijack and subvert pretty much anything you want, from kernel calls
(the kernel entry jump tables are modifiable from user-space) through to
subverting apps in various ways (the coolest one being thread injection, I'm
surprised virii don't use that one more often because you become totally
undetectable with that).  Chapter 6 covers the various implications of this in
more detail (I'm being lazy and just citing the chapter to avoid having to
paraphrase the whole thing here :-).

Peter.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA326ukT044066 for <[e-mail]>; Sun, 2 Nov 2003 18:06:56 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA326u2Q044065 for ietf-pkix-bks; Sun, 2 Nov 2003 18:06:56 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA326rkT044058; Sun, 2 Nov 2003 18:06:56 -0800 (PST) (envelope-from [e-mail])
Received: from bpsi.net (c-24-118-152-218.mn.client2.attbi.com[24.118.152.218]) by comcast.net (rwcrmhc12) with SMTP id <2003110302065001400cdmrbe> (Authid: degustafson); Mon, 3 Nov 2003 02:06:51 +0000
Message-ID: <[e-mail]>
Date: Sun, 02 Nov 2003 20:01:25 -0600
From: Dale Gustafson <[e-mail]>
X-Mailer: Mozilla 4.78 [en] (Win98; U)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: Paul Hoffman / IMC <[e-mail]>
CC: [e-mail], Jim Heimberg <[e-mail]>
Subject: Re: Request change in son-of-rfc2633
References: <007501c39f00$60446fa0$[e-mail]> <[e-mail]> <p0600206ebbc779d9d3fe@[63.202.92.152]>
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>

Paul Hoffman / IMC wrote

< ... >

> PCs are vulnerable. This doesn't mean we stop all development of
> things that run on PCs.
>
> (FWIW, the paper can be found at
> <http://www.cs.dartmouth.edu/~sws/papers/keyjack.pdf>.)

Interesting paper, although most secure application designers probably realize
that browser keystores are most often protected only by a user-chosen password
which may be weak or even NULL.

The issues raised re: creative ways to insert a "shim DLL" between a secure
application and CryptoAPI (or any other security library using the common DLL
form-factor) are most interesting and apply irrespective of use/non-use of SSL
client authentication.  Anyone know of other recent work in this same area?

> --Paul Hoffman, Director
> --Internet Mail Consortium

Regards,

Dale Gustafson




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA1ADMkT000904 for <[e-mail]>; Sat, 1 Nov 2003 02:13:22 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA1ADLA0000903 for ietf-pkix-bks; Sat, 1 Nov 2003 02:13:21 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp2.fre.skanova.net (smtp2.fre.skanova.net [195.67.227.95]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA1ADKkT000898 for <[e-mail]>; Sat, 1 Nov 2003 02:13:20 -0800 (PST) (envelope-from [e-mail])
Received: from arport (t7o913p55.telia.com [213.64.26.55]) by smtp2.fre.skanova.net (8.12.10/8.12.10) with SMTP id hA1ABoIo014252; Sat, 1 Nov 2003 11:11:50 +0100 (CET)
Message-ID: <007d01c3a060$22288010$371a40d5@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Pierre Heuze" <[e-mail]>, "Stephen Kent" <[e-mail]>, "Jean-Marc Desperrier" <[e-mail]>
Cc: <[e-mail]>
References: <DF2205440160D511B877000255745FF24911B5@TMAIL>
Subject: Re: Web-PKI Keygen/Certreq Questions
Date: Sat, 1 Nov 2003 11:08:42 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
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>

Pierre,
We apparently agree on the state of affaires.

Regarding your particular concerns, I am slightly less in agreement
as I see on-line certification being a provider-defined activity.
To in a PKCS #10 client-created packet "ask" for certain DN attributes
does not apply to such scenarios.  It is rather "all-on-the-server".

At least the systems that are rolled out in Europe are definitely
of that type and I think this make sense as well.  PKIX standards
(as well as current browser implementations), where designed for
a "collaborative" environment where the user often is supposed to
know about things like key length etc.

But PKIs for on-line banking and e-Governments (C2G) are
targeted at user groups who essentially know nothing about PKI.

The (mostly Java-written) systems I have seen in these areas are
all designed to hide PKI as much as it is technically possible.
These systems, AFAIK, all take a "complete grip" on the whole
process from on-line certification to on-line (web) signatures.

I don't know exactly where that leaves current PKIX standards
or what to do next though.

To get the browser vendors (which are at least five taking the
mobile dittos also in consideration), to cooperate is a major task.
It might actually be easier to define "the whole thing" (on-line
Web-PKI) from scratch using XML and perform this work in W3C
rather than "tweaking" current standards and existing systems.

My 2 öres at least.

Anders

----- Original Message -----
From: "Pierre Heuze" <[e-mail]>
To: "Stephen Kent" <[e-mail]>; "Jean-Marc Desperrier" <[e-mail]>
Cc: <[e-mail]>
Sent: Saturday, November 01, 2003 00:29
Subject: RE: Web-PKI Keygen/Certreq Questions



Anders Rundgren wrote:
>I cannot find any "compilation" of browser (on-line)-adapted mechanisms
>for performing key generation or performing certificate requests.
Indeed there isn't a de-facto reference for this, by now you must realize
every PKI/Browser vendors have developed their ownn solution as mentionned
already, but don't forget the many token/smart card providers who also have
come-up with additional solutions. So it's the jungle out there, as any
request in a search engine for "browser certificate request" or similar will
show (cf Stephen's comment do some more homework.)

Stephen Kent wrote:
> both browsers have had facilities for generating an RSA key pair for
> a user, and sending a cert request for years.
Indeed, at least 1998 from my own experience, but surely someone will claim
an earlier date. In practice, it is almost always based on free/liberal use
of PKCS#10; which has raised many interop issues as you all know, to mention
few (signature and extension format).

Jean-Marc Desperrier wrote:
>So, from the point of view of what should be put on a web page to get a
>browser to generate a certificate request, there is no standard.
>This can be considered not to be a valable item of concern for pkix
thought.
Indeed this topic is somewhat out of the scope of PKIX, but few things to
consider:
- Requesting a certificate is one of the most basic operation to be
completed in the PKI world and browser based application have gained a large
acceptance. So it is a valid concern.
- Requesting a certificate is a somewhat complex operation, and the
browser-based solution too often overlooked basic consideration for the sake
of simplicity, the main drawbacks are:
- No authentication, Proof of Possession (having the key pair) is
often taken as valid
        authentication mechanism (sic).
      - No standard way to mandate what certificate profile should be used
to fulfil the request
      - No control of the certificate life-cycle, each request are handled
separately which
        doesn't cater well when certificate need to be renewed, or
re-activated
        after suspension.
The above points are in part covered by various PKIX message format, but to
be honest they haven't gained acceptance (yet?) for browser based operations
and if used they are highly not interoperable (i.e. to say the least no
improvement on the interop side compare to using PKCS#10).

So is it the case that one should refine the standard to restrict the use of
existing messages to cover the above scenario as to achieve greater
interoperability and hence acceptance? To me this seems to be a genuine item
for the PKIX group.

Pierre Heuzé
http://www.cardbase.com


-----Original Message-----
From: Stephen Kent [mailto:[e-mail]]
Sent: 31 October 2003 19:35
To: Jean-Marc Desperrier
Cc: [e-mail]
Subject: Re: Web-PKI Keygen/Certreq Questions



At 19:15 +0100 10/31/03, Jean-Marc Desperrier wrote:
>Stephen Kent wrote:
>
>>At 16:21 +0100 10/31/03, Anders Rundgren wrote:
>>
>>>I cannot find any "compilation" of browser (on-line)-adapted mechanisms
>>>for performing key generation or performing certificate requests.
>>
>>yes, you are wrong.
>>
>>both browsers have had facilities for generating an RSA key pair
>>for a user, and sending a cert request for years.
>
>Facilities is one thing, interoperability is another.

I have not worked this problem recently, but in my  experience
developing three different CA products a few years ago, all were able
to accept enrollment requests from both browsers, and all major
providers of CA software did so as well. it was a necessary
prerequisite for selling CA software.

we now have 2 PKIX standards for enrollment protocols: CMP and CMC.
if the browser vendors choose to support these, then we have
interoperable solutions as well, but vendors must choose to make use
of them.

Steve


CardBASE Technologies®
Address: BIM House, Crofton Road, Dun Laoghaire, Co Dublin, Ireland
PH: [phone]  FAX: [phone]  WEB: http://www.cardbase.com
 ***********************************************************************
This e-mail and any attachment, contains information which is private
and confidential and is intended for the addressee only. If you are not
an addressee, you are not authorised to read, copy or use the e-mail
or any attachments. If you have received this e-mail in error, please
notify the sender by return e-mail and then destroy it.
This message has been swept for viruses by anti-virus software.
***********************************************************************