Re: encoding an X.509 certificate

[Steven Legg <[e-mail]>]

Tom,

Tom Gindin wrote:
>         Steven:
> 
>         Is your recommendation for re-encoding (in case b) that an RP 
> should re-encode everything other than extension values into DER, or that 
> it should also re-encode extension values whose syntax it recognizes?

In the case of certificate extensions, as far as the ASN.1 is concerned
the extension values are OCTET STRING values so they are not prone to
being altered by vanilla decoders and encoders. I think it is adequate
to leave them as is when re-encoding a certificate in DER, which is
the technically correct thing to do anyway. More so than with the
certificate as a whole, the RP is likely to have received the extension
value encodings that were actually signed.

Of course one could be ultra-interoperable and try the DER re-encoding
both ways.

Regards,
Steven

 > The
> statement "re-encode the received encoding into DER" cannot always be 
> executed on the values of unrecognized extensions,as I hope I've 
> demonstrated in earlier posts, although indefinite length encodings can 
> always be eliminated.
> 
>                 Tom Gindin
> 
> 
> 
> 
> Steven Legg <[e-mail]> 
> Sent by: [e-mail]
> 11/27/2008 06:51 PM
> 
> To
> Santosh Chokhani <[e-mail]>
> cc
> Michael Ströder <[e-mail]>, [e-mail]
> Subject
> Re: encoding an X.509 certificate
> 
> 
> 
> 
> 
> 
> 
> 
> Santosh,
> 
> Santosh Chokhani wrote:
>> Michael,
>>
>> The question remains what it does to interoperability and performance 
> since I suspect you are not the sole provider of PK enablement software to 
> the world.
> 
> I've lost track of what "it" is, but maybe this will answer your
> question. There are four possibilities to consider when a relying
> party receives some signed data:
> 
> (1) the signature is calculated over the DER encoding of the data
>      to be signed and the RP receives this DER encoding, or
> 
> (2) the signature is calculated over the DER encoding of the data
>      to be signed and the RP receives a non-DER re-encoding
>      of the signed data, or
> 
> (3) the signature is calculated over a non-DER encoding of the data
>      to be signed and the RP receives this same non-DER encoding, or
> 
> (4) the signature is calculated over a non-DER encoding of the data
>      to be signed and the RP receives a different re-encoding of the
>      signed data.
> 
> There are two basic strategies an RP can use to attempt to validate
> the signature on the signed data:
> 
> (a) check the signature using the encoding as received, or
> 
> (b) re-encode the received encoding into DER and check the
>      signature using the DER encoding.
> 
> An RP that just does (a) will validate the signature in cases (1) and (3).
> An RP that just does (b) will validate the signature in cases (1) and (2).
> There is no practical way of dealing with case (4), so we can disregard 
> it.
> 
> We know that signatures calculated over non-DER encodings are accepted
> in practice so implementations must generally be avoiding the re-encoding
> of signed data. Therefore I expect that (3) is more common than (2), in
> which case an RP that does only (a) will have better interoperability than
> an RP that does only (b).
> 
> To maximise interoperability an RP needs to try both (a) and (b), in
> which case it will validate the signature in cases (1), (2) and (3).
> If it tries (a) first, then in the best case (i.e., (1) or (3)) it only
> does one signature check, and in the worst case (i.e., (2)) it does two
> signature checks and a DER re-encoding of the signed data. If it tries
> (b) first, then in the best case (i.e., (1) or (2)) it does a DER
> re-encoding of the signed data and one signature check, and in the
> worst case (i.e., (3)) it does two signature checks and a DER re-encoding
> of the signed data.
> 
> The "(a) first" strategy is more efficient for (1) and (3), and the
> "(b) first" strategy is more efficient for (2). Since I expect (3) is
> more common than (2), "(a) first" will be the more efficient strategy
> overall.
> 
> Regards,
> Steven
> 
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] 
> On Behalf Of Michael Ströder
>> Sent: Wednesday, November 26, 2008 6:23 PM
>> To: [e-mail]
>> Subject: Re: encoding an X.509 certificate
>>
>>
>> Santosh Chokhani wrote:
>>> What does that do to interoperability or performance since you get
>>> certificates from various sources who can encode them whichever way.
>> When implementing the cert viewer in web2ldap it took me quite a while 
>> to believe how broken certs of major CAs are. So my development 
>> performance was really bad. And yes, like all others I've added a 
>> work-around...
>>
>> Ciao, Michael.
>>
> 
> 
> 




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mB10xEEN060120 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 30 Nov 2008 17:59:14 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mB10xEal060119; Sun, 30 Nov 2008 17:59:14 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from eb2bcom.com (eb2bcom.com [72.232.34.13]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mB10x23t060110 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Sun, 30 Nov 2008 17:59:12 -0700 (MST) (envelope-from [e-mail])
Received: from eth3065.vic.adsl.internode.on.net ([150.101.156.248] helo=[192.168.1.180]) by host.eb2bcom.com with esmtpa (Exim 4.69) (envelope-from <[e-mail]>) id 1L6x7s-000289-QT; Mon, 01 Dec 2008 11:59:01 +1100
Message-ID: <[e-mail]>
Date: Mon, 01 Dec 2008 11:58:56 +1100
From: Steven Legg <[e-mail]>
User-Agent: Thunderbird 2.0.0.18 (Windows/20081105)
MIME-Version: 1.0
To: Tom Gindin <[e-mail]>
CC: [e-mail], =?ISO-8859-1?Q?Michael_Str=F6der?= <[e-mail]>, Santosh Chokhani <[e-mail]>
Subject: Re: encoding an X.509 certificate
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - host.eb2bcom.com
X-AntiAbuse: Original Domain - imc.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - eb2bcom.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tom,

Tom Gindin wrote:
>         Steven:
> 
>         Is your recommendation for re-encoding (in case b) that an RP 
> should re-encode everything other than extension values into DER, or that 
> it should also re-encode extension values whose syntax it recognizes?

In the case of certificate extensions, as far as the ASN.1 is concerned
the extension values are OCTET STRING values so they are not prone to
being altered by vanilla decoders and encoders. I think it is adequate
to leave them as is when re-encoding a certificate in DER, which is
the technically correct thing to do anyway. More so than with the
certificate as a whole, the RP is likely to have received the extension
value encodings that were actually signed.

Of course one could be ultra-interoperable and try the DER re-encoding
both ways.

Regards,
Steven

 > The
> statement "re-encode the received encoding into DER" cannot always be 
> executed on the values of unrecognized extensions,as I hope I've 
> demonstrated in earlier posts, although indefinite length encodings can 
> always be eliminated.
> 
>                 Tom Gindin
> 
> 
> 
> 
> Steven Legg <[e-mail]> 
> Sent by: [e-mail]
> 11/27/2008 06:51 PM
> 
> To
> Santosh Chokhani <[e-mail]>
> cc
> Michael Ströder <[e-mail]>, [e-mail]
> Subject
> Re: encoding an X.509 certificate
> 
> 
> 
> 
> 
> 
> 
> 
> Santosh,
> 
> Santosh Chokhani wrote:
>> Michael,
>>
>> The question remains what it does to interoperability and performance 
> since I suspect you are not the sole provider of PK enablement software to 
> the world.
> 
> I've lost track of what "it" is, but maybe this will answer your
> question. There are four possibilities to consider when a relying
> party receives some signed data:
> 
> (1) the signature is calculated over the DER encoding of the data
>      to be signed and the RP receives this DER encoding, or
> 
> (2) the signature is calculated over the DER encoding of the data
>      to be signed and the RP receives a non-DER re-encoding
>      of the signed data, or
> 
> (3) the signature is calculated over a non-DER encoding of the data
>      to be signed and the RP receives this same non-DER encoding, or
> 
> (4) the signature is calculated over a non-DER encoding of the data
>      to be signed and the RP receives a different re-encoding of the
>      signed data.
> 
> There are two basic strategies an RP can use to attempt to validate
> the signature on the signed data:
> 
> (a) check the signature using the encoding as received, or
> 
> (b) re-encode the received encoding into DER and check the
>      signature using the DER encoding.
> 
> An RP that just does (a) will validate the signature in cases (1) and (3).
> An RP that just does (b) will validate the signature in cases (1) and (2).
> There is no practical way of dealing with case (4), so we can disregard 
> it.
> 
> We know that signatures calculated over non-DER encodings are accepted
> in practice so implementations must generally be avoiding the re-encoding
> of signed data. Therefore I expect that (3) is more common than (2), in
> which case an RP that does only (a) will have better interoperability than
> an RP that does only (b).
> 
> To maximise interoperability an RP needs to try both (a) and (b), in
> which case it will validate the signature in cases (1), (2) and (3).
> If it tries (a) first, then in the best case (i.e., (1) or (3)) it only
> does one signature check, and in the worst case (i.e., (2)) it does two
> signature checks and a DER re-encoding of the signed data. If it tries
> (b) first, then in the best case (i.e., (1) or (2)) it does a DER
> re-encoding of the signed data and one signature check, and in the
> worst case (i.e., (3)) it does two signature checks and a DER re-encoding
> of the signed data.
> 
> The "(a) first" strategy is more efficient for (1) and (3), and the
> "(b) first" strategy is more efficient for (2). Since I expect (3) is
> more common than (2), "(a) first" will be the more efficient strategy
> overall.
> 
> Regards,
> Steven
> 
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] 
> On Behalf Of Michael Ströder
>> Sent: Wednesday, November 26, 2008 6:23 PM
>> To: [e-mail]
>> Subject: Re: encoding an X.509 certificate
>>
>>
>> Santosh Chokhani wrote:
>>> What does that do to interoperability or performance since you get
>>> certificates from various sources who can encode them whichever way.
>> When implementing the cert viewer in web2ldap it took me quite a while 
>> to believe how broken certs of major CAs are. So my development 
>> performance was really bad. And yes, like all others I've added a 
>> work-around...
>>
>> Ciao, Michael.
>>
> 
> 
> 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mATL69YN096070 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 29 Nov 2008 14:06:09 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mATL69V9096069; Sat, 29 Nov 2008 14:06:09 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.cs.dartmouth.edu (mail.cs.dartmouth.edu [129.170.212.100]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mATL5vti096062 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Sat, 29 Nov 2008 14:06:09 -0700 (MST) (envelope-from [e-mail])
Received: from titan.cs.dartmouth.edu (mm.cs.dartmouth.edu [129.170.214.89]) (authenticated bits=0) by mail.cs.dartmouth.edu (8.14.2/8.14.2) with ESMTP id mATL5uGl030399 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Sat, 29 Nov 2008 16:05:57 -0500
Message-ID: <[e-mail]>
Date: Sat, 29 Nov 2008 16:05:55 -0500
From: Massimiliano Pala <[e-mail]>
Organization: Dartmouth College - Computer Science Department
User-Agent: Thunderbird 2.0.0.16 (X11/20080707)
MIME-Version: 1.0
To: pkix <[e-mail]>
Subject: New I-D for PRQP published
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000600000101030905040109"
Sender: [e-mail]
Precedence: 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.

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

Hi PKIX,

as promised in Minneapolis I published the new version of the PRQP I-D with
all the announced changes:

    http://www.ietf.org/internet-drafts/draft-ietf-pkix-prqp-01.txt

I added a lot of text for describing the OIDs. Being the first version of the
I-D carrying all the description, I would really appreciate if you could
provide me with feedback especially on them.

I also added the annex on how to use DNS SRV records and DHCP to distribute
the RQA address. Moreover I contacted Ralph Droms from the dhc WG and let him
know that the new version is published. I expect to receive feedback from the
dhc WG on Section B.1 (hopefully soon).

Happy thanksgiving to all of you who celebrated it...

-- 

Best Regards,

	Massimiliano Pala

--o------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager]  [e-mail]
                                                  [e-mail]

Dartmouth Computer Science Dept               Home Phone: [phone]
PKI/Trust Laboratory                          Work Phone: [phone]
--o------------------------------------------------------------------------
People who think they know everything are a great annoyance to those of us
who do.
							   -- Isaac Asimov

--------------ms000600000101030905040109
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJIjCC
BI0wggN1oAMCAQICAhpTMA0GCSqGSIb3DQEBBQUAMHcxEzARBgoJkiaJk/IsZAEZFgNlZHUx
GTAXBgoJkiaJk/IsZAEZFglkYXJ0bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0
bW91dGggQ29sbGVnZTEcMBoGA1UEAxMTRGFydG1vdXRoIENlcnRBdXRoMTAeFw0wNTExMDgy
MDMzMDZaFw0wOTExMDkyMDMzMDZaMIHBMRMwEQYKCZImiZPyLGQBGRYDZWR1MRkwFwYKCZIm
iZPyLGQBGRYJZGFydG1vdXRoMQswCQYDVQQGEwJVUzEaMBgGA1UEChMRRGFydG1vdXRoIENv
bGxlZ2UxGjAYBgoJkiaJk/IsZAEBEwoxMjI1NjAyOTQ3MRowGAYDVQQDExFNYXNzaW1pbGlh
bm8gUGFsYTEuMCwGCSqGSIb3DQEJARYfTWFzc2ltaWxpYW5vLlBhbGFARGFydG1vdXRoLmVk
dTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAsv8obBpbhPixgdyIJj7UN0GYRNhsgWHB
muCE5j8v8IvCSJWRF9spKoR0NBYgOfJu8DwQuKTIgrvbp0EC3ikrneotL4KTGD1IqWz/bSXL
UR/bZAsc0r9PrvCUsZOi7wbijy784gOuqQUCJ2fJwKwk5SJ3RBaPnUROQXTp+LPSK8MCAwEA
AaOCAVowggFWMA4GA1UdDwEB/wQEAwIF4DARBglghkgBhvhCAQEEBAMCBaAwgaIGA1UdIASB
mjCBlzCBlAYKKwYBBAFBAgEBATCBhTA9BggrBgEFBQcCAjAxMBgWEURhcnRtb3V0aCBDb2xs
ZWdlMAMCAQEaFURhcnRtb3V0aCBDb2xsZWdlIENQUzBEBggrBgEFBQcCARY4aHR0cDovL3d3
dy5kYXJ0bW91dGguZWR1L35wa2lsYWIvRGFydG1vdXRoQ1BTXzRTZXAwMy5wZGYwKgYDVR0R
BCMwIYEfTWFzc2ltaWxpYW5vLlBhbGFARGFydG1vdXRoLmVkdTAfBgNVHSMEGDAWgBQ/wNbH
p08Afu8GmWdsvJYeTaN3EjA/BggrBgEFBQcBAQQzMDEwLwYIKwYBBQUHMAGGI2h0dHA6Ly9j
b2xsZWdlY2EuZGFydG1vdXRoLmVkdS9vY3NwMA0GCSqGSIb3DQEBBQUAA4IBAQDEYIWmG3Ht
wcgFiBbrYKp7YpI62hgAw9I3Dj9Ai+etQcMDZL8cWg3Kd7DwYHDkLxO7jl518HIJCk8Elk+Z
3Y2c0rR+c9WLuxE+EHEUmQg2AbgxzRGZAeMXj7jrv5w75IWiXBrW3SdDkjVH6MQFZVP1CBk7
PF3/+dzmiO6E5g4cVtphPSdK2qtnX7Sh0zdePzeE+e0BTnsWdN0yHgKabKx3dCiEnQXt96sA
Jf5ckg7fFLcplohwWlWJCpk8WwnJM0QGw3xbrZvLk+kIQgyh0sn2va4FgA1ae29cJ1d2NurA
Z+LMdei9/ZbzBeMoD9XPSYyj7zLuVXGLF/JQQoPywk5oMIIEjTCCA3WgAwIBAgICGlMwDQYJ
KoZIhvcNAQEFBQAwdzETMBEGCgmSJomT8ixkARkWA2VkdTEZMBcGCgmSJomT8ixkARkWCWRh
cnRtb3V0aDELMAkGA1UEBhMCVVMxGjAYBgNVBAoTEURhcnRtb3V0aCBDb2xsZWdlMRwwGgYD
VQQDExNEYXJ0bW91dGggQ2VydEF1dGgxMB4XDTA1MTEwODIwMzMwNloXDTA5MTEwOTIwMzMw
NlowgcExEzARBgoJkiaJk/IsZAEZFgNlZHUxGTAXBgoJkiaJk/IsZAEZFglkYXJ0bW91dGgx
CzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91dGggQ29sbGVnZTEaMBgGCgmSJomT8ixk
AQETCjEyMjU2MDI5NDcxGjAYBgNVBAMTEU1hc3NpbWlsaWFubyBQYWxhMS4wLAYJKoZIhvcN
AQkBFh9NYXNzaW1pbGlhbm8uUGFsYUBEYXJ0bW91dGguZWR1MIGfMA0GCSqGSIb3DQEBAQUA
A4GNADCBiQKBgQCy/yhsGluE+LGB3IgmPtQ3QZhE2GyBYcGa4ITmPy/wi8JIlZEX2ykqhHQ0
FiA58m7wPBC4pMiCu9unQQLeKSud6i0vgpMYPUipbP9tJctRH9tkCxzSv0+u8JSxk6LvBuKP
LvziA66pBQInZ8nArCTlIndEFo+dRE5BdOn4s9IrwwIDAQABo4IBWjCCAVYwDgYDVR0PAQH/
BAQDAgXgMBEGCWCGSAGG+EIBAQQEAwIFoDCBogYDVR0gBIGaMIGXMIGUBgorBgEEAUECAQEB
MIGFMD0GCCsGAQUFBwICMDEwGBYRRGFydG1vdXRoIENvbGxlZ2UwAwIBARoVRGFydG1vdXRo
IENvbGxlZ2UgQ1BTMEQGCCsGAQUFBwIBFjhodHRwOi8vd3d3LmRhcnRtb3V0aC5lZHUvfnBr
aWxhYi9EYXJ0bW91dGhDUFNfNFNlcDAzLnBkZjAqBgNVHREEIzAhgR9NYXNzaW1pbGlhbm8u
UGFsYUBEYXJ0bW91dGguZWR1MB8GA1UdIwQYMBaAFD/A1senTwB+7waZZ2y8lh5No3cSMD8G
CCsGAQUFBwEBBDMwMTAvBggrBgEFBQcwAYYjaHR0cDovL2NvbGxlZ2VjYS5kYXJ0bW91dGgu
ZWR1L29jc3AwDQYJKoZIhvcNAQEFBQADggEBAMRghaYbce3ByAWIFutgqntikjraGADD0jcO
P0CL561BwwNkvxxaDcp3sPBgcOQvE7uOXnXwcgkKTwSWT5ndjZzStH5z1Yu7ET4QcRSZCDYB
uDHNEZkB4xePuOu/nDvkhaJcGtbdJ0OSNUfoxAVlU/UIGTs8Xf/53OaI7oTmDhxW2mE9J0ra
q2dftKHTN14/N4T57QFOexZ03TIeAppsrHd0KISdBe33qwAl/lySDt8UtymWiHBaVYkKmTxb
CckzRAbDfFutm8uT6QhCDKHSyfa9rgWADVp7b1wnV3Y26sBn4sx16L39lvMF4ygP1c9JjKPv
Mu5VcYsX8lBCg/LCTmgxggL4MIIC9AIBATB9MHcxEzARBgoJkiaJk/IsZAEZFgNlZHUxGTAX
BgoJkiaJk/IsZAEZFglkYXJ0bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91
dGggQ29sbGVnZTEcMBoGA1UEAxMTRGFydG1vdXRoIENlcnRBdXRoMQICGlMwCQYFKw4DAhoF
AKCCAdEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDgxMTI5
MjEwNTU1WjAjBgkqhkiG9w0BCQQxFgQUnQ3emTMIryEl/7kkk+d2yj1R+AgwUgYJKoZIhvcN
AQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYF
Kw4DAgcwDQYIKoZIhvcNAwICASgwgYwGCSsGAQQBgjcQBDF/MH0wdzETMBEGCgmSJomT8ixk
ARkWA2VkdTEZMBcGCgmSJomT8ixkARkWCWRhcnRtb3V0aDELMAkGA1UEBhMCVVMxGjAYBgNV
BAoTEURhcnRtb3V0aCBDb2xsZWdlMRwwGgYDVQQDExNEYXJ0bW91dGggQ2VydEF1dGgxAgIa
UzCBjgYLKoZIhvcNAQkQAgsxf6B9MHcxEzARBgoJkiaJk/IsZAEZFgNlZHUxGTAXBgoJkiaJ
k/IsZAEZFglkYXJ0bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91dGggQ29s
bGVnZTEcMBoGA1UEAxMTRGFydG1vdXRoIENlcnRBdXRoMQICGlMwDQYJKoZIhvcNAQEBBQAE
gYAeiyexKXxhSBkq+mZy88QOzdowPFBTZlapk1yhv/QtGw1vVVoI3szMOwL2StN2Vv5vDla3
LsfSTh9UtcG/pe4Ww/J6QjWMgpikboZrO89eMfIL1Gwvsg7we2UUEprjwKgR+XeJIweiswuR
BJ8KSzMSwv1hNLT1fsTjVJuvD3ogWQAAAAAAAA==
--------------ms000600000101030905040109--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mATFiwP9077498 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 29 Nov 2008 08:44:58 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mATFiwbb077497; Sat, 29 Nov 2008 08:44:58 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.156]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mATFijtY077470 for <[e-mail]>; Sat, 29 Nov 2008 08:44:56 -0700 (MST) (envelope-from [e-mail])
Received: by fg-out-1718.google.com with SMTP id l26so1291465fgb.26 for <[e-mail]>; Sat, 29 Nov 2008 07:44:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=7ZCk8kXLPoYZfRKssN7xAG+3AhyxHn/nv1qJxp5Ezqg=; b=PmYZ0HP5HpH+7xpIN8gvcBXDl4MV9GLbgVYV0esHhl/qB8KfSSGeCENgjAwfEB6t6p +rK+PJ+lC8K5Rs+xQazuouwr0TJvyqH/E90Rw05Dwm3guchdU82b9946NtCTgw2PciG7 Mldi942legmvA3HZDEJ5CuIvko3JDkuuit8zk=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=TkPJWkwWvPoVapAX9/2tikjTAjv+jrqhf8gwS1a56GIXtBOEhJAwMKL+AnVy7omqUB GmYQ/nKgZ+ltrJgaE9L6zW65MXkLezQMbGzB10RLU1AWPHXr3BMOtCxc1z1+mP/iEpS/ AKkr8Bvatk3ZC+V1okXHFQ/5GVARfs0UuQLzQ=
Received: by 10.181.18.2 with SMTP id v2mr3175179bki.194.1227973483999; Sat, 29 Nov 2008 07:44:43 -0800 (PST)
Received: by 10.180.207.15 with HTTP; Sat, 29 Nov 2008 07:44:43 -0800 (PST)
Message-ID: <[e-mail]>
Date: Sat, 29 Nov 2008 16:44:43 +0100
From: "=?ISO-8859-1?Q?Jorge_L=F3pez?=" <[e-mail]>
To: "Anders Rundgren" <[e-mail]>
Subject: Re: The EU Signature Directive - A 15+15 Year Perspective
Cc: [e-mail]
In-Reply-To: <1E0ECAB75B5B496F942BC7D49F9D7DA5@AndersPC>
MIME-Version: 1.0
Content-Type: multipart/alternative;  boundary="----=_Part_80624_20426458.1227973483990"
References: <1E0ECAB75B5B496F942BC7D49F9D7DA5@AndersPC>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

------=_Part_80624_20426458.1227973483990
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi all,
In Spain, we are (un)fortunatelly one of the few countries that have moved
the EU Directive on Electronic Signatures to a National Law. Now, users own
insecure tools to create non-repudiable and legally-binding e-signatures.
What is going on with current business model? Do the users have to cope with
the legal consequences of a signature created on their behalf, just because
a cryptographic validation of a set of bits says that?

The purposes derived from a handwritten signature have been directly
translated to the digital realm by means of PKI and cryptography. However,
the conditions and threats under which a signature is generated in the
digital realm are obviously far away from those of the physical realm. IMHO,
the main reason that make current business model fail is precisely the
uncertainty that end users have respecting the actual security of
PKI-enabled applications and the founded "legal support".

Regards,

Jorge L. Hernandez-Ardieta

2008/11/18 Anders Rundgren <[e-mail]>

>  Some 15 years ago the EU launched a signature directive.  This posting
> tries to describe the consequences of this directive with respect to usage
> of PKI.
>
> *Primary Motivation*
>
> There are a number of processes needing a human-written signature in order
> to fulfill legal requirements.
>
> Some of these processes could without doubt be possible to carry out
> electronically and thus also remote over a network, if there was some kind
> of technology available that could serve as a replacement for a hand-written
> signature.
>
> *The Solution*
>
> Right or wrong, digital signatures using PKI were considered as a
> viable alternative.  To make PKI a credible solution, the EU signature
> directive added a number of requirements including characteristics of the
> signature creation device and policies for CAs.
>
> *Current Deployment*
>
> Apart from Qualified Certificates which (for reasons too diverse for
> describing in an email) have not become truly mainstream, the EU signature
> directive have indeed in local legislations made it possible to perform
> fairly qualified tasks remotely over the Internet.  I.e. the directive has
> functioned as an *ENABLER*.
>
> *Then Something Went Wrong...*
>
> Unfortunately, a few (but influential) people got a bit carried away and
> interpreted the signature directive in way that has severely hampered the
> use of PKI.  Essentially they began claiming that all messages in order to
> be trustworthy should be signed by a qualified signature or at least by a
> digital signature created under the direct control a human being.
>
> From a 50000 ft perspective this may sound like a great idea, but the fact
> is that decades before the signature directive was conceived; yes, even
> before PKI was invented, the concept of secure messaging actually
> existed.  Back in those days secure messaging was facilitated through the
> use of leased lines which allowed banks (and some early b2b networks), to
> securely exchange transaction messages *in a completely automated fashion*
> .
>
> An example:  If you want to wire-transfer money from your bank to another
> bank, the way the transfer is initiated (phone, paper, on-line, etc) has no
> impact on the transaction messaging because it is performed in a transaction
> network that neither the customers, nor most of the staff have direct access
> to.
>
> That such networks have proved to be secure, reliable, cost-efficient, and
> sometimes even globally scalable, apparently did not impress the bunch of
> hard-core signature experts who for example in Germany managed to make PKI a
> *DISABLER* by outlawing non-human digital signatures on invoices.  That
> German paper-invoices do not even require signatures makes this position a
> true mystery.
>
> One had hoped that this would be an exception to the rule but it is not; If
> you scan sites like NIST.GOV, CIO.GOV, and GSA.GOV you'll find literally
> thousands of security-related documents, indeed in a few places mentioning
> PKI, but mostly full of government regulation abbreviations like FISMA,
> giving little if any guidance on how to create secure messaging between
> agencies, not to mention between agencies and the private sector.
>
> I'm happy to see that the Nordic countries plus Estonia have realized that
> all signatures that can be securely bound to an entity (in practice) are
> legally binding, in the extremely rare case somebody would actually
> repudiate a signed invoice.   These governments have all (and independently
> of each other) created local variants of a scheme that I have described in:
> http://webpki.org/papers/web/gateway.pdf
> which could be characterized as a 21st century version of leased lines for
> multi-party automated secure messaging.
> It will probably take another 15 years for this concept to achieve general
> acceptance although it is really (if you look closely) very similar to the
> US e-Authentication scheme, they have just not connected the dots yet: A
> SAML assertion and an server-signed invoice from a specific entity are
> essentially only different in content, not in trustworthiness.
>
> Anders Rundgren
> http://WebPKI.org
>
>
>

------=_Part_80624_20426458.1227973483990
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi all,<div><br></div><div>In Spain, we are&nbsp;(un)fortunatelly one of the few countries that have moved the EU Directive on Electronic Signatures to a National Law. Now, users own insecure tools to create non-repudiable and legally-binding e-signatures. What is going on with current business model? Do the users have to cope with the legal consequences of a signature created on their behalf, just because a cryptographic validation of a set of bits says that?</div>
<div><br></div><div>The purposes derived from a handwritten signature have been directly translated to the digital realm by means of PKI and cryptography. However, the conditions and threats under which a signature is generated in the digital realm are obviously far away from those of the physical realm. IMHO, the main reason that make current business model fail is precisely the uncertainty that end users have respecting the actual security of PKI-enabled applications and the founded &quot;legal support&quot;.</div>
<div><br></div><div>Regards,</div><div><br></div><div>Jorge L. Hernandez-Ardieta</div><div><br><div class="gmail_quote">2008/11/18 Anders Rundgren <span dir="ltr">&lt;<a href="mailto:[e-mail]">[e-mail]</a>&gt;</span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">





<div bgcolor="#ffffff">
<div><font face="Arial" size="2">Some 15 years ago the EU launched a signature 
directive.&nbsp; This posting tries to describe the consequences of this 
directive with respect to usage of PKI.</font></div>
<div><font face="Arial" size="2"></font>&nbsp;</div>
<div><font face="Arial"><strong>Primary Motivation</strong></font></div>
<div><font face="Arial" size="2"></font>&nbsp;</div>
<div><font face="Arial" size="2">There are a number of processes&nbsp;needing a 
human-written signature in order to fulfill legal requirements.</font></div>
<div><font face="Arial" size="2"></font>&nbsp;</div>
<div><font face="Arial" size="2">Some of these processes could without doubt be 
possible to carry out electronically and thus also remote over a network, if 
there was some kind of technology available that could serve as a replacement 
for a hand-written signature.</font></div>
<div><font face="Arial" size="2"></font>&nbsp;</div>
<div><font face="Arial"><strong>The Solution</strong></font></div>
<div><font face="Arial" size="2"></font>&nbsp;</div>
<div><font face="Arial" size="2">Right or wrong, digital signatures using PKI were 
considered as&nbsp;a viable&nbsp;alternative.&nbsp; To make PKI a credible 
solution, the EU signature directive added a number of requirements including 
characteristics of the signature creation device and policies for 
CAs.</font></div>
<div><font face="Arial" size="2"></font>&nbsp;</div>
<div><font face="Arial"><strong>Current Deployment</strong></font></div>
<div><font face="Arial" size="2"></font>&nbsp;</div>
<div><font face="Arial" size="2"><font face="Arial" size="2">Apart from Qualified 
Certificates which (for reasons too diverse for describing in an email) have not 
become truly mainstream, the EU signature directive have indeed in local 
legislations made it possible to perform fairly qualified tasks remotely over 
the Internet.&nbsp; I.e. the directive has functioned as an 
<strong>ENABLER</strong>.</font></font></div>
<div><font face="Arial" size="2"></font>&nbsp;</div>
<div><font face="Arial"><strong>Then Something 
Went&nbsp;Wrong...</strong></font></div>
<div><font face="Arial" size="2"></font>&nbsp;</div>
<div><font face="Arial" size="2">Unfortunately, a few (but&nbsp;influential) people 
got a bit carried away and interpreted the signature directive in way that has 
severely hampered the use of PKI.&nbsp; Essentially they began claiming that all 
messages in order to be&nbsp;trustworthy should be signed by a qualified 
signature or at least by a digital signature created&nbsp;under the direct 
control&nbsp;a human being.</font></div>
<div><font face="Arial" size="2"></font>&nbsp;</div>
<div><font face="Arial" size="2">From a 50000 ft perspective this may sound like a 
great idea, but the fact is that decades before the signature directive was 
conceived; yes, even before PKI was invented, the concept of secure messaging 
actually existed.&nbsp;&nbsp;Back in those days&nbsp;secure messaging was 
facilitated through the use of leased lines which allowed banks (and some early 
b2b networks), to securely exchange transaction messages <em>in a completely 
automated fashion</em>.</font></div>
<div><font face="Arial" size="2"></font>&nbsp;</div>
<div><font face="Arial" size="2">An example:&nbsp; If you want to wire-transfer 
money from your bank to another bank, the way the transfer is initiated (phone, 
paper,&nbsp;on-line, etc)&nbsp;has no impact on the transaction messaging 
because it is&nbsp;performed in a transaction network that neither 
the&nbsp;customers, nor&nbsp;most of the staff have direct access 
to.&nbsp;</font></div>
<div><font face="Arial" size="2"></font>&nbsp;</div>
<div><font face="Arial" size="2">That&nbsp;such networks have proved to be secure, 
reliable, cost-efficient, and sometimes even globally scalable, apparently did 
not impress the bunch of hard-core signature experts who for example in Germany 
managed to make PKI a <strong>DISABLER</strong> by outlawing non-human digital 
signatures on invoices.&nbsp; That German paper-invoices do not even require 
signatures&nbsp;makes this position a true mystery.</font></div>
<div><font face="Arial" size="2"></font>&nbsp;</div>
<div><font face="Arial" size="2">One had hoped that this would be an exception to 
the rule but it is not; If you scan sites like <a href="http://NIST.GOV" target="_blank">NIST.GOV</a>, <a href="http://CIO.GOV" target="_blank">CIO.GOV</a>, and <a href="http://GSA.GOV" target="_blank">GSA.GOV</a> 
you&#39;ll find literally thousands of security-related documents, indeed in a few 
places mentioning PKI, but mostly full of government regulation abbreviations 
like FISMA, giving little if any guidance on how to create secure messaging 
between agencies, not to mention between agencies and the private 
sector.</font></div>
<div><font face="Arial" size="2"></font>&nbsp;</div>
<div><font face="Arial" size="2">I&#39;m happy to see&nbsp;that the Nordic countries 
plus Estonia have realized that all signatures that can be securely bound to an 
entity (in practice) are legally binding, in the extremely rare case somebody 
would actually repudiate a signed invoice.&nbsp;&nbsp; These governments have 
all (and independently of each other) created local variants of&nbsp;a scheme 
that I have described in:</font></div>
<div><a href="http://webpki.org/papers/web/gateway.pdf" target="_blank"><font face="Arial" size="2">http://webpki.org/papers/web/gateway.pdf</font></a></div>
<div><font face="Arial" size="2">which&nbsp;could be characterized as&nbsp;a 21st 
century version of leased lines for multi-party&nbsp;automated secure 
messaging.</font><br></div>
<div><font face="Arial" size="2">It will probably take another 15 years for this 
concept to achieve general acceptance although it is really (if you look 
closely) very similar&nbsp;to the US e-Authentication scheme, they have just not 
connected the dots yet:&nbsp;A SAML assertion and an server-signed&nbsp;invoice 
from a specific entity are essentially only different in content, not in 
trustworthiness.</font></div>
<div><font face="Arial" size="2"></font>&nbsp;</div>
<div><font face="Arial" size="2">Anders Rundgren</font></div>
<div><font face="Arial" size="2"><a href="http://WebPKI.org" target="_blank">http://WebPKI.org</a></font></div>
<div><font face="Arial" size="2"></font>&nbsp;</div>
<div><font face="Arial" size="2"></font>&nbsp;</div></div>
</blockquote></div><br></div>

------=_Part_80624_20426458.1227973483990--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mATC29GH067896 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 29 Nov 2008 05:02:09 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mATC29hS067895; Sat, 29 Nov 2008 05:02:09 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.157]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mATC1vJO067882 for <[e-mail]>; Sat, 29 Nov 2008 05:02:08 -0700 (MST) (envelope-from [e-mail])
Received: by fg-out-1718.google.com with SMTP id l26so1264890fgb.26 for <[e-mail]>; Sat, 29 Nov 2008 04:01:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type:references; bh=YdghVbfneFhGSaMddm+XLV6imGind1fkd5L2hfRuEqg=; b=fLseG3PEoR9DiwJRw+5Q7Da0EZJ7v/SW37SRPehqQw3ijVLh2gLeveDEC3rXBo6XWE Obi4bIXrZoUfiKz/XvLfv0J5M1UTLlORWKuM3guAIDNtsIyerroK2jea+a1BAB1DartB IejGlIIRrWR1ITBUgS9I9P4zJeNnNi3DXCZ1E=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:references; b=WiVzYX1ssopwvXOxIc71U5BFpXHl7qUpQHUrY/L1DdhivLopAjW0jUG07bZrk2nB1t vvZmSZErX0ANSc7sJTGeQY8295v2FZk8Q2smxFJUMdxJ4X1E3AnC1PAA8Zl4Bnq4MkxX t8ApooWBOvA7CpaKvtMYZFDGh8mtnAbmdqOjg=
Received: by 10.181.33.18 with SMTP id l18mr235946bkj.192.1227960116030; Sat, 29 Nov 2008 04:01:56 -0800 (PST)
Received: by 10.180.207.15 with HTTP; Sat, 29 Nov 2008 04:01:55 -0800 (PST)
Message-ID: <[e-mail]>
Date: Sat, 29 Nov 2008 13:01:55 +0100
From: "=?ISO-8859-1?Q?Jorge_L=F3pez?=" <[e-mail]>
To: [e-mail]
Subject: Re: Signing and Encrypting with the same key?
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative;  boundary="----=_Part_79160_8051648.1227960116017"
References: <[e-mail]> <B9A9F0E608D94D2CA899102A88789787@AndersPC> <[e-mail]> <51604CB892B44C39BAF60D61875EB21E@AndersPC> <[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>

------=_Part_79160_8051648.1227960116017
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi all,
This mail was intented for the past discussion about if using the same key
pair for encrypting and signing may derive in a reduction of the security of
the scheme. Sorry if it's too late for that, but I haven't had the URL to
the paper so far. The URL points to the recent results of a research
(preprint version) made by a spanish colleague of mine where they actually
prove the security or insecurity of using the same key pair in both
encryption and signature schemes, depending on the specific situation.

http://eprint.iacr.org/2008/466

Hope this (still) help a bit

Regards,

Jorge L. Hernandez-Ardieta

2008/11/17 Kemp, David P. <[e-mail]>

>
>
> -----Original Message-----
> > From: Stephen Wilson
> >
> > I'd like to know the precise
> > history of the NR bit in X.509.  Who actually thought of it, were they
> > an engineer or a lawyer, and what if any debate went on at the time?
>
> Trust me, you really, REALLY don't want to know :-).
>
> Those on one side of the argument thought that the NR bit set should be
> used for signatures that could be validated indefinitely (i.e. for what one
> normally thinks of as "signing"), and signatures with the NR bit clear could
> be used only for session authentication.  That way a signed object created
> as part of a login session could not be misrepresented as a signed document.
>
> Those on the other side thought that the NR bit actually had something to
> do with "repudiating" signatures, which IMHO is a ridiculous idea for the
> reasons you suggest.  Those who believe in the current X.509 interpretation
> may defend it if they wish, or spare us the discussion.
>
> Dave
>

------=_Part_79160_8051648.1227960116017
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

<span class="Apple-style-span" style="border-collapse: collapse; ">Hi all,<div><br></div><div>This mail was intented for the past discussion about if using the same key pair for encrypting and signing may derive in a reduction of the security of the scheme. Sorry if it&#39;s too late for that, but I haven&#39;t had the URL to the paper so far. The URL points to&nbsp;the recent results of a research (preprint version) made by a spanish colleague of mine where they actually prove the security or insecurity of using the same key pair in both encryption and signature schemes, depending on the specific situation.</div>
<div><br></div><div><a href="http://eprint.iacr.org/2008/466">http://eprint.iacr.org/2008/466</a><br></div><div><br></div><div><span style="border-collapse: collapse; ">Hope this&nbsp;(still)&nbsp;help a bit&nbsp;</span></div><div><span style="border-collapse: collapse; "><br>
</span></div><div><span style="border-collapse: collapse; ">Regards,</span></div><div><span style="border-collapse: collapse; "><br></span></div><div><span style="border-collapse: collapse; ">Jorge L. Hernandez-Ardieta</span></div>
</span><br><div class="gmail_quote">2008/11/17 Kemp, David P. <span dir="ltr">&lt;<a href="mailto:[e-mail]">[e-mail]</a>&gt;</span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="Ih2E3d"><br>
<br>
-----Original Message-----<br>
&gt; From: Stephen Wilson<br>
&gt;<br>
&gt; I&#39;d like to know the precise<br>
&gt; history of the NR bit in X.509. &nbsp;Who actually thought of it, were they<br>
&gt; an engineer or a lawyer, and what if any debate went on at the time?<br>
<br>
</div>Trust me, you really, REALLY don&#39;t want to know :-).<br>
<br>
Those on one side of the argument thought that the NR bit set should be used for signatures that could be validated indefinitely (i.e. for what one normally thinks of as &quot;signing&quot;), and signatures with the NR bit clear could be used only for session authentication. &nbsp;That way a signed object created as part of a login session could not be misrepresented as a signed document.<br>

<br>
Those on the other side thought that the NR bit actually had something to do with &quot;repudiating&quot; signatures, which IMHO is a ridiculous idea for the reasons you suggest. &nbsp;Those who believe in the current X.509 interpretation may defend it if they wish, or spare us the discussion.<br>

<br>
Dave<br>
</blockquote></div><br>

------=_Part_79160_8051648.1227960116017--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAT4ExJc048948 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Nov 2008 21:15:00 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAT4ExKh048947; Fri, 28 Nov 2008 21:14:59 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAT4Ex3E048941 for <[e-mail]>; Fri, 28 Nov 2008 21:14:59 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id A12D63A67DF; Fri, 28 Nov 2008 20:15:01 -0800 (PST)
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D Action:draft-ietf-pkix-prqp-01.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Fri, 28 Nov 2008 20:15:01 -0800 (PST)
Sender: [e-mail]
Precedence: 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           : PKI Resource Query Protocol (PRQP)
	Author(s)       : M. Pala
	Filename        : draft-ietf-pkix-prqp-01.txt
	Pages           : 34
	Date            : 2008-11-28

One of the most strategic problems still open in PKIX is locating
public data and services associated with a Certification Authority
(CA).  This issue impacts interoperability and usability in PKIX.

This draft describes the PKI Resource Query Protocol (PRQP), its
design, definition, and its impact in already deployed PKIX
protocols.

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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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: Message/External-body;
	name="draft-ietf-pkix-prqp-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--NextPart--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAT36VhK046435 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Nov 2008 20:06:32 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAT36VbO046434; Fri, 28 Nov 2008 20:06:31 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from e8.ny.us.ibm.com (e8.ny.us.ibm.com [32.97.182.138]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAT36HfF046424 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Fri, 28 Nov 2008 20:06:28 -0700 (MST) (envelope-from [e-mail])
Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e8.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id mAT31pUP009436 for <[e-mail]>; Fri, 28 Nov 2008 22:01:51 -0500
Received: from d01av05.pok.ibm.com (d01av05.pok.ibm.com [9.56.224.195]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id mAT36ECs161342 for <[e-mail]>; Fri, 28 Nov 2008 22:06:16 -0500
Received: from d01av05.pok.ibm.com (loopback [127.0.0.1]) by d01av05.pok.ibm.com (8.13.1/8.13.3) with ESMTP id mAT36DtY005661 for <[e-mail]>; Fri, 28 Nov 2008 22:06:14 -0500
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.56.228.115]) by d01av05.pok.ibm.com (8.13.1/8.12.11) with ESMTP id mAT36DI6005658; Fri, 28 Nov 2008 22:06:13 -0500
In-Reply-To: <[e-mail]>
To: Steven Legg <[e-mail]>
Cc: [e-mail], =?ISO-8859-1?Q?Michael_Str=F6der?= <[e-mail]>, Santosh Chokhani <[e-mail]>
MIME-Version: 1.0
Subject: Re: encoding an X.509 certificate
X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006
From: Tom Gindin <[e-mail]>
Message-ID: <[e-mail]>
Date: Fri, 28 Nov 2008 22:06:12 -0500
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 8.0.1 HF1|June 13, 2008) at 11/28/2008 22:06:13, Serialize complete at 11/28/2008 22:06:13
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

        Steven:

        Is your recommendation for re-encoding (in case b) that an RP=20
should re-encode everything other than extension values into DER, or that=20
it should also re-encode extension values whose syntax it recognizes?  The =

statement "re-encode the received encoding into DER" cannot always be=20
executed on the values of unrecognized extensions, as I hope I've=20
demonstrated in earlier posts, although indefinite length encodings can=20
always be eliminated.

                Tom Gindin




Steven Legg <[e-mail]>=20
Sent by: [e-mail]
11/27/2008 06:51 PM

To
Santosh Chokhani <[e-mail]>
cc
Michael Str=F6der <[e-mail]>, [e-mail]
Subject
Re: encoding an X.509 certificate








Santosh,

Santosh Chokhani wrote:
> Michael,
>=20
> The question remains what it does to interoperability and performance=20
since I suspect you are not the sole provider of PK enablement software to =

the world.

I've lost track of what "it" is, but maybe this will answer your
question. There are four possibilities to consider when a relying
party receives some signed data:

(1) the signature is calculated over the DER encoding of the data
     to be signed and the RP receives this DER encoding, or

(2) the signature is calculated over the DER encoding of the data
     to be signed and the RP receives a non-DER re-encoding
     of the signed data, or

(3) the signature is calculated over a non-DER encoding of the data
     to be signed and the RP receives this same non-DER encoding, or

(4) the signature is calculated over a non-DER encoding of the data
     to be signed and the RP receives a different re-encoding of the
     signed data.

There are two basic strategies an RP can use to attempt to validate
the signature on the signed data:

(a) check the signature using the encoding as received, or

(b) re-encode the received encoding into DER and check the
     signature using the DER encoding.

An RP that just does (a) will validate the signature in cases (1) and (3).
An RP that just does (b) will validate the signature in cases (1) and (2).
There is no practical way of dealing with case (4), so we can disregard=20
it.

We know that signatures calculated over non-DER encodings are accepted
in practice so implementations must generally be avoiding the re-encoding
of signed data. Therefore I expect that (3) is more common than (2), in
which case an RP that does only (a) will have better interoperability than
an RP that does only (b).

To maximise interoperability an RP needs to try both (a) and (b), in
which case it will validate the signature in cases (1), (2) and (3).
If it tries (a) first, then in the best case (i.e., (1) or (3)) it only
does one signature check, and in the worst case (i.e., (2)) it does two
signature checks and a DER re-encoding of the signed data. If it tries
(b) first, then in the best case (i.e., (1) or (2)) it does a DER
re-encoding of the signed data and one signature check, and in the
worst case (i.e., (3)) it does two signature checks and a DER re-encoding
of the signed data.

The "(a) first" strategy is more efficient for (1) and (3), and the
"(b) first" strategy is more efficient for (2). Since I expect (3) is
more common than (2), "(a) first" will be the more efficient strategy
overall.

Regards,
Steven

>=20
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] =

On Behalf Of Michael Str=F6der
> Sent: Wednesday, November 26, 2008 6:23 PM
> To: [e-mail]
> Subject: Re: encoding an X.509 certificate
>=20
>=20
> Santosh Chokhani wrote:
>> What does that do to interoperability or performance since you get
>> certificates from various sources who can encode them whichever way.
>=20
> When implementing the cert viewer in web2ldap it took me quite a while=20
> to believe how broken certs of major CAs are. So my development=20
> performance was really bad. And yes, like all others I've added a=20
> work-around...
>=20
> Ciao, Michael.
>=20





Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mASBp704001031 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Nov 2008 04:51:08 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mASBp7aO001030; Fri, 28 Nov 2008 04:51:07 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ganymede.on-x.com (ganymede.on-x.com [194.51.68.3]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mASBotiX001006 for <[e-mail]>; Fri, 28 Nov 2008 04:51:06 -0700 (MST) (envelope-from [e-mail])
Received: from vinea.on-x.com (sedna.puteaux.on-x [192.168.10.9]) by ganymede.on-x.com (Postfix) with ESMTP id 5BF4F69; Fri, 28 Nov 2008 12:50:54 +0100 (CET)
Received: from [193.51.14.5] ([212.234.46.65]) by vinea.on-x.com (Lotus Domino Release 5.0.11) with ESMTP id 2008112812505265:239282 ; Fri, 28 Nov 2008 12:50:52 +0100 
Message-ID: <[e-mail]>
Date: Fri, 28 Nov 2008 12:45:24 +0100
From: Peter Sylvester <[e-mail]>
User-Agent: Thunderbird 1.5.0.9 (X11/20061206)
MIME-Version: 1.0
To: Steven Legg <[e-mail]>
Cc: Santosh Chokhani <[e-mail]>, =?ISO-8859-1?Q?Michael_S?= =?ISO-8859-1?Q?tr=F6der?= <[e-mail]>, [e-mail]
Subject: Re: encoding an X.509 certificate
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on vinea/ON-X(Release 5.0.11  |July 24, 2002) at 11/28/2008 12:50:52 PM, Serialize by Router on vinea/ON-X(Release 5.0.11  |July 24, 2002) at 11/28/2008 12:50:53 PM, Serialize complete at 11/28/2008 12:50:53 PM
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050403060307010308080902"
Sender: [e-mail]
Precedence: 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.

--------------ms050403060307010308080902
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Hi all,

The reference to X.509 seems to indicate that one should check (a)
and is not required to do (b).
I had forgotten that X.509 was so strict , "shall" means "MUST" in ISO=20
terms.

regards


Steven Legg wrote:
>
>
> Santosh,
>
> Santosh Chokhani wrote:
>> Michael,
>>
>> The question remains what it does to interoperability and performance =

>> since I suspect you are not the sole provider of PK enablement=20
>> software to the world.
>
> I've lost track of what "it" is, but maybe this will answer your
> question. There are four possibilities to consider when a relying
> party receives some signed data:
>
> (1) the signature is calculated over the DER encoding of the data
>     to be signed and the RP receives this DER encoding, or
>
> (2) the signature is calculated over the DER encoding of the data
>     to be signed and the RP receives a non-DER re-encoding
>     of the signed data, or
>
> (3) the signature is calculated over a non-DER encoding of the data
>     to be signed and the RP receives this same non-DER encoding, or
>
> (4) the signature is calculated over a non-DER encoding of the data
>     to be signed and the RP receives a different re-encoding of the
>     signed data.
>
> There are two basic strategies an RP can use to attempt to validate
> the signature on the signed data:
>
> (a) check the signature using the encoding as received, or
>
> (b) re-encode the received encoding into DER and check the
>     signature using the DER encoding.
>
> An RP that just does (a) will validate the signature in cases (1) and=20
> (3).
> An RP that just does (b) will validate the signature in cases (1) and=20
> (2).
> There is no practical way of dealing with case (4), so we can=20
> disregard it.
>
> We know that signatures calculated over non-DER encodings are accepted
> in practice so implementations must generally be avoiding the re-encodi=
ng
> of signed data. Therefore I expect that (3) is more common than (2), in=

> which case an RP that does only (a) will have better interoperability=20
> than
> an RP that does only (b).
>
> To maximise interoperability an RP needs to try both (a) and (b), in
> which case it will validate the signature in cases (1), (2) and (3).
> If it tries (a) first, then in the best case (i.e., (1) or (3)) it only=

> does one signature check, and in the worst case (i.e., (2)) it does two=

> signature checks and a DER re-encoding of the signed data. If it tries
> (b) first, then in the best case (i.e., (1) or (2)) it does a DER
> re-encoding of the signed data and one signature check, and in the
> worst case (i.e., (3)) it does two signature checks and a DER re-encodi=
ng
> of the signed data.
>
> The "(a) first" strategy is more efficient for (1) and (3), and the
> "(b) first" strategy is more efficient for (2). Since I expect (3) is
> more common than (2), "(a) first" will be the more efficient strategy
> overall.
>
> Regards,
> Steven
>
>>
>> -----Original Message-----
>> From: [e-mail]=20
>> [mailto:[e-mail]] On Behalf Of Michael Str=F6der
>> Sent: Wednesday, November 26, 2008 6:23 PM
>> To: [e-mail]
>> Subject: Re: encoding an X.509 certificate
>>
>>
>> Santosh Chokhani wrote:
>>> What does that do to interoperability or performance since you get
>>> certificates from various sources who can encode them whichever way.
>>
>> When implementing the cert viewer in web2ldap it took me quite a=20
>> while to believe how broken certs of major CAs are. So my development =

>> performance was really bad. And yes, like all others I've added a=20
>> work-around...
>>
>> Ciao, Michael.
>>
>
>


--=20

<http://www.edelweb.fr>
*Edel/W/eb* 	Peter SYLVESTER
Consultant S=E9curit=E9 des Syst=E8mes d'Information
-----------------------------------------------------------
EdelWeb - Groupe ON-X
15, quai de Dion-Bouton
F-92816 Puteaux Cedex
Tel : [phone] / Fax : [phone]
www.edelweb.fr <http://www.edelweb.fr> / www.on-x.com <http://www.on-x.co=
m>
-----------------------------------------------------------
To verify the message signature, see edelpki.edelweb.fr=20
<http://edelpki.edelweb.fr/>
Cela vous permet de charger le certificat de l'autorit=E9 de racine=20
<http://edelpki.edelweb.fr/cacerts/EdelPKI-ca.der>;
die Liste mit zur=FCckgerufenen Zertifikaten finden Sie da auch.



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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOhTCC
BHIwggLfoAMCAQICBgqvijKA3jANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G
A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs
UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNzAzMjYxMDM3MDNaFw0wOTA2MDMxMDM3MDNaMHAx
CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ
S0kxNTAzBgNVBAMMLFBldGVyIFNZTFZFU1RFUiA8UGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIu
ZnI+MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDPB7ZSfmYsUuVIV0W2izxb1Zyvr6ZJ
IjPiqRMs77dbEQhQ6FZhhUSuABxxc8NjZvyPMRo0uuT0iVpRDktb0fWPTx3m9qTfdqrhWg2c
IOBKNbNQr8NogDJvG1AxRx4q9SXKZCVpZCoHu3fz2Rfji1kL7l597+7qBEsFd9IyvRaexQID
AQABo4IBLjCCASowYgYDVR0RBFswWYEaUGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIuZnKkOzA5
MQswCQYDVQQGEwJGUjEQMA4GA1UECgwHRWRlbFdlYjEYMBYGA1UEAwwPUGV0ZXIgU1lMVkVT
VEVSMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD
VR0fBEMwQTA/oD2gO4Y5aHR0cDovL2VkZWxwa2kuZWRlbHdlYi5mci9jcmwvRWRlbFBLSS1F
ZGVsV2ViLVBlcnNHRU4uY3JsMB0GA1UdDgQWBBSZjq81LuJmsiiu1Yt/ezwCiUQSQTAfBgNV
HSMEGDAWgBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUA
A4IBfAAUq5MJ3gXhdKDpOm0ascDE9e1iMo0RQ24ujkc9IrFXhAJNS+3eNwcJEieU2vgZTsGb
zKeBZom1zVOFoh73VIRP6T08j4dDlndpDYZbxD20KzFt9zX6gV8IgR2zkkZXLQRbLyW16kw8
oFe3s//p1csCkCPAlZv1rZQYR5Psm0A1aiOiuSHhWUmgfAJxmIgfbmKtS3WpsUZVBuLQpThN
rWjLRAqJKYA++++qqo3ujqAAzJLe+MHrX5dai7+n6WBfV4qo1uDArR7XbmgVpV/EdPA75XRi
XEedLgbFDawJ9nAMN6WfL/NG6GZkEa7mZ7sH/gG34y21nq4w4mAAxn9wz7mDKMsEbJMZ5VlJ
TOp0g6TdYqGjNoc/rQg7pqjcRChVitwd1Rl8O31+bIdNSpv4UReNMDcffRQrt+pF1FxR4q6q
M9YLJU8NThx/89Mf/WF7fzrgVlsNJ78D9nJu0EhKes/9EX2qpIcHUfk/izOj8lCc1ksFgXpd
UEchE0DcMIIEcjCCAt+gAwIBAgIGCq+KMoDeMA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT
AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV
BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA3MDMyNjEwMzcwM1oXDTA5MDYwMzEw
MzcwM1owcDELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsMD1NlcnZp
Y2UgRWRlbFBLSTE1MDMGA1UEAwwsUGV0ZXIgU1lMVkVTVEVSIDxQZXRlci5TeWx2ZXN0ZXJA
ZWRlbHdlYi5mcj4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAM8HtlJ+ZixS5UhXRbaL
PFvVnK+vpkkiM+KpEyzvt1sRCFDoVmGFRK4AHHFzw2Nm/I8xGjS65PSJWlEOS1vR9Y9PHeb2
pN92quFaDZwg4Eo1s1Cvw2iAMm8bUDFHHir1JcpkJWlkKge7d/PZF+OLWQvuXn3v7uoESwV3
0jK9Fp7FAgMBAAGjggEuMIIBKjBiBgNVHREEWzBZgRpQZXRlci5TeWx2ZXN0ZXJAZWRlbHdl
Yi5mcqQ7MDkxCzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQDDA9QZXRl
ciBTWUxWRVNURVIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF
BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2ViLmZyL2NybC9F
ZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFJmOrzUu4mayKK7Vi397PAKJ
RBJBMB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MAkGA1UdEwQCMAAwDQYJKoZI
hvcNAQEFBQADggF8ABSrkwneBeF0oOk6bRqxwMT17WIyjRFDbi6ORz0isVeEAk1L7d43BwkS
J5Ta+BlOwZvMp4FmibXNU4WiHvdUhE/pPTyPh0OWd2kNhlvEPbQrMW33NfqBXwiBHbOSRlct
BFsvJbXqTDygV7ez/+nVywKQI8CVm/WtlBhHk+ybQDVqI6K5IeFZSaB8AnGYiB9uYq1Ldamx
RlUG4tClOE2taMtECokpgD7776qqje6OoADMkt74wetfl1qLv6fpYF9XiqjW4MCtHtduaBWl
X8R08DvldGJcR50uBsUNrAn2cAw3pZ8v80boZmQRruZnuwf+AbfjLbWerjDiYADGf3DPuYMo
ywRskxnlWUlM6nSDpN1ioaM2hz+tCDumqNxEKFWK3B3VGXw7fX5sh01Km/hRF40wNx99FCu3
6kXUXFHirqoz1gslTw1OHH/z0x/9YXt/OuBWWw0nvwP2cm7QSEp6z/0RfaqkhwdR+T+LM6Py
UJzWSwWBel1QRyETQNwwggWVMIIDMKADAgECAgYKwoI0lJgwDQYJKoZIhvcNAQEFBQAwUjEL
MAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2UgRWRlbFBL
STEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDcwNjI4MTc0MDU0WhcNMTQwNTAyMTc0
MDU0WjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2Vydmlj
ZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTjCCAZwwDQYJKoZI
hvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bcrJKIlnAPn6eH8V1M
ORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5JfuDjU6Aq0RzmjqTWDe
1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WLwHLA+sIKFzA/CCRt
qeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQNHeCgbUvebvAT9Hd
UGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy4DazzXfZosKeJATH
pyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38psgnVLtPPITgOZrS
cV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+EiISL7aJHQcJRoNB
CdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4GgMIGdMDoGA1UdHwQzMDEwL6AtoCuGKWh0
dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8GA1UdEwQIMAYBAf8C
AQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAfBgNV
HSMEGDAWgBSo2SuP1LBnur1JXLwz/HdSEblnnTANBgkqhkiG9w0BAQUFAAOCAk4AUgtIR4Jh
Ynyk939SM6X4YZPNYIgDio8Gp064P1MBILDgI/hzSwyxT5bb1qUQub+icXO9/5ufsDufr/ff
2gCzKMuo3hC26iey630PzHTvJgrTcEp9c92IZPt3UKeouqy+95Lz2r58dbfouKLZVwiKQ0jP
2c2U5tPWmzW4CAjFWUKRYlrhbt+tjzW8CAA0DHO1xrrzAuTyuGNKcH4LlLuVo7MbDPn/uLma
1fAVYvH2c6OTwGHJyKTQVveYw4UqgAhErJMFWJDKm+Q9h91mCzkjrA1Eu0nVDUTV1+dW6mNT
DPLIq0qSdqP7iT2WcNzQVy/0PiXT2aaEH9lE2W1SSD6PnT8y+aqJTGjRMK1cl7VSJHxbq8U9
lIS+6eiV5VrogAa8X52pKF0u91i+/CBZ3e5Mi2/BwMrMN/mXA/ZwL3p+jZpnijpqnqdz8iCn
qR9ExhR+BpN/b56RqEu7llLrcwOS44kjbubALjxe0+XutidWjt/6/tLYuM7rJ6Hk1EweFGVd
kRejKogD3GzZ3gOAIF/D28VBJcTRcyF7OI/k/3jPD0gHUGN1uxk2Krz8SE9GEPvP/JehCBl/
FrQOCsEUmszi7Se0Vxr2k1P7icxT7L/AcWt/djIgp/vsQNurbi0+5+q7YS2b2bc1HchjsmaI
cXy8ha5IGk4+F1qrHZsGqTm5M7TzZN6k0X2llMaozrtPzxNMC6uvf1uRvHYHf1x0Q0pdxTzZ
PuuFw1PUlu6o5xPHbf3ZgC7ZNSDry13ZEXmlG2Re0u9WwEJJ1nYqlcDvNzGCAq4wggKqAgEB
MGUwWzELMAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2Ug
RWRlbFBLSTEgMB4GA1UEAxMXRWRlbFBLSSBFZGVsV2ViIFBlcnNHRU4CBgqvijKA3jAJBgUr
DgMCGgUAoIIBnzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0w
ODExMjgxMTQ1MjRaMCMGCSqGSIb3DQEJBDEWBBQvui5dOfLUZ9HhepGGLHh7e4QROzBSBgkq
hkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIB
QDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDB0BgkrBgEEAYI3EAQxZzBlMFsxCzAJBgNVBAYT
AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV
BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOAgYKr4oygN4wdgYLKoZIhvcNAQkQAgsxZ6Bl
MFsxCzAJBgNVBAYTAkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVk
ZWxQS0kxIDAeBgNVBAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOAgYKr4oygN4wDQYJKoZI
hvcNAQEBBQAEgYCV1zD6U6hBQYLAOawOwMtD5xIQIf08EVrqCir/WOFbBkGSMlRAjFE0XJzp
pmUOpO8vNFr90vsMTdlnL7kqLdncwiMADQWpyv3GGyXcZcYucLcppL8OBRpLijVxzjL6rZ3C
zyuC1TT/fJZDWK9a4CnHXuXUiUmVTNtn4D0vzAHjuAAAAAAAAA==
--------------ms050403060307010308080902--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mARNq7F4066332 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Nov 2008 16:52:07 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mARNq7Z1066331; Thu, 27 Nov 2008 16:52:07 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from eb2bcom.com (eb2bcom.com [72.232.34.13]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mARNptt2066318 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 27 Nov 2008 16:52:05 -0700 (MST) (envelope-from [e-mail])
Received: from 202.164.192.219.static.rev.aanet.com.au ([202.164.192.219] helo=[192.168.99.100]) by host.eb2bcom.com with esmtpa (Exim 4.69) (envelope-from <[e-mail]>) id 1L5qeG-00056M-BZ; Fri, 28 Nov 2008 10:51:53 +1100
Message-ID: <[e-mail]>
Date: Fri, 28 Nov 2008 10:51:48 +1100
From: Steven Legg <[e-mail]>
User-Agent: Thunderbird 2.0.0.18 (Windows/20081105)
MIME-Version: 1.0
To: Santosh Chokhani <[e-mail]>
CC: =?ISO-8859-1?Q?Michael_Str=F6der?= <[e-mail]>, [e-mail]
Subject: Re: encoding an X.509 certificate
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
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - host.eb2bcom.com
X-AntiAbuse: Original Domain - imc.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - eb2bcom.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Sender: [e-mail]
Precedence: 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,

Santosh Chokhani wrote:
> Michael,
> 
> The question remains what it does to interoperability and performance since I suspect you are not the sole provider of PK enablement software to the world.

I've lost track of what "it" is, but maybe this will answer your
question. There are four possibilities to consider when a relying
party receives some signed data:

(1) the signature is calculated over the DER encoding of the data
     to be signed and the RP receives this DER encoding, or

(2) the signature is calculated over the DER encoding of the data
     to be signed and the RP receives a non-DER re-encoding
     of the signed data, or

(3) the signature is calculated over a non-DER encoding of the data
     to be signed and the RP receives this same non-DER encoding, or

(4) the signature is calculated over a non-DER encoding of the data
     to be signed and the RP receives a different re-encoding of the
     signed data.

There are two basic strategies an RP can use to attempt to validate
the signature on the signed data:

(a) check the signature using the encoding as received, or

(b) re-encode the received encoding into DER and check the
     signature using the DER encoding.

An RP that just does (a) will validate the signature in cases (1) and (3).
An RP that just does (b) will validate the signature in cases (1) and (2).
There is no practical way of dealing with case (4), so we can disregard it.

We know that signatures calculated over non-DER encodings are accepted
in practice so implementations must generally be avoiding the re-encoding
of signed data. Therefore I expect that (3) is more common than (2), in
which case an RP that does only (a) will have better interoperability than
an RP that does only (b).

To maximise interoperability an RP needs to try both (a) and (b), in
which case it will validate the signature in cases (1), (2) and (3).
If it tries (a) first, then in the best case (i.e., (1) or (3)) it only
does one signature check, and in the worst case (i.e., (2)) it does two
signature checks and a DER re-encoding of the signed data. If it tries
(b) first, then in the best case (i.e., (1) or (2)) it does a DER
re-encoding of the signed data and one signature check, and in the
worst case (i.e., (3)) it does two signature checks and a DER re-encoding
of the signed data.

The "(a) first" strategy is more efficient for (1) and (3), and the
"(b) first" strategy is more efficient for (2). Since I expect (3) is
more common than (2), "(a) first" will be the more efficient strategy
overall.

Regards,
Steven

> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Michael Ströder
> Sent: Wednesday, November 26, 2008 6:23 PM
> To: [e-mail]
> Subject: Re: encoding an X.509 certificate
> 
> 
> Santosh Chokhani wrote:
>> What does that do to interoperability or performance since you get
>> certificates from various sources who can encode them whichever way.
> 
> When implementing the cert viewer in web2ldap it took me quite a while 
> to believe how broken certs of major CAs are. So my development 
> performance was really bad. And yes, like all others I've added a 
> work-around...
> 
> Ciao, Michael.
> 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mARB3p9t006033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Nov 2008 04:03:51 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mARB3pKN006032; Thu, 27 Nov 2008 04:03:51 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mo-p00-ob.rzone.de (mo-p00-ob.rzone.de [81.169.146.161]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mARB3dTV006003 for <[e-mail]>; Thu, 27 Nov 2008 04:03:50 -0700 (MST) (envelope-from [e-mail])
X-RZG-CLASS-ID: mo00
X-RZG-AUTH: :IWUHfUGtd9+vE/nIU31usF8LLMefsb7t6jGFCjOtWWkYYor1wfCDrbylGgNY45c=
Received: from [10.1.1.5] (p54A35820.dip.t-dialin.net [84.163.88.32]) by post.strato.de (mrclete mo19) (RZmta 17.20) with DHE-RSA-AES128-SHA encrypted ESMTP id C01238kARAv00S ; Thu, 27 Nov 2008 12:03:38 +0100 (MET)
Message-ID: <[e-mail]>
Date: Thu, 27 Nov 2008 12:03:37 +0100
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.18) Gecko/20081030 SeaMonkey/1.1.13
MIME-Version: 1.0
To: Santosh Chokhani <[e-mail]>
CC: [e-mail]
Subject: Re: encoding an X.509 certificate
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: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Santosh Chokhani wrote:
> 
> The question remains what it does to interoperability and performance
> since I suspect you are not the sole provider of PK enablement
> software to the world.

I think the work-arounds added to some software can even lead to 
security problems since the issues are also with the certs' structure 
(not only the encoding).
As an extreme example: I remember discussions on another mailing list 
where a developer even argued to ignore the SEQUENCE's order of subject 
and issuer names. (I guess Peter Sylvester will also remember this 
strange discussion since he raised the issue with wrong name ordering on 
this mailing list.)

Ciao, Michael.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAR2h6Om076327 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Nov 2008 19:43:06 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAR2h63F076326; Wed, 26 Nov 2008 19:43:06 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mAR2gtLI076318 for <[e-mail]>; Wed, 26 Nov 2008 19:43:05 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 959 invoked from network); 27 Nov 2008 02:42:40 -0000
Received: from [e-mail] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;27 Nov 2008 02:42:40 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 27 Nov 2008 02:42:40 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: encoding an X.509 certificate
Date: Wed, 26 Nov 2008 21:42:53 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: encoding an X.509 certificate
thread-index: AclQILwnR2QVSZT/SD+yib4MOQPNDwAGPpUg
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Santosh Chokhani" <[e-mail]>
To: =?iso-8859-1?Q?Michael_Str=F6der?= <[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>

Michael,

The question remains what it does to interoperability and performance =
since I suspect you are not the sole provider of PK enablement software =
to the world.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] =
On Behalf Of Michael Str=F6der
Sent: Wednesday, November 26, 2008 6:23 PM
To: [e-mail]
Subject: Re: encoding an X.509 certificate


Santosh Chokhani wrote:
>=20
> What does that do to interoperability or performance since you get
> certificates from various sources who can encode them whichever way.

When implementing the cert viewer in web2ldap it took me quite a while=20
to believe how broken certs of major CAs are. So my development=20
performance was really bad. And yes, like all others I've added a=20
work-around...

Ciao, Michael.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAQNNWhL068709 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Nov 2008 16:23:32 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAQNNWvP068708; Wed, 26 Nov 2008 16:23:32 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mo-p00-ob.rzone.de (mo-p00-ob.rzone.de [81.169.146.161]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAQNNKFv068684 for <[e-mail]>; Wed, 26 Nov 2008 16:23:30 -0700 (MST) (envelope-from [e-mail])
X-RZG-CLASS-ID: mo00
X-RZG-AUTH: :IWUHfUGtd9+vE/nIU31usF8LLMefsb7t6jGFCjOtWWkYYor1wfCDrbylEgNa5Jc=
Received: from [10.1.1.5] (p54A3500F.dip.t-dialin.net [84.163.80.15]) by post.strato.de (mrclete mo42) (RZmta 17.20) with DHE-RSA-AES128-SHA encrypted ESMTP id J02065kAQLjavD for <[e-mail]>; Thu, 27 Nov 2008 00:23:18 +0100 (MET)
Message-ID: <[e-mail]>
Date: Thu, 27 Nov 2008 00:23:17 +0100
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.18) Gecko/20081030 SeaMonkey/1.1.13
MIME-Version: 1.0
To: [e-mail]
Subject: Re: encoding an X.509 certificate
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Santosh Chokhani wrote:
> 
> What does that do to interoperability or performance since you get
> certificates from various sources who can encode them whichever way.

When implementing the cert viewer in web2ldap it took me quite a while 
to believe how broken certs of major CAs are. So my development 
performance was really bad. And yes, like all others I've added a 
work-around...

Ciao, Michael.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAPIpAuE075525 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Nov 2008 11:51:10 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAPIpAqf075524; Tue, 25 Nov 2008 11:51:10 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mX1.myoutlookonLine.com (mx1.myoutlookonline.com [69.25.74.54]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAPIoxCG075508 for <[e-mail]>; Tue, 25 Nov 2008 11:51:10 -0700 (MST) (envelope-from [e-mail])
Received: from be122.mail.lan ([10.109.208.122]) by mX1.myoutlookonLine.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 25 Nov 2008 13:50:47 -0500
Received: from mail pickup service by be122.mail.lan with Microsoft SMTPSVC; Tue, 25 Nov 2008 13:50:36 -0500
Received: from Mx1.myoutlookonlIne.com ([10.9.35.230]) by BE127.mail.lan with Microsoft SMTPSVC(6.0.3790.3959); Tue, 25 Nov 2008 13:43:03 -0500
Received: from mailout14.yourhostingaccount.com ([65.254.253.113]) by Mx1.myoutlookonlIne.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 25 Nov 2008 12:54:06 -0500
Received: from mailscan15.yourhostingaccount.com ([10.1.15.15] helo=mailscan15.yourhostingaccount.com) by mailout14.yourhostingaccount.com with esmtp (Exim) id 1L526v-0004oW-VW for [e-mail]; Tue, 25 Nov 2008 12:54:06 -0500
Received: from impinc05.yourhostingaccount.com ([10.1.13.105] helo=impinc05.yourhostingaccount.com) by mailscan15.yourhostingaccount.com with esmtp (Exim) id 1L526t-0005hY-BA for [e-mail]; Tue, 25 Nov 2008 12:54:03 -0500
Received: from balder-227.proper.com ([192.245.12.227]) by impinc05.yourhostingaccount.com with NO UCE id jVu21a00i4tvYcG03Vu2mf; Tue, 25 Nov 2008 12:54:03 -0500
X-EN-OrigIP: 192.245.12.227
X-EN-IMPSID: jVu21a00i4tvYcG03Vu2mf
Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAPHFxV7070208 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Nov 2008 10:15:59 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAPHFx0N070207; Tue, 25 Nov 2008 10:15:59 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAPHFxoe070201 for <[e-mail]>; Tue, 25 Nov 2008 10:15:59 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 30) id C0EA93A6939; Tue, 25 Nov 2008 09:16:00 -0800 (PST)
X-idtracker: yes
To: IETF-Announce <[e-mail]>
From: The IESG <[e-mail]>
Subject: Last Call: draft-ietf-pkix-ecc-subpubkeyinfo (Elliptic Curve  Cryptography Subject Public Key Information) to Proposed  Standard 
Reply-to: [e-mail]
CC: <[e-mail]>
Message-Id: <[e-mail]>
Date: Tue, 25 Nov 2008 09:16:00 -0800 (PST)
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: 25 Nov 2008 17:54:06.0801 (UTC) FILETIME=[CFA7EC10:01C94F26]
Sender: [e-mail]
Precedence: 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 (pkix) to consider the following document:

- 'Elliptic Curve Cryptography Subject Public Key Information '
   <draft-ietf-pkix-ecc-subpubkeyinfo-10.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 substantive comments to the
[e-mail] mailing lists by 2008-12-09. Exceptionally, 
comments may be sent to [e-mail] instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-pkix-ecc-subpubkeyinfo-10.txt


IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=16782&rfc_flag=0



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAPI04uh072434 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Nov 2008 11:00:04 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAPI04mk072433; Tue, 25 Nov 2008 11:00:04 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.ascertia.com (server5852.dedicated.webfusion.co.uk [81.21.74.134]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAPI02r5072425 for <[e-mail]>; Tue, 25 Nov 2008 11:00:03 -0700 (MST) (envelope-from [e-mail])
Received: from ASCUK001 ([87.201.190.214]) by ds5852.dedicated.turbodns.co.uk with MailEnable ESMTP; Tue, 25 Nov 2008 18:00:16 +0000
From: "Liaquat Khan" <[e-mail]>
To: "'Timothy J. Miller'" <[e-mail]>
Cc: "'Johannes Merkle'" <[e-mail]>, "'Mauricio Balassiano'" <[e-mail]>, <[e-mail]>
References: <052601c94e56$60120f00$[e-mail]> <[e-mail]> <BBE6D91086994FFD98961A6911B831BC@ASCUK001> <[e-mail]>
Subject: RE: OCSP Responder Status
Date: Tue, 25 Nov 2008 21:59:37 +0400
Message-ID: <93AADDD7597C4A01A5219930F5BA1D87@ASCUK001>
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <[e-mail]>
Thread-Index: AclPIkmo7MxujmQqTDeaNaFu8CaHMQAAUl2g
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_04E6_01C94F49.1B981B50"
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
X-ME-Bayesian: 0.000000
Sender: [e-mail]
Precedence: 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_04E6_01C94F49.1B981B50
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

See below

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Timothy J. Miller
Sent: 25 November 2008 21:18
To: Liaquat Khan
Cc: 'Johannes Merkle'; 'Mauricio Balassiano'; [e-mail]
Subject: Re: OCSP Responder Status

Liaquat Khan wrote:
> The problem with your option 3 is that RFC2560 doesn't explain how a
client
> can check that the second responder is acting on behalf of the first CA.
> I.e. it may chain to a trust anchor, allowing you to verify the signature
on
> the OCSP response, but how do you know that the original CA actually
> authorised this second responder to provide status information on the
first
> responder's certificate? 

That's what client configuration control is for.  :)  That's the whole 
point of the trusted responder model--trust in that responder is 
established out-of-band (i.e., not part of the OCSP protocol).

[LK:] :-) of course anything is possible with configuration but the
situation can become quite complex for even administrators to follow,
especially if multiple CAs are being handled.  E.g. our ARP-OCSP client
supports the capability to use AIA extension to locate responders and also
locally configured responder addresses, with the order of which method is to
be used being configurable.   There is also possibility to configure
separate trust anchor sets per CA etc, so that it can be controlled which
CAs trust which responders. Only issue is that generally speaking no one
really uses these advanced features and instead opts for simpler models
(CRLs or no-check).   


> If you are happy to live without this check then this can work, however I
> have not really seen this method actual used (probably because it
introduces
> more complexity than the benefit it offers).  

The DoD OCSP service uses the trusted responder model.  It's a real PITA 
to manage; you have to make sure all the RPs are properly configured. 
Key changing under this model is even worse; the hoops we had to jump 
through were seriously sick.

We're now migrating to the CA designated model.  The CA-issued OCSP 
signing certs will be short-lived certs with longer-lived keys (IIRC, 30 
day cert life with renewal allowed for some period of time).

[LK:] OK sounds interesting, so responder cert will have "no-check" option
and lifetime of 30 days.  Sounds like quite a long lifetime for a
certificate which is supposed to be short-lived :-). 
  
-- Tim

------=_NextPart_000_04E6_01C94F49.1B981B50
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKsTCCA2Yw
ggJOoAMCAQICAgCiMA0GCSqGSIb3DQEBBQUAMDsxCzAJBgNVBAYTAkdCMREwDwYDVQQKEwhBc2Nl
cnRpYTEZMBcGA1UEAxMQQXNjZXJ0aWEgUm9vdCBDQTAeFw0wNzA4MjkxMTMyNDFaFw0xMjA3MzAx
NDAwMDBaMD8xCzAJBgNVBAYTAkdCMREwDwYDVQQKEwhBc2NlcnRpYTEdMBsGA1UEAxMUQXNjZXJ0
aWEgSW50ZXJuYWwgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALuLrYfKGZYthbhiDOuw
MAnoE5tOiOWRRg4M8V/EVy40jznn4rv7uxD7a0QFGu3FpDSB5sF+scoFnPRQOTxzl356ZJi1buOy
Uyh/5CuPA/rwhi9rdpCISxR6yRyHZZ/XflR/Yv7dF5MXVJey/JVOx5v79PUV5cQPiLRbB82V42Nl
AgMBAAGjgfMwgfAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFLet
N082zMwCpLTUC2CLHoP+PHSwME4GA1UdHwRHMEUwQ6BBoD+GPWh0dHA6Ly93d3cuYXNjZXJ0aWEu
Y29tL09ubGluZUNBL2NybHMvYXNjZXJ0aWFyb290Y2Evcm9vdC5jcmwwPQYIKwYBBQUHAQEEMTAv
MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC5nbG9iYWx0cnVzdGZpbmRlci5jb20wHwYDVR0jBBgw
FoAUsVNxoCj95wxTmh1rEDzuyBrNXs4wDQYJKoZIhvcNAQEFBQADggEBABPox5Vj8s+4lemtxQ3z
cj93BL232DlSIeOoo9gnO4Kkfk0aIw5dfEUrTOKE5BNbaRoivpbwLkTsLuSBYBUX75UbImLlVDHQ
yxw/iFSzMGvQJnzOAIEXt0ppZizrNadPxA7QlurT+aU6IEkVXk2dTBIsAQm7eYKcyvnF1GG8srHy
AOaUL2syBzih9yEtRC+PQa4FyouraGmF/xZKvtrRyqgla/95nJF+Adm9+zlcNh+Kesb9tovxTEoD
/QuyR8kdlxpCif8TmeJqZcU5yDT4gByn4bocrcwOIu7m5ohOoKwv0fhZ4XXLBPlco+pUZu4aFbUT
HeUnO28GZ3QS/Xq70UYwggNqMIICUqADAgECAgEBMA0GCSqGSIb3DQEBBQUAMDsxCzAJBgNVBAYT
AkdCMREwDwYDVQQKEwhBc2NlcnRpYTEZMBcGA1UEAxMQQXNjZXJ0aWEgUm9vdCBDQTAeFw0wMzAz
MDQwODA2MTJaFw0xMzAzMDQwODAxMjdaMDsxCzAJBgNVBAYTAkdCMREwDwYDVQQKEwhBc2NlcnRp
YTEZMBcGA1UEAxMQQXNjZXJ0aWEgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC
ggEBANH4095uJr+IYSU0bdAj1OVBJYT6/CGH03WnrTyG3HBfccbY9EQOi7yE/+vekiSQkSx+UbG3
dFVcr5S3sjIooHXuuGVRIaauppEvZ8DHIKwJu1qTq4uqHtp8Nh6wjWjMufixgwV4VYYJYqSQ0HMZ
8O8p5uNcDP3I3GEXIsZsH5lSQSx+NADcYngPNrgUBtZQf9D2Nal3xFT1bH0eL5BN9c5NppZOf5Ax
GD1Ba4/qmSVKwYDrmP1hagF34421IRQzRpfen+K55xKoL8iN9LFruFYKyRBH5vOqDfEwlNpHUmkJ
B2zpnU6olflHdQSHvUVrELZNMyAaE0OHBW6jESBI+GUCAwEAAaN5MHcwDgYDVR0PAQH/BAQDAgEG
MA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFLFTcaAo/ecMU5odaxA87sgazV7OMDUGCCsGAQUF
BwEBBCkwJzAlBggrBgEFBQcwAYYZd3d3Lmdsb2JhbHRydXN0ZmluZGVyLmNvbTANBgkqhkiG9w0B
AQUFAAOCAQEApGux/r8DwvMyoQUlwqXemrjV89cfuAMttrIZjG9EnXktEzDHLoDwDZKtjmtXy7w9
K0pwwYqP/VHirXNj+HZMfR4gcM3MhxeICd1kU0EhE+yRDWogoiVO079NgLV/6qyz2vt4pzBiT3Ra
F2R1nST+vbVnslAy0sa+A77YxzgsRvh/UuL9N0HczR0GrSdGsNfnCIzeGhFtiRaf7Ss20eXh9Wqn
kzRL0F5a53+M0iI+7Y5IUJ2JcOBhVg/no59Vge5RC5MZ+xE/wQje5QTlEWog8GP5XH8PDO38uc1H
YJ8q/oc9LkCy0plavTiT9Eqx6sgGYku7GiGB+dS4tYmi8sU8mTCCA9UwggM+oAMCAQICAgCtMA0G
CSqGSIb3DQEBBQUAMD8xCzAJBgNVBAYTAkdCMREwDwYDVQQKEwhBc2NlcnRpYTEdMBsGA1UEAxMU
QXNjZXJ0aWEgSW50ZXJuYWwgQ0EwHhcNMDcxMDA1MDQ1NDI2WhcNMDkxMjMwMTkwMDMyWjBLMQsw
CQYDVQQGEwJHQjERMA8GA1UEChMIQXNjZXJ0aWExEjAQBgNVBAsTCVNvbHV0aW9uczEVMBMGA1UE
AxMMTGlhcXVhdCBLaGFuMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCuNACF79rxizV0A8rf
iliq+uzHFbtD6aWjUpHnIYJ6MY6n8eTRay7qJJQWZjKM4BISJ50dV48Dy/yM64okMuNe8WzJHfgv
rtMYsZgnoKDdUbgXuMw5PWSmsSwHX3AHowPCVT1GadFmfGymFHeKbj4t11OJATMBpzme7aj5GRnI
fQIDAQABo4IB0jCCAc4wDgYDVR0PAQH/BAQDAgP4MIGpBgNVHSAEgaEwgZ4wgZsGCisGAQQB/EkB
AgEwgYwwgYkGCCsGAQUFBwICMH0ae1RoaXMgY2VydGlmaWNhdGUgaXMgZm9yIHRoZSBzb2xlIHVz
ZSBvZiBBc2NlcnRpYSBhbmQgaXRzIGN1c3RvbWVycywgZm9yIGRlbW9uc3RyYXRpb24gcHVycG9z
ZXMgb25seS4gTk8gTElBQklMSVRZIEFDQ0VQVEVELjAdBgNVHQ4EFgQU80CQnhnZsE8dTSFzYDnk
xq//VDQwYAYDVR0fBFkwVzBVoFOgUYZPaHR0cDovL3d3dy5hc2NlcnRpYS5jb20vT25saW5lQ0Ev
Y3Jscy9Bc2NlcnRpYUludGVybmFsQ0EvQXNjZXJ0aWFJbnRlcm5hbENBLmNybDA9BggrBgEFBQcB
AQQxMC8wLQYIKwYBBQUHMAGGIWh0dHA6Ly9vY3NwLmdsb2JhbHRydXN0ZmluZGVyLmNvbTAJBgNV
HRMEAjAAMCQGA1UdEQQdMBuBGWxpYXF1YXQua2hhbkBhc2NlcnRpYS5jb20wHwYDVR0jBBgwFoAU
t603TzbMzAKktNQLYIseg/48dLAwDQYJKoZIhvcNAQEFBQADgYEAdrM7H1Rg7TMcInb9vpmEwM7N
aSatawqAPk+PSTZm4vLyaMC0pTSYCrL7Ifb6Az6eSn4cfOnKXOtHIDTzVdRpuxnQUEz/28pRRMDv
qzIe7OkBZySqtmchDI6gzAfhbnGNXR8IxnPu2GKZlIAIf4DV4y7re5oWhnAexwuoOvNsGpwxggJj
MIICXwIBATBFMD8xCzAJBgNVBAYTAkdCMREwDwYDVQQKEwhBc2NlcnRpYTEdMBsGA1UEAxMUQXNj
ZXJ0aWEgSW50ZXJuYWwgQ0ECAgCtMAkGBSsOAwIaBQCgggF0MBgGCSqGSIb3DQEJAzELBgkqhkiG
9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA4MTEyNTE3NTkzN1owIwYJKoZIhvcNAQkEMRYEFFFK1CSl
3hTVQwLU2H7zik98lNaUMFQGCSsGAQQBgjcQBDFHMEUwPzELMAkGA1UEBhMCR0IxETAPBgNVBAoT
CEFzY2VydGlhMR0wGwYDVQQDExRBc2NlcnRpYSBJbnRlcm5hbCBDQQICAK0wVgYLKoZIhvcNAQkQ
AgsxR6BFMD8xCzAJBgNVBAYTAkdCMREwDwYDVQQKEwhBc2NlcnRpYTEdMBsGA1UEAxMUQXNjZXJ0
aWEgSW50ZXJuYWwgQ0ECAgCtMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcN
AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoG
CCqGSIb3DQIFMA0GCSqGSIb3DQEBAQUABIGADu03VlLo4yCaIvuqqsK1TBMWaUpOYGJ8wBa5sKkq
vMfq6KgYHE8YTMczExStkqaeXb8WvNOPzal5tRvG4T0DU/TQ+LuCynkxUgYbKnoQHuIGMWtZin7+
YERNgtL6djVAZpcEuR09p9jSRWRQCcLIM8YBLIFb5l5Qp8NhnmdPO1EAAAAAAAA=

------=_NextPart_000_04E6_01C94F49.1B981B50--





Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAPHHx6N070267 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Nov 2008 10:17:59 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAPHHxAQ070266; Tue, 25 Nov 2008 10:17:59 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAPHHlMu070258 for <[e-mail]>; Tue, 25 Nov 2008 10:17:58 -0700 (MST) (envelope-from [e-mail])
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id mAPHHkhE003348 for <[e-mail]>; Tue, 25 Nov 2008 12:17:47 -0500
Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id mAPHHkf2003325; Tue, 25 Nov 2008 12:17:46 -0500
Received: from [129.83.200.7] (129.83.200.7) by imchub2.MITRE.ORG (129.83.29.74) with Microsoft SMTP Server (TLS) id 8.1.311.2; Tue, 25 Nov 2008 12:17:46 -0500
Message-ID: <[e-mail]>
Date: Tue, 25 Nov 2008 11:17:54 -0600
From: "Timothy J. Miller" <[e-mail]>
User-Agent: Thunderbird 2.0.0.18 (Windows/20081105)
MIME-Version: 1.0
To: Liaquat Khan <[e-mail]>
CC: "'Johannes Merkle'" <[e-mail]>, "'Mauricio Balassiano'" <[e-mail]>, [e-mail]
Subject: Re: OCSP Responder Status
References: <052601c94e56$60120f00$[e-mail]> <[e-mail]> <BBE6D91086994FFD98961A6911B831BC@ASCUK001>
In-Reply-To: <BBE6D91086994FFD98961A6911B831BC@ASCUK001>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010409010602090905080403"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

Liaquat Khan wrote:
> The problem with your option 3 is that RFC2560 doesn't explain how a client
> can check that the second responder is acting on behalf of the first CA.
> I.e. it may chain to a trust anchor, allowing you to verify the signature on
> the OCSP response, but how do you know that the original CA actually
> authorised this second responder to provide status information on the first
> responder's certificate? 

That's what client configuration control is for.  :)  That's the whole 
point of the trusted responder model--trust in that responder is 
established out-of-band (i.e., not part of the OCSP protocol).

> If you are happy to live without this check then this can work, however I
> have not really seen this method actual used (probably because it introduces
> more complexity than the benefit it offers).  

The DoD OCSP service uses the trusted responder model.  It's a real PITA 
to manage; you have to make sure all the RPs are properly configured. 
Key changing under this model is even worse; the hoops we had to jump 
through were seriously sick.

We're now migrating to the CA designated model.  The CA-issued OCSP 
signing certs will be short-lived certs with longer-lived keys (IIRC, 30 
day cert life with renewal allowed for some period of time).

-- Tim

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKvjCC
A2cwggJPoAMCAQICAh8FMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEe
MBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3Jh
dGlvbiBQcmltYXJ5IENBLTEwHhcNMDgwODIxMTUzMTI5WhcNMTAwMjEyMTUzMTI5WjBaMRIw
EAYDVQQKEwltaXRyZS5vcmcxDzANBgNVBAsTBnBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3Rt
aWxsZXIxGjAYBgNVBAMTEU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQCTxM+z5fDKvmBInGatv0DkVwuOxd69S2M2jho8QkOltYJK/4JUm9uK0UtQZkyI
bEjmCpmXLw17iMCgA0SjwuUfJxdF8ntTys8keyMjRdlKSwFnkgZl9tL7o060LBtZQYzI5ajr
W9k3N768G/k1bZS5UYiMGHU5+Ygl4IwVhmQv3wIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF
4DAdBgNVHQ4EFgQUSXARqmj5Bl2Lz7RLoUIkuOHl0MkwHwYDVR0jBBgwFoAUh7QPSI1iM0LB
LVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL3d3dy5taXRyZS5vcmcvdGVj
aC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1UdEQQVMBOBEXRtaWxsZXJAbWl0cmUu
b3JnMA0GCSqGSIb3DQEBBQUAA4IBAQAbA1PH/hed/rryO1f0yfTRJnD/vL1rFTduUut/irL7
FSXHGybuPHxydfyGPvJ4qj+T8hs1W0jTa2zQnaPR52tms3hefl76CNVP9vJoVmaM9svFX4DX
6eJh/4SAI81tAuBIK8gxsWd1Va/Bnnh1/wsZLc8w2jkojVqkT2AHPaHS3DBKX7QAWovXVSxY
QlqMIH4zvSNSVfpvpIf0MWJWRBPvgerVSbJsA4dz6ziKvXDWySTV9zwSuNjikNqL//nIKwjb
r3ZOfSUOxSuhW58an2Ha4TdORvG4dGJEsMzxbpTB+wt/s6tK6roONV4uiDtODBNVAG+XGofe
McsS0b7iXdxDMIIDZzCCAk+gAwIBAgICHwUwDQYJKoZIhvcNAQEFBQAwXTESMBAGA1UEChMJ
bWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAlBgNVBAMTHk1J
VFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMTAeFw0wODA4MjExNTMxMjlaFw0xMDAyMTIx
NTMxMjlaMFoxEjAQBgNVBAoTCW1pdHJlLm9yZzEPMA0GA1UECxMGcGVvcGxlMRcwFQYKCZIm
iZPyLGQBARMHdG1pbGxlcjEaMBgGA1UEAxMRTWlsbGVyIFRpbW90aHkgSi4wgZ8wDQYJKoZI
hvcNAQEBBQADgY0AMIGJAoGBAJPEz7Pl8Mq+YEicZq2/QORXC47F3r1LYzaOGjxCQ6W1gkr/
glSb24rRS1BmTIhsSOYKmZcvDXuIwKADRKPC5R8nF0Xye1PKzyR7IyNF2UpLAWeSBmX20vuj
TrQsG1lBjMjlqOtb2Tc3vrwb+TVtlLlRiIwYdTn5iCXgjBWGZC/fAgMBAAGjgbcwgbQwDgYD
VR0PAQH/BAQDAgXgMB0GA1UdDgQWBBRJcBGqaPkGXYvPtEuhQiS44eXQyTAfBgNVHSMEGDAW
gBSHtA9IjWIzQsEtURpIHsKeuwqxrTBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vd3d3Lm1p
dHJlLm9yZy90ZWNoL21paS9wa2kvY2ExX21pdHJlX29yZy5jcmwwHAYDVR0RBBUwE4ERdG1p
bGxlckBtaXRyZS5vcmcwDQYJKoZIhvcNAQEFBQADggEBABsDU8f+F53+uvI7V/TJ9NEmcP+8
vWsVN25S63+KsvsVJccbJu48fHJ1/IY+8niqP5PyGzVbSNNrbNCdo9Hna2azeF5+XvoI1U/2
8mhWZoz2y8VfgNfp4mH/hIAjzW0C4EgryDGxZ3VVr8GeeHX/CxktzzDaOSiNWqRPYAc9odLc
MEpftABai9dVLFhCWowgfjO9I1JV+m+kh/QxYlZEE++B6tVJsmwDh3PrOIq9cNbJJNX3PBK4
2OKQ2ov/+cgrCNuvdk59JQ7FK6FbnxqfYdrhN05G8bh0YkSwzPFulMH7C3+zq0rqug41Xi6I
O04ME1UAb5cah94xyxLRvuJd3EMwggPkMIICzKADAgECAgEFMA0GCSqGSIb3DQEBBQUAMFox
EjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MSQw
IgYDVQQDExtNSVRSRSBDb3Jwb3JhdGlvbiBSb290IENBLTEwHhcNMDYwNjAzMTcxMzIyWhcN
MTIwNjAzMTcxMzIyWjBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmlj
YXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0x
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyPB7Vl0QgqgQt0u8Q2duRs7eZUPn
hlflKPFPMXGG+iqGpImYs6nfbFPsn0q8FqklFsm/UEV2JJQ3c7Srwfrqe9CrCbVFh761OxZI
7fnUWiUasNP2ING19aAfrQ8IoJsAEtGzHeIacS+M5CN4C0yfUC6CpBZTc9ZldjLUatvJr407
K1i+7WnrRsMVKhICfgmiO/XiVR9YeXyzeRqFrLy6YtJCJuJd0QRfwKtKRpek5oU67Izr7ClH
DtPJs7UOTjMYBS2fTzztC+wwOTp6+A3ZbEymuQcAZRwmGkjVBe2R8MiX26R02Iigz+903ZAL
/6bpvx0DnkrlR2UFr1KBGfBqmQIDAQABo4GxMIGuMBIGA1UdEwEB/wQIMAYBAf8CAQIwDgYD
VR0PAQH/BAQDAgGGMB0GA1UdDgQWBBSHtA9IjWIzQsEtURpIHsKeuwqxrTAfBgNVHSMEGDAW
gBTHcFEA2E3+5AHUaJbFPZ+al/50LzBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vd3d3Lm1p
dHJlLm9yZy90ZWNoL21paS9wa2kvcm9vdGNhMV9taXRyZV9vcmcuY3JsMA0GCSqGSIb3DQEB
BQUAA4IBAQBNbm7rrins3SICPbteX9qSN1+RJClqix/pw3IAe7u60LK0V9jVZ9E2a+c0MZiS
ojdcwU5rXxI2OI2wwIf6wVBo76jIOc+IiQRlC+V8YatGmoibqP/8WDPzlud/WQAzkjrU2nuh
8KdyJG+n1kH/6772Lbra2CIk8mu8FypeaB5P2uIJzdE+PGo82ZiyU680ukiJ9yF6UmEXuciB
77tGQBRxMl6ePzIrArQnf48SmBhFD5XYLraueOiG7E+AzD99ig1M6WHcxWXtp3DIrVqE/DZr
146NJaCWqg9NoE14cmpEllnpWLtLnn5UBYJ+QCozmbe1SJXOOynZ0VxMnGdh7NqgMYICqDCC
AqQCAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1
dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTAJ
BgUrDgMCGgUAoIIBmzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0wODExMjUxNzE3NTRaMCMGCSqGSIb3DQEJBDEWBBSnEPKHBd1ZeQ5SSkCzLATScmEr3TBS
BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D
AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNV
BAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQD
Ex5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAh8FMHQGCyqGSIb3DQEJEAILMWWg
YzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0
eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTANBgkqhkiG
9w0BAQEFAASBgIAYYB+/Ah7gBffVjQy1Y6932NDe7QZo3I+70BN0M5rMV1yA4pcItn4DQjrk
qagTx5R93r7MJAE4Jb2NYDM6srmCgY+Vq0sMcL2i7ev2R8LS/4CbfRj/fuSNiE+FqpBUSaVS
/s4nhE/Hpdf/lW4CXJInx/eMadU3u0VJDlOc9iq0AAAAAAAA
--------------ms010409010602090905080403--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAPHFxV7070208 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Nov 2008 10:15:59 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAPHFx0N070207; Tue, 25 Nov 2008 10:15:59 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAPHFxoe070201 for <[e-mail]>; Tue, 25 Nov 2008 10:15:59 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 30) id C0EA93A6939; Tue, 25 Nov 2008 09:16:00 -0800 (PST)
X-idtracker: yes
To: IETF-Announce <[e-mail]>
From: The IESG <[e-mail]>
Subject: Last Call: draft-ietf-pkix-ecc-subpubkeyinfo (Elliptic Curve  Cryptography Subject Public Key Information) to Proposed  Standard 
Reply-to: [e-mail]
CC: <[e-mail]>
Message-Id: <[e-mail]>
Date: Tue, 25 Nov 2008 09:16:00 -0800 (PST)
Sender: [e-mail]
Precedence: 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 (pkix) to consider the following document:

- 'Elliptic Curve Cryptography Subject Public Key Information '
   <draft-ietf-pkix-ecc-subpubkeyinfo-10.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 substantive comments to the
[e-mail] mailing lists by 2008-12-09. Exceptionally, 
comments may be sent to [e-mail] instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-pkix-ecc-subpubkeyinfo-10.txt


IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=16782&rfc_flag=0



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAPFGJGM060025 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Nov 2008 08:16:19 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAPFGJcr060024; Tue, 25 Nov 2008 08:16:19 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.ascertia.com (server5852.dedicated.webfusion.co.uk [81.21.74.134]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAPFG7UU059992 for <[e-mail]>; Tue, 25 Nov 2008 08:16:18 -0700 (MST) (envelope-from [e-mail])
Received: from ASCUK001 ([87.201.190.214]) by ds5852.dedicated.turbodns.co.uk with MailEnable ESMTP; Tue, 25 Nov 2008 15:16:20 +0000
From: "Liaquat Khan" <[e-mail]>
To: "'Johannes Merkle'" <[e-mail]>, "'Mauricio Balassiano'" <[e-mail]>
Cc: <[e-mail]>
References: <052601c94e56$60120f00$[e-mail]> <[e-mail]>
Subject: RE: OCSP Responder Status
Date: Tue, 25 Nov 2008 19:15:45 +0400
Message-ID: <BBE6D91086994FFD98961A6911B831BC@ASCUK001>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <[e-mail]>
Thread-Index: AclPBUPvdSsjaj0uT5ideaps6Hk2FwACe26Q
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
X-ME-Bayesian: 0.000000
Sender: [e-mail]
Precedence: 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 problem with your option 3 is that RFC2560 doesn't explain how a client
can check that the second responder is acting on behalf of the first CA.
I.e. it may chain to a trust anchor, allowing you to verify the signature on
the OCSP response, but how do you know that the original CA actually
authorised this second responder to provide status information on the first
responder's certificate? 

If you are happy to live without this check then this can work, however I
have not really seen this method actual used (probably because it introduces
more complexity than the benefit it offers).  

The main method I have seen is the use of CRLs (e.g. Adobe CDS certificates
generally use this to verify the OCSP responder certificate status, or use
the no-check option). 

The other approach I have seen is the IdenTrust one with OCSP responder
hierarchies, but this is one where even the first responder is not certified
by the CA for which it responds, so doesn't apply to scenario described in
the original email. 

Regards,
LK


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Johannes Merkle
Sent: 25 November 2008 17:47
To: Mauricio Balassiano
Cc: [e-mail]
Subject: Re: OCSP Responder Status


Mauricio,

> Which other way, other than CRL, could a OCSP Responder certificate be
> checked considering that OCSP No Check extension is not an option ?

An alternative could be another OCSP-Repsponder specified in the first OCSP
responders certificate. For establishing
trust in this second responder, there are the three option mentioned in RFC
2560:
- It uses the CA signing key to sign the OCSP responses (
- It's certificate has also been issued by the CA that issued the
certificate of the first responder. This only
transfers the problem to the second responder
- It's certificate has been issued by another CA, e.g. a root CA. In this
case, the clients must be locally configured
to trust the responders replies.

At the top level of this OCSP hierarchy you will face the problem that
unless you are willing to trust the top-level
responder's certificate without revocation checking (e.g. by using OCSP No
Check), or to use a CA key to sign the
top-level OCSP responses, you must switch to CRLs. I agree that this in not
satisfactory in many circumstances.

For CRLs you'll face a similar problem at the top of the "CRL hierarchy": RP
have to trust the top level CRL signer
without revocation checking. But if you are not willing to issue directs
CRLs (e.g. because the root CA is operated
offline and you wish to avoid daily access to it) then your top level CRL
signer will constitute a kind of second trust
anchor, at least with respect to revocation status checking.

Johannes

--
Johannes Merkle
secunet Security Networks AG
www.secunet.com







Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAPFC6pL059456 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Nov 2008 08:12:06 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAPFC6cG059455; Tue, 25 Nov 2008 08:12:06 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mAPFBsk9059414 for <[e-mail]>; Tue, 25 Nov 2008 08:12:05 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 18714 invoked from network); 25 Nov 2008 15:11:42 -0000
Received: from [e-mail] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;25 Nov 2008 15:11:42 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 25 Nov 2008 15:11:42 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-class: urn:content-classes:message
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: OCSP Responder Status
Date: Tue, 25 Nov 2008 10:11:53 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: OCSP Responder Status
thread-index: AclPBqY7IeyOmzMVTc2LHrGKeuMAxgACT9WA
References: <052601c94e56$60120f00$[e-mail]> <[e-mail]>
From: "Santosh Chokhani" <[e-mail]>
To: "Johannes Merkle" <[e-mail]>, "Mauricio Balassiano" <[e-mail]>
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>

You have to careful regarding the third option of trust: "- It's
certificate has been issued by another CA, e.g. a root CA. In this case,
the clients must be locally configured to trust the responders replies."

Some of the widely deployed OCSP clients interpret the local policy
option in RFC 2560 to simply mean explicitly trusted Responder.  Thus,
Responder certificate signed by Root will not work for checking the
status of certificates issued by some other CA.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Johannes Merkle
Sent: Tuesday, November 25, 2008 8:47 AM
To: Mauricio Balassiano
Cc: [e-mail]
Subject: Re: OCSP Responder Status


Mauricio,

> Which other way, other than CRL, could a OCSP Responder certificate be
> checked considering that OCSP No Check extension is not an option ?

An alternative could be another OCSP-Repsponder specified in the first
OCSP responders certificate. For establishing
trust in this second responder, there are the three option mentioned in
RFC 2560:
- It uses the CA signing key to sign the OCSP responses (
- It's certificate has also been issued by the CA that issued the
certificate of the first responder. This only
transfers the problem to the second responder
- It's certificate has been issued by another CA, e.g. a root CA. In
this case, the clients must be locally configured
to trust the responders replies.

At the top level of this OCSP hierarchy you will face the problem that
unless you are willing to trust the top-level
responder's certificate without revocation checking (e.g. by using OCSP
No Check), or to use a CA key to sign the
top-level OCSP responses, you must switch to CRLs. I agree that this in
not satisfactory in many circumstances.

For CRLs you'll face a similar problem at the top of the "CRL
hierarchy": RP have to trust the top level CRL signer
without revocation checking. But if you are not willing to issue directs
CRLs (e.g. because the root CA is operated
offline and you wish to avoid daily access to it) then your top level
CRL signer will constitute a kind of second trust
anchor, at least with respect to revocation status checking.

Johannes

--
Johannes Merkle
secunet Security Networks AG
www.secunet.com



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAPDlOZn049339 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Nov 2008 06:47:24 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAPDlNHM049338; Tue, 25 Nov 2008 06:47:23 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from a.mx.secunet.com (a.mx.secunet.com [213.68.205.161]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAPDlCIg049299 for <[e-mail]>; Tue, 25 Nov 2008 06:47:23 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (alg3 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 4788620C0AF; Tue, 25 Nov 2008 14:47:10 +0100 (CET)
X-Virus-Scanned: by secunet
Received: from mail-srv1.secumail.de (unknown [10.53.40.200]) by a.mx.secunet.com (Postfix) with ESMTP id ECA3720C0A4; Tue, 25 Nov 2008 14:47:09 +0100 (CET)
Received: from [10.208.1.240] ([10.208.1.240]) by mail-srv1.secumail.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 25 Nov 2008 14:47:09 +0100
Message-ID: <[e-mail]>
Date: Tue, 25 Nov 2008 14:47:08 +0100
From: Johannes Merkle <[e-mail]>
User-Agent: Thunderbird 2.0.0.18 (Windows/20081105)
MIME-Version: 1.0
To: Mauricio Balassiano <[e-mail]>
CC: [e-mail]
Subject: Re: OCSP Responder Status
References: <052601c94e56$60120f00$[e-mail]>
In-Reply-To: <052601c94e56$60120f00$[e-mail]>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 25 Nov 2008 13:47:10.0015 (UTC) FILETIME=[5029CCF0:01C94F04]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Mauricio,

> Which other way, other than CRL, could a OCSP Responder certificate be
> checked considering that OCSP No Check extension is not an option ?

An alternative could be another OCSP-Repsponder specified in the first OCSP responders certificate. For establishing
trust in this second responder, there are the three option mentioned in RFC 2560:
- It uses the CA signing key to sign the OCSP responses (
- It's certificate has also been issued by the CA that issued the certificate of the first responder. This only
transfers the problem to the second responder
- It's certificate has been issued by another CA, e.g. a root CA. In this case, the clients must be locally configured
to trust the responders replies.

At the top level of this OCSP hierarchy you will face the problem that unless you are willing to trust the top-level
responder's certificate without revocation checking (e.g. by using OCSP No Check), or to use a CA key to sign the
top-level OCSP responses, you must switch to CRLs. I agree that this in not satisfactory in many circumstances.

For CRLs you'll face a similar problem at the top of the "CRL hierarchy": RP have to trust the top level CRL signer
without revocation checking. But if you are not willing to issue directs CRLs (e.g. because the root CA is operated
offline and you wish to avoid daily access to it) then your top level CRL signer will constitute a kind of second trust
anchor, at least with respect to revocation status checking.

Johannes

--
Johannes Merkle
secunet Security Networks AG
www.secunet.com



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAOM0ATT086919 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 Nov 2008 15:00:10 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAOM0Asj086918; Mon, 24 Nov 2008 15:00:10 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAOM00D8086855 for <[e-mail]>; Mon, 24 Nov 2008 15:00:10 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id 7BC8F3A69F9; Mon, 24 Nov 2008 14:00:01 -0800 (PST)
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-ecc-subpubkeyinfo-10.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Mon, 24 Nov 2008 14:00:01 -0800 (PST)
Sender: [e-mail]
Precedence: 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		: Elliptic Curve Cryptography Subject Public Key Information
	Author(s)	: S. Turner, K. Yiu, D. Brown, R. Housley, W. Polk
	Filename	: draft-ietf-pkix-ecc-subpubkeyinfo-10.txt
	Pages		: 22
	Date		: 2008-11-24
	
This document specifies the syntax and semantics for the Subject 
   Public Key Information field in certificates that support Elliptic 
   Curve Cryptography.  This document updates Sections 2.3.5, 5, and the 
   ASN.1 module of RFC 3279.

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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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: Message/External-body;
	name="draft-ietf-pkix-ecc-subpubkeyinfo-10.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--NextPart--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAOH2R58053049 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 Nov 2008 10:02:27 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAOH2RlC053048; Mon, 24 Nov 2008 10:02:27 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-01.mandic.com.br (smtp-01.mandic.com.br [200.225.81.132]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAOH2CoX053032 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 24 Nov 2008 10:02:25 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 23556 invoked from network); 24 Nov 2008 17:02:07 -0000
Received: from caveiras.certisign.com.br (HELO NBCPTSC199) (18bKz8nE3dDI2NqOyM3Wp5qTmpehZphvbS5icg==@[200.219.129.102]) (envelope-sender <[e-mail]>) by smtp-01.mandic.com.br (qmail-ldap-1.03) with SMTP for <[e-mail]>; 24 Nov 2008 17:02:07 -0000
From: "Mauricio Balassiano" <[e-mail]>
To: <[e-mail]>
Subject: OCSP Responder Status
Date: Mon, 24 Nov 2008 15:02:03 -0200
MIME-Version: 1.0
Message-ID: <052601c94e56$60120f00$[e-mail]>
X-Mailer: Microsoft Office Outlook 11
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_051E_01C94E45.9BC3CC20"
thread-index: AclOVl9HjWBnqOi2RoyDpK5idp3fyA==
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
Sender: [e-mail]
Precedence: 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_051E_01C94E45.9BC3CC20
Content-Type: multipart/related;
	boundary="----=_NextPart_001_051F_01C94E45.9BC3CC20"


------=_NextPart_001_051F_01C94E45.9BC3CC20
Content-Type: multipart/alternative;
	boundary="----=_NextPart_002_0520_01C94E45.9BC3CC20"


------=_NextPart_002_0520_01C94E45.9BC3CC20
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,

=20

In a model where the OCSP Responder certificate is issued by the same CA =
who
issues the end entity certificates, isn=92t it a disadvantage to use the =
OCSP
service when CRL is used for checking the validity status of the OCSP
Responder certificate ?
=20
The OCSP RFC says that a CA may specify how the responder's certificate =
be
checked for revocation. This can be done using CRL Distribution Points =
if
the check should be done using CRLs or CRL Distribution Points, or =
Authority
Information Access if the check should be done in some other way.

=20

Which other way, other than CRL, could a OCSP Responder certificate be
checked considering that OCSP No Check extension is not an option ?=20

=20

Thanks,

  _____ =20

 <http://www.certisign.com.br>  <http://www.certisign.com.br/> CERTISIGN
<http://www.certisign.com.br> Mauricio Schueftan Balassiano
Departamento de Normas e Ger=EAncia de PKI
(21) 4501 1850

Certisign Certificadora Digital
certisign.com.br <http://www.certisign.com.br>=20

=20


------=_NextPart_002_0520_01C94E45.9BC3CC20
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Batang;
	panose-1:2 3 6 0 0 1 1 1 1 1;}
@font-face
	{font-family:Verdana;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:"\@Batang";
	panose-1:2 3 6 0 0 1 1 1 1 1;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
pre
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
span.EstiloDeEmail17
	{mso-style-type:personal-compose;
	font-family:Verdana;
	color:windowtext;
	font-weight:normal;
	font-style:normal;
	text-decoration:none none;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:70.85pt 3.0cm 70.85pt 3.0cm;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1027" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DPT-BR link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DVerdana><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Verdana'>Hi,<o:p></o:p></span></font></p>

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

<pre><font size=3D2 face=3DVerdana><span lang=3DEN-US =
style=3D'font-size:10.0pt;
font-family:Verdana'>In a model where the OCSP Responder certificate is =
issued by the same CA who issues the end entity certificates, =
isn&#8217;t it a disadvantage to use the OCSP service when CRL is used =
for checking the validity status of the OCSP Responder certificate =
?<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3DVerdana><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:Verdana'><o:p>&nbsp;</o:p></span></=
font></pre><pre><font
size=3D2 face=3DVerdana><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:Verdana'>The OCSP RFC says that a =
CA may specify how the responder's certificate be checked for =
revocation. This can be done using CRL Distribution Points if the check =
should be done using CRLs or CRL Distribution Points, or Authority =
Information Access if the check should be done in some other =
way.<o:p></o:p></span></font></pre>

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

<p class=3DMsoNormal><font size=3D2 face=3DVerdana><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Verdana'>Which other way, other than CRL, could a =
OCSP
Responder certificate be checked considering that OCSP No Check =
extension is
not an option ? </span></font><font size=3D2 face=3DVerdana><span =
lang=3DEN-US
style=3D'font-size:10.0pt;font-family:Verdana'><o:p></o:p></span></font><=
/p>

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

<p class=3DMsoNormal><font size=3D2 face=3DVerdana><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Verdana'>Thanks,<o:p></o:p></span></font></p>

<div class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'>

<hr size=3D1 width=3D"40%" noshade color=3D"#9d9da1" align=3Dleft>

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

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><a =
href=3D"http://www.certisign.com.br"></a></span></font><!--[if gte vml =
1]><v:shapetype=20
 id=3D"_x0000_t75" coordsize=3D"21600,21600" o:spt=3D"75" =
o:preferrelative=3D"t"=20
 path=3D"m@4@5l@4@11@9@11@9@5xe" filled=3D"f" stroked=3D"f">
 <v:stroke joinstyle=3D"miter" />
 <v:formulas>
  <v:f eqn=3D"if lineDrawn pixelLineWidth 0" />
  <v:f eqn=3D"sum @0 1 0" />
  <v:f eqn=3D"sum 0 0 @1" />
  <v:f eqn=3D"prod @2 1 2" />
  <v:f eqn=3D"prod @3 21600 pixelWidth" />
  <v:f eqn=3D"prod @3 21600 pixelHeight" />
  <v:f eqn=3D"sum @0 0 1" />
  <v:f eqn=3D"prod @6 1 2" />
  <v:f eqn=3D"prod @7 21600 pixelWidth" />
  <v:f eqn=3D"sum @8 21600 0" />
  <v:f eqn=3D"prod @7 21600 pixelHeight" />
  <v:f eqn=3D"sum @10 21600 0" />
 </v:formulas>
 <v:path o:extrusionok=3D"f" gradientshapeok=3D"t" =
o:connecttype=3D"rect" />
 <o:lock v:ext=3D"edit" aspectratio=3D"t" />
</v:shapetype><v:shape id=3D"Certisign" o:spid=3D"_x0000_s1026" =
type=3D"#_x0000_t75"=20
 alt=3D"CERTISIGN" href=3D"http://www.certisign.com.br/" =
style=3D'position:absolute;
 margin-left:0;margin-top:0;width:57.75pt;height:67.5pt;z-index:1;
 =
mso-wrap-distance-left:0;mso-wrap-distance-top:0;mso-wrap-distance-right:=
0;
 mso-wrap-distance-bottom:0;mso-position-horizontal:left;
 =
mso-position-horizontal-relative:text;mso-position-vertical-relative:line=
'=20
 o:allowoverlap=3D"f" o:button=3D"t">
 <v:imagedata src=3D"cid:image001.jpg@01C94E45.9BBA0820" =
o:href=3D"http://certisign.com.br/images/email/icone_90pxls.jpg" />
 <w:wrap type=3D"square"/>
</v:shape><![endif]--><![if !vml]><a =
href=3D"http://www.certisign.com.br/"><img
border=3D0 width=3D77 height=3D90 =
src=3D"cid:image001.jpg@01C94E45.9BBA0820"
align=3Dleft alt=3DCERTISIGN longDesc=3D"http://certisign.com.br" =
name=3DCertisign
v:shapes=3D"Certisign"></a><![endif]><a =
href=3D"http://www.certisign.com.br"></a><strong><b><font
size=3D1 face=3D"Times New Roman"><span =
style=3D'font-size:7.5pt'>Mauricio Schueftan
Balassiano</span></font></b></strong><font size=3D1 face=3DVerdana><span
style=3D'font-size:7.5pt;font-family:Verdana'><br>
Departamento de Normas e Ger=EAncia de PKI<br>
(21) 4501 1850<br>
<br>
Certisign Certificadora Digital<br>
<a =
href=3D"http://www.certisign.com.br">certisign.com.br</a></span></font><o=
:p></o:p></p>

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

</div>

</body>

</html>

------=_NextPart_002_0520_01C94E45.9BC3CC20--

------=_NextPart_001_051F_01C94E45.9BC3CC20
Content-Type: image/jpeg;
	name="image001.jpg"
Content-Transfer-Encoding: base64
Content-ID: <image001.jpg@01C94E45.9BBA0820>

/9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAARgAA/+4ADkFkb2JlAGTAAAAAAf/b
AIQABAMDAwMDBAMDBAYEAwQGBwUEBAUHCAYGBwYGCAoICQkJCQgKCgwMDAwMCgwMDQ0MDBERERER
FBQUFBQUFBQUFAEEBQUIBwgPCgoPFA4ODhQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQU
FBQUFBQUFBQUFBQUFBQUFBQU/8AAEQgAWgBNAwERAAIRAQMRAf/EAKcAAQADAQEBAAAAAAAAAAAA
AAAGBwgFBAMBAQEBAQEBAQEAAAAAAAAAAAAGBQQDBwIBEAABBAEDAwMBBgMIAwAAAAABAgMEBQYA
ERIhEwcxQRQiUWEyQlIVcYEjoWKiM0NTY3M0JRYRAAECBAQDBAYHBwMFAAAAAAECAwARBAUhMUES
YSIGUXEyE4GRQlJiFPCh0YKSMxWxweFyI0MH8cI0stKDJCX/2gAMAwEAAhEDEQA/AN/aQhpCGkIa
Qji5NlVNiNf+43LxQhau2wy2nm885sTwbSPU7D1OwHuRrPr7gzRt+Y6cNBqe76SjRoLe9WubGhjq
dAO0/SfZEWxfzNhuVWppozjsSeXOwhMkslJf9Q0VMuOBDh26JXx39BudZtNfWXVoQtDjXmibZcTt
Cx2pOR78jkDMx31NkdbQtaFodDZkvYrcUH4hIEcezWLD1RRPw0hDSENIQ0hDSENIQ0hGefMVz3cz
kl0dyFi9TJnrYX1QpcaI9YuDb++lppB18/rGU3K+sUi/BuQlQ4HnV60yEX1I4qgsT9S3+YQop9HI
n1EqMUhjGMDF36VMZSkz7jx5W5fYPJUrkq1ctgQ8dz0UG5IbG36R76+if5CV8zaVunxU9QNh90S2
EDgcD6B2RFdEEMXRDafA60rcNFTmUz7gmX3j2xumpnCzqoNkBxEyO1ICR6DuoC9v7dcdM95zSHPe
SD6xOP5UteU6pHuqI9RlHs10Rzw0hDSERLyLmJwrHjYsNpesZDgjQW3N+2HClSytYBBKUJSpRA9T
sNxvuMO9XP5Cn8wCaiZJ7+08AB+6N2yWz5+o2EySBNUs5ZSHEkjuzxlKKpEbyjcByWrJCw4gMfKX
MsTTRW35TIkojtBiM8XFoZWhbiuCEgq4pLhSsjLp7S84wh+srlslwTCUJGA4krbE+ABy7o0n7sy3
ULYpKJDqWzIqWozJ1IklZlxP8B8ZFj57xBBsERXsipWwHFvVUhi/BG4GxZdahy1evpHStWtFuy1Y
SFUlelz4XkbQfvhTgHpKe+OFd2pFqKamiLfxNLmR90hH7DEw8cedsczYNxJa2ok9bhjofbUr4y5C
ehaUHAlxh3fp2ngD7AknbX4aujrD4pa9o07xyn4F8UKxBB0kSNJzwj9P2ltxk1FE557Qz99P8yfr
0wxlLGIN5HrkWPkXJKWVIRDZvq6VWiY9/lMiwpVxUuLI32Qlf4j7Dqemp1p4U/Uzbipy3olLEmaA
kD14RvuNl7pxaUkAhCs8AJObsfR9kUz48yRWWUM7IZb8X95i01HgdVVMvh2QzXUqEzJUt1ISNm5E
kNJbVv8ArT148tXX+S6kUlCmmH99wrJIwwxkDlMYYentiQ/x+x8xXF84BlG0DXmknEZ9pB7x36Py
3zRj+A0LNbTyI0wVcVll+3dWTXtdpsABJQeT6yB+Bs/dy33TqWTdVzborej5l7akDbinAZz7AMzM
JTqrSN/9JTz1lcryGypRkfGZmeWnASKlaJxBin13/mnydXvZDDSmnwhKO85lGXSzT1BZCQQtuKzs
VNnccHVJUhXurVC10gpw/wD06pbiz/Zp8hwKpSJ7ZJ+8c4x3Op0NYW+nQhI/uO4k/XMcDuPFIyjj
eNrfLKxFrndfdCZjUaRGi47bIhKrGLiQjkuchlhRDjkRoJKC66PqVtx4rBCcvqu02+xNNO0QUy/u
kpJcKwpEp88znkeXDEz9kxqdNXCuvLzjNZJ1gpwO0JUhWABQQBqT4scB8QjbvePxvkcFb8O52/ze
m/H+OqPdy7paRKbebbPWIJ5fxidkeMtrrGVSZtY/8oRUDdbrRbW24lA91AK5Aep22HU6mOpaBdVS
/wBMblIO6WpEiCBx19EhjFN01Xopakhw7UrG2fYZggnhhLhOcVlV3WP5pSR8fyN5iHcx2W41fZS9
/hS24/IMJdWCFMvthS0ocB/MfxpUto49rvFHW0ooq4cvsqnIiQwKVHBKpDHdyqljjKNq52isoqo1
tAeY+JGeBxIUn2kTxEuZBx0meBOxjNcIsA6xU20RwE9qxpmHrBpYB9lVqHHFJ/74zW/6Nf1fRlYy
vzKJ9tY0mvyV9xCuQ+hahH4a6wpqhIbrWVJOvL5rfoI5x6UgxGc5avMwcj5NQ4dfr8oMqbYlWEOj
mxKq7r2xxW3Y/LajNpdbSP6bqOSj0QABxCPodBbn62hVR3gNhHsKDiFLQv30bCractwwSoEzEpgx
NwrWaKrRVWtSyfaSUqCZe6qeYOhkSO8JUPHSVkPOMfiZVmt62MUukGS1h9C+69bWaUrUhbVpPcDa
o7XNJS622N1jf6+SQNYizbek1KlOorZfmLlMTH9tMyEAz8aiVETzHLGyhNw6kCSZM0qSOUeHl7Th
vI0AG0TBkkgLjt3kTx1lSm52YY/+wyatgiNkmJOislwq2E2SlpbZBadbYaTwSpSd0oTslI98yx9a
VlQ8KRxoPh9UthAUCTjzJXhhiSqaQBirUx33jpOlpmjUtulktCe7GeGHKUAkFWQASToDEJxzxwi/
i1mYZNmdnRxHX12OE1k+uburH9oDh+LLmJUAwlx7YKSFNFKkp5DcHZN3W3u0dPuLZaZbQtwDzPKB
TMjTDEJGMhMY6TiLpLHdL0gOqcUtDZknzDPjqoT0mcZ4aSiXz6LAJL7FhlczJPJdmwrnFbzCeGqd
p/fcLbgxtuX2FtY4qHTUZWf5HCEFNI0EE6yCftJ+o8YrqPoJalBVQ7MDRM1fWcvxEcItbEfH1/lt
nDyDMmRCo4aUJr6jtCOksMkdphqMOjEdPEfSoclgdenUz1FbKq4v/M1s5TntOuOUtE9+KvTONqtu
lLbWDS0Ut0pTGQwlPd7SpZS5U6dkXpr6LHzmGkIr7MfElFk7ztjBWam3eJU+80gOMPqV6l1klIKj
+pKkqPvvqVufTjFWStP9NZzIyPeO3iJcZxVWzqN+kAQseYgZAmRT/Krs4GY7JRAm/HvlvGwmPQzy
uIkkobhTlNtDf/hkhKE/y31LCy3elwZXMdiVyH4VSEU6r1aarF5GPxImfxJxjmZIPLtDEYtb6ymR
mvkIbjlMttSe+AXG+43H2SUko68twfQ+uuOuN3pkh15akichzjPMTAw01jsof0moWW2UJUZEnlOW
RkVYzx0x1iu3o0WuzLKIcBkR6m4RX5rUxgQrtNXyVMzm9wB0RNZ+keiQo6sesAm4WmjuQ8Y/or7i
CpA+6QofeiS6WUqhudTbzkZrT3o2hSvvJUmQ7EiPnc10a6jUeNTiRW5TkEWst+JKVLpqxhy2ntAj
qO6GmE7j7Pv1/P8AHraGBV3BY/47XLwKgST6ky7iY/XXTynVU9Gn+4rcePMlCfwlRUOIEXN44wmJ
nQscyy6MXo895SIMNC3GWx29kqI7akng0EhhpPLYBB3B6bYtmtYuZXV1YKt5wEyO85zkPCnHQ4ZR
rXm5m2hFJSHb5YEzIegZSmfGrDUcYtinw/FqBQdp6iLFfHQSEtgvbH/kVuv/ABat6a2UtNi02lJ7
ZY+vOIipudVUiTrilDsnh6so7etKM6GkIaQhpCGkIo3zT5TxJuhnUaZCHWW1tLmWpWExY647qXSh
B2JdcPAp4t+m/ruOOoe71n6ifkKNCn3VkeHISM88v5lEhKZ4q0i3tNEbf/7tUoMtpBwV4lTSRlnx
AxUrROM4z5V2GTZ/lLysSbiUECuxaDWWN1lQcjMphvWrtlHkx20glRfJCWEqGy0pUem6dXqbLSUF
hbpLovAOb1eWseIT5N5GmStuM8EnWI1d1qa29qqbeg7thSncmcwUpBVIesTmMtwzA9OVYta0sGhv
IXk962agZBBh2ExFIiHFqU37LsBc5KXCS6nijsqSTxUFeytt/fpqos1U2/SUTH9NSDvTucJc0lNX
NiJ4pyjy6hprtTrZqax3nBklUkcoTJZnt5ZDPEY66xLcczfyH4eyOux7IpMa4obfuKo7SCv/ANXZ
pZVs60lKv/GlpO/JCehV0IX66k6i3N0lL+oWhanKZOLrCju2J1W2rPaPaB5k+IzAIFKxXGrf+Sua
Q2+cEPS2knCSVjAGeEspzCUymkq1jTW8G+q4lxWOd2DMbDrKvQgH1SoeykndKh7Eba16apRUNJcb
M0qEx9OGR4xh1NMundU04JKSZH6dhzHCPdrpjmhpCGkIaQjP3mny/Egw7GthzTDx6v3bubJrcvSX
iSkQ4wSQVFShwPHqtW43CErVqMqHKq81f6dQ/wDkXoEjxEnRAyOq1SQnPG0pWKa00wrq3M/lo1Jl
MYHNUsRPBCedXCraXEURZ0PI/IlfHl5e8lCsewqaQqrx+M7spEmzT0D0oo2cLR2S2n6lbbI47FXd
KawoFttSfMfcKQtz23FHBMyMkzPI2nADH4l59NQPXlSrhclbGEBRSnQJGKts+7mWrM4HIIR6sUXK
zZ+RkrqlrsfJ2RpnRXXAA6mhqAaqvWttICUlQ+U906bJB9NePXZm5SWtKtxRIrVL2lYFXZI8ysMo
9OjEFKKq4qG0SISO7ml3p5Wz2xIMoxGugXmQ+PMhdUzjWQRVV/z3AVFhmSpL0Gb1U2FKiyG08iTt
9K9SdrqVWC8hRPJOUz7isjM9h5VHvinuDAvdp5fHnL40+IS4jmCdeURXqZF1eYnmfjnJQqD5Ixpl
y7RGIWXEX+Pt/KamxtyN0ToyFhTg/EFpPopO/wBNo6VVpvoU2N1FXlRTqlK1Ca2laDUge0mQx2Kj
55VVSLjaJOHbU0cgrMKLWQWDmojATBwUd2AUmehPAWSIsYcyvRsiHNjw8hrGQSQhm0YQ642nf8qF
KT/NR1KWpr5CuqrfPlZcJR/Kcvq2+kmN67LNZRU1aRzuI2rl7yfor1Rc+quJWGkIaQivfK2XyqKs
YoqVSv8A6O7V2I3ZOzrTRIQpaduoWoqDbZ6fUeX5TqT6juaqZoNNz8xzASzA7RxOSeOIyir6dtqa
h0uu/lNYmeROcjwHiVwEtYzPjvYn2Qzvi2/QY9JerfH7K2ucedcxwETrtQc6LZiHZmH0I57HZKwo
nRrSnpW0imRL5uoxdVnIy8P8qAZcVEmRCsPCiSrqS5qqHP8Ajs+EZGRxH3lkblHCQkMCiR8duiZl
Fo3gdfNcYsL1p+Xkl0StxddQN/VYTXVjf+o8klhvl+JSyDtySdY/Q9uS15l4qvy2N3l7vbdlzK7T
sGvvmY8BjU6uuCnSi2U3jc27wn2UewjCQG45icto2mW8Renh+lauMhkZUzE+FQ0rLdVj8HclMdpp
lLLTSd1KP9GOAlX2rcUdcdlLlxr3a9ztO3vP2JzwzVHvevLt1C3QN5yBV3D/ALlZaySImvlDA1Zf
WIl1qEfv9eFfGSshKZDK+q2FKPQb7boKugV9gKtbF/tHzrW5AHmIy+Iap+yeE+yZMY9gu/yTpSv8
tefwnRX29o4gRny2gYplzcSHnrFxBv6Ft2vg5HQOoh3bUNaVtuV8oPgpW1s4tI5gqAJHTmsryLD1
q9bWyw+grSmUgRMgpOE0kiSk6Gc/2xuXzpFq4LDzKgkrzx5VA5lJAOCtRlx9mLQ8KV7b+QWFxVQz
Axitro9DVxioucGYyWW2mu4Sea0NsJLh3P1L16WZ9y4XJ+vUJBYl6eX9gTj3xz3tlugt7NEDNSTu
/wCrH0lRl2ynF4auohIaQgSACSdgPU6QjHvkzIrfL7WUcfd432WTWsUxJSuRDDcsKQ5KKdlKCGIv
efWU/gW6lXtqT6TaFzvDle7izSDcO/ENjHXBTneIsOpnP021t0KPzH/H3Yb58CSlqegjiZZd1OOs
11JicNcyOwhnH8IpGEgyJaGPobVshKOSn3FKkPLIB3X1OsZijqOqrq44SUMpxW5o23oBP2147Emc
szypjWeqWunLYhuQLysk+84cyZaJwCpZnLmVEgxfCbGvWvCYb6bTPMgfbk5tdBXKOH4vVEJnbYCJ
AB+r/cd6Dj0QNHqW5fPut2ugSEU7PKAMgE9vbLxKJmVK+KZVy2C3/ItLuVaoqdcE8c+bs7CvJIGC
UfDt26rx+jhY3TQ6SvBEWIjgFK6rWskqWtR/UtRKlfedVNHSopWUtIySP9T6TjEfWVa6p5Tq81H1
dgHADAR0tdcccca2xLGL15Mm4qIk2SkAB95lCnOI9AVbbkfcems+ot1NUK3ONpUe0jH1xoU9xqad
O1pxSR2AmUdOLEiwI7cSCw3GiNDi0wyhLbaB9iUpAAH8NdjbaW0hKAEgaDARxuOLcUVLJUTmTiY+
2vSPOGkIifkyxeq8Eu5Uc8XlsCMlQ6FPy3Ex+Q+8dzcawr8+WaB1QzlL8RCf3xuWJgPVzSVZTn+E
FX7oylbRsnqrvGrujxW2yNp6gtomPGrYW6wxkFnOMGQp91OwY4QGgkLXsOu/oFEdXStAio6eWwh1
LKn3D5ilYnywQnlGE1SSdvEw6krFs31Lq0KcSylG1Om6RVj8KirmkDkMI6WNYrY4naqddcTc+ZLV
JgvSYJ5xqNhYINfWn07/AB3+TJ/0xuAQeatYl6vbVO0m0WhJSgHmUPEpWpUrVZ9pWSBgJSARs2iz
uVLhul0IJlNKT4Up0w93HlTiVk67lFzSXjrx/Ewit5O8Hr2UlPzZKPwISnqlhncAhtP2nqs/Udui
U9llsyKBvHmcV4j/ALRwHrJxOgGZe7yuvcwwbT4R/uVxP1DAakzXVFE7DSENIQ0hDSENIRzb+liZ
FTTaSduI01otKWjotB9UrTv+ZKgFD7xrkrKVFSyppeSh/ofQcY66OqXTPJdRmkz/AIekYRSLfi/y
hVuP1NVYJRVSFkuvx5rsWO5uOPNbSQVpUUgBQTy+zcjXzYdP3NkltpckKOYWUg94zyzl9cfRzf7Y
6A44jnToUBRHAKyI7Jy7hFl4B46rcJil5RTLvXk8JE7jwShvfftMp3PBAI3Pus9T+UJs7PZW6BE/
E4c1fuHYPrJxOgEfeL25Xql4Wxknj7yjqfqAwGpM11QxOw0hDSENIQ0hDSENIQ0hDSENIQ0hDSEN
IQ0hDSENIQ0hH//Z

------=_NextPart_001_051F_01C94E45.9BC3CC20--

------=_NextPart_000_051E_01C94E45.9BC3CC20
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQaTCCAwMw
ggJsAhEAuS9gzIifoXpGCbhbcGyKrzANBgkqhkiG9w0BAQUFADCBwTELMAkGA1UEBhMCVVMxFzAV
BgNVBAoTDlZlcmlTaWduLCBJbmMuMTwwOgYDVQQLEzNDbGFzcyAyIFB1YmxpYyBQcmltYXJ5IENl
cnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzIxOjA4BgNVBAsTMShjKSAxOTk4IFZlcmlTaWduLCBJ
bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l
dHdvcmswHhcNOTgwNTE4MDAwMDAwWhcNMjgwODAxMjM1OTU5WjCBwTELMAkGA1UEBhMCVVMxFzAV
BgNVBAoTDlZlcmlTaWduLCBJbmMuMTwwOgYDVQQLEzNDbGFzcyAyIFB1YmxpYyBQcmltYXJ5IENl
cnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzIxOjA4BgNVBAsTMShjKSAxOTk4IFZlcmlTaWduLCBJ
bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l
dHdvcmswgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKeIASF0LOcaA/CY4Zc8DyEI8Zzbl+ma
/MIEBhO+X1LIzB4sElYsuAFpLMyZH62wlq55BPITOcF7mLoILOjChBMsqmnpCfTHqQKkQsIjT0rY
8A6i+zFsyeZvmScH9eb0THiebetGhvq5hslU8rLEr9RGHFrJFTD/DWz1LQ5tzn93AgMBAAEwDQYJ
KoZIhvcNAQEFBQADgYEAci75f9HxcfvEnvbFXlGKQJi4aPibHIPY4p29/+2h5mbqLwn0ytfqpSuV
9iRghk1ELoOlxC2g0654aW9y2myuCPBjkjfmu8QwF613zEk1qs/Yj9G+txiWR3NqVCI0ZC22FptZ
W7RRWTqzCxT0Et9noPStMmResUZyJ4wSe8VEtK4wggQbMIIDhKADAgECAhBPhas0wCSntCXsn+CH
L3dUMA0GCSqGSIb3DQEBBQUAMIHBMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIElu
Yy4xPDA6BgNVBAsTM0NsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3Jp
dHkgLSBHMjE6MDgGA1UECxMxKGMpIDE5OTggVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXpl
ZCB1c2Ugb25seTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazAeFw0wMDA0MTkwMDAw
MDBaFw0xNTA0MTgyMzU5NTlaMHAxLjAsBgNVBAoTJUNlcnRpc2lnbiBDZXJ0aWZpY2Fkb3JhIERp
Z2l0YWwgTHRkYS4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxHTAbBgNVBAMTFENl
cnRpc2lnbiBDbGFzcyAyIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC3GbF6QpvSK8T5
5cbxzHB/J6vmQqJu4BjtMWxjFCIeANsr332Qnl++9LnrVmg/tcNKgJZ2WeQWOlqpA/rd+h6a7INF
jXqTQ54OlzWnxLnhgdVid2ZT/Tel97r+3tDwabpCzqM7SnI+umtkknMXZkEQ0QMmBm4/P9dqJ6K8
b9v/dQIDAQABo4IBYjCCAV4wCwYDVR0PBAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wNAYDVR0fBC0w
KzApoCegJYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMi1nMi5jcmwwHQYDVR0OBBYEFHm9
46p2WD8IjEyzGtYSZHshyjhPMIHoBgNVHSMEgeAwgd2hgcekgcQwgcExCzAJBgNVBAYTAlVTMRcw
FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE8MDoGA1UECxMzQ2xhc3MgMiBQdWJsaWMgUHJpbWFyeSBD
ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEcyMTowOAYDVQQLEzEoYykgMTk5OCBWZXJpU2lnbiwg
SW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO
ZXR3b3JrghEAuS9gzIifoXpGCbhbcGyKrzANBgkqhkiG9w0BAQUFAAOBgQClUVzcrIl01SX9sQ+I
tgctn8wm1NjG1k/C/Qy09pIUgVTJcYryO20DjJsEnBEl/CiISsJfijZDVydP1kTroUh4kqd5RBa2
5BsZxsUydZLpV2Gm2R3RqNdh/VDs8ddU5Itb90Lf1lqfyh/xUvJvuKmSrk6EJpXCcJ+tmY1ABaVy
wTCCBEMwggOsoAMCAQICED21iMf302QEDHKjCHLPFjswDQYJKoZIhvcNAQEFBQAwcDEuMCwGA1UE
ChMlQ2VydGlzaWduIENlcnRpZmljYWRvcmEgRGlnaXRhbCBMdGRhLjEfMB0GA1UECxMWVmVyaVNp
Z24gVHJ1c3QgTmV0d29yazEdMBsGA1UEAxMUQ2VydGlzaWduIENsYXNzIDIgQ0EwHhcNMDMwNTMw
MDAwMDAwWhcNMTMwNTI5MjM1OTU5WjCB+TEtMCsGA1UEChMkQ2VydGlzaWduIENlcnRpZmljYWRv
cmEgRGlnaXRhbCBTLkEuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMT8wPQYDVQQL
EzZUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cuY2VydGlzaWduLmNvbS5ici9ycGEgKGMpMDMx
MDAuBgNVBAsTJ0NsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTE0MDIGA1UE
AxMrQ2VydGlTaWduIEF1dG9yaWRhZGUgQ2VydGlmaWNhZG9yYSBDbGFzc2UgMjCBnzANBgkqhkiG
9w0BAQEFAAOBjQAwgYkCgYEAqjHvZKRJ5aWPUaKkbFeJpYfIfryt7yLMA+ZXG3WPHwbJsZTfGJSb
FWcQGW0Jqjta2CpWa+nRULe2/snYp8+7K32AOyOhIBhXDBoTgZjZaFCAiElaefCtaoP6z7/3l0ev
AZuVd6JqBeaLfsnYQ+zS0wGm3Cyt2DYyGhfIY4AkatUCAwEAAaOCAVIwggFOMEgGA1UdIARBMD8w
PQYLYIZIAYb4RQEHFwIwLjAsBggrBgEFBQcCARYgaHR0cHM6Ly93d3cuY2VydGlzaWduLmNvbS5i
ci9ycGEwCwYDVR0PBAQDAgEGMBEGCWCGSAGG+EIBAQQEAwIBBjAqBgNVHREEIzAhpB8wHTEbMBkG
A1UEAxMSQ2VydGlzaWduQzFDMi0xLTExMBIGA1UdEwEB/wQIMAYBAf8CAQAwYgYDVR0fBFswWTBX
oFWgU4ZRaHR0cDovL29uc2l0ZWNybC5jZXJ0aXNpZ24uY29tLmJyL3JlcG9zaXRvcmlvL2xjci9D
ZXJ0aXNpZ25DbGFzczJDQS9MYXRlc3RDUkwuY3JsMB0GA1UdDgQWBBT4srQBIH+BQooPfGcuIT6j
vplx1TAfBgNVHSMEGDAWgBR5veOqdlg/CIxMsxrWEmR7Ico4TzANBgkqhkiG9w0BAQUFAAOBgQAH
qPAKK3YzHt+jIIbQRVTK25/2g08VEKsxcuuDV0fRb3q/7o4aT8cWYuKV9CsY2JlCTG1PorUUq3Dr
OPEeR8x5TDbflcufzO1JLsUfHzey6XVfUCSptlxGxHEeqi+2bNW/zEsVFL81w443PfzPSuGo8KQ+
cgxx5E02B7KQaCfXkjCCBPgwggRhoAMCAQICECQ0DjQVrawFTPMIoy5keE8wDQYJKoZIhvcNAQEF
BQAwgfkxLTArBgNVBAoTJENlcnRpc2lnbiBDZXJ0aWZpY2Fkb3JhIERpZ2l0YWwgUy5BLjEfMB0G
A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE/MD0GA1UECxM2VGVybXMgb2YgdXNlIGF0IGh0
dHBzOi8vd3d3LmNlcnRpc2lnbi5jb20uYnIvcnBhIChjKTAzMTAwLgYDVQQLEydDbGFzcyAyIE9u
U2l0ZSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ExNDAyBgNVBAMTK0NlcnRpU2lnbiBBdXRvcmlk
YWRlIENlcnRpZmljYWRvcmEgQ2xhc3NlIDIwHhcNMDgwNDI4MDAwMDAwWhcNMDkwNDI4MjM1OTU5
WjCB2DEtMCsGA1UEChQkQ2VydGlTaWduIENlcnRpZmljYWRvcmEgRGlnaXRhbCBTLkEuMSUwIwYD
VQQLFBxBdXRlbnRpY2FkbyBwb3IgQ2VydGlTaWduIFJIMSswKQYDVQQLFCJFLW1haWwgU2VndXJv
IENvcnBvcmF0aXZvIENsYXNzZSAyMSYwJAYDVQQDEx1NYXVyaWNpbyBTY2h1ZWZ0YW4gQmFsYXNz
aWFubzErMCkGCSqGSIb3DQEJARYcbWJhbGFzc2lhbm9AY2VydGlzaWduLmNvbS5icjCBnzANBgkq
hkiG9w0BAQEFAAOBjQAwgYkCgYEAxQoYmSe/nOcogGFVMyz429OwuKHOdmWjxHhV6BAWuaQPgLng
c4dToTEXXVMF20kgOYQ3V9WXgds374KLRfJ81t1Z5zDrODvpFwIt5I2SHNTApoJgGl835UQnPEH8
5vzWD+eLHwSA6bZIWwpaaShzwuyXaxW4YQrm+x9tFjjfeO8CAwEAAaOCAZ4wggGaMCQGA1UdEQQd
MBugGQYKKwYBBAGCNxQCA6ALDAkwMDAwQDAwMDAwCQYDVR0TBAIwADBnBgNVHR8EYDBeMFygWqBY
hlZodHRwOi8vb25zaXRlY3JsLmNlcnRpc2lnbi5jb20uYnIvQ2VydGlTaWduQ2VydGlmaWNhZG9y
YURpZ2l0YWxTQUNsYXNzZTIvTGF0ZXN0Q1JMLmNybDCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhF
AQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEF
BQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkg
cmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wKQYDVR0lBCIwIAYIKwYBBQUHAwQG
CCsGAQUFBwMCBgorBgEEAYI3FAICMBEGCWCGSAGG+EIBAQQEAwIHgDARBgpghkgBhvhFAQYJBAMB
Af8wDQYJKoZIhvcNAQEFBQADgYEAcnst3qf+8CV0Mt7eM4OiiO8G9TkIMlcjKr2c4+mR9ZSQgJl5
t6fwnuOHVubTpqJC5tLsjOe87Fv9DCPgBHWXnPVU/rSlBR91w3+gBkSZ1BxMlXIycmSXYzL/c5QD
zN6WrMRZfQYq2fr9Ixcw/ffgRUm6NAEUcNWIx1eqgocBC2QxggTMMIIEyAIBATCCAQ4wgfkxLTAr
BgNVBAoTJENlcnRpc2lnbiBDZXJ0aWZpY2Fkb3JhIERpZ2l0YWwgUy5BLjEfMB0GA1UECxMWVmVy
aVNpZ24gVHJ1c3QgTmV0d29yazE/MD0GA1UECxM2VGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3
LmNlcnRpc2lnbi5jb20uYnIvcnBhIChjKTAzMTAwLgYDVQQLEydDbGFzcyAyIE9uU2l0ZSBJbmRp
dmlkdWFsIFN1YnNjcmliZXIgQ0ExNDAyBgNVBAMTK0NlcnRpU2lnbiBBdXRvcmlkYWRlIENlcnRp
ZmljYWRvcmEgQ2xhc3NlIDICECQ0DjQVrawFTPMIoy5keE8wCQYFKw4DAhoFAKCCAxIwGAYJKoZI
hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDgxMTI0MTcwMjAyWjAjBgkqhkiG
9w0BCQQxFgQUGmwD2P+SWnBCA/s8Tu7X5riWlM0wZwYJKoZIhvcNAQkPMVowWDAKBggqhkiG9w0D
BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgw
BwYFKw4DAhowCgYIKoZIhvcNAgUwggEhBgkrBgEEAYI3EAQxggESMIIBDjCB+TEtMCsGA1UEChMk
Q2VydGlzaWduIENlcnRpZmljYWRvcmEgRGlnaXRhbCBTLkEuMR8wHQYDVQQLExZWZXJpU2lnbiBU
cnVzdCBOZXR3b3JrMT8wPQYDVQQLEzZUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cuY2VydGlz
aWduLmNvbS5ici9ycGEgKGMpMDMxMDAuBgNVBAsTJ0NsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwg
U3Vic2NyaWJlciBDQTE0MDIGA1UEAxMrQ2VydGlTaWduIEF1dG9yaWRhZGUgQ2VydGlmaWNhZG9y
YSBDbGFzc2UgMgIQJDQONBWtrAVM8wijLmR4TzCCASMGCyqGSIb3DQEJEAILMYIBEqCCAQ4wgfkx
LTArBgNVBAoTJENlcnRpc2lnbiBDZXJ0aWZpY2Fkb3JhIERpZ2l0YWwgUy5BLjEfMB0GA1UECxMW
VmVyaVNpZ24gVHJ1c3QgTmV0d29yazE/MD0GA1UECxM2VGVybXMgb2YgdXNlIGF0IGh0dHBzOi8v
d3d3LmNlcnRpc2lnbi5jb20uYnIvcnBhIChjKTAzMTAwLgYDVQQLEydDbGFzcyAyIE9uU2l0ZSBJ
bmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ExNDAyBgNVBAMTK0NlcnRpU2lnbiBBdXRvcmlkYWRlIENl
cnRpZmljYWRvcmEgQ2xhc3NlIDICECQ0DjQVrawFTPMIoy5keE8wDQYJKoZIhvcNAQEBBQAEgYBX
APDJpIq9BPk3YYn35T0yAlnbz8bq+/rZBgvAU0tY65wev8xKnOT/9T9gCQN9tT+paDk7Tv+Sgo4M
H+fWsveCmi8X4imR1texoxrSWNuHwG4vzuZaZORauBBdUe/9rGnW5ZyvZv90xk5WgRC9gwAQoICu
SOlBByX9wPu2HJEohwAAAAAAAA==

------=_NextPart_000_051E_01C94E45.9BC3CC20--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAN7IkCC056196 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 23 Nov 2008 00:18:46 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAN7Ikau056195; Sun, 23 Nov 2008 00:18:46 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAN7IWlr056188 for <[e-mail]>; Sun, 23 Nov 2008 00:18:43 -0700 (MST) (envelope-from [e-mail])
Received: from RnD-Test.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id mAN7ICQC006043; Sun, 23 Nov 2008 09:18:12 +0200 (IST)
Cc: [e-mail], [e-mail], [e-mail], [e-mail]
Message-Id: <[e-mail]>
From: Yoav Nir <[e-mail]>
To: Peter Gutmann <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v929.2)
Subject: Re: encoding an X.509 certificate
Date: Sun, 23 Nov 2008 08:51:31 +0200
References: <[e-mail]>
X-Mailer: Apple Mail (2.929.2)
Sender: [e-mail]
Precedence: 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 Nov 22, 2008, at 8:00 AM, Peter Gutmann wrote:

> So let's say you do set up a service mark, you certify things  
> against it, you
> can even make it a USG purchasing requirement that they only buy  
> certified
> products, and the same vendors that already craft their products to  
> fit that
> particular market keep doing so and everyone else ignores it and  
> nothing
> changes.

Oh, but we can make our firewalls inspect TLS handshakes, and drop all  
the ones where the certificate is not properly signed and properly DER.
Then buying at Amazon from work won't work.
Then everybody turns off the feature.
Or we go out of business.
Never mind.

But seriously, a few governments could make a difference, but they  
don't care that much either. It's perceived (and probably rightly so)  
as a problem of interoperability that the Windows people and the  
OpenSSL people have already solved for us.

> In my talk at the time I made the observation that I can't think of
> a big enough hammer to get this any traction, and the situation  
> hasn't got any
> better since.  For USB/HDMI/WUSB/whatever you've got industy  
> consortia that
> you have to sign up to and pay license fees to when you introduce a  
> new
> product so the old-school-tie process works (and even then for USB  
> only the
> minutest fraction of the vast, elephantine bulk that is the USB spec  
> is
> actually checked, and even that only barely, see the source code for  
> any USB
> driver for proof), but for PKI the universal acceptance check is "if  
> I click
> on this in Windows, will it get accepted without an error message?".

That's very 2004. Maybe even earlier. Now you need to be able to click  
this on Macs, Firefox, and Safari.  Seriously, at least for HTML this  
did make a difference. Websites today are much better written than  
they were at the time when 90% of browsing was done on IE.

> What's going to make this even worse is that if the certification  
> really does
> test compliance with some of the silly-walks required by the spec, a  
> certified
> product will be less interoperable than a non-certified one.  So you  
> end up
> trying to certify something that no-one cares about, and where  
> certification
> results in less interoperability than being non-certified.
>
> Yeah, that one'll really fly.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAM9Bleq010292 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 22 Nov 2008 02:11:47 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAM9Bloi010291; Sat, 22 Nov 2008 02:11:47 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mailhost.auckland.ac.nz (larry.its.auckland.ac.nz [130.216.12.34]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAM9BZFY010281 for <[e-mail]>; Sat, 22 Nov 2008 02:11:46 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 35FA21A1D7; Sat, 22 Nov 2008 22:11:35 +1300 (NZDT)
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (larry.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0DPxBl+5vfyd; Sat, 22 Nov 2008 22:11:35 +1300 (NZDT)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 17CD11A1B7; Sat, 22 Nov 2008 22:11:32 +1300 (NZDT)
Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id B059A1A2416A; Sat, 22 Nov 2008 22:11:32 +1300 (NZDT)
Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from <[e-mail]>) id 1L3oWa-0004Cr-J0; Sat, 22 Nov 2008 22:11:32 +1300
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: The EU Signature Directive - A 15+15 Year Perspective
Cc: [e-mail]
In-Reply-To: <3F7D87D9792849A28D560DC8341AC63F@AndersPC>
Message-Id: <[e-mail]>
Date: Sat, 22 Nov 2008 22:11:32 +1300
Sender: [e-mail]
Precedence: 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:

>This is sometimes referred to as the "hostage" PKI solution 

Ahh, I knew there must be some name for it :-).

>and must be one of the most flagrant examples of "pushing the envelope" ever
>heard of, 

>From talking to the person who'd had experience with this, and in particular
the totally unnatural business model it was creating, it certainly sounded
exactly like a hostage PKI.

Peter.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAM9893A009955 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 22 Nov 2008 02:08:09 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAM9894g009954; Sat, 22 Nov 2008 02:08:09 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.33]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAM97v6h009942 for <[e-mail]>; Sat, 22 Nov 2008 02:08:07 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id D5EEE9CEF9; Sat, 22 Nov 2008 22:07:55 +1300 (NZDT)
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lZTyP7ldIUTz; Sat, 22 Nov 2008 22:07:55 +1300 (NZDT)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 6B1F19CEF7; Sat, 22 Nov 2008 22:07:54 +1300 (NZDT)
Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 02A2A1A2416A; Sat, 22 Nov 2008 22:07:53 +1300 (NZDT)
Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from <[e-mail]>) id 1L3oT2-0003xm-SE; Sat, 22 Nov 2008 22:07:52 +1300
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: The EU Signature Directive - A 15+15 Year Perspective
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
Date: Sat, 22 Nov 2008 22:07:52 +1300
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Juergen Brauckmann <[e-mail]> writes:

>Actually there are several products and services that you can buy to automate
>qualified signature creation; google shows you some of them if you ask for
>"signature server".

>From talking to someone who's endured this in Germany, the only reason the
services exist is that you're paying them to bypass Anders' PKI-disabler for
you (either that or you exploit loopholes in the requirements, I can't
remember the precise details because they were pretty obscure but there are
tricks around using PDFs as electronic documents to meet the filing
requirements but having them in printed form to meet the archiving
requirements, and other odds and ends).

The system (without using the loopholes) required that not only do you need to
carry out a complex signing ritual but you have to verify cert chains and
CRLs, and then the certs expire so you need timestamping and secure archiving
of the fact that you've verified everything (when he described this to me I
had to keep stopping him to verify things because it sounded like a
description of a pathological torture test that someone had invented as sort
of obstacle course for businesses, but he claimed this wasn't a worst-case
scenario but something that everyone was expected to do).

So it's created a great business model in that you can outsource the pain to
companies that have sprung up to service the market, but first hobbling
businesses and then saying you have all these great new services that take the
hobbles away seems pretty counterproductive unless you happen to be in the
signature services racket.

Peter.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAM60LXQ004243 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Nov 2008 23:00:21 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAM60LIf004242; Fri, 21 Nov 2008 23:00:21 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.33]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAM609F0004224 for <[e-mail]>; Fri, 21 Nov 2008 23:00:20 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id D76039CBD3; Sat, 22 Nov 2008 19:00:08 +1300 (NZDT)
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5XnhLc-xOudt; Sat, 22 Nov 2008 19:00:08 +1300 (NZDT)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 819719CBD2; Sat, 22 Nov 2008 19:00:07 +1300 (NZDT)
Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id AF1A71A2416A; Sat, 22 Nov 2008 19:00:05 +1300 (NZDT)
Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from <[e-mail]>) id 1L3lXJ-0003Ki-I4; Sat, 22 Nov 2008 19:00:05 +1300
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: encoding an X.509 certificate
Cc: [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
Date: Sat, 22 Nov 2008 19:00:05 +1300
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Timothy J. Miller" <[e-mail]> writes:

>If it provided a service mark for use by a vendor?  Quite a bit.  Most of the
>major standards do this and it does work (mostly).

This is exactly what I proposed in my talk at the (then) PKI workshop several
years ago (and then shot down over dinner, since I ran out of time during my
talk to point out why this particular proposal was mostly a strawman :-).  The
problem is, to use David's example of e-cycling, that for something like that
you can show photos of 12-year-old kids boiling circuit boards in acid and the
public will be horrified and demand that something be done.  With
certificates, no-one cares (or at least no-one outside this list and maybe a
few procurement managers somewhere going down a checklist).

So let's say you do set up a service mark, you certify things against it, you
can even make it a USG purchasing requirement that they only buy certified
products, and the same vendors that already craft their products to fit that
particular market keep doing so and everyone else ignores it and nothing
changes.  In my talk at the time I made the observation that I can't think of
a big enough hammer to get this any traction, and the situation hasn't got any
better since.  For USB/HDMI/WUSB/whatever you've got industy consortia that
you have to sign up to and pay license fees to when you introduce a new
product so the old-school-tie process works (and even then for USB only the
minutest fraction of the vast, elephantine bulk that is the USB spec is
actually checked, and even that only barely, see the source code for any USB
driver for proof), but for PKI the universal acceptance check is "if I click
on this in Windows, will it get accepted without an error message?".

What's going to make this even worse is that if the certification really does
test compliance with some of the silly-walks required by the spec, a certified
product will be less interoperable than a non-certified one.  So you end up
trying to certify something that no-one cares about, and where certification
results in less interoperability than being non-certified.

Yeah, that one'll really fly.

Peter.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAM5gwU0003884 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Nov 2008 22:42:58 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAM5gwgs003883; Fri, 21 Nov 2008 22:42:58 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mailhost.auckland.ac.nz (moe.its.auckland.ac.nz [130.216.12.35]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAM5gjON003877 for <[e-mail]>; Fri, 21 Nov 2008 22:42:57 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id DB01848194C; Sat, 22 Nov 2008 18:42:44 +1300 (NZDT)
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (moe.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fa5cNqt-Wi6c; Sat, 22 Nov 2008 18:42:44 +1300 (NZDT)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id BEBF1481948; Sat, 22 Nov 2008 18:42:41 +1300 (NZDT)
Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id E5FA91A04001; Sat, 22 Nov 2008 18:42:37 +1300 (NZDT)
Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from <[e-mail]>) id 1L3lGP-0002bu-Pz; Sat, 22 Nov 2008 18:42:37 +1300
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: encoding an X.509 certificate
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
Date: Sat, 22 Nov 2008 18:42:37 +1300
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Julien Stern <[e-mail]> writes:

>Just recently, we encountered a certificate whose serial number was negative.
>The RFC very specifically states that serial numbers MUST be positive
>integers. Now, it is easy to decode such a certificate, and actually, most
>ASN.1 libraries will not even figure out that this number is negative unless
>someone has specified a constraint or if there is an explicit check on this
>number. So, should certificate validation fail?

Given the amount of software that has created these certs in the past
(including one from a vendor called Microsoft, you may have heard of them,
their products have a fair bit of market share), the answer is:

  Yes, if you want your product to fail in the marketplace.

Most parsers that I know of treat all ints as unsigned to deal with the number 
of implementations that forget there's a sign bit at the start when people use 
a MD5/SHA1 hash as a serial number or other such integer, and those that 
didn't initially get modified fairly quickly if they have any exposure to 
real-world certs.

Peter.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mALHJjHV079863 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Nov 2008 10:19:45 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mALHJi4A079862; Fri, 21 Nov 2008 10:19:44 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mALHJXLp079849 for <[e-mail]>; Fri, 21 Nov 2008 10:19:44 -0700 (MST) (envelope-from [e-mail])
Received: from dommiel.bbn.com ([192.1.122.15] helo=[130.129.78.165]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from <[e-mail]>) id 1L3ZfI-0007rT-Fs for [e-mail]; Fri, 21 Nov 2008 12:19:33 -0500
Mime-Version: 1.0
Message-Id: <p0624050ac54c9de33ab6@[130.129.78.165]>
Date: Fri, 21 Nov 2008 12:19:04 -0500
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: minutes posted
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>

Folks,

Meeting minutes fro yesterday have been posted. Please send 
corrections to me over the next two weeks.

Thanks,

Steve



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mALH8xuG079334 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Nov 2008 10:08:59 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mALH8xVv079333; Fri, 21 Nov 2008 10:08:59 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ganymede.on-x.com (ganymede.on-x.com [194.51.68.3]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mALH8mXe079324 for <[e-mail]>; Fri, 21 Nov 2008 10:08:58 -0700 (MST) (envelope-from [e-mail])
Received: from vinea.on-x.com (sedna.puteaux.on-x [192.168.10.9]) by ganymede.on-x.com (Postfix) with ESMTP id C42827C for <[e-mail]>; Fri, 21 Nov 2008 18:08:46 +0100 (CET)
Received: from [193.51.14.5] ([212.234.46.65]) by vinea.on-x.com (Lotus Domino Release 5.0.11) with ESMTP id 2008112118084589:229119 ; Fri, 21 Nov 2008 18:08:45 +0100 
Message-ID: <[e-mail]>
Date: Fri, 21 Nov 2008 18:04:24 +0100
From: Peter Sylvester <[e-mail]>
User-Agent: Thunderbird 1.5.0.9 (X11/20061206)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: The EU Signature Directive - A 15+15 Year Perspective
References: <1E0ECAB75B5B496F942BC7D49F9D7DA5@AndersPC> <[e-mail]> <3F7D87D9792849A28D560DC8341AC63F@AndersPC> <[e-mail]> <C515607EF9594962B192C59A8D711456@AndersPC> <[e-mail]> <E99AF3B38BBE4AADB8055166E0C801BF@AndersPC> <[e-mail]> <[e-mail]> <C9AC1F930318490194E751FD49E04B4C@AndersPC>
In-Reply-To: <C9AC1F930318490194E751FD49E04B4C@AndersPC>
X-MIMETrack: Itemize by SMTP Server on vinea/ON-X(Release 5.0.11  |July 24, 2002) at 11/21/2008 06:08:46 PM, Serialize by Router on vinea/ON-X(Release 5.0.11  |July 24, 2002) at 11/21/2008 06:08:46 PM, Serialize complete at 11/21/2008 06:08:46 PM
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060307010407040708020303"
Sender: [e-mail]
Precedence: 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.

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

There are some firewalls that doesn' like things like:

X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f


I don't know whether it is intended that majordom is not a trustworthy
entity to the local mail daemon.






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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOhTCC
BHIwggLfoAMCAQICBgqvijKA3jANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G
A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs
UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNzAzMjYxMDM3MDNaFw0wOTA2MDMxMDM3MDNaMHAx
CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ
S0kxNTAzBgNVBAMMLFBldGVyIFNZTFZFU1RFUiA8UGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIu
ZnI+MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDPB7ZSfmYsUuVIV0W2izxb1Zyvr6ZJ
IjPiqRMs77dbEQhQ6FZhhUSuABxxc8NjZvyPMRo0uuT0iVpRDktb0fWPTx3m9qTfdqrhWg2c
IOBKNbNQr8NogDJvG1AxRx4q9SXKZCVpZCoHu3fz2Rfji1kL7l597+7qBEsFd9IyvRaexQID
AQABo4IBLjCCASowYgYDVR0RBFswWYEaUGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIuZnKkOzA5
MQswCQYDVQQGEwJGUjEQMA4GA1UECgwHRWRlbFdlYjEYMBYGA1UEAwwPUGV0ZXIgU1lMVkVT
VEVSMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD
VR0fBEMwQTA/oD2gO4Y5aHR0cDovL2VkZWxwa2kuZWRlbHdlYi5mci9jcmwvRWRlbFBLSS1F
ZGVsV2ViLVBlcnNHRU4uY3JsMB0GA1UdDgQWBBSZjq81LuJmsiiu1Yt/ezwCiUQSQTAfBgNV
HSMEGDAWgBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUA
A4IBfAAUq5MJ3gXhdKDpOm0ascDE9e1iMo0RQ24ujkc9IrFXhAJNS+3eNwcJEieU2vgZTsGb
zKeBZom1zVOFoh73VIRP6T08j4dDlndpDYZbxD20KzFt9zX6gV8IgR2zkkZXLQRbLyW16kw8
oFe3s//p1csCkCPAlZv1rZQYR5Psm0A1aiOiuSHhWUmgfAJxmIgfbmKtS3WpsUZVBuLQpThN
rWjLRAqJKYA++++qqo3ujqAAzJLe+MHrX5dai7+n6WBfV4qo1uDArR7XbmgVpV/EdPA75XRi
XEedLgbFDawJ9nAMN6WfL/NG6GZkEa7mZ7sH/gG34y21nq4w4mAAxn9wz7mDKMsEbJMZ5VlJ
TOp0g6TdYqGjNoc/rQg7pqjcRChVitwd1Rl8O31+bIdNSpv4UReNMDcffRQrt+pF1FxR4q6q
M9YLJU8NThx/89Mf/WF7fzrgVlsNJ78D9nJu0EhKes/9EX2qpIcHUfk/izOj8lCc1ksFgXpd
UEchE0DcMIIEcjCCAt+gAwIBAgIGCq+KMoDeMA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT
AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV
BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA3MDMyNjEwMzcwM1oXDTA5MDYwMzEw
MzcwM1owcDELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsMD1NlcnZp
Y2UgRWRlbFBLSTE1MDMGA1UEAwwsUGV0ZXIgU1lMVkVTVEVSIDxQZXRlci5TeWx2ZXN0ZXJA
ZWRlbHdlYi5mcj4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAM8HtlJ+ZixS5UhXRbaL
PFvVnK+vpkkiM+KpEyzvt1sRCFDoVmGFRK4AHHFzw2Nm/I8xGjS65PSJWlEOS1vR9Y9PHeb2
pN92quFaDZwg4Eo1s1Cvw2iAMm8bUDFHHir1JcpkJWlkKge7d/PZF+OLWQvuXn3v7uoESwV3
0jK9Fp7FAgMBAAGjggEuMIIBKjBiBgNVHREEWzBZgRpQZXRlci5TeWx2ZXN0ZXJAZWRlbHdl
Yi5mcqQ7MDkxCzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQDDA9QZXRl
ciBTWUxWRVNURVIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF
BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2ViLmZyL2NybC9F
ZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFJmOrzUu4mayKK7Vi397PAKJ
RBJBMB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MAkGA1UdEwQCMAAwDQYJKoZI
hvcNAQEFBQADggF8ABSrkwneBeF0oOk6bRqxwMT17WIyjRFDbi6ORz0isVeEAk1L7d43BwkS
J5Ta+BlOwZvMp4FmibXNU4WiHvdUhE/pPTyPh0OWd2kNhlvEPbQrMW33NfqBXwiBHbOSRlct
BFsvJbXqTDygV7ez/+nVywKQI8CVm/WtlBhHk+ybQDVqI6K5IeFZSaB8AnGYiB9uYq1Ldamx
RlUG4tClOE2taMtECokpgD7776qqje6OoADMkt74wetfl1qLv6fpYF9XiqjW4MCtHtduaBWl
X8R08DvldGJcR50uBsUNrAn2cAw3pZ8v80boZmQRruZnuwf+AbfjLbWerjDiYADGf3DPuYMo
ywRskxnlWUlM6nSDpN1ioaM2hz+tCDumqNxEKFWK3B3VGXw7fX5sh01Km/hRF40wNx99FCu3
6kXUXFHirqoz1gslTw1OHH/z0x/9YXt/OuBWWw0nvwP2cm7QSEp6z/0RfaqkhwdR+T+LM6Py
UJzWSwWBel1QRyETQNwwggWVMIIDMKADAgECAgYKwoI0lJgwDQYJKoZIhvcNAQEFBQAwUjEL
MAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2UgRWRlbFBL
STEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDcwNjI4MTc0MDU0WhcNMTQwNTAyMTc0
MDU0WjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2Vydmlj
ZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTjCCAZwwDQYJKoZI
hvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bcrJKIlnAPn6eH8V1M
ORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5JfuDjU6Aq0RzmjqTWDe
1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WLwHLA+sIKFzA/CCRt
qeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQNHeCgbUvebvAT9Hd
UGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy4DazzXfZosKeJATH
pyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38psgnVLtPPITgOZrS
cV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+EiISL7aJHQcJRoNB
CdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4GgMIGdMDoGA1UdHwQzMDEwL6AtoCuGKWh0
dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8GA1UdEwQIMAYBAf8C
AQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAfBgNV
HSMEGDAWgBSo2SuP1LBnur1JXLwz/HdSEblnnTANBgkqhkiG9w0BAQUFAAOCAk4AUgtIR4Jh
Ynyk939SM6X4YZPNYIgDio8Gp064P1MBILDgI/hzSwyxT5bb1qUQub+icXO9/5ufsDufr/ff
2gCzKMuo3hC26iey630PzHTvJgrTcEp9c92IZPt3UKeouqy+95Lz2r58dbfouKLZVwiKQ0jP
2c2U5tPWmzW4CAjFWUKRYlrhbt+tjzW8CAA0DHO1xrrzAuTyuGNKcH4LlLuVo7MbDPn/uLma
1fAVYvH2c6OTwGHJyKTQVveYw4UqgAhErJMFWJDKm+Q9h91mCzkjrA1Eu0nVDUTV1+dW6mNT
DPLIq0qSdqP7iT2WcNzQVy/0PiXT2aaEH9lE2W1SSD6PnT8y+aqJTGjRMK1cl7VSJHxbq8U9
lIS+6eiV5VrogAa8X52pKF0u91i+/CBZ3e5Mi2/BwMrMN/mXA/ZwL3p+jZpnijpqnqdz8iCn
qR9ExhR+BpN/b56RqEu7llLrcwOS44kjbubALjxe0+XutidWjt/6/tLYuM7rJ6Hk1EweFGVd
kRejKogD3GzZ3gOAIF/D28VBJcTRcyF7OI/k/3jPD0gHUGN1uxk2Krz8SE9GEPvP/JehCBl/
FrQOCsEUmszi7Se0Vxr2k1P7icxT7L/AcWt/djIgp/vsQNurbi0+5+q7YS2b2bc1HchjsmaI
cXy8ha5IGk4+F1qrHZsGqTm5M7TzZN6k0X2llMaozrtPzxNMC6uvf1uRvHYHf1x0Q0pdxTzZ
PuuFw1PUlu6o5xPHbf3ZgC7ZNSDry13ZEXmlG2Re0u9WwEJJ1nYqlcDvNzGCAq4wggKqAgEB
MGUwWzELMAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2Ug
RWRlbFBLSTEgMB4GA1UEAxMXRWRlbFBLSSBFZGVsV2ViIFBlcnNHRU4CBgqvijKA3jAJBgUr
DgMCGgUAoIIBnzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0w
ODExMjExNzA0MjRaMCMGCSqGSIb3DQEJBDEWBBSlEEYg12gIwbcoKTtIK24KWUiooDBSBgkq
hkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIB
QDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDB0BgkrBgEEAYI3EAQxZzBlMFsxCzAJBgNVBAYT
AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV
BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOAgYKr4oygN4wdgYLKoZIhvcNAQkQAgsxZ6Bl
MFsxCzAJBgNVBAYTAkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVk
ZWxQS0kxIDAeBgNVBAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOAgYKr4oygN4wDQYJKoZI
hvcNAQEBBQAEgYBXkHVq3IRT/NOO0K2X5G+uryijmzio3WeYj5QJpp/quI/6ng0L6BqAWFqt
8H9WRBxw/uTQmwifG50t85C1OKqJJPwELpqN+P7izrblValW8sUg85gfGtdcNgVRwxJzpVru
YSi+c/BK4MvHL2DJTSRnjla/t/e9kYcVzk0/6t2iowAAAAAAAA==
--------------ms060307010407040708020303--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mALGLMq5077413 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Nov 2008 09:21:22 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mALGLMs4077412; Fri, 21 Nov 2008 09:21:22 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pne-smtpout1-sn2.hy.skanova.net (pne-smtpout1-sn2.hy.skanova.net [81.228.8.83]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mALGLBq1077397 for <[e-mail]>; Fri, 21 Nov 2008 09:21:21 -0700 (MST) (envelope-from [e-mail])
Received: from AndersPC (81.232.45.215) by pne-smtpout1-sn2.hy.skanova.net (7.3.129) id 48A144C501ACEB09; Fri, 21 Nov 2008 17:21:09 +0100
Message-ID: <C9AC1F930318490194E751FD49E04B4C@AndersPC>
From: "Timothy J Miller" <[e-mail]>
To: "Timothy J Miller" <[e-mail]>
Cc: <[e-mail]>
References: <1E0ECAB75B5B496F942BC7D49F9D7DA5@AndersPC> <[e-mail]> <3F7D87D9792849A28D560DC8341AC63F@AndersPC> <[e-mail]> <C515607EF9594962B192C59A8D711456@AndersPC> <[e-mail]> <E99AF3B38BBE4AADB8055166E0C801BF@AndersPC> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: Re: The EU Signature Directive - A 15+15 Year Perspective
Date: Fri, 21 Nov 2008 17:21:09 +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 Windows Mail 6.0.6000.20661
X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16669
Sender: [e-mail]
Precedence: 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 the other hand I neither expect nor assume that people will accept  
>or install trust in the MITRE PKI just because I'm signing mail to a  
>list.  But the integrity functions of S/MIME are unimpaired and IMHO  
>as important as the authentication and confidentiality functions.

I could if I had spent some 20 extra minutes, created a certificate that
would be "visually" indistinguishable from your MITRE PKI certificate.
With that I would like to say that integrity without authentication doesn't
buy that much.

[e-mail] impersonating [e-mail] which was
piece of cake since secure Internet mail is a joke.  Although I personally
do not laugh...

Naturally my ISP should have authenticated me and only let me use one
of the e-mail addresses I have registered, but it didn't since there is no
point in doing that because the rest of the security architecture is broken.

Anders-as-Tim



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mALEISgG072095 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Nov 2008 07:18:28 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mALEISEK072094; Fri, 21 Nov 2008 07:18:28 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mALEIGLY072086 for <[e-mail]>; Fri, 21 Nov 2008 07:18:27 -0700 (MST) (envelope-from [e-mail])
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id mALEIG4P022368 for <[e-mail]>; Fri, 21 Nov 2008 09:18:16 -0500
Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id mALEIFjJ022355; Fri, 21 Nov 2008 09:18:15 -0500
Received: from stovetop.mitre.org (128.29.115.173) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server id 8.1.311.2; Fri, 21 Nov 2008 09:18:15 -0500
CC: <[e-mail]>
Message-ID: <[e-mail]>
From: Timothy J Miller <[e-mail]>
To: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; boundary="Apple-Mail-2--138277110"; micalg=sha1; protocol="application/pkcs7-signature"
MIME-Version: 1.0 (Apple Message framework v929.2)
Subject: Re: The EU Signature Directive - A 15+15 Year Perspective
Date: Fri, 21 Nov 2008 08:17:02 -0600
References: <1E0ECAB75B5B496F942BC7D49F9D7DA5@AndersPC> <[e-mail]> <3F7D87D9792849A28D560DC8341AC63F@AndersPC> <[e-mail]> <C515607EF9594962B192C59A8D711456@AndersPC> <[e-mail]> <E99AF3B38BBE4AADB8055166E0C801BF@AndersPC> <[e-mail]>
X-Mailer: Apple Mail (2.929.2)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--Apple-Mail-2--138277110
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: 7bit

On Nov 21, 2008, at 3:13 AM, Stephen Wilson wrote:

> In an open community, one stranger sending a signed e-mail to  
> another is very closely analogous to sending a plain paper fax with  
> a handwritten signature on the bottom.  If you weren't expecting it,  
> and you didn't recognise the sender, you would probably throw such a  
> fax into the trash.  The idea that a receiver would be interested  
> enough to examine the certificate and even read the sender's CA's CP  
> was always fanciful.
>
> So, S/MIME on its own is not terribly useful in business.  [Whether  
> someone signs their e-mail to this list is really immaterial; most  
> of us recognise one another, and in any case the communications are  
> not critical, so authentication is moot.  Frankly I don't know why  
> anyone would bother signing their e-mails, I assume it's habit, and/ 
> or a default.]

Since it's my ears burning, I'll say it's both habit and default.  :)   
Apple Mail is my main MUA; it handles S/MIME settings on a "last set  
is next default" basis.  So if I sign an internal mail--and typically  
have reasons to do so--the next mail will default to signed.  TB is  
the other MUA I use relatively frequently, and it makes it unintuitive  
enough to change S/MIME options on any single email that I've set  
signed as the default.

On the other hand I neither expect nor assume that people will accept  
or install trust in the MITRE PKI just because I'm signing mail to a  
list.  But the integrity functions of S/MIME are unimpaired and IMHO  
as important as the authentication and confidentiality functions.

> So I still don't think that anyone should fixate on messaging as a  
> keystone application of PKI.  The experience of messaging is not an  
> accurate baromoter of the fortunes of PKI.

However, it's been my experience that S/MIME is the flagship PKI  
application *from a typical user's perspective.* In the environment I  
support users see and use it every day, even more than PKI authN to  
web services or even Kerberos PKINIT.  When I say "PKI" to a group of  
users, the response I get is "email"--and that's after years of  
training (though the high turnover rate of some of my user population  
doesn't help here).

And it's the application that causes the most pain and suffering.

-- Tim


--Apple-Mail-2--138277110
Content-Disposition: attachment; filename="smime.p7s"
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIHUzCCA2cw
ggJPoAMCAQICAh8FMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UE
CxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmlt
YXJ5IENBLTEwHhcNMDgwODIxMTUzMTI5WhcNMTAwMjEyMTUzMTI5WjBaMRIwEAYDVQQKEwltaXRy
ZS5vcmcxDzANBgNVBAsTBnBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3RtaWxsZXIxGjAYBgNVBAMT
EU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCTxM+z5fDKvmBI
nGatv0DkVwuOxd69S2M2jho8QkOltYJK/4JUm9uK0UtQZkyIbEjmCpmXLw17iMCgA0SjwuUfJxdF
8ntTys8keyMjRdlKSwFnkgZl9tL7o060LBtZQYzI5ajrW9k3N768G/k1bZS5UYiMGHU5+Ygl4IwV
hmQv3wIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF4DAdBgNVHQ4EFgQUSXARqmj5Bl2Lz7RLoUIk
uOHl0MkwHwYDVR0jBBgwFoAUh7QPSI1iM0LBLVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYz
aHR0cDovL3d3dy5taXRyZS5vcmcvdGVjaC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1Ud
EQQVMBOBEXRtaWxsZXJAbWl0cmUub3JnMA0GCSqGSIb3DQEBBQUAA4IBAQAbA1PH/hed/rryO1f0
yfTRJnD/vL1rFTduUut/irL7FSXHGybuPHxydfyGPvJ4qj+T8hs1W0jTa2zQnaPR52tms3hefl76
CNVP9vJoVmaM9svFX4DX6eJh/4SAI81tAuBIK8gxsWd1Va/Bnnh1/wsZLc8w2jkojVqkT2AHPaHS
3DBKX7QAWovXVSxYQlqMIH4zvSNSVfpvpIf0MWJWRBPvgerVSbJsA4dz6ziKvXDWySTV9zwSuNji
kNqL//nIKwjbr3ZOfSUOxSuhW58an2Ha4TdORvG4dGJEsMzxbpTB+wt/s6tK6roONV4uiDtODBNV
AG+XGofeMcsS0b7iXdxDMIID5DCCAsygAwIBAgIBBTANBgkqhkiG9w0BAQUFADBaMRIwEAYDVQQK
EwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEkMCIGA1UEAxMbTUlU
UkUgQ29ycG9yYXRpb24gUm9vdCBDQS0xMB4XDTA2MDYwMzE3MTMyMloXDTEyMDYwMzE3MTMyMlow
XTESMBAGA1UEChMJbWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAl
BgNVBAMTHk1JVFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMTCCASIwDQYJKoZIhvcNAQEBBQAD
ggEPADCCAQoCggEBAMjwe1ZdEIKoELdLvENnbkbO3mVD54ZX5SjxTzFxhvoqhqSJmLOp32xT7J9K
vBapJRbJv1BFdiSUN3O0q8H66nvQqwm1RYe+tTsWSO351FolGrDT9iDRtfWgH60PCKCbABLRsx3i
GnEvjOQjeAtMn1AugqQWU3PWZXYy1Grbya+NOytYvu1p60bDFSoSAn4Jojv14lUfWHl8s3kahay8
umLSQibiXdEEX8CrSkaXpOaFOuyM6+wpRw7TybO1Dk4zGAUtn0887QvsMDk6evgN2WxMprkHAGUc
JhpI1QXtkfDIl9ukdNiIoM/vdN2QC/+m6b8dA55K5UdlBa9SgRnwapkCAwEAAaOBsTCBrjASBgNV
HRMBAf8ECDAGAQH/AgECMA4GA1UdDwEB/wQEAwIBhjAdBgNVHQ4EFgQUh7QPSI1iM0LBLVEaSB7C
nrsKsa0wHwYDVR0jBBgwFoAUx3BRANhN/uQB1GiWxT2fmpf+dC8wSAYDVR0fBEEwPzA9oDugOYY3
aHR0cDovL3d3dy5taXRyZS5vcmcvdGVjaC9taWkvcGtpL3Jvb3RjYTFfbWl0cmVfb3JnLmNybDAN
BgkqhkiG9w0BAQUFAAOCAQEATW5u664p7N0iAj27Xl/akjdfkSQpaosf6cNyAHu7utCytFfY1WfR
NmvnNDGYkqI3XMFOa18SNjiNsMCH+sFQaO+oyDnPiIkEZQvlfGGrRpqIm6j//Fgz85bnf1kAM5I6
1Np7ofCnciRvp9ZB/+u+9i262tgiJPJrvBcqXmgeT9riCc3RPjxqPNmYslOvNLpIifchelJhF7nI
ge+7RkAUcTJenj8yKwK0J3+PEpgYRQ+V2C62rnjohuxPgMw/fYoNTOlh3MVl7adwyK1ahPw2a9eO
jSWglqoPTaBNeHJqRJZZ6Vi7S55+VAWCfkAqM5m3tUiVzjsp2dFcTJxnYezaoDGCAlQwggJQAgEB
MGMwXTESMBAGA1UEChMJbWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkx
JzAlBgNVBAMTHk1JVFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMQICHwUwCQYFKw4DAhoFAKCC
AUcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDgxMTIxMTQxNzAz
WjAjBgkqhkiG9w0BCQQxFgQU7dpbmteXQgduJE+mlPCQvEZK8dMwcgYJKwYBBAGCNxAEMWUwYzBd
MRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEnMCUG
A1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTB0BgsqhkiG9w0BCRACCzFl
oGMwXTESMBAGA1UEChMJbWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkx
JzAlBgNVBAMTHk1JVFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMQICHwUwDQYJKoZIhvcNAQEB
BQAEgYAjvmD/uROg+4qV3WaS33lDh9xGJ/3LutecZEoIm+nXXocXqwKelrcdK4lHNHnADWt3BQMy
uWKjM6IX2B34680xchxiudjbmu2NCBZswurxjU5kSWpwM22dCeKZCMhZqXrlx/+gFAMIHrMWoqLG
H0b5EeS8I1GI1o33+5r6Ajk+ygAAAAAAAA==

--Apple-Mail-2--138277110--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mALCK8wD067557 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Nov 2008 05:20:08 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mALCK8Ng067556; Fri, 21 Nov 2008 05:20:08 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pne-smtpout2-sn2.hy.skanova.net (pne-smtpout2-sn2.hy.skanova.net [81.228.8.164]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mALCJvL7067539 for <[e-mail]>; Fri, 21 Nov 2008 05:20:08 -0700 (MST) (envelope-from [e-mail])
Received: from AndersPC (81.232.45.215) by pne-smtpout2-sn2.hy.skanova.net (7.3.129) id 4873CA950219F444; Fri, 21 Nov 2008 13:19:55 +0100
Message-ID: <C755FC0446C147BD8BEA31E18197AC56@AndersPC>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
References: <1E0ECAB75B5B496F942BC7D49F9D7DA5@AndersPC> <[e-mail]> <3F7D87D9792849A28D560DC8341AC63F@AndersPC> <[e-mail]> <C515607EF9594962B192C59A8D711456@AndersPC> <[e-mail]> <E99AF3B38BBE4AADB8055166E0C801BF@AndersPC> <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: Re: The EU Signature Directive - A 15+15 Year Perspective
Date: Fri, 21 Nov 2008 13:19:56 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Windows Mail 6.0.6000.20661
X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16669
Sender: [e-mail]
Precedence: 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,

>And so S/MIME it was never pushed hard.  The infrastructure and 
>interoperability challenges, while significant, would not have been 
>insurmountable, provided there was sufficient demand to solve them. 
>There wasn't, so they weren't.

I don't really see that there actually could be an economically, politically,
and technically realistic way making a user-based authentication, signing or
encryption solution work outside of a limited community.

Anyway, since S/MIME is pretty much a relic, when I talk about secure
messaging I refer to web services.

I may indeed be "obsessed" with secure messaging, and I do see some
progress in Europe where "PKI-lite" schemes are getting some traction.
The US seems to forever be stuck in the architecture once raised by the
federal government which is a very expensive and slow path to secure
messaging.  To get an Org (legal entity)-cert in the EU is a $300 thing,
while the cost of getting cross-certified with the FBCA ( http://www.cio.gov/fpkipa )
is prohibitive for all but pretty large organizations.

Germany (of course...) tries hard to get the EU countries lining up for
an EU BCA ( http://www.bridge-ca.de ), but I think they begin to see
that this will not be as easy as planned, since the alternative is cheaper,
faster, and integrates nicely with just about any "business" process you
can think of.

I don't know what they are doing "Down Under" but if you have a link
or two, I would appreciate it.

Anders



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAL9F1lw058932 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Nov 2008 02:15:01 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAL9F1RK058931; Fri, 21 Nov 2008 02:15:01 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp202.sat.emailsrvr.com (smtp202.sat.emailsrvr.com [66.216.121.202]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAL9EoGg058914 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Fri, 21 Nov 2008 02:15:00 -0700 (MST) (envelope-from [e-mail])
Received: from relay10.relay.sat.mlsrvr.com (localhost [127.0.0.1]) by relay10.relay.sat.mlsrvr.com (SMTP Server) with ESMTP id C54491DFA0D for <[e-mail]>; Fri, 21 Nov 2008 04:14:49 -0500 (EST)
Received: by relay10.relay.sat.mlsrvr.com (Authenticated sender: swilson-AT-lockstep.com.au) with ESMTP id 44A111DFA0C for <[e-mail]>; Fri, 21 Nov 2008 04:14:49 -0500 (EST)
Message-ID: <[e-mail]>
Date: Fri, 21 Nov 2008 20:13:14 +1100
From: Stephen Wilson <[e-mail]>
Reply-To: [e-mail]
Organization: Lockstep
User-Agent: Thunderbird 2.0.0.18 (Windows/20081105)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: The EU Signature Directive - A 15+15 Year Perspective
References: <1E0ECAB75B5B496F942BC7D49F9D7DA5@AndersPC> <[e-mail]> <3F7D87D9792849A28D560DC8341AC63F@AndersPC> <[e-mail]> <C515607EF9594962B192C59A8D711456@AndersPC> <[e-mail]> <E99AF3B38BBE4AADB8055166E0C801BF@AndersPC>
In-Reply-To: <E99AF3B38BBE4AADB8055166E0C801BF@AndersPC>
Content-Type: text/plain; charset=UTF-8; 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 my view, S/MIME e-mail is a very generic application.  It does fit 
well my analysis of application-specific versus generic, and I think it 
is actually predictable that S/MIME on its own would be difficult and 
not very beneficial.

In an open community, one stranger sending a signed e-mail to another is 
very closely analogous to sending a plain paper fax with a handwritten 
signature on the bottom.  If you weren't expecting it, and you didn't 
recognise the sender, you would probably throw such a fax into the 
trash.  The idea that a receiver would be interested enough to examine 
the certificate and even read the sender's CA's CP was always fanciful.

So, S/MIME on its own is not terribly useful in business.  [Whether 
someone signs their e-mail to this list is really immaterial; most of us 
recognise one another, and in any case the communications are not 
critical, so authentication is moot.  Frankly I don't know why anyone 
would bother signing their e-mails, I assume it's habit, and/or a default.]

And so S/MIME it was never pushed hard.  The infrastructure and 
interoperability challenges, while significant, would not have been 
insurmountable, provided there was sufficient demand to solve them. 
There wasn't, so they weren't.

There are all sorts of ways to realise "electronic messaging" and S/MINE 
is just one.  I presume that most defence forces have good electornic 
messaging systems.  Some messaging solutions would sensibly use digital 
signatures and certificates; others might not need to.

Meanwhile, there are inumerable other e-business applications separate 
over and above 'messaging;, where PKI is delivering great benefits.

So I still don't think that anyone should fixate on messaging as a 
keystone application of PKI.  The experience of messaging is not an 
accurate baromoter of the fortunes of PKI.

Cheers,

Stephen Wilson.



Anders Rundgren wrote:
> Stephen,
> I completely agree with your view regarding the value and use of community
> or app-specific PKIs.
> 
> However, one of the applications that caught my interest, secure messaging
> over the Internet doesn't fit very well into the categories you are mentioning,
> with S/MIME as the primary example.  That a bunch of people insist signing
> their mails to this list using PKIs that hardly any of the recipients recognize,
> is an indication that the concepts "community-scale security solution" versus
> "Internet-scale security solution" still are largely unknown.
> 
> That this knowledge deficit has limited impact on "nerdy" mailing lists like
> IETF-PKIX is for sure.   However, for governments it is not equally easy.
> 
> Anders
> 
> ----- Original Message ----- 
> From: "Stephen Wilson" <[e-mail]>
> To: "Anders Rundgren" <[e-mail]>
> Cc: <[e-mail]>; <[e-mail]>
> Sent: Wednesday, November 19, 2008 01:23
> Subject: Re: The EU Signature Directive - A 15+15 Year Perspective
> 
> 
> 
> Anders Rundgren wrote:
>> ... VeriSign's SSL PKI reaches out over the entire globe, while
>>       employee PKIs (be it PIV or just your local stuff) typically is
>>       unknown at 99.99% of all places, indicates that the employee PKI
>>       model suffers from pretty serious trust establishment issues
> 
> This is another red herring.  It tells us nothing true or deep about the 
> effectiveness of individual certificates.  The fact that employee PKIs 
> don't have global reach is hardly surprising.  To begin with, global 
> recognition of *employees* outside the enterprise is not usually 
> important!  Look at the J&J corporate PKI; seems to be working great 
> with 100,000+ individuals.
> 
> But more importantly, successful PKIs are always application specific. 
> [BTW the application-specificity of SSL server certificates is really 
> one of their most salient features, but almost always overlooked when 
> people try to draw lessons form SSL's success!]  The reach problem that 
> so concerns Anders is really only a matter of root key distribution. 
> With application specific PKI, where 9 times out of 10 the transacting 
> parties run special software (healthcare apps, conveyancing, trade 
> documentation management, Skype etc etc), root key distribution is 
> trivial.
> 
> Cheers,
> 
> Steve Wilson.
> 
> 
> 
> 
> Managing Director
> Lockstep Technologies
> 
> Phone [phone]
> 
> www.lockstep.com.au/technologies
> -------------------
>   * ABC TV 'The New Inventors' Nov 2008
>   * Global Security Challenge Asia Top Five 2008
>   * Australian Technology Showcase 2008
>   * AusIndustry COMET Grant 2007
>   * ICT Secrets of Innovation Finalist (Security) 2007
>   * Anthill / PwC Cool Company Finalist (Innovation) 2007
> -------------------
> Lockstep Technologies develops unique new smart ID solutions to
> safeguard identity and privacy. Lockstep Consulting provides
> independent specialist advice and analysis on authentication, PKI
> and smartcards.
> 
> 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAL8qAeG057682 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Nov 2008 01:52:10 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAL8qAn9057681; Fri, 21 Nov 2008 01:52:10 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pne-smtpout2-sn2.hy.skanova.net (pne-smtpout2-sn2.hy.skanova.net [81.228.8.164]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAL8pxDH057668 for <[e-mail]>; Fri, 21 Nov 2008 01:52:10 -0700 (MST) (envelope-from [e-mail])
Received: from AndersPC (81.232.45.215) by pne-smtpout2-sn2.hy.skanova.net (7.3.129) id 4873CA950218EF97; Fri, 21 Nov 2008 09:51:57 +0100
Message-ID: <E99AF3B38BBE4AADB8055166E0C801BF@AndersPC>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
References: <1E0ECAB75B5B496F942BC7D49F9D7DA5@AndersPC> <[e-mail]> <3F7D87D9792849A28D560DC8341AC63F@AndersPC> <[e-mail]> <C515607EF9594962B192C59A8D711456@AndersPC> <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: Re: The EU Signature Directive - A 15+15 Year Perspective
Date: Fri, 21 Nov 2008 09:51:58 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Windows Mail 6.0.6000.20661
X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16669
Sender: [e-mail]
Precedence: 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,
I completely agree with your view regarding the value and use of community
or app-specific PKIs.

However, one of the applications that caught my interest, secure messaging
over the Internet doesn't fit very well into the categories you are mentioning,
with S/MIME as the primary example.  That a bunch of people insist signing
their mails to this list using PKIs that hardly any of the recipients recognize,
is an indication that the concepts "community-scale security solution" versus
"Internet-scale security solution" still are largely unknown.

That this knowledge deficit has limited impact on "nerdy" mailing lists like
IETF-PKIX is for sure.   However, for governments it is not equally easy.

Anders

----- Original Message ----- 
From: "Stephen Wilson" <[e-mail]>
To: "Anders Rundgren" <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>
Sent: Wednesday, November 19, 2008 01:23
Subject: Re: The EU Signature Directive - A 15+15 Year Perspective



Anders Rundgren wrote:
> ... VeriSign's SSL PKI reaches out over the entire globe, while
>       employee PKIs (be it PIV or just your local stuff) typically is
>       unknown at 99.99% of all places, indicates that the employee PKI
>       model suffers from pretty serious trust establishment issues

This is another red herring.  It tells us nothing true or deep about the 
effectiveness of individual certificates.  The fact that employee PKIs 
don't have global reach is hardly surprising.  To begin with, global 
recognition of *employees* outside the enterprise is not usually 
important!  Look at the J&J corporate PKI; seems to be working great 
with 100,000+ individuals.

But more importantly, successful PKIs are always application specific. 
[BTW the application-specificity of SSL server certificates is really 
one of their most salient features, but almost always overlooked when 
people try to draw lessons form SSL's success!]  The reach problem that 
so concerns Anders is really only a matter of root key distribution. 
With application specific PKI, where 9 times out of 10 the transacting 
parties run special software (healthcare apps, conveyancing, trade 
documentation management, Skype etc etc), root key distribution is 
trivial.

Cheers,

Steve Wilson.




Managing Director
Lockstep Technologies

Phone [phone]

www.lockstep.com.au/technologies
-------------------
  * ABC TV 'The New Inventors' Nov 2008
  * Global Security Challenge Asia Top Five 2008
  * Australian Technology Showcase 2008
  * AusIndustry COMET Grant 2007
  * ICT Secrets of Innovation Finalist (Security) 2007
  * Anthill / PwC Cool Company Finalist (Innovation) 2007
-------------------
Lockstep Technologies develops unique new smart ID solutions to
safeguard identity and privacy. Lockstep Consulting provides
independent specialist advice and analysis on authentication, PKI
and smartcards.




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAKF4Tdd016234 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Nov 2008 08:04:29 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAKF4TKw016233; Thu, 20 Nov 2008 08:04:29 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAKF4G5q016220 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 20 Nov 2008 08:04:27 -0700 (MST) (envelope-from [e-mail])
Received: from dommiel.bbn.com ([192.1.122.15] helo=[130.129.78.165]) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from <[e-mail]>) id 1L3B4o-0004Dl-A6; Thu, 20 Nov 2008 10:04:14 -0500
Mime-Version: 1.0
Message-Id: <p0624050bc54b2c4410e8@[130.129.78.165]>
In-Reply-To: <17164937EE0E410A9CD1703DBA5E0F1D@Wylie>
References: <[e-mail]> <6DE5ACAFBF0648278ABF3936799A87FA@Wylie> <[e-mail]> <17164937EE0E410A9CD1703DBA5E0F1D@Wylie>
Date: Thu, 20 Nov 2008 10:02:25 -0500
To: "Turner, Sean P." <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: AD comments for draft-ietf-pkix-ecc-subpubkeyinfo-09
Cc: <[e-mail]>, <[e-mail]>
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>

Sean & Pasi,

I am comfortable with these changes.

If anyone in the WG objects, say so now, else we will consider the 
previous WGLC to still be valid.

Steve



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAK6nohk085988 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Nov 2008 23:49:50 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAK6noiQ085986; Wed, 19 Nov 2008 23:49:50 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.33]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAK6nb2C085965 for <[e-mail]>; Wed, 19 Nov 2008 23:49:49 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 40B8D9D793; Thu, 20 Nov 2008 19:49:37 +1300 (NZDT)
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W4w994hJ2Wnv; Thu, 20 Nov 2008 19:49:37 +1300 (NZDT)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 5C4309D791; Thu, 20 Nov 2008 19:49:30 +1300 (NZDT)
Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 3C65F19EC0BA; Thu, 20 Nov 2008 19:49:29 +1300 (NZDT)
Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from <[e-mail]>) id 1L33M1-0001CQ-3W; Thu, 20 Nov 2008 19:49:29 +1300
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail]
Subject: Re: encoding an X.509 certificate
Cc: [e-mail]
In-Reply-To: <p06240820c53d14b4be06@[10.20.30.152]>
Message-Id: <[e-mail]>
Date: Thu, 20 Nov 2008 19:49:29 +1300
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Paul Hoffman <[e-mail]> writes:

>However, as Peter points out, there seems to be little interest on the part
>of the CA ven dors to enforce the rules of X.509 and PKIX.

There's been an off-list discussion of various instances of this, I don't want
to start quoting other people's private mail but here's a sample from my part
of the discussion:

  The pushback from users of commercial CAs ("It's a large commercial CA, they
  can't be wrong!") is even worse than the "We have thousands of certs already
  deployed" that you mention.  The worst ones are the "This is a CA certified
  and approved by our government, we can't even ask them to fix things".

This isn't going to get fixed, ever.  I have a marvellously broken cert chain
created some years ago by a particular government-approved CA (who were
notified of the problem and requested to fix it) and it expired recently, so I
asked someone in the country where they issue certs whether I could get a
recent cert chain from them (these things make for nice test cases :-).  They
sent me a new cert chain, still broken as before.

When your decision on what to do can be rephrased as "Would you like to
continue doing business in country X?" then the choices are rather limited
(particularly when your company is based in country X and depends heavily on
government contracts, as these guys were).

Peter.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAJMA37v060120 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Nov 2008 15:10:03 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAJMA3X7060119; Wed, 19 Nov 2008 15:10:03 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pne-smtpout1-sn1.fre.skanova.net (pne-smtpout1-sn1.fre.skanova.net [81.228.11.98]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAJM9prw060096 for <[e-mail]>; Wed, 19 Nov 2008 15:10:02 -0700 (MST) (envelope-from [e-mail])
Received: from AndersPC (81.232.45.215) by pne-smtpout1-sn1.fre.skanova.net (7.3.129) id 47A9795004CABA5F; Wed, 19 Nov 2008 23:09:49 +0100
Message-ID: <58AA507C8A2442E892FCFB10FD675C46@AndersPC>
From: "Anders Rundgren" <[e-mail]>
To: "Stefan Santesson" <[e-mail]>, <[e-mail]>
References: <1E0ECAB75B5B496F942BC7D49F9D7DA5@AndersPC> <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: Re: The EU Signature Directive - A 15+15 Year Perspective
Date: Wed, 19 Nov 2008 23:09:48 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00BB_01C94A9B.EB774BA0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Windows Mail 6.0.6000.20661
X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16669
Sender: [e-mail]
Precedence: 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_00BB_01C94A9B.EB774BA0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Stefan,
You're right, I screw up the adoption year.

Regarding the motives behind this and that for e-invoices I'm not able =
to tell because it is simply not decodable based on for example the =
German "solution" depicted a few postings ago.

Is this political manifesto? Well, that depends on what you mean with =
political :-)

What does S/MIME bring me using Windows Mail except for a black screen =
telling that there is a security problem with this message, compared to =
unsigned messages encouraging me to download coolpicture.exe which is =
treated as secure mail?  Of course Microsoft can add =
yet-another-impossible-to-understand-by-ordinary-humans-security-setting,=
 but I don't think it will help much because S/MIME is based on an =
inferior security architecture (which in fact is the indirect reason to =
why I got the coolpicture.exe message as well).

Isn't somewhat funny that the scheme I described some 10 years ago =
(server-signed assertions), which roughly 100% of the PKIX list slammed =
as a bad idea, actually is one of the corner-stones of Microsoft's =
brilliant CardSpace technology?

Both of these things are in turn is highly related to the undisputed =
fact that the US government doesn't have a documented architecture for =
secure messaging between agencies of the kind that is slowly but surely =
becoming standard in the EU.

Is there something for PKIX to cater for here?  It seems that most PKIX =
folks prefer dealing with rather esoteric stuff
http://www.ietf.org/proceedings/08nov/agenda/pkix.txt
than for example digging into the realities of large-scale =
consumer/citizen PKIs of the kind used in Europe.  I'm currently =
implementing the PKI for Web 2.0 framework in Google's Android because I =
think the route Microsoft selected for CardSpace (first code + =
preliminary specs, then standards) is a better mousetrap.

Regards
Anders Rundgren


  ----- Original Message -----=20
  From: Stefan Santesson=20
  To: Anders Rundgren ; [e-mail]=20
  Sent: Tuesday, November 18, 2008 23:41
  Subject: RE: The EU Signature Directive - A 15+15 Year Perspective


  Anders,

  =20

  On the factual side, the EU signature directive was adopted 1999, =
which is 9 years ago and not 15.

  Further, the primary function of the EU directive was to establish =
that no signature should be denied legal value solely because it was not =
based on a certain technology or met certain standards. The article 5 =
signature (often referred to as qualified signatures) are just a level =
of security that all member countries MUST accept as equivalent to =
hand-written signatures. I certainly agree that the content and =
intention of this directive has been highly misunderstood.

  =20

  The requirements on electronic invoicing comes from a totally separate =
directive.

  =20

  However, I lack any specific technical proposal for this working group =
to consider in your e-mail.=20

  In absence of such proposal, your mail appears to me more as a =
political manifesto.

  =20

  =20

  Stefan Santesson

  Senior Program Manager

  Windows Security, Standards

  =20

  From: [e-mail] =
[mailto:[e-mail]] On Behalf Of Anders Rundgren
  Sent: den 18 november 2008 04:38
  To: [e-mail]
  Subject: The EU Signature Directive - A 15+15 Year Perspective

  =20

  Some 15 years ago the EU launched a signature directive.  This posting =
tries to describe the consequences of this directive with respect to =
usage of PKI.

  =20

  Primary Motivation

  =20

  There are a number of processes needing a human-written signature in =
order to fulfill legal requirements.

  =20

  Some of these processes could without doubt be possible to carry out =
electronically and thus also remote over a network, if there was some =
kind of technology available that could serve as a replacement for a =
hand-written signature.

  =20

  The Solution

  =20

  Right or wrong, digital signatures using PKI were considered as a =
viable alternative.  To make PKI a credible solution, the EU signature =
directive added a number of requirements including characteristics of =
the signature creation device and policies for CAs.

  =20

  Current Deployment

  =20

  Apart from Qualified Certificates which (for reasons too diverse for =
describing in an email) have not become truly mainstream, the EU =
signature directive have indeed in local legislations made it possible =
to perform fairly qualified tasks remotely over the Internet.  I.e. the =
directive has functioned as an ENABLER.

  =20

  Then Something Went Wrong...

  =20

  Unfortunately, a few (but influential) people got a bit carried away =
and interpreted the signature directive in way that has severely =
hampered the use of PKI.  Essentially they began claiming that all =
messages in order to be trustworthy should be signed by a qualified =
signature or at least by a digital signature created under the direct =
control a human being.

  =20

  From a 50000 ft perspective this may sound like a great idea, but the =
fact is that decades before the signature directive was conceived; yes, =
even before PKI was invented, the concept of secure messaging actually =
existed.  Back in those days secure messaging was facilitated through =
the use of leased lines which allowed banks (and some early b2b =
networks), to securely exchange transaction messages in a completely =
automated fashion.

  =20

  An example:  If you want to wire-transfer money from your bank to =
another bank, the way the transfer is initiated (phone, paper, on-line, =
etc) has no impact on the transaction messaging because it is performed =
in a transaction network that neither the customers, nor most of the =
staff have direct access to.=20

  =20

  That such networks have proved to be secure, reliable, cost-efficient, =
and sometimes even globally scalable, apparently did not impress the =
bunch of hard-core signature experts who for example in Germany managed =
to make PKI a DISABLER by outlawing non-human digital signatures on =
invoices.  That German paper-invoices do not even require signatures =
makes this position a true mystery.

  =20

  One had hoped that this would be an exception to the rule but it is =
not; If you scan sites like NIST.GOV, CIO.GOV, and GSA.GOV you'll find =
literally thousands of security-related documents, indeed in a few =
places mentioning PKI, but mostly full of government regulation =
abbreviations like FISMA, giving little if any guidance on how to create =
secure messaging between agencies, not to mention between agencies and =
the private sector.

  =20

  I'm happy to see that the Nordic countries plus Estonia have realized =
that all signatures that can be securely bound to an entity (in =
practice) are legally binding, in the extremely rare case somebody would =
actually repudiate a signed invoice.   These governments have all (and =
independently of each other) created local variants of a scheme that I =
have described in:

  http://webpki.org/papers/web/gateway.pdf

  which could be characterized as a 21st century version of leased lines =
for multi-party automated secure messaging.

  It will probably take another 15 years for this concept to achieve =
general acceptance although it is really (if you look closely) very =
similar to the US e-Authentication scheme, they have just not connected =
the dots yet: A SAML assertion and an server-signed invoice from a =
specific entity are essentially only different in content, not in =
trustworthiness.

  =20

  Anders Rundgren

  http://WebPKI.org

  =20

  =20

------=_NextPart_000_00BB_01C94A9B.EB774BA0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:v =3D=20
"urn:schemas-microsoft-com:vml" xmlns:o =3D=20
"urn:schemas-microsoft-com:office:office" xmlns:w =3D=20
"urn:schemas-microsoft-com:office:word" xmlns:x =3D=20
"urn:schemas-microsoft-com:office:excel" xmlns:p =3D=20
"urn:schemas-microsoft-com:office:powerpoint" xmlns:a =3D=20
"urn:schemas-microsoft-com:office:access" xmlns:dt =3D=20
"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s =3D=20
"uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs =3D=20
"urn:schemas-microsoft-com:rowset" xmlns:z =3D "#RowsetSchema" xmlns:b =
=3D=20
"urn:schemas-microsoft-com:office:publisher" xmlns:ss =3D=20
"urn:schemas-microsoft-com:office:spreadsheet" xmlns:c =3D=20
"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns:odc =3D=20
"urn:schemas-microsoft-com:office:odc" xmlns:oa =3D=20
"urn:schemas-microsoft-com:office:activation" xmlns:html =3D=20
"http://www.w3.org/TR/REC-html40" xmlns:q =3D=20
"http://schemas.xmlsoap.org/soap/envelope/" XMLNS:D =3D "DAV:" xmlns:x2 =
=3D=20
"http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ois =3D=20
"http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir =3D=20
"http://schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds =3D=20
"http://www.w3.org/2000/09/xmldsig#" xmlns:dsp =3D=20
"http://schemas.microsoft.com/sharepoint/dsp" xmlns:udc =3D=20
"http://schemas.microsoft.com/data/udc" xmlns:xsd =3D=20
"http://www.w3.org/2001/XMLSchema" xmlns:sub =3D=20
"http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/" xmlns:ec =
=3D=20
"http://www.w3.org/2001/04/xmlenc#" xmlns:sp =3D=20
"http://schemas.microsoft.com/sharepoint/" xmlns:sps =3D=20
"http://schemas.microsoft.com/sharepoint/soap/" xmlns:xsi =3D=20
"http://www.w3.org/2001/XMLSchema-instance" xmlns:udcxf =3D=20
"http://schemas.microsoft.com/data/udc/xmlfile" xmlns:wf =3D=20
"http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:mver =3D=20
"http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:m =
=3D=20
"http://schemas.microsoft.com/office/2004/12/omml" xmlns:mrels =3D=20
"http://schemas.openxmlformats.org/package/2006/relationships" =
xmlns:ex12t =3D=20
"http://schemas.microsoft.com/exchange/services/2006/types" xmlns:ex12m =
=3D=20
"http://schemas.microsoft.com/exchange/services/2006/messages" XMLNS:Z =
=3D=20
"urn:schemas-microsoft-com:" xmlns:st =3D "=01"><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.6000.20927" name=3DGENERATOR>
<STYLE>@font-face {
	font-family: SimSun;
}
@font-face {
	font-family: Cambria Math;
}
@font-face {
	font-family: Calibri;
}
@font-face {
	font-family: Tahoma;
}
@font-face {
	font-family: @SimSun;
}
@page Section1 {size: 612.0pt 792.0pt; margin: 70.85pt 70.85pt 70.85pt =
70.85pt; }
P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New =
Roman","serif"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New =
Roman","serif"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New =
Roman","serif"
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline; mso-style-priority: 99
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline; mso-style-priority: 99
}
A:visited {
	COLOR: purple; TEXT-DECORATION: underline; mso-style-priority: 99
}
SPAN.MsoHyperlinkFollowed {
	COLOR: purple; TEXT-DECORATION: underline; mso-style-priority: 99
}
SPAN.EmailStyle19 {
	COLOR: #1f497d; FONT-FAMILY: "Calibri","sans-serif"; mso-style-type: =
personal-reply
}
.MsoChpDefault {
	FONT-SIZE: 10pt; mso-style-type: export-only
}
DIV.Section1 {
	page: Section1
}
</STYLE>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]--></HEAD>
<BODY lang=3DSV vLink=3Dpurple link=3Dblue bgColor=3Dwhite>
<DIV><FONT face=3DArial size=3D2>Hi Stefan,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>You're right, I screw up the adoption=20
year.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Regarding the motives behind this and =
that for=20
e-invoices I'm not able to tell because it is simply not decodable based =
on for=20
example the German "solution" depicted a few postings ago.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Is this political manifesto? Well, that =
depends on=20
what you mean with political :-)</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>What does S/MIME bring me using Windows =
Mail except=20
for a black screen telling that there is a security problem with this =
message,=20
compared to unsigned messages encouraging me to download <FONT=20
face=3D"Courier New">coolpicture.exe</FONT> which is treated =
as&nbsp;secure=20
mail?&nbsp; Of course Microsoft can add=20
yet-another-impossible-to-understand-by-ordinary-humans-security-setting,=
 but I=20
don't think it will help much because S/MIME is based on an inferior =
security=20
architecture (which in fact is the <EM>indirect</EM> reason to why I got =
the=20
<FONT face=3D"Courier New">coolpicture.exe</FONT> message as =
well).</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Isn't somewhat funny that the scheme I =
described=20
some 10 years ago (server-signed assertions),&nbsp;which =
roughly&nbsp;100% of=20
the PKIX list slammed as a bad idea, actually&nbsp;is&nbsp;one of=20
the&nbsp;corner-stones of&nbsp;Microsoft's brilliant CardSpace=20
technology?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Both of these things are in turn =
is&nbsp;highly=20
related to the undisputed&nbsp;fact that the US government doesn't have =
a=20
documented architecture for secure messaging between agencies of the =
kind that=20
is slowly but surely becoming standard in the EU.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>Is there something for PKIX to cater for here?&nbsp; It seems=20
that&nbsp;most&nbsp;PKIX folks prefer dealing with rather esoteric =
stuff</DIV>
<DIV><A=20
href=3D"http://www.ietf.org/proceedings/08nov/agenda/pkix.txt">http://www=
.ietf.org/proceedings/08nov/agenda/pkix.txt</A></DIV>
<DIV>than for example digging into the realities of large-scale =
consumer/citizen=20
PKIs of the kind used in Europe.&nbsp; I'm currently implementing the =
PKI for=20
Web 2.0 framework in Google's Android because I think the route =
Microsoft=20
selected for CardSpace (first code + preliminary specs, then standards) =
is a=20
better mousetrap.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Regards</DIV>
<DIV>Anders Rundgren</DIV></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A title=[e-mail] =
href=3D"mailto:[e-mail]">Stefan=20
  Santesson</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=[e-mail]=20
  href=3D"mailto:[e-mail]">Anders Rundgren</A> ; <A=20
  title=[e-mail] =
href=3D"mailto:[e-mail]">[e-mail]</A>=20
  </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Tuesday, November 18, =
2008=20
  23:41</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> RE: The EU Signature =
Directive -=20
  A 15+15 Year Perspective</DIV>
  <DIV><BR></DIV>
  <DIV class=3DSection1>
  <P class=3DMsoNormal><A name=3D_MailEndCompose><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'">Anders,<o:p></o:p></SPAN></A></P>
  <P class=3DMsoNormal><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'">On=20
  the factual side, the EU signature directive was adopted 1999, which =
is 9=20
  years ago and not 15.<o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'">Further,=20
  the primary function of the EU directive was to establish that no =
signature=20
  should be denied legal value solely because it was not based on a =
certain=20
  technology or met certain standards. The article 5 signature (often =
referred=20
  to as qualified signatures) are just a level of security that all =
member=20
  countries MUST accept as equivalent to hand-written signatures. I =
certainly=20
  agree that the content and intention of this directive has been highly =

  misunderstood.<o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'">The=20
  requirements on electronic invoicing comes from a totally separate=20
  directive.<o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'">However,=20
  I lack any specific technical proposal for this working group to =
consider in=20
  your e-mail. <o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'">In=20
  absence of such proposal, your mail appears to me more as a political=20
  manifesto.<o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
  <DIV>
  <P class=3DMsoNormal><B><SPAN lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: maroon; FONT-FAMILY: =
'Arial','sans-serif'">Stefan=20
  Santesson</SPAN></B><SPAN lang=3DEN-GB=20
  style=3D"COLOR: #1f497d"><o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: #400040; FONT-FAMILY: =
'Arial','sans-serif'">Senior=20
  Program Manager</SPAN><SPAN lang=3DEN-GB=20
  style=3D"COLOR: navy"><o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><B><SPAN lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: #400040; FONT-FAMILY: =
'Arial','sans-serif'">Windows=20
  Security, Standards</SPAN></B><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p></o:p></SPAN></P></DIV>
  <P class=3DMsoNormal><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
  <DIV=20
  style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0cm; BORDER-TOP: =
medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0cm; BORDER-LEFT: blue =
1.5pt solid; PADDING-TOP: 0cm; BORDER-BOTTOM: medium none">
  <DIV>
  <DIV=20
  style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0cm; BORDER-TOP: =
#b5c4df 1pt solid; PADDING-LEFT: 0cm; PADDING-BOTTOM: 0cm; BORDER-LEFT: =
medium none; PADDING-TOP: 3pt; BORDER-BOTTOM: medium none">
  <P class=3DMsoNormal><B><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
'Tahoma','sans-serif'">From:</SPAN></B><SPAN=20
  lang=3DEN-US style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
'Tahoma','sans-serif'">=20
  [e-mail] [mailto:[e-mail]] =
<B>On=20
  Behalf Of </B>Anders Rundgren<BR><B>Sent:</B> den 18 november 2008=20
  04:38<BR><B>To:</B> [e-mail]<BR><B>Subject:</B> The EU =
Signature=20
  Directive - A 15+15 Year Perspective<o:p></o:p></SPAN></P></DIV></DIV>
  <P class=3DMsoNormal><o:p>&nbsp;</o:p></P>
  <DIV>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">Some 15 =
years ago=20
  the EU launched a signature directive.&nbsp; This posting tries to =
describe=20
  the consequences of this directive with respect to usage of=20
  PKI.</SPAN><o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal>&nbsp;<o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal><STRONG><SPAN=20
  style=3D"FONT-FAMILY: 'Arial','sans-serif'">Primary=20
  Motivation</SPAN></STRONG><o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal>&nbsp;<o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">There are =
a number=20
  of processes&nbsp;needing a human-written signature in order to =
fulfill legal=20
  requirements.</SPAN><o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal>&nbsp;<o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">Some of =
these=20
  processes could without doubt be possible to carry out electronically =
and thus=20
  also remote over a network, if there was some kind of technology =
available=20
  that could serve as a replacement for a hand-written=20
  signature.</SPAN><o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal>&nbsp;<o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal><STRONG><SPAN style=3D"FONT-FAMILY: =
'Arial','sans-serif'">The=20
  Solution</SPAN></STRONG><o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal>&nbsp;<o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">Right or =
wrong,=20
  digital signatures using PKI were considered as&nbsp;a=20
  viable&nbsp;alternative.&nbsp; To make PKI a credible solution, the EU =

  signature directive added a number of requirements including =
characteristics=20
  of the signature creation device and policies for=20
  CAs.</SPAN><o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal>&nbsp;<o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal><STRONG><SPAN=20
  style=3D"FONT-FAMILY: 'Arial','sans-serif'">Current=20
  Deployment</SPAN></STRONG><o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal>&nbsp;<o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">Apart =
from=20
  Qualified Certificates which (for reasons too diverse for describing =
in an=20
  email) have not become truly mainstream, the EU signature directive =
have=20
  indeed in local legislations made it possible to perform fairly =
qualified=20
  tasks remotely over the Internet.&nbsp; I.e. the directive has =
functioned as=20
  an <STRONG><SPAN=20
  style=3D"FONT-FAMILY: =
'Arial','sans-serif'">ENABLER</SPAN></STRONG>.<o:p></o:p></SPAN></P></DIV=
>
  <DIV>
  <P class=3DMsoNormal>&nbsp;<o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal><STRONG><SPAN=20
  style=3D"FONT-FAMILY: 'Arial','sans-serif'">Then Something=20
  Went&nbsp;Wrong...</SPAN></STRONG><o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal>&nbsp;<o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
'Arial','sans-serif'">Unfortunately, a=20
  few (but&nbsp;influential) people got a bit carried away and =
interpreted the=20
  signature directive in way that has severely hampered the use of =
PKI.&nbsp;=20
  Essentially they began claiming that all messages in order to=20
  be&nbsp;trustworthy should be signed by a qualified signature or at =
least by a=20
  digital signature created&nbsp;under the direct control&nbsp;a human=20
  being.</SPAN><o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal>&nbsp;<o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">From a =
50000 ft=20
  perspective this may sound like a great idea, but the fact is that =
decades=20
  before the signature directive was conceived; yes, even before PKI was =

  invented, the concept of secure messaging actually =
existed.&nbsp;&nbsp;Back in=20
  those days&nbsp;secure messaging was facilitated through the use of =
leased=20
  lines which allowed banks (and some early b2b networks), to securely =
exchange=20
  transaction messages <EM><SPAN style=3D"FONT-FAMILY: =
'Arial','sans-serif'">in a=20
  completely automated fashion</SPAN></EM>.</SPAN><o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal>&nbsp;<o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">An =
example:&nbsp;=20
  If you want to wire-transfer money from your bank to another bank, the =
way the=20
  transfer is initiated (phone, paper,&nbsp;on-line, etc)&nbsp;has no =
impact on=20
  the transaction messaging because it is&nbsp;performed in a =
transaction=20
  network that neither the&nbsp;customers, nor&nbsp;most of the staff =
have=20
  direct access to.&nbsp;</SPAN><o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal>&nbsp;<o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
'Arial','sans-serif'">That&nbsp;such=20
  networks have proved to be secure, reliable, cost-efficient, and =
sometimes=20
  even globally scalable, apparently did not impress the bunch of =
hard-core=20
  signature experts who for example in Germany managed to make PKI a=20
  <STRONG><SPAN=20
  style=3D"FONT-FAMILY: 'Arial','sans-serif'">DISABLER</SPAN></STRONG> =
by=20
  outlawing non-human digital signatures on invoices.&nbsp; That German=20
  paper-invoices do not even require signatures&nbsp;makes this position =
a true=20
  mystery.</SPAN><o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal>&nbsp;<o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">One had =
hoped that=20
  this would be an exception to the rule but it is not; If you scan =
sites like=20
  NIST.GOV, CIO.GOV, and GSA.GOV you'll find literally thousands of=20
  security-related documents, indeed in a few places mentioning PKI, but =
mostly=20
  full of government regulation abbreviations like FISMA, giving little =
if any=20
  guidance on how to create secure messaging between agencies, not to =
mention=20
  between agencies and the private sector.</SPAN><o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal>&nbsp;<o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">I'm happy =
to=20
  see&nbsp;that the Nordic countries plus Estonia have realized that all =

  signatures that can be securely bound to an entity (in practice) are =
legally=20
  binding, in the extremely rare case somebody would actually repudiate =
a signed=20
  invoice.&nbsp;&nbsp; These governments have all (and independently of =
each=20
  other) created local variants of&nbsp;a scheme that I have described=20
  in:</SPAN><o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal><A =
href=3D"http://webpki.org/papers/web/gateway.pdf"><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
'Arial','sans-serif'">http://webpki.org/papers/web/gateway.pdf</SPAN></A>=
<o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
'Arial','sans-serif'">which&nbsp;could be=20
  characterized as&nbsp;a 21st century version of leased lines for=20
  multi-party&nbsp;automated secure =
messaging.</SPAN><o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">It will =
probably=20
  take another 15 years for this concept to achieve general acceptance =
although=20
  it is really (if you look closely) very similar&nbsp;to the US=20
  e-Authentication scheme, they have just not connected the dots =
yet:&nbsp;A=20
  SAML assertion and an server-signed&nbsp;invoice from a specific =
entity are=20
  essentially only different in content, not in=20
  trustworthiness.</SPAN><o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal>&nbsp;<o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">Anders=20
  Rundgren</SPAN><o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'"><A=20
  =
href=3D"http://WebPKI.org">http://WebPKI.org</A></SPAN><o:p></o:p></P></D=
IV>
  <DIV>
  <P class=3DMsoNormal>&nbsp;<o:p></o:p></P></DIV>
  <DIV>
  <P=20
class=3DMsoNormal>&nbsp;<o:p></o:p></P></DIV></DIV></DIV></BLOCKQUOTE></B=
ODY></HTML>

------=_NextPart_000_00BB_01C94A9B.EB774BA0--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAJ5I9GF099648 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Nov 2008 22:18:09 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAJ5I9E0099647; Tue, 18 Nov 2008 22:18:09 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-dub.microsoft.com (smtp-dub.microsoft.com [213.199.138.181]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAJ5HuIM099638 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Tue, 18 Nov 2008 22:18:08 -0700 (MST) (envelope-from [e-mail])
Received: from dub-exhub-c302.europe.corp.microsoft.com (65.53.213.92) by DUB-EXGWY-E802.partners.extranet.microsoft.com (10.251.129.2) with Microsoft SMTP Server (TLS) id 8.1.291.1; Wed, 19 Nov 2008 05:17:56 +0000
Received: from EA-EXMSG-C332.europe.corp.microsoft.com ([169.254.1.102]) by DUB-EXHUB-C302.europe.corp.microsoft.com ([65.53.213.92]) with mapi; Wed, 19 Nov 2008 05:17:55 +0000
From: Stefan Santesson <[e-mail]>
To: Stephen Farrell <[e-mail]>, Eric Norman <[e-mail]>
CC: "[e-mail]" <[e-mail]>
Date: Wed, 19 Nov 2008 05:17:48 +0000
Subject: RE: encoding an X.509 certificate
Thread-Topic: encoding an X.509 certificate
Thread-Index: AclJ4tfRP4e99N3hR1W5CFpPdj8LXQAIcYEg
Message-ID: <[e-mail]>
References: <[e-mail]> <p06240514c5474e7c5e53@[130.129.30.0]> <[e-mail]> <[e-mail]> <p06240502c5478a569750@[130.129.30.0]> <[e-mail]> <p06240511c5489dcf4568@[130.129.30.0]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
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>

Correct me if I'm wrong, but the core of this issue seems to be a scenario =
where a certificate is stored in some system. This system is ASN.1 aware an=
d for some reason refuse to store the certificate as is as a chunk of arbit=
rary bytes, but choose to decode the ASN.1 and store the inner data element=
s instead together with the signature. Once retrieved again, the system rea=
ssembles the certificate using its knowledge about ASN.1 and X.509 certific=
ates for the process. Unfortunately it deploys illegal encoding (BER or XXX=
ER) and delivers back a certificate where the associated signature no longe=
r matches the encoded certificate.

Russ seems to have encountered such system in a distant past.

But are there really any system with any significance around today that ope=
rates this way?
Somehow I have a hard time to believe there is.


Stefan Santesson
Senior Program Manager
Windows Security, Standards


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> On Behalf Of Stephen Farrell
> Sent: den 18 november 2008 18:39
> To: Eric Norman
> Cc: [e-mail]
> Subject: Re: encoding an X.509 certificate
>
>
>
>
> Eric Norman wrote:
> > Another personal opinion: in this particular case, some of the blame
> > for non-compliance rests with PKIX.  The requirement that serial
> > numbers be a positive INTEGER instead of an OCTET_STRING seems silly.
>
> Well, the field is an INTEGER and not an OCTET STRING so that choice
> isn't available (and if a mistake was made it happened in the 1980's).
>
> The positive integer thing was (as I recall) due to early CA code
> generating serials in various ways (e.g. via hashes) but then not
> encoding them correctly. I think it was that if the MSB was a 1
> and you don't add a 0x00 in front, then the serial is a negative
> and that caused problems for matching serial numbers for various
> bits of RP code.
>
> I think the positive integer restriction is fine. But it'd be no
> harm to generate an erratum for 5280 if you feel that the
> "SHOULD...gracefully" isn't  sufficiently clear.
>
> Stephen.
>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAJ3Jrkv094502 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Nov 2008 20:19:53 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAJ3JrUl094501; Tue, 18 Nov 2008 20:19:53 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mx1.myOutLookonline.com (mx1.myoutlookonline.com [69.25.74.49]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAJ3Jpki094494 for <[e-mail]>; Tue, 18 Nov 2008 20:19:52 -0700 (MST) (envelope-from [e-mail])
Received: from BE127.mail.lan ([10.109.208.127]) by mx1.myOutLookonline.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Nov 2008 22:19:51 -0500
Received: from mail pickup service by BE127.mail.lan with Microsoft SMTPSVC; Tue, 18 Nov 2008 22:19:44 -0500
Received: from Mx1.myoutlookonliNe.com ([10.9.35.235]) by BE114.mail.lan with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Nov 2008 17:15:24 -0500
Received: from mailout11.yourhostingaccount.com ([65.254.253.91]) by Mx1.myoutlookonliNe.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Nov 2008 17:15:24 -0500
Received: from mailscan11.yourhostingaccount.com ([10.1.15.11] helo=mailscan11.yourhostingaccount.com) by mailout11.yourhostingaccount.com with esmtp (Exim) id 1L2Yqx-0000nh-GS for [e-mail]; Tue, 18 Nov 2008 17:15:23 -0500
Received: from impinc01.yourhostingaccount.com ([10.1.13.101] helo=impinc01.yourhostingaccount.com) by mailscan11.yourhostingaccount.com with esmtp (Exim) id 1L2Yqx-00074w-DA for [e-mail]; Tue, 18 Nov 2008 17:15:23 -0500
Received: from balder-227.proper.com ([192.245.12.227]) by impinc01.yourhostingaccount.com with NO UCE id gmFN1a01o4tvYcG02mFNSW; Tue, 18 Nov 2008 17:15:23 -0500
X-EN-OrigIP: 192.245.12.227
X-EN-IMPSID: gmFN1a01o4tvYcG02mFNSW
Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAILo2ZW080334 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Nov 2008 14:50:02 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAILo2vH080333; Tue, 18 Nov 2008 14:50:02 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.carillon.ca (mail.carillon.ca [207.115.107.27]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAILnoTJ080264 for <[e-mail]>; Tue, 18 Nov 2008 14:50:00 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost [127.0.0.1]) by mail.carillon.ca (Postfix) with ESMTP id CE318328090 for <[e-mail]>; Tue, 18 Nov 2008 16:49:49 -0500 (EST)
Received: from mail.carillon.ca ([127.0.0.1]) by localhost (rhea.carillon.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TuZQdsY3mUPg for <[e-mail]>; Tue, 18 Nov 2008 16:49:44 -0500 (EST)
Received: from carillon.dcoombs.ca (69-196-152-118.dsl.teksavvy.com [69.196.152.118]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.carillon.ca (Postfix) with ESMTP id 2358132801B for <[e-mail]>; Tue, 18 Nov 2008 16:49:44 -0500 (EST)
From: Patrick Patterson <[e-mail]>
Reply-To: [e-mail]
Organization: Carillon Information Security Inc.
To: [e-mail]
Subject: Re: The EU Signature Directive - A 15+15 Year Perspective
Date: Tue, 18 Nov 2008 16:49:27 -0500
User-Agent: KMail/1.9.10
References: <1E0ECAB75B5B496F942BC7D49F9D7DA5@AndersPC> <[e-mail]> <C515607EF9594962B192C59A8D711456@AndersPC>
In-Reply-To: <C515607EF9594962B192C59A8D711456@AndersPC>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-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: 18 Nov 2008 22:15:24.0513 (UTC) FILETIME=[2768AD10:01C949CB]
Sender: [e-mail]
Precedence: 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 November 18, 2008 12:55:57 pm Anders Rundgren wrote:
> Hi Patrick,
>
> <snip>
>
> >As an aside, this is one of the reasons that in the Aerospace industry,
> > we're working on the concept of "Organisational" certificates (PKI analog
> > to the corporate seal).
>
> That's interesting and VERY GOOD news!  I thought the Aerospace industry
> spent their PKI money on [IMO] rather awkward Bridge CA stuff like
> http://certipath.com which I consider the opposite to Organizational
> certificates since Bridge CAs is typically rather about extending the reach
> of (existing) employee certificates.
>
Well, I'll let Santosh ring in on this if he wants, but the I can say that 
most of the companies with which I am familiar have had to implement or beef 
up their "existing" PKI infrastructures to comply with the much more rigorous 
and standardised requirements of joining the Bridge, thus facilitating, 
within the community at least, the establishment of Trust "more than a few 
blocks away from your own backyard" :)

> >It neatly side-steps the mental block that some people have regarding
> >"one person, one key", and allows anyone who is authorized to "sign
> >on behalf of the company" to use the PKI based corporate seal.
>
> Apart from possible mental blocks, there are other quite down-to-earth
> hurdles as well: 
> a.. Employees come and go => Your "digital handles" to 
> other companies easily get invalid 

That is why the Corporate Seal (you know - the one that is a physical piece of 
hardware, is kept in a safe, and is only let out by the corporate lawyers for 
defined and logged purposes) is a usefull concept to translate into the 
Digital Credential (read PKI) realm. Since the Certificate is issued to the 
corporate legal body, and not any particular physical person, it doesn't 
suffer from the same problems as "personal" certificates.

> b.. How do you automatically and 
> securely correlate a company identity as expressed in business messages
> with a PKI-based employee identity, and preferably make that scale a few
> blocks from of your own backyard? 

Is this is somewhat dependant on both the messaging format, and the trust and 
policy infrastructure that you place on the Organisational issuing practices? 

Not to get into any dogmatic debates, but by leveraging the Bridge within the 
community, we believe that this can allow the trust in the Org certs to be 
validated to quite a rigorous level.

> c.. That VeriSign's SSL PKI reaches out 
> over the entire globe, while employee PKIs (be it PIV or just your local
> stuff) typically is unknown at 99.99% of all places, indicates that the
> employee PKI model suffers from pretty serious trust establishment issues

Ok - now you're tickling one of my favourite points of discussion. The entire 
idea behind the PKI framework being worked on within the Aerospace industry 
is that it is meant to be only for within the industry. As I tell my clients, 
if you want a certificate for a web portal that is B2C focused (i.e.: for 
John Q. Public to access and interact with) then buy a Verisign (or 
equivalent) SSL certificate. If you want a certificate for 
inter-industry "closed community" collaboration (B2B within the closed 
community that is an aerospace program or project), then use a certificate 
from a CA that is cross-certified with CertiPath. Within the industry, we 
have worked out solutions for trust anchor establishment (although if more 
people did PDVAL correctly, it would make it even easier:), so we're not 
interested in propagating each individual companies CA Trust Anchor to 
millions of non-affiliated entities. In the ideal case (where the platforms 
that we work on do PDVAL correctly), each company would only propagate it's 
own trust anchor to its internal systems (trivial with such mechanisms as AD 
group policies), and let the pdval tools do their jobs when presented with 
a "external" certificate. If that external cert can "cross the bridge", then 
we're fine. If it can't, then don't trust it.

> d.. Privacy concerns.  Who (in the organization) actually orders goods is
> not necessarily something the seller needs to know.  In fact, employment is
> not public information Regarding who is authorized "to sign on behalf of
> the company", I believe that such certificates should only to be used for
> secure messaging which means that they are installed in gateway servers
> and/or information systems.  The purpose of such signatures is supporting
> authenticity and message integrity, while "consent" and "authorization" are
> things that typically stay inside of the company.  This is at least how
> bank transaction networks operate.
>

Ok - we've got a slightly different view on this point - the precise point of 
Org certs is to act as the digital equivalent of the corporate seal, which is 
the legacy mechanism for engaging the corporation in some sort of contract, 
liability, or promise - eg.: Signature.

The way that I see it, the EV SSL certs that are currently being espoused 
today are probably sufficient to convey the identity assurance that would be 
required for gateway messaging servers - for us to develop an industry 
specific solution that would compete with this would subject us to precisely 
the concerns that you had in b) and c).

> In addition, company certificates open the road for even more sophisticated
> security schemes which I have briefly covered on the last page of:
> http://webpki.org/papers/web/gateway.pdf
>
I've not read your paper yet, but I'll add it to my list :)

-- 
Patrick Patterson
President and Chief PKI Architect,
Carillon Information Security Inc.
http://www.carillon.ca



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAJ3Iv4Q094473 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Nov 2008 20:18:57 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAJ3IvAW094472; Tue, 18 Nov 2008 20:18:57 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mx1.myOutLookonline.com (mx1.myoutlookonline.com [69.25.74.49]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAJ3Ijdl094459 for <[e-mail]>; Tue, 18 Nov 2008 20:18:56 -0700 (MST) (envelope-from [e-mail])
Received: from BE127.mail.lan ([10.109.208.127]) by mx1.myOutLookonline.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Nov 2008 22:18:45 -0500
Received: from mail pickup service by BE127.mail.lan with Microsoft SMTPSVC; Tue, 18 Nov 2008 22:18:02 -0500
Received: from Mx1.myoutlookonliNe.com ([10.9.35.235]) by BE114.mail.lan with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Nov 2008 18:55:02 -0500
Received: from mailout11.yourhostingaccount.com ([65.254.253.91]) by Mx1.myoutlookonliNe.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Nov 2008 18:55:02 -0500
Received: from mailscan02.yourhostingaccount.com ([10.1.15.2] helo=mailscan02.yourhostingaccount.com) by mailout11.yourhostingaccount.com with esmtp (Exim) id 1L2aPN-0001Y3-P7 for [e-mail]; Tue, 18 Nov 2008 18:55:01 -0500
Received: from impinc05.yourhostingaccount.com ([10.1.13.105] helo=impinc05.yourhostingaccount.com) by mailscan02.yourhostingaccount.com with esmtp (Exim) id 1L2aPM-0007SP-DA for [e-mail]; Tue, 18 Nov 2008 18:55:00 -0500
Received: from balder-227.proper.com ([192.245.12.227]) by impinc05.yourhostingaccount.com with NO UCE id gnuz1a01w4tvYcG03nv0gF; Tue, 18 Nov 2008 18:55:00 -0500
X-EN-OrigIP: 192.245.12.227
X-EN-IMPSID: gnuz1a01w4tvYcG03nv0gF
Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAINOEjM084428 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Nov 2008 16:24:14 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAINOEqS084427; Tue, 18 Nov 2008 16:24:14 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from eb2bcom.com (eb2bcom.com [72.232.34.13]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAINO35O084416 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 18 Nov 2008 16:24:13 -0700 (MST) (envelope-from [e-mail])
Received: from 202.164.192.219.static.rev.aanet.com.au ([202.164.192.219] helo=[192.168.99.100]) by host.eb2bcom.com with esmtpa (Exim 4.69) (envelope-from <[e-mail]>) id 1L2ZvJ-0006lx-0A; Wed, 19 Nov 2008 10:23:57 +1100
Message-ID: <[e-mail]>
Date: Wed, 19 Nov 2008 10:23:51 +1100
From: Steven Legg <[e-mail]>
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: Tom Gindin <[e-mail]>
CC: Stephen Kent <[e-mail]>, [e-mail]
Subject: Re: encoding an X.509 certificate
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - host.eb2bcom.com
X-AntiAbuse: Original Domain - imc.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - eb2bcom.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
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: 18 Nov 2008 23:55:02.0456 (UTC) FILETIME=[128A6380:01C949D9]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tom,

Tom Gindin wrote:
>         Steve:
> 
>         As a theoretical exercise, let us assume that a relying party 
> encounters the following encoding as part of the value of a non-critical 
> extension with syntax unknown to the relying party: A1 13 16 03 4F 6E 65 
> 16 07 45 78 61 6D 70 6C 65 16 03 4E 6F 77.
>         How can the relying party tell whether this is a valid DER 
> encoding of [1] IMPLICIT SEQUENCE OF PrintableString, an encoding of [1] 
> IMPLICIT PrintableString which violates section 10.2 of X.690, or an 
> encoding of [1] IMPLICIT SET OF PrintableString which violates section 
> 11.6 of X.690?  The component string values are "One", "Example", and 
> "Now".
>         I am not convinced that "re-encode as DER" can be performed by 
> general purpose library code.

I'm convinced that it cannot in the general case. You've touched on the
main problem, which is that it is necessary to have perfect knowledge of
the ASN.1 type of an abstract value in order to be able to correctly
re-encode the value in a different set of encoding rules (including the
canonical version of the original encoding). For signed operations in
X.500, for example, it isn't practical to have complete knowledge of the
ASN.1 type of every part of an operation. It's for that reason that X.509
has this to say at the end of clause 6.1:

     The Directory shall follow these rules:

         – It shall preserve the encoding of received information whose
           abstract syntax it does not fully know and which it expects to
           subsequently sign;

         – When signing data for sending, it shall send data whose syntax
           it fully knows with a distinguished encoding and any other data
           with its preserved encoding, and shall sign the actual encoding
           it sends;

         – When checking signatures in received data, it shall check the
           signature against the actual data received rather than its
           conversion of the received data to a distinguished encoding.

Even when the ASN.1 type is fully known, there are still problems. For
one, the DER canonicalization rules for TeletexString are woefully
inadequate. If a BER or DER encoding containing TeletexString values
is re-encoded in, say, XER, which transcodes into UTF-8, then there is
no guarantee that the original encoding will be recoverable. Add to that,
that implementations of TeletexString encoding are often limited and/or
technically non-conformant. If implementors can't get TeletexString right
then they won't be able to get TeletexString canonicalization rules right
either (if they exist at some point in the future). Another problem is
that canonicalization of local time for GeneralizedTime is broken.

As a solution, signing what one sends and preserving what one receives
is simpler to implement, easier to get right, more efficient, and
free of the gotcha's that plague canonical encodings, so why do we
persist with canonical encodings ?

Regards,
Steven

> One can verify that the certificate down to 
> the OCTET STRING wrappings for extension values is in DER, but one cannot 
> always tell whether the inner values of extensions are in DER, let alone 
> re-encode them into DER.
> 
>                 Tom Gindin
> 
> P.S - The above opinions (and those in my last post as well) are mine and 
> not necessarily those of my employer
> 
> 
> 
> 
> Stephen Kent <[e-mail]> 
> 11/17/2008 11:40 AM
> 
> To
> Tom Gindin/Watson/IBM@IBMUS
> cc
> "Timothy J. Miller" <[e-mail]>, [e-mail], 
> [e-mail], Peter Gutmann <[e-mail]>
> Subject
> Re: encoding an X.509 certificate
> 
> 
> 
> 
> 
> 
> At 8:22 PM -0500 11/12/08, Tom Gindin wrote:
>>         "Conservative in what you produce" - CA code should generate 
> DER.
>> Not all such code does so, but it should.
>>         "Liberal in what you accept" - RP code should verify signatures 
> on
>> the supplied binary TBSCertificate, rather than re-encoding.  For parsing
>> code to accept BER which isn't valid DER is almost harmless.    There may
>> well have been a good reason for believing that DER was more secure than
>> BER against various digest collision or pre-image attacks when X.509v1 
> was
>> in use and all certificate content had syntax verifiable by every RP (at
>> least in theory).  With non-critical extensions, that is no longer the
>> case.
>>
>>                 Tom Gindin
> 
> Tom,
> 
> I have to disagree. The standards call for DER to be used for 
> signature generation and validation. They are generally silent on 
> transport encoding. If we say that an RP should just try to verify 
> the signature on whatever it receives, then we encourage (more) 
> sloppy behavior by CAs. The preferred approach is for the RP to 
> encode the received cert into DER before checking.
> 
> Steve
> 
> 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAJ0k9Gr088115 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Nov 2008 17:46:09 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAJ0k9bV088114; Tue, 18 Nov 2008 17:46:09 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-dub.microsoft.com (smtp-dub.microsoft.com [213.199.138.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAJ0jvLj088102 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Tue, 18 Nov 2008 17:46:08 -0700 (MST) (envelope-from [e-mail])
Received: from DUB-EXHUB-C301.europe.corp.microsoft.com (65.53.213.91) by DUB-EXGWY-E801.partners.extranet.microsoft.com (10.251.129.1) with Microsoft SMTP Server (TLS) id 8.1.291.1; Wed, 19 Nov 2008 00:45:56 +0000
Received: from EA-EXMSG-C332.europe.corp.microsoft.com ([169.254.1.102]) by DUB-EXHUB-C301.europe.corp.microsoft.com ([65.53.213.91]) with mapi; Wed, 19 Nov 2008 00:45:56 +0000
From: Stefan Santesson <[e-mail]>
To: Mike <[e-mail]>, "[e-mail]" <[e-mail]>
Date: Wed, 19 Nov 2008 00:45:50 +0000
Subject: RE: Robustness principle
Thread-Topic: Robustness principle
Thread-Index: AclJ2koxPynT4sssQmqVZIyv57OLqAABRfxw
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
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>

I would say that it is impossible to successfully generalize what an approp=
riate behavior is.
What is reasonable in one situation and context is not reasonable in anothe=
r.

No matter what we say, implementers will do what best serves their customer=
s and their own business.

Stefan Santesson
Senior Program Manager
Windows Security, Standards


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> On Behalf Of Mike
> Sent: den 18 november 2008 17:25
> To: [e-mail]
> Subject: Re: Robustness principle
>
>
> > If signature verification on "as is" fails, but succeeds for DER
> > encoded, what harm do you see in saving, using and relaying DER
> encoded?
>
> Saving and using the fixed version for your own purposes is fine, but
> you shouldn't pass it along.  If re-encoding the certificate renders
> it valid, then somewhere along the way somebody broke it.  That broken
> software needs to be fixed, so if you don't pass along the fixed
> version, discovering where the problem is will be much easier, and
> there will be more unhappy people to pressure them for a fix.  As an
> engineer I understand that it may be easier to just add a little code
> to work around a problem.  Then you end up with something like SSLv2
> with so many little workarounds that are not in any document which
> make it nearly impossible to implement (and interoperate).  Fortunately
> SSLv2 can now be considered historical.
>
> Mike
>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAJ0dvNX087859 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Nov 2008 17:39:57 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAJ0dv8J087858; Tue, 18 Nov 2008 17:39:57 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from services.meeting.ietf.org (smtp.meeting.ietf.org [130.129.5.10]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAJ0dkVo087846 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 18 Nov 2008 17:39:57 -0700 (MST) (envelope-from [e-mail])
Received: from [130.129.78.129] ([130.129.78.129]) by services.meeting.ietf.org (8.14.2/8.14.2) with ESMTP id mAJ0dbGN031959 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Wed, 19 Nov 2008 00:39:39 GMT (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Wed, 19 Nov 2008 00:39:21 +0000
From: Stephen Farrell <[e-mail]>
User-Agent: Thunderbird 2.0.0.16 (X11/20080707)
MIME-Version: 1.0
To: Eric Norman <[e-mail]>
CC: [e-mail]
Subject: Re: encoding an X.509 certificate
References: <[e-mail]> <p06240514c5474e7c5e53@[130.129.30.0]> <[e-mail]> <[e-mail]> <p06240502c5478a569750@[130.129.30.0]> <[e-mail]> <p06240511c5489dcf4568@[130.129.30.0]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset=ISO-8859-1
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>

Eric Norman wrote:
> Another personal opinion: in this particular case, some of the blame
> for non-compliance rests with PKIX.  The requirement that serial
> numbers be a positive INTEGER instead of an OCTET_STRING seems silly.

Well, the field is an INTEGER and not an OCTET STRING so that choice
isn't available (and if a mistake was made it happened in the 1980's).

The positive integer thing was (as I recall) due to early CA code
generating serials in various ways (e.g. via hashes) but then not
encoding them correctly. I think it was that if the MSB was a 1
and you don't add a 0x00 in front, then the serial is a negative
and that caused problems for matching serial numbers for various
bits of RP code.

I think the positive integer restriction is fine. But it'd be no
harm to generate an erratum for 5280 if you feel that the
"SHOULD...gracefully" isn't  sufficiently clear.

Stephen.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAJ0On25087346 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Nov 2008 17:24:49 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAJ0OnAJ087345; Tue, 18 Nov 2008 17:24:49 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp182.sat.emailsrvr.com (smtp182.sat.emailsrvr.com [66.216.121.182]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAJ0OcIn087332 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 18 Nov 2008 17:24:48 -0700 (MST) (envelope-from [e-mail])
Received: from relay8.relay.sat.mlsrvr.com (localhost [127.0.0.1]) by relay8.relay.sat.mlsrvr.com (SMTP Server) with ESMTP id D08A61CF191; Tue, 18 Nov 2008 19:24:37 -0500 (EST)
Received: by relay8.relay.sat.mlsrvr.com (Authenticated sender: swilson-AT-lockstep.com.au) with ESMTP id ABF9E1CF37F; Tue, 18 Nov 2008 19:24:36 -0500 (EST)
Message-ID: <[e-mail]>
Date: Wed, 19 Nov 2008 11:23:47 +1100
From: Stephen Wilson <[e-mail]>
Reply-To: [e-mail]
Organization: Lockstep
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: Anders Rundgren <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: The EU Signature Directive - A 15+15 Year Perspective
References: <1E0ECAB75B5B496F942BC7D49F9D7DA5@AndersPC> <[e-mail]> <3F7D87D9792849A28D560DC8341AC63F@AndersPC> <[e-mail]> <C515607EF9594962B192C59A8D711456@AndersPC>
In-Reply-To: <C515607EF9594962B192C59A8D711456@AndersPC>
Content-Type: text/plain; charset=UTF-8; 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>

Anders Rundgren wrote:
> 	... VeriSign's SSL PKI reaches out over the entire globe, while
>       employee PKIs (be it PIV or just your local stuff) typically is
>       unknown at 99.99% of all places, indicates that the employee PKI
>       model suffers from pretty serious trust establishment issues

This is another red herring.  It tells us nothing true or deep about the 
effectiveness of individual certificates.  The fact that employee PKIs 
don't have global reach is hardly surprising.  To begin with, global 
recognition of *employees* outside the enterprise is not usually 
important!  Look at the J&J corporate PKI; seems to be working great 
with 100,000+ individuals.

But more importantly, successful PKIs are always application specific. 
[BTW the application-specificity of SSL server certificates is really 
one of their most salient features, but almost always overlooked when 
people try to draw lessons form SSL's success!]  The reach problem that 
so concerns Anders is really only a matter of root key distribution. 
With application specific PKI, where 9 times out of 10 the transacting 
parties run special software (healthcare apps, conveyancing, trade 
documentation management, Skype etc etc), root key distribution is 
trivial.

Cheers,

Steve Wilson.




Managing Director
Lockstep Technologies

Phone [phone]

www.lockstep.com.au/technologies
-------------------
  * ABC TV 'The New Inventors' Nov 2008
  * Global Security Challenge Asia Top Five 2008
  * Australian Technology Showcase 2008
  * AusIndustry COMET Grant 2007
  * ICT Secrets of Innovation Finalist (Security) 2007
  * Anthill / PwC Cool Company Finalist (Innovation) 2007
-------------------
Lockstep Technologies develops unique new smart ID solutions to
safeguard identity and privacy. Lockstep Consulting provides
independent specialist advice and analysis on authentication, PKI
and smartcards.




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAINrMFw085365 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Nov 2008 16:53:22 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAINrMwg085364; Tue, 18 Nov 2008 16:53:22 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from agogare.doit.wisc.edu (agogare.doit.wisc.edu [144.92.197.211]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAINrBRS085358 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL) for <[e-mail]>; Tue, 18 Nov 2008 16:53:22 -0700 (MST) (envelope-from [e-mail])
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; charset=US-ASCII; format=flowed
Received: from avs-daemon.smtpauth2.wiscmail.wisc.edu by smtpauth2.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 6.3-6.03 (built Mar 14 2008; 32bit)) id <[e-mail]> for [e-mail]; Tue, 18 Nov 2008 17:53:10 -0600 (CST)
Received: from [192.168.0.14] (static.unknown.charter.com [97.92.189.144]) by smtpauth2.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 6.3-6.03 (built Mar 14 2008; 32bit)) with ESMTPSA id <[e-mail]> for [e-mail]; Tue, 18 Nov 2008 17:53:09 -0600 (CST)
Date: Tue, 18 Nov 2008 17:53:08 -0600
From: Eric Norman <[e-mail]>
Subject: Re: encoding an X.509 certificate
In-reply-to: <[e-mail]>
To: [e-mail]
Message-id: <[e-mail]>
X-Mailer: Apple Mail (2.624)
X-Spam-Report: AuthenticatedSender=yes, SenderIP=97.92.189.144
X-Spam-PmxInfo: Server=avs-9, Version=5.4.1.325704, Antispam-Engine: 2.6.0.325393, Antispam-Data: 2008.11.18.234321, SenderIP=97.92.189.144
References: <[e-mail]> <p06240514c5474e7c5e53@[130.129.30.0]> <[e-mail]> <[e-mail]> <p06240502c5478a569750@[130.129.30.0]> <[e-mail]> <p06240511c5489dcf4568@[130.129.30.0]> <[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>

On Nov 18, 2008, at 10:50 AM, Julien Stern wrote:

> as a side note, while it may already implicitly be the case, a 
> strongly worded statement by PKIX that implementations should reject 
> all these "bogus" certificates (in BER, with negative serials, without 
> critical extensions when they have to be, etc) would certainly help 
> smaller vendors to "plead their cause" when they are told that their 
> software "do not work" (well, if there is indeed a consensus on this 
> statement, of course).

As to serial numbers, RFC 5280 already says this:

    Note: Non-conforming CAs may issue certificates with serial numbers
    that are negative or zero.  Certificate users SHOULD be prepared to
    gracefully handle such certificates.

If the intent is that "SHOULD ... gracefully" means that the certificate
must be rejected, then it would be a good idea to say that.  If the
meaning of "SHOULD .. gracefully" is that the robustness principle is
applicable, then it would be a good idea to say so.

Another personal opinion: in this particular case, some of the blame
for non-compliance rests with PKIX.  The requirement that serial
numbers be a positive INTEGER instead of an OCTET_STRING seems silly.

Eric Norman




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAINPCmW084487 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Nov 2008 16:25:12 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAINPCtA084486; Tue, 18 Nov 2008 16:25:12 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sasl.smtp.pobox.com (a-sasl-fastnet.sasl.smtp.pobox.com [207.106.133.19]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAINP1dF084476 for <[e-mail]>; Tue, 18 Nov 2008 16:25:11 -0700 (MST) (envelope-from [e-mail])
Received: from localhost.localdomain (unknown [127.0.0.1]) by a-sasl-fastnet.sasl.smtp.pobox.com (Postfix) with ESMTP id 49C3E7FB88 for <[e-mail]>; Tue, 18 Nov 2008 18:25:00 -0500 (EST)
Received: from [192.168.1.8] (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-sasl-fastnet.sasl.smtp.pobox.com (Postfix) with ESMTPSA id E3B447FB87 for <[e-mail]>; Tue, 18 Nov 2008 18:24:55 -0500 (EST)
Message-ID: <[e-mail]>
Date: Tue, 18 Nov 2008 15:25:26 -0800
From: Mike <[e-mail]>
User-Agent: Thunderbird 2.0.0.16 (Windows/20080708)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Robustness principle
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Pobox-Relay-ID: 1EA04A26-B5C8-11DD-AA81-9CEDC82D7133-38729857!a-sasl-fastnet.pobox.com
Sender: [e-mail]
Precedence: 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 signature verification on "as is" fails, but succeeds for DER
> encoded, what harm do you see in saving, using and relaying DER encoded?

Saving and using the fixed version for your own purposes is fine, but
you shouldn't pass it along.  If re-encoding the certificate renders
it valid, then somewhere along the way somebody broke it.  That broken
software needs to be fixed, so if you don't pass along the fixed
version, discovering where the problem is will be much easier, and
there will be more unhappy people to pressure them for a fix.  As an
engineer I understand that it may be easier to just add a little code
to work around a problem.  Then you end up with something like SSLv2
with so many little workarounds that are not in any document which
make it nearly impossible to implement (and interoperate).  Fortunately
SSLv2 can now be considered historical.

Mike



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAINOEjM084428 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Nov 2008 16:24:14 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAINOEqS084427; Tue, 18 Nov 2008 16:24:14 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from eb2bcom.com (eb2bcom.com [72.232.34.13]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAINO35O084416 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 18 Nov 2008 16:24:13 -0700 (MST) (envelope-from [e-mail])
Received: from 202.164.192.219.static.rev.aanet.com.au ([202.164.192.219] helo=[192.168.99.100]) by host.eb2bcom.com with esmtpa (Exim 4.69) (envelope-from <[e-mail]>) id 1L2ZvJ-0006lx-0A; Wed, 19 Nov 2008 10:23:57 +1100
Message-ID: <[e-mail]>
Date: Wed, 19 Nov 2008 10:23:51 +1100
From: Steven Legg <[e-mail]>
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: Tom Gindin <[e-mail]>
CC: Stephen Kent <[e-mail]>, [e-mail]
Subject: Re: encoding an X.509 certificate
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - host.eb2bcom.com
X-AntiAbuse: Original Domain - imc.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - eb2bcom.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tom,

Tom Gindin wrote:
>         Steve:
> 
>         As a theoretical exercise, let us assume that a relying party 
> encounters the following encoding as part of the value of a non-critical 
> extension with syntax unknown to the relying party: A1 13 16 03 4F 6E 65 
> 16 07 45 78 61 6D 70 6C 65 16 03 4E 6F 77.
>         How can the relying party tell whether this is a valid DER 
> encoding of [1] IMPLICIT SEQUENCE OF PrintableString, an encoding of [1] 
> IMPLICIT PrintableString which violates section 10.2 of X.690, or an 
> encoding of [1] IMPLICIT SET OF PrintableString which violates section 
> 11.6 of X.690?  The component string values are "One", "Example", and 
> "Now".
>         I am not convinced that "re-encode as DER" can be performed by 
> general purpose library code.

I'm convinced that it cannot in the general case. You've touched on the
main problem, which is that it is necessary to have perfect knowledge of
the ASN.1 type of an abstract value in order to be able to correctly
re-encode the value in a different set of encoding rules (including the
canonical version of the original encoding). For signed operations in
X.500, for example, it isn't practical to have complete knowledge of the
ASN.1 type of every part of an operation. It's for that reason that X.509
has this to say at the end of clause 6.1:

     The Directory shall follow these rules:

         – It shall preserve the encoding of received information whose
           abstract syntax it does not fully know and which it expects to
           subsequently sign;

         – When signing data for sending, it shall send data whose syntax
           it fully knows with a distinguished encoding and any other data
           with its preserved encoding, and shall sign the actual encoding
           it sends;

         – When checking signatures in received data, it shall check the
           signature against the actual data received rather than its
           conversion of the received data to a distinguished encoding.

Even when the ASN.1 type is fully known, there are still problems. For
one, the DER canonicalization rules for TeletexString are woefully
inadequate. If a BER or DER encoding containing TeletexString values
is re-encoded in, say, XER, which transcodes into UTF-8, then there is
no guarantee that the original encoding will be recoverable. Add to that,
that implementations of TeletexString encoding are often limited and/or
technically non-conformant. If implementors can't get TeletexString right
then they won't be able to get TeletexString canonicalization rules right
either (if they exist at some point in the future). Another problem is
that canonicalization of local time for GeneralizedTime is broken.

As a solution, signing what one sends and preserving what one receives
is simpler to implement, easier to get right, more efficient, and
free of the gotcha's that plague canonical encodings, so why do we
persist with canonical encodings ?

Regards,
Steven

> One can verify that the certificate down to 
> the OCTET STRING wrappings for extension values is in DER, but one cannot 
> always tell whether the inner values of extensions are in DER, let alone 
> re-encode them into DER.
> 
>                 Tom Gindin
> 
> P.S - The above opinions (and those in my last post as well) are mine and 
> not necessarily those of my employer
> 
> 
> 
> 
> Stephen Kent <[e-mail]> 
> 11/17/2008 11:40 AM
> 
> To
> Tom Gindin/Watson/IBM@IBMUS
> cc
> "Timothy J. Miller" <[e-mail]>, [e-mail], 
> [e-mail], Peter Gutmann <[e-mail]>
> Subject
> Re: encoding an X.509 certificate
> 
> 
> 
> 
> 
> 
> At 8:22 PM -0500 11/12/08, Tom Gindin wrote:
>>         "Conservative in what you produce" - CA code should generate 
> DER.
>> Not all such code does so, but it should.
>>         "Liberal in what you accept" - RP code should verify signatures 
> on
>> the supplied binary TBSCertificate, rather than re-encoding.  For parsing
>> code to accept BER which isn't valid DER is almost harmless.    There may
>> well have been a good reason for believing that DER was more secure than
>> BER against various digest collision or pre-image attacks when X.509v1 
> was
>> in use and all certificate content had syntax verifiable by every RP (at
>> least in theory).  With non-critical extensions, that is no longer the
>> case.
>>
>>                 Tom Gindin
> 
> Tom,
> 
> I have to disagree. The standards call for DER to be used for 
> signature generation and validation. They are generally silent on 
> transport encoding. If we say that an RP should just try to verify 
> the signature on whatever it receives, then we encourage (more) 
> sloppy behavior by CAs. The preferred approach is for the RP to 
> encode the received cert into DER before checking.
> 
> Steve
> 
> 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAIMfuJU082699 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Nov 2008 15:41:56 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAIMfuG6082698; Tue, 18 Nov 2008 15:41:56 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-dub.microsoft.com (smtp-dub.microsoft.com [213.199.138.181]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAIMfsiF082692 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Tue, 18 Nov 2008 15:41:55 -0700 (MST) (envelope-from [e-mail])
Received: from DUB-EXHUB-C301.europe.corp.microsoft.com (65.53.213.91) by DUB-EXGWY-E802.partners.extranet.microsoft.com (10.251.129.2) with Microsoft SMTP Server (TLS) id 8.1.291.1; Tue, 18 Nov 2008 22:41:53 +0000
Received: from EA-EXMSG-C332.europe.corp.microsoft.com ([169.254.1.102]) by DUB-EXHUB-C301.europe.corp.microsoft.com ([65.53.213.91]) with mapi; Tue, 18 Nov 2008 22:41:53 +0000
From: Stefan Santesson <[e-mail]>
To: Anders Rundgren <[e-mail]>, "[e-mail]" <[e-mail]>
Date: Tue, 18 Nov 2008 22:41:47 +0000
Subject: RE: The EU Signature Directive - A 15+15 Year Perspective
Thread-Topic: The EU Signature Directive - A 15+15 Year Perspective
Thread-Index: AclJbr80xd4QFFQITm6bz/kIlpQgpQAXuhjg
Message-ID: <[e-mail]>
References: <1E0ECAB75B5B496F942BC7D49F9D7DA5@AndersPC>
In-Reply-To: <1E0ECAB75B5B496F942BC7D49F9D7DA5@AndersPC>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_9F11911AED01D24BAA1C2355723C3D321AB0CF72DCEAEXMSGC332eu_"
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>

--_000_9F11911AED01D24BAA1C2355723C3D321AB0CF72DCEAEXMSGC332eu_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Anders,

On the factual side, the EU signature directive was adopted 1999, which is =
9 years ago and not 15.
Further, the primary function of the EU directive was to establish that no =
signature should be denied legal value solely because it was not based on a=
 certain technology or met certain standards. The article 5 signature (ofte=
n referred to as qualified signatures) are just a level of security that al=
l member countries MUST accept as equivalent to hand-written signatures. I =
certainly agree that the content and intention of this directive has been h=
ighly misunderstood.

The requirements on electronic invoicing comes from a totally separate dire=
ctive.

However, I lack any specific technical proposal for this working group to c=
onsider in your e-mail.
In absence of such proposal, your mail appears to me more as a political ma=
nifesto.


Stefan Santesson
Senior Program Manager
Windows Security, Standards

From: [e-mail] [mailto:[e-mail]] On=
 Behalf Of Anders Rundgren
Sent: den 18 november 2008 04:38
To: [e-mail]
Subject: The EU Signature Directive - A 15+15 Year Perspective

Some 15 years ago the EU launched a signature directive.  This posting trie=
s to describe the consequences of this directive with respect to usage of P=
KI.

Primary Motivation

There are a number of processes needing a human-written signature in order =
to fulfill legal requirements.

Some of these processes could without doubt be possible to carry out electr=
onically and thus also remote over a network, if there was some kind of tec=
hnology available that could serve as a replacement for a hand-written sign=
ature.

The Solution

Right or wrong, digital signatures using PKI were considered as a viable al=
ternative.  To make PKI a credible solution, the EU signature directive add=
ed a number of requirements including characteristics of the signature crea=
tion device and policies for CAs.

Current Deployment

Apart from Qualified Certificates which (for reasons too diverse for descri=
bing in an email) have not become truly mainstream, the EU signature direct=
ive have indeed in local legislations made it possible to perform fairly qu=
alified tasks remotely over the Internet.  I.e. the directive has functione=
d as an ENABLER.

Then Something Went Wrong...

Unfortunately, a few (but influential) people got a bit carried away and in=
terpreted the signature directive in way that has severely hampered the use=
 of PKI.  Essentially they began claiming that all messages in order to be =
trustworthy should be signed by a qualified signature or at least by a digi=
tal signature created under the direct control a human being.

>From a 50000 ft perspective this may sound like a great idea, but the fact =
is that decades before the signature directive was conceived; yes, even bef=
ore PKI was invented, the concept of secure messaging actually existed.  Ba=
ck in those days secure messaging was facilitated through the use of leased=
 lines which allowed banks (and some early b2b networks), to securely excha=
nge transaction messages in a completely automated fashion.

An example:  If you want to wire-transfer money from your bank to another b=
ank, the way the transfer is initiated (phone, paper, on-line, etc) has no =
impact on the transaction messaging because it is performed in a transactio=
n network that neither the customers, nor most of the staff have direct acc=
ess to.

That such networks have proved to be secure, reliable, cost-efficient, and =
sometimes even globally scalable, apparently did not impress the bunch of h=
ard-core signature experts who for example in Germany managed to make PKI a=
 DISABLER by outlawing non-human digital signatures on invoices.  That Germ=
an paper-invoices do not even require signatures makes this position a true=
 mystery.

One had hoped that this would be an exception to the rule but it is not; If=
 you scan sites like NIST.GOV, CIO.GOV, and GSA.GOV you'll find literally t=
housands of security-related documents, indeed in a few places mentioning P=
KI, but mostly full of government regulation abbreviations like FISMA, givi=
ng little if any guidance on how to create secure messaging between agencie=
s, not to mention between agencies and the private sector.

I'm happy to see that the Nordic countries plus Estonia have realized that =
all signatures that can be securely bound to an entity (in practice) are le=
gally binding, in the extremely rare case somebody would actually repudiate=
 a signed invoice.   These governments have all (and independently of each =
other) created local variants of a scheme that I have described in:
http://webpki.org/papers/web/gateway.pdf
which could be characterized as a 21st century version of leased lines for =
multi-party automated secure messaging.
It will probably take another 15 years for this concept to achieve general =
acceptance although it is really (if you look closely) very similar to the =
US e-Authentication scheme, they have just not connected the dots yet: A SA=
ML assertion and an server-signed invoice from a specific entity are essent=
ially only different in content, not in trustworthiness.

Anders Rundgren
http://WebPKI.org



--_000_9F11911AED01D24BAA1C2355723C3D321AB0CF72DCEAEXMSGC332eu_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:p=3D"urn:schemas-m=
icrosoft-com:office:powerpoint" xmlns:a=3D"urn:schemas-microsoft-com:office=
:access" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s=3D"=
uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs=3D"urn:schemas-microsof=
t-com:rowset" xmlns:z=3D"#RowsetSchema" xmlns:b=3D"urn:schemas-microsoft-co=
m:office:publisher" xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadshee=
t" xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns=
:odc=3D"urn:schemas-microsoft-com:office:odc" xmlns:oa=3D"urn:schemas-micro=
soft-com:office:activation" xmlns:html=3D"http://www.w3.org/TR/REC-html40" =
xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:D=3D"DAV:" xmln=
s:x2=3D"http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ois=3D"ht=
tp://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir=3D"http://schema=
s.microsoft.com/sharepoint/soap/directory/" xmlns:ds=3D"http://www.w3.org/2=
000/09/xmldsig#" xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint/dsp" =
xmlns:udc=3D"http://schemas.microsoft.com/data/udc" xmlns:xsd=3D"http://www=
.w3.org/2001/XMLSchema" xmlns:sub=3D"http://schemas.microsoft.com/sharepoin=
t/soap/2002/1/alerts/" xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#" xmlns=
:sp=3D"http://schemas.microsoft.com/sharepoint/" xmlns:sps=3D"http://schema=
s.microsoft.com/sharepoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001/XMLSc=
hema-instance" xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile=
" xmlns:wf=3D"http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns=
:mver=3D"http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns=
:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns:mrels=3D"http=
://schemas.openxmlformats.org/package/2006/relationships" xmlns:ex12t=3D"ht=
tp://schemas.microsoft.com/exchange/services/2006/types" xmlns:ex12m=3D"htt=
p://schemas.microsoft.com/exchange/services/2006/messages" xmlns:Z=3D"urn:s=
chemas-microsoft-com:" xmlns:st=3D"&#1;" xmlns=3D"http://www.w3.org/TR/REC-=
html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:"\@SimSun";
	panose-1:2 1 6 0 3 1 1 1 1 1;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle19
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body bgcolor=3Dwhite lang=3DSV link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><a name=3D"_MailEndCompose"><span lang=3DEN-US style=
=3D'font-size:
11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Anders,<o:p></o:p>=
</span></a></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'>On the factual side, the EU signature directive was adopted
1999, which is 9 years ago and not 15.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'>Further, the primary function of the EU directive was to
establish that no signature should be denied legal value solely because it =
was
not based on a certain technology or met certain standards. The article 5
signature (often referred to as qualified signatures) are just a level of
security that all member countries MUST accept as equivalent to hand-writte=
n
signatures. I certainly agree that the content and intention of this direct=
ive
has been highly misunderstood.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'>The requirements on electronic invoicing comes from a totall=
y
separate directive.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'>However, I lack any specific technical proposal for this wor=
king
group to consider in your e-mail. <o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'>In absence of such proposal, your mail appears to me more as=
 a
political manifesto.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div>

<p class=3DMsoNormal><b><span lang=3DEN-GB style=3D'font-size:10.0pt;font-f=
amily:
"Arial","sans-serif";color:maroon'>Stefan Santesson</span></b><span lang=3D=
EN-GB
style=3D'color:#1F497D'><o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-GB style=3D'font-size:10.0pt;font-fami=
ly:"Arial","sans-serif";
color:#400040'>Senior Program Manager</span><span lang=3DEN-GB style=3D'col=
or:navy'><o:p></o:p></span></p>

<p class=3DMsoNormal><b><span lang=3DEN-GB style=3D'font-size:10.0pt;font-f=
amily:
"Arial","sans-serif";color:#400040'>Windows Security, Standards</span></b><=
span
lang=3DEN-US style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p></o:p></span></p>

</div>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

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

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm =
0cm 0cm'>

<p class=3DMsoNormal><b><span lang=3DEN-US style=3D'font-size:10.0pt;font-f=
amily:
"Tahoma","sans-serif"'>From:</span></b><span lang=3DEN-US style=3D'font-siz=
e:10.0pt;
font-family:"Tahoma","sans-serif"'> [e-mail]
[mailto:[e-mail]] <b>On Behalf Of </b>Anders Rundgren<b=
r>
<b>Sent:</b> den 18 november 2008 04:38<br>
<b>To:</b> [e-mail]<br>
<b>Subject:</b> The EU Signature Directive - A 15+15 Year Perspective<o:p><=
/o:p></span></p>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<div>

<p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Arial","s=
ans-serif"'>Some
15 years ago the EU launched a signature directive.&nbsp; This posting trie=
s to
describe the consequences of this directive with respect to usage of PKI.</=
span><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal>&nbsp;<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><strong><span style=3D'font-family:"Arial","sans-serif=
"'>Primary
Motivation</span></strong><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal>&nbsp;<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Arial","s=
ans-serif"'>There
are a number of processes&nbsp;needing a human-written signature in order t=
o
fulfill legal requirements.</span><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal>&nbsp;<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Arial","s=
ans-serif"'>Some
of these processes could without doubt be possible to carry out electronica=
lly
and thus also remote over a network, if there was some kind of technology
available that could serve as a replacement for a hand-written signature.</=
span><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal>&nbsp;<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><strong><span style=3D'font-family:"Arial","sans-serif=
"'>The
Solution</span></strong><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal>&nbsp;<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Arial","s=
ans-serif"'>Right
or wrong, digital signatures using PKI were considered as&nbsp;a
viable&nbsp;alternative.&nbsp; To make PKI a credible solution, the EU
signature directive added a number of requirements including characteristic=
s of
the signature creation device and policies for CAs.</span><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal>&nbsp;<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><strong><span style=3D'font-family:"Arial","sans-serif=
"'>Current
Deployment</span></strong><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal>&nbsp;<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Arial","s=
ans-serif"'>Apart
from Qualified Certificates which (for reasons too diverse for describing i=
n an
email) have not become truly mainstream, the EU signature directive have in=
deed
in local legislations made it possible to perform fairly qualified tasks
remotely over the Internet.&nbsp; I.e. the directive has functioned as an <=
strong><span
style=3D'font-family:"Arial","sans-serif"'>ENABLER</span></strong>.<o:p></o=
:p></span></p>

</div>

<div>

<p class=3DMsoNormal>&nbsp;<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><strong><span style=3D'font-family:"Arial","sans-serif=
"'>Then
Something Went&nbsp;Wrong...</span></strong><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal>&nbsp;<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Arial","s=
ans-serif"'>Unfortunately,
a few (but&nbsp;influential) people got a bit carried away and interpreted =
the
signature directive in way that has severely hampered the use of PKI.&nbsp;
Essentially they began claiming that all messages in order to
be&nbsp;trustworthy should be signed by a qualified signature or at least b=
y a
digital signature created&nbsp;under the direct control&nbsp;a human being.=
</span><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal>&nbsp;<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Arial","s=
ans-serif"'>From
a 50000 ft perspective this may sound like a great idea, but the fact is th=
at
decades before the signature directive was conceived; yes, even before PKI =
was
invented, the concept of secure messaging actually existed.&nbsp;&nbsp;Back=
 in
those days&nbsp;secure messaging was facilitated through the use of leased
lines which allowed banks (and some early b2b networks), to securely exchan=
ge
transaction messages <em><span style=3D'font-family:"Arial","sans-serif"'>i=
n a
completely automated fashion</span></em>.</span><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal>&nbsp;<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Arial","s=
ans-serif"'>An
example:&nbsp; If you want to wire-transfer money from your bank to another
bank, the way the transfer is initiated (phone, paper,&nbsp;on-line,
etc)&nbsp;has no impact on the transaction messaging because it
is&nbsp;performed in a transaction network that neither the&nbsp;customers,
nor&nbsp;most of the staff have direct access to.&nbsp;</span><o:p></o:p></=
p>

</div>

<div>

<p class=3DMsoNormal>&nbsp;<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Arial","s=
ans-serif"'>That&nbsp;such
networks have proved to be secure, reliable, cost-efficient, and sometimes =
even
globally scalable, apparently did not impress the bunch of hard-core signat=
ure
experts who for example in Germany managed to make PKI a <strong><span
style=3D'font-family:"Arial","sans-serif"'>DISABLER</span></strong> by outl=
awing
non-human digital signatures on invoices.&nbsp; That German paper-invoices =
do
not even require signatures&nbsp;makes this position a true mystery.</span>=
<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal>&nbsp;<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Arial","s=
ans-serif"'>One
had hoped that this would be an exception to the rule but it is not; If you
scan sites like NIST.GOV, CIO.GOV, and GSA.GOV you'll find literally thousa=
nds
of security-related documents, indeed in a few places mentioning PKI, but
mostly full of government regulation abbreviations like FISMA, giving littl=
e if
any guidance on how to create secure messaging between agencies, not to men=
tion
between agencies and the private sector.</span><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal>&nbsp;<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Arial","s=
ans-serif"'>I'm
happy to see&nbsp;that the Nordic countries plus Estonia have realized that=
 all
signatures that can be securely bound to an entity (in practice) are legall=
y
binding, in the extremely rare case somebody would actually repudiate a sig=
ned
invoice.&nbsp;&nbsp; These governments have all (and independently of each
other) created local variants of&nbsp;a scheme that I have described in:</s=
pan><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><a href=3D"http://webpki.org/papers/web/gateway.pdf"><=
span
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>http://webpki.o=
rg/papers/web/gateway.pdf</span></a><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Arial","s=
ans-serif"'>which&nbsp;could
be characterized as&nbsp;a 21st century version of leased lines for multi-p=
arty&nbsp;automated
secure messaging.</span><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Arial","s=
ans-serif"'>It
will probably take another 15 years for this concept to achieve general
acceptance although it is really (if you look closely) very similar&nbsp;to=
 the
US e-Authentication scheme, they have just not connected the dots yet:&nbsp=
;A
SAML assertion and an server-signed&nbsp;invoice from a specific entity are
essentially only different in content, not in trustworthiness.</span><o:p><=
/o:p></p>

</div>

<div>

<p class=3DMsoNormal>&nbsp;<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Arial","s=
ans-serif"'>Anders
Rundgren</span><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Arial","s=
ans-serif"'><a
href=3D"http://WebPKI.org">http://WebPKI.org</a></span><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal>&nbsp;<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal>&nbsp;<o:p></o:p></p>

</div>

</div>

</div>

</body>

</html>

--_000_9F11911AED01D24BAA1C2355723C3D321AB0CF72DCEAEXMSGC332eu_--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAILxClF080884 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Nov 2008 14:59:12 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAILxC4v080883; Tue, 18 Nov 2008 14:59:12 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mAILxAMA080877 for <[e-mail]>; Tue, 18 Nov 2008 14:59:11 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 7030 invoked from network); 18 Nov 2008 21:59:08 -0000
Received: from [e-mail] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;18 Nov 2008 21:59:08 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 18 Nov 2008 21:59:08 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: Robustness principle
Date: Tue, 18 Nov 2008 16:59:09 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Robustness principle
Thread-Index: AclJwLAkw1RwYk0VSUCcwMiQ9mxMrQAAGFnAAAFgq6AAAIeFoA==
References: <[e-mail]> <[e-mail]> <[e-mail]>
From: "Santosh Chokhani" <[e-mail]>
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>

Stefan,

The purpose of my post was that while relaying payload is a good
principle, if I am going to use the certificate to create a new payload,
I should DER encode the certificate if the signature verifies on the DER
encoding.

-----Original Message-----
From: Stefan Santesson [mailto:[e-mail]]=20
Sent: Tuesday, November 18, 2008 4:50 PM
To: Santosh Chokhani; Mike; [e-mail]
Subject: RE: Robustness principle

I agree, but I'm not sure where this has applicability within the
context of standardization.

If you pass a certificate to me where the signature validates, I will be
able to use it and trust it regardless of whether you "fixed" it.

The situation is quite different when we talk about signed objects. For
this case there is only one single representation of the signed data
that will match the signature. The Relying Party is safe as long as the
signature validates and the signed data can be decoded.


Stefan Santesson
Senior Program Manager
Windows Security, Standards


> -----Original Message-----
> From: [e-mail]
[mailto:[e-mail]]
> On Behalf Of Santosh Chokhani
> Sent: den 18 november 2008 15:05
> To: Mike; [e-mail]
> Subject: RE: Robustness principle
>
>
> Mike,
>
> If signature verification on "as is" fails, but succeeds for DER
> encoded, what harm do you see in saving, using and relaying DER
encoded?
>
> One harm I see is that the payload that contained the certificate
> itself, may be signed and that signature will break.
>
> -----Original Message-----
> From: [e-mail]
[mailto:[e-mail]]
> On Behalf Of Mike
> Sent: Tuesday, November 18, 2008 3:50 PM
> To: [e-mail]
> Subject: Robustness principle
>
>
> The robustness principle is not necessarily bad when it is
> applied as it was originally intended.  It has two parts:
>
>     1 - be liberal in what you accept
>     2 - be conservative in what you send
>
> The problem is that some people incorrectly interpret the
> second part to mean, "if you accepted something non-standard
> (that would otherwise have been rejected), *attempt to fix
> it* before passing it along, so what you send is standard-
> compliant."
>
> W.R.T. a non-DER-encoded certificate, I think the best thing
> you can do as an RP is to first attempt to validate it as is,
> and if that fails, optionally attempt to re-encode it as DER
> and validate it a second time.  That is being liberal in
> what you accept.
>
> However, DO NOT pass your "fixed" version on to anyone else;
> always give them the original.  That is being conservative
> in what you send.  It may seem like you should help your
> neighbor, but perhaps they wield the kind of power that can
> cause the originator to actually fix their broken software,
> making the situation better for everyone.
>
> I have a lot of experience in email server software design
> where in the 90's it was considered a good thing to fix email
> messages that didn't have proper CR-LF line endings.  This
> "helpful" behavior causes too many problems, so it is no
> longer recommended.  It, too, was done in the name of the
> robustness principle, but the principle does not actually
> advocate modifying relayed objects.
>
> Mike
>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAILoRZX080360 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Nov 2008 14:50:27 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAILoR9b080359; Tue, 18 Nov 2008 14:50:27 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-dub.microsoft.com (smtp-dub.microsoft.com [213.199.138.181]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAILoFn5080344 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Tue, 18 Nov 2008 14:50:26 -0700 (MST) (envelope-from [e-mail])
Received: from DUB-EXHUB-C303.europe.corp.microsoft.com (65.53.213.93) by DUB-EXGWY-E802.partners.extranet.microsoft.com (10.251.129.2) with Microsoft SMTP Server (TLS) id 8.1.291.1; Tue, 18 Nov 2008 21:50:14 +0000
Received: from EA-EXMSG-C332.europe.corp.microsoft.com ([169.254.1.102]) by DUB-EXHUB-C303.europe.corp.microsoft.com ([65.53.213.93]) with mapi; Tue, 18 Nov 2008 21:50:14 +0000
From: Stefan Santesson <[e-mail]>
To: Santosh Chokhani <[e-mail]>, Mike <[e-mail]>, "[e-mail]" <[e-mail]>
Date: Tue, 18 Nov 2008 21:50:09 +0000
Subject: RE: Robustness principle
Thread-Topic: Robustness principle
Thread-Index: AclJwLAkw1RwYk0VSUCcwMiQ9mxMrQAAGFnAAAFgq6A=
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
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>

I agree, but I'm not sure where this has applicability within the context o=
f standardization.

If you pass a certificate to me where the signature validates, I will be ab=
le to use it and trust it regardless of whether you "fixed" it.

The situation is quite different when we talk about signed objects. For thi=
s case there is only one single representation of the signed data that will=
 match the signature. The Relying Party is safe as long as the signature va=
lidates and the signed data can be decoded.


Stefan Santesson
Senior Program Manager
Windows Security, Standards


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> On Behalf Of Santosh Chokhani
> Sent: den 18 november 2008 15:05
> To: Mike; [e-mail]
> Subject: RE: Robustness principle
>
>
> Mike,
>
> If signature verification on "as is" fails, but succeeds for DER
> encoded, what harm do you see in saving, using and relaying DER encoded?
>
> One harm I see is that the payload that contained the certificate
> itself, may be signed and that signature will break.
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> On Behalf Of Mike
> Sent: Tuesday, November 18, 2008 3:50 PM
> To: [e-mail]
> Subject: Robustness principle
>
>
> The robustness principle is not necessarily bad when it is
> applied as it was originally intended.  It has two parts:
>
>     1 - be liberal in what you accept
>     2 - be conservative in what you send
>
> The problem is that some people incorrectly interpret the
> second part to mean, "if you accepted something non-standard
> (that would otherwise have been rejected), *attempt to fix
> it* before passing it along, so what you send is standard-
> compliant."
>
> W.R.T. a non-DER-encoded certificate, I think the best thing
> you can do as an RP is to first attempt to validate it as is,
> and if that fails, optionally attempt to re-encode it as DER
> and validate it a second time.  That is being liberal in
> what you accept.
>
> However, DO NOT pass your "fixed" version on to anyone else;
> always give them the original.  That is being conservative
> in what you send.  It may seem like you should help your
> neighbor, but perhaps they wield the kind of power that can
> cause the originator to actually fix their broken software,
> making the situation better for everyone.
>
> I have a lot of experience in email server software design
> where in the 90's it was considered a good thing to fix email
> messages that didn't have proper CR-LF line endings.  This
> "helpful" behavior causes too many problems, so it is no
> longer recommended.  It, too, was done in the name of the
> robustness principle, but the principle does not actually
> advocate modifying relayed objects.
>
> Mike
>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAILo2ZW080334 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Nov 2008 14:50:02 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAILo2vH080333; Tue, 18 Nov 2008 14:50:02 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.carillon.ca (mail.carillon.ca [207.115.107.27]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAILnoTJ080264 for <[e-mail]>; Tue, 18 Nov 2008 14:50:00 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost [127.0.0.1]) by mail.carillon.ca (Postfix) with ESMTP id CE318328090 for <[e-mail]>; Tue, 18 Nov 2008 16:49:49 -0500 (EST)
Received: from mail.carillon.ca ([127.0.0.1]) by localhost (rhea.carillon.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TuZQdsY3mUPg for <[e-mail]>; Tue, 18 Nov 2008 16:49:44 -0500 (EST)
Received: from carillon.dcoombs.ca (69-196-152-118.dsl.teksavvy.com [69.196.152.118]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.carillon.ca (Postfix) with ESMTP id 2358132801B for <[e-mail]>; Tue, 18 Nov 2008 16:49:44 -0500 (EST)
From: Patrick Patterson <[e-mail]>
Reply-To: [e-mail]
Organization: Carillon Information Security Inc.
To: [e-mail]
Subject: Re: The EU Signature Directive - A 15+15 Year Perspective
Date: Tue, 18 Nov 2008 16:49:27 -0500
User-Agent: KMail/1.9.10
References: <1E0ECAB75B5B496F942BC7D49F9D7DA5@AndersPC> <[e-mail]> <C515607EF9594962B192C59A8D711456@AndersPC>
In-Reply-To: <C515607EF9594962B192C59A8D711456@AndersPC>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
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>

On November 18, 2008 12:55:57 pm Anders Rundgren wrote:
> Hi Patrick,
>
> <snip>
>
> >As an aside, this is one of the reasons that in the Aerospace industry,
> > we're working on the concept of "Organisational" certificates (PKI analog
> > to the corporate seal).
>
> That's interesting and VERY GOOD news!  I thought the Aerospace industry
> spent their PKI money on [IMO] rather awkward Bridge CA stuff like
> http://certipath.com which I consider the opposite to Organizational
> certificates since Bridge CAs is typically rather about extending the reach
> of (existing) employee certificates.
>
Well, I'll let Santosh ring in on this if he wants, but the I can say that 
most of the companies with which I am familiar have had to implement or beef 
up their "existing" PKI infrastructures to comply with the much more rigorous 
and standardised requirements of joining the Bridge, thus facilitating, 
within the community at least, the establishment of Trust "more than a few 
blocks away from your own backyard" :)

> >It neatly side-steps the mental block that some people have regarding
> >"one person, one key", and allows anyone who is authorized to "sign
> >on behalf of the company" to use the PKI based corporate seal.
>
> Apart from possible mental blocks, there are other quite down-to-earth
> hurdles as well: 
> a.. Employees come and go => Your "digital handles" to 
> other companies easily get invalid 

That is why the Corporate Seal (you know - the one that is a physical piece of 
hardware, is kept in a safe, and is only let out by the corporate lawyers for 
defined and logged purposes) is a usefull concept to translate into the 
Digital Credential (read PKI) realm. Since the Certificate is issued to the 
corporate legal body, and not any particular physical person, it doesn't 
suffer from the same problems as "personal" certificates.

> b.. How do you automatically and 
> securely correlate a company identity as expressed in business messages
> with a PKI-based employee identity, and preferably make that scale a few
> blocks from of your own backyard? 

Is this is somewhat dependant on both the messaging format, and the trust and 
policy infrastructure that you place on the Organisational issuing practices? 

Not to get into any dogmatic debates, but by leveraging the Bridge within the 
community, we believe that this can allow the trust in the Org certs to be 
validated to quite a rigorous level.

> c.. That VeriSign's SSL PKI reaches out 
> over the entire globe, while employee PKIs (be it PIV or just your local
> stuff) typically is unknown at 99.99% of all places, indicates that the
> employee PKI model suffers from pretty serious trust establishment issues

Ok - now you're tickling one of my favourite points of discussion. The entire 
idea behind the PKI framework being worked on within the Aerospace industry 
is that it is meant to be only for within the industry. As I tell my clients, 
if you want a certificate for a web portal that is B2C focused (i.e.: for 
John Q. Public to access and interact with) then buy a Verisign (or 
equivalent) SSL certificate. If you want a certificate for 
inter-industry "closed community" collaboration (B2B within the closed 
community that is an aerospace program or project), then use a certificate 
from a CA that is cross-certified with CertiPath. Within the industry, we 
have worked out solutions for trust anchor establishment (although if more 
people did PDVAL correctly, it would make it even easier:), so we're not 
interested in propagating each individual companies CA Trust Anchor to 
millions of non-affiliated entities. In the ideal case (where the platforms 
that we work on do PDVAL correctly), each company would only propagate it's 
own trust anchor to its internal systems (trivial with such mechanisms as AD 
group policies), and let the pdval tools do their jobs when presented with 
a "external" certificate. If that external cert can "cross the bridge", then 
we're fine. If it can't, then don't trust it.

> d.. Privacy concerns.  Who (in the organization) actually orders goods is
> not necessarily something the seller needs to know.  In fact, employment is
> not public information Regarding who is authorized "to sign on behalf of
> the company", I believe that such certificates should only to be used for
> secure messaging which means that they are installed in gateway servers
> and/or information systems.  The purpose of such signatures is supporting
> authenticity and message integrity, while "consent" and "authorization" are
> things that typically stay inside of the company.  This is at least how
> bank transaction networks operate.
>

Ok - we've got a slightly different view on this point - the precise point of 
Org certs is to act as the digital equivalent of the corporate seal, which is 
the legacy mechanism for engaging the corporation in some sort of contract, 
liability, or promise - eg.: Signature.

The way that I see it, the EV SSL certs that are currently being espoused 
today are probably sufficient to convey the identity assurance that would be 
required for gateway messaging servers - for us to develop an industry 
specific solution that would compete with this would subject us to precisely 
the concerns that you had in b) and c).

> In addition, company certificates open the road for even more sophisticated
> security schemes which I have briefly covered on the last page of:
> http://webpki.org/papers/web/gateway.pdf
>
I've not read your paper yet, but I'll add it to my list :)

-- 
Patrick Patterson
President and Chief PKI Architect,
Carillon Information Security Inc.
http://www.carillon.ca



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAIL9AvP078043 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Nov 2008 14:09:10 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAIL9ARs078042; Tue, 18 Nov 2008 14:09:10 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-dub.microsoft.com (smtp-dub.microsoft.com [213.199.138.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAIL8wRQ078032 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Tue, 18 Nov 2008 14:09:09 -0700 (MST) (envelope-from [e-mail])
Received: from dub-exhub-c302.europe.corp.microsoft.com (65.53.213.92) by DUB-EXGWY-E801.partners.extranet.microsoft.com (10.251.129.1) with Microsoft SMTP Server (TLS) id 8.1.291.1; Tue, 18 Nov 2008 21:08:57 +0000
Received: from EA-EXMSG-C332.europe.corp.microsoft.com ([169.254.1.102]) by DUB-EXHUB-C302.europe.corp.microsoft.com ([65.53.213.92]) with mapi; Tue, 18 Nov 2008 21:08:57 +0000
From: Stefan Santesson <[e-mail]>
To: pkix <[e-mail]>
Date: Tue, 18 Nov 2008 21:08:49 +0000
Subject: PKIX meeting slides
Thread-Topic: PKIX meeting slides
Thread-Index: AclJwdpVQfbezUBMQ9+HLWvIyw8E9A==
Message-ID: <[e-mail]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_9F11911AED01D24BAA1C2355723C3D321AB0CF72ADEAEXMSGC332eu_"
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>

--_000_9F11911AED01D24BAA1C2355723C3D321AB0CF72ADEAEXMSGC332eu_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

All of you who are presenting at the PKIX meeting on Thursday, please send =
me your slides prior to the meeting so I can make them available on the mee=
ting materials page.
https://datatracker.ietf.org/meeting/73/materials.html


Stefan Santesson
Senior Program Manager
Windows Security, Standards


--_000_9F11911AED01D24BAA1C2355723C3D321AB0CF72ADEAEXMSGC332eu_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:p=3D"urn:schemas-m=
icrosoft-com:office:powerpoint" xmlns:a=3D"urn:schemas-microsoft-com:office=
:access" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s=3D"=
uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs=3D"urn:schemas-microsof=
t-com:rowset" xmlns:z=3D"#RowsetSchema" xmlns:b=3D"urn:schemas-microsoft-co=
m:office:publisher" xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadshee=
t" xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns=
:odc=3D"urn:schemas-microsoft-com:office:odc" xmlns:oa=3D"urn:schemas-micro=
soft-com:office:activation" xmlns:html=3D"http://www.w3.org/TR/REC-html40" =
xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:D=3D"DAV:" xmln=
s:x2=3D"http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ois=3D"ht=
tp://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir=3D"http://schema=
s.microsoft.com/sharepoint/soap/directory/" xmlns:ds=3D"http://www.w3.org/2=
000/09/xmldsig#" xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint/dsp" =
xmlns:udc=3D"http://schemas.microsoft.com/data/udc" xmlns:xsd=3D"http://www=
.w3.org/2001/XMLSchema" xmlns:sub=3D"http://schemas.microsoft.com/sharepoin=
t/soap/2002/1/alerts/" xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#" xmlns=
:sp=3D"http://schemas.microsoft.com/sharepoint/" xmlns:sps=3D"http://schema=
s.microsoft.com/sharepoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001/XMLSc=
hema-instance" xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile=
" xmlns:wf=3D"http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns=
:mver=3D"http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns=
:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns:mrels=3D"http=
://schemas.openxmlformats.org/package/2006/relationships" xmlns:ex12t=3D"ht=
tp://schemas.microsoft.com/exchange/services/2006/types" xmlns:ex12m=3D"htt=
p://schemas.microsoft.com/exchange/services/2006/messages" xmlns:Z=3D"urn:s=
chemas-microsoft-com:" xmlns:st=3D"&#1;" xmlns=3D"http://www.w3.org/TR/REC-=
html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:"\@SimSun";
	panose-1:2 1 6 0 3 1 1 1 1 1;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DSV link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><span lang=3DEN-US>All of you who are presenting at th=
e PKIX
meeting on Thursday, please send me your slides prior to the meeting so I c=
an
make them available on the meeting materials page.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><a
href=3D"https://datatracker.ietf.org/meeting/73/materials.html">https://dat=
atracker.ietf.org/meeting/73/materials.html</a><o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><b><span lang=3DEN-GB style=3D'font-size:10.0pt;font-f=
amily:
"Arial","sans-serif";color:maroon'>Stefan Santesson</span></b><span lang=3D=
EN-GB
style=3D'font-size:12.0pt;font-family:"Times New Roman","serif";color:#1F49=
7D'><o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-GB style=3D'font-size:10.0pt;font-fami=
ly:"Arial","sans-serif";
color:#400040'>Senior Program Manager</span><span lang=3DEN-GB style=3D'fon=
t-size:
12.0pt;font-family:"Times New Roman","serif";color:navy'><o:p></o:p></span>=
</p>

<p class=3DMsoNormal><b><span lang=3DEN-GB style=3D'font-size:10.0pt;font-f=
amily:
"Arial","sans-serif";color:#400040'>Windows Security, Standards</span></b><=
span
lang=3DEN-US style=3D'color:#1F497D'><o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

</div>

</body>

</html>

--_000_9F11911AED01D24BAA1C2355723C3D321AB0CF72ADEAEXMSGC332eu_--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAIL5YLL077929 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Nov 2008 14:05:34 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAIL5Yr0077928; Tue, 18 Nov 2008 14:05:34 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mAIL5MqW077918 for <[e-mail]>; Tue, 18 Nov 2008 14:05:33 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 6515 invoked from network); 18 Nov 2008 21:05:10 -0000
Received: from [e-mail] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;18 Nov 2008 21:05:10 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 18 Nov 2008 21:05:10 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: Robustness principle
Date: Tue, 18 Nov 2008 16:05:12 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Robustness principle
Thread-Index: AclJwLAkw1RwYk0VSUCcwMiQ9mxMrQAAGFnA
References: <[e-mail]>
From: "Santosh Chokhani" <[e-mail]>
To: "Mike" <[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>

Mike,

If signature verification on "as is" fails, but succeeds for DER
encoded, what harm do you see in saving, using and relaying DER encoded?

One harm I see is that the payload that contained the certificate
itself, may be signed and that signature will break.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Mike
Sent: Tuesday, November 18, 2008 3:50 PM
To: [e-mail]
Subject: Robustness principle


The robustness principle is not necessarily bad when it is
applied as it was originally intended.  It has two parts:

    1 - be liberal in what you accept
    2 - be conservative in what you send

The problem is that some people incorrectly interpret the
second part to mean, "if you accepted something non-standard
(that would otherwise have been rejected), *attempt to fix
it* before passing it along, so what you send is standard-
compliant."

W.R.T. a non-DER-encoded certificate, I think the best thing
you can do as an RP is to first attempt to validate it as is,
and if that fails, optionally attempt to re-encode it as DER
and validate it a second time.  That is being liberal in
what you accept.

However, DO NOT pass your "fixed" version on to anyone else;
always give them the original.  That is being conservative
in what you send.  It may seem like you should help your
neighbor, but perhaps they wield the kind of power that can
cause the originator to actually fix their broken software,
making the situation better for everyone.

I have a lot of experience in email server software design
where in the 90's it was considered a good thing to fix email
messages that didn't have proper CR-LF line endings.  This
"helpful" behavior causes too many problems, so it is no
longer recommended.  It, too, was done in the name of the
robustness principle, but the principle does not actually
advocate modifying relayed objects.

Mike



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAIKnmqm076740 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Nov 2008 13:49:48 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAIKnmka076737; Tue, 18 Nov 2008 13:49:48 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sasl.smtp.pobox.com (a-sasl-quonix.sasl.smtp.pobox.com [208.72.237.25]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAIKnZoI076699 for <[e-mail]>; Tue, 18 Nov 2008 13:49:46 -0700 (MST) (envelope-from [e-mail])
Received: from localhost.localdomain (unknown [127.0.0.1]) by b-sasl-quonix.sasl.smtp.pobox.com (Postfix) with ESMTP id DCFD016F71 for <[e-mail]>; Tue, 18 Nov 2008 15:49:34 -0500 (EST)
Received: from [192.168.1.8] (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by b-sasl-quonix.sasl.smtp.pobox.com (Postfix) with ESMTPSA id 8F24AE2BA for <[e-mail]>; Tue, 18 Nov 2008 15:49:27 -0500 (EST)
Message-ID: <[e-mail]>
Date: Tue, 18 Nov 2008 12:50:04 -0800
From: Mike <[e-mail]>
User-Agent: Thunderbird 2.0.0.16 (Windows/20080708)
MIME-Version: 1.0
To: [e-mail]
Subject: Robustness principle
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Pobox-Relay-ID: 6841B676-B5B2-11DD-9C80-C128113D384A-38729857!a-sasl-quonix.pobox.com
Sender: [e-mail]
Precedence: 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 robustness principle is not necessarily bad when it is
applied as it was originally intended.  It has two parts:

    1 - be liberal in what you accept
    2 - be conservative in what you send

The problem is that some people incorrectly interpret the
second part to mean, "if you accepted something non-standard
(that would otherwise have been rejected), *attempt to fix
it* before passing it along, so what you send is standard-
compliant."

W.R.T. a non-DER-encoded certificate, I think the best thing
you can do as an RP is to first attempt to validate it as is,
and if that fails, optionally attempt to re-encode it as DER
and validate it a second time.  That is being liberal in
what you accept.

However, DO NOT pass your "fixed" version on to anyone else;
always give them the original.  That is being conservative
in what you send.  It may seem like you should help your
neighbor, but perhaps they wield the kind of power that can
cause the originator to actually fix their broken software,
making the situation better for everyone.

I have a lot of experience in email server software design
where in the 90's it was considered a good thing to fix email
messages that didn't have proper CR-LF line endings.  This
"helpful" behavior causes too many problems, so it is no
longer recommended.  It, too, was done in the name of the
robustness principle, but the principle does not actually
advocate modifying relayed objects.

Mike



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAIJsh1c073388 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Nov 2008 12:54:43 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAIJsh32073387; Tue, 18 Nov 2008 12:54:43 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from QMTA05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAIJsVFM073374 for <[e-mail]>; Tue, 18 Nov 2008 12:54:41 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Received: from OMTA14.westchester.pa.mail.comcast.net ([76.96.62.60]) by QMTA05.westchester.pa.mail.comcast.net with comcast id gjaf1a00T1HzFnQ55juW0k; Tue, 18 Nov 2008 19:54:30 +0000
Received: from MIKES-LAPTOM.comcast.net ([130.129.94.208]) by OMTA14.westchester.pa.mail.comcast.net with comcast id gjts1a00S4VkWh63ajtvZQ; Tue, 18 Nov 2008 19:54:05 +0000
X-Authority-Analysis: v=1.0 c=1 a=5jT1aD21_CTz5z3LwnMA:9 a=jyXD9S-brKzQ9HKduHkA:7 a=7i1QMvw4t2e3OC1IXXMgpzf1VuAA:4 a=Ez8hvaqXLMoA:10 a=c6yCmYCQaqgyDNPbbkkA:9 a=0raws3NFFIIXPfHA7xcA:7 a=F5utOtS8VQ9R2qV6Ws24P-LxTT4A:4 a=37WNUvjkh6kA:10
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Tue, 18 Nov 2008 14:54:15 -0500
To: "David A. Cooper" <[e-mail]>, Julien Stern <[e-mail]>
From: Michael StJohns <[e-mail]>
Subject: Re: encoding an X.509 certificate
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <p06240514c5474e7c5e53@[130.129.30.0]> <[e-mail]> <[e-mail]> <p06240502c5478a569750@[130.129.30.0]> <[e-mail]> <p06240511c5489dcf4568@[130.129.30.0]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=====================_594740406==.ALT"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--=====================_594740406==.ALT
Content-Type: text/plain; charset="us-ascii"

X509 actually - in a backwards way - requires one extension to be marked critical.  The text in X509 is "If this extension field is present and is flagged critical, the subject field of the certificate may contain a null name (e.g., a sequence of zero relative distinguished names) in which case the subject is identified only by the name or names in this extension. "  - note 2 under 8.3.2.1

This refers to the SubjectAltName extension.  Another way of stating it (and this is how 5280 states it) - if the subject field has a null name, there MUST be a subjectAltName and it MUST be critical.

Mike



At 02:29 PM 11/18/2008, David A. Cooper wrote:

>We need to be careful to distinguish between "bogus" certificates and certificates that were not issued in conformance with RFC 5280.  While RFC 5280 requires conforming CAs to use positive serial numbers, there is no such requirement in X.509.  Similarly, while X.509 requires that some public key certificate extensions be marked non-critical, X.509 does not require that any public key certificate extensions be marked critical.  There are, however, a few CRL and CRL entry extensions that X.509 says must be marked critical.
>
>Dave
>
>Julien Stern wrote:
>>Steve,
>>
>>as a side note, while it may already implicitly be the case, a strongly worded statement by PKIX that implementations should reject all these "bogus" certificates (in BER, with negative serials, without critical extensions when they have to be, etc) would certainly help smaller vendors to "plead their cause" when they are told that their software "do not work" (well, if there is indeed a consensus on this statement, of course).
>>
>>Regards,
>>
>>-- 
>>Julien


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

<html>
<body>
X509 actually - in a backwards way - requires one extension to be marked
critical.&nbsp; The text in X509 is
&quot;<font face="Times New Roman, Times" size=2>If this extension field
is present and is flagged critical, the </font><font size=1><b>subject
</b></font><font face="Times New Roman, Times" size=2>field of the
certificate may contain a null name (e.g., a sequence of zero relative
distinguished names) in which case the subject is identified only by the
name or names in this extension. &quot;&nbsp; - note 2 under
8.3.2.1<br><br>
</font>This refers to the SubjectAltName extension.&nbsp; Another way of
stating it (and this is how 5280 states it) - if the subject field has a
null name, there MUST be a subjectAltName and it MUST be
critical.<br><br>
Mike<br><br>
<br><br>
At 02:29 PM 11/18/2008, David A. Cooper wrote:<br><br>
<blockquote type=cite class=cite cite="">We need to be careful to
distinguish between &quot;bogus&quot; certificates and certificates that
were not issued in conformance with RFC 5280.&nbsp; While RFC 5280
requires conforming CAs to use positive serial numbers, there is no such
requirement in X.509.&nbsp; Similarly, while X.509 requires that some
public key certificate extensions be marked non-critical, X.509 does not
require that any public key certificate extensions be marked
critical.&nbsp; There are, however, a few CRL and CRL entry extensions
that X.509 says must be marked critical.<br><br>
Dave<br><br>
Julien Stern wrote:<br>
<blockquote type=cite class=cite cite="">Steve,<br><br>
as a side note, while it may already implicitly be the case, a strongly
worded statement by PKIX that implementations should reject all these
&quot;bogus&quot; certificates (in BER, with negative serials, without
critical extensions when they have to be, etc) would certainly help
smaller vendors to &quot;plead their cause&quot; when they are told that
their software &quot;do not work&quot; (well, if there is indeed a
consensus on this statement, of course).<br><br>
Regards,<br><br>
-- <br>
Julien<br>
</blockquote></blockquote></body>
<br>
</html>

--=====================_594740406==.ALT--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAIJgTYN072574 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Nov 2008 12:42:29 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAIJgTWc072573; Tue, 18 Nov 2008 12:42:29 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp104.biz.mail.mud.yahoo.com (smtp104.biz.mail.mud.yahoo.com [68.142.200.252]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mAIJgIgD072545 for <[e-mail]>; Tue, 18 Nov 2008 12:42:28 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 13505 invoked from network); 18 Nov 2008 19:42:18 -0000
Received: from unknown (HELO Wylie) (turners@130.129.78.78 with login) by smtp104.biz.mail.mud.yahoo.com with SMTP; 18 Nov 2008 19:42:17 -0000
X-YMail-OSG: DH_uIW0VM1mUNo9rwqiNP5O9WyneMFzgvwtmMS5YR2ErSMocHrXgg1T.Wvg4bCCCcjv.D2QAk2v.orz5hqlT5sGE7rZ9IzBPX7pgjzrBMxiI1.wDGUqJ7OvTyP9kjQT6ppFd7MdpPlTGcmTB0tTvC8uRNdgtwxKWWpTLVs3.b1otQEjtVK3oJbfur.Hr
X-Yahoo-Newman-Property: ymail-3
From: "Turner, Sean P." <[e-mail]>
To: <[e-mail]>, <[e-mail]>
References: <[e-mail]> <6DE5ACAFBF0648278ABF3936799A87FA@Wylie> <[e-mail]>
Subject: RE: AD comments for draft-ietf-pkix-ecc-subpubkeyinfo-09
Date: Tue, 18 Nov 2008 13:41:54 -0600
Organization: IECA, Inc.
Message-ID: <17164937EE0E410A9CD1703DBA5E0F1D@Wylie>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
Thread-Index: AclFkTVKBddzMZh/RymSj/vhXGDRogAKSpkAAMMYYOAAAjwuIA==
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] 
>
>Sean,
>
>Thanks for a quick reply!
>
>> To answer your questions:
>> 
>> 1) Using parameter inheritance would mean that the EE certificate 
>> would not contain all of the necessary information that would be 
>> required for relying party to process a certificate.  The relying 
>> party might luck in to guessing the curve because there are only so 
>> many "well known" curves for a given key size, but to be sure the 
>> relying party would need to get the curve either from an issuer's 
>> certificate or through some other means.  The last paragraph of
>> 2.1.1 address these options.
>
>Hmm -- guessing the curve sounds like it could be dangerous?
>(But I haven't really thought what the attacks could be..)
>
>> 2) The rationale for retaining parameter inheritance is that many 
>> people that support DSA already deal with parameter inheritance in 
>> that context.  So, it may not be a burden to keep this capability in 
>> the specification.
>
>With DSA, inheritance saves hundreds of bytes, so this 
>optimization makes more sense there. Also, I think ECDSA could 
>get more widely used than DSA has been (and in more open and 
>non-homogeneous environments), so there are more opportunities 
>for problems to arise. (But opinions from other WG members 
>would be welcome, too.)

I talked to the one advocate (i.e., Russ H.) and he said he was fine taking
it out.  Nobody else has posted anything suggesting that they were
interested in this choice.  I'll comment it out, add some text to the ASN.1
note (the '88 ASN.1 below), and modify the bullet:

ECParameters ::= CHOICE {
  namedCurve         OBJECT IDENTIFIER
  -- implicitCurve   NULL
  -- specifiedCurve  SpecifiedECDomain
}
  -- implicitCurve and specifiedCurve MUST NOT be used in PKIX.
  -- Details for SpecifiedECDomain can be found in [X9.62].
  -- Any future additions to this CHOICE should be coordinated
  -- with ANSI X.9.

o implicitCurve allows the elliptic curve parameters to be inherited.  This
choice MUST NOT be used.

>> It's PKIX so we generally assume people are doing path validation ;)
>
>Well, that's not always what other IETF WGs are doing :) 
>
>> >Topic #2: scope of Appendix A
>> >
>> >For a document that specifies how to carry ECC public keys in 
>> >SubjectPublicKeyInfo, I was sort of expecting ASN.1 module(s) to do 
>> >so.  When I got to Appendix A, I was very surprised to find ASN.1 
>> >modules that contain mostly other things (not related to 
>ECC at all, 
>> >or not related to SubjectPublicKeyInfo) -- nothing in the main 
>> >document (abstract and Sections 1..8) hinted that this would be 
>> >coming. Could you briefly explain why ASN.1 about RSA, DSA, 
>MD5, etc. 
>> >belongs in this document?
>> 
>> One of early comments was that since we're updating RFC 
>3279, we'd end 
>> up with a Chinese menu for implementers if we didn't update 
>the entire 
>> RFC 3279 module.  RFC 3279 includes more than ECC "stuff" so if we 
>> update the RFC 3279 module have baggage.
>
>Sounds like a reasonable explanation. Could you add a sentence 
>or two to the document abstract and introduction explaining this?

Yes.

><snip>
>> The reference to draft-ietf-pkix-new-asn1 is an informative 
>reference.  
>> I wish the reference could be normative, but we'd be blocked on it.  
>> We could 1) pull the appendix out of the document (we'd have 
>some text 
>> tweaking to do) and put the appendix in a) separate document 
>b) put it 
>> in draft-ietf-pkix-new-asn1 2) leave it in the document and 
>produce an 
>> update after draft-ietf-pkix-asn1 gets published that says the 
>> appendices are now normative 3) indicate that it does not form a 
>> normative part of the document (not sure what we'd do with the 
>> reference).  I am willing to be guided on the best way forward.
>
>I guess this depends how soon draft-ietf-pkix-new-asn1 is 
>going to be ready. If we want to publish ecc-subpubkeyinfo 
>first, I would suggest moving Appendix A.4 to draft-ietf-pkix-new-asn1.

The time frame we're looking to meet for IEEE is RFC status before they go
to ballot.  I think that time frame is sometime in Jan so to do that I think
it might be best to rip out the '02 ASN.1 module.  Turns out they don't care
which version of the ASN.1 we use.  I talked with Jim and Paul and they're
happy to put the '02 module in their document so the information won't get
lost.  They're looking at going to WG LC in January so it wouldn't be to far
on the heals of draft-ietf-pkix-ecc-subpubkeyinfo.  There's some from matter
text tweaking that will need to be done to remove the '02 syntax but it
shouldn't take too long.  We'll also revert back to one ASN.1 module because
we're not duplicating the OIDs in multiple places in this document.

spt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAIJTk69070506 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Nov 2008 12:29:46 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAIJTkLl070505; Tue, 18 Nov 2008 12:29:46 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAIJThhe070498 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 18 Nov 2008 12:29:45 -0700 (MST) (envelope-from [e-mail])
Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mAIJTKcO023108; Tue, 18 Nov 2008 14:29:20 -0500
Received: from PowerBook-149.local ([129.6.222.74]) by postmark.nist.gov (8.13.1/8.13.1) with ESMTP id mAIJT7DE004990; Tue, 18 Nov 2008 14:29:08 -0500
Message-ID: <[e-mail]>
Date: Tue, 18 Nov 2008 13:29:05 -0600
From: "David A. Cooper" <[e-mail]>
User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914)
MIME-Version: 1.0
To: Julien Stern <[e-mail]>
CC: [e-mail]
Subject: Re: encoding an X.509 certificate
References: <[e-mail]> <p06240514c5474e7c5e53@[130.129.30.0]> <[e-mail]> <[e-mail]> <p06240502c5478a569750@[130.129.30.0]> <[e-mail]> <p06240511c5489dcf4568@[130.129.30.0]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-NIST-MailScanner-Information: 
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

We need to be careful to distinguish between "bogus" certificates and 
certificates that were not issued in conformance with RFC 5280.  While 
RFC 5280 requires conforming CAs to use positive serial numbers, there 
is no such requirement in X.509.  Similarly, while X.509 requires that 
some public key certificate extensions be marked non-critical, X.509 
does not require that any public key certificate extensions be marked 
critical.  There are, however, a few CRL and CRL entry extensions that 
X.509 says must be marked critical.

Dave

Julien Stern wrote:
> Steve,
>
> as a side note, while it may already implicitly be the case, a 
> strongly worded statement by PKIX that implementations should reject 
> all these "bogus" certificates (in BER, with negative serials, without 
> critical extensions when they have to be, etc) would certainly help 
> smaller vendors to "plead their cause" when they are told that their 
> software "do not work" (well, if there is indeed a consensus on this 
> statement, of course).
>
> Regards,
>
> -- 
> Julien
>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAIHu3Eq065689 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Nov 2008 10:56:03 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAIHu3Cd065688; Tue, 18 Nov 2008 10:56:03 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pne-smtpout2-sn2.hy.skanova.net (pne-smtpout2-sn2.hy.skanova.net [81.228.8.164]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAIHtqYK065679 for <[e-mail]>; Tue, 18 Nov 2008 10:56:02 -0700 (MST) (envelope-from [e-mail])
Received: from AndersPC (81.232.45.215) by pne-smtpout2-sn2.hy.skanova.net (7.3.129) id 4873CA95020D7304; Tue, 18 Nov 2008 18:55:50 +0100
Message-ID: <C515607EF9594962B192C59A8D711456@AndersPC>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
References: <1E0ECAB75B5B496F942BC7D49F9D7DA5@AndersPC> <[e-mail]> <3F7D87D9792849A28D560DC8341AC63F@AndersPC> <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: Re: The EU Signature Directive - A 15+15 Year Perspective
Date: Tue, 18 Nov 2008 18:55:57 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0361_01C949AF.4A8F4EA0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Windows Mail 6.0.6000.20661
X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16669
Sender: [e-mail]
Precedence: 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_0361_01C949AF.4A8F4EA0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Patrick,

<snip>

>As an aside, this is one of the reasons that in the Aerospace industry, =
we're=20
>working on the concept of "Organisational" certificates (PKI analog to =
the=20
>corporate seal).

That's interesting and VERY GOOD news!  I thought the Aerospace industry =
spent their PKI money on [IMO] rather awkward Bridge CA stuff like =
http://certipath.com which I consider the opposite to Organizational =
certificates since Bridge CAs is typically rather about extending the =
reach of (existing) employee certificates.

>It neatly side-steps the mental block that some people have regarding =20
>"one person, one key", and allows anyone who is authorized to "sign=20
>on behalf of the company" to use the PKI based corporate seal.

Apart from possible mental blocks, there are other quite down-to-earth =
hurdles as well:
  a.. Employees come and go =3D> Your "digital handles" to other =
companies easily get invalid
  b.. How do you automatically and securely correlate a company identity =
as expressed in business messages with a PKI-based employee identity, =
and preferably make that scale a few blocks from of your own backyard?
  c.. That VeriSign's SSL PKI reaches out over the entire globe, while =
employee PKIs (be it PIV or just your local stuff) typically is unknown =
at 99.99% of all places, indicates that the employee PKI model suffers =
from pretty serious trust establishment issues
  d.. Privacy concerns.  Who (in the organization) actually orders goods =
is not necessarily something the seller needs to know.  In fact, =
employment is not public information
Regarding who is authorized "to sign on behalf of the company", I =
believe that such certificates should only to be used for secure =
messaging which means that they are installed in gateway servers and/or =
information systems.  The purpose of such signatures is supporting =
authenticity and message integrity, while "consent" and "authorization" =
are things that typically stay inside of the company.  This is at least =
how bank transaction networks operate.

In addition, company certificates open the road for even more =
sophisticated security schemes which I have briefly covered on the last =
page of:
http://webpki.org/papers/web/gateway.pdf

Regards
Anders Rundgren
http://WebPKI.org


------=_NextPart_000_0361_01C949AF.4A8F4EA0
Content-Type: text/html;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

=EF=BB=BF<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dutf-8">
<META content=3D"MSHTML 6.00.6000.20927" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2>Hi Patrick,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&lt;snip&gt;</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT><BR><FONT face=3DArial =
size=3D2>&gt;As an aside,=20
this is one of the reasons that in the Aerospace industry, we're =
<BR>&gt;working=20
on the concept of "Organisational" certificates (PKI analog to the=20
<BR>&gt;corporate seal).</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>That's interesting and VERY GOOD news! =
&nbsp;I=20
thought the Aerospace industry spent their PKI money </FONT><FONT =
face=3DArial=20
size=3D2>on [IMO]&nbsp;rather awkward Bridge CA stuff like </FONT><FONT =
face=3DArial=20
size=3D2><A =
href=3D"http://certipath.com">http://certipath.com</A>&nbsp;</FONT><FONT =

face=3DArial size=3D2>which I consider the opposite to Organizational =
certificates=20
since Bridge&nbsp;CAs is typically rather about extending the reach of=20
(existing) employee certificates.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&gt;It neatly side-steps the mental =
block that some=20
people have&nbsp;regarding&nbsp; </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&gt;"one person, one key", and allows =
anyone who is=20
authorized to "sign <BR>&gt;on behalf of the company" to use the PKI =
based=20
corporate seal.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Apart from possible mental blocks, =
there are other=20
quite down-to-earth hurdles as well:</FONT></DIV>
<UL>
  <LI><FONT face=3DArial size=3D2>Employees come and go =3D&gt; Your =
"digital handles"=20
  to&nbsp;other companies easily get invalid</FONT></LI>
  <LI><FONT face=3DArial size=3D2>How do you automatically and securely=20
  correlate&nbsp;a company identity as expressed</FONT><FONT =
face=3DArial size=3D2>=20
  in business messages&nbsp;with&nbsp;a PKI-based&nbsp;employee =
identity, and=20
  preferably&nbsp;make that</FONT><FONT face=3DArial =
size=3D2>&nbsp;scale a=20
  few&nbsp;blocks from of your own backyard?</FONT></LI>
  <LI><FONT face=3DArial size=3D2>That VeriSign's SSL PKI reaches out =
over the=20
  entire globe, while employee PKIs</FONT><FONT face=3DArial size=3D2> =
(be it PIV or=20
  just your local stuff) typically is unknown at 99.99% of all=20
  places,</FONT><FONT face=3DArial size=3D2> indicates that the employee =
PKI model=20
  suffers from pretty serious trust establishment issues</FONT></LI>
  <LI><FONT face=3DArial size=3D2>Privacy concerns.&nbsp; Who (in the=20
  organization)&nbsp;actually orders goods is not necessarily something =
the=20
  seller needs to know.&nbsp; In fact, employment is not public=20
  information</FONT></LI></UL>
<DIV><FONT face=3DArial size=3D2>Regarding who is authorized "to sign on =
behalf of=20
the company", I believe that such certificates&nbsp;should only to be =
used for=20
secure messaging which means that they are installed in gateway servers =
and/or=20
information systems.&nbsp; The purpose of such signatures is supporting=20
authenticity and message integrity, while "consent" and =
"authorization"&nbsp;are=20
things that typically&nbsp;stay inside of the company.&nbsp; This is at =
least=20
how bank transaction&nbsp;networks operate.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>In addition, company certificates open =
the road for=20
even more sophisticated security schemes which I have briefly covered on =
the=20
last page of:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2><A=20
href=3D"http://webpki.org/papers/web/gateway.pdf"><FONT face=3DArial=20
size=3D2>http://webpki.org/papers/web/gateway.pdf</FONT></A></FONT></DIV>=

<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Regards</FONT></DIV><FONT face=3DArial =
size=3D2>
<DIV>Anders Rundgren</DIV>
<DIV><A href=3D"http://WebPKI.org">http://WebPKI.org</A></DIV>
<DIV><BR>&nbsp;</DIV></FONT></BODY></HTML>

------=_NextPart_000_0361_01C949AF.4A8F4EA0--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAIGoVMd061455 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Nov 2008 09:50:31 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAIGoV1D061454; Tue, 18 Nov 2008 09:50:31 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from maiev.nerim.net (smtp-116-tuesday.nerim.net [62.4.16.116]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAIGoKYc061442 for <[e-mail]>; Tue, 18 Nov 2008 09:50:31 -0700 (MST) (envelope-from [e-mail])
Received: from uranus.cry.pto (cryptolog2.pck.nerim.net [213.41.184.9]) by maiev.nerim.net (Postfix) with ESMTP id 531E8B93F2; Tue, 18 Nov 2008 17:50:17 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by uranus.cry.pto (Postfix) with ESMTP id 515954401B; Tue, 18 Nov 2008 17:50:17 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at cryptolog.com
Received: from uranus.cry.pto ([127.0.0.1]) by localhost (uranus.cry.pto [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id re8xBiWJt2bX; Tue, 18 Nov 2008 17:50:13 +0100 (CET)
Received: from [10.0.1.30] (leda.cry.pto [10.0.1.30]) by uranus.cry.pto (Postfix) with ESMTP id 961784400C; Tue, 18 Nov 2008 17:50:13 +0100 (CET)
Message-ID: <[e-mail]>
Date: Tue, 18 Nov 2008 17:50:13 +0100
From: Julien Stern <[e-mail]>
User-Agent: Mozilla-Thunderbird 2.0.0.14 (X11/20080509)
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
Cc: [e-mail]
Subject: Re: encoding an X.509 certificate
References: <[e-mail]> <p06240514c5474e7c5e53@[130.129.30.0]> <[e-mail]> <[e-mail]> <p06240502c5478a569750@[130.129.30.0]> <[e-mail]> <p06240511c5489dcf4568@[130.129.30.0]>
In-Reply-To: <p06240511c5489dcf4568@[130.129.30.0]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stephen Kent wrote:
> At 5:01 PM +0100 11/18/08, Julien Stern wrote:
>> Stephen Kent wrote:
>>> Julien,
>>>
>>> I am painfully aware that if a really big vendor fails to follow 
>>> standards, then it may cause many other, smaller vendors to have to 
>>> accept certs, CRLs, OCSP responses, HTML, etc. that are "broken" 
>>> vis-a-vis the relevant standards.
>>>
>>> But, the IETF works to create standards based on the consensus of 
>>> knowledgeable individuals who chose to participate in the IETF 
>>> standards process. I don't think it's appropriate to skew our 
>>> standards to accommodate the practices of any (large) vendor who 
>>> violates our standards, and I'd rather we not debate this in the 
>>> context of an IETF standards WG.
>>
>> My apologies if this was considered inapropriate, I was being ironic 
>> (as somehow indicated by the smiley). Please only read it as a way to 
>> pinpoint the difficulties of being strictly standard compliant in the 
>> real world.
>>
>> I did also say that a strictly standard compliant implementation can 
>> hardly be blamed for being so, and underlined the fact that deciding 
>> to be "strict in what you produce/liberal in what you accept" should 
>> take into account the possible security impacts, especially in the 
>> context of PKIX.
>>
>> Regards,
>>
>> -- 
>> Julien
> 
> 
> Thanks for the clarifying  message.

Steve,

as a side note, while it may already implicitly be the case, a strongly 
worded statement by PKIX that implementations should reject all these 
"bogus" certificates (in BER, with negative serials, without critical 
extensions when they have to be, etc) would certainly help smaller 
vendors to "plead their cause" when they are told that their software 
"do not work" (well, if there is indeed a consensus on this statement, 
of course).

Regards,

--
Julien



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAIGYq0j060249 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Nov 2008 09:34:52 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAIGYq4T060248; Tue, 18 Nov 2008 09:34:52 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAIGYood060241 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 18 Nov 2008 09:34:51 -0700 (MST) (envelope-from [e-mail])
Received: from dommiel.bbn.com ([192.1.122.15] helo=[130.129.30.0]) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from <[e-mail]>) id 1L2TXN-0003xK-AM; Tue, 18 Nov 2008 11:34:49 -0500
Mime-Version: 1.0
Message-Id: <p06240511c5489dcf4568@[130.129.30.0]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <p06240514c5474e7c5e53@[130.129.30.0]> <[e-mail]> <[e-mail]> <p06240502c5478a569750@[130.129.30.0]> <[e-mail]>
Date: Tue, 18 Nov 2008 11:29:50 -0500
To: Julien Stern <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: encoding an X.509 certificate
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 5:01 PM +0100 11/18/08, Julien Stern wrote:
>Stephen Kent wrote:
>>Julien,
>>
>>I am painfully aware that if a really big vendor fails to follow 
>>standards, then it may cause many other, smaller vendors to have to 
>>accept certs, CRLs, OCSP responses, HTML, etc. that are "broken" 
>>vis-a-vis the relevant standards.
>>
>>But, the IETF works to create standards based on the consensus of 
>>knowledgeable individuals who chose to participate in the IETF 
>>standards process. I don't think it's appropriate to skew our 
>>standards to accommodate the practices of any (large) vendor who 
>>violates our standards, and I'd rather we not debate this in the 
>>context of an IETF standards WG.
>
>My apologies if this was considered inapropriate, I was being ironic 
>(as somehow indicated by the smiley). Please only read it as a way 
>to pinpoint the difficulties of being strictly standard compliant in 
>the real world.
>
>I did also say that a strictly standard compliant implementation can 
>hardly be blamed for being so, and underlined the fact that deciding 
>to be "strict in what you produce/liberal in what you accept" should 
>take into account the possible security impacts, especially in the 
>context of PKIX.
>
>Regards,
>
>--
>Julien


Thanks for the clarifying  message.

Steve




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAIGR1vq059700 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Nov 2008 09:27:01 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAIGR1QP059699; Tue, 18 Nov 2008 09:27:01 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mga03.intel.com (mga03.intel.com [143.182.124.21]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAIGQonj059681 for <[e-mail]>; Tue, 18 Nov 2008 09:27:01 -0700 (MST) (envelope-from [e-mail])
Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga101.ch.intel.com with ESMTP; 18 Nov 2008 08:26:50 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.33,625,1220252400";  d="scan'208";a="78162437"
Received: from azsmsx602.amr.corp.intel.com ([10.2.121.201]) by azsmga001.ch.intel.com with ESMTP; 18 Nov 2008 08:26:49 -0800
Received: from orsmsx601.amr.corp.intel.com (10.22.226.213) by azsmsx602.amr.corp.intel.com (10.2.121.201) with Microsoft SMTP Server (TLS) id 8.1.311.2; Tue, 18 Nov 2008 09:26:43 -0700
Received: from orsmsx503.amr.corp.intel.com ([10.22.226.47]) by orsmsx601.amr.corp.intel.com ([10.22.226.213]) with mapi; Tue, 18 Nov 2008 08:26:41 -0800
From: "Sood, Kapil" <[e-mail]>
To: Stephen Kent <[e-mail]>, "Timothy J. Miller" <[e-mail]>
CC: Eric Norman <[e-mail]>, "[e-mail]" <[e-mail]>, "Bar-Or, Sagi" <[e-mail]>
Date: Tue, 18 Nov 2008 08:26:40 -0800
Subject: RE: encoding an X.509 certificate
Thread-Topic: encoding an X.509 certificate
Thread-Index: AclJl5FR7+GqZcZoSQenUGc5mC+0FgAAquaw
Message-ID: <[e-mail]>
References: <[e-mail]> <p06240514c5474e7c5e53@[130.129.30.0]> <[e-mail]> <p06240516c5476ce48e9a@[130.129.30.0]> <[e-mail]> <p06240501c547897161bb@[130.129.30.0]> <[e-mail]> <p0624050ac5488e57a568@[130.129.30.0]>
In-Reply-To: <p0624050ac5488e57a568@[130.129.30.0]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
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>

A testing (inter-op, certification) along these lines will be of immense va=
lue to numerous organizations that deploy PKI components...

Best Regards,
=20
Kapil.
971.506.1700

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On=
 Behalf Of Stephen Kent
Sent: Tuesday, November 18, 2008 7:24 AM
To: Timothy J. Miller
Cc: Eric Norman; [e-mail]
Subject: Re: encoding an X.509 certificate


At 8:49 AM -0600 11/18/08, Timothy J. Miller wrote:
>Stephen Kent wrote:
>
>>Pity we don't have a "PKIX Compliant" trademark :-).
>
>So what would it take to *make* a certification program?  VPNC runs
>one for IPSec, The Open Group runs one for S/MIME
>
>-- Tim

Ask Paul Hoffman if he is interested, and if he sees enough interest
from vendors to support a testing program of that sort. Paul has
excellent experience in this context.

Steve



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAIG1WNE057968 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Nov 2008 09:01:32 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAIG1WZ0057967; Tue, 18 Nov 2008 09:01:32 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kraid.nerim.net (smtp-102-tuesday.nerim.net [62.4.16.102]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAIG1LvT057957 for <[e-mail]>; Tue, 18 Nov 2008 09:01:32 -0700 (MST) (envelope-from [e-mail])
Received: from uranus.cry.pto (cryptolog2.pck.nerim.net [213.41.184.9]) by kraid.nerim.net (Postfix) with ESMTP id EB525CF9BC; Tue, 18 Nov 2008 17:01:19 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by uranus.cry.pto (Postfix) with ESMTP id 13C7E4401B; Tue, 18 Nov 2008 17:01:20 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at cryptolog.com
Received: from uranus.cry.pto ([127.0.0.1]) by localhost (uranus.cry.pto [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aBOB4s-Qtdhs; Tue, 18 Nov 2008 17:01:16 +0100 (CET)
Received: from [10.0.1.30] (leda.cry.pto [10.0.1.30]) by uranus.cry.pto (Postfix) with ESMTP id 876504400C; Tue, 18 Nov 2008 17:01:16 +0100 (CET)
Message-ID: <[e-mail]>
Date: Tue, 18 Nov 2008 17:01:16 +0100
From: Julien Stern <[e-mail]>
User-Agent: Mozilla-Thunderbird 2.0.0.14 (X11/20080509)
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
Cc: [e-mail]
Subject: Re: encoding an X.509 certificate
References: <[e-mail]> <p06240514c5474e7c5e53@[130.129.30.0]> <[e-mail]> <[e-mail]> <p06240502c5478a569750@[130.129.30.0]>
In-Reply-To: <p06240502c5478a569750@[130.129.30.0]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stephen Kent wrote:
> Julien,
> 
> I am painfully aware that if a really big vendor fails to follow 
> standards, then it may cause many other, smaller vendors to have to 
> accept certs, CRLs, OCSP responses, HTML, etc. that are "broken" 
> vis-a-vis the relevant standards.
> 
> But, the IETF works to create standards based on the consensus of 
> knowledgeable individuals who chose to participate in the IETF standards 
> process. I don't think it's appropriate to skew our standards to 
> accommodate the practices of any (large) vendor who violates our 
> standards, and I'd rather we not debate this in the context of an IETF 
> standards WG.

My apologies if this was considered inapropriate, I was being ironic (as 
somehow indicated by the smiley). Please only read it as a way to 
pinpoint the difficulties of being strictly standard compliant in the 
real world.

I did also say that a strictly standard compliant implementation can 
hardly be blamed for being so, and underlined the fact that deciding to 
be "strict in what you produce/liberal in what you accept" should take 
into account the possible security impacts, especially in the context of 
PKIX.

Regards,

--
Julien



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAIFhVJA056588 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Nov 2008 08:43:31 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAIFhVV5056587; Tue, 18 Nov 2008 08:43:31 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAIFhU7C056575 for <[e-mail]>; Tue, 18 Nov 2008 08:43:30 -0700 (MST) (envelope-from [e-mail])
Received: from dommiel.bbn.com ([192.1.122.15] helo=[130.129.30.0]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from <[e-mail]>) id 1L2Sjh-0002u0-FK; Tue, 18 Nov 2008 10:43:29 -0500
Mime-Version: 1.0
Message-Id: <p06240502c5478a569750@[130.129.30.0]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <p06240514c5474e7c5e53@[130.129.30.0]> <[e-mail]> <[e-mail]>
Date: Tue, 18 Nov 2008 10:28:42 -0500
To: Julien Stern <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: encoding an X.509 certificate
Cc: [e-mail]
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>

Julien,

I am painfully aware that if a really big vendor fails to follow 
standards, then it may cause many other, smaller vendors to have to 
accept certs, CRLs, OCSP responses, HTML, etc. that are "broken" 
vis-a-vis the relevant standards.

But, the IETF works to create standards based on the consensus of 
knowledgeable individuals who chose to participate in the IETF 
standards process. I don't think it's appropriate to skew our 
standards to accommodate the practices of any (large) vendor who 
violates our standards, and I'd rather we not debate this in the 
context of an IETF standards WG.

Steve



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAIFhVK9056589 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Nov 2008 08:43:31 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAIFhVfl056586; Tue, 18 Nov 2008 08:43:31 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAIFhUPq056574 for <[e-mail]>; Tue, 18 Nov 2008 08:43:30 -0700 (MST) (envelope-from [e-mail])
Received: from dommiel.bbn.com ([192.1.122.15] helo=[130.129.30.0]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from <[e-mail]>) id 1L2Sjh-0002u0-DH; Tue, 18 Nov 2008 10:43:29 -0500
Mime-Version: 1.0
Message-Id: <p0624050ac5488e57a568@[130.129.30.0]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <p06240514c5474e7c5e53@[130.129.30.0]> <[e-mail]> <p06240516c5476ce48e9a@[130.129.30.0]> <[e-mail]> <p06240501c547897161bb@[130.129.30.0]> <[e-mail]>
Date: Tue, 18 Nov 2008 10:24:17 -0500
To: "Timothy J. Miller" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: encoding an X.509 certificate
Cc: Eric Norman <[e-mail]>, [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 8:49 AM -0600 11/18/08, Timothy J. Miller wrote:
>Stephen Kent wrote:
>
>>Pity we don't have a "PKIX Compliant" trademark :-).
>
>So what would it take to *make* a certification program?  VPNC runs 
>one for IPSec, The Open Group runs one for S/MIME
>
>-- Tim

Ask Paul Hoffman if he is interested, and if he sees enough interest 
from vendors to support a testing program of that sort. Paul has 
excellent experience in this context.

Steve



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAIFOtxa055179 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Nov 2008 08:24:55 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAIFOtHC055178; Tue, 18 Nov 2008 08:24:55 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAIFOiba055163 for <[e-mail]>; Tue, 18 Nov 2008 08:24:55 -0700 (MST) (envelope-from [e-mail])
Received: from dhcp89-089-178.bbn.com ([128.89.89.178] helo=gardiner-xp.bbn.com) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from <[e-mail]>) id 1L2SRX-0002hT-G4; Tue, 18 Nov 2008 10:24:44 -0500
Message-Id: <[e-mail]>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2
Date: Tue, 18 Nov 2008 10:24:43 -0500
To: Tom Gindin <[e-mail]>, Stephen Kent <[e-mail]>
From: "Charles W. Gardiner" <[e-mail]>
Subject: Re: encoding an X.509 certificate
Cc: [e-mail]
In-Reply-To: <OFD8FFAB1C.63533A5E-ON85257504.007B95EE-85257505.00094C56@ us.ibm.com>
References: <p06240514c5474e7c5e53@[130.129.30.0]> <[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>

     This raises the question of whether things inside a wrapper must be 
DER-encoded or are they in some way inviolate so one must take them "as is".

Charlie Gardiner

At 08:41 PM 11/17/2008, Tom Gindin wrote:

>         Steve:
>
>         As a theoretical exercise, let us assume that a relying party
>encounters the following encoding as part of the value of a non-critical
>extension with syntax unknown to the relying party: A1 13 16 03 4F 6E 65
>16 07 45 78 61 6D 70 6C 65 16 03 4E 6F 77.
>         How can the relying party tell whether this is a valid DER
>encoding of [1] IMPLICIT SEQUENCE OF PrintableString, an encoding of [1]
>IMPLICIT PrintableString which violates section 10.2 of X.690, or an
>encoding of [1] IMPLICIT SET OF PrintableString which violates section
>11.6 of X.690?  The component string values are "One", "Example", and
>"Now".
>         I am not convinced that "re-encode as DER" can be performed by
>general purpose library code.  One can verify that the certificate down to
>the OCTET STRING wrappings for extension values is in DER, but one cannot
>always tell whether the inner values of extensions are in DER, let alone
>re-encode them into DER.
>
>                 Tom Gindin
>
>P.S - The above opinions (and those in my last post as well) are mine and
>not necessarily those of my employer
>
>
>
>
>Stephen Kent <[e-mail]>
>11/17/2008 11:40 AM
>
>To
>Tom Gindin/Watson/IBM@IBMUS
>cc
>"Timothy J. Miller" <[e-mail]>, [e-mail],
>[e-mail], Peter Gutmann <[e-mail]>
>Subject
>Re: encoding an X.509 certificate
>
>
>
>
>
>
>At 8:22 PM -0500 11/12/08, Tom Gindin wrote:
> >         "Conservative in what you produce" - CA code should generate
>DER.
> >Not all such code does so, but it should.
> >         "Liberal in what you accept" - RP code should verify signatures
>on
> >the supplied binary TBSCertificate, rather than re-encoding.  For parsing
> >code to accept BER which isn't valid DER is almost harmless.    There may
> >well have been a good reason for believing that DER was more secure than
> >BER against various digest collision or pre-image attacks when X.509v1
>was
> >in use and all certificate content had syntax verifiable by every RP (at
> >least in theory).  With non-critical extensions, that is no longer the
> >case.
> >
> >                 Tom Gindin
>
>Tom,
>
>I have to disagree. The standards call for DER to be used for
>signature generation and validation. They are generally silent on
>transport encoding. If we say that an RP should just try to verify
>the signature on whatever it receives, then we encourage (more)
>sloppy behavior by CAs. The preferred approach is for the RP to
>encode the received cert into DER before checking.
>
>Steve




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAIFHobl054651 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Nov 2008 08:17:50 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAIFHoSc054650; Tue, 18 Nov 2008 08:17:50 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAIFHW9f054610 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 18 Nov 2008 08:17:43 -0700 (MST) (envelope-from [e-mail])
Received: from dommiel.bbn.com ([192.1.122.15] helo=[130.129.30.0]) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from <[e-mail]>) id 1L2SKW-0002Yd-Ao; Tue, 18 Nov 2008 10:17:28 -0500
Mime-Version: 1.0
Message-Id: <p06240502c5488a5ab623@[130.129.30.0]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <p06240514c5474e7c5e53@[130.129.30.0]> <[e-mail]> <p06240516c5476ce48e9a@[130.129.30.0]> <[e-mail]>
Date: Tue, 18 Nov 2008 10:12:52 -0500
To: Eric Norman <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: encoding an X.509 certificate
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 3:08 PM -0600 11/17/08, Eric Norman wrote:
>On Nov 17, 2008, at 12:50 PM, Stephen Kent wrote:
>
>>At 11:24 AM -0600 11/17/08, Eric Norman wrote:
>>>So if someone receives a bit blob that contains a certificate,
>>>and the signature would verify if the bit blob was used,
>>>but some parts of that bit blob are BER but not DER encoded,
>>>then certificate validation should fail?
>>>
>>>Eric Norman
>>
>>We're talking about certs, not blobs that contain certs.
>
>OK.
>
>So is someone receives a certificate,
>and the certificate signature would verify if it (TBS part) were 
>used as received,
>but some parts of the certificate are BER but not DER encoded,
>then certificate validation should fail?
>
>Eric Norman

I assume that you mean to ask "if the cert had its signature computed 
over a mix of DER and BER encoded fields, should the RP consider the 
cert valid, because a signature computed on the cert (as received, a 
mix of DER and BER) matches the signature provided with the cert?"

My answer is yes, the RP should reject the cert. My rationale is that 
if an RP uses the standards-compliant strategy of encoding every 
received cert into DER, before it checks the cert sig, this cert will 
fail the sig check. If we encourage RPs to just compute a hash on a 
cert as received, without encoding to DER, then the "broken" cert you 
describe will verify, but implementations following the procedure I 
described will reject the cert, creating interoperability issues (and 
encouraging bad behavior).

Steve



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAIFHhmv054634 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Nov 2008 08:17:43 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAIFHh1d054633; Tue, 18 Nov 2008 08:17:43 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAIFHWqA054611 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 18 Nov 2008 08:17:43 -0700 (MST) (envelope-from [e-mail])
Received: from dommiel.bbn.com ([192.1.122.15] helo=[130.129.30.0]) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from <[e-mail]>) id 1L2SKX-0002Yd-AC; Tue, 18 Nov 2008 10:17:29 -0500
Mime-Version: 1.0
Message-Id: <p06240503c5488bfe1857@[130.129.30.0]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <p06240514c5474e7c5e53@[130.129.30.0]> <[e-mail]> <p06240516c5476ce48e9a@[130.129.30.0]> <[e-mail]> <[e-mail]>
Date: Tue, 18 Nov 2008 10:14:26 -0500
To: Eric Norman <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: encoding an X.509 certificate
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 3:12 PM -0600 11/17/08, Eric Norman wrote:
>On Nov 17, 2008, at 3:08 PM, Eric Norman wrote:
>
>>So is someone receives a certificate,
>>and the certificate signature would verify if it (TBS part) were 
>>used as received,
>>but some parts of the certificate are BER but not DER encoded,
>>then certificate validation should fail?
>
>To be clear.
>
>Why shouldn't the robustness principle apply in this case?
>
>Eric Norman

Jon Postel's robustness principle has always been in tension with 
security protocols, since being liberal in what you accept is a 
recipe for insecurity.

Steve



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAIEngqZ052581 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Nov 2008 07:49:42 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAIEngd8052580; Tue, 18 Nov 2008 07:49:42 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAIEnUo6052566 for <[e-mail]>; Tue, 18 Nov 2008 07:49:41 -0700 (MST) (envelope-from [e-mail])
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id mAIEnTV2026460 for <[e-mail]>; Tue, 18 Nov 2008 09:49:30 -0500
Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id mAIEnTQs026457; Tue, 18 Nov 2008 09:49:29 -0500
Received: from [129.83.200.4] (129.83.200.4) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server (TLS) id 8.1.311.2; Tue, 18 Nov 2008 09:49:29 -0500
Message-ID: <[e-mail]>
Date: Tue, 18 Nov 2008 08:49:26 -0600
From: "Timothy J. Miller" <[e-mail]>
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
CC: Eric Norman <[e-mail]>, [e-mail]
Subject: Re: encoding an X.509 certificate
References: <[e-mail]> <p06240514c5474e7c5e53@[130.129.30.0]> <[e-mail]> <p06240516c5476ce48e9a@[130.129.30.0]> <[e-mail]> <p06240501c547897161bb@[130.129.30.0]>
In-Reply-To: <p06240501c547897161bb@[130.129.30.0]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030800020400050902020303"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

Stephen Kent wrote:

> Pity we don't have a "PKIX Compliant" trademark :-).

So what would it take to *make* a certification program?  VPNC runs one 
for IPSec, The Open Group runs one for S/MIME

-- Tim

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKvjCC
A2cwggJPoAMCAQICAh8FMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEe
MBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3Jh
dGlvbiBQcmltYXJ5IENBLTEwHhcNMDgwODIxMTUzMTI5WhcNMTAwMjEyMTUzMTI5WjBaMRIw
EAYDVQQKEwltaXRyZS5vcmcxDzANBgNVBAsTBnBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3Rt
aWxsZXIxGjAYBgNVBAMTEU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQCTxM+z5fDKvmBInGatv0DkVwuOxd69S2M2jho8QkOltYJK/4JUm9uK0UtQZkyI
bEjmCpmXLw17iMCgA0SjwuUfJxdF8ntTys8keyMjRdlKSwFnkgZl9tL7o060LBtZQYzI5ajr
W9k3N768G/k1bZS5UYiMGHU5+Ygl4IwVhmQv3wIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF
4DAdBgNVHQ4EFgQUSXARqmj5Bl2Lz7RLoUIkuOHl0MkwHwYDVR0jBBgwFoAUh7QPSI1iM0LB
LVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL3d3dy5taXRyZS5vcmcvdGVj
aC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1UdEQQVMBOBEXRtaWxsZXJAbWl0cmUu
b3JnMA0GCSqGSIb3DQEBBQUAA4IBAQAbA1PH/hed/rryO1f0yfTRJnD/vL1rFTduUut/irL7
FSXHGybuPHxydfyGPvJ4qj+T8hs1W0jTa2zQnaPR52tms3hefl76CNVP9vJoVmaM9svFX4DX
6eJh/4SAI81tAuBIK8gxsWd1Va/Bnnh1/wsZLc8w2jkojVqkT2AHPaHS3DBKX7QAWovXVSxY
QlqMIH4zvSNSVfpvpIf0MWJWRBPvgerVSbJsA4dz6ziKvXDWySTV9zwSuNjikNqL//nIKwjb
r3ZOfSUOxSuhW58an2Ha4TdORvG4dGJEsMzxbpTB+wt/s6tK6roONV4uiDtODBNVAG+XGofe
McsS0b7iXdxDMIIDZzCCAk+gAwIBAgICHwUwDQYJKoZIhvcNAQEFBQAwXTESMBAGA1UEChMJ
bWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAlBgNVBAMTHk1J
VFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMTAeFw0wODA4MjExNTMxMjlaFw0xMDAyMTIx
NTMxMjlaMFoxEjAQBgNVBAoTCW1pdHJlLm9yZzEPMA0GA1UECxMGcGVvcGxlMRcwFQYKCZIm
iZPyLGQBARMHdG1pbGxlcjEaMBgGA1UEAxMRTWlsbGVyIFRpbW90aHkgSi4wgZ8wDQYJKoZI
hvcNAQEBBQADgY0AMIGJAoGBAJPEz7Pl8Mq+YEicZq2/QORXC47F3r1LYzaOGjxCQ6W1gkr/
glSb24rRS1BmTIhsSOYKmZcvDXuIwKADRKPC5R8nF0Xye1PKzyR7IyNF2UpLAWeSBmX20vuj
TrQsG1lBjMjlqOtb2Tc3vrwb+TVtlLlRiIwYdTn5iCXgjBWGZC/fAgMBAAGjgbcwgbQwDgYD
VR0PAQH/BAQDAgXgMB0GA1UdDgQWBBRJcBGqaPkGXYvPtEuhQiS44eXQyTAfBgNVHSMEGDAW
gBSHtA9IjWIzQsEtURpIHsKeuwqxrTBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vd3d3Lm1p
dHJlLm9yZy90ZWNoL21paS9wa2kvY2ExX21pdHJlX29yZy5jcmwwHAYDVR0RBBUwE4ERdG1p
bGxlckBtaXRyZS5vcmcwDQYJKoZIhvcNAQEFBQADggEBABsDU8f+F53+uvI7V/TJ9NEmcP+8
vWsVN25S63+KsvsVJccbJu48fHJ1/IY+8niqP5PyGzVbSNNrbNCdo9Hna2azeF5+XvoI1U/2
8mhWZoz2y8VfgNfp4mH/hIAjzW0C4EgryDGxZ3VVr8GeeHX/CxktzzDaOSiNWqRPYAc9odLc
MEpftABai9dVLFhCWowgfjO9I1JV+m+kh/QxYlZEE++B6tVJsmwDh3PrOIq9cNbJJNX3PBK4
2OKQ2ov/+cgrCNuvdk59JQ7FK6FbnxqfYdrhN05G8bh0YkSwzPFulMH7C3+zq0rqug41Xi6I
O04ME1UAb5cah94xyxLRvuJd3EMwggPkMIICzKADAgECAgEFMA0GCSqGSIb3DQEBBQUAMFox
EjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MSQw
IgYDVQQDExtNSVRSRSBDb3Jwb3JhdGlvbiBSb290IENBLTEwHhcNMDYwNjAzMTcxMzIyWhcN
MTIwNjAzMTcxMzIyWjBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmlj
YXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0x
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyPB7Vl0QgqgQt0u8Q2duRs7eZUPn
hlflKPFPMXGG+iqGpImYs6nfbFPsn0q8FqklFsm/UEV2JJQ3c7Srwfrqe9CrCbVFh761OxZI
7fnUWiUasNP2ING19aAfrQ8IoJsAEtGzHeIacS+M5CN4C0yfUC6CpBZTc9ZldjLUatvJr407
K1i+7WnrRsMVKhICfgmiO/XiVR9YeXyzeRqFrLy6YtJCJuJd0QRfwKtKRpek5oU67Izr7ClH
DtPJs7UOTjMYBS2fTzztC+wwOTp6+A3ZbEymuQcAZRwmGkjVBe2R8MiX26R02Iigz+903ZAL
/6bpvx0DnkrlR2UFr1KBGfBqmQIDAQABo4GxMIGuMBIGA1UdEwEB/wQIMAYBAf8CAQIwDgYD
VR0PAQH/BAQDAgGGMB0GA1UdDgQWBBSHtA9IjWIzQsEtURpIHsKeuwqxrTAfBgNVHSMEGDAW
gBTHcFEA2E3+5AHUaJbFPZ+al/50LzBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vd3d3Lm1p
dHJlLm9yZy90ZWNoL21paS9wa2kvcm9vdGNhMV9taXRyZV9vcmcuY3JsMA0GCSqGSIb3DQEB
BQUAA4IBAQBNbm7rrins3SICPbteX9qSN1+RJClqix/pw3IAe7u60LK0V9jVZ9E2a+c0MZiS
ojdcwU5rXxI2OI2wwIf6wVBo76jIOc+IiQRlC+V8YatGmoibqP/8WDPzlud/WQAzkjrU2nuh
8KdyJG+n1kH/6772Lbra2CIk8mu8FypeaB5P2uIJzdE+PGo82ZiyU680ukiJ9yF6UmEXuciB
77tGQBRxMl6ePzIrArQnf48SmBhFD5XYLraueOiG7E+AzD99ig1M6WHcxWXtp3DIrVqE/DZr
146NJaCWqg9NoE14cmpEllnpWLtLnn5UBYJ+QCozmbe1SJXOOynZ0VxMnGdh7NqgMYICqDCC
AqQCAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1
dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTAJ
BgUrDgMCGgUAoIIBmzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0wODExMTgxNDQ5MjZaMCMGCSqGSIb3DQEJBDEWBBQERUjIKWm61UajgXYn7SC+zTglWzBS
BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D
AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNV
BAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQD
Ex5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAh8FMHQGCyqGSIb3DQEJEAILMWWg
YzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0
eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTANBgkqhkiG
9w0BAQEFAASBgEs5JLw7Je3vD7HHKfNJsrwNLQBHYGpOX9B1KpXWz2gnlEXXCnpKEkag2bIi
sOlBxtm4OkYVk18hNkJnx0Qd950ToBl+WKbzmpaZkwdkIQKwmsl3dS5+fEBi9+P3V3HmW1YC
7qQzfZkNl3/YZIXhbPbCmf2G2en6AJUS9IjAXAXlAAAAAAAA
--------------ms030800020400050902020303--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAIERt25051053 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Nov 2008 07:27:55 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAIERt8x051052; Tue, 18 Nov 2008 07:27:55 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.carillon.ca (mail.carillon.ca [207.115.107.27]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAIERi8Y051037 for <[e-mail]>; Tue, 18 Nov 2008 07:27:55 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost [127.0.0.1]) by mail.carillon.ca (Postfix) with ESMTP id 73154328083 for <[e-mail]>; Tue, 18 Nov 2008 09:27:43 -0500 (EST)
Received: from mail.carillon.ca ([127.0.0.1]) by localhost (rhea.carillon.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m4CgP+Zz9Ndb for <[e-mail]>; Tue, 18 Nov 2008 09:27:38 -0500 (EST)
Received: from carillon.dcoombs.ca (69-196-152-118.dsl.teksavvy.com [69.196.152.118]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.carillon.ca (Postfix) with ESMTP id 08BCD32801B for <[e-mail]>; Tue, 18 Nov 2008 09:27:38 -0500 (EST)
From: Patrick Patterson <[e-mail]>
Reply-To: [e-mail]
Organization: Carillon Information Security Inc.
To: [e-mail]
Subject: Re: The EU Signature Directive - A 15+15 Year Perspective
Date: Tue, 18 Nov 2008 09:27:22 -0500
User-Agent: KMail/1.9.10
References: <1E0ECAB75B5B496F942BC7D49F9D7DA5@AndersPC> <[e-mail]> <3F7D87D9792849A28D560DC8341AC63F@AndersPC>
In-Reply-To: <3F7D87D9792849A28D560DC8341AC63F@AndersPC>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
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 Anders:

On November 18, 2008 08:35:24 am Anders Rundgren wrote:
> Hi Juergen,
>
> Should I interpret your response like following?  In Germany you can buy
> special equipment or services in which a company official (CFO?) puts
> another instance of his/her smart card, and then this card is used to
> automatically sign outgoing invoices that this card-owner typically has
> neither seen nor have direct control of, including when he or she is at
> home sleeping?
>
Just how is this different from the signature printers that are used on all 
cheques issued by larger companies? Or the signature stamp that has been in 
use by accounting departments for at least a century?

> This is sometimes referred to as the "hostage" PKI solution and must be one
> of the most flagrant examples of "pushing the envelope" ever heard of,
> since this scheme obviously was not the intent with the EU signature
> directive.
>
No, this is business reality - one needs an "officer of the company" to sign 
documents (be they cheques, invoices, purchase orders, etc.), and no company 
over a couple of hundred employees is going to make their CFO and COO sit 
down and spend their days signing documents. They will use either the printed 
(or stamped) equivalent of their handwritten signature, or the PKI 
alternative.

As long as the use of these signatures is controlled by policy, and is 
accountable, then just because it isn't a "pure" implementation, doesn't mean 
that it isn't valid.

As an aside, this is one of the reasons that in the Aerospace industry, we're 
working on the concept of "Organisational" certificates (PKI analog to the 
corporate seal). It neatly side-steps the mental block that some people have 
regarding "one person, one key", and allows anyone who is authorised to "sign 
on behalf of the company" to use the PKI based corporate seal.


-- 
Patrick Patterson
President and Chief PKI Architect,
Carillon Information Security Inc.
http://www.carillon.ca



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAIDZNMX047872 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Nov 2008 06:35:23 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAIDZNvG047871; Tue, 18 Nov 2008 06:35:23 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pne-smtpout1-sn2.hy.skanova.net (pne-smtpout1-sn2.hy.skanova.net [81.228.8.83]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAIDZMg0047865 for <[e-mail]>; Tue, 18 Nov 2008 06:35:23 -0700 (MST) (envelope-from [e-mail])
Received: from AndersPC (81.232.45.215) by pne-smtpout1-sn2.hy.skanova.net (7.3.129) id 48A144C5019ED93E; Tue, 18 Nov 2008 14:35:16 +0100
Message-ID: <3F7D87D9792849A28D560DC8341AC63F@AndersPC>
From: "Anders Rundgren" <[e-mail]>
To: "Juergen Brauckmann" <[e-mail]>
Cc: <[e-mail]>
References: <1E0ECAB75B5B496F942BC7D49F9D7DA5@AndersPC> <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: Re: The EU Signature Directive - A 15+15 Year Perspective
Date: Tue, 18 Nov 2008 14:35:24 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_01AE_01C9498A.E444D300"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Windows Mail 6.0.6000.20661
X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16669
Sender: [e-mail]
Precedence: 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_01AE_01C9498A.E444D300
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Juergen,

Should I interpret your response like following?  In Germany you can buy =
special equipment or services in which a company official (CFO?) puts =
another instance of his/her smart card, and then this card is used to =
automatically sign outgoing invoices that this card-owner typically has =
neither seen nor have direct control of, including when he or she is at =
home sleeping?

This is sometimes referred to as the "hostage" PKI solution and must be =
one of the most flagrant examples of "pushing the envelope" ever heard =
of, since this scheme obviously was not the intent with the EU signature =
directive.

Anders Rundgren


----- Original Message -----=20
From: "Juergen Brauckmann" <[e-mail]>
To: "Anders Rundgren" <[e-mail]>
Cc: <[e-mail]>
Sent: Tuesday, November 18, 2008 12:56
Subject: Re: The EU Signature Directive - A 15+15 Year Perspective


Anders Rundgren wrote:
> hard-core signature experts who for example in Germany managed=20
> to make PKI a *DISABLER* by outlawing non-human digital signatures on=20
> invoices.  That German paper-invoices do not even require=20
> signatures makes this position a true mystery.

It is my understanding that requiring qualified digital signature on=20
invoices is targeted against VAT refund fraud.

Actually there are several products and services that you can buy to=20
automate qualified signature creation; google shows you some of them if=20
you ask for "signature server".

J=FCrgen

------=_NextPart_000_01AE_01C9498A.E444D300
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.6000.20927" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2>Hi Juergen,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Should I interpret&nbsp;your =
response&nbsp;like=20
following?&nbsp; In Germany you can buy special equipment or services in =
which a=20
company official (CFO?)&nbsp;puts another instance of his/her smart =
card, and=20
then this card is used to <EM>automatically sign outgoing invoices</EM> =
that=20
this card-owner typically has neither seen nor have direct control of, =
including=20
when he or she is at home sleeping?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>This is sometimes referred =
to&nbsp;as&nbsp;the=20
"hostage" PKI solution and must be</FONT><FONT face=3DArial size=3D2> =
one of the=20
most flagrant examples of "pushing the envelope" ever heard of, since =
this=20
scheme&nbsp;obviously was not the intent with&nbsp;the EU signature=20
directive.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Anders Rundgren</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>----- Original Message ----- </FONT>
<DIV><FONT face=3DArial size=3D2>From: "Juergen Brauckmann" =
&lt;</FONT><A=20
href=3D"mailto:[e-mail]"><FONT face=3DArial=20
size=3D2>[e-mail]</FONT></A><FONT face=3DArial=20
size=3D2>&gt;</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>To: "Anders Rundgren" &lt;</FONT><A=20
href=3D"mailto:[e-mail]"><FONT face=3DArial=20
size=3D2>[e-mail]</FONT></A><FONT face=3DArial=20
size=3D2>&gt;</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Cc: &lt;</FONT><A=20
href=3D"mailto:[e-mail]"><FONT face=3DArial=20
size=3D2>[e-mail]</FONT></A><FONT face=3DArial =
size=3D2>&gt;</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Sent: Tuesday, November 18, 2008 =
12:56</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Subject: Re: The EU Signature Directive =
- A 15+15=20
Year Perspective</FONT></DIV></DIV>
<DIV><FONT face=3DArial><BR><FONT size=3D2></FONT></FONT></DIV><FONT =
face=3DArial=20
size=3D2>Anders Rundgren wrote:<BR>&gt; hard-core signature experts who =
for=20
example in Germany managed <BR>&gt; to make PKI a *DISABLER* by =
outlawing=20
non-human digital signatures on <BR>&gt; invoices.&nbsp; That German=20
paper-invoices do not even require <BR>&gt; signatures makes this =
position a=20
true mystery.<BR><BR>It is my understanding that requiring qualified =
digital=20
signature on <BR>invoices is targeted against VAT refund =
fraud.<BR><BR>Actually=20
there are several products and services that you can buy to <BR>automate =

qualified signature creation; google shows you some of them if <BR>you =
ask for=20
"signature server".<BR><BR>J=FCrgen<BR></FONT></BODY></HTML>

------=_NextPart_000_01AE_01C9498A.E444D300--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAIBuKMQ042028 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Nov 2008 04:56:20 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAIBuKRk042027; Tue, 18 Nov 2008 04:56:20 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sam.dfn-cert.de (sam.dfn-cert.de [193.174.13.196]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAIBu85X042012 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Tue, 18 Nov 2008 04:56:20 -0700 (MST) (envelope-from [e-mail])
Received: from [193.174.12.38] (fozzie.dfn-cert.de [193.174.12.38]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Registrierungsstelle DFN-CERT Services GmbH ", Issuer "DFN-CERT Services GmbH CA - G02" (verified OK)) by animal.dfn-cert.de (Postfix) with ESMTP id E424C2578045; Tue, 18 Nov 2008 12:57:03 +0100 (CET)
Message-ID: <[e-mail]>
Date: Tue, 18 Nov 2008 12:56:01 +0100
From: Juergen Brauckmann <[e-mail]>
Organization: DFN-CERT Services GmbH
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.16) Gecko/20080702 SeaMonkey/1.1.11
MIME-Version: 1.0
To: Anders Rundgren <[e-mail]>
CC: [e-mail]
Subject: Re: The EU Signature Directive - A 15+15 Year Perspective
References: <1E0ECAB75B5B496F942BC7D49F9D7DA5@AndersPC>
In-Reply-To: <1E0ECAB75B5B496F942BC7D49F9D7DA5@AndersPC>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Sender: [e-mail]
Precedence: 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 wrote:
> hard-core signature experts who for example in Germany managed=20
> to make PKI a *DISABLER* by outlawing non-human digital signatures on=20
> invoices.  That German paper-invoices do not even require=20
> signatures makes this position a true mystery.

It is my understanding that requiring qualified digital signature on=20
invoices is targeted against VAT refund fraud.

Actually there are several products and services that you can buy to=20
automate qualified signature creation; google shows you some of them if=20
you ask for "signature server".

J=FCrgen



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAIAbhAu036662 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Nov 2008 03:37:53 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAIAbhop036661; Tue, 18 Nov 2008 03:37:43 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pne-smtpout1-sn2.hy.skanova.net (pne-smtpout1-sn2.hy.skanova.net [81.228.8.83]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAIAbWDl036646 for <[e-mail]>; Tue, 18 Nov 2008 03:37:43 -0700 (MST) (envelope-from [e-mail])
Received: from AndersPC (81.232.45.215) by pne-smtpout1-sn2.hy.skanova.net (7.3.129) id 48A144C5019E032F for [e-mail]; Tue, 18 Nov 2008 11:37:31 +0100
Message-ID: <1E0ECAB75B5B496F942BC7D49F9D7DA5@AndersPC>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>
Subject: The EU Signature Directive - A 15+15 Year Perspective
Date: Tue, 18 Nov 2008 11:37:39 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0104_01C94972.0F669410"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Windows Mail 6.0.6000.20661
X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16669
Sender: [e-mail]
Precedence: 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_0104_01C94972.0F669410
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Some 15 years ago the EU launched a signature directive.  This posting =
tries to describe the consequences of this directive with respect to =
usage of PKI.

Primary Motivation

There are a number of processes needing a human-written signature in =
order to fulfill legal requirements.

Some of these processes could without doubt be possible to carry out =
electronically and thus also remote over a network, if there was some =
kind of technology available that could serve as a replacement for a =
hand-written signature.

The Solution

Right or wrong, digital signatures using PKI were considered as a viable =
alternative.  To make PKI a credible solution, the EU signature =
directive added a number of requirements including characteristics of =
the signature creation device and policies for CAs.

Current Deployment

Apart from Qualified Certificates which (for reasons too diverse for =
describing in an email) have not become truly mainstream, the EU =
signature directive have indeed in local legislations made it possible =
to perform fairly qualified tasks remotely over the Internet.  I.e. the =
directive has functioned as an ENABLER.

Then Something Went Wrong...

Unfortunately, a few (but influential) people got a bit carried away and =
interpreted the signature directive in way that has severely hampered =
the use of PKI.  Essentially they began claiming that all messages in =
order to be trustworthy should be signed by a qualified signature or at =
least by a digital signature created under the direct control a human =
being.

>From a 50000 ft perspective this may sound like a great idea, but the =
fact is that decades before the signature directive was conceived; yes, =
even before PKI was invented, the concept of secure messaging actually =
existed.  Back in those days secure messaging was facilitated through =
the use of leased lines which allowed banks (and some early b2b =
networks), to securely exchange transaction messages in a completely =
automated fashion.

An example:  If you want to wire-transfer money from your bank to =
another bank, the way the transfer is initiated (phone, paper, on-line, =
etc) has no impact on the transaction messaging because it is performed =
in a transaction network that neither the customers, nor most of the =
staff have direct access to.=20

That such networks have proved to be secure, reliable, cost-efficient, =
and sometimes even globally scalable, apparently did not impress the =
bunch of hard-core signature experts who for example in Germany managed =
to make PKI a DISABLER by outlawing non-human digital signatures on =
invoices.  That German paper-invoices do not even require signatures =
makes this position a true mystery.

One had hoped that this would be an exception to the rule but it is not; =
If you scan sites like NIST.GOV, CIO.GOV, and GSA.GOV you'll find =
literally thousands of security-related documents, indeed in a few =
places mentioning PKI, but mostly full of government regulation =
abbreviations like FISMA, giving little if any guidance on how to create =
secure messaging between agencies, not to mention between agencies and =
the private sector.

I'm happy to see that the Nordic countries plus Estonia have realized =
that all signatures that can be securely bound to an entity (in =
practice) are legally binding, in the extremely rare case somebody would =
actually repudiate a signed invoice.   These governments have all (and =
independently of each other) created local variants of a scheme that I =
have described in:
http://webpki.org/papers/web/gateway.pdf
which could be characterized as a 21st century version of leased lines =
for multi-party automated secure messaging.

It will probably take another 15 years for this concept to achieve =
general acceptance although it is really (if you look closely) very =
similar to the US e-Authentication scheme, they have just not connected =
the dots yet: A SAML assertion and an server-signed invoice from a =
specific entity are essentially only different in content, not in =
trustworthiness.

Anders Rundgren
http://WebPKI.org


------=_NextPart_000_0104_01C94972.0F669410
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.6000.20927" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Some 15 years ago the EU launched a =
signature=20
directive.&nbsp; This posting tries to describe the consequences of this =

directive with respect to usage of PKI.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial><STRONG>Primary Motivation</STRONG></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>There are a number of =
processes&nbsp;needing a=20
human-written signature in order to fulfill legal =
requirements.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Some of these processes could without =
doubt be=20
possible to carry out electronically and thus also remote over a =
network, if=20
there was some kind of technology available that could serve as a =
replacement=20
for a hand-written signature.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial><STRONG>The Solution</STRONG></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Right or wrong, digital signatures =
using PKI were=20
considered as&nbsp;a viable&nbsp;alternative.&nbsp; To make PKI a =
credible=20
solution, the EU signature directive added a number of requirements =
including=20
characteristics of the signature creation device and policies for=20
CAs.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial><STRONG>Current Deployment</STRONG></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><FONT face=3DArial size=3D2>Apart from =
Qualified=20
Certificates which (for reasons too diverse for describing in an email) =
have not=20
become truly mainstream, the EU signature directive have indeed in local =

legislations made it possible to perform fairly qualified tasks remotely =
over=20
the Internet.&nbsp; I.e. the directive has functioned as an=20
<STRONG>ENABLER</STRONG>.</FONT></DIV>
<DIV></FONT><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial><STRONG>Then Something=20
Went&nbsp;Wrong...</STRONG></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Unfortunately, a few =
(but&nbsp;influential) people=20
got a bit carried away and interpreted the signature directive in way =
that has=20
severely hampered the use of PKI.&nbsp; Essentially they began claiming =
that all=20
messages in order to be&nbsp;trustworthy should be signed by a qualified =

signature or at least by a digital signature created&nbsp;under the =
direct=20
control&nbsp;a human being.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>From a 50000 ft perspective this may =
sound like a=20
great idea, but the fact is that decades before the signature directive =
was=20
conceived; yes, even before PKI was invented, the concept of secure =
messaging=20
actually existed.&nbsp;&nbsp;Back in those days&nbsp;secure messaging =
was=20
facilitated through the use of leased lines which allowed banks (and =
some early=20
b2b networks), to securely exchange transaction messages <EM>in a =
completely=20
automated fashion</EM>.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>An example:&nbsp; If you want to =
wire-transfer=20
money from your bank to another bank, the way the transfer is initiated =
(phone,=20
paper,&nbsp;on-line, etc)&nbsp;has no impact on the transaction =
messaging=20
because it is&nbsp;performed in a transaction network that neither=20
the&nbsp;customers, nor&nbsp;most of the staff have direct access=20
to.&nbsp;</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>That&nbsp;such networks have proved to =
be secure,=20
reliable, cost-efficient, and sometimes even globally scalable, =
apparently did=20
not impress the bunch of hard-core signature experts who for example in =
Germany=20
managed to make PKI a <STRONG>DISABLER</STRONG> by outlawing non-human =
digital=20
signatures on invoices.&nbsp; That German paper-invoices do not even =
require=20
signatures&nbsp;makes this position a true mystery.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>One had hoped that this would be an =
exception to=20
the rule but it is not; If you scan sites like NIST.GOV, CIO.GOV, and =
GSA.GOV=20
you'll find literally thousands of security-related documents, indeed in =
a few=20
places mentioning PKI, but mostly full of government regulation =
abbreviations=20
like FISMA, giving little if any guidance on how to create secure =
messaging=20
between agencies, not to mention between agencies and the private=20
sector.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>I'm happy to see&nbsp;that the Nordic =
countries=20
plus Estonia have realized that all signatures that can be securely =
bound to an=20
entity (in practice) are legally binding, in the extremely rare case =
somebody=20
would actually repudiate a signed invoice.&nbsp;&nbsp; These governments =
have=20
all (and independently of each other) created local variants of&nbsp;a =
scheme=20
that I have described in:</FONT></DIV>
<DIV><A href=3D"http://webpki.org/papers/web/gateway.pdf"><FONT =
face=3DArial=20
size=3D2>http://webpki.org/papers/web/gateway.pdf</FONT></A></DIV>
<DIV><FONT face=3DArial size=3D2>which&nbsp;could be characterized =
as&nbsp;a 21st=20
century version of leased lines for multi-party&nbsp;automated secure=20
messaging.</FONT><BR></DIV>
<DIV><FONT face=3DArial size=3D2>It will probably take another 15 years =
for this=20
concept to achieve general acceptance although it is really (if you look =

closely) very similar&nbsp;to the US e-Authentication scheme, they have =
just not=20
connected the dots yet:&nbsp;A SAML assertion and an =
server-signed&nbsp;invoice=20
from a specific entity are essentially only different in content, not in =

trustworthiness.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Anders Rundgren</FONT></DIV>
<DIV><FONT face=3DArial size=3D2><A=20
href=3D"http://WebPKI.org">http://WebPKI.org</A></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_0104_01C94972.0F669410--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAI46Ge9017710 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Nov 2008 21:06:16 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAI46Gma017709; Mon, 17 Nov 2008 21:06:16 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from QMTA07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAI462uh017699 for <[e-mail]>; Mon, 17 Nov 2008 21:06:14 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Received: from OMTA10.westchester.pa.mail.comcast.net ([76.96.62.28]) by QMTA07.westchester.pa.mail.comcast.net with comcast id gRtf1a0210cZkys57U5E2e; Tue, 18 Nov 2008 04:05:14 +0000
Received: from MIKES-LAPTOM.comcast.net ([12.104.246.2]) by OMTA10.westchester.pa.mail.comcast.net with comcast id gU5p1a00M03q6N43WU5sWA; Tue, 18 Nov 2008 04:05:58 +0000
X-Authority-Analysis: v=1.0 c=1 a=4UOdyLgRf7hS5PBf1gkA:9 a=cLIBl4n2XXj8lpqK7F21mpKBT4YA:4 a=1zCgxjP13n0A:10
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Mon, 17 Nov 2008 23:05:50 -0500
To: Eric Norman <[e-mail]>, [e-mail]
From: Michael StJohns <[e-mail]>
Subject: Re: encoding an X.509 certificate
In-Reply-To: <[e-mail]>
References: <[e-mail]> <p06240514c5474e7c5e53@[130.129.30.0]> <[e-mail]> <p06240516c5476ce48e9a@[130.129.30.0]> <[e-mail]> <[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>

Eric - if you're referring to "be generous in what you accept" - that's probably not a great idea for things related to security.

E.g. accepting a library card when the preferred credential is a driver's license is probably not a good idea, even though both encode an identity.

Mike


At 04:12 PM 11/17/2008, Eric Norman wrote:


>On Nov 17, 2008, at 3:08 PM, Eric Norman wrote:
>
>>So is someone receives a certificate,
>>and the certificate signature would verify if it (TBS part) were used as received,
>>but some parts of the certificate are BER but not DER encoded,
>>then certificate validation should fail?
>
>To be clear.
>
>Why shouldn't the robustness principle apply in this case?
>
>Eric Norman




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAI1fwjM009810 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Nov 2008 18:41:58 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAI1fw1A009809; Mon, 17 Nov 2008 18:41:58 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.144]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAI1fkZ7009793 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Mon, 17 Nov 2008 18:41:57 -0700 (MST) (envelope-from [e-mail])
Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e4.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id mAI1fUJx001941 for <[e-mail]>; Mon, 17 Nov 2008 20:41:30 -0500
Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id mAI1fVED138606 for <[e-mail]>; Mon, 17 Nov 2008 20:41:35 -0500
Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id mAI1fUEq028959 for <[e-mail]>; Mon, 17 Nov 2008 20:41:31 -0500
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.56.228.115]) by d01av01.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id mAI1fUN8028956; Mon, 17 Nov 2008 20:41:30 -0500
In-Reply-To: <p06240514c5474e7c5e53@[130.129.30.0]>
To: Stephen Kent <[e-mail]>
Cc: [e-mail], [e-mail], Peter Gutmann <[e-mail]>, "Timothy J. Miller" <[e-mail]>
MIME-Version: 1.0
Subject: Re: encoding an X.509 certificate
X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006
From: Tom Gindin <[e-mail]>
Message-ID: <[e-mail]>
Date: Mon, 17 Nov 2008 20:41:29 -0500
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 8.0.1 HF1|June 13, 2008) at 11/17/2008 20:41:30, Serialize complete at 11/17/2008 20:41:30
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>

        Steve:

        As a theoretical exercise, let us assume that a relying party 
encounters the following encoding as part of the value of a non-critical 
extension with syntax unknown to the relying party: A1 13 16 03 4F 6E 65 
16 07 45 78 61 6D 70 6C 65 16 03 4E 6F 77.
        How can the relying party tell whether this is a valid DER 
encoding of [1] IMPLICIT SEQUENCE OF PrintableString, an encoding of [1] 
IMPLICIT PrintableString which violates section 10.2 of X.690, or an 
encoding of [1] IMPLICIT SET OF PrintableString which violates section 
11.6 of X.690?  The component string values are "One", "Example", and 
"Now".
        I am not convinced that "re-encode as DER" can be performed by 
general purpose library code.  One can verify that the certificate down to 
the OCTET STRING wrappings for extension values is in DER, but one cannot 
always tell whether the inner values of extensions are in DER, let alone 
re-encode them into DER.

                Tom Gindin

P.S - The above opinions (and those in my last post as well) are mine and 
not necessarily those of my employer




Stephen Kent <[e-mail]> 
11/17/2008 11:40 AM

To
Tom Gindin/Watson/IBM@IBMUS
cc
"Timothy J. Miller" <[e-mail]>, [e-mail], 
[e-mail], Peter Gutmann <[e-mail]>
Subject
Re: encoding an X.509 certificate






At 8:22 PM -0500 11/12/08, Tom Gindin wrote:
>         "Conservative in what you produce" - CA code should generate 
DER.
>Not all such code does so, but it should.
>         "Liberal in what you accept" - RP code should verify signatures 
on
>the supplied binary TBSCertificate, rather than re-encoding.  For parsing
>code to accept BER which isn't valid DER is almost harmless.    There may
>well have been a good reason for believing that DER was more secure than
>BER against various digest collision or pre-image attacks when X.509v1 
was
>in use and all certificate content had syntax verifiable by every RP (at
>least in theory).  With non-critical extensions, that is no longer the
>case.
>
>                 Tom Gindin

Tom,

I have to disagree. The standards call for DER to be used for 
signature generation and validation. They are generally silent on 
transport encoding. If we say that an RP should just try to verify 
the signature on whatever it receives, then we encourage (more) 
sloppy behavior by CAs. The preferred approach is for the RP to 
encode the received cert into DER before checking.

Steve




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAHLCuSs096162 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Nov 2008 14:12:56 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAHLCusY096161; Mon, 17 Nov 2008 14:12:56 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from agogare.doit.wisc.edu (agogare.doit.wisc.edu [144.92.197.211]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAHLCtnb096155 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL) for <[e-mail]>; Mon, 17 Nov 2008 14:12:56 -0700 (MST) (envelope-from [e-mail])
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; charset=US-ASCII; format=flowed
Received: from avs-daemon.smtpauth2.wiscmail.wisc.edu by smtpauth2.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 6.3-6.03 (built Mar 14 2008; 32bit)) id <[e-mail]> for [e-mail]; Mon, 17 Nov 2008 15:12:55 -0600 (CST)
Received: from [192.168.0.14] (static.unknown.charter.com [97.92.189.144]) by smtpauth2.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 6.3-6.03 (built Mar 14 2008; 32bit)) with ESMTPSA id <[e-mail]> for [e-mail]; Mon, 17 Nov 2008 15:12:53 -0600 (CST)
Date: Mon, 17 Nov 2008 15:12:51 -0600
From: Eric Norman <[e-mail]>
Subject: Re: encoding an X.509 certificate
In-reply-to: <[e-mail]>
To: [e-mail]
Message-id: <[e-mail]>
X-Mailer: Apple Mail (2.624)
X-Spam-Report: AuthenticatedSender=yes, SenderIP=97.92.189.144
X-Spam-PmxInfo: Server=avs-14, Version=5.4.2.344556, Antispam-Engine: 2.6.0.325393, Antispam-Data: 2008.11.17.210129, SenderIP=97.92.189.144
References: <[e-mail]> <p06240514c5474e7c5e53@[130.129.30.0]> <[e-mail]> <p06240516c5476ce48e9a@[130.129.30.0]> <[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>

On Nov 17, 2008, at 3:08 PM, Eric Norman wrote:

> So is someone receives a certificate,
> and the certificate signature would verify if it (TBS part) were used 
> as received,
> but some parts of the certificate are BER but not DER encoded,
> then certificate validation should fail?

To be clear.

Why shouldn't the robustness principle apply in this case?

Eric Norman



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAHL93Ia095830 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Nov 2008 14:09:03 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAHL93ZC095829; Mon, 17 Nov 2008 14:09:03 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from agogare.doit.wisc.edu (agogare.doit.wisc.edu [144.92.197.211]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAHL8qEN095818 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL) for <[e-mail]>; Mon, 17 Nov 2008 14:09:03 -0700 (MST) (envelope-from [e-mail])
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; charset=US-ASCII; format=flowed
Received: from avs-daemon.smtpauth2.wiscmail.wisc.edu by smtpauth2.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 6.3-6.03 (built Mar 14 2008; 32bit)) id <[e-mail]> for [e-mail]; Mon, 17 Nov 2008 15:08:51 -0600 (CST)
Received: from [192.168.0.14] (static.unknown.charter.com [97.92.189.144]) by smtpauth2.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 6.3-6.03 (built Mar 14 2008; 32bit)) with ESMTPSA id <[e-mail]> for [e-mail]; Mon, 17 Nov 2008 15:08:47 -0600 (CST)
Date: Mon, 17 Nov 2008 15:08:46 -0600
From: Eric Norman <[e-mail]>
Subject: Re: encoding an X.509 certificate
In-reply-to: <p06240516c5476ce48e9a@[130.129.30.0]>
To: [e-mail]
Message-id: <[e-mail]>
X-Mailer: Apple Mail (2.624)
X-Spam-Report: AuthenticatedSender=yes, SenderIP=97.92.189.144
X-Spam-PmxInfo: Server=avs-13, Version=5.4.2.344556, Antispam-Engine: 2.6.0.325393, Antispam-Data: 2008.11.17.205209, SenderIP=97.92.189.144
References: <[e-mail]> <p06240514c5474e7c5e53@[130.129.30.0]> <[e-mail]> <p06240516c5476ce48e9a@[130.129.30.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>

On Nov 17, 2008, at 12:50 PM, Stephen Kent wrote:

> At 11:24 AM -0600 11/17/08, Eric Norman wrote:
>> So if someone receives a bit blob that contains a certificate,
>> and the signature would verify if the bit blob was used,
>> but some parts of that bit blob are BER but not DER encoded,
>> then certificate validation should fail?
>>
>> Eric Norman
>
> We're talking about certs, not blobs that contain certs.

OK.

So is someone receives a certificate,
and the certificate signature would verify if it (TBS part) were used 
as received,
but some parts of the certificate are BER but not DER encoded,
then certificate validation should fail?

Eric Norman



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAHKqoW9095080 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Nov 2008 13:52:50 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAHKqojZ095079; Mon, 17 Nov 2008 13:52:50 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAHKqdZR095071 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 17 Nov 2008 13:52:50 -0700 (MST) (envelope-from [e-mail])
Received: from dommiel.bbn.com ([192.1.122.15] helo=[130.129.30.0]) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from <[e-mail]>) id 1L2B5J-0006lD-BG; Mon, 17 Nov 2008 15:52:37 -0500
Mime-Version: 1.0
Message-Id: <p06240501c547897161bb@[130.129.30.0]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <p06240514c5474e7c5e53@[130.129.30.0]> <[e-mail]> <p06240516c5476ce48e9a@[130.129.30.0]> <[e-mail]>
Date: Mon, 17 Nov 2008 15:51:16 -0500
To: "Timothy J. Miller" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: encoding an X.509 certificate
Cc: Eric Norman <[e-mail]>, [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 2:31 PM -0600 11/17/08, Timothy J. Miller wrote:
>Stephen Kent wrote:
>
>>We're talking about certs, not blobs that contain certs.
>
>You can't fix interoperability in someone else's application.  You 
>can only address interoperability in your own.

agreed.

>You *can* make it embarrassing for the bad player.  That's the point 
>of things like the USB trademark.
>
>-- Tim

agreed.

Pity we don't have a "PKIX Compliant" trademark :-).

Steve



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAHKVGhQ094018 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Nov 2008 13:31:16 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAHKVGFl094017; Mon, 17 Nov 2008 13:31:16 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAHKV5NJ094005 for <[e-mail]>; Mon, 17 Nov 2008 13:31:16 -0700 (MST) (envelope-from [e-mail])
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id mAHKV49D012653 for <[e-mail]>; Mon, 17 Nov 2008 15:31:05 -0500
Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id mAHKV4ul012643; Mon, 17 Nov 2008 15:31:04 -0500
Received: from [129.83.200.5] (129.83.200.5) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server (TLS) id 8.1.311.2; Mon, 17 Nov 2008 15:31:04 -0500
Message-ID: <[e-mail]>
Date: Mon, 17 Nov 2008 14:31:01 -0600
From: "Timothy J. Miller" <[e-mail]>
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
CC: Eric Norman <[e-mail]>, [e-mail]
Subject: Re: encoding an X.509 certificate
References: <[e-mail]> <p06240514c5474e7c5e53@[130.129.30.0]> <[e-mail]> <p06240516c5476ce48e9a@[130.129.30.0]>
In-Reply-To: <p06240516c5476ce48e9a@[130.129.30.0]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020006050004060602030603"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

Stephen Kent wrote:

> We're talking about certs, not blobs that contain certs.

You can't fix interoperability in someone else's application.  You can 
only address interoperability in your own.

You *can* make it embarrassing for the bad player.  That's the point of 
things like the USB trademark.

-- Tim


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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKvjCC
A2cwggJPoAMCAQICAh8FMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEe
MBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3Jh
dGlvbiBQcmltYXJ5IENBLTEwHhcNMDgwODIxMTUzMTI5WhcNMTAwMjEyMTUzMTI5WjBaMRIw
EAYDVQQKEwltaXRyZS5vcmcxDzANBgNVBAsTBnBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3Rt
aWxsZXIxGjAYBgNVBAMTEU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQCTxM+z5fDKvmBInGatv0DkVwuOxd69S2M2jho8QkOltYJK/4JUm9uK0UtQZkyI
bEjmCpmXLw17iMCgA0SjwuUfJxdF8ntTys8keyMjRdlKSwFnkgZl9tL7o060LBtZQYzI5ajr
W9k3N768G/k1bZS5UYiMGHU5+Ygl4IwVhmQv3wIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF
4DAdBgNVHQ4EFgQUSXARqmj5Bl2Lz7RLoUIkuOHl0MkwHwYDVR0jBBgwFoAUh7QPSI1iM0LB
LVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL3d3dy5taXRyZS5vcmcvdGVj
aC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1UdEQQVMBOBEXRtaWxsZXJAbWl0cmUu
b3JnMA0GCSqGSIb3DQEBBQUAA4IBAQAbA1PH/hed/rryO1f0yfTRJnD/vL1rFTduUut/irL7
FSXHGybuPHxydfyGPvJ4qj+T8hs1W0jTa2zQnaPR52tms3hefl76CNVP9vJoVmaM9svFX4DX
6eJh/4SAI81tAuBIK8gxsWd1Va/Bnnh1/wsZLc8w2jkojVqkT2AHPaHS3DBKX7QAWovXVSxY
QlqMIH4zvSNSVfpvpIf0MWJWRBPvgerVSbJsA4dz6ziKvXDWySTV9zwSuNjikNqL//nIKwjb
r3ZOfSUOxSuhW58an2Ha4TdORvG4dGJEsMzxbpTB+wt/s6tK6roONV4uiDtODBNVAG+XGofe
McsS0b7iXdxDMIIDZzCCAk+gAwIBAgICHwUwDQYJKoZIhvcNAQEFBQAwXTESMBAGA1UEChMJ
bWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAlBgNVBAMTHk1J
VFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMTAeFw0wODA4MjExNTMxMjlaFw0xMDAyMTIx
NTMxMjlaMFoxEjAQBgNVBAoTCW1pdHJlLm9yZzEPMA0GA1UECxMGcGVvcGxlMRcwFQYKCZIm
iZPyLGQBARMHdG1pbGxlcjEaMBgGA1UEAxMRTWlsbGVyIFRpbW90aHkgSi4wgZ8wDQYJKoZI
hvcNAQEBBQADgY0AMIGJAoGBAJPEz7Pl8Mq+YEicZq2/QORXC47F3r1LYzaOGjxCQ6W1gkr/
glSb24rRS1BmTIhsSOYKmZcvDXuIwKADRKPC5R8nF0Xye1PKzyR7IyNF2UpLAWeSBmX20vuj
TrQsG1lBjMjlqOtb2Tc3vrwb+TVtlLlRiIwYdTn5iCXgjBWGZC/fAgMBAAGjgbcwgbQwDgYD
VR0PAQH/BAQDAgXgMB0GA1UdDgQWBBRJcBGqaPkGXYvPtEuhQiS44eXQyTAfBgNVHSMEGDAW
gBSHtA9IjWIzQsEtURpIHsKeuwqxrTBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vd3d3Lm1p
dHJlLm9yZy90ZWNoL21paS9wa2kvY2ExX21pdHJlX29yZy5jcmwwHAYDVR0RBBUwE4ERdG1p
bGxlckBtaXRyZS5vcmcwDQYJKoZIhvcNAQEFBQADggEBABsDU8f+F53+uvI7V/TJ9NEmcP+8
vWsVN25S63+KsvsVJccbJu48fHJ1/IY+8niqP5PyGzVbSNNrbNCdo9Hna2azeF5+XvoI1U/2
8mhWZoz2y8VfgNfp4mH/hIAjzW0C4EgryDGxZ3VVr8GeeHX/CxktzzDaOSiNWqRPYAc9odLc
MEpftABai9dVLFhCWowgfjO9I1JV+m+kh/QxYlZEE++B6tVJsmwDh3PrOIq9cNbJJNX3PBK4
2OKQ2ov/+cgrCNuvdk59JQ7FK6FbnxqfYdrhN05G8bh0YkSwzPFulMH7C3+zq0rqug41Xi6I
O04ME1UAb5cah94xyxLRvuJd3EMwggPkMIICzKADAgECAgEFMA0GCSqGSIb3DQEBBQUAMFox
EjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MSQw
IgYDVQQDExtNSVRSRSBDb3Jwb3JhdGlvbiBSb290IENBLTEwHhcNMDYwNjAzMTcxMzIyWhcN
MTIwNjAzMTcxMzIyWjBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmlj
YXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0x
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyPB7Vl0QgqgQt0u8Q2duRs7eZUPn
hlflKPFPMXGG+iqGpImYs6nfbFPsn0q8FqklFsm/UEV2JJQ3c7Srwfrqe9CrCbVFh761OxZI
7fnUWiUasNP2ING19aAfrQ8IoJsAEtGzHeIacS+M5CN4C0yfUC6CpBZTc9ZldjLUatvJr407
K1i+7WnrRsMVKhICfgmiO/XiVR9YeXyzeRqFrLy6YtJCJuJd0QRfwKtKRpek5oU67Izr7ClH
DtPJs7UOTjMYBS2fTzztC+wwOTp6+A3ZbEymuQcAZRwmGkjVBe2R8MiX26R02Iigz+903ZAL
/6bpvx0DnkrlR2UFr1KBGfBqmQIDAQABo4GxMIGuMBIGA1UdEwEB/wQIMAYBAf8CAQIwDgYD
VR0PAQH/BAQDAgGGMB0GA1UdDgQWBBSHtA9IjWIzQsEtURpIHsKeuwqxrTAfBgNVHSMEGDAW
gBTHcFEA2E3+5AHUaJbFPZ+al/50LzBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vd3d3Lm1p
dHJlLm9yZy90ZWNoL21paS9wa2kvcm9vdGNhMV9taXRyZV9vcmcuY3JsMA0GCSqGSIb3DQEB
BQUAA4IBAQBNbm7rrins3SICPbteX9qSN1+RJClqix/pw3IAe7u60LK0V9jVZ9E2a+c0MZiS
ojdcwU5rXxI2OI2wwIf6wVBo76jIOc+IiQRlC+V8YatGmoibqP/8WDPzlud/WQAzkjrU2nuh
8KdyJG+n1kH/6772Lbra2CIk8mu8FypeaB5P2uIJzdE+PGo82ZiyU680ukiJ9yF6UmEXuciB
77tGQBRxMl6ePzIrArQnf48SmBhFD5XYLraueOiG7E+AzD99ig1M6WHcxWXtp3DIrVqE/DZr
146NJaCWqg9NoE14cmpEllnpWLtLnn5UBYJ+QCozmbe1SJXOOynZ0VxMnGdh7NqgMYICqDCC
AqQCAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1
dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTAJ
BgUrDgMCGgUAoIIBmzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0wODExMTcyMDMxMDFaMCMGCSqGSIb3DQEJBDEWBBTZ65yt9ejkYBPRw/gPLwfJ+P9w2jBS
BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D
AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNV
BAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQD
Ex5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAh8FMHQGCyqGSIb3DQEJEAILMWWg
YzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0
eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTANBgkqhkiG
9w0BAQEFAASBgAac1Pug8lX95TpmlvwX2Jpe8Z0PyrhDtuMKsAtsClrDlUORHgdxYdI70MY0
90Z8b26PagZ+rZizEPw7gGrPdPRql4rCWDFJaPcPOjVMRGh9HGsLU7tLhm/krHQneXwCEFUt
jJxof135YZGD3ie1RNzVYxjg/QMm31qXPmfD/DYMAAAAAAAA
--------------ms020006050004060602030603--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAHK4BU0092469 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Nov 2008 13:04:11 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAHK4Bk5092468; Mon, 17 Nov 2008 13:04:11 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mailhost.noorhome.net (adsl-63-194-79-229.dsl.snfc21.pacbell.net [63.194.79.229]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAHK40bX092438 for <[e-mail]>; Mon, 17 Nov 2008 13:04:10 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.noorhome.net (Postfix) with ESMTP id 491FE3AF1C7 for <[e-mail]>; Mon, 17 Nov 2008 14:38:41 -0500 (EST)
X-Spam-Score: -2.815
X-Spam-Level: 
X-Spam-Status: No, score=-2.815 tagged_above=-10 required=6.6 tests=[ALL_TRUSTED=-1.8, AWL=0.071, BAYES_00=-2.599, DNS_FROM_SECURITYSAGE=1.513]
Received: from mailhost.noorhome.net ([127.0.0.1]) by localhost (mailhost.noorhome.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C8F7hTCWMM+D for <[e-mail]>; Mon, 17 Nov 2008 14:38:40 -0500 (EST)
Received: from poseidon.noorhome.net (poseidon.noorhome.net [192.168.0.9]) by mailhost.noorhome.net (Postfix) with ESMTP id CBAD93AF190 for <[e-mail]>; Mon, 17 Nov 2008 14:38:40 -0500 (EST)
Message-ID: <[e-mail]>
Date: Mon, 17 Nov 2008 12:03:59 -0800
From: Arshad Noor <[e-mail]>
Organization: StrongAuth, Inc.
User-Agent: Thunderbird 2.0.0.16 (X11/20080723)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: encoding an X.509 certificate
References: <[e-mail]> <p06240514c5474e7c5e53@[130.129.30.0]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I trust you are being facetious, Julien.  If not, why bother with
standards efforts at all?  Lets all just cede the market to the
biggest players in the industry - no matter how ridiculous their
implementations may be - and call it a day.

Arshad Noor
StrongAuth, Inc.

Julien Stern wrote:
> 
> I think it really boils down to how big and powerful the company 
> implementing the validation is. If a BER encoded certificate (or a 
> certificate with a negative serial) is rejected by your implementation 
> AND if you can explain to your customers that YOU are doing the right 
> thing, then you are fine, otherwise, you'll have to patch your 
> implementation to accept the buggy certificates produced by a more 
> powerful entity than yours :)
> 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAHIttDK087395 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Nov 2008 11:55:55 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAHIttWP087394; Mon, 17 Nov 2008 11:55:55 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAHItsLi087388 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 17 Nov 2008 11:55:55 -0700 (MST) (envelope-from [e-mail])
Received: from dommiel.bbn.com ([192.1.122.15] helo=[130.129.30.0]) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from <[e-mail]>) id 1L29GK-0004tE-B6; Mon, 17 Nov 2008 13:55:52 -0500
Mime-Version: 1.0
Message-Id: <p06240516c5476ce48e9a@[130.129.30.0]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <p06240514c5474e7c5e53@[130.129.30.0]> <[e-mail]>
Date: Mon, 17 Nov 2008 13:50:09 -0500
To: Eric Norman <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: encoding an X.509 certificate
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 11:24 AM -0600 11/17/08, Eric Norman wrote:
>On Nov 17, 2008, at 10:40 AM, Stephen Kent wrote:
>
>>I have to disagree. The standards call for DER to be used for 
>>signature generation and validation. They are generally silent on 
>>transport encoding. If we say that an RP should just try to verify 
>>the signature on whatever it receives, then we encourage (more) 
>>sloppy behavior by CAs. The preferred approach is for the RP to 
>>encode the received cert into DER before checking.
>
>So if someone receives a bit blob that contains a certificate,
>and the signature would verify if the bit blob was used,
>but some parts of that bit blob are BER but not DER encoded,
>then certificate validation should fail?
>
>Eric Norman

We're talking about certs, not blobs that contain certs.

Steve



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAHIPpaZ086025 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Nov 2008 11:25:51 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAHIPpc1086024; Mon, 17 Nov 2008 11:25:51 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mAHIPg1q086010 for <[e-mail]>; Mon, 17 Nov 2008 11:25:50 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 26185 invoked from network); 17 Nov 2008 18:25:26 -0000
Received: from [e-mail] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;17 Nov 2008 18:25:26 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 17 Nov 2008 18:25:25 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C948E1.DC68836A"
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: I-D Action:draft-ietf-pkix-ta-mgmt-reqs-02.txt (second part)
Date: Mon, 17 Nov 2008 13:25:25 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: I-D Action:draft-ietf-pkix-ta-mgmt-reqs-02.txt (second part)
Thread-Index: Ack//VTYKJc2zWyEReWeiLacIJscWwGCrjOA
References: <[e-mail]> <[e-mail]>
From: "Carl Wallace" <[e-mail]>
To: "ietf-pkix" <[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>

This is a multi-part message in MIME format.

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

inline...


________________________________

	From: [e-mail]
[mailto:[e-mail]] On Behalf Of Denis Pinkas
	Sent: Thursday, November 06, 2008 5:27 AM
	To: ietf-pkix
	Subject: Re: I-D Action:draft-ietf-pkix-ta-mgmt-reqs-02.txt
(second part)
=09
=09
	In order to keep the message short, two answers are given on
this document.
	=20

	Comments on draft-ietf-pkix-ta-mgmt-reqs-02

	=20

	Topic: Clarifications needed about associated data, purpose and=20

	constraints.

	=20

	For most web browsers and Java machines, the current situation
is the=20

	following:

	=20

	   - self-signed certificates are used for all purposes, e.g.
TLS server,

	     TLS client, sending e-mails, receiving e-mails, applets'
signatures,

	     and

	=20

	   - it is unknown whether revocation conditions are checked and
how.

	=20

	Suppose (for the time being) that we want to move from the
current=20

	situation where self-signed certificates are placed in the same
storage and=20

	hence used for all purposes to a situation where self-signed
certificates=20

	are no more used for any purpose, e.g. used for sending e-mails
or used for=20

	receiving e-mails.

	=20

	There are two possible approaches:

	=20

	   a) consider a given a *purpose*, e.g. applets' signatures,
and then=20

	      list all self-signed certificates that can be used for
such a

	      purpose, or

	=20

	   b) consider each self-signed certificate and tell for which
purpose=20

	      that self-signed certificate may be used.

	=20

	If we take into consideration the "need-to-know" requirement,
some=20

	applications need to know which self-signed certificates shall
be used for=20

	a given purpose and do not need to know if they are also used
for a=20

	different purpose.=20

	=20

=09

	The approach a) fulfils this requirement, but not the approach
b).

	=20

	When a path validation must be done for a given purpose, case a)
is rather=20

	straightforward: all the information is under the purpose.

	=20

	With case b), this would be more difficult, since the
application would=20

	need to scan every "Trust Anchor" store (?) and look if the
given purpose=20

	is mentioned under a "Trust Anchor".

	=20

	Case a) allows a clear and clean separation of information.
However, it=20

	seems that the document has implicitly chosen case b). :-(=20

	=20

	[CRW] This document does not choose a) or b).  You are
describing implementation details for how a trust anchor store is
queried.  We're not defining an API for interacting with a trust anchor
store.

	=20

	It is unclear in the current document what is the relationship
between the=20

	purpose of use of a self-signed certificate that would be placed
in TA, the=20

	"Trust Anchor" itself or the "Trust Anchor Store".

	=20

	Is one Trust anchor Store usable for some specific purpose(s)?=20

	=20

	Hence is the "purpose" part of the Trust Anchor Store rather
than=20
	the Trust Anchor itself?=20

	=20

	All this needs to be clarified. Once this will be clarified,=20

	it will be possible to address the kind of operations that
should be=20

	possible on the various objects.=20

	=20

	[CRW] The document does not discuss purpose in terms of a trust
anchor store.  One could create and manage a trust anchor store such
that the trust anchor store served a specific purpose.  One could define
an purpose-centric API for interacting with a trust anchor store that
served multiple purposes. =20

	=20

=09

=09
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=3D=3D

	=20

	In the abstract the text states:

	=20

	   The public key is used to verify digital

	   signatures and the *associated data is used to constrain* the
types of

	   information for which the trust anchor is authoritative.

	=20

	This sentence is confusing since the word "constrain" is kept
vague and=20

	thus does not make the difference between:

	=20

	   1) the intended purpose,

	   2) the constraints that are set by the CA and apply for all
purposes,

	   3) the constraints that are set by the RP.

	=20

	Let us now illustrate case 2): the constraints are included into
the self-

	signed certificate. The constraints are set by the CA and apply
to all=20

	usages of that self-signed certificate, i.e. all "purposes".

	=20

	Let us now illustrate cases 3): the constraints are external to
the self-

	signed certificate. The constraints come in addition to those
included=20

	inside the self-signed certificate and are tailored to the
specific=20

	purpose.

	=20

	Case 2) and case 3) may co-exist.=20

	=20

	However, the current draft does not make the distinction between
case 2)=20

	and case 3). This is rather fundamental, since a "TA manager"
cannot change=20

	the constraints that are included in a self-signed certificate.=20

	=20

	[CRW] A "TA manager" cannot change what's included in a
self-signed certificate but it can define additional restrictions or
further restrict the constraints contained in a self-signed certificate.
This is addressed in the subordination processing rules in the TAMP
draft.=20

	=20

=09
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=3D=3D=3D=3D

	=20

	The document defines a Trust Anchor as : "A trust anchor
represents an=20

	authoritative entity via a public key and associated data". This
sentence=20

	is confusing since the wording "associated data" means
everything and thus=20

	nothing.=20

	=20

	This definition is not coherent with RFC 5280 which states on
page 76:

	=20

	   " The trust anchor information includes:

	=20

	      (1)  the trusted issuer name,

	      (2)  the trusted public key algorithm,

	      (3)  the trusted public key, and

	      (4)  optionally, the trusted public key parameters
associated

	           with the public key.

	=20

	The issuer name shall always be present in a trust anchor".

	=20

	The definition of a TA should also make the difference between:

	=20

	   a) the constraints that are set by the CA and apply for all
purposes,

	   b) the constraints that are set by the RP.

	=20

	Only the later, can be managed when self-signed certificates are
used.=20

	=20

	[CRW] I think the definition of a trust anchor has been
sufficiently discussed and don't see anything here that warrants a
change.  I recognize the difference with 5280, but TAs have broader use
than just 5280, as noted in the draft.=20

	=20

=09

=09

	Denis
	=20


------_=_NextPart_001_01C948E1.DC68836A
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns:o =3D =
"urn:schemas-microsoft-com:office:office"><HEAD><TITLE></TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.6000.16735" name=3DGENERATOR></HEAD>
<BODY style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Tahoma" leftMargin=3D5 =
topMargin=3D5=20
#ffffff>
<DIV dir=3Dltr align=3Dleft><SPAN=20
class=3D948152103-14112008>inline...</SPAN></DIV><BR>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
  <HR tabIndex=3D-1>
  <B>From:</B> [e-mail]=20
  [mailto:[e-mail]] <B>On Behalf Of </B>Denis=20
  Pinkas<BR><B>Sent:</B> Thursday, November 06, 2008 5:27 =
AM<BR><B>To:</B>=20
  ietf-pkix<BR><B>Subject:</B> Re: I-D=20
  Action:draft-ietf-pkix-ta-mgmt-reqs-02.txt (second part)<BR><BR></DIV>
  <DIV></DIV>
  <DIV>In order to keep the message short, two answers are given on this =

  document.</DIV>
  <DIV><SPAN lang=3DEN-GB style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></DIV>
  <DIV>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">Comments =
on=20
  draft-ietf-pkix-ta-mgmt-reqs-02<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">Topic:=20
  Clarifications needed about associated data, purpose and=20
  <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT=20
  face=3D"Courier New">constraints.<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">For most =
web=20
  browsers and Java machines, the current situation is the=20
  <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT=20
  face=3D"Courier New">following:<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>- self-signed =
certificates are=20
  used for all purposes, e.g. TLS server,<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>TLS =
client, sending=20
  e-mails, receiving e-mails, applets' =
signatures,<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN>and<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>- it is unknown =
whether=20
  revocation conditions are checked and =
how.<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">Suppose =
(for the=20
  time being) that we want to move from the current=20
<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier =
New">situation where=20
  self-signed certificates are placed in the same storage and=20
  <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">hence =
used for all=20
  purposes to a situation where self-signed certificates=20
  <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">are no =
more used for=20
  any purpose, e.g. used for sending e-mails or used for=20
  <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier =
New">receiving=20
  e-mails.<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">There =
are two=20
  possible approaches:<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>a) consider a given a =
*purpose*,=20
  e.g. applets' signatures, and then <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>list =
all=20
  self-signed certificates that can be used for such=20
  a<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</SPAN>purpose,=20
  or<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>b) consider each =
self-signed=20
  certificate and tell for which purpose <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>that =

  self-signed certificate may be used.<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">If we =
take into=20
  consideration the "need-to-know" requirement, some=20
  <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier =
New">applications need to=20
  know which self-signed certificates shall be used for=20
  <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">a given =
purpose and=20
  do not need to know if they are also used for a =
<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier =
New">different=20
  purpose.</FONT><FONT face=3DTahoma><SPAN=20
  class=3D948152103-14112008>&nbsp;</SPAN></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3DTahoma><SPAN=20
  class=3D948152103-14112008></SPAN></FONT></SPAN>&nbsp;</P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New"></FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">The =
approach a)=20
  fulfils this requirement, but not the approach=20
b).<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">When a =
path=20
  validation must be done for a given purpose, case a) is rather=20
  <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier =
New">straightforward: all=20
  the information is under the purpose.<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">With =
case b), this=20
  would be more difficult, since the application would=20
  <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">need to =
scan every=20
  "Trust Anchor" store (?) and look if the given purpose=20
  <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">is =
mentioned under a=20
  "Trust Anchor".<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">Case a) =
allows a=20
  clear and clean separation of information. However, it=20
  <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">seems =
that the=20
  document has implicitly chosen case b). :-(</FONT><FONT =
face=3DTahoma><SPAN=20
  class=3D948152103-14112008>&nbsp;</SPAN></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3DTahoma><SPAN=20
  class=3D948152103-14112008></SPAN></FONT></SPAN>&nbsp;</P><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3DTahoma><SPAN=20
  class=3D948152103-14112008>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3DTahoma><SPAN=20
  class=3D948152103-14112008><FONT face=3D"Courier New">[CRW]&nbsp;This =
document=20
  does not choose a) or b).&nbsp; You&nbsp;are describing implementation =
details=20
  for&nbsp;how a trust anchor store is queried.&nbsp; We're not defining =
an API=20
  for interacting with a trust anchor=20
  store.</FONT></SPAN></FONT></SPAN></SPAN></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">It is =
unclear in the=20
  current document what is the relationship between the=20
  <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">purpose =
of use of a=20
  self-signed certificate that would be placed in TA, the=20
  <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">"Trust =
Anchor"=20
  itself or the "Trust Anchor Store&#8221;.<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">Is one =
Trust anchor=20
  Store usable for some specific purpose(s)? </FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT=20
  face=3D"Courier New"></FONT></SPAN>&nbsp;</P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">Hence is =

  </FONT></SPAN><SPAN lang=3DEN-GB style=3D"mso-ansi-language: =
EN-GB"><FONT=20
  face=3D"Courier New">the "purpose" part of the Trust Anchor Store =
rather than=20
  <BR>the Trust A</FONT></SPAN><SPAN lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">nchor =
itself?=20
  </FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT=20
  face=3D"Courier New"></FONT></SPAN>&nbsp;</P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">All this =
needs to be=20
  clarified. Once this will be clarified, <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">it will =
be possible=20
  to address the kind of operations that should be =
<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">possible =
on the=20
  various objects.</FONT><FONT face=3DTahoma><SPAN=20
  class=3D948152103-14112008>&nbsp;</SPAN></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
  class=3D948152103-14112008></SPAN></FONT></SPAN>&nbsp;</P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
  class=3D948152103-14112008>[CRW] The document does not discuss purpose =
in terms=20
  of a trust anchor store.&nbsp; One could create and manage a trust =
anchor=20
  store such that the trust anchor store served a specific =
purpose.&nbsp; One=20
  could define an purpose-centric API for interacting with a trust =
anchor store=20
  that served multiple purposes.&nbsp; </SPAN></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3DTahoma><SPAN=20
  class=3D948152103-14112008></SPAN></FONT></SPAN>&nbsp;</P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New"></FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier =
New">=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p>&nbsp;</o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">In the =
abstract the=20
  text states:<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>The public key is used =
to verify=20
  digital<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>signatures and the =
*associated=20
  data is used to constrain* the types of<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>information for which =
the trust=20
  anchor is authoritative.<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">This =
sentence is=20
  confusing since the word "constrain" is kept vague and=20
  <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">thus =
does not make=20
  the difference between:<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>1) the intended=20
  purpose,<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>2) the constraints =
that are set=20
  by the CA and apply for all purposes,<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>3) the constraints =
that are set=20
  by the RP.<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">Let us =
now=20
  illustrate case 2): the constraints are included into the=20
  self-<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">signed =
certificate.=20
  The constraints are set by the CA and apply to all=20
  <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">usages =
of that=20
  self-signed certificate, i.e. all =
"purposes".<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">Let us =
now=20
  illustrate cases 3): the constraints are external to the=20
  self-<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">signed =
certificate.=20
  The constraints come in addition to those included=20
  <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">inside =
the=20
  self-signed certificate and are tailored to the specific=20
  <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT=20
  face=3D"Courier New">purpose.<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">Case 2) =
and case 3)=20
  may co-exist. <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">However, =
the current=20
  draft does not make the distinction between case 2)=20
  <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">and case =
3). This is=20
  rather fundamental, since a "TA manager" cannot change=20
  <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">the =
constraints that=20
  are included in a self-signed certificate.</FONT><FONT =
face=3DTahoma><SPAN=20
  class=3D948152103-14112008>&nbsp;</SPAN></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3DTahoma><SPAN=20
  class=3D948152103-14112008></SPAN></FONT></SPAN>&nbsp;</P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3DTahoma><SPAN=20
  class=3D948152103-14112008><FONT face=3D"Courier New">[CRW] A "TA =
manager" cannot=20
  change what's included in a self-signed certificate but it can define=20
  additional restrictions or further restrict the constraints contained =
in a=20
  self-signed certificate.&nbsp; This is addressed&nbsp;in the =
subordination=20
  processing rules in&nbsp;the TAMP=20
  draft.</FONT>&nbsp;</SPAN><o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier =
New">=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p>&nbsp;</o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">The =
document defines=20
  a Trust Anchor as : "A trust anchor represents an=20
<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier =
New">authoritative entity=20
  via a public key and associated data". This sentence=20
  <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">is =
confusing since=20
  the wording "associated data" means everything and thus=20
  <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">nothing. =

  <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">This =
definition is=20
  not coherent with RFC 5280 which states on page=20
  76:<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;&nbsp; " </SPAN>The trust anchor =
information=20
  includes:<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</SPAN>(1)<SPAN=20
  style=3D"mso-spacerun: yes">&nbsp; </SPAN>the trusted issuer=20
  name,<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN><SPAN lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;</SPAN><SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;&nbsp;</SPAN>(2)<SPAN=20
  style=3D"mso-spacerun: yes">&nbsp; </SPAN>the trusted public key=20
  algorithm,<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN><SPAN lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>(3)<SPAN=20
  style=3D"mso-spacerun: yes">&nbsp; </SPAN>the trusted public key,=20
  and<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN><SPAN lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>(4)<SPAN=20
  style=3D"mso-spacerun: yes">&nbsp; </SPAN>optionally, the trusted =
public key=20
  parameters associated<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
  style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN>with the public key.<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">The =
issuer name=20
  shall always be present in a trust =
anchor".<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">The =
definition of a=20
  TA should also make the difference =
between:<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>a) the constraints =
that are set=20
  by the CA and apply for all purposes,<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>b) the constraints =
that are set=20
  by the RP.<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">Only the =
later, can=20
  be managed when self-signed certificates are used.</FONT><FONT=20
  face=3DTahoma><SPAN =
class=3D948152103-14112008>&nbsp;</SPAN></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3DTahoma><SPAN=20
  class=3D948152103-14112008></SPAN></FONT></SPAN>&nbsp;</P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3DTahoma><SPAN=20
  class=3D948152103-14112008><FONT face=3D"Courier New">[CRW] I think =
the definition=20
  of a trust anchor has been sufficiently discussed and don't see =
anything here=20
  that warrants a change.&nbsp; I recognize the difference with 5280, =
but TAs=20
  have broader use than just&nbsp;5280, as noted in the=20
  draft.</FONT>&nbsp;</SPAN></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3DTahoma><SPAN=20
  class=3D948152103-14112008></SPAN><o:p></o:p></FONT></SPAN>&nbsp;</P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New"></FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"></SPAN></P></DIV>
  <DIV></DIV>
  <DIV><!--AID_FROMNAME_BEGIN-->Denis</DIV>
  <DIV>&nbsp;</DIV></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C948E1.DC68836A--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAHIPprn086026 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Nov 2008 11:25:51 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAHIPpNW086023; Mon, 17 Nov 2008 11:25:51 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mAHIPeKV086008 for <[e-mail]>; Mon, 17 Nov 2008 11:25:50 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 26180 invoked from network); 17 Nov 2008 18:25:23 -0000
Received: from [e-mail] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;17 Nov 2008 18:25:23 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 17 Nov 2008 18:25:23 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C948E1.DB11330A"
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: I-D Action:draft-ietf-pkix-ta-mgmt-reqs-02.txt
Date: Mon, 17 Nov 2008 13:25:23 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: I-D Action:draft-ietf-pkix-ta-mgmt-reqs-02.txt
Thread-Index: Ack//ThKqtKY/+3yRvOdBCujp5+sOgGCZFaw
References: <[e-mail]> <[e-mail]>
From: "Carl Wallace" <[e-mail]>
To: "ietf-pkix" <[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>

This is a multi-part message in MIME format.

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

inline...


________________________________

	From: [e-mail]
[mailto:[e-mail]] On Behalf Of Denis Pinkas
	Sent: Thursday, November 06, 2008 5:25 AM
	To: ietf-pkix
	Subject: Re: I-D Action:draft-ietf-pkix-ta-mgmt-reqs-02.txt
=09
=09
	In order to keep the message short, two answers are given on
this document.
	=20

	Comments on draft-ietf-pkix-ta-mgmt-reqs-02

	=20

	Topic: automatic root key rollover only using trust anchors
initially=20

	installed.

	=20

	The document states on page 7:

	=20

	   Ideally, only the initial set of trust anchors are installed
in=20

	   a particular trust anchor store should require out-of-band=20

	   verification, particularly when the costs of performing
out-of-band=20

	   checks commensurate with the security requirements of
applications=20

	   using the trust anchor store are high.

	=20

	It implicitly means that once an initial set of trust anchors is
installed,=20

	the renewal should happen automatically.=20

	=20

	Unfortunately, this text is only a *statement* within section 2
"Problem=20

	Statement" rather than a *requirement* within section 3
"Requirements". It=20

	should be transformed into a requirement with section 3.=20

	=20

	In practice, we are very close to reach this goal.

	=20

	The CMP protocol allows RPs to pull the information and to
automatically=20

	update trust anchors using the old-by-new self-signed
certificate and the=20

	new-by-new self-signed certificate. There are only two
additional questions=20

	to be answered:=20

	=20

	   a) where to fetch these self-signed-certificates ?

	   b) when to fetch these self-signed-certificates ?=20

	=20

	The answer to the first question is:=20

	=20

	   1) add an LDAP address or an HTTP address, or

	   2) use an Authority Information Access extension=20

	      within the self-signed certificate.

	=20

	The answer to the second question is:=20

	=20

	   1) add a time period for root key renewal, or

	   2) use a private key usage extension within the self-signed
certificate.

	=20

	 ... and then we are done when CA issue self-signed
certificates, which is=20

	what *all* CAs are doing today.

	=20

	It does not matter where self-signed certificates are stored,
e.g. in=20

	validation policies or in TA anchors stores (whatever this last
term may=20

	mean).

	=20

	It means that the use of self-signed certificates allows
automatic root key=20

	rollover and to reach the ideal situation mentioned above.

	=20

	A major advantage of this approach is the use of a pull model:
the process=20

	is initiated from the inside of a company and the number of
applications=20

	using that self-signed certificate may be hidden to the outside.
Denial of=20

	service is easier to handle since the first exchange comes from
the inside.=20

	=20

	These considerations should be taken into consideration in the
draft.=20

	=20

	[CRW] A mechanism based solely on self-signed certificates and
newWithOld/oldWithNew will fail to meet several of the requirements.
Given that auto-renewal could be implemented in terms of existing
requirements, I don't see a need to add it as a separate requirement.  I
don't think we need to enumerate all extensions/associated data in this
draft.

	=20

=09
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

	=20

	The document states in section 3.1.: Transport independence

	=20

	   "It MUST work in both session-oriented

	   and store-and-forward communications environments as well as
in both

	   push and pull distribution models".

	=20

	CMP only works in a pull model. With such sentence CMP would be
ruled out=20

	whereas it is already a standard track protocol.=20

	=20

=09

	The document states in section 3.1.: Transport independence

	=20

	   "connectionless integrity and data origin

	   authentication for TA transactions MUST be provided at the

	   application layer".

	=20

	With CMP, the security is obtained directly by the self-signed=20

	certificates, i.e. the data itself which is self-protected. With
such=20

	sentence CMP would be ruled out, whereas it is already a
standard track=20

	protocol.

	=20

	[CRW] CMP fails to meet several of the requirements. =20

	=20

	The document cannot say on one side that the pull model is
allowed and on=20

	the other side include requirements which rule out the use of
CMP (which is=20

	based on a pull model).

	=20

	Denis

	=20


------_=_NextPart_001_01C948E1.DB11330A
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns:o =3D =
"urn:schemas-microsoft-com:office:office"><HEAD><TITLE></TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.6000.16735" name=3DGENERATOR></HEAD>
<BODY style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Tahoma" leftMargin=3D5 =
topMargin=3D5=20
#ffffff>
<DIV dir=3Dltr align=3Dleft><SPAN=20
class=3D358121203-14112008>inline...</SPAN></DIV><BR>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
  <HR tabIndex=3D-1>
  <B>From:</B> [e-mail]=20
  [mailto:[e-mail]] <B>On Behalf Of </B>Denis=20
  Pinkas<BR><B>Sent:</B> Thursday, November 06, 2008 5:25 =
AM<BR><B>To:</B>=20
  ietf-pkix<BR><B>Subject:</B> Re: I-D=20
  Action:draft-ietf-pkix-ta-mgmt-reqs-02.txt<BR><BR></DIV>
  <DIV></DIV>
  <DIV>In order to keep the message short, two answers are given on this =

  document.</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">Comments =
on=20
  draft-ietf-pkix-ta-mgmt-reqs-02<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">Topic: =
automatic=20
  root key rollover only using trust anchors initially=20
  <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT=20
  face=3D"Courier New">installed.<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">The =
document states=20
  on page 7:<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>Ideally, only the =
initial set of=20
  trust anchors are installed in <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>a particular trust =
anchor store=20
  should require out-of-band <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>verification, =
particularly when=20
  the costs of performing out-of-band <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>checks commensurate =
with the=20
  security requirements of applications <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>using the trust anchor =
store are=20
  high.<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">It =
implicitly means=20
  that once an initial set of trust anchors is installed,=20
  <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">the =
renewal should=20
  happen automatically.</FONT><FONT face=3DTahoma><SPAN=20
  class=3D358121203-14112008>&nbsp;</SPAN></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3DTahoma><SPAN=20
  class=3D358121203-14112008><FONT=20
  face=3D"Courier New"></FONT></SPAN></FONT></SPAN>&nbsp;</P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier =
New">Unfortunately, this=20
  text is only a *statement* within section 2 "Problem=20
  <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier =
New">Statement" rather=20
  than a *requirement* within section 3 "Requirements". It=20
  <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">should =
be=20
  transformed into a requirement with section 3.</FONT><FONT =
face=3DTahoma><SPAN=20
  class=3D358121203-14112008>&nbsp;</SPAN></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
  class=3D358121203-14112008></SPAN></FONT></SPAN>&nbsp;</P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">In =
practice, we are=20
  very close to reach this goal.<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">The CMP =
protocol=20
  allows RPs to pull the information and to automatically=20
  <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">update =
trust anchors=20
  using the old-by-new self-signed certificate and the=20
  <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier =
New">new-by-new=20
  self-signed certificate. There are only two additional questions=20
  <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">to be =
answered:=20
  <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier =
New">&nbsp;&nbsp; a)=20
  where to fetch these self-signed-certificates =
?<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN><SPAN lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">&nbsp; =
b) when to=20
  fetch these self-signed-certificates ? <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">The =
answer to the=20
  first question is: <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>1) add an LDAP address =
or an=20
  HTTP address, or<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>2) use an Authority =
Information=20
  Access extension <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</SPAN>within the=20
  self-signed certificate.<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">The =
answer to the=20
  second question is: <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>1) add a time period =
for root=20
  key renewal, or<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>2) use a private key =
usage=20
  extension within the self-signed =
certificate.<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;</SPAN>... and then we are done when =
CA issue=20
  self-signed certificates, which is <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">what =
*all* CAs are=20
  doing today.<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">It does =
not matter=20
  where self-signed certificates are stored, e.g. in=20
  <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier =
New">validation policies=20
  or in TA anchors stores (whatever this last term may=20
  <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT=20
  face=3D"Courier New">mean).<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">It means =
that the=20
  use of self-signed certificates allows automatic root key=20
  <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">rollover =
and to=20
  reach the ideal situation mentioned =
above.<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">A major =
advantage of=20
  this approach is the use of a pull model: the process=20
  <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">is =
initiated from=20
  the inside of a company and the number of applications=20
  <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">using =
that=20
  self-signed certificate may be hidden to the outside. Denial of=20
  <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">service =
is easier to=20
  handle since the first exchange comes from the inside.=20
  <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">These =
considerations=20
  should be taken into consideration in the draft.</FONT><FONT =
face=3DTahoma><SPAN=20
  class=3D358121203-14112008>&nbsp;</SPAN></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3DTahoma><SPAN=20
  class=3D358121203-14112008></SPAN></FONT></SPAN>&nbsp;</P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3DTahoma><SPAN=20
  class=3D358121203-14112008><FONT face=3D"Courier New">[CRW] =
</FONT><FONT=20
  face=3D"Courier New">A mechanism based solely on self-signed =
certificates and=20
  newWithOld/oldWithNew&nbsp;will fail to meet several of the=20
  requirements.&nbsp; Given that auto-renewal could be implemented in =
terms of=20
  existing requirements, I don't see a need to add it as a separate=20
  requirement.&nbsp; I don't think we need to enumerate all=20
  extensions/associated data in this =
draft.</FONT></SPAN></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT=20
  face=3D"Courier =
New">=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<o:p=
></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">The =
document states=20
  in section 3.1.: Transport independence<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>"It MUST work in both=20
  session-oriented<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>and store-and-forward=20
  communications environments as well as in =
both<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>push and pull =
distribution=20
  models".<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">CMP only =
works in a=20
  pull model. With such sentence CMP would be ruled out=20
  <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">whereas =
it is=20
  already a standard track protocol.</FONT><FONT face=3DTahoma><SPAN=20
  class=3D358121203-14112008>&nbsp;</SPAN></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3DTahoma><SPAN=20
  class=3D358121203-14112008></SPAN></FONT></SPAN>&nbsp;</P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New"></FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">The =
document states=20
  in section 3.1.: Transport independence<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>"connectionless =
integrity and=20
  data origin<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>authentication for TA=20
  transactions MUST be provided at the<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>application=20
  layer".<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">With =
CMP, the=20
  security is obtained directly by the self-signed =
<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier =
New">certificates, i.e.=20
  the data itself which is self-protected. With such=20
  <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">sentence =
CMP would=20
  be ruled out, whereas it is already a standard track=20
  <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT=20
  face=3D"Courier New">protocol.<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New"></FONT></o:p></SPAN>&nbsp;</P><SPAN lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3DTahoma><SPAN=20
  class=3D358121203-14112008><FONT face=3D"Courier New">[CRW] CMP fails =
to meet=20
  several of the requirements.</FONT>&nbsp;<FONT face=3D"Courier New">=20
  </FONT></SPAN></FONT></SPAN></P></o:p></SPAN>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p>&nbsp;</o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">The =
document cannot=20
  say on one side that the pull model is allowed and on=20
  <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">the =
other side=20
  include requirements which rule out the use of CMP (which is=20
  <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">based on =
a pull=20
  model).</FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT=20
  face=3D"Courier New"></FONT></SPAN>&nbsp;</P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT=20
  face=3D"Courier New">Denis</FONT></SPAN></P>
  <P class=3DMsoPlainText=20
style=3D"MARGIN: 0cm 0cm =
0pt">&nbsp;</P></DIV></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C948E1.DB11330A--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAHI3veB084520 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Nov 2008 11:03:57 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAHI3vcV084519; Mon, 17 Nov 2008 11:03:57 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kraid.nerim.net (smtp-101-monday.nerim.net [62.4.16.101]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAHI3k09084498 for <[e-mail]>; Mon, 17 Nov 2008 11:03:57 -0700 (MST) (envelope-from [e-mail])
Received: from uranus.cry.pto (cryptolog2.pck.nerim.net [213.41.184.9]) by kraid.nerim.net (Postfix) with ESMTP id 1B292CFE60 for <[e-mail]>; Mon, 17 Nov 2008 19:03:44 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by uranus.cry.pto (Postfix) with ESMTP id 09FB94401B for <[e-mail]>; Mon, 17 Nov 2008 19:03:45 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at cryptolog.com
Received: from uranus.cry.pto ([127.0.0.1]) by localhost (uranus.cry.pto [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L30TOHwwIqLT for <[e-mail]>; Mon, 17 Nov 2008 19:03:41 +0100 (CET)
Received: from [10.0.1.30] (leda.cry.pto [10.0.1.30]) by uranus.cry.pto (Postfix) with ESMTP id 74DD444009 for <[e-mail]>; Mon, 17 Nov 2008 19:03:41 +0100 (CET)
Message-ID: <[e-mail]>
Date: Mon, 17 Nov 2008 19:03:41 +0100
From: Julien Stern <[e-mail]>
User-Agent: Mozilla-Thunderbird 2.0.0.14 (X11/20080509)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: encoding an X.509 certificate
References: <[e-mail]> <p06240514c5474e7c5e53@[130.129.30.0]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Eric Norman wrote:
> 
> 
> On Nov 17, 2008, at 10:40 AM, Stephen Kent wrote:
> 
>> I have to disagree. The standards call for DER to be used for 
>> signature generation and validation. They are generally silent on 
>> transport encoding. If we say that an RP should just try to verify the 
>> signature on whatever it receives, then we encourage (more) sloppy 
>> behavior by CAs. The preferred approach is for the RP to encode the 
>> received cert into DER before checking.
> 
> So if someone receives a bit blob that contains a certificate,
> and the signature would verify if the bit blob was used,
> but some parts of that bit blob are BER but not DER encoded,
> then certificate validation should fail?

Oh well, why not ?
This is really an infamous "matter of local policy", but it would be 
hard to blame an implementation that does not validate the certificate 
in question.

Just recently, we encountered a certificate whose serial number was 
negative. The RFC very specifically states that serial numbers MUST be 
positive integers. Now, it is easy to decode such a certificate, and 
actually, most ASN.1 libraries will not even figure out that this number 
is negative unless someone has specified a constraint or if there is an 
explicit check on this number. So, should certificate validation fail?

I think it really boils down to how big and powerful the company 
implementing the validation is. If a BER encoded certificate (or a 
certificate with a negative serial) is rejected by your implementation 
AND if you can explain to your customers that YOU are doing the right 
thing, then you are fine, otherwise, you'll have to patch your 
implementation to accept the buggy certificates produced by a more 
powerful entity than yours :)

It actually only gets tricky when accepting these buggy certificates is 
linked to a security risk. The intuition is that attacks through hash 
collisions are easier if BER encoding is allowed, however, because 
extensions can also be used to add entropy, it is not clear whether BER 
encoding actually decreases security or not in theoretical attack cases.

Regards,

--
Julien



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAHHOe3M082476 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Nov 2008 10:24:40 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAHHOeH3082475; Mon, 17 Nov 2008 10:24:40 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from agogare.doit.wisc.edu (agogare.doit.wisc.edu [144.92.197.211]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAHHOT08082462 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL) for <[e-mail]>; Mon, 17 Nov 2008 10:24:39 -0700 (MST) (envelope-from [e-mail])
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; charset=US-ASCII; format=flowed
Received: from avs-daemon.smtpauth2.wiscmail.wisc.edu by smtpauth2.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 6.3-6.03 (built Mar 14 2008; 32bit)) id <[e-mail]> for [e-mail]; Mon, 17 Nov 2008 11:24:28 -0600 (CST)
Received: from [192.168.0.14] (static.unknown.charter.com [97.92.189.144]) by smtpauth2.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 6.3-6.03 (built Mar 14 2008; 32bit)) with ESMTPSA id <[e-mail]> for [e-mail]; Mon, 17 Nov 2008 11:24:24 -0600 (CST)
Date: Mon, 17 Nov 2008 11:24:12 -0600
From: Eric Norman <[e-mail]>
Subject: Re: encoding an X.509 certificate
In-reply-to: <p06240514c5474e7c5e53@[130.129.30.0]>
To: [e-mail]
Message-id: <[e-mail]>
X-Mailer: Apple Mail (2.624)
X-Spam-Report: AuthenticatedSender=yes, SenderIP=97.92.189.144
X-Spam-PmxInfo: Server=avs-13, Version=5.4.2.344556, Antispam-Engine: 2.6.0.325393, Antispam-Data: 2008.11.17.171024, SenderIP=97.92.189.144
References: <[e-mail]> <p06240514c5474e7c5e53@[130.129.30.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>

On Nov 17, 2008, at 10:40 AM, Stephen Kent wrote:

> I have to disagree. The standards call for DER to be used for 
> signature generation and validation. They are generally silent on 
> transport encoding. If we say that an RP should just try to verify the 
> signature on whatever it receives, then we encourage (more) sloppy 
> behavior by CAs. The preferred approach is for the RP to encode the 
> received cert into DER before checking.

So if someone receives a bit blob that contains a certificate,
and the signature would verify if the bit blob was used,
but some parts of that bit blob are BER but not DER encoded,
then certificate validation should fail?

Eric Norman



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAHGejpA078978 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Nov 2008 09:40:45 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAHGej9P078977; Mon, 17 Nov 2008 09:40:45 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAHGeYPM078959 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 17 Nov 2008 09:40:45 -0700 (MST) (envelope-from [e-mail])
Received: from dommiel.bbn.com ([192.1.122.15] helo=[130.129.30.0]) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from <[e-mail]>) id 1L279F-0002va-AQ; Mon, 17 Nov 2008 11:40:25 -0500
Mime-Version: 1.0
Message-Id: <p06240514c5474e7c5e53@[130.129.30.0]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Mon, 17 Nov 2008 11:40:25 -0500
To: Tom Gindin <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: encoding an X.509 certificate
Cc: "Timothy J. Miller" <[e-mail]>, [e-mail], [e-mail], Peter Gutmann <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 8:22 PM -0500 11/12/08, Tom Gindin wrote:
>         "Conservative in what you produce" - CA code should generate DER.
>Not all such code does so, but it should.
>         "Liberal in what you accept" - RP code should verify signatures on
>the supplied binary TBSCertificate, rather than re-encoding.  For parsing
>code to accept BER which isn't valid DER is almost harmless.    There may
>well have been a good reason for believing that DER was more secure than
>BER against various digest collision or pre-image attacks when X.509v1 was
>in use and all certificate content had syntax verifiable by every RP (at
>least in theory).  With non-critical extensions, that is no longer the
>case.
>
>                 Tom Gindin

Tom,

I have to disagree. The standards call for DER to be used for 
signature generation and validation. They are generally silent on 
transport encoding. If we say that an RP should just try to verify 
the signature on whatever it receives, then we encourage (more) 
sloppy behavior by CAs. The preferred approach is for the RP to 
encode the received cert into DER before checking.

Steve



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAHG33xT075971 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Nov 2008 09:03:03 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAHG33sq075970; Mon, 17 Nov 2008 09:03:03 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAHG2qSM075955 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Mon, 17 Nov 2008 09:03:02 -0700 (MST) (envelope-from [e-mail])
Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id mAHG2CcI015737; Mon, 17 Nov 2008 10:02:48 -0600
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 Nov 2008 18:02:38 +0200
Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 Nov 2008 18:02:37 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: AD comments for draft-ietf-pkix-ecc-subpubkeyinfo-09
Date: Mon, 17 Nov 2008 18:02:38 +0200
Message-ID: <[e-mail]>
In-Reply-To: <6DE5ACAFBF0648278ABF3936799A87FA@Wylie>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: AD comments for draft-ietf-pkix-ecc-subpubkeyinfo-09
Thread-Index: AclFkTVKBddzMZh/RymSj/vhXGDRogAKSpkAAMMYYOA=
References: <[e-mail]> <6DE5ACAFBF0648278ABF3936799A87FA@Wylie>
From: <[e-mail]>
To: <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 17 Nov 2008 16:02:37.0928 (UTC) FILETIME=[E978E680:01C948CD]
X-Nokia-AV: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Sean,

Thanks for a quick reply!

> To answer your questions:
>=20
> 1) Using parameter inheritance would mean that the EE certificate
> would not contain all of the necessary information that would be
> required for relying party to process a certificate.  The relying
> party might luck in to guessing the curve because there are only so
> many "well known" curves for a given key size, but to be sure the
> relying party would need to get the curve either from an issuer's
> certificate or through some other means.  The last paragraph of
> 2.1.1 address these options.

Hmm -- guessing the curve sounds like it could be dangerous?
(But I haven't really thought what the attacks could be..)

> 2) The rationale for retaining parameter inheritance is that many
> people that support DSA already deal with parameter inheritance in
> that context.  So, it may not be a burden to keep this capability in
> the specification.

With DSA, inheritance saves hundreds of bytes, so this optimization
makes more sense there. Also, I think ECDSA could get more widely used
than DSA has been (and in more open and non-homogeneous environments),
so there are more opportunities for problems to arise. (But opinions
from other WG members would be welcome, too.)

> It's PKIX so we generally assume people are doing path validation ;)

Well, that's not always what other IETF WGs are doing :)=20

> >Topic #2: scope of Appendix A
> >
> >For a document that specifies how to carry ECC public keys in
> >SubjectPublicKeyInfo, I was sort of expecting ASN.1 module(s) to do
> >so.  When I got to Appendix A, I was very surprised to find ASN.1
> >modules that contain mostly other things (not related to ECC at all,
> >or not related to SubjectPublicKeyInfo) -- nothing in the main
> >document (abstract and Sections 1..8) hinted that this would be
> >coming. Could you briefly explain why ASN.1 about RSA, DSA, MD5,=20
> >etc. belongs in this document?
>=20
> One of early comments was that since we're updating RFC 3279, we'd
> end up with a Chinese menu for implementers if we didn't update the
> entire RFC 3279 module.  RFC 3279 includes more than ECC "stuff" so
> if we update the RFC 3279 module have baggage.

Sounds like a reasonable explanation. Could you add a sentence or two
to the document abstract and introduction explaining this?

<snip>
> The reference to draft-ietf-pkix-new-asn1 is an informative
> reference.  I wish the reference could be normative, but we'd be
> blocked on it.  We could 1) pull the appendix out of the document
> (we'd have some text tweaking to do) and put the appendix in a)
> separate document b) put it in draft-ietf-pkix-new-asn1 2) leave it
> in the document and produce an update after draft-ietf-pkix-asn1
> gets published that says the appendices are now normative 3)
> indicate that it does not form a normative part of the document (not
> sure what we'd do with the reference).  I am willing to be guided on
> the best way forward.

I guess this depends how soon draft-ietf-pkix-new-asn1 is going
to be ready. If we want to publish ecc-subpubkeyinfo first,=20
I would suggest moving Appendix A.4 to draft-ietf-pkix-new-asn1.

> >The remaining comments are basically questions or suggestions
> >for minor clarifications:
> >
> >- Section 2.2: ANSI X9.62 specifies a third point form (that isn't=20
> >in [SEC1]); should this text say "the hybrid form MUST NOT be used"?
> >Or is the intent something else?
>=20
> I do not remember discussing the hybrid form and I don't remember
> back to the RFC 3279 discussion wrt to the hybrid form.  I would
> propose we add a new second sentence to the seconds paragraph "The
> hybrid form from [X9.62] MUST NOT be used."

Ok with me.

> >- I'm trying to understand how this ASN.1 fragment (and several
> >other similar cases) can actually compile:
> >
> >   sa-rsaWithMD2 SIGNATURE-ALGORITHM ::=3D {=20
> >     IDENTIFIER md2WithRSAEncryption=20
> >     PARAMS TYPE NULL ARE present=20
> >     HASHES { mda-md2 }=20
> >     PUBLIC KEYS { pk-rsa }=20
> >   }=20
> >
> >I'm puzzled because the string "present" is not one of the values
> >enumerated in ParamOptions -- but perhaps it's an ASN.1 keyword or
> >something?  (I have to admit that while I could usually read the old
> >1988 ASN.1 syntax, I don't really understand how this CLASS stuff
> >works...)
>=20
> "present" needs to be replaced by "required" (in 3 places).  I had=20
> a module that I was compiling and I forgot to copy over these=20
> changes :(

Ok (the spelling of "prefered" vs. "preferred" also needs to be=20
checked).

<snip>
> NEW:
>=20
> Two "restricted" algorithms are defined for key agreement
> algorithms: the Elliptic Curve Diffie-Hellman (ECDH) key agreement
> scheme and the Elliptic Curve Menezes-Qu-Vanstone (ECMQV) key
> agreement scheme. Both algorithms are identified by an object
> identifier and have parameters.  The object identifier varies based
> on the algorithm but the parameters are always ECParameters and they
> MUST always be present (see Section 2.1.1).

Works for me.

Best regards,
Pasi



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAHE6ljA066141 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Nov 2008 07:06:52 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAHE6lcC066140; Mon, 17 Nov 2008 07:06:47 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.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 balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAHE6aEO066124 for <[e-mail]>; Mon, 17 Nov 2008 07:06:46 -0700 (MST) (envelope-from [e-mail])
Received: from Augustine.missi.ncsc.mil (augustine.missi.ncsc.mil [144.51.60.33]) by stingray.missi.ncsc.mil with ESMTP id mAHE6ZSa022200 for <[e-mail]>; Mon, 17 Nov 2008 09:06:35 -0500 (EST)
Received: from DABECK.missi.ncsc.mil ([144.51.60.15]) by Augustine.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 Nov 2008 09:04:10 -0500
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: Signing and Encrypting with the same key?
Date: Mon, 17 Nov 2008 09:06:35 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Signing and Encrypting with the same key?
Thread-Index: AclHM5GhiwsKjI5xQ6qgVyHzIVGcwwBiHg0Q
References: <[e-mail]> <B9A9F0E608D94D2CA899102A88789787@AndersPC> <[e-mail]> <51604CB892B44C39BAF60D61875EB21E@AndersPC> <[e-mail]>
From: "Kemp, David P." <[e-mail]>
To: <[e-mail]>
X-OriginalArrivalTime: 17 Nov 2008 14:04:10.0015 (UTC) FILETIME=[5CD372F0:01C948BD]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFN0ZXBoZW4gV2lsc29uDQo+
DQo+IEknZCBsaWtlIHRvIGtub3cgdGhlIHByZWNpc2UgDQo+IGhpc3Rvcnkgb2YgdGhlIE5SIGJp
dCBpbiBYLjUwOS4gIFdobyBhY3R1YWxseSB0aG91Z2h0IG9mIGl0LCB3ZXJlIHRoZXkgDQo+IGFu
IGVuZ2luZWVyIG9yIGEgbGF3eWVyLCBhbmQgd2hhdCBpZiBhbnkgZGViYXRlIHdlbnQgb24gYXQg
dGhlIHRpbWU/DQoNClRydXN0IG1lLCB5b3UgcmVhbGx5LCBSRUFMTFkgZG9uJ3Qgd2FudCB0byBr
bm93IDotKS4NCg0KVGhvc2Ugb24gb25lIHNpZGUgb2YgdGhlIGFyZ3VtZW50IHRob3VnaHQgdGhh
dCB0aGUgTlIgYml0IHNldCBzaG91bGQgYmUgdXNlZCBmb3Igc2lnbmF0dXJlcyB0aGF0IGNvdWxk
IGJlIHZhbGlkYXRlZCBpbmRlZmluaXRlbHkgKGkuZS4gZm9yIHdoYXQgb25lIG5vcm1hbGx5IHRo
aW5rcyBvZiBhcyAic2lnbmluZyIpLCBhbmQgc2lnbmF0dXJlcyB3aXRoIHRoZSBOUiBiaXQgY2xl
YXIgY291bGQgYmUgdXNlZCBvbmx5IGZvciBzZXNzaW9uIGF1dGhlbnRpY2F0aW9uLiAgVGhhdCB3
YXkgYSBzaWduZWQgb2JqZWN0IGNyZWF0ZWQgYXMgcGFydCBvZiBhIGxvZ2luIHNlc3Npb24gY291
bGQgbm90IGJlIG1pc3JlcHJlc2VudGVkIGFzIGEgc2lnbmVkIGRvY3VtZW50Lg0KDQpUaG9zZSBv
biB0aGUgb3RoZXIgc2lkZSB0aG91Z2h0IHRoYXQgdGhlIE5SIGJpdCBhY3R1YWxseSBoYWQgc29t
ZXRoaW5nIHRvIGRvIHdpdGggInJlcHVkaWF0aW5nIiBzaWduYXR1cmVzLCB3aGljaCBJTUhPIGlz
IGEgcmlkaWN1bG91cyBpZGVhIGZvciB0aGUgcmVhc29ucyB5b3Ugc3VnZ2VzdC4gIFRob3NlIHdo
byBiZWxpZXZlIGluIHRoZSBjdXJyZW50IFguNTA5IGludGVycHJldGF0aW9uIG1heSBkZWZlbmQg
aXQgaWYgdGhleSB3aXNoLCBvciBzcGFyZSB1cyB0aGUgZGlzY3Vzc2lvbi4NCg0KRGF2ZQ0K



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAH3axWu032188 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 16 Nov 2008 20:36:59 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAH3axT8032187; Sun, 16 Nov 2008 20:36:59 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from eurymedon.net.ttu.edu (eurymedon.net.ttu.edu [129.118.1.225]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAH3alC5032172 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for <[e-mail]>; Sun, 16 Nov 2008 20:36:58 -0700 (MST) (envelope-from [e-mail])
Received: from hippolytus.net.ttu.edu (129.118.1.212) by eurymedon.net.ttu.edu (129.118.1.225) with Microsoft SMTP Server (TLS) id 8.1.311.2; Sun, 16 Nov 2008 21:36:47 -0600
Received: from smtp.ttu.edu (129.118.41.119) by smtp.ttu.edu (129.118.240.206) with Microsoft SMTP Server (TLS) id 8.1.311.2; Sun, 16 Nov 2008 21:36:45 -0600
Message-ID: <[e-mail]>
From: Alan Sill <[e-mail]>
To: pkix <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0 (Apple Message framework v929.2)
Subject: Re: Attribute Authorities
Date: Sun, 16 Nov 2008 21:36:45 -0600
References: <[e-mail]>
X-Mailer: Apple Mail (2.929.2)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Attribute authorities are features of virtual or real organizations,  
not CAs in general.  A give VO can have multiple CAs associated with  
it or accepted by its relying parties, none of which may be uniquely  
authoritative to assert that the AA itself is authentic.  In large- 
scale VOs that want to make such an assertion, a certificate from one  
of those CAs may be used to identify the AA service.  An example is  
the certificate checking built into some, but not all, of the relying  
party software that uses VOMS extended attribute certificates.  The  
responsibility to check the credentials of the AA belongs to the  
relying party, not to the CA.  They can do so by checking the  
credentials of the service that adds the extensions.

Alan

On Nov 15, 2008, at 3:53 AM, Massimiliano Pala wrote:

> I was wondering if there is a way to actually identify an AA based  
> on the
> contents of its certificate (eg., extendedKeyUsage, an extension, an
> OID,... ) ?
>
> How can a third party know that an Identity has been identified by a  
> CA
> as a valid AA ? I know that the problem of Identity and Authorization
> should not be tied together - but it would be easier for an  
> application
> to know that an identity can sign attribute certificates. Is there  
> anything
> of the sort ? And if not, has anybody thought about it ?

Alan Sill, Ph.D
Senior Scientist, High Performance Computing Center
Adjunct Professor of Physics
TTU

====================================================================
:  Alan Sill, Texas Tech University  Office: Admin 233, MS 4-1167  :
:  e-mail: [e-mail]   ph. 806-742-4350  fax [phone]  :
====================================================================





Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAH3aDXg032160 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 16 Nov 2008 20:36:13 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAH3aDEh032159; Sun, 16 Nov 2008 20:36:13 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from euphorbus.net.ttu.edu (euphorbus.net.ttu.edu [129.118.1.216]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAH3a2aY032149 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for <[e-mail]>; Sun, 16 Nov 2008 20:36:13 -0700 (MST) (envelope-from [e-mail])
Received: from hippolytus.net.ttu.edu (129.118.1.212) by euphorbus.net.ttu.edu (129.118.1.216) with Microsoft SMTP Server (TLS) id 8.1.311.2; Sun, 16 Nov 2008 21:36:01 -0600
Received: from smtp.ttu.edu (129.118.41.119) by smtp.ttu.edu (129.118.240.206) with Microsoft SMTP Server (TLS) id 8.1.311.2; Sun, 16 Nov 2008 21:36:01 -0600
Message-ID: <[e-mail]>
From: Alan Sill <[e-mail]>
To: pkix <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0 (Apple Message framework v929.2)
Subject: Re: Attribute Authorities
Date: Sun, 16 Nov 2008 15:26:51 -0600
References: <[e-mail]>
X-Mailer: Apple Mail (2.929.2)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Attribute authorities are features of virtual or real organizations,  
not CAs in general.  A give VO can have multiple CAs associated with  
it or accepted by its relying parties, none of which may be uniquely  
authoritative to assert that the AA itself is authentic.  In large- 
scale VOs that want to make such an assertion, a certificate from one  
of those CAs may be used to identify the AA service.  An example is  
the certificate checking built into some, but not all, of the relying  
party software that uses VOMS extended attribute certificates.  The  
responsibility to check the credentials of the AA belongs to the  
relying party, not to the CA.  They can do so by checking the  
credentials of the service that adds the extensions.

Alan

On Nov 15, 2008, at 3:53 AM, Massimiliano Pala wrote:

> I was wondering if there is a way to actually identify an AA based  
> on the
> contents of its certificate (eg., extendedKeyUsage, an extension, an
> OID,... ) ?
>
> How can a third party know that an Identity has been identified by a  
> CA
> as a valid AA ? I know that the problem of Identity and Authorization
> should not be tied together - but it would be easier for an  
> application
> to know that an identity can sign attribute certificates. Is there  
> anything
> of the sort ? And if not, has anybody thought about it ?

Alan Sill, Ph.D
Senior Scientist, High Performance Computing Center
Adjunct Professor of Physics
TTU

====================================================================
:  Alan Sill, Texas Tech University  Office: Admin 233, MS 4-1167  :
:  e-mail: [e-mail]   ph. 806-742-4350  fax [phone]  :
====================================================================





Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAGHuHdP010795 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 16 Nov 2008 10:56:17 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAGHuHZg010794; Sun, 16 Nov 2008 10:56:17 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pne-smtpout1-sn2.hy.skanova.net (pne-smtpout1-sn2.hy.skanova.net [81.228.8.83]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAGHu5du010785 for <[e-mail]>; Sun, 16 Nov 2008 10:56:16 -0700 (MST) (envelope-from [e-mail])
Received: from AndersPC (81.232.45.215) by pne-smtpout1-sn2.hy.skanova.net (7.3.129) id 48A144C50196E33C; Sun, 16 Nov 2008 18:56:03 +0100
Message-ID: <97C8A7FB5B8D47FE8F23B75301DF0BE8@AndersPC>
From: "Anders Rundgren" <[e-mail]>
To: "Massimiliano Pala" <[e-mail]>
Cc: "pkix" <[e-mail]>
References: <[e-mail]> <9D3C913A55AD41538FC235BF2B30EBBC@AndersPC> <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: Re: Attribute Authorities
Date: Sun, 16 Nov 2008 18:56:00 +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 Windows Mail 6.0.6000.20661
X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16669
Sender: [e-mail]
Precedence: 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 Max,
I have taken the liberty (?) of studying the AC use-case in the business world, including 
e-governments.

I came up with a solution that I consider a viable alternative to X509 ACs although the method can 
be used with such as well.
The basic concept is that the AA publishes signed XML "ACs" using high-entropy URLs (can't be 
guessed) and the client only forwards this URL like the following example:
http://webpki.org/attributecertificates/A.2006.10.0452/9j2g637gdHu3erh8udvh5ddyugdRd9Gw30fdu0pwetfkotgoi4218hfcsKeherufu.xml
It also makes revocation a simple thing, the AA just removes the AC or replaces its contents with a 
revoke notice.

ACs can also be created for human consumption:
http://webpki.org/attributecertificates/A.2006.10.0452/9j2g637gdHu3erh8udvh5ddyugdRd9Gw30fdu0pwetfkotgoi4218hfcsKeherufu.pdf

IMHO, core PKI does not need much additional innovation, it is rather the application of PKI that is 
problem.  There is an over-belief in complexity as the solution.

In case you  *really* want to make PKI more useful you should tell these guys
http://www.mel.nist.gov/msid/b2btestbed
how they should dress their scheme in PKI because their buddies at the computer security department 
obviously haven't a clue!
BTW, I would be happy to see the design as well...

Anders

----- Original Message ----- 
From: "Massimiliano Pala" <[e-mail]>
To: "Anders Rundgren" <[e-mail]>
Cc: "pkix" <[e-mail]>
Sent: Sunday, November 16, 2008 06:01
Subject: Re: Attribute Authorities


Hi Anders,

my question was different and it was related to how to identify an AA - which is
basically answered in rfc3281 in 7.4 (thanks Santosh).

Talking about attribute authorities, the AC has been researched extensively (an
example being the work from Chadwick and the current work within the OGF). It is
true, although, that client software implementations are not widely deployed
outside certain communities. I do hope this will change as soon as we will
improve the usability of PKIs :D

Later,
Max


Anders Rundgren wrote:
> I thought that an X509 AC is supposed to contain a binding to a PKC (or identity) and
> that you need to trust both CAs in order to get something useful out of this concept.
> To me that sounds like that there already is a solution.
>
> Talking about attribute authorities; what do you think about the Microsoft-originated
> Information Card scheme? http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=imi
>  IMO it will do what ACs never did because it addresses real-world use-cases and is
> already supported by Vista, XP and Firefox platforms while the AC use-case(?) is poorly
> researched and client-side implementations are scarce to say the least.
>
> Anders Rundgren




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAGGSrBO007401 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 16 Nov 2008 09:28:53 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAGGSrlt007400; Sun, 16 Nov 2008 09:28:53 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.cs.dartmouth.edu (mail.cs.dartmouth.edu [129.170.212.100]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAGGSfxh007387 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Sun, 16 Nov 2008 09:28:53 -0700 (MST) (envelope-from [e-mail])
Received: from titan.cs.dartmouth.edu (99-207-16-108.pools.spcsdns.net [99.207.16.108] (may be forged)) (authenticated bits=0) by mail.cs.dartmouth.edu (8.14.2/8.14.2) with ESMTP id mAGGSbPR009192 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 16 Nov 2008 11:28:39 -0500
Message-ID: <[e-mail]>
Date: Sun, 16 Nov 2008 11:31:11 +0630
From: Massimiliano Pala <[e-mail]>
Organization: Dartmouth College - Computer Science Department
User-Agent: Thunderbird 2.0.0.16 (X11/20080707)
MIME-Version: 1.0
To: Anders Rundgren <[e-mail]>
CC: pkix <[e-mail]>
Subject: Re: Attribute Authorities
References: <[e-mail]> <9D3C913A55AD41538FC235BF2B30EBBC@AndersPC>
In-Reply-To: <9D3C913A55AD41538FC235BF2B30EBBC@AndersPC>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090500010709050801030504"
Sender: [e-mail]
Precedence: 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.

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

Hi Anders,

my question was different and it was related to how to identify an AA - which is
basically answered in rfc3281 in 7.4 (thanks Santosh).

Talking about attribute authorities, the AC has been researched extensively (an
example being the work from Chadwick and the current work within the OGF). It is
true, although, that client software implementations are not widely deployed
outside certain communities. I do hope this will change as soon as we will
improve the usability of PKIs :D

Later,
Max


Anders Rundgren wrote:
> I thought that an X509 AC is supposed to contain a binding to a PKC (or identity) and
> that you need to trust both CAs in order to get something useful out of this concept.
> To me that sounds like that there already is a solution.
> 
> Talking about attribute authorities; what do you think about the Microsoft-originated
> Information Card scheme? http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=imi
>  IMO it will do what ACs never did because it addresses real-world use-cases and is
> already supported by Vista, XP and Firefox platforms while the AC use-case(?) is poorly
> researched and client-side implementations are scarce to say the least.
> 
> Anders Rundgren


--------------ms090500010709050801030504
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJIjCC
BI0wggN1oAMCAQICAhpTMA0GCSqGSIb3DQEBBQUAMHcxEzARBgoJkiaJk/IsZAEZFgNlZHUx
GTAXBgoJkiaJk/IsZAEZFglkYXJ0bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0
bW91dGggQ29sbGVnZTEcMBoGA1UEAxMTRGFydG1vdXRoIENlcnRBdXRoMTAeFw0wNTExMDgy
MDMzMDZaFw0wOTExMDkyMDMzMDZaMIHBMRMwEQYKCZImiZPyLGQBGRYDZWR1MRkwFwYKCZIm
iZPyLGQBGRYJZGFydG1vdXRoMQswCQYDVQQGEwJVUzEaMBgGA1UEChMRRGFydG1vdXRoIENv
bGxlZ2UxGjAYBgoJkiaJk/IsZAEBEwoxMjI1NjAyOTQ3MRowGAYDVQQDExFNYXNzaW1pbGlh
bm8gUGFsYTEuMCwGCSqGSIb3DQEJARYfTWFzc2ltaWxpYW5vLlBhbGFARGFydG1vdXRoLmVk
dTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAsv8obBpbhPixgdyIJj7UN0GYRNhsgWHB
muCE5j8v8IvCSJWRF9spKoR0NBYgOfJu8DwQuKTIgrvbp0EC3ikrneotL4KTGD1IqWz/bSXL
UR/bZAsc0r9PrvCUsZOi7wbijy784gOuqQUCJ2fJwKwk5SJ3RBaPnUROQXTp+LPSK8MCAwEA
AaOCAVowggFWMA4GA1UdDwEB/wQEAwIF4DARBglghkgBhvhCAQEEBAMCBaAwgaIGA1UdIASB
mjCBlzCBlAYKKwYBBAFBAgEBATCBhTA9BggrBgEFBQcCAjAxMBgWEURhcnRtb3V0aCBDb2xs
ZWdlMAMCAQEaFURhcnRtb3V0aCBDb2xsZWdlIENQUzBEBggrBgEFBQcCARY4aHR0cDovL3d3
dy5kYXJ0bW91dGguZWR1L35wa2lsYWIvRGFydG1vdXRoQ1BTXzRTZXAwMy5wZGYwKgYDVR0R
BCMwIYEfTWFzc2ltaWxpYW5vLlBhbGFARGFydG1vdXRoLmVkdTAfBgNVHSMEGDAWgBQ/wNbH
p08Afu8GmWdsvJYeTaN3EjA/BggrBgEFBQcBAQQzMDEwLwYIKwYBBQUHMAGGI2h0dHA6Ly9j
b2xsZWdlY2EuZGFydG1vdXRoLmVkdS9vY3NwMA0GCSqGSIb3DQEBBQUAA4IBAQDEYIWmG3Ht
wcgFiBbrYKp7YpI62hgAw9I3Dj9Ai+etQcMDZL8cWg3Kd7DwYHDkLxO7jl518HIJCk8Elk+Z
3Y2c0rR+c9WLuxE+EHEUmQg2AbgxzRGZAeMXj7jrv5w75IWiXBrW3SdDkjVH6MQFZVP1CBk7
PF3/+dzmiO6E5g4cVtphPSdK2qtnX7Sh0zdePzeE+e0BTnsWdN0yHgKabKx3dCiEnQXt96sA
Jf5ckg7fFLcplohwWlWJCpk8WwnJM0QGw3xbrZvLk+kIQgyh0sn2va4FgA1ae29cJ1d2NurA
Z+LMdei9/ZbzBeMoD9XPSYyj7zLuVXGLF/JQQoPywk5oMIIEjTCCA3WgAwIBAgICGlMwDQYJ
KoZIhvcNAQEFBQAwdzETMBEGCgmSJomT8ixkARkWA2VkdTEZMBcGCgmSJomT8ixkARkWCWRh
cnRtb3V0aDELMAkGA1UEBhMCVVMxGjAYBgNVBAoTEURhcnRtb3V0aCBDb2xsZWdlMRwwGgYD
VQQDExNEYXJ0bW91dGggQ2VydEF1dGgxMB4XDTA1MTEwODIwMzMwNloXDTA5MTEwOTIwMzMw
NlowgcExEzARBgoJkiaJk/IsZAEZFgNlZHUxGTAXBgoJkiaJk/IsZAEZFglkYXJ0bW91dGgx
CzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91dGggQ29sbGVnZTEaMBgGCgmSJomT8ixk
AQETCjEyMjU2MDI5NDcxGjAYBgNVBAMTEU1hc3NpbWlsaWFubyBQYWxhMS4wLAYJKoZIhvcN
AQkBFh9NYXNzaW1pbGlhbm8uUGFsYUBEYXJ0bW91dGguZWR1MIGfMA0GCSqGSIb3DQEBAQUA
A4GNADCBiQKBgQCy/yhsGluE+LGB3IgmPtQ3QZhE2GyBYcGa4ITmPy/wi8JIlZEX2ykqhHQ0
FiA58m7wPBC4pMiCu9unQQLeKSud6i0vgpMYPUipbP9tJctRH9tkCxzSv0+u8JSxk6LvBuKP
LvziA66pBQInZ8nArCTlIndEFo+dRE5BdOn4s9IrwwIDAQABo4IBWjCCAVYwDgYDVR0PAQH/
BAQDAgXgMBEGCWCGSAGG+EIBAQQEAwIFoDCBogYDVR0gBIGaMIGXMIGUBgorBgEEAUECAQEB
MIGFMD0GCCsGAQUFBwICMDEwGBYRRGFydG1vdXRoIENvbGxlZ2UwAwIBARoVRGFydG1vdXRo
IENvbGxlZ2UgQ1BTMEQGCCsGAQUFBwIBFjhodHRwOi8vd3d3LmRhcnRtb3V0aC5lZHUvfnBr
aWxhYi9EYXJ0bW91dGhDUFNfNFNlcDAzLnBkZjAqBgNVHREEIzAhgR9NYXNzaW1pbGlhbm8u
UGFsYUBEYXJ0bW91dGguZWR1MB8GA1UdIwQYMBaAFD/A1senTwB+7waZZ2y8lh5No3cSMD8G
CCsGAQUFBwEBBDMwMTAvBggrBgEFBQcwAYYjaHR0cDovL2NvbGxlZ2VjYS5kYXJ0bW91dGgu
ZWR1L29jc3AwDQYJKoZIhvcNAQEFBQADggEBAMRghaYbce3ByAWIFutgqntikjraGADD0jcO
P0CL561BwwNkvxxaDcp3sPBgcOQvE7uOXnXwcgkKTwSWT5ndjZzStH5z1Yu7ET4QcRSZCDYB
uDHNEZkB4xePuOu/nDvkhaJcGtbdJ0OSNUfoxAVlU/UIGTs8Xf/53OaI7oTmDhxW2mE9J0ra
q2dftKHTN14/N4T57QFOexZ03TIeAppsrHd0KISdBe33qwAl/lySDt8UtymWiHBaVYkKmTxb
CckzRAbDfFutm8uT6QhCDKHSyfa9rgWADVp7b1wnV3Y26sBn4sx16L39lvMF4ygP1c9JjKPv
Mu5VcYsX8lBCg/LCTmgxggL4MIIC9AIBATB9MHcxEzARBgoJkiaJk/IsZAEZFgNlZHUxGTAX
BgoJkiaJk/IsZAEZFglkYXJ0bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91
dGggQ29sbGVnZTEcMBoGA1UEAxMTRGFydG1vdXRoIENlcnRBdXRoMQICGlMwCQYFKw4DAhoF
AKCCAdEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDgxMTE2
MDUwMTExWjAjBgkqhkiG9w0BCQQxFgQUSze+elXcsC6RnxgJBf2WG2d3h/IwUgYJKoZIhvcN
AQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYF
Kw4DAgcwDQYIKoZIhvcNAwICASgwgYwGCSsGAQQBgjcQBDF/MH0wdzETMBEGCgmSJomT8ixk
ARkWA2VkdTEZMBcGCgmSJomT8ixkARkWCWRhcnRtb3V0aDELMAkGA1UEBhMCVVMxGjAYBgNV
BAoTEURhcnRtb3V0aCBDb2xsZWdlMRwwGgYDVQQDExNEYXJ0bW91dGggQ2VydEF1dGgxAgIa
UzCBjgYLKoZIhvcNAQkQAgsxf6B9MHcxEzARBgoJkiaJk/IsZAEZFgNlZHUxGTAXBgoJkiaJ
k/IsZAEZFglkYXJ0bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91dGggQ29s
bGVnZTEcMBoGA1UEAxMTRGFydG1vdXRoIENlcnRBdXRoMQICGlMwDQYJKoZIhvcNAQEBBQAE
gYCVnVTlcOsRt37rwh9xKRoi8UHLZYVCBeL5iCTgeo87zDpgaLfQo1niTXyZky+R4tBfjyqD
iGcnre68FqBNIRaL3SsyFbzp0I4jvsFG49xwQ0aYGAwT0H6y381uCU/I+I0nAQWzgnrCu0vJ
UreF7OyTQ5Y5Yq4YO9o1rcqn5ZLxEQAAAAAAAA==
--------------ms090500010709050801030504--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAG8gvBq088316 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 16 Nov 2008 01:42:57 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAG8gvTX088315; Sun, 16 Nov 2008 01:42:57 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pne-smtpout1-sn2.hy.skanova.net (pne-smtpout1-sn2.hy.skanova.net [81.228.8.83]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAG8gjSH088309 for <[e-mail]>; Sun, 16 Nov 2008 01:42:56 -0700 (MST) (envelope-from [e-mail])
Received: from AndersPC (81.232.45.215) by pne-smtpout1-sn2.hy.skanova.net (7.3.129) id 48A144C5019593E5; Sun, 16 Nov 2008 09:42:43 +0100
Message-ID: <9D3C913A55AD41538FC235BF2B30EBBC@AndersPC>
From: "Anders Rundgren" <[e-mail]>
To: "Massimiliano Pala" <[e-mail]>, "pkix" <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: Re: Attribute Authorities
Date: Sun, 16 Nov 2008 09: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 Windows Mail 6.0.6000.20661
X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16669
Sender: [e-mail]
Precedence: 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 thought that an X509 AC is supposed to contain a binding to a PKC (or identity) and that you need 
to trust both CAs in order to get something useful out of this concept.  To me that sounds like that 
there already is a solution.

Talking about attribute authorities; what do you think about the Microsoft-originated Information 
Card scheme?
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=imi
IMO it will do what ACs never did because it addresses real-world use-cases and is already supported 
by Vista, XP and Firefox platforms while the AC use-case(?) is poorly researched and client-side 
implementations are scarce to say the least.

Anders Rundgren

----- Original Message ----- 
From: "Massimiliano Pala" <[e-mail]>
To: "pkix" <[e-mail]>
Sent: Saturday, November 15, 2008 10:53
Subject: Attribute Authorities


Hi all,

I was wondering if there is a way to actually identify an AA based on the
contents of its certificate (eg., extendedKeyUsage, an extension, an
OID,... ) ?

How can a third party know that an Identity has been identified by a CA
as a valid AA ? I know that the problem of Identity and Authorization
should not be tied together - but it would be easier for an application
to know that an identity can sign attribute certificates. Is there anything
of the sort ? And if not, has anybody thought about it ?

Later,
Max

-- 

Best Regards,

Massimiliano Pala

--o------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager]  [e-mail]
                                                    [e-mail]

Dartmouth Computer Science Dept               Home Phone: [phone]
PKI/Trust Laboratory                          Work Phone: [phone]
--o------------------------------------------------------------------------

People who think they know everything are a great annoyance to those of us
who do.
   -- Isaac Asimov



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAFLLAUs068029 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 15 Nov 2008 14:21:10 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAFLLAeK068028; Sat, 15 Nov 2008 14:21:10 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.cs.dartmouth.edu (mail.cs.dartmouth.edu [129.170.212.100]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAFLKwaV068016 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Sat, 15 Nov 2008 14:21:09 -0700 (MST) (envelope-from [e-mail])
Received: from titan.cs.dartmouth.edu (dhcp-212-194.cs.dartmouth.edu [129.170.212.194]) (authenticated bits=0) by mail.cs.dartmouth.edu (8.14.2/8.14.2) with ESMTP id mAFLKpWB013748 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Sat, 15 Nov 2008 16:20:57 -0500
Message-ID: <[e-mail]>
Date: Sat, 15 Nov 2008 16:23:18 +0630
From: Massimiliano Pala <[e-mail]>
Organization: Dartmouth College - Computer Science Department
User-Agent: Thunderbird 2.0.0.16 (X11/20080707)
MIME-Version: 1.0
To: pkix <[e-mail]>
Subject: Attribute Authorities
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080809060906030406020105"
Sender: [e-mail]
Precedence: 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.

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

Hi all,

I was wondering if there is a way to actually identify an AA based on the
contents of its certificate (eg., extendedKeyUsage, an extension, an
OID,... ) ?

How can a third party know that an Identity has been identified by a CA
as a valid AA ? I know that the problem of Identity and Authorization
should not be tied together - but it would be easier for an application
to know that an identity can sign attribute certificates. Is there anything
of the sort ? And if not, has anybody thought about it ?

Later,
Max

-- 

Best Regards,

	Massimiliano Pala

--o------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager]  [e-mail]
                                                    [e-mail]

Dartmouth Computer Science Dept               Home Phone: [phone]
PKI/Trust Laboratory                          Work Phone: [phone]
--o------------------------------------------------------------------------

People who think they know everything are a great annoyance to those of us
who do.
							   -- Isaac Asimov

--------------ms080809060906030406020105
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJIjCC
BI0wggN1oAMCAQICAhpTMA0GCSqGSIb3DQEBBQUAMHcxEzARBgoJkiaJk/IsZAEZFgNlZHUx
GTAXBgoJkiaJk/IsZAEZFglkYXJ0bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0
bW91dGggQ29sbGVnZTEcMBoGA1UEAxMTRGFydG1vdXRoIENlcnRBdXRoMTAeFw0wNTExMDgy
MDMzMDZaFw0wOTExMDkyMDMzMDZaMIHBMRMwEQYKCZImiZPyLGQBGRYDZWR1MRkwFwYKCZIm
iZPyLGQBGRYJZGFydG1vdXRoMQswCQYDVQQGEwJVUzEaMBgGA1UEChMRRGFydG1vdXRoIENv
bGxlZ2UxGjAYBgoJkiaJk/IsZAEBEwoxMjI1NjAyOTQ3MRowGAYDVQQDExFNYXNzaW1pbGlh
bm8gUGFsYTEuMCwGCSqGSIb3DQEJARYfTWFzc2ltaWxpYW5vLlBhbGFARGFydG1vdXRoLmVk
dTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAsv8obBpbhPixgdyIJj7UN0GYRNhsgWHB
muCE5j8v8IvCSJWRF9spKoR0NBYgOfJu8DwQuKTIgrvbp0EC3ikrneotL4KTGD1IqWz/bSXL
UR/bZAsc0r9PrvCUsZOi7wbijy784gOuqQUCJ2fJwKwk5SJ3RBaPnUROQXTp+LPSK8MCAwEA
AaOCAVowggFWMA4GA1UdDwEB/wQEAwIF4DARBglghkgBhvhCAQEEBAMCBaAwgaIGA1UdIASB
mjCBlzCBlAYKKwYBBAFBAgEBATCBhTA9BggrBgEFBQcCAjAxMBgWEURhcnRtb3V0aCBDb2xs
ZWdlMAMCAQEaFURhcnRtb3V0aCBDb2xsZWdlIENQUzBEBggrBgEFBQcCARY4aHR0cDovL3d3
dy5kYXJ0bW91dGguZWR1L35wa2lsYWIvRGFydG1vdXRoQ1BTXzRTZXAwMy5wZGYwKgYDVR0R
BCMwIYEfTWFzc2ltaWxpYW5vLlBhbGFARGFydG1vdXRoLmVkdTAfBgNVHSMEGDAWgBQ/wNbH
p08Afu8GmWdsvJYeTaN3EjA/BggrBgEFBQcBAQQzMDEwLwYIKwYBBQUHMAGGI2h0dHA6Ly9j
b2xsZWdlY2EuZGFydG1vdXRoLmVkdS9vY3NwMA0GCSqGSIb3DQEBBQUAA4IBAQDEYIWmG3Ht
wcgFiBbrYKp7YpI62hgAw9I3Dj9Ai+etQcMDZL8cWg3Kd7DwYHDkLxO7jl518HIJCk8Elk+Z
3Y2c0rR+c9WLuxE+EHEUmQg2AbgxzRGZAeMXj7jrv5w75IWiXBrW3SdDkjVH6MQFZVP1CBk7
PF3/+dzmiO6E5g4cVtphPSdK2qtnX7Sh0zdePzeE+e0BTnsWdN0yHgKabKx3dCiEnQXt96sA
Jf5ckg7fFLcplohwWlWJCpk8WwnJM0QGw3xbrZvLk+kIQgyh0sn2va4FgA1ae29cJ1d2NurA
Z+LMdei9/ZbzBeMoD9XPSYyj7zLuVXGLF/JQQoPywk5oMIIEjTCCA3WgAwIBAgICGlMwDQYJ
KoZIhvcNAQEFBQAwdzETMBEGCgmSJomT8ixkARkWA2VkdTEZMBcGCgmSJomT8ixkARkWCWRh
cnRtb3V0aDELMAkGA1UEBhMCVVMxGjAYBgNVBAoTEURhcnRtb3V0aCBDb2xsZWdlMRwwGgYD
VQQDExNEYXJ0bW91dGggQ2VydEF1dGgxMB4XDTA1MTEwODIwMzMwNloXDTA5MTEwOTIwMzMw
NlowgcExEzARBgoJkiaJk/IsZAEZFgNlZHUxGTAXBgoJkiaJk/IsZAEZFglkYXJ0bW91dGgx
CzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91dGggQ29sbGVnZTEaMBgGCgmSJomT8ixk
AQETCjEyMjU2MDI5NDcxGjAYBgNVBAMTEU1hc3NpbWlsaWFubyBQYWxhMS4wLAYJKoZIhvcN
AQkBFh9NYXNzaW1pbGlhbm8uUGFsYUBEYXJ0bW91dGguZWR1MIGfMA0GCSqGSIb3DQEBAQUA
A4GNADCBiQKBgQCy/yhsGluE+LGB3IgmPtQ3QZhE2GyBYcGa4ITmPy/wi8JIlZEX2ykqhHQ0
FiA58m7wPBC4pMiCu9unQQLeKSud6i0vgpMYPUipbP9tJctRH9tkCxzSv0+u8JSxk6LvBuKP
LvziA66pBQInZ8nArCTlIndEFo+dRE5BdOn4s9IrwwIDAQABo4IBWjCCAVYwDgYDVR0PAQH/
BAQDAgXgMBEGCWCGSAGG+EIBAQQEAwIFoDCBogYDVR0gBIGaMIGXMIGUBgorBgEEAUECAQEB
MIGFMD0GCCsGAQUFBwICMDEwGBYRRGFydG1vdXRoIENvbGxlZ2UwAwIBARoVRGFydG1vdXRo
IENvbGxlZ2UgQ1BTMEQGCCsGAQUFBwIBFjhodHRwOi8vd3d3LmRhcnRtb3V0aC5lZHUvfnBr
aWxhYi9EYXJ0bW91dGhDUFNfNFNlcDAzLnBkZjAqBgNVHREEIzAhgR9NYXNzaW1pbGlhbm8u
UGFsYUBEYXJ0bW91dGguZWR1MB8GA1UdIwQYMBaAFD/A1senTwB+7waZZ2y8lh5No3cSMD8G
CCsGAQUFBwEBBDMwMTAvBggrBgEFBQcwAYYjaHR0cDovL2NvbGxlZ2VjYS5kYXJ0bW91dGgu
ZWR1L29jc3AwDQYJKoZIhvcNAQEFBQADggEBAMRghaYbce3ByAWIFutgqntikjraGADD0jcO
P0CL561BwwNkvxxaDcp3sPBgcOQvE7uOXnXwcgkKTwSWT5ndjZzStH5z1Yu7ET4QcRSZCDYB
uDHNEZkB4xePuOu/nDvkhaJcGtbdJ0OSNUfoxAVlU/UIGTs8Xf/53OaI7oTmDhxW2mE9J0ra
q2dftKHTN14/N4T57QFOexZ03TIeAppsrHd0KISdBe33qwAl/lySDt8UtymWiHBaVYkKmTxb
CckzRAbDfFutm8uT6QhCDKHSyfa9rgWADVp7b1wnV3Y26sBn4sx16L39lvMF4ygP1c9JjKPv
Mu5VcYsX8lBCg/LCTmgxggL4MIIC9AIBATB9MHcxEzARBgoJkiaJk/IsZAEZFgNlZHUxGTAX
BgoJkiaJk/IsZAEZFglkYXJ0bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91
dGggQ29sbGVnZTEcMBoGA1UEAxMTRGFydG1vdXRoIENlcnRBdXRoMQICGlMwCQYFKw4DAhoF
AKCCAdEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDgxMTE1
MDk1MzE4WjAjBgkqhkiG9w0BCQQxFgQUwYVbHfKPYsb1anoome/7ihngH0MwUgYJKoZIhvcN
AQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYF
Kw4DAgcwDQYIKoZIhvcNAwICASgwgYwGCSsGAQQBgjcQBDF/MH0wdzETMBEGCgmSJomT8ixk
ARkWA2VkdTEZMBcGCgmSJomT8ixkARkWCWRhcnRtb3V0aDELMAkGA1UEBhMCVVMxGjAYBgNV
BAoTEURhcnRtb3V0aCBDb2xsZWdlMRwwGgYDVQQDExNEYXJ0bW91dGggQ2VydEF1dGgxAgIa
UzCBjgYLKoZIhvcNAQkQAgsxf6B9MHcxEzARBgoJkiaJk/IsZAEZFgNlZHUxGTAXBgoJkiaJ
k/IsZAEZFglkYXJ0bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91dGggQ29s
bGVnZTEcMBoGA1UEAxMTRGFydG1vdXRoIENlcnRBdXRoMQICGlMwDQYJKoZIhvcNAQEBBQAE
gYAh+Hd9aPHUOwzdG3+GVMoZoyJ1trbFCNVUm+7vGbn2mlTDvH1hRg65H1j/s3UpOsIkAseZ
feMpa82CV4ZVySrM6Z2X11M6d7nDukefTwvwnjKKADFlEm7cSTXYP5xB5Hdwj/k9rFC5MveV
iPpz6A8bMnfghzXz2s0UcFJcJVT1IwAAAAAAAA==
--------------ms080809060906030406020105--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAFKpJbX066884 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 15 Nov 2008 13:51:19 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAFKpJw6066883; Sat, 15 Nov 2008 13:51:19 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mAFKp8PL066871 for <[e-mail]>; Sat, 15 Nov 2008 13:51:18 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 4131 invoked from network); 15 Nov 2008 20:51:09 -0000
Received: from [e-mail] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;15 Nov 2008 20:51:09 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 15 Nov 2008 20:51:09 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: Signing and Encrypting with the same key?
Date: Sat, 15 Nov 2008 15:51:06 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Signing and Encrypting with the same key?
Thread-Index: AclHMVCyvv2uk1j/Ti2OuoWlXqZ98gAMmKDQ
References: <[e-mail]> <B9A9F0E608D94D2CA899102A88789787@AndersPC> <[e-mail]> <51604CB892B44C39BAF60D61875EB21E@AndersPC> <[e-mail]>
From: "Santosh Chokhani" <[e-mail]>
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>

One benefit of setting both bits for a TLS Server for RSA algorithm is
that when the Server is acting as a Server, the key is used to encrypt
and when the Server acts as a client, the same key can be used to
perform client authentication using digital signature.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Stephen Wilson
Sent: Saturday, November 15, 2008 9:34 AM
To: [e-mail]
Subject: Re: Signing and Encrypting with the same key?



And a short reiteration of what I thought was the answer:

Using the same key pair for signing and encryption (key exchange) is not

cryptanalytically a bad idea.  Rather, it is merely convention dating=20
back to the idea that backing up (or escrowing) keys used for encryption

dilutes their value for authentication, because of the possibility that=20
the extra copies might be used for signing things without the owner's=20
permission.

So, if TLS uses the same key pair, it's not breaking any rules.

Cheers,

Steve Wilson.


PS. I actually always thought the argument for key separation was=20
massively over-stated.  "Non repudiation" is one the greatest red=20
herrings in the history of cryptography.  If someone uses my signing key

without my permission, then I shouldn't be held accountable for that, if

it can be shown that the usage was illicit.  Some jurisdictions grant an

extra degree of 'attribution' when qualified digital signature devices=20
are used, but as far as I know, the attribution is still not absolute.=20
Rather, it's just a matter of onus of proof; if I can show that my=20
private key was used by someone else, without my consent, then I can=20
repudiate the transaction.  It's just another form of identity fraud;=20
investigating fraud entails working who really did what to whom.  It's=20
exactly the same with any authenticator -- a password, PKI private key,=20
biometric or whatever.  The idea that someone cannot in principle ever=20
repudiate a digitally signed transaction is plain silly, and to my=20
knowledge, has no actual legal foundation.  I'd like to know the precise

history of the NR bit in X.509.  Who actually thought of it, were they=20
an engineer or a lawyer, and what if any debate went on at the time?


Stephen Wilson
Managing Director
Lockstep Technologies

Phone [phone]

www.lockstep.com.au/technologies
-------------------
  * ABC TV 'The New Inventors' Nov 2008
  * Global Security Challenge Asia Top Five 2008
  * Australian Technology Showcase 2008
  * AusIndustry COMET Grant 2007
  * ICT Secrets of Innovation Finalist (Security) 2007
  * Anthill / PwC Cool Company Finalist (Innovation) 2007
-------------------
Lockstep Technologies develops unique new smart ID solutions to
safeguard identity and privacy. Lockstep Consulting provides
independent specialist advice and analysis on authentication, PKI
and smartcards.



Anders Rundgren wrote:
> Just a short iteration of this question:
>=20
> If using a single key for authentication and encryption is a bad idea,
how come that TLS after all=20
> these years still only relies on a single key-pair for authenticating
the server as well as=20
> encrypting the channel?
>=20
> Anders
>=20
>=20



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAFEZ6Eh051289 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 15 Nov 2008 07:35:06 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAFEZ6QW051288; Sat, 15 Nov 2008 07:35:06 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp152.sat.emailsrvr.com (smtp152.sat.emailsrvr.com [66.216.121.152]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAFEYt71051274 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Sat, 15 Nov 2008 07:35:06 -0700 (MST) (envelope-from [e-mail])
Received: from relay5.relay.sat.mlsrvr.com (localhost [127.0.0.1]) by relay5.relay.sat.mlsrvr.com (SMTP Server) with ESMTP id 6BCBFBEDF9 for <[e-mail]>; Sat, 15 Nov 2008 09:34:54 -0500 (EST)
Received: by relay5.relay.sat.mlsrvr.com (Authenticated sender: swilson-AT-lockstep.com.au) with ESMTP id 90F8FBEDA2 for <[e-mail]>; Sat, 15 Nov 2008 09:34:53 -0500 (EST)
Message-ID: <[e-mail]>
Date: Sun, 16 Nov 2008 01:34:05 +1100
From: Stephen Wilson <[e-mail]>
Reply-To: [e-mail]
Organization: Lockstep
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Signing and Encrypting with the same key?
References: <[e-mail]> <B9A9F0E608D94D2CA899102A88789787@AndersPC> <[e-mail]> <51604CB892B44C39BAF60D61875EB21E@AndersPC>
In-Reply-To: <51604CB892B44C39BAF60D61875EB21E@AndersPC>
Content-Type: text/plain; charset=UTF-8; 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>

And a short reiteration of what I thought was the answer:

Using the same key pair for signing and encryption (key exchange) is not 
cryptanalytically a bad idea.  Rather, it is merely convention dating 
back to the idea that backing up (or escrowing) keys used for encryption 
dilutes their value for authentication, because of the possibility that 
the extra copies might be used for signing things without the owner's 
permission.

So, if TLS uses the same key pair, it's not breaking any rules.

Cheers,

Steve Wilson.


PS. I actually always thought the argument for key separation was 
massively over-stated.  "Non repudiation" is one the greatest red 
herrings in the history of cryptography.  If someone uses my signing key 
without my permission, then I shouldn't be held accountable for that, if 
it can be shown that the usage was illicit.  Some jurisdictions grant an 
extra degree of 'attribution' when qualified digital signature devices 
are used, but as far as I know, the attribution is still not absolute. 
Rather, it's just a matter of onus of proof; if I can show that my 
private key was used by someone else, without my consent, then I can 
repudiate the transaction.  It's just another form of identity fraud; 
investigating fraud entails working who really did what to whom.  It's 
exactly the same with any authenticator -- a password, PKI private key, 
biometric or whatever.  The idea that someone cannot in principle ever 
repudiate a digitally signed transaction is plain silly, and to my 
knowledge, has no actual legal foundation.  I'd like to know the precise 
history of the NR bit in X.509.  Who actually thought of it, were they 
an engineer or a lawyer, and what if any debate went on at the time?


Stephen Wilson
Managing Director
Lockstep Technologies

Phone [phone]

www.lockstep.com.au/technologies
-------------------
  * ABC TV 'The New Inventors' Nov 2008
  * Global Security Challenge Asia Top Five 2008
  * Australian Technology Showcase 2008
  * AusIndustry COMET Grant 2007
  * ICT Secrets of Innovation Finalist (Security) 2007
  * Anthill / PwC Cool Company Finalist (Innovation) 2007
-------------------
Lockstep Technologies develops unique new smart ID solutions to
safeguard identity and privacy. Lockstep Consulting provides
independent specialist advice and analysis on authentication, PKI
and smartcards.



Anders Rundgren wrote:
> Just a short iteration of this question:
> 
> If using a single key for authentication and encryption is a bad idea, how come that TLS after all 
> these years still only relies on a single key-pair for authenticating the server as well as 
> encrypting the channel?
> 
> Anders
> 
> 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAFE9rDq050017 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 15 Nov 2008 07:09:53 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAFE9rvU050016; Sat, 15 Nov 2008 07:09:53 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sasl.smtp.pobox.com (a-sasl-quonix.sasl.smtp.pobox.com [208.72.237.25]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAFE9gaN050006 for <[e-mail]>; Sat, 15 Nov 2008 07:09:53 -0700 (MST) (envelope-from [e-mail])
Received: from localhost.localdomain (localhost [127.0.0.1]) by b-sasl-quonix.sasl.smtp.pobox.com (Postfix) with ESMTP id 6942C16B7F for <[e-mail]>; Sat, 15 Nov 2008 09:09:41 -0500 (EST)
Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by b-sasl-quonix.sasl.smtp.pobox.com (Postfix) with ESMTPSA id 14A7216AC2 for <[e-mail]>; Sat, 15 Nov 2008 09:09:39 -0500 (EST)
Message-ID: <[e-mail]>
Date: Sat, 15 Nov 2008 06:10:14 -0800
From: Mike <[e-mail]>
User-Agent: Thunderbird 2.0.0.16 (Windows/20080708)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Signing and Encrypting with the same key?
References: <[e-mail]> <B9A9F0E608D94D2CA899102A88789787@AndersPC> <[e-mail]> <51604CB892B44C39BAF60D61875EB21E@AndersPC>
In-Reply-To: <51604CB892B44C39BAF60D61875EB21E@AndersPC>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Pobox-Relay-ID: 0BCAE484-B31F-11DD-9606-C128113D384A-38729857!a-sasl-quonix.pobox.com
Sender: [e-mail]
Precedence: 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 a particular TLS cipher suite, a key is used for only one purpose,
either signing or encrypting, not both.  In the case of an RSA key
exchange, the act of encrypting the channel has the side effect of
authenticating the server, since the server can only decrypt the
secret if it has the private key.  In other exchanges, an RSA or DSA
key is used to sign some Diffie-Hellman parameters.  The signature
provides the authentication of the server, but the Diffie-Hellman
exchange encrypts the channel.

The issue you raise is whether you use the same RSA key for both
types of cipher suites; in pure RSA exchanges, the key is used for
encryption, and in Diffie-Hellman exchanges it is used for signing.
This is an implementation/configuration issue, not a problem with TLS.
It is possible for a server to use two different keys, but it is
easier (and cheaper) to just use one, so that's what lots of people
do.

Mike


Anders Rundgren wrote:
> Just a short iteration of this question:
> 
> If using a single key for authentication and encryption is a bad idea, how come that TLS after all 
> these years still only relies on a single key-pair for authenticating the server as well as 
> encrypting the channel?
> 
> Anders



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAFBYMmP043335 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 15 Nov 2008 04:34:22 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAFBYMkM043334; Sat, 15 Nov 2008 04:34:22 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pne-smtpout1-sn2.hy.skanova.net (pne-smtpout1-sn2.hy.skanova.net [81.228.8.83]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAFBYBNN043325 for <[e-mail]>; Sat, 15 Nov 2008 04:34:22 -0700 (MST) (envelope-from [e-mail])
Received: from AndersPC (81.232.45.215) by pne-smtpout1-sn2.hy.skanova.net (7.3.129) id 48A144C50193AA20 for [e-mail]; Sat, 15 Nov 2008 12:34:11 +0100
Message-ID: <51604CB892B44C39BAF60D61875EB21E@AndersPC>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>
References: <[e-mail]> <B9A9F0E608D94D2CA899102A88789787@AndersPC> <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: Re: Signing and Encrypting with the same key?
Date: Sat, 15 Nov 2008 12:34:13 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Windows Mail 6.0.6000.20661
X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16669
Sender: [e-mail]
Precedence: 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 a short iteration of this question:

If using a single key for authentication and encryption is a bad idea, how come that TLS after all 
these years still only relies on a single key-pair for authenticating the server as well as 
encrypting the channel?

Anders




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mADKOldg036156 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Nov 2008 13:24:47 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mADKOlno036155; Thu, 13 Nov 2008 13:24:47 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp104.biz.mail.re2.yahoo.com (smtp104.biz.mail.re2.yahoo.com [206.190.52.173]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mADKOam0036146 for <[e-mail]>; Thu, 13 Nov 2008 13:24:46 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 54962 invoked from network); 13 Nov 2008 20:24:36 -0000
Received: from unknown (HELO Wylie) ([e-mail]@96.231.123.19 with login) by smtp104.biz.mail.re2.yahoo.com with SMTP; 13 Nov 2008 20:24:35 -0000
X-YMail-OSG: Di3LrAgVM1lOr0A67SidTMPpppdfI9khvsF8Mwwyu4jorsCDz3JTycItWzvSpFg0xNtndC4jzQxBLLTtUOT7bC0r5HVIjsHRh1dd7ZsnZQp5f4GnuwPKBR1bzNPS2oyJP09RX7PeaYJINkSD4M09HhYHMQ_3FgnVCsyuzkafQyUPfy_fgIj9vY8co_iw
X-Yahoo-Newman-Property: ymail-3
From: "Turner, Sean P." <[e-mail]>
To: <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: RE: AD comments for draft-ietf-pkix-ecc-subpubkeyinfo-09
Date: Thu, 13 Nov 2008 15:24:21 -0500
Organization: IECA, Inc.
Message-ID: <6DE5ACAFBF0648278ABF3936799A87FA@Wylie>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
Thread-Index: AclFkTVKBddzMZh/RymSj/vhXGDRogAKSpkA
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>

Pasi,

Thanks for your comments.  Responses inline.

spt

>-----Original Message-----
>From: [e-mail]
>Sent: Thursday, November 13, 2008 8:11 AM
>To: [e-mail]
>Subject: AD comments for draft-ietf-pkix-ecc-subpubkeyinfo-09
>
>
>I'm now doing the AD review for draft-ietf-pkix-ecc-subpubkeyinfo-09.
>My situation is slightly unusual, since I've never read the 
>draft before -- usually the AD has followed the draft for some 
>time, and is at least somewhat familiar with the WG 
>discussions that lead to making the decisions that were made. 
>So, I might be asking questions that were discussed already earlier...
>
>In general, the document looks quite good. I've identified 
>couple of topics that I'd like to discuss with the WG (plus some minor
>clarifications/comments):
>
>
>Topic #1: implicitCurve
>
>I'd like to better understand the motivation behind this option.
>It certainly saves ~10 bytes (one OID) in the certificate, but doesn't
>it also mean the end-entity certificate does not any longer contain 
>the whole public key? (since the ECPoint value alone is not useful 
>without knowing the curve)
>
>If that's the case, it would significantly complicate using the
>certificate to "carry public keys" in situations where the recipient
>does not necessarily do path validation (and may not have the issuer's
>public key).
>
>This situation is of course very common in web browsing (browser asks
>you whether you want to accept the certificate anyway), but occurs
>also in e.g. DTLS-SRTP and RFC 4572 (where the party receiving the
>certificate might do real path validation, or might just check that it
>matches the fingerprint received in SIP/SDP), and Syslog-over-TLS
>(where small implementations might use fingerprints instead of path
>validation, even if the certificate isn't self-signed). And I'm pretty
>sure more uses like this will be specified in the future.
>
>Would the spec be missing important functionality if it just said
>"implicitCurve MUST NOT be used" (like it says for specifiedCurve)?

To answer your questions:

1) Using parameter inheritance would mean that the EE certificate would not
contain all of the necessary information that would be required for relying
party to process a certificate.  The relying party might luck in to guessing
the curve because there are only so many "well known" curves for a given key
size, but to be sure the relying party would need to get the curve either
from an issuer's certificate or through some other means.  The last
paragraph of 2.1.1 address these options.

2) The rationale for retaining parameter inheritance is that many people
that support DSA already deal with parameter inheritance in that context.
So, it  may not be a burden to keep this capability in the specification.

It's PKIX so we generally assume people are doing path validation ;)

>Topic #2: scope of Appendix A
>
>For a document that specifies how to carry ECC public keys in
>SubjectPublicKeyInfo, I was sort of expecting ASN.1 module(s) to do
>so.  When I got to Appendix A, I was very surprised to find ASN.1
>modules that contain mostly other things (not related to ECC at all,
>or not related to SubjectPublicKeyInfo) -- nothing in the main
>document (abstract and Sections 1..8) hinted that this would be
>coming. Could you briefly explain why ASN.1 about RSA, DSA, MD5, 
>etc. belongs in this document?

One of early comments was that since we're updating RFC 3279, we'd end up
with a Chinese menu for implementers if we didn't update the entire RFC 3279
module.  RFC 3279 includes more than ECC "stuff" so if we update the RFC
3279 module have baggage.

>Topic #3: "informative" ASN.1
>
>I'm wondering whether calling a section consisting solely of formal
>language "informative" makes sense, and if just adding that one word
>avoids a normative reference to draft-ietf-pkix-new-asn1 (due to
>"IMPORTS" -- a case which is mentioned explicitly in RFC 3967).
>
>It looks like stuff implementors would use, and perhaps more
>importantly, something writers of future IETF specifications might
>want to use. Can we simultaneously claim it's not really part of the
>specification (and thus the reference to new-asn1 is not normative)
>and allow future documents to import from it (with a normative
>reference)?

The reference to draft-ietf-pkix-new-asn1 is an informative reference.  I
wish the reference could be normative, but we'd be blocked on it.  We could
1) pull the appendix out of the document (we'd have some text tweaking to
do) and put the appendix in a) separate document b) put it in
draft-ietf-pkix-new-asn1 2) leave it in the document and produce an update
after draft-ietf-pkix-asn1 gets published that says the appendices are now
normative 3) indicate that it does not form a normative part of the document
(not sure what we'd do with the reference).  I am willing to be guided on
the best way forward.

>The remaining comments are basically questions or suggestions
>for minor clarifications:
>
>- Section 2.2: ANSI X9.62 specifies a third point form (that isn't 
>in [SEC1]); should this text say "the hybrid form MUST NOT be used"?
>Or is the intent something else?

I do not remember discussing the hybrid form and I don't remember back to
the RFC 3279 discussion wrt to the hybrid form.   I would propose we add a
new second sentence to the seconds paragraph "The hybrid form from [X9.62]
MUST NOT be used."

>- I'm trying to understand how this ASN.1 fragment (and several
>other similar cases) can actually compile:
>
>   sa-rsaWithMD2 SIGNATURE-ALGORITHM ::= { 
>     IDENTIFIER md2WithRSAEncryption 
>     PARAMS TYPE NULL ARE present 
>     HASHES { mda-md2 } 
>     PUBLIC KEYS { pk-rsa } 
>   } 
>
>I'm puzzled because the string "present" is not one of the values
>enumerated in ParamOptions -- but perhaps it's an ASN.1 keyword or
>something?  (I have to admit that while I could usually read the old
>1988 ASN.1 syntax, I don't really understand how this CLASS stuff
>works...)

"present" needs to be replaced by "required" (in 3 places).  I had a module
that I was compiling and I forgot to copy over these changes :(

>- A question: for some AlgorithmIdentifiers it's occasionally been
>unclear whether the parameters must be NULL, must be omitted, or if
>either is allowed. This document looks quite clear about this topic --
>but is it 100% consistent with e.g. RFC 3279, PKCS#1 and other
>relevant documents? If it's not, it would be important to explicitly
>point out the differences.

I believe we're consistent.

>- Section 2.1.2 says "Algorithms used with elliptic curve cryptography
>fall in two different categories: signature and key agreement
>algorithms." Do you consider encryption schemes such as ECIES
>(specified in IEEE 1363) to be "key agreement"? (it certainly has
>similarities to ECDH). This question is also relevant for Section 3,
>where keyEncipherment bit is never mentioned.  Or perhaps the text's
>intent is that other uses of elliptic curves than ECDSA/ECDH/ECMQV
>are beyond the scope?

I definitely wasn't (not sure about the other authors) thinking about ECIES
when working on this ID.  That sentence was meant to be more of an
introductory sentence to explain why we've got three OIDs.  We could do the
following for 2.1.2 (but does this address your comment?):

OLD:

Algorithms used with elliptic curve cryptography fall in two different
categories: signature and key agreement algorithms.  ECDSA uses the pk-ec
identifier described in 2.1.1. Two sets of key agreement algorithms are
identified herein: the Elliptic Curve Diffie-Hellman (ECDH) key agreement
scheme and the Elliptic Curve Menezes-Qu-Vanstone (ECMQV) key agreement
scheme. All algorithms are identified by an object identifier and have
parameters.  The object identifier varies based on the algorithm but the
parameters are always ECParameters and they MUST always be present (see
Section 2.1.1).

NEW:

Two "restricted" algorithms are defined for key agreement algorithms: the
Elliptic Curve Diffie-Hellman (ECDH) key agreement scheme and the Elliptic
Curve Menezes-Qu-Vanstone (ECMQV) key agreement scheme. Both algorithms are
identified by an object identifier and have parameters.  The object
identifier varies based on the algorithm but the parameters are always
ECParameters and they MUST always be present (see Section 2.1.1).

>- The ASN.1 modules in Appendix A have a number of "TBA" values -- 
>it would be a good idea to have an explicit note (in the document) 
>saying who will fill them and at what point. Also, it's slightly 
>difficult to tell which TBAs refer to the same value, and which 
>to different values -- using something like "TBA1", "TBA2", etc., 
>might help.

I'll add a note in Appendix A to indicate that all the TBAs are going to
filled in during AUTH48.

>- Typos:
>Section 2.1.1 "ASNI" 
>Appendix A.3, should "FROM PKIXCurves" be "FROM PKIXCurves-2008"?
>Appendix A.4, "id-mod-algorithInformation" 

I'll fix these.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mADDB6UI091011 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Nov 2008 06:11:06 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mADDB6T2091010; Thu, 13 Nov 2008 06:11:06 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mADDAtw4090969 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Thu, 13 Nov 2008 06:11:06 -0700 (MST) (envelope-from [e-mail])
Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id mADDATXH014496 for <[e-mail]>; Thu, 13 Nov 2008 07:10:53 -0600
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 13 Nov 2008 15:10:31 +0200
Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 13 Nov 2008 15:10:31 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: AD comments for draft-ietf-pkix-ecc-subpubkeyinfo-09
Date: Thu, 13 Nov 2008 15:10:32 +0200
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: AD comments for draft-ietf-pkix-ecc-subpubkeyinfo-09
Thread-Index: AclFkTVKBddzMZh/RymSj/vhXGDRog==
From: <[e-mail]>
To: <[e-mail]>
X-OriginalArrivalTime: 13 Nov 2008 13:10:31.0510 (UTC) FILETIME=[34CB8F60:01C94591]
X-Nokia-AV: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I'm now doing the AD review for draft-ietf-pkix-ecc-subpubkeyinfo-09.
My situation is slightly unusual, since I've never read the draft
before -- usually the AD has followed the draft for some time, and is
at least somewhat familiar with the WG discussions that lead to making
the decisions that were made. So, I might be asking questions that
were discussed already earlier...

In general, the document looks quite good. I've identified couple=20
of topics that I'd like to discuss with the WG (plus some minor
clarifications/comments):


Topic #1: implicitCurve

I'd like to better understand the motivation behind this option.
It certainly saves ~10 bytes (one OID) in the certificate, but doesn't
it also mean the end-entity certificate does not any longer contain=20
the whole public key? (since the ECPoint value alone is not useful=20
without knowing the curve)

If that's the case, it would significantly complicate using the
certificate to "carry public keys" in situations where the recipient
does not necessarily do path validation (and may not have the issuer's
public key).

This situation is of course very common in web browsing (browser asks
you whether you want to accept the certificate anyway), but occurs
also in e.g. DTLS-SRTP and RFC 4572 (where the party receiving the
certificate might do real path validation, or might just check that it
matches the fingerprint received in SIP/SDP), and Syslog-over-TLS
(where small implementations might use fingerprints instead of path
validation, even if the certificate isn't self-signed). And I'm pretty
sure more uses like this will be specified in the future.

Would the spec be missing important functionality if it just said
"implicitCurve MUST NOT be used" (like it says for specifiedCurve)?


Topic #2: scope of Appendix A

For a document that specifies how to carry ECC public keys in
SubjectPublicKeyInfo, I was sort of expecting ASN.1 module(s) to do
so.  When I got to Appendix A, I was very surprised to find ASN.1
modules that contain mostly other things (not related to ECC at all,
or not related to SubjectPublicKeyInfo) -- nothing in the main
document (abstract and Sections 1..8) hinted that this would be
coming. Could you briefly explain why ASN.1 about RSA, DSA, MD5,=20
etc. belongs in this document?


Topic #3: "informative" ASN.1

I'm wondering whether calling a section consisting solely of formal
language "informative" makes sense, and if just adding that one word
avoids a normative reference to draft-ietf-pkix-new-asn1 (due to
"IMPORTS" -- a case which is mentioned explicitly in RFC 3967).

It looks like stuff implementors would use, and perhaps more
importantly, something writers of future IETF specifications might
want to use. Can we simultaneously claim it's not really part of the
specification (and thus the reference to new-asn1 is not normative)
and allow future documents to import from it (with a normative
reference)?



The remaining comments are basically questions or suggestions
for minor clarifications:

- Section 2.2: ANSI X9.62 specifies a third point form (that isn't=20
in [SEC1]); should this text say "the hybrid form MUST NOT be used"?
Or is the intent something else?

- I'm trying to understand how this ASN.1 fragment (and several
other similar cases) can actually compile:

   sa-rsaWithMD2 SIGNATURE-ALGORITHM ::=3D {=20
     IDENTIFIER md2WithRSAEncryption=20
     PARAMS TYPE NULL ARE present=20
     HASHES { mda-md2 }=20
     PUBLIC KEYS { pk-rsa }=20
   }=20

I'm puzzled because the string "present" is not one of the values
enumerated in ParamOptions -- but perhaps it's an ASN.1 keyword or
something?  (I have to admit that while I could usually read the old
1988 ASN.1 syntax, I don't really understand how this CLASS stuff
works...)

- A question: for some AlgorithmIdentifiers it's occasionally been
unclear whether the parameters must be NULL, must be omitted, or if
either is allowed. This document looks quite clear about this topic --
but is it 100% consistent with e.g. RFC 3279, PKCS#1 and other
relevant documents? If it's not, it would be important to explicitly
point out the differences.

- Section 2.1.2 says "Algorithms used with elliptic curve cryptography
fall in two different categories: signature and key agreement
algorithms." Do you consider encryption schemes such as ECIES
(specified in IEEE 1363) to be "key agreement"? (it certainly has
similarities to ECDH). This question is also relevant for Section 3,
where keyEncipherment bit is never mentioned.  Or perhaps the text's
intent is that other uses of elliptic curves than ECDSA/ECDH/ECMQV
are beyond the scope?

- The ASN.1 modules in Appendix A have a number of "TBA" values --=20
it would be a good idea to have an explicit note (in the document)=20
saying who will fill them and at what point. Also, it's slightly=20
difficult to tell which TBAs refer to the same value, and which=20
to different values -- using something like "TBA1", "TBA2", etc.,=20
might help.

- Typos:
Section 2.1.1 "ASNI"=20
Appendix A.3, should "FROM PKIXCurves" be "FROM PKIXCurves-2008"?
Appendix A.4, "id-mod-algorithInformation"=20


Best regards,
Pasi



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAD1NN9e051326 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Nov 2008 18:23:23 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAD1NN0M051325; Wed, 12 Nov 2008 18:23:23 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.146]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAD1NA2H051306 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Wed, 12 Nov 2008 18:23:21 -0700 (MST) (envelope-from [e-mail])
Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e6.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id mAD1Pmoq020752 for <[e-mail]>; Wed, 12 Nov 2008 20:25:48 -0500
Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id mAD1MnWs175206 for <[e-mail]>; Wed, 12 Nov 2008 20:22:49 -0500
Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id mAD1MmTK031697 for <[e-mail]>; Wed, 12 Nov 2008 20:22:49 -0500
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.56.228.115]) by d01av04.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id mAD1MmkJ031672; Wed, 12 Nov 2008 20:22:48 -0500
In-Reply-To: <[e-mail]>
To: "Timothy J. Miller" <[e-mail]>
Cc: [e-mail], [e-mail], Peter Gutmann <[e-mail]>
MIME-Version: 1.0
Subject: Re: encoding an X.509 certificate
X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006
From: Tom Gindin <[e-mail]>
Message-ID: <[e-mail]>
Date: Wed, 12 Nov 2008 20:22:48 -0500
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 8.0.1|February 07, 2008) at 11/12/2008 20:22:48, Serialize complete at 11/12/2008 20:22:48
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>

        "Conservative in what you produce" - CA code should generate DER. 
Not all such code does so, but it should.
        "Liberal in what you accept" - RP code should verify signatures on 
the supplied binary TBSCertificate, rather than re-encoding.  For parsing 
code to accept BER which isn't valid DER is almost harmless.    There may 
well have been a good reason for believing that DER was more secure than 
BER against various digest collision or pre-image attacks when X.509v1 was 
in use and all certificate content had syntax verifiable by every RP (at 
least in theory).  With non-critical extensions, that is no longer the 
case.

                Tom Gindin



"Timothy J. Miller" <[e-mail]> 
Sent by: [e-mail]
11/12/2008 10:31 AM

To
Peter Gutmann <[e-mail]>
cc
[e-mail], [e-mail]
Subject
Re: encoding an X.509 certificate






Peter Gutmann wrote:

> If you follow the spec in this regard you get 100% unreliability, not
> reliability - your PKI application when shipped will break repeatedly 
whenever
> it encounters a non-DER certificate, while everything else will work 
just
> fine.  So "X.509 dogma" is for X.509 dogmatists and pretty much no-one 
else.

Postel's Law, anyone?  :)

-- Tim




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mACGArlq013736 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Nov 2008 09:10:53 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mACGArSN013735; Wed, 12 Nov 2008 09:10:53 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mACGAp6u013720 for <[e-mail]>; Wed, 12 Nov 2008 09:10:52 -0700 (MST) (envelope-from [e-mail])
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id mACGApvA014800 for <[e-mail]>; Wed, 12 Nov 2008 11:10:51 -0500
Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id mACGAowo014768; Wed, 12 Nov 2008 11:10:50 -0500
Received: from [129.83.200.7] (129.83.200.7) by imchub2.MITRE.ORG (129.83.29.74) with Microsoft SMTP Server (TLS) id 8.1.311.2; Wed, 12 Nov 2008 11:10:50 -0500
Message-ID: <[e-mail]>
Date: Wed, 12 Nov 2008 10:10:47 -0600
From: "Timothy J. Miller" <[e-mail]>
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: Paul Hoffman <[e-mail]>
CC: Anders Rundgren <[e-mail]>, pkix <[e-mail]>
Subject: Re: encoding an X.509 certificate
References: <[e-mail]> <[e-mail]> <3AFA0E5E3C2F40D8BDB10F80185A69B3@AndersPC> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <9652D780F49E47888D7348621BE9EDAF@AndersPC> <p06240814c53bc48a7147@[10.20.30.152]>
In-Reply-To: <p06240814c53bc48a7147@[10.20.30.152]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020704000502090603090300"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

Paul Hoffman wrote:

> Of course. Of what possible use would it be? People paying attention to Peter's posting on this thread already know that different CAs emit certs that wouldn't pass the test. Having a public box say so isn't going to change anything.

By itself?  Not much.

If it provided a service mark for use by a vendor?  Quite a bit.  Most 
of the major standards do this and it does work (mostly).

-- Tim

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKvjCC
A2cwggJPoAMCAQICAh8FMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEe
MBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3Jh
dGlvbiBQcmltYXJ5IENBLTEwHhcNMDgwODIxMTUzMTI5WhcNMTAwMjEyMTUzMTI5WjBaMRIw
EAYDVQQKEwltaXRyZS5vcmcxDzANBgNVBAsTBnBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3Rt
aWxsZXIxGjAYBgNVBAMTEU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQCTxM+z5fDKvmBInGatv0DkVwuOxd69S2M2jho8QkOltYJK/4JUm9uK0UtQZkyI
bEjmCpmXLw17iMCgA0SjwuUfJxdF8ntTys8keyMjRdlKSwFnkgZl9tL7o060LBtZQYzI5ajr
W9k3N768G/k1bZS5UYiMGHU5+Ygl4IwVhmQv3wIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF
4DAdBgNVHQ4EFgQUSXARqmj5Bl2Lz7RLoUIkuOHl0MkwHwYDVR0jBBgwFoAUh7QPSI1iM0LB
LVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL3d3dy5taXRyZS5vcmcvdGVj
aC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1UdEQQVMBOBEXRtaWxsZXJAbWl0cmUu
b3JnMA0GCSqGSIb3DQEBBQUAA4IBAQAbA1PH/hed/rryO1f0yfTRJnD/vL1rFTduUut/irL7
FSXHGybuPHxydfyGPvJ4qj+T8hs1W0jTa2zQnaPR52tms3hefl76CNVP9vJoVmaM9svFX4DX
6eJh/4SAI81tAuBIK8gxsWd1Va/Bnnh1/wsZLc8w2jkojVqkT2AHPaHS3DBKX7QAWovXVSxY
QlqMIH4zvSNSVfpvpIf0MWJWRBPvgerVSbJsA4dz6ziKvXDWySTV9zwSuNjikNqL//nIKwjb
r3ZOfSUOxSuhW58an2Ha4TdORvG4dGJEsMzxbpTB+wt/s6tK6roONV4uiDtODBNVAG+XGofe
McsS0b7iXdxDMIIDZzCCAk+gAwIBAgICHwUwDQYJKoZIhvcNAQEFBQAwXTESMBAGA1UEChMJ
bWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAlBgNVBAMTHk1J
VFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMTAeFw0wODA4MjExNTMxMjlaFw0xMDAyMTIx
NTMxMjlaMFoxEjAQBgNVBAoTCW1pdHJlLm9yZzEPMA0GA1UECxMGcGVvcGxlMRcwFQYKCZIm
iZPyLGQBARMHdG1pbGxlcjEaMBgGA1UEAxMRTWlsbGVyIFRpbW90aHkgSi4wgZ8wDQYJKoZI
hvcNAQEBBQADgY0AMIGJAoGBAJPEz7Pl8Mq+YEicZq2/QORXC47F3r1LYzaOGjxCQ6W1gkr/
glSb24rRS1BmTIhsSOYKmZcvDXuIwKADRKPC5R8nF0Xye1PKzyR7IyNF2UpLAWeSBmX20vuj
TrQsG1lBjMjlqOtb2Tc3vrwb+TVtlLlRiIwYdTn5iCXgjBWGZC/fAgMBAAGjgbcwgbQwDgYD
VR0PAQH/BAQDAgXgMB0GA1UdDgQWBBRJcBGqaPkGXYvPtEuhQiS44eXQyTAfBgNVHSMEGDAW
gBSHtA9IjWIzQsEtURpIHsKeuwqxrTBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vd3d3Lm1p
dHJlLm9yZy90ZWNoL21paS9wa2kvY2ExX21pdHJlX29yZy5jcmwwHAYDVR0RBBUwE4ERdG1p
bGxlckBtaXRyZS5vcmcwDQYJKoZIhvcNAQEFBQADggEBABsDU8f+F53+uvI7V/TJ9NEmcP+8
vWsVN25S63+KsvsVJccbJu48fHJ1/IY+8niqP5PyGzVbSNNrbNCdo9Hna2azeF5+XvoI1U/2
8mhWZoz2y8VfgNfp4mH/hIAjzW0C4EgryDGxZ3VVr8GeeHX/CxktzzDaOSiNWqRPYAc9odLc
MEpftABai9dVLFhCWowgfjO9I1JV+m+kh/QxYlZEE++B6tVJsmwDh3PrOIq9cNbJJNX3PBK4
2OKQ2ov/+cgrCNuvdk59JQ7FK6FbnxqfYdrhN05G8bh0YkSwzPFulMH7C3+zq0rqug41Xi6I
O04ME1UAb5cah94xyxLRvuJd3EMwggPkMIICzKADAgECAgEFMA0GCSqGSIb3DQEBBQUAMFox
EjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MSQw
IgYDVQQDExtNSVRSRSBDb3Jwb3JhdGlvbiBSb290IENBLTEwHhcNMDYwNjAzMTcxMzIyWhcN
MTIwNjAzMTcxMzIyWjBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmlj
YXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0x
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyPB7Vl0QgqgQt0u8Q2duRs7eZUPn
hlflKPFPMXGG+iqGpImYs6nfbFPsn0q8FqklFsm/UEV2JJQ3c7Srwfrqe9CrCbVFh761OxZI
7fnUWiUasNP2ING19aAfrQ8IoJsAEtGzHeIacS+M5CN4C0yfUC6CpBZTc9ZldjLUatvJr407
K1i+7WnrRsMVKhICfgmiO/XiVR9YeXyzeRqFrLy6YtJCJuJd0QRfwKtKRpek5oU67Izr7ClH
DtPJs7UOTjMYBS2fTzztC+wwOTp6+A3ZbEymuQcAZRwmGkjVBe2R8MiX26R02Iigz+903ZAL
/6bpvx0DnkrlR2UFr1KBGfBqmQIDAQABo4GxMIGuMBIGA1UdEwEB/wQIMAYBAf8CAQIwDgYD
VR0PAQH/BAQDAgGGMB0GA1UdDgQWBBSHtA9IjWIzQsEtURpIHsKeuwqxrTAfBgNVHSMEGDAW
gBTHcFEA2E3+5AHUaJbFPZ+al/50LzBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vd3d3Lm1p
dHJlLm9yZy90ZWNoL21paS9wa2kvcm9vdGNhMV9taXRyZV9vcmcuY3JsMA0GCSqGSIb3DQEB
BQUAA4IBAQBNbm7rrins3SICPbteX9qSN1+RJClqix/pw3IAe7u60LK0V9jVZ9E2a+c0MZiS
ojdcwU5rXxI2OI2wwIf6wVBo76jIOc+IiQRlC+V8YatGmoibqP/8WDPzlud/WQAzkjrU2nuh
8KdyJG+n1kH/6772Lbra2CIk8mu8FypeaB5P2uIJzdE+PGo82ZiyU680ukiJ9yF6UmEXuciB
77tGQBRxMl6ePzIrArQnf48SmBhFD5XYLraueOiG7E+AzD99ig1M6WHcxWXtp3DIrVqE/DZr
146NJaCWqg9NoE14cmpEllnpWLtLnn5UBYJ+QCozmbe1SJXOOynZ0VxMnGdh7NqgMYICqDCC
AqQCAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1
dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTAJ
BgUrDgMCGgUAoIIBmzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0wODExMTIxNjEwNDdaMCMGCSqGSIb3DQEJBDEWBBQasa/8BPpH9xCNvHzbLYOlkF8zZDBS
BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D
AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNV
BAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQD
Ex5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAh8FMHQGCyqGSIb3DQEJEAILMWWg
YzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0
eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTANBgkqhkiG
9w0BAQEFAASBgEYtEteqOgEZmSAtx58hc+wA+f63sta4c8y7lYfbzAuzc6GlDfT5bOUdFV6r
avrAY9QMlahWoorfXvsGdJlj5Wy/la3TjD6556ys9lyDKYNfernhtcerKeLK4Nb66yzpDYM4
HKMMUzVe9PvzbNqD6aU0jZuijnU+bRQ0NYXV2v2UAAAAAAAA
--------------ms020704000502090603090300--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mACFVgiK011308 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Nov 2008 08:31:42 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mACFVg9u011307; Wed, 12 Nov 2008 08:31:42 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mACFVV6c011289 for <[e-mail]>; Wed, 12 Nov 2008 08:31:41 -0700 (MST) (envelope-from [e-mail])
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id mACFVTVJ026572 for <[e-mail]>; Wed, 12 Nov 2008 10:31:30 -0500
Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id mACFVTko026557; Wed, 12 Nov 2008 10:31:29 -0500
Received: from [129.83.200.7] (129.83.200.7) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server (TLS) id 8.1.311.2; Wed, 12 Nov 2008 10:31:29 -0500
Message-ID: <[e-mail]>
Date: Wed, 12 Nov 2008 09:31:26 -0600
From: "Timothy J. Miller" <[e-mail]>
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: Peter Gutmann <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: encoding an X.509 certificate
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090108050000070706030009"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

Peter Gutmann wrote:

> If you follow the spec in this regard you get 100% unreliability, not
> reliability - your PKI application when shipped will break repeatedly whenever
> it encounters a non-DER certificate, while everything else will work just
> fine.  So "X.509 dogma" is for X.509 dogmatists and pretty much no-one else.

Postel's Law, anyone?  :)

-- Tim

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKvjCC
A2cwggJPoAMCAQICAh8FMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEe
MBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3Jh
dGlvbiBQcmltYXJ5IENBLTEwHhcNMDgwODIxMTUzMTI5WhcNMTAwMjEyMTUzMTI5WjBaMRIw
EAYDVQQKEwltaXRyZS5vcmcxDzANBgNVBAsTBnBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3Rt
aWxsZXIxGjAYBgNVBAMTEU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQCTxM+z5fDKvmBInGatv0DkVwuOxd69S2M2jho8QkOltYJK/4JUm9uK0UtQZkyI
bEjmCpmXLw17iMCgA0SjwuUfJxdF8ntTys8keyMjRdlKSwFnkgZl9tL7o060LBtZQYzI5ajr
W9k3N768G/k1bZS5UYiMGHU5+Ygl4IwVhmQv3wIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF
4DAdBgNVHQ4EFgQUSXARqmj5Bl2Lz7RLoUIkuOHl0MkwHwYDVR0jBBgwFoAUh7QPSI1iM0LB
LVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL3d3dy5taXRyZS5vcmcvdGVj
aC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1UdEQQVMBOBEXRtaWxsZXJAbWl0cmUu
b3JnMA0GCSqGSIb3DQEBBQUAA4IBAQAbA1PH/hed/rryO1f0yfTRJnD/vL1rFTduUut/irL7
FSXHGybuPHxydfyGPvJ4qj+T8hs1W0jTa2zQnaPR52tms3hefl76CNVP9vJoVmaM9svFX4DX
6eJh/4SAI81tAuBIK8gxsWd1Va/Bnnh1/wsZLc8w2jkojVqkT2AHPaHS3DBKX7QAWovXVSxY
QlqMIH4zvSNSVfpvpIf0MWJWRBPvgerVSbJsA4dz6ziKvXDWySTV9zwSuNjikNqL//nIKwjb
r3ZOfSUOxSuhW58an2Ha4TdORvG4dGJEsMzxbpTB+wt/s6tK6roONV4uiDtODBNVAG+XGofe
McsS0b7iXdxDMIIDZzCCAk+gAwIBAgICHwUwDQYJKoZIhvcNAQEFBQAwXTESMBAGA1UEChMJ
bWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAlBgNVBAMTHk1J
VFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMTAeFw0wODA4MjExNTMxMjlaFw0xMDAyMTIx
NTMxMjlaMFoxEjAQBgNVBAoTCW1pdHJlLm9yZzEPMA0GA1UECxMGcGVvcGxlMRcwFQYKCZIm
iZPyLGQBARMHdG1pbGxlcjEaMBgGA1UEAxMRTWlsbGVyIFRpbW90aHkgSi4wgZ8wDQYJKoZI
hvcNAQEBBQADgY0AMIGJAoGBAJPEz7Pl8Mq+YEicZq2/QORXC47F3r1LYzaOGjxCQ6W1gkr/
glSb24rRS1BmTIhsSOYKmZcvDXuIwKADRKPC5R8nF0Xye1PKzyR7IyNF2UpLAWeSBmX20vuj
TrQsG1lBjMjlqOtb2Tc3vrwb+TVtlLlRiIwYdTn5iCXgjBWGZC/fAgMBAAGjgbcwgbQwDgYD
VR0PAQH/BAQDAgXgMB0GA1UdDgQWBBRJcBGqaPkGXYvPtEuhQiS44eXQyTAfBgNVHSMEGDAW
gBSHtA9IjWIzQsEtURpIHsKeuwqxrTBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vd3d3Lm1p
dHJlLm9yZy90ZWNoL21paS9wa2kvY2ExX21pdHJlX29yZy5jcmwwHAYDVR0RBBUwE4ERdG1p
bGxlckBtaXRyZS5vcmcwDQYJKoZIhvcNAQEFBQADggEBABsDU8f+F53+uvI7V/TJ9NEmcP+8
vWsVN25S63+KsvsVJccbJu48fHJ1/IY+8niqP5PyGzVbSNNrbNCdo9Hna2azeF5+XvoI1U/2
8mhWZoz2y8VfgNfp4mH/hIAjzW0C4EgryDGxZ3VVr8GeeHX/CxktzzDaOSiNWqRPYAc9odLc
MEpftABai9dVLFhCWowgfjO9I1JV+m+kh/QxYlZEE++B6tVJsmwDh3PrOIq9cNbJJNX3PBK4
2OKQ2ov/+cgrCNuvdk59JQ7FK6FbnxqfYdrhN05G8bh0YkSwzPFulMH7C3+zq0rqug41Xi6I
O04ME1UAb5cah94xyxLRvuJd3EMwggPkMIICzKADAgECAgEFMA0GCSqGSIb3DQEBBQUAMFox
EjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MSQw
IgYDVQQDExtNSVRSRSBDb3Jwb3JhdGlvbiBSb290IENBLTEwHhcNMDYwNjAzMTcxMzIyWhcN
MTIwNjAzMTcxMzIyWjBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmlj
YXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0x
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyPB7Vl0QgqgQt0u8Q2duRs7eZUPn
hlflKPFPMXGG+iqGpImYs6nfbFPsn0q8FqklFsm/UEV2JJQ3c7Srwfrqe9CrCbVFh761OxZI
7fnUWiUasNP2ING19aAfrQ8IoJsAEtGzHeIacS+M5CN4C0yfUC6CpBZTc9ZldjLUatvJr407
K1i+7WnrRsMVKhICfgmiO/XiVR9YeXyzeRqFrLy6YtJCJuJd0QRfwKtKRpek5oU67Izr7ClH
DtPJs7UOTjMYBS2fTzztC+wwOTp6+A3ZbEymuQcAZRwmGkjVBe2R8MiX26R02Iigz+903ZAL
/6bpvx0DnkrlR2UFr1KBGfBqmQIDAQABo4GxMIGuMBIGA1UdEwEB/wQIMAYBAf8CAQIwDgYD
VR0PAQH/BAQDAgGGMB0GA1UdDgQWBBSHtA9IjWIzQsEtURpIHsKeuwqxrTAfBgNVHSMEGDAW
gBTHcFEA2E3+5AHUaJbFPZ+al/50LzBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vd3d3Lm1p
dHJlLm9yZy90ZWNoL21paS9wa2kvcm9vdGNhMV9taXRyZV9vcmcuY3JsMA0GCSqGSIb3DQEB
BQUAA4IBAQBNbm7rrins3SICPbteX9qSN1+RJClqix/pw3IAe7u60LK0V9jVZ9E2a+c0MZiS
ojdcwU5rXxI2OI2wwIf6wVBo76jIOc+IiQRlC+V8YatGmoibqP/8WDPzlud/WQAzkjrU2nuh
8KdyJG+n1kH/6772Lbra2CIk8mu8FypeaB5P2uIJzdE+PGo82ZiyU680ukiJ9yF6UmEXuciB
77tGQBRxMl6ePzIrArQnf48SmBhFD5XYLraueOiG7E+AzD99ig1M6WHcxWXtp3DIrVqE/DZr
146NJaCWqg9NoE14cmpEllnpWLtLnn5UBYJ+QCozmbe1SJXOOynZ0VxMnGdh7NqgMYICqDCC
AqQCAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1
dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTAJ
BgUrDgMCGgUAoIIBmzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0wODExMTIxNTMxMjZaMCMGCSqGSIb3DQEJBDEWBBTm2gJoTbGmG+ljTD573iF/E5XxCTBS
BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D
AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNV
BAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQD
Ex5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAh8FMHQGCyqGSIb3DQEJEAILMWWg
YzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0
eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTANBgkqhkiG
9w0BAQEFAASBgAKzC3tqrE382ZzzFcFWBUXz95+I6ob4B+8Fw1OnKUgxdfye1PpBPUkIXaVv
9QQEY5leOBGgwNnewUxo0PF0C7BE7DaXaE1tVDgO++5EyDD1GcgeHpdoaw4riKwyyRb3ZRBT
8ljeCcMNoyiebzIzmv7r3RoWatKKqrhMg0k1j2QDAAAAAAAA
--------------ms090108050000070706030009--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mACEKtnW007880 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Nov 2008 07:20:55 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mACEKtnA007879; Wed, 12 Nov 2008 07:20:55 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-dub.microsoft.com (smtp-dub.microsoft.com [213.199.138.181]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mACEKgMw007870 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Wed, 12 Nov 2008 07:20:54 -0700 (MST) (envelope-from [e-mail])
Received: from dub-exhub-c302.europe.corp.microsoft.com (65.53.213.92) by DUB-EXGWY-E802.partners.extranet.microsoft.com (10.251.129.2) with Microsoft SMTP Server (TLS) id 8.1.291.1; Wed, 12 Nov 2008 14:20:42 +0000
Received: from EA-EXMSG-C332.europe.corp.microsoft.com ([169.254.1.102]) by DUB-EXHUB-C302.europe.corp.microsoft.com ([65.53.213.92]) with mapi; Wed, 12 Nov 2008 14:20:42 +0000
From: Stefan Santesson <[e-mail]>
To: pkix <[e-mail]>
Date: Wed, 12 Nov 2008 14:20:41 +0000
Subject: Agenda uploaded
Thread-Topic: Agenda uploaded
Thread-Index: AclE0deNVum68IrWR5GwpKlsTTi/Dw==
Message-ID: <[e-mail]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_9F11911AED01D24BAA1C2355723C3D321AB0B0B015EAEXMSGC332eu_"
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>

--_000_9F11911AED01D24BAA1C2355723C3D321AB0B0B015EAEXMSGC332eu_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

The preliminary agenda for the PKIX meeting next week is uploaded and can b=
e viewed at:
http://www.ietf.org/proceedings/08nov/agenda/pkix.txt


Stefan Santesson
Senior Program Manager
Windows Security, Standards


--_000_9F11911AED01D24BAA1C2355723C3D321AB0B0B015EAEXMSGC332eu_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:p=3D"urn:schemas-m=
icrosoft-com:office:powerpoint" xmlns:a=3D"urn:schemas-microsoft-com:office=
:access" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s=3D"=
uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs=3D"urn:schemas-microsof=
t-com:rowset" xmlns:z=3D"#RowsetSchema" xmlns:b=3D"urn:schemas-microsoft-co=
m:office:publisher" xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadshee=
t" xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns=
:odc=3D"urn:schemas-microsoft-com:office:odc" xmlns:oa=3D"urn:schemas-micro=
soft-com:office:activation" xmlns:html=3D"http://www.w3.org/TR/REC-html40" =
xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:D=3D"DAV:" xmln=
s:x2=3D"http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ois=3D"ht=
tp://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir=3D"http://schema=
s.microsoft.com/sharepoint/soap/directory/" xmlns:ds=3D"http://www.w3.org/2=
000/09/xmldsig#" xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint/dsp" =
xmlns:udc=3D"http://schemas.microsoft.com/data/udc" xmlns:xsd=3D"http://www=
.w3.org/2001/XMLSchema" xmlns:sub=3D"http://schemas.microsoft.com/sharepoin=
t/soap/2002/1/alerts/" xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#" xmlns=
:sp=3D"http://schemas.microsoft.com/sharepoint/" xmlns:sps=3D"http://schema=
s.microsoft.com/sharepoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001/XMLSc=
hema-instance" xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile=
" xmlns:wf=3D"http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns=
:mver=3D"http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns=
:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns:mrels=3D"http=
://schemas.openxmlformats.org/package/2006/relationships" xmlns:ex12t=3D"ht=
tp://schemas.microsoft.com/exchange/services/2006/types" xmlns:ex12m=3D"htt=
p://schemas.microsoft.com/exchange/services/2006/messages" xmlns:Z=3D"urn:s=
chemas-microsoft-com:" xmlns:st=3D"&#1;" 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=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:"\@SimSun";
	panose-1:2 1 6 0 3 1 1 1 1 1;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DSV link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><span lang=3DEN-US>The preliminary agenda for the PKIX=
 meeting
next week is uploaded and can be viewed at:<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><a
href=3D"http://www.ietf.org/proceedings/08nov/agenda/pkix.txt">http://www.i=
etf.org/proceedings/08nov/agenda/pkix.txt</a><o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><b><span lang=3DEN-GB style=3D'font-size:10.0pt;font-f=
amily:
"Arial","sans-serif";color:maroon'>Stefan Santesson</span></b><span lang=3D=
EN-GB
style=3D'font-size:12.0pt;font-family:"Times New Roman","serif";color:#1F49=
7D'><o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-GB style=3D'font-size:10.0pt;font-fami=
ly:"Arial","sans-serif";
color:#400040'>Senior Program Manager</span><span lang=3DEN-GB style=3D'fon=
t-size:
12.0pt;font-family:"Times New Roman","serif";color:navy'><o:p></o:p></span>=
</p>

<p class=3DMsoNormal><b><span lang=3DEN-GB style=3D'font-size:10.0pt;font-f=
amily:
"Arial","sans-serif";color:#400040'>Windows Security, Standards</span></b><=
span
lang=3DEN-US style=3D'color:#1F497D'><o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

</div>

</body>

</html>

--_000_9F11911AED01D24BAA1C2355723C3D321AB0B0B015EAEXMSGC332eu_--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAAFDoRi060381 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Nov 2008 08:13:50 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAAFDoL3060380; Mon, 10 Nov 2008 08:13:50 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.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 balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAAFDnQO060372 for <[e-mail]>; Mon, 10 Nov 2008 08:13:49 -0700 (MST) (envelope-from [e-mail])
Received: from Augustine.missi.ncsc.mil (augustine.missi.ncsc.mil [144.51.60.33]) by stingray.missi.ncsc.mil with ESMTP id mAAFDmrV027544 for <[e-mail]>; Mon, 10 Nov 2008 10:13:48 -0500 (EST)
Received: from DABECK.missi.ncsc.mil ([144.51.60.15]) by Augustine.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 Nov 2008 10:11:33 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: encoding an X.509 certificate
Date: Mon, 10 Nov 2008 10:13:48 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: encoding an X.509 certificate
Thread-Index: AclB9n2/SCUGKOCZSomWsuULWb+M/gBRFJpAAAJX/nA=
References: <[e-mail]> <[e-mail]> <3AFA0E5E3C2F40D8BDB10F80185A69B3@AndersPC> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <9652D780F49E47888D7348621BE9EDAF@AndersPC> <p06240814c53bc48a7147@[10.20.30.152]> <[e-mail]>
From: "Kemp, David P." <[e-mail]>
To: "pkix" <[e-mail]>
X-OriginalArrivalTime: 10 Nov 2008 15:11:33.0140 (UTC) FILETIME=[9DD31D40:01C94346]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Sorry, I hit "send" before getting to the punchline.

I watched a "60 Minutes" segment last night on e-cycling, where a
company that publicly claims to recycle CRTs in the US using state of
the art methods actually ships them to China to be recycled using less
sophisticated and more toxic methods.  This is against both US and
Chinese law, but many companies do it anyway.  So why would CBS bother
to spend valuable airtime railing against common practice?  Because they
hope publicity will change behavior.

One could hope that an online certificate validation tool could also
change CA behavior by making errors more publicized than just a list
maintained by a crackpot activist :-).   Maybe extra publicity wouldn't
change anything, maybe it would.

The other punchline is that applications should not be penalized for
validating correct certificates - it may address a niche (or even
non-existent) market to be able to validate a DER signature of a
certificate that was transmitted using XER, but being able to do is
undeniably a feature, not a bug.

Dave


-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Kemp, David P.
Sent: Monday, November 10, 2008 9:02 AM
To: pkix
Subject: RE: encoding an X.509 certificate


No disagreement there - any application that doesn't validate
incorrectly encoded certificates will fail in the marketplace just as
any web browser that doesn't accept non-validated HTML would fail.  That
doesn't:
 * make the validator application useless, or
 * imply that CAs / HTML authors / C coders who do validate their work
products are wasting time by ensuring that their output is correct, or
 * say that an unambiguous standard for what is correct/incorrect output
is "dogma".

CAs that sign non-DER encodings are wrong, whether or not they care what
others think.



-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Paul Hoffman
Sent: Saturday, November 08, 2008 5:37 PM
To: Anders Rundgren
Cc: pkix
Subject: Re: encoding an X.509 certificate


At 10:17 PM +0100 11/8/08, Anders Rundgren wrote:
>Couldn't somebody setup something like W3C's HTML validator but for
X509 certificates?

Of course. Of what possible use would it be? People paying attention to
Peter's posting on this thread already know that different CAs emit
certs that wouldn't pass the test. Having a public box say so isn't
going to change anything.

--Paul Hoffman, Director
--VPN Consortium



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAAE2W4W049856 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Nov 2008 07:02:33 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAAE2WUH049855; Mon, 10 Nov 2008 07:02:32 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.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 balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAAE2LLp049785 for <[e-mail]>; Mon, 10 Nov 2008 07:02:32 -0700 (MST) (envelope-from [e-mail])
Received: from Augustine.missi.ncsc.mil (augustine.missi.ncsc.mil [144.51.60.33]) by stingray.missi.ncsc.mil with ESMTP id mAAE2I5g023002 for <[e-mail]>; Mon, 10 Nov 2008 09:02:20 -0500 (EST)
Received: from DABECK.missi.ncsc.mil ([144.51.60.15]) by Augustine.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 Nov 2008 09:00:03 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: encoding an X.509 certificate
Date: Mon, 10 Nov 2008 09:02:18 -0500
Message-ID: <[e-mail]>
In-Reply-To: <p06240814c53bc48a7147@[10.20.30.152]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: encoding an X.509 certificate
Thread-Index: AclB9n2/SCUGKOCZSomWsuULWb+M/gBRFJpA
References: <[e-mail]> <[e-mail]> <3AFA0E5E3C2F40D8BDB10F80185A69B3@AndersPC> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <9652D780F49E47888D7348621BE9EDAF@AndersPC> <p06240814c53bc48a7147@[10.20.30.152]>
From: "Kemp, David P." <[e-mail]>
To: "pkix" <[e-mail]>
X-OriginalArrivalTime: 10 Nov 2008 14:00:03.0203 (UTC) FILETIME=[A0D2AD30:01C9433C]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

No disagreement there - any application that doesn't validate
incorrectly encoded certificates will fail in the marketplace just as
any web browser that doesn't accept non-validated HTML would fail.  That
doesn't:
 * make the validator application useless, or
 * imply that CAs / HTML authors / C coders who do validate their work
products are wasting time by ensuring that their output is correct, or
 * say that an unambiguous standard for what is correct/incorrect output
is "dogma".

CAs that sign non-DER encodings are wrong, whether or not they care what
others think.



-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Paul Hoffman
Sent: Saturday, November 08, 2008 5:37 PM
To: Anders Rundgren
Cc: pkix
Subject: Re: encoding an X.509 certificate


At 10:17 PM +0100 11/8/08, Anders Rundgren wrote:
>Couldn't somebody setup something like W3C's HTML validator but for
X509 certificates?

Of course. Of what possible use would it be? People paying attention to
Peter's posting on this thread already know that different CAs emit
certs that wouldn't pass the test. Having a public box say so isn't
going to change anything.

--Paul Hoffman, Director
--VPN Consortium



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAA9gVRk029492 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Nov 2008 02:42:31 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAA9gVMP029491; Mon, 10 Nov 2008 02:42:31 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pne-smtpout2-sn2.hy.skanova.net (pne-smtpout2-sn2.hy.skanova.net [81.228.8.164]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAA9gJ6q029460 for <[e-mail]>; Mon, 10 Nov 2008 02:42:31 -0700 (MST) (envelope-from [e-mail])
Received: from AndersPC (81.232.45.215) by pne-smtpout2-sn2.hy.skanova.net (7.3.129) id 4873CA9501EA3E03; Mon, 10 Nov 2008 10:42:15 +0100
Message-ID: <49D7757165654EF99178C42CD8698524@AndersPC>
From: "Anders Rundgren" <[e-mail]>
To: "Russ Housley" <[e-mail]>, "Paul Hoffman" <[e-mail]>
Cc: "pkix" <[e-mail]>
References: <[e-mail]> <[e-mail]> <3AFA0E5E3C2F40D8BDB10F80185A69B3@AndersPC> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <9652D780F49E47888D7348621BE9EDAF@AndersPC> <[e-mail]> <p06240820c53d14b4be06@[10.20.30.152]>
In-Reply-To: <p06240820c53d14b4be06@[10.20.30.152]>
Subject: Re: encoding an X.509 certificate
Date: Mon, 10 Nov 2008 10:42: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 Windows Mail 6.0.6000.20661
X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16669
Sender: [e-mail]
Precedence: 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 point with public validates is to verify your own interpretation or maybe help you when you got 
an unexplainable error.  Here's one example which I have actually used in spite of its somewhat 
"funny" name:

http://tinyurl.com/578h86

Even if Peter is right, there may be a point being compliant because there are probably some less 
used implementations out there that haven't been exposed to all the bad stuff Peter has acquired 
over the years.

Anders

----- Original Message ----- 
From: "Paul Hoffman" <[e-mail]>
To: "Russ Housley" <[e-mail]>; "Anders Rundgren" <[e-mail]>
Cc: "pkix" <[e-mail]>
Sent: Sunday, November 09, 2008 23:41
Subject: Re: encoding an X.509 certificate


At 4:13 PM -0500 11/9/08, Russ Housley wrote:
>Anders:
>
>>Couldn't somebody setup something like W3C's HTML validator but for X509 certificates?
>
>I do not know what the W3C HTML validator does, but I aware of the NIST PKI testing:
>
>http://csrc.nist.gov/groups/ST/crypto_apps_infra/pki/pkitesting.html

The W3C Validator (<http://validator.w3.org/>) is an online mechanism for people to see whether a
web page is valid HTML or XHTML. Some people like showing that their HTML is valid by checking it
every time it changes and, if shown valid, put up a cute little logo on their web page.

The NIST PKIX test system is an offline system. I think Anders was hoping that, by putting up an
online system, the problems mentioned in this thread might be reduced because CAs issuing
certificates could check if they are valid. However, as Peter points out, there seems to be little
interest on the part of the CA vendors to enforce the rules of X.509 and PKIX.

Creating a local validation tool inside a CA vendor's lab is trivial. The assumption that individual
CA vendors don't know about their lack of conformance to the specs is dubious at best.

--Paul Hoffman, Director
--VPN Consortium



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA9MfJoF023892 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 9 Nov 2008 15:41:19 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA9MfJOS023891; Sun, 9 Nov 2008 15:41:19 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from [10.20.30.152] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA9MfBUf023882 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 9 Nov 2008 15:41:12 -0700 (MST) (envelope-from [e-mail])
Mime-Version: 1.0
Message-Id: <p06240820c53d14b4be06@[10.20.30.152]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <3AFA0E5E3C2F40D8BDB10F80185A69B3@AndersPC> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <9652D780F49E47888D7348621BE9EDAF@AndersPC> <[e-mail]>
Date: Sun, 9 Nov 2008 14:41:10 -0800
To: Russ Housley <[e-mail]>, "Anders Rundgren" <[e-mail]>
From: Paul Hoffman <[e-mail]>
Subject: Re: encoding an X.509 certificate
Cc: "pkix" <[e-mail]>
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>

At 4:13 PM -0500 11/9/08, Russ Housley wrote:
>Anders:
>
>>Couldn't somebody setup something like W3C's HTML validator but for X509 certificates?
>
>I do not know what the W3C HTML validator does, but I aware of the NIST PKI testing:
>
>http://csrc.nist.gov/groups/ST/crypto_apps_infra/pki/pkitesting.html

The W3C Validator (<http://validator.w3.org/>) is an online mechanism for people to see whether a web page is valid HTML or XHTML. Some people like showing that their HTML is valid by checking it every time it changes and, if shown valid, put up a cute little logo on their web page.

The NIST PKIX test system is an offline system. I think Anders was hoping that, by putting up an online system, the problems mentioned in this thread might be reduced because CAs issuing certificates could check if they are valid. However, as Peter points out, there seems to be little interest on the part of the CA vendors to enforce the rules of X.509 and PKIX.

Creating a local validation tool inside a CA vendor's lab is trivial. The assumption that individual CA vendors don't know about their lack of conformance to the specs is dubious at best.

--Paul Hoffman, Director
--VPN Consortium



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA9LDkwQ020534 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 9 Nov 2008 14:13:46 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA9LDkWC020533; Sun, 9 Nov 2008 14:13:46 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [8.8.40.152]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mA9LDZ7i020514 for <[e-mail]>; Sun, 9 Nov 2008 14:13:46 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Received: (qmail 9263 invoked by uid 0); 9 Nov 2008 21:13:28 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (96.255.143.189) by woodstock.binhost.com with SMTP; 9 Nov 2008 21:13:28 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Sun, 09 Nov 2008 16:13:31 -0500
To: "Anders Rundgren" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: encoding an X.509 certificate
Cc: "pkix" <[e-mail]>
In-Reply-To: <9652D780F49E47888D7348621BE9EDAF@AndersPC>
References: <[e-mail]> <[e-mail]> <3AFA0E5E3C2F40D8BDB10F80185A69B3@AndersPC> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <9652D780F49E47888D7348621BE9EDAF@AndersPC>
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>

Anders:

>Couldn't somebody setup something like W3C's HTML validator but for 
>X509 certificates?

I do not know what the W3C HTML validator does, but I aware of the 
NIST PKI testing:

http://csrc.nist.gov/groups/ST/crypto_apps_infra/pki/pkitesting.html

Russ 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA8NJEVq092964 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 8 Nov 2008 16:19:14 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA8NJEMv092963; Sat, 8 Nov 2008 16:19:14 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yx-out-1718.google.com (yx-out-1718.google.com [74.125.44.154]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA8NJ2dx092951 for <[e-mail]>; Sat, 8 Nov 2008 16:19:13 -0700 (MST) (envelope-from [e-mail])
Received: by yx-out-1718.google.com with SMTP id 36so827016yxh.4 for <[e-mail]>; Sat, 08 Nov 2008 15:19:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=LOE9NdUQj8s6sQaoHA3LMGRjrFZuKycZwM6qf/ZbYfI=; b=M7P41OSWny92VFJmBu63nTz1s2/d5prQPH7WpZqQdAhQM3RQeosC2ZbyopodHzwXx5 7E8NB3JypPFM8mF8YdTE07VsHELvlnuZXTAxgFTVLP8M306OVdFWybmlsyU96DP14sET e5GsLI61SKWOHSqYdS+n448kRl9swZ1QF21qg=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=cfMgtOAZ80xqYW4Qgsb7j/oYbvWpQykk3Uoi/ecYs6Ufb542sDfXCd4PaW8koxjFk1 oPYUkTEICutokRvPRiWrsfp0RMho+3jIc6at/masdyoqNpmuF7Zhpry+/Ie5lJg2Btsb 907CB1PbmEp6Bogs6f2fsv4+X2IgEf7yIqBZ4=
Received: by 10.150.137.12 with SMTP id k12mr6523869ybd.210.1226186342101; Sat, 08 Nov 2008 15:19:02 -0800 (PST)
Received: by 10.150.152.5 with HTTP; Sat, 8 Nov 2008 15:19:01 -0800 (PST)
Message-ID: <[e-mail]>
Date: Sat, 8 Nov 2008 18:19:01 -0500
From: "Tom Scavo" <[e-mail]>
To: "Anders Rundgren" <[e-mail]>
Subject: Re: encoding an X.509 certificate
Cc: "Ben Laurie" <[e-mail]>, pkix <[e-mail]>
In-Reply-To: <9652D780F49E47888D7348621BE9EDAF@AndersPC>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <[e-mail]> <[e-mail]> <3AFA0E5E3C2F40D8BDB10F80185A69B3@AndersPC> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <9652D780F49E47888D7348621BE9EDAF@AndersPC>
Sender: [e-mail]
Precedence: 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 Sat, Nov 8, 2008 at 4:17 PM, Anders Rundgren
<[e-mail]> wrote:
>
> I do not fully agree with the following document:
> http://docs.google.com/Doc?id=ddj3qnj2_231hms5vtgq

Can you say why?

> A certificate should [IMO] always be decodable, and verifiable against a trust anchor, otherwise it
> is not much of a certificate.

Decodable is one thing (the only characteristic I'm interested in, in
fact) but "verifiable against a trust anchor" is quite another.  I
like to think that the certificates in this profile are "meaningless":

http://www.ietf.org/internet-drafts/draft-moreau-pkix-aixcm-00.txt

In other words, SAML holder-of-key subject confirmation does not
require an X.509-based PKI.  The goal is to cryptographically
strengthen the SAML flow.  If this can be done without assuming an
X.509-based PKI, so much the better.

Practically speaking, a typical flow is based on TLS client
"authentication."  A client presents a certificate to the identity
provider via TLS and authenticates by unspecified means.  (If the
identity provider trusts the issuer of the certificate, TLS serves
both purposes of course.)  The certificate from the TLS exchange is
the certificate "possessed" by the identity provider.

If we could limit the choices at the identity provider to one
(<ds:X509Certificate>), this would be a done deal.  Unfortunately,
that's not possible, because if there *is* an X.509-based PKI in
place, there are real use cases for the other XML elements specified
in the XML Signature spec.

Tom



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA8MbIPD091072 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 8 Nov 2008 15:37:18 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA8MbIsu091071; Sat, 8 Nov 2008 15:37:18 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from [10.20.30.152] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA8MbDft091062 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 8 Nov 2008 15:37:15 -0700 (MST) (envelope-from [e-mail])
Mime-Version: 1.0
Message-Id: <p06240814c53bc48a7147@[10.20.30.152]>
In-Reply-To: <9652D780F49E47888D7348621BE9EDAF@AndersPC>
References: <[e-mail]> <[e-mail]> <3AFA0E5E3C2F40D8BDB10F80185A69B3@AndersPC> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <9652D780F49E47888D7348621BE9EDAF@AndersPC>
Date: Sat, 8 Nov 2008 14:37:11 -0800
To: "Anders Rundgren" <[e-mail]>
From: Paul Hoffman <[e-mail]>
Subject: Re: encoding an X.509 certificate
Cc: "pkix" <[e-mail]>
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>

At 10:17 PM +0100 11/8/08, Anders Rundgren wrote:
>Couldn't somebody setup something like W3C's HTML validator but for X509 certificates?

Of course. Of what possible use would it be? People paying attention to Peter's posting on this thread already know that different CAs emit certs that wouldn't pass the test. Having a public box say so isn't going to change anything.

--Paul Hoffman, Director
--VPN Consortium



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA8LHm7H084153 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 8 Nov 2008 14:17:48 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA8LHmYk084152; Sat, 8 Nov 2008 14:17:48 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pne-smtpout1-sn2.hy.skanova.net (pne-smtpout1-sn2.hy.skanova.net [81.228.8.83]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA8LHblX084118 for <[e-mail]>; Sat, 8 Nov 2008 14:17:47 -0700 (MST) (envelope-from [e-mail])
Received: from AndersPC (81.232.45.215) by pne-smtpout1-sn2.hy.skanova.net (7.3.129) id 48A144C50179775A; Sat, 8 Nov 2008 22:17:34 +0100
Message-ID: <9652D780F49E47888D7348621BE9EDAF@AndersPC>
From: "Anders Rundgren" <[e-mail]>
To: "Tom Scavo" <[e-mail]>, "Ben Laurie" <[e-mail]>
Cc: "pkix" <[e-mail]>
References: <[e-mail]> <[e-mail]> <3AFA0E5E3C2F40D8BDB10F80185A69B3@AndersPC> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: Re: encoding an X.509 certificate
Date: Sat, 8 Nov 2008 22:17:38 +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 Windows Mail 6.0.6000.20661
X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16669
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

According to this document DER is a subset of BER:
http://luca.ntop.org/Teaching/Appunti/asn1.html

That probably means that certificate decoders cope with both (or even mixed) formats, but that they 
always keep the original representation in the background if the the binary representation is 
requested.  "Fake serialization".

As Peter Gutmann writes this is sort if a "convention" among implementers which is not well-known 
outside of these circles.   Microsoft states "raw binary representation" in .NET and that seems like 
the only thing that is for sure.  SUN's Java actually claims DER but that is probably incorrect.

I do not fully agree with the following document:
http://docs.google.com/Doc?id=ddj3qnj2_231hms5vtgq
A certificate should [IMO] always be decodable, and verifiable against a trust anchor, otherwise it 
is not much of a certificate.

Couldn't somebody setup something like W3C's HTML validator but for X509 certificates?

Anders

----- Original Message ----- 
From: "Tom Scavo" <[e-mail]>
To: "Ben Laurie" <[e-mail]>
Cc: "Anders Rundgren" <[e-mail]>; "pkix" <[e-mail]>
Sent: Saturday, November 08, 2008 20:49
Subject: Re: encoding an X.509 certificate


Hi Ben,

Thanks for gently pushing back on my remarks.  I was trying to distill
the essence of the profile, but I'm not sure I've adequately done
that.  As I said earlier, I probably I have to provide more detail
before the issues clearly emerge.  Please bear with me as I try to do
that below.

On Fri, Nov 7, 2008 at 3:19 AM, Ben Laurie <[e-mail]> wrote:
> Tom Scavo wrote:
>>
>> The SAML profile that makes use of the XML structure posted earlier
>> does not require that the certificate in question be validated by the
>> receiving party.  The certificate is merely a container for a public
>> key, for which the client proves possession of the corresponding
>> private key, nothing more.

Sorry, the above is an overstatement on my part.  Although it happens
to be true, it doesn't really have anything to do with my original
question regarding certificate encodings.

>> If the receiving party is a SAML identity provider, the presented
>> certificate is bound to a SAML assertion (using the XML structure
>> posted earlier).  If the receiving party is a SAML service provider,
>> the presented certificate is compared to the certificate bound to the
>> SAML assertion.  So the actual encoding applied to the certificate is
>> not important, except of course the identity provider and the service
>> provider need to be on the same page, otherwise certificate comparison
>> at the service provider will fail.
>
> If that's true, then your first paragraph is incorrect - all of the
> certificate matters.

Well, it depends on the content of the assertion.  In the case of
<ds:X509Certificate>, yes, all of the certificate does matter, but
other kinds of X.509 data may be bound to the assertion, namely,
<ds:X509SKI>, <ds:X509SubjectName>, or <ds:X509IssuerSerial>.  As it
turns out, it's these other elements that require additional
processing of the certificate by both parties.

See this short write-up that discusses each element in some detail:

http://docs.google.com/Doc?id=ddj3qnj2_231hms5vtgq

If a <ds:X509Certificate> element is bound to the assertion, it's
all-or-nothing, yes.  On the other hand, if a <ds:X509SubjectName>
element is bound to the assertion, only the subject DN of the
certificate matters.  Indeed, in that case the identity provider and
the service provider may be holding different certificates.  Moreover,
in the case of <ds:X509SubjectName> we assume the service provider
trusts the issuer of the certificate in its possession.  If not, the
subject DN should not be used by the service provider to confirm the
subject.

> However, if all you really care about is the public
> key, why does the receiving party not just check that and ignore the
> certificate?

Again, I misspoke (or spoke out of context) earlier.  Now that I've
had a chance to explain myself, would you care to rephrase your
question?

Cheers,
Tom 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA8Jo1Te073900 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 8 Nov 2008 12:50:01 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA8Jo1Z8073896; Sat, 8 Nov 2008 12:50:01 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-gx0-f15.google.com (mail-gx0-f15.google.com [209.85.217.15]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA8JnmNR073859 for <[e-mail]>; Sat, 8 Nov 2008 12:49:59 -0700 (MST) (envelope-from [e-mail])
Received: by gxk8 with SMTP id 8so1357132gxk.10 for <[e-mail]>; Sat, 08 Nov 2008 11:49:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=k3BPn4L7jicL3iENIBgQTLesX/D4Lkb+nsxU6f1OJmw=; b=fiP+YDjYFZY7MSqQjZEQtHQqVOUJIYyjHIzXN9782aUMH1MLt43sXU8f/XgHHRRLOi bl96P8uM07nnL/9/wkiknJz1v+NLQQT2E376AnHY7RINrfmUIG4nrP44bEvz/UUjBH/9 VOS49w5mFHbUwbYqTQrTSbQkXKJlrblkhmM+w=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=dJblTiwQ25FMTAQIFreYgiXixGZDZZmea/ZnIHrSKPfdDUWeyE2djF+ROgcCmqHj9x VlxB+7tct2vVVjDni4faitKYArdduS0NBsTTKWtGWIZG9mr4Wa8likSm3b6J/q7OISHt DQFq9JIL1S2n24GImbcWRUgjDYAdb7Zb3GVws=
Received: by 10.150.157.17 with SMTP id f17mr6221582ybe.104.1226173787275; Sat, 08 Nov 2008 11:49:47 -0800 (PST)
Received: by 10.150.152.5 with HTTP; Sat, 8 Nov 2008 11:49:47 -0800 (PST)
Message-ID: <[e-mail]>
Date: Sat, 8 Nov 2008 14:49:47 -0500
From: "Tom Scavo" <[e-mail]>
To: "Ben Laurie" <[e-mail]>
Subject: Re: encoding an X.509 certificate
Cc: "Anders Rundgren" <[e-mail]>, pkix <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <[e-mail]> <[e-mail]> <3AFA0E5E3C2F40D8BDB10F80185A69B3@AndersPC> <[e-mail]> <[e-mail]> <[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>

Hi Ben,

Thanks for gently pushing back on my remarks.  I was trying to distill
the essence of the profile, but I'm not sure I've adequately done
that.  As I said earlier, I probably I have to provide more detail
before the issues clearly emerge.  Please bear with me as I try to do
that below.

On Fri, Nov 7, 2008 at 3:19 AM, Ben Laurie <[e-mail]> wrote:
> Tom Scavo wrote:
>>
>> The SAML profile that makes use of the XML structure posted earlier
>> does not require that the certificate in question be validated by the
>> receiving party.  The certificate is merely a container for a public
>> key, for which the client proves possession of the corresponding
>> private key, nothing more.

Sorry, the above is an overstatement on my part.  Although it happens
to be true, it doesn't really have anything to do with my original
question regarding certificate encodings.

>> If the receiving party is a SAML identity provider, the presented
>> certificate is bound to a SAML assertion (using the XML structure
>> posted earlier).  If the receiving party is a SAML service provider,
>> the presented certificate is compared to the certificate bound to the
>> SAML assertion.  So the actual encoding applied to the certificate is
>> not important, except of course the identity provider and the service
>> provider need to be on the same page, otherwise certificate comparison
>> at the service provider will fail.
>
> If that's true, then your first paragraph is incorrect - all of the
> certificate matters.

Well, it depends on the content of the assertion.  In the case of
<ds:X509Certificate>, yes, all of the certificate does matter, but
other kinds of X.509 data may be bound to the assertion, namely,
<ds:X509SKI>, <ds:X509SubjectName>, or <ds:X509IssuerSerial>.  As it
turns out, it's these other elements that require additional
processing of the certificate by both parties.

See this short write-up that discusses each element in some detail:

http://docs.google.com/Doc?id=ddj3qnj2_231hms5vtgq

If a <ds:X509Certificate> element is bound to the assertion, it's
all-or-nothing, yes.  On the other hand, if a <ds:X509SubjectName>
element is bound to the assertion, only the subject DN of the
certificate matters.  Indeed, in that case the identity provider and
the service provider may be holding different certificates.  Moreover,
in the case of <ds:X509SubjectName> we assume the service provider
trusts the issuer of the certificate in its possession.  If not, the
subject DN should not be used by the service provider to confirm the
subject.

> However, if all you really care about is the public
> key, why does the receiving party not just check that and ignore the
> certificate?

Again, I misspoke (or spoke out of context) earlier.  Now that I've
had a chance to explain myself, would you care to rephrase your
question?

Cheers,
Tom



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA8GOvia059208 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 8 Nov 2008 09:24:57 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA8GOvb7059207; Sat, 8 Nov 2008 09:24:57 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mA8GOk5o059192 for <[e-mail]>; Sat, 8 Nov 2008 09:24:56 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 20546 invoked from network); 8 Nov 2008 16:24:55 -0000
Received: from [e-mail] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;08 Nov 2008 16:24:55 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 8 Nov 2008 16:24:55 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: encoding an X.509 certificate
Date: Sat, 8 Nov 2008 11:24:42 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: encoding an X.509 certificate
Thread-Index: AclA8kTOX8HupilKSHe3PLIl9GbeiQAAIAlwAANCxiAALK7oIA==
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Santosh Chokhani" <[e-mail]>
To: "Kemp, David P." <[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>

Dave,

I also have seen Peter's responses.

Either I am misunderstanding you or we have a genuine disagreement.

In terms of interoperability, I did not think that many clients
recognize the various ASN.1 encodings.

Performance may be a minor item depending on at what point in decoding
you get an error and try another one.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Kemp, David P.
Sent: Friday, November 07, 2008 12:46 PM
To: [e-mail]
Subject: RE: encoding an X.509 certificate


The same thing that happens to people who don't lint or bounds-check
their C code - it works most of the time, so it must not matter if the
code is actually correct.  "X.509 dogma" is just for anal people who
want 100% reliability.


-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Santosh Chokhani
Sent: Friday, November 07, 2008 11:55 AM
To: pgut001; [e-mail]; [e-mail]
Subject: RE: encoding an X.509 certificate


Peter,

What does that do to interoperability or performance since you get
certificates from various sources who can encode them whichever way.

-----Original Message-----
From: pgut001 [mailto:[e-mail]]=20
Sent: Friday, November 07, 2008 11:03 AM
To: [e-mail]; [e-mail]; Santosh Chokhani;
[e-mail]
Subject: RE: encoding an X.509 certificate

"Santosh Chokhani" <[e-mail]> writes:

>How do you reconcile what you say with the following in Section 4.1 of
5280:
>
>"The X.509 v3 certificate basic syntax is as follows.  For signature
>calculation, the data that is to be signed is encoded using the ASN.1
>distinguished encoding rules (DER) [X.690].

The standard says all sorts of odd things that
implementors/implementations
completely ignore.  That's exactly what I was pointing out.

Peter.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA87Yh3h019667 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 8 Nov 2008 00:34:43 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA87Yhg3019666; Sat, 8 Nov 2008 00:34:43 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mailhost.auckland.ac.nz (larry.its.auckland.ac.nz [130.216.12.34]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA87YV2e019656 for <[e-mail]>; Sat, 8 Nov 2008 00:34:42 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 37173195A6; Sat,  8 Nov 2008 20:34:31 +1300 (NZDT)
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (larry.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pR6xHCt+9qJY; Sat,  8 Nov 2008 20:34:31 +1300 (NZDT)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 1BF7A1958A; Sat,  8 Nov 2008 20:34:31 +1300 (NZDT)
Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id C12F219EC0BA; Sat,  8 Nov 2008 20:34:30 +1300 (NZDT)
Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from <[e-mail]>) id 1KyiL0-0001wq-Kq; Sat, 08 Nov 2008 20:34:30 +1300
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: RE: encoding an X.509 certificate
Message-Id: <[e-mail]>
Date: Sat, 08 Nov 2008 20:34:30 +1300
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Kemp, David P." <[e-mail]> writes:

>"X.509 dogma" is just for anal people who want 100% reliability.

Actually this one is just too good to let go, can I use it as a siq quote?

Peter :-).

--
"X.509 dogma" is just for anal people who want 100% reliability - David P.Kemp.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA87MX4G019080 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 8 Nov 2008 00:22:33 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA87MXac019079; Sat, 8 Nov 2008 00:22:33 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.33]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA87MWnB019073 for <[e-mail]>; Sat, 8 Nov 2008 00:22:32 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 1CA8C9D672; Sat,  8 Nov 2008 20:22:32 +1300 (NZDT)
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CViu--7cUU7S; Sat,  8 Nov 2008 20:22:32 +1300 (NZDT)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 00D7E9D5FF; Sat,  8 Nov 2008 20:22:31 +1300 (NZDT)
Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id C8F7519EC0BA; Sat,  8 Nov 2008 20:22:31 +1300 (NZDT)
Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from <[e-mail]>) id 1Kyi9P-0001Tg-M0; Sat, 08 Nov 2008 20:22:31 +1300
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail], [e-mail]
Subject: RE: encoding an X.509 certificate
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
Date: Sat, 08 Nov 2008 20:22:31 +1300
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Santosh Chokhani" <[e-mail]> writes:

>What does that do to interoperability or performance since you get
>certificates from various sources who can encode them whichever way.

Since pretty much everything follows the "the only encoding rule is memcpy()"
rule (and anyone who doesn't learns pretty quickly) there's no effect.  If
people did actually enforce the DER rules as per the spec, that'd kill any
chance of interoperability (and also reduce performance due to the re-encoding
that's necessary, so the net effect is negative on both counts if you follow
the spec).

My intention in pointing out the issues was to at least give the XML guys the
option of having their spec approximate reality, but whether they choose to do
this or to follow PKIX practice is up to them, all I can do is point out the
problem.

(Editorialising a bit, I'm somewhat disturbed that this kind of thing is
 actually news to people.  I've had a few emails off-list from implementors -
 yes, there are still a few left on the list, although all in read-only mode -
 saying, in effect, "Don't people know this stuff?".  If you want a few real-
 world examples, and this is a pretty small subset of selected examples
 because the full list would fill a book, have a look at
 http://www.cypherpunks.to/~peter/T2a_X509_Certs.pdf, starting at slide #61,
 which would be on about p.30 in the PDF (they're laid out two to a page)).

Peter.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA87LNtI019022 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 8 Nov 2008 00:21:23 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA87LNxt019021; Sat, 8 Nov 2008 00:21:23 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.33]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA87LAt2019012 for <[e-mail]>; Sat, 8 Nov 2008 00:21:22 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id CB1469D672; Sat,  8 Nov 2008 20:21:09 +1300 (NZDT)
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ujHGcP1ykr1f; Sat,  8 Nov 2008 20:21:09 +1300 (NZDT)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 22EE19D5FF; Sat,  8 Nov 2008 20:21:08 +1300 (NZDT)
Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 5F15B19EC0BA; Sat,  8 Nov 2008 20:21:07 +1300 (NZDT)
Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from <[e-mail]>) id 1Kyi83-0001TX-7W; Sat, 08 Nov 2008 20:21:07 +1300
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: RE: encoding an X.509 certificate
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
Date: Sat, 08 Nov 2008 20:21:07 +1300
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Kemp, David P." <[e-mail]> writes:

>The same thing that happens to people who don't lint or bounds-check their C
>code - it works most of the time, so it must not matter if the code is
>actually correct.  "X.509 dogma" is just for anal people who want 100%
>reliability.

If you follow the spec in this regard you get 100% unreliability, not
reliability - your PKI application when shipped will break repeatedly whenever
it encounters a non-DER certificate, while everything else will work just
fine.  So "X.509 dogma" is for X.509 dogmatists and pretty much no-one else.

(I actually had a bit of trouble replying to this message, it's not often that
 you see the terms "100% reliability" and "X.509" used in the same sentence 
 (in fact this may be the first time I've ever seen it without a negation in
 there as well), there were so many ways I could have replied to this :-).

Peter.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA7HxxE1028015 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Nov 2008 10:59:59 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA7Hxxi8028014; Fri, 7 Nov 2008 10:59:59 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA7HxxND028007 for <[e-mail]>; Fri, 7 Nov 2008 10:59:59 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id 2C5B13A6B3A; Fri,  7 Nov 2008 10:00:00 -0800 (PST)
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-authorityclearanceconstraints-00.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Fri,  7 Nov 2008 10:00:01 -0800 (PST)
Sender: [e-mail]
Precedence: 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		: Clearance Attribute and Authority Clearance Constraints 
Certificate Extension
	Author(s)	: S. Chokhani, S. Turner
	Filename	: draft-ietf-pkix-authorityclearanceconstraints-00.txt
	Pages		: 19
	Date		: 2008-10-31
	
   This document defines the syntax and semantics for the Clearance 
   attribute and the Authority Clearance Constraints extension in X.509 
   certificates.  The Clearance attribute is used to indicate the 
   clearance held by the subject.  The Clearance attribute may appear in    the subject directory attributes extension of a public key 
   certificate or in the attributes field of an attribute certificate.  
   The Authority Clearance Constraints certificate extension values in a 
   Trust Anchor (TA), CA public key certificates, and an Attribute 
   Authority (AA) public key certificate in a public key certification 
   path constrain the effective Clearance of the subject. 

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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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: Message/External-body;
	name="draft-ietf-pkix-authorityclearanceconstraints-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--NextPart--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA7HjgRw025923 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Nov 2008 10:45:42 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA7HjgB3025922; Fri, 7 Nov 2008 10:45:42 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.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 balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA7HjVQJ025893 for <[e-mail]>; Fri, 7 Nov 2008 10:45:41 -0700 (MST) (envelope-from [e-mail])
Received: from Augustine.missi.ncsc.mil (augustine.missi.ncsc.mil [144.51.60.33]) by stingray.missi.ncsc.mil with ESMTP id mA7HjV2i004724 for <[e-mail]>; Fri, 7 Nov 2008 12:45:31 -0500 (EST)
Received: from DABECK.missi.ncsc.mil ([144.51.60.15]) by Augustine.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 Nov 2008 12:43:20 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: encoding an X.509 certificate
Date: Fri, 7 Nov 2008 12:45:30 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: encoding an X.509 certificate
Thread-Index: AclA8kTOX8HupilKSHe3PLIl9GbeiQAAIAlwAANCxiA=
References: <[e-mail]> <[e-mail]> <[e-mail]>
From: "Kemp, David P." <[e-mail]>
To: <[e-mail]>
X-OriginalArrivalTime: 07 Nov 2008 17:43:20.0125 (UTC) FILETIME=[52C57ED0:01C94100]
Sender: [e-mail]
Precedence: 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 same thing that happens to people who don't lint or bounds-check
their C code - it works most of the time, so it must not matter if the
code is actually correct.  "X.509 dogma" is just for anal people who
want 100% reliability.


-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Santosh Chokhani
Sent: Friday, November 07, 2008 11:55 AM
To: pgut001; [e-mail]; [e-mail]
Subject: RE: encoding an X.509 certificate


Peter,

What does that do to interoperability or performance since you get
certificates from various sources who can encode them whichever way.

-----Original Message-----
From: pgut001 [mailto:[e-mail]]=20
Sent: Friday, November 07, 2008 11:03 AM
To: [e-mail]; [e-mail]; Santosh Chokhani;
[e-mail]
Subject: RE: encoding an X.509 certificate

"Santosh Chokhani" <[e-mail]> writes:

>How do you reconcile what you say with the following in Section 4.1 of
5280:
>
>"The X.509 v3 certificate basic syntax is as follows.  For signature
>calculation, the data that is to be signed is encoded using the ASN.1
>distinguished encoding rules (DER) [X.690].

The standard says all sorts of odd things that
implementors/implementations
completely ignore.  That's exactly what I was pointing out.

Peter.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA7GtCXk020187 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Nov 2008 09:55:12 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA7GtCnK020183; Fri, 7 Nov 2008 09:55:12 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mA7GtACo020171 for <[e-mail]>; Fri, 7 Nov 2008 09:55:11 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 10492 invoked from network); 7 Nov 2008 16:55:24 -0000
Received: from [e-mail] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;07 Nov 2008 16:55:24 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 7 Nov 2008 16:55:24 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: encoding an X.509 certificate
Date: Fri, 7 Nov 2008 11:55:09 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: encoding an X.509 certificate
Thread-Index: AclA8kTOX8HupilKSHe3PLIl9GbeiQAAIAlw
References: <[e-mail]> <[e-mail]>
From: "Santosh Chokhani" <[e-mail]>
To: "pgut001" <[e-mail]>, <[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>

Peter,

What does that do to interoperability or performance since you get
certificates from various sources who can encode them whichever way.

-----Original Message-----
From: pgut001 [mailto:[e-mail]]=20
Sent: Friday, November 07, 2008 11:03 AM
To: [e-mail]; [e-mail]; Santosh Chokhani;
[e-mail]
Subject: RE: encoding an X.509 certificate

"Santosh Chokhani" <[e-mail]> writes:

>How do you reconcile what you say with the following in Section 4.1 of
5280:
>
>"The X.509 v3 certificate basic syntax is as follows.  For signature
>calculation, the data that is to be signed is encoded using the ASN.1
>distinguished encoding rules (DER) [X.690].

The standard says all sorts of odd things that
implementors/implementations
completely ignore.  That's exactly what I was pointing out.

Peter.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA7Gp3GH019844 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Nov 2008 09:51:03 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA7Gp3i9019843; Fri, 7 Nov 2008 09:51:03 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pne-smtpout2-sn2.hy.skanova.net (pne-smtpout2-sn2.hy.skanova.net [81.228.8.164]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA7GoqUP019817 for <[e-mail]>; Fri, 7 Nov 2008 09:51:03 -0700 (MST) (envelope-from [e-mail])
Received: from AndersPC (81.232.45.215) by pne-smtpout2-sn2.hy.skanova.net (7.3.129) id 4873CA9501E123EA; Fri, 7 Nov 2008 17:50:50 +0100
Message-ID: <557551D05E5F406A87309052A433B7EA@AndersPC>
From: "Anders Rundgren" <[e-mail]>
To: "Peter Gutmann" <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: Re: encoding an X.509 certificate
Date: Fri, 7 Nov 2008 17:50:51 +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 Windows Mail 6.0.6000.20661
X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16669
Sender: [e-mail]
Precedence: 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,

That was both interesting and entertaining!

The assumption must then be that implementations always keep the original blob and never normalize 
it to DER, BER etc.

Life is about learning.  I learnt something today :-) :-)

So the response to the XML Dsig people must be "keep that certificate in whatever shape it was" but 
translated to a more standards-conformant lingo.

Anders

----- Original Message ----- 
From: "Peter Gutmann" <[e-mail]>
To: <[e-mail]>; <[e-mail]>; <[e-mail]>
Sent: Friday, November 07, 2008 16:35
Subject: RE: encoding an X.509 certificate



Santosh Chokhani <[e-mail]> writes:

>An X.509 certificate is always DER encoded.

Actually I should have edited the above to say:

  Santosh Chokhani <[e-mail]> quotes the standard:

  >An X.509 certificate is always DER encoded.

In practice it's actually:

  "An X.509 certificate is always encoded in any damn way the originator
  pleases, as long as MSIE, Netscape/FF, and OpenSSL can still swallow the
  result".

with the corollary:

  "Any downstream party keeps a copy of the binary exactly as originally
  encoded and reuses that as and when required".

In other words "there is only one encoding rule and that is memcpy()".  There
have been CAs whose certs break into BER in the middle of the cert, whose
certs contain totally incorrect ASN.1, in at least one memorable occasion
which didn't even contain ASN.1 at all but just raw binary data (and these
were major commercial CAs, Verisign, Thawte, European government-level CAs,
operations at that level), and no-one noticed because they just accepted
whatever they were given without being too choosy.  It's stil going on today,
I got a non-DER cert as recently as a week ago, in this case one with the
keyUsage encoded wrong.

So trying to enforce any kind of encoding is just going to lead to endless
pain.  Given their ongoing c18n problems I'd have thought the XML security
guys would be more aware of this than most :-).

[Reading through numerous other posts from people all saying you use DER,
 e.g.]:

>Certificate and signature could be encoded ways other than DER.  But, in
>order to verify the signature you need to encode the payload in DER since the
>signature is computed on DER.

>DER

>Please use DER.  If you use BER, then the recipient will have to decode the
>certificate and re-encode it with DER in order to validate the signature,
>wasting much effort.

>Certificate and signature could be encoded ways other than DER.  But, in
>order to verify the signature you need to encode the payload in DER since the
>signature is computed on DER.

>Obviously the signature will only verify if it is DER encoded. So, there's
>generally not much point in supporting other encodings.

No, you need to leave the payload exactly in whatever form the signer left it
(and specifically not DER-encode it) or your sig-checks will start failing.

Sheesh, are there *any* implementers still left on this list?  Everyone seems
to be blindly repeating X.509 dogma without any (apparent) awareness of how
things really work.  The repeated advice to enforce DER is just going to cause
your signatures to fail whenever you encounter something that isn't DER-
encoded.

>What's actually needed is the original encoding over which the signature was
>calculated, which although it's supposed to be the DER encoding sometimes
>isn't quite (in which case any re-encoding of the certificate breaks the
>signature). The safest thing to do is accept BER and preserve the exact
>encoding received. That's what directory implementations do.

OK, so there is at least one :-).

Peter.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA7G2pR8015755 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Nov 2008 09:02:51 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA7G2pcC015754; Fri, 7 Nov 2008 09:02:51 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mailhost.auckland.ac.nz (moe.its.auckland.ac.nz [130.216.12.35]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA7G2e5L015724 for <[e-mail]>; Fri, 7 Nov 2008 09:02:50 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 9061F48122B; Sat,  8 Nov 2008 05:02:39 +1300 (NZDT)
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (moe.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6qsYRYHzrLNX; Sat,  8 Nov 2008 05:02:39 +1300 (NZDT)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 2E0DC480D36; Sat,  8 Nov 2008 05:02:39 +1300 (NZDT)
Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 3009419EC0BA; Sat,  8 Nov 2008 05:02:38 +1300 (NZDT)
Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from <[e-mail]>) id 1KyTnC-0007GD-1l; Sat, 08 Nov 2008 05:02:38 +1300
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail], [e-mail]
Subject: RE: encoding an X.509 certificate
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
Date: Sat, 08 Nov 2008 05:02:38 +1300
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Santosh Chokhani" <[e-mail]> writes:

>How do you reconcile what you say with the following in Section 4.1 of 5280:
>
>"The X.509 v3 certificate basic syntax is as follows.  For signature
>calculation, the data that is to be signed is encoded using the ASN.1
>distinguished encoding rules (DER) [X.690].

The standard says all sorts of odd things that implementors/implementations
completely ignore.  That's exactly what I was pointing out.

Peter.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA7FeP6m014500 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Nov 2008 08:40:26 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA7FePPs014499; Fri, 7 Nov 2008 08:40:25 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mA7FeEZp014481 for <[e-mail]>; Fri, 7 Nov 2008 08:40:25 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 9899 invoked from network); 7 Nov 2008 15:40:12 -0000
Received: from [e-mail] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;07 Nov 2008 15:40:12 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 7 Nov 2008 15:40:12 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: encoding an X.509 certificate
Date: Fri, 7 Nov 2008 10:39:57 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: encoding an X.509 certificate
Thread-Index: AclA7oJNpyAR9ZeGQXOpSgOjrAbIdQAAG8sw
References: <[e-mail]> <[e-mail]>
From: "Santosh Chokhani" <[e-mail]>
To: "pgut001" <[e-mail]>, <[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>

Peter,

How do you reconcile what you say with the following in Section 4.1 of
5280:

"The X.509 v3 certificate basic syntax is as follows.  For signature
calculation, the data that is to be signed is encoded using the ASN.1
   distinguished encoding rules (DER) [X.690]. =20

-----Original Message-----
From: pgut001 [mailto:[e-mail]]=20
Sent: Friday, November 07, 2008 10:36 AM
To: [e-mail]; Santosh Chokhani; [e-mail]
Subject: RE: encoding an X.509 certificate

Santosh Chokhani <[e-mail]> writes:

>An X.509 certificate is always DER encoded.

Actually I should have edited the above to say:

  Santosh Chokhani <[e-mail]> quotes the standard:

  >An X.509 certificate is always DER encoded.

In practice it's actually:

  "An X.509 certificate is always encoded in any damn way the originator
  pleases, as long as MSIE, Netscape/FF, and OpenSSL can still swallow
the
  result".

with the corollary:

  "Any downstream party keeps a copy of the binary exactly as originally
  encoded and reuses that as and when required".

In other words "there is only one encoding rule and that is memcpy()".
There
have been CAs whose certs break into BER in the middle of the cert,
whose
certs contain totally incorrect ASN.1, in at least one memorable
occasion
which didn't even contain ASN.1 at all but just raw binary data (and
these
were major commercial CAs, Verisign, Thawte, European government-level
CAs,
operations at that level), and no-one noticed because they just accepted
whatever they were given without being too choosy.  It's stil going on
today,
I got a non-DER cert as recently as a week ago, in this case one with
the
keyUsage encoded wrong.

So trying to enforce any kind of encoding is just going to lead to
endless
pain.  Given their ongoing c18n problems I'd have thought the XML
security
guys would be more aware of this than most :-).

[Reading through numerous other posts from people all saying you use
DER,
 e.g.]:

>Certificate and signature could be encoded ways other than DER.  But,
in
>order to verify the signature you need to encode the payload in DER
since the
>signature is computed on DER.

>DER

>Please use DER.  If you use BER, then the recipient will have to decode
the
>certificate and re-encode it with DER in order to validate the
signature,
>wasting much effort.

>Certificate and signature could be encoded ways other than DER.  But,
in
>order to verify the signature you need to encode the payload in DER
since the
>signature is computed on DER.

>Obviously the signature will only verify if it is DER encoded. So,
there's
>generally not much point in supporting other encodings.

No, you need to leave the payload exactly in whatever form the signer
left it
(and specifically not DER-encode it) or your sig-checks will start
failing.

Sheesh, are there *any* implementers still left on this list?  Everyone
seems
to be blindly repeating X.509 dogma without any (apparent) awareness of
how
things really work.  The repeated advice to enforce DER is just going to
cause
your signatures to fail whenever you encounter something that isn't DER-
encoded.

>What's actually needed is the original encoding over which the
signature was
>calculated, which although it's supposed to be the DER encoding
sometimes
>isn't quite (in which case any re-encoding of the certificate breaks
the
>signature). The safest thing to do is accept BER and preserve the exact
>encoding received. That's what directory implementations do.

OK, so there is at least one :-).

Peter.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA7FZwZn014211 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Nov 2008 08:35:58 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA7FZwji014210; Fri, 7 Nov 2008 08:35:58 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.33]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA7FZkFq014198 for <[e-mail]>; Fri, 7 Nov 2008 08:35:57 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id D4B949D355; Sat,  8 Nov 2008 04:35:45 +1300 (NZDT)
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5r11YHjgb0+b; Sat,  8 Nov 2008 04:35:45 +1300 (NZDT)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 465EC9D338; Sat,  8 Nov 2008 04:35:44 +1300 (NZDT)
Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id CFE9119EC0BA; Sat,  8 Nov 2008 04:35:43 +1300 (NZDT)
Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from <[e-mail]>) id 1KyTN9-00067x-Mh; Sat, 08 Nov 2008 04:35:43 +1300
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail]
Subject: RE: encoding an X.509 certificate
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
Date: Sat, 08 Nov 2008 04:35:43 +1300
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Santosh Chokhani <[e-mail]> writes:

>An X.509 certificate is always DER encoded.

Actually I should have edited the above to say:

  Santosh Chokhani <[e-mail]> quotes the standard:

  >An X.509 certificate is always DER encoded.

In practice it's actually:

  "An X.509 certificate is always encoded in any damn way the originator
  pleases, as long as MSIE, Netscape/FF, and OpenSSL can still swallow the
  result".

with the corollary:

  "Any downstream party keeps a copy of the binary exactly as originally
  encoded and reuses that as and when required".

In other words "there is only one encoding rule and that is memcpy()".  There
have been CAs whose certs break into BER in the middle of the cert, whose
certs contain totally incorrect ASN.1, in at least one memorable occasion
which didn't even contain ASN.1 at all but just raw binary data (and these
were major commercial CAs, Verisign, Thawte, European government-level CAs,
operations at that level), and no-one noticed because they just accepted
whatever they were given without being too choosy.  It's stil going on today,
I got a non-DER cert as recently as a week ago, in this case one with the
keyUsage encoded wrong.

So trying to enforce any kind of encoding is just going to lead to endless
pain.  Given their ongoing c18n problems I'd have thought the XML security
guys would be more aware of this than most :-).

[Reading through numerous other posts from people all saying you use DER,
 e.g.]:

>Certificate and signature could be encoded ways other than DER.  But, in
>order to verify the signature you need to encode the payload in DER since the
>signature is computed on DER.

>DER

>Please use DER.  If you use BER, then the recipient will have to decode the
>certificate and re-encode it with DER in order to validate the signature,
>wasting much effort.

>Certificate and signature could be encoded ways other than DER.  But, in
>order to verify the signature you need to encode the payload in DER since the
>signature is computed on DER.

>Obviously the signature will only verify if it is DER encoded. So, there's
>generally not much point in supporting other encodings.

No, you need to leave the payload exactly in whatever form the signer left it
(and specifically not DER-encode it) or your sig-checks will start failing.

Sheesh, are there *any* implementers still left on this list?  Everyone seems
to be blindly repeating X.509 dogma without any (apparent) awareness of how
things really work.  The repeated advice to enforce DER is just going to cause
your signatures to fail whenever you encounter something that isn't DER-
encoded.

>What's actually needed is the original encoding over which the signature was
>calculated, which although it's supposed to be the DER encoding sometimes
>isn't quite (in which case any re-encoding of the certificate breaks the
>signature). The safest thing to do is accept BER and preserve the exact
>encoding received. That's what directory implementations do.

OK, so there is at least one :-).

Peter.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA7EuYRa010485 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Nov 2008 07:56:34 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA7EuYdB010484; Fri, 7 Nov 2008 07:56:34 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ganymede.on-x.com (ganymede.on-x.com [194.51.68.3]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA7EuMuh010473 for <[e-mail]>; Fri, 7 Nov 2008 07:56:32 -0700 (MST) (envelope-from [e-mail])
Received: from vinea.on-x.com (sedna.puteaux.on-x [192.168.10.9]) by ganymede.on-x.com (Postfix) with ESMTP id 1611869; Fri,  7 Nov 2008 15:56:21 +0100 (CET)
Received: from [193.51.14.5] ([212.234.46.65]) by vinea.on-x.com (Lotus Domino Release 5.0.11) with ESMTP id 2008110715561968:210355 ; Fri, 7 Nov 2008 15:56:19 +0100 
Message-ID: <[e-mail]>
Date: Fri, 07 Nov 2008 15:54:18 +0100
From: Peter Sylvester <[e-mail]>
User-Agent: Thunderbird 1.5.0.9 (X11/20061206)
MIME-Version: 1.0
To: Tomas Gustavsson <[e-mail]>
Cc: Juan Gonzalez <[e-mail]>, "Kemp, David P." <[e-mail]>, Tom Scavo <[e-mail]>, pkix <[e-mail]>
Subject: Re: encoding an X.509 certificate
References: <[e-mail]> <[e-mail]> <[e-mail]> <801F0AF0A50D1F48A1E4DA25881C1CB43C3FEE@exch-bck> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on vinea/ON-X(Release 5.0.11  |July 24, 2002) at 11/07/2008 03:56:19 PM, Serialize by Router on vinea/ON-X(Release 5.0.11  |July 24, 2002) at 11/07/2008 03:56:20 PM, Serialize complete at 11/07/2008 03:56:20 PM
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000500010203070601080500"
Sender: [e-mail]
Precedence: 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.

--------------ms000500010203070601080500
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Tomas Gustavsson wrote:
>
> Hmm, chapter 4.1 in RFC3280 clearly states:
> -----
> 4.1  Basic Certificate Fields
>
>    The X.509 v3 certificate basic syntax is as follows.  For signature
>    calculation, the data that is to be signed is encoded using the ASN.=
1
>    distinguished encoding rules (DER) [X.690].  ASN.1 DER encoding is a=

>    tag, length, value encoding system for each element.
> -----
>
It says 'For signature calculation the date is encoded'. It does not say
that how you encode it when you transfer it to someone.

>
> Cheers,
> Tomas
>
>
> Peter Sylvester wrote:
>> Juan Gonzalez wrote:
>>> Tom:
>>> =20
>>> From my pont of view, the X.509 standard assumes DER encoding for=20
>>> certificates.
>> IMO it does not do that at all. A certficate is an ASN.1 data structur=
e
>> which is independant from a transfer syntax. X.509 does not even=20
>> indicate
>> that one must encode it in DER when it is transfered or stored. I=20
>> vaguely
>> remember that somewhere else in ASN.1 there is a suggestion that
>> when a part of a data structure is signed, that one should use DER
>> as a transfer syntax in order to avoid reencoding.
>>
>> In practice I have never seen a certficate encoded in anything else
>> than DER except in XER like flavour.
>>
>>
>


--=20

<http://www.edelweb.fr>
*Edel/W/eb* 	Peter SYLVESTER
Consultant S=E9curit=E9 des Syst=E8mes d'Information
-----------------------------------------------------------
EdelWeb - Groupe ON-X
15, quai de Dion-Bouton
F-92816 Puteaux Cedex
Tel : [phone] / Fax : [phone]
www.edelweb.fr <http://www.edelweb.fr> / www.on-x.com <http://www.on-x.co=
m>
-----------------------------------------------------------
To verify the message signature, see edelpki.edelweb.fr=20
<http://edelpki.edelweb.fr/>
Cela vous permet de charger le certificat de l'autorit=E9 de racine=20
<http://edelpki.edelweb.fr/cacerts/EdelPKI-ca.der>;
die Liste mit zur=FCckgerufenen Zertifikaten finden Sie da auch.



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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOhTCC
BHIwggLfoAMCAQICBgqvijKA3jANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G
A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs
UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNzAzMjYxMDM3MDNaFw0wOTA2MDMxMDM3MDNaMHAx
CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ
S0kxNTAzBgNVBAMMLFBldGVyIFNZTFZFU1RFUiA8UGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIu
ZnI+MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDPB7ZSfmYsUuVIV0W2izxb1Zyvr6ZJ
IjPiqRMs77dbEQhQ6FZhhUSuABxxc8NjZvyPMRo0uuT0iVpRDktb0fWPTx3m9qTfdqrhWg2c
IOBKNbNQr8NogDJvG1AxRx4q9SXKZCVpZCoHu3fz2Rfji1kL7l597+7qBEsFd9IyvRaexQID
AQABo4IBLjCCASowYgYDVR0RBFswWYEaUGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIuZnKkOzA5
MQswCQYDVQQGEwJGUjEQMA4GA1UECgwHRWRlbFdlYjEYMBYGA1UEAwwPUGV0ZXIgU1lMVkVT
VEVSMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD
VR0fBEMwQTA/oD2gO4Y5aHR0cDovL2VkZWxwa2kuZWRlbHdlYi5mci9jcmwvRWRlbFBLSS1F
ZGVsV2ViLVBlcnNHRU4uY3JsMB0GA1UdDgQWBBSZjq81LuJmsiiu1Yt/ezwCiUQSQTAfBgNV
HSMEGDAWgBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUA
A4IBfAAUq5MJ3gXhdKDpOm0ascDE9e1iMo0RQ24ujkc9IrFXhAJNS+3eNwcJEieU2vgZTsGb
zKeBZom1zVOFoh73VIRP6T08j4dDlndpDYZbxD20KzFt9zX6gV8IgR2zkkZXLQRbLyW16kw8
oFe3s//p1csCkCPAlZv1rZQYR5Psm0A1aiOiuSHhWUmgfAJxmIgfbmKtS3WpsUZVBuLQpThN
rWjLRAqJKYA++++qqo3ujqAAzJLe+MHrX5dai7+n6WBfV4qo1uDArR7XbmgVpV/EdPA75XRi
XEedLgbFDawJ9nAMN6WfL/NG6GZkEa7mZ7sH/gG34y21nq4w4mAAxn9wz7mDKMsEbJMZ5VlJ
TOp0g6TdYqGjNoc/rQg7pqjcRChVitwd1Rl8O31+bIdNSpv4UReNMDcffRQrt+pF1FxR4q6q
M9YLJU8NThx/89Mf/WF7fzrgVlsNJ78D9nJu0EhKes/9EX2qpIcHUfk/izOj8lCc1ksFgXpd
UEchE0DcMIIEcjCCAt+gAwIBAgIGCq+KMoDeMA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT
AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV
BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA3MDMyNjEwMzcwM1oXDTA5MDYwMzEw
MzcwM1owcDELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsMD1NlcnZp
Y2UgRWRlbFBLSTE1MDMGA1UEAwwsUGV0ZXIgU1lMVkVTVEVSIDxQZXRlci5TeWx2ZXN0ZXJA
ZWRlbHdlYi5mcj4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAM8HtlJ+ZixS5UhXRbaL
PFvVnK+vpkkiM+KpEyzvt1sRCFDoVmGFRK4AHHFzw2Nm/I8xGjS65PSJWlEOS1vR9Y9PHeb2
pN92quFaDZwg4Eo1s1Cvw2iAMm8bUDFHHir1JcpkJWlkKge7d/PZF+OLWQvuXn3v7uoESwV3
0jK9Fp7FAgMBAAGjggEuMIIBKjBiBgNVHREEWzBZgRpQZXRlci5TeWx2ZXN0ZXJAZWRlbHdl
Yi5mcqQ7MDkxCzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQDDA9QZXRl
ciBTWUxWRVNURVIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF
BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2ViLmZyL2NybC9F
ZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFJmOrzUu4mayKK7Vi397PAKJ
RBJBMB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MAkGA1UdEwQCMAAwDQYJKoZI
hvcNAQEFBQADggF8ABSrkwneBeF0oOk6bRqxwMT17WIyjRFDbi6ORz0isVeEAk1L7d43BwkS
J5Ta+BlOwZvMp4FmibXNU4WiHvdUhE/pPTyPh0OWd2kNhlvEPbQrMW33NfqBXwiBHbOSRlct
BFsvJbXqTDygV7ez/+nVywKQI8CVm/WtlBhHk+ybQDVqI6K5IeFZSaB8AnGYiB9uYq1Ldamx
RlUG4tClOE2taMtECokpgD7776qqje6OoADMkt74wetfl1qLv6fpYF9XiqjW4MCtHtduaBWl
X8R08DvldGJcR50uBsUNrAn2cAw3pZ8v80boZmQRruZnuwf+AbfjLbWerjDiYADGf3DPuYMo
ywRskxnlWUlM6nSDpN1ioaM2hz+tCDumqNxEKFWK3B3VGXw7fX5sh01Km/hRF40wNx99FCu3
6kXUXFHirqoz1gslTw1OHH/z0x/9YXt/OuBWWw0nvwP2cm7QSEp6z/0RfaqkhwdR+T+LM6Py
UJzWSwWBel1QRyETQNwwggWVMIIDMKADAgECAgYKwoI0lJgwDQYJKoZIhvcNAQEFBQAwUjEL
MAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2UgRWRlbFBL
STEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDcwNjI4MTc0MDU0WhcNMTQwNTAyMTc0
MDU0WjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2Vydmlj
ZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTjCCAZwwDQYJKoZI
hvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bcrJKIlnAPn6eH8V1M
ORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5JfuDjU6Aq0RzmjqTWDe
1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WLwHLA+sIKFzA/CCRt
qeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQNHeCgbUvebvAT9Hd
UGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy4DazzXfZosKeJATH
pyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38psgnVLtPPITgOZrS
cV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+EiISL7aJHQcJRoNB
CdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4GgMIGdMDoGA1UdHwQzMDEwL6AtoCuGKWh0
dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8GA1UdEwQIMAYBAf8C
AQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAfBgNV
HSMEGDAWgBSo2SuP1LBnur1JXLwz/HdSEblnnTANBgkqhkiG9w0BAQUFAAOCAk4AUgtIR4Jh
Ynyk939SM6X4YZPNYIgDio8Gp064P1MBILDgI/hzSwyxT5bb1qUQub+icXO9/5ufsDufr/ff
2gCzKMuo3hC26iey630PzHTvJgrTcEp9c92IZPt3UKeouqy+95Lz2r58dbfouKLZVwiKQ0jP
2c2U5tPWmzW4CAjFWUKRYlrhbt+tjzW8CAA0DHO1xrrzAuTyuGNKcH4LlLuVo7MbDPn/uLma
1fAVYvH2c6OTwGHJyKTQVveYw4UqgAhErJMFWJDKm+Q9h91mCzkjrA1Eu0nVDUTV1+dW6mNT
DPLIq0qSdqP7iT2WcNzQVy/0PiXT2aaEH9lE2W1SSD6PnT8y+aqJTGjRMK1cl7VSJHxbq8U9
lIS+6eiV5VrogAa8X52pKF0u91i+/CBZ3e5Mi2/BwMrMN/mXA/ZwL3p+jZpnijpqnqdz8iCn
qR9ExhR+BpN/b56RqEu7llLrcwOS44kjbubALjxe0+XutidWjt/6/tLYuM7rJ6Hk1EweFGVd
kRejKogD3GzZ3gOAIF/D28VBJcTRcyF7OI/k/3jPD0gHUGN1uxk2Krz8SE9GEPvP/JehCBl/
FrQOCsEUmszi7Se0Vxr2k1P7icxT7L/AcWt/djIgp/vsQNurbi0+5+q7YS2b2bc1HchjsmaI
cXy8ha5IGk4+F1qrHZsGqTm5M7TzZN6k0X2llMaozrtPzxNMC6uvf1uRvHYHf1x0Q0pdxTzZ
PuuFw1PUlu6o5xPHbf3ZgC7ZNSDry13ZEXmlG2Re0u9WwEJJ1nYqlcDvNzGCAq4wggKqAgEB
MGUwWzELMAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2Ug
RWRlbFBLSTEgMB4GA1UEAxMXRWRlbFBLSSBFZGVsV2ViIFBlcnNHRU4CBgqvijKA3jAJBgUr
DgMCGgUAoIIBnzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0w
ODExMDcxNDU0MThaMCMGCSqGSIb3DQEJBDEWBBTtEuD0xA4/QpCIb/cNxGL3Hyj4wTBSBgkq
hkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIB
QDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDB0BgkrBgEEAYI3EAQxZzBlMFsxCzAJBgNVBAYT
AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV
BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOAgYKr4oygN4wdgYLKoZIhvcNAQkQAgsxZ6Bl
MFsxCzAJBgNVBAYTAkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVk
ZWxQS0kxIDAeBgNVBAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOAgYKr4oygN4wDQYJKoZI
hvcNAQEBBQAEgYCLBTT3zsNQTtaY80Gh4eriGnWGiz3BFMGcxJCeXo5MkeFFu9bT20ea/k13
ZfGbvwbb3D6VGX3cF+vR6Ni5YzKxuz9EmCHX3H1vdmGYl+r01acoRB7Z4iN7jW9VsRo3SPRw
e3uGfpmL1XHhluuD70h8yLIh5CLQwDsms9zvQdTaKgAAAAAAAA==
--------------ms000500010203070601080500--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA7Ejqt3009772 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Nov 2008 07:45:52 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA7EjqjX009771; Fri, 7 Nov 2008 07:45:52 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [8.8.40.152]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mA7EjfgJ009750 for <[e-mail]>; Fri, 7 Nov 2008 07:45:51 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Received: (qmail 10094 invoked by uid 0); 7 Nov 2008 14:45:38 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (96.255.143.189) by woodstock.binhost.com with SMTP; 7 Nov 2008 14:45:38 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Fri, 07 Nov 2008 09:45:37 -0500
To: Steven Legg <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: encoding an X.509 certificate
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[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>

>>Please use DER.  If you use BER, then the recipient will have to 
>>decode the certificate and re-encode it with DER in order to 
>>validate the signature, wasting much effort.
>
>What's actually needed is the original encoding over which the signature
>was calculated, which although it's supposed to be the DER encoding
>sometimes isn't quite (in which case any re-encoding of the certificate
>breaks the signature). The safest thing to do is accept BER and preserve
>the exact encoding received. That's what directory implementations do.

Steve, you are completely correct.  All of the PKIX specifications 
talk about signing the DER-encoded certificate.  RFC 5280 says:

    For signature calculation, the data that is to be signed is encoded
    using the ASN.1 distinguished encoding rules (DER) [X.690].

Once the certificate is signed, it would be great if the certificate 
was carried as a blob and the encoding was not 
changed.  Unfortunately, this is not my experience.  I recall a 
system that used an X.500 Directory in the mid-1990s.  Post a 
DER-encoded certificate, and then fetch it again, and it came back 
BER-encoded.  The client had to re-encode the certificate with DER in 
order to perform signature validation.

You claim that "directory implementations" do not change the 
encoding.  I hope that is what happens today.  Much effort was wasted 
encoding and re-encoding the certificates.  We know that the CAs did 
DER properly in that system, otherwise no certificate validation 
would have been successful.

In summary, create the certificate using DER, and then carry it 
without changing the encoding.

Russ 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA7E5fHA006340 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Nov 2008 07:05:41 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA7E5fVM006339; Fri, 7 Nov 2008 07:05:41 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA7E5U0O006326 for <[e-mail]>; Fri, 7 Nov 2008 07:05:40 -0700 (MST) (envelope-from [e-mail])
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id mA7E5Swg023423 for <[e-mail]>; Fri, 7 Nov 2008 09:05:29 -0500
Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id mA7E5SMR023413; Fri, 7 Nov 2008 09:05:28 -0500
Received: from [129.83.200.2] (129.83.200.2) by imchub2.MITRE.ORG (129.83.29.74) with Microsoft SMTP Server (TLS) id 8.1.311.2; Fri, 7 Nov 2008 09:05:28 -0500
Message-ID: <[e-mail]>
Date: Fri, 7 Nov 2008 08:05:24 -0600
From: "Timothy J. Miller" <[e-mail]>
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: Anders Rundgren <[e-mail]>
CC: Peter Sylvester <[e-mail]>, Juan Gonzalez <[e-mail]>, "Kemp, David P." <[e-mail]>, Tom Scavo <[e-mail]>, pkix <[e-mail]>
Subject: Re: encoding an X.509 certificate
References: <[e-mail]> <[e-mail]> <[e-mail]> <801F0AF0A50D1F48A1E4DA25881C1CB43C3FEE@exch-bck> <[e-mail]> <1873A42DC1CA442899DC6879D87679AF@AndersPC>
In-Reply-To: <1873A42DC1CA442899DC6879D87679AF@AndersPC>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070605060508090503030904"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

Anders Rundgren wrote:

> What's apparent is that the specification is a bit unclear on this point which should be possible to 
> fix any old day since it doesn't break any code, it just formalizes the de-facto standard.

IMHO the specification is clear.  Certificates are data structures, with 
the signature portion defined as using the ASN.1 DER encoding of that 
data structure.

After that, how you marshal that data structure for transport is up to 
your application.  This grants maximum flexibility.

-- Tim

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKvjCC
A2cwggJPoAMCAQICAh8FMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEe
MBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3Jh
dGlvbiBQcmltYXJ5IENBLTEwHhcNMDgwODIxMTUzMTI5WhcNMTAwMjEyMTUzMTI5WjBaMRIw
EAYDVQQKEwltaXRyZS5vcmcxDzANBgNVBAsTBnBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3Rt
aWxsZXIxGjAYBgNVBAMTEU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQCTxM+z5fDKvmBInGatv0DkVwuOxd69S2M2jho8QkOltYJK/4JUm9uK0UtQZkyI
bEjmCpmXLw17iMCgA0SjwuUfJxdF8ntTys8keyMjRdlKSwFnkgZl9tL7o060LBtZQYzI5ajr
W9k3N768G/k1bZS5UYiMGHU5+Ygl4IwVhmQv3wIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF
4DAdBgNVHQ4EFgQUSXARqmj5Bl2Lz7RLoUIkuOHl0MkwHwYDVR0jBBgwFoAUh7QPSI1iM0LB
LVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL3d3dy5taXRyZS5vcmcvdGVj
aC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1UdEQQVMBOBEXRtaWxsZXJAbWl0cmUu
b3JnMA0GCSqGSIb3DQEBBQUAA4IBAQAbA1PH/hed/rryO1f0yfTRJnD/vL1rFTduUut/irL7
FSXHGybuPHxydfyGPvJ4qj+T8hs1W0jTa2zQnaPR52tms3hefl76CNVP9vJoVmaM9svFX4DX
6eJh/4SAI81tAuBIK8gxsWd1Va/Bnnh1/wsZLc8w2jkojVqkT2AHPaHS3DBKX7QAWovXVSxY
QlqMIH4zvSNSVfpvpIf0MWJWRBPvgerVSbJsA4dz6ziKvXDWySTV9zwSuNjikNqL//nIKwjb
r3ZOfSUOxSuhW58an2Ha4TdORvG4dGJEsMzxbpTB+wt/s6tK6roONV4uiDtODBNVAG+XGofe
McsS0b7iXdxDMIIDZzCCAk+gAwIBAgICHwUwDQYJKoZIhvcNAQEFBQAwXTESMBAGA1UEChMJ
bWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAlBgNVBAMTHk1J
VFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMTAeFw0wODA4MjExNTMxMjlaFw0xMDAyMTIx
NTMxMjlaMFoxEjAQBgNVBAoTCW1pdHJlLm9yZzEPMA0GA1UECxMGcGVvcGxlMRcwFQYKCZIm
iZPyLGQBARMHdG1pbGxlcjEaMBgGA1UEAxMRTWlsbGVyIFRpbW90aHkgSi4wgZ8wDQYJKoZI
hvcNAQEBBQADgY0AMIGJAoGBAJPEz7Pl8Mq+YEicZq2/QORXC47F3r1LYzaOGjxCQ6W1gkr/
glSb24rRS1BmTIhsSOYKmZcvDXuIwKADRKPC5R8nF0Xye1PKzyR7IyNF2UpLAWeSBmX20vuj
TrQsG1lBjMjlqOtb2Tc3vrwb+TVtlLlRiIwYdTn5iCXgjBWGZC/fAgMBAAGjgbcwgbQwDgYD
VR0PAQH/BAQDAgXgMB0GA1UdDgQWBBRJcBGqaPkGXYvPtEuhQiS44eXQyTAfBgNVHSMEGDAW
gBSHtA9IjWIzQsEtURpIHsKeuwqxrTBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vd3d3Lm1p
dHJlLm9yZy90ZWNoL21paS9wa2kvY2ExX21pdHJlX29yZy5jcmwwHAYDVR0RBBUwE4ERdG1p
bGxlckBtaXRyZS5vcmcwDQYJKoZIhvcNAQEFBQADggEBABsDU8f+F53+uvI7V/TJ9NEmcP+8
vWsVN25S63+KsvsVJccbJu48fHJ1/IY+8niqP5PyGzVbSNNrbNCdo9Hna2azeF5+XvoI1U/2
8mhWZoz2y8VfgNfp4mH/hIAjzW0C4EgryDGxZ3VVr8GeeHX/CxktzzDaOSiNWqRPYAc9odLc
MEpftABai9dVLFhCWowgfjO9I1JV+m+kh/QxYlZEE++B6tVJsmwDh3PrOIq9cNbJJNX3PBK4
2OKQ2ov/+cgrCNuvdk59JQ7FK6FbnxqfYdrhN05G8bh0YkSwzPFulMH7C3+zq0rqug41Xi6I
O04ME1UAb5cah94xyxLRvuJd3EMwggPkMIICzKADAgECAgEFMA0GCSqGSIb3DQEBBQUAMFox
EjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MSQw
IgYDVQQDExtNSVRSRSBDb3Jwb3JhdGlvbiBSb290IENBLTEwHhcNMDYwNjAzMTcxMzIyWhcN
MTIwNjAzMTcxMzIyWjBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmlj
YXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0x
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyPB7Vl0QgqgQt0u8Q2duRs7eZUPn
hlflKPFPMXGG+iqGpImYs6nfbFPsn0q8FqklFsm/UEV2JJQ3c7Srwfrqe9CrCbVFh761OxZI
7fnUWiUasNP2ING19aAfrQ8IoJsAEtGzHeIacS+M5CN4C0yfUC6CpBZTc9ZldjLUatvJr407
K1i+7WnrRsMVKhICfgmiO/XiVR9YeXyzeRqFrLy6YtJCJuJd0QRfwKtKRpek5oU67Izr7ClH
DtPJs7UOTjMYBS2fTzztC+wwOTp6+A3ZbEymuQcAZRwmGkjVBe2R8MiX26R02Iigz+903ZAL
/6bpvx0DnkrlR2UFr1KBGfBqmQIDAQABo4GxMIGuMBIGA1UdEwEB/wQIMAYBAf8CAQIwDgYD
VR0PAQH/BAQDAgGGMB0GA1UdDgQWBBSHtA9IjWIzQsEtURpIHsKeuwqxrTAfBgNVHSMEGDAW
gBTHcFEA2E3+5AHUaJbFPZ+al/50LzBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vd3d3Lm1p
dHJlLm9yZy90ZWNoL21paS9wa2kvcm9vdGNhMV9taXRyZV9vcmcuY3JsMA0GCSqGSIb3DQEB
BQUAA4IBAQBNbm7rrins3SICPbteX9qSN1+RJClqix/pw3IAe7u60LK0V9jVZ9E2a+c0MZiS
ojdcwU5rXxI2OI2wwIf6wVBo76jIOc+IiQRlC+V8YatGmoibqP/8WDPzlud/WQAzkjrU2nuh
8KdyJG+n1kH/6772Lbra2CIk8mu8FypeaB5P2uIJzdE+PGo82ZiyU680ukiJ9yF6UmEXuciB
77tGQBRxMl6ePzIrArQnf48SmBhFD5XYLraueOiG7E+AzD99ig1M6WHcxWXtp3DIrVqE/DZr
146NJaCWqg9NoE14cmpEllnpWLtLnn5UBYJ+QCozmbe1SJXOOynZ0VxMnGdh7NqgMYICqDCC
AqQCAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1
dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTAJ
BgUrDgMCGgUAoIIBmzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0wODExMDcxNDA1MjRaMCMGCSqGSIb3DQEJBDEWBBTlUkFGV8VCkxfnKzprXOyY+0GFwzBS
BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D
AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNV
BAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQD
Ex5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAh8FMHQGCyqGSIb3DQEJEAILMWWg
YzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0
eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTANBgkqhkiG
9w0BAQEFAASBgDyEQ+gMXrxb7DGHQa2AtP+54fNFKF6cRJAHczXMpKdIMkGbr24pec9WIpHF
lm3vLKg296xhHmy5f0ue7+aHRXCZRQWBMpp3ka/aGPUNC9FdPHW232jC3mKz6uU2zg6IrcZN
OS4H6cq8gg2rauD3+jCIRBrEJI2T7d6WZwTJXzy9AAAAAAAA
--------------ms070605060508090503030904--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA7Bgt2f093776 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Nov 2008 04:42:55 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA7Bgthb093775; Fri, 7 Nov 2008 04:42:55 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pne-smtpout2-sn2.hy.skanova.net (pne-smtpout2-sn2.hy.skanova.net [81.228.8.164]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA7BgiF9093755 for <[e-mail]>; Fri, 7 Nov 2008 04:42:54 -0700 (MST) (envelope-from [e-mail])
Received: from AndersPC (81.232.45.215) by pne-smtpout2-sn2.hy.skanova.net (7.3.129) id 4873CA9501DF9DB4; Fri, 7 Nov 2008 12:42:33 +0100
Message-ID: <1873A42DC1CA442899DC6879D87679AF@AndersPC>
From: "Anders Rundgren" <[e-mail]>
To: "Peter Sylvester" <[e-mail]>, "Juan Gonzalez" <[e-mail]>
Cc: "Kemp, David P." <[e-mail]>, "Tom Scavo" <[e-mail]>, "pkix" <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <801F0AF0A50D1F48A1E4DA25881C1CB43C3FEE@exch-bck> <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: Re: encoding an X.509 certificate
Date: Fri, 7 Nov 2008 12:42:31 +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 Windows Mail 6.0.6000.20661
X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16669
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Everybody is right :-)

If we cut down the question to the original issue which was how X509Certificate XML Dsig objects are 
encoded, existing systems use Base64 over DER and there is no chance (or reason) for changing that. 
What's apparent is that the specification is a bit unclear on this point which should be possible to 
fix any old day since it doesn't break any code, it just formalizes the de-facto standard.

Anders

----- Original Message ----- 
From: "Peter Sylvester" <[e-mail]>
To: "Juan Gonzalez" <[e-mail]>
Cc: "Kemp, David P." <[e-mail]>; "Tom Scavo" <[e-mail]>; "pkix" 
<[e-mail]>
Sent: Friday, November 07, 2008 10:56
Subject: Re: encoding an X.509 certificate


Juan Gonzalez wrote:
> Tom:
>
> From my pont of view, the X.509 standard assumes DER encoding for
> certificates.
IMO it does not do that at all. A certficate is an ASN.1 data structure
which is independant from a transfer syntax. X.509 does not even indicate
that one must encode it in DER when it is transfered or stored. I vaguely
remember that somewhere else in ASN.1 there is a suggestion that
when a part of a data structure is signed, that one should use DER
as a transfer syntax in order to avoid reencoding.

In practice I have never seen a certficate encoded in anything else
than DER except in XER like flavour.





Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA79wVE0084619 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Nov 2008 02:58:31 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA79wVbW084618; Fri, 7 Nov 2008 02:58:31 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ganymede.on-x.com (ganymede.on-x.com [194.51.68.3]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA79wGAK084594 for <[e-mail]>; Fri, 7 Nov 2008 02:58:29 -0700 (MST) (envelope-from [e-mail])
Received: from vinea.on-x.com (sedna.puteaux.on-x [192.168.10.9]) by ganymede.on-x.com (Postfix) with ESMTP id 121C569; Fri,  7 Nov 2008 10:58:11 +0100 (CET)
Received: from [193.51.14.5] ([212.234.46.65]) by vinea.on-x.com (Lotus Domino Release 5.0.11) with ESMTP id 2008110710580957:209630 ; Fri, 7 Nov 2008 10:58:09 +0100 
Message-ID: <[e-mail]>
Date: Fri, 07 Nov 2008 10:56:11 +0100
From: Peter Sylvester <[e-mail]>
User-Agent: Thunderbird 1.5.0.9 (X11/20061206)
MIME-Version: 1.0
To: Juan Gonzalez <[e-mail]>
Cc: "Kemp, David P." <[e-mail]>, Tom Scavo <[e-mail]>, pkix <[e-mail]>
Subject: Re: encoding an X.509 certificate
References: <[e-mail]> <[e-mail]> <[e-mail]> <801F0AF0A50D1F48A1E4DA25881C1CB43C3FEE@exch-bck>
In-Reply-To: <801F0AF0A50D1F48A1E4DA25881C1CB43C3FEE@exch-bck>
X-MIMETrack: Itemize by SMTP Server on vinea/ON-X(Release 5.0.11  |July 24, 2002) at 11/07/2008 10:58:09 AM, Serialize by Router on vinea/ON-X(Release 5.0.11  |July 24, 2002) at 11/07/2008 10:58:10 AM, Serialize complete at 11/07/2008 10:58:10 AM
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040808030509030708000309"
Sender: [e-mail]
Precedence: 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.

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

Juan Gonzalez wrote:
> Tom:
>  
> From my pont of view, the X.509 standard assumes DER encoding for 
> certificates.
IMO it does not do that at all. A certficate is an ASN.1 data structure
which is independant from a transfer syntax. X.509 does not even indicate
that one must encode it in DER when it is transfered or stored. I vaguely
remember that somewhere else in ASN.1 there is a suggestion that
when a part of a data structure is signed, that one should use DER
as a transfer syntax in order to avoid reencoding.

In practice I have never seen a certficate encoded in anything else
than DER except in XER like flavour.



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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOhTCC
BHIwggLfoAMCAQICBgqvijKA3jANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G
A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs
UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNzAzMjYxMDM3MDNaFw0wOTA2MDMxMDM3MDNaMHAx
CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ
S0kxNTAzBgNVBAMMLFBldGVyIFNZTFZFU1RFUiA8UGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIu
ZnI+MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDPB7ZSfmYsUuVIV0W2izxb1Zyvr6ZJ
IjPiqRMs77dbEQhQ6FZhhUSuABxxc8NjZvyPMRo0uuT0iVpRDktb0fWPTx3m9qTfdqrhWg2c
IOBKNbNQr8NogDJvG1AxRx4q9SXKZCVpZCoHu3fz2Rfji1kL7l597+7qBEsFd9IyvRaexQID
AQABo4IBLjCCASowYgYDVR0RBFswWYEaUGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIuZnKkOzA5
MQswCQYDVQQGEwJGUjEQMA4GA1UECgwHRWRlbFdlYjEYMBYGA1UEAwwPUGV0ZXIgU1lMVkVT
VEVSMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD
VR0fBEMwQTA/oD2gO4Y5aHR0cDovL2VkZWxwa2kuZWRlbHdlYi5mci9jcmwvRWRlbFBLSS1F
ZGVsV2ViLVBlcnNHRU4uY3JsMB0GA1UdDgQWBBSZjq81LuJmsiiu1Yt/ezwCiUQSQTAfBgNV
HSMEGDAWgBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUA
A4IBfAAUq5MJ3gXhdKDpOm0ascDE9e1iMo0RQ24ujkc9IrFXhAJNS+3eNwcJEieU2vgZTsGb
zKeBZom1zVOFoh73VIRP6T08j4dDlndpDYZbxD20KzFt9zX6gV8IgR2zkkZXLQRbLyW16kw8
oFe3s//p1csCkCPAlZv1rZQYR5Psm0A1aiOiuSHhWUmgfAJxmIgfbmKtS3WpsUZVBuLQpThN
rWjLRAqJKYA++++qqo3ujqAAzJLe+MHrX5dai7+n6WBfV4qo1uDArR7XbmgVpV/EdPA75XRi
XEedLgbFDawJ9nAMN6WfL/NG6GZkEa7mZ7sH/gG34y21nq4w4mAAxn9wz7mDKMsEbJMZ5VlJ
TOp0g6TdYqGjNoc/rQg7pqjcRChVitwd1Rl8O31+bIdNSpv4UReNMDcffRQrt+pF1FxR4q6q
M9YLJU8NThx/89Mf/WF7fzrgVlsNJ78D9nJu0EhKes/9EX2qpIcHUfk/izOj8lCc1ksFgXpd
UEchE0DcMIIEcjCCAt+gAwIBAgIGCq+KMoDeMA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT
AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV
BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA3MDMyNjEwMzcwM1oXDTA5MDYwMzEw
MzcwM1owcDELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsMD1NlcnZp
Y2UgRWRlbFBLSTE1MDMGA1UEAwwsUGV0ZXIgU1lMVkVTVEVSIDxQZXRlci5TeWx2ZXN0ZXJA
ZWRlbHdlYi5mcj4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAM8HtlJ+ZixS5UhXRbaL
PFvVnK+vpkkiM+KpEyzvt1sRCFDoVmGFRK4AHHFzw2Nm/I8xGjS65PSJWlEOS1vR9Y9PHeb2
pN92quFaDZwg4Eo1s1Cvw2iAMm8bUDFHHir1JcpkJWlkKge7d/PZF+OLWQvuXn3v7uoESwV3
0jK9Fp7FAgMBAAGjggEuMIIBKjBiBgNVHREEWzBZgRpQZXRlci5TeWx2ZXN0ZXJAZWRlbHdl
Yi5mcqQ7MDkxCzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQDDA9QZXRl
ciBTWUxWRVNURVIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF
BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2ViLmZyL2NybC9F
ZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFJmOrzUu4mayKK7Vi397PAKJ
RBJBMB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MAkGA1UdEwQCMAAwDQYJKoZI
hvcNAQEFBQADggF8ABSrkwneBeF0oOk6bRqxwMT17WIyjRFDbi6ORz0isVeEAk1L7d43BwkS
J5Ta+BlOwZvMp4FmibXNU4WiHvdUhE/pPTyPh0OWd2kNhlvEPbQrMW33NfqBXwiBHbOSRlct
BFsvJbXqTDygV7ez/+nVywKQI8CVm/WtlBhHk+ybQDVqI6K5IeFZSaB8AnGYiB9uYq1Ldamx
RlUG4tClOE2taMtECokpgD7776qqje6OoADMkt74wetfl1qLv6fpYF9XiqjW4MCtHtduaBWl
X8R08DvldGJcR50uBsUNrAn2cAw3pZ8v80boZmQRruZnuwf+AbfjLbWerjDiYADGf3DPuYMo
ywRskxnlWUlM6nSDpN1ioaM2hz+tCDumqNxEKFWK3B3VGXw7fX5sh01Km/hRF40wNx99FCu3
6kXUXFHirqoz1gslTw1OHH/z0x/9YXt/OuBWWw0nvwP2cm7QSEp6z/0RfaqkhwdR+T+LM6Py
UJzWSwWBel1QRyETQNwwggWVMIIDMKADAgECAgYKwoI0lJgwDQYJKoZIhvcNAQEFBQAwUjEL
MAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2UgRWRlbFBL
STEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDcwNjI4MTc0MDU0WhcNMTQwNTAyMTc0
MDU0WjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2Vydmlj
ZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTjCCAZwwDQYJKoZI
hvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bcrJKIlnAPn6eH8V1M
ORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5JfuDjU6Aq0RzmjqTWDe
1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WLwHLA+sIKFzA/CCRt
qeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQNHeCgbUvebvAT9Hd
UGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy4DazzXfZosKeJATH
pyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38psgnVLtPPITgOZrS
cV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+EiISL7aJHQcJRoNB
CdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4GgMIGdMDoGA1UdHwQzMDEwL6AtoCuGKWh0
dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8GA1UdEwQIMAYBAf8C
AQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAfBgNV
HSMEGDAWgBSo2SuP1LBnur1JXLwz/HdSEblnnTANBgkqhkiG9w0BAQUFAAOCAk4AUgtIR4Jh
Ynyk939SM6X4YZPNYIgDio8Gp064P1MBILDgI/hzSwyxT5bb1qUQub+icXO9/5ufsDufr/ff
2gCzKMuo3hC26iey630PzHTvJgrTcEp9c92IZPt3UKeouqy+95Lz2r58dbfouKLZVwiKQ0jP
2c2U5tPWmzW4CAjFWUKRYlrhbt+tjzW8CAA0DHO1xrrzAuTyuGNKcH4LlLuVo7MbDPn/uLma
1fAVYvH2c6OTwGHJyKTQVveYw4UqgAhErJMFWJDKm+Q9h91mCzkjrA1Eu0nVDUTV1+dW6mNT
DPLIq0qSdqP7iT2WcNzQVy/0PiXT2aaEH9lE2W1SSD6PnT8y+aqJTGjRMK1cl7VSJHxbq8U9
lIS+6eiV5VrogAa8X52pKF0u91i+/CBZ3e5Mi2/BwMrMN/mXA/ZwL3p+jZpnijpqnqdz8iCn
qR9ExhR+BpN/b56RqEu7llLrcwOS44kjbubALjxe0+XutidWjt/6/tLYuM7rJ6Hk1EweFGVd
kRejKogD3GzZ3gOAIF/D28VBJcTRcyF7OI/k/3jPD0gHUGN1uxk2Krz8SE9GEPvP/JehCBl/
FrQOCsEUmszi7Se0Vxr2k1P7icxT7L/AcWt/djIgp/vsQNurbi0+5+q7YS2b2bc1HchjsmaI
cXy8ha5IGk4+F1qrHZsGqTm5M7TzZN6k0X2llMaozrtPzxNMC6uvf1uRvHYHf1x0Q0pdxTzZ
PuuFw1PUlu6o5xPHbf3ZgC7ZNSDry13ZEXmlG2Re0u9WwEJJ1nYqlcDvNzGCAq4wggKqAgEB
MGUwWzELMAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2Ug
RWRlbFBLSTEgMB4GA1UEAxMXRWRlbFBLSSBFZGVsV2ViIFBlcnNHRU4CBgqvijKA3jAJBgUr
DgMCGgUAoIIBnzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0w
ODExMDcwOTU2MTFaMCMGCSqGSIb3DQEJBDEWBBQP9xTkybP4gwU89y2eUCCLnxF+YDBSBgkq
hkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIB
QDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDB0BgkrBgEEAYI3EAQxZzBlMFsxCzAJBgNVBAYT
AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV
BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOAgYKr4oygN4wdgYLKoZIhvcNAQkQAgsxZ6Bl
MFsxCzAJBgNVBAYTAkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVk
ZWxQS0kxIDAeBgNVBAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOAgYKr4oygN4wDQYJKoZI
hvcNAQEBBQAEgYA9bxvPzehEFxMlo+mp1cUsjbX3eA2FJyZ5xXnchTbDhfmgFhCg505WF74W
6FlsFE415k92cJLfEPh0SNkf9KqUQVYf8ElAiR7MGcCs7QiCD7DH7XGhxExhcu+i+IE/buFF
3sq7yxTj62OBSCIE0FFNe3CRK+CI05aVIulJ2jW0qwAAAAAAAA==
--------------ms040808030509030708000309--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA78KCYK077434 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Nov 2008 01:20:12 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA78KCxJ077433; Fri, 7 Nov 2008 01:20:12 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.links.org (mail.links.org [217.155.92.109]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA78K0rY077413 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Fri, 7 Nov 2008 01:20:12 -0700 (MST) (envelope-from [e-mail])
Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id D38AD33C1E; Fri,  7 Nov 2008 08:21:26 +0000 (GMT)
Message-ID: <[e-mail]>
Date: Fri, 07 Nov 2008 08:19:51 +0000
From: Ben Laurie <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.4.0
MIME-Version: 1.0
To: Tom Scavo <[e-mail]>
CC: Anders Rundgren <[e-mail]>, pkix <[e-mail]>
Subject: Re: encoding an X.509 certificate
References: <[e-mail]>	 <[e-mail]>	 <3AFA0E5E3C2F40D8BDB10F80185A69B3@AndersPC>	 <[e-mail]>	 <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset=ISO-8859-1
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>

Tom Scavo wrote:
> On Thu, Nov 6, 2008 at 3:36 PM, Ben Laurie <[e-mail]> wrote:
>> Obviously the signature will only verify if it is DER encoded. So,
>> there's generally not much point in supporting other encodings.
> 
> Well, that brings up a good point, which I neglected to make clear.
> The SAML profile that makes use of the XML structure posted earlier
> does not require that the certificate in question be validated by the
> receiving party.  The certificate is merely a container for a public
> key, for which the client proves possession of the corresponding
> private key, nothing more.
> 
> If the receiving party is a SAML identity provider, the presented
> certificate is bound to a SAML assertion (using the XML structure
> posted earlier).  If the receiving party is a SAML service provider,
> the presented certificate is compared to the certificate bound to the
> SAML assertion.  So the actual encoding applied to the certificate is
> not important, except of course the identity provider and the service
> provider need to be on the same page, otherwise certificate comparison
> at the service provider will fail.

If that's true, then your first paragraph is incorrect - all of the
certificate matters. However, if all you really care about is the public
key, why does the receiving party not just check that and ignore the
certificate?

> Obviously, if the identity provider is required to bind a base64
> encoding of a DER-encoded certificate, the service provider will have
> no problem (or so it seems), but there are some who are inclined not
> to specify DER explicitly, to future-proof the profile, as it were.
> 
> I hope this helps to clarify.  I had hoped to avoid the details but I
> see that may not be possible.
> 
> Thanks,
> Tom
> 
> 


-- 
http://www.apache-ssl.org/ben.html           http://www.links.org/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA6Nb7WK054032 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Nov 2008 16:37:07 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA6Nb78Y054031; Thu, 6 Nov 2008 16:37:07 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from eb2bcom.com (eb2bcom.com [72.232.34.13]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA6Nb6CF054025 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 6 Nov 2008 16:37:06 -0700 (MST) (envelope-from [e-mail])
Received: from [202.164.192.219] (helo=[192.168.99.100]) by host.eb2bcom.com with esmtpa (Exim 4.69) (envelope-from <[e-mail]>) id 1KyEPQ-0008CD-OB; Fri, 07 Nov 2008 10:37:05 +1100
Message-ID: <[e-mail]>
Date: Fri, 07 Nov 2008 10:37:00 +1100
From: Steven Legg <[e-mail]>
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: Russ Housley <[e-mail]>
CC: Tom Scavo <[e-mail]>, [e-mail]
Subject: Re: encoding an X.509 certificate
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - host.eb2bcom.com
X-AntiAbuse: Original Domain - imc.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - eb2bcom.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ,

Russ Housley wrote:
> 
> Please use DER.  If you use BER, then the recipient will have to decode 
> the certificate and re-encode it with DER in order to validate the 
> signature, wasting much effort.

What's actually needed is the original encoding over which the signature
was calculated, which although it's supposed to be the DER encoding
sometimes isn't quite (in which case any re-encoding of the certificate
breaks the signature). The safest thing to do is accept BER and preserve
the exact encoding received. That's what directory implementations do.

Regards,
Steven

> 
> Russ
> 
> At 12:49 PM 11/6/2008, Tom Scavo wrote:
> 
>> I've asked the following question in a number of forums with no luck.
>> I'm hoping someone with intimate knowledge of ASN.1 encodings can help
>> me out here.  Many thanks in advance.
>>
>> Currently there are three profiles before the OASIS Security Services
>> Technical Committee (SSTC) that rely on XML elements of the form:
>>
>> <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
>>  <ds:X509Data>
>>    <ds:X509Certificate>
>> MII...
>>    </ds:X509Certificate>
>>  </ds:X509Data>
>> </ds:KeyInfo>
>>
>> Interestingly, the above element has sparked a vigorous debate within
>> the SSTC, which has since spread to the W3C XML Signature WG.  The
>> issue involves the ASN.1 encoding of the underlying certificate (which
>> is base64 encoded in the XML).  Specifically, should the certificate
>> be DER-encoded or should the encoding be left unspecified?
>>
>> So my question is:  If you were given an X.509 certificate of unknown
>> encoding, could you determine the encoding by simply inspecting the
>> bytes?  Does your favorite ASN.1 library support such a function?
>>
>> Thanks for shedding some light on this issue.
>>
>> Tom Scavo
>> NCSA
> 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA6N1xps052527 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Nov 2008 16:01:59 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA6N1x1A052526; Thu, 6 Nov 2008 16:01:59 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from eb2bcom.com (eb2bcom.com [72.232.34.13]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA6N1lFG052514 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 6 Nov 2008 16:01:58 -0700 (MST) (envelope-from [e-mail])
Received: from [202.164.192.219] (helo=[192.168.99.100]) by host.eb2bcom.com with esmtpa (Exim 4.69) (envelope-from <[e-mail]>) id 1KyDrG-00069x-Lf; Fri, 07 Nov 2008 10:01:47 +1100
Message-ID: <[e-mail]>
Date: Fri, 07 Nov 2008 10:01:42 +1100
From: Steven Legg <[e-mail]>
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: Tom Scavo <[e-mail]>
CC: pkix <[e-mail]>
Subject: Re: encoding an X.509 certificate
References: <[e-mail]>	 <[e-mail]>	 <3AFA0E5E3C2F40D8BDB10F80185A69B3@AndersPC>	 <[e-mail]>	 <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - host.eb2bcom.com
X-AntiAbuse: Original Domain - imc.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - eb2bcom.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tom,

Tom Scavo wrote:
> On Thu, Nov 6, 2008 at 3:36 PM, Ben Laurie <[e-mail]> wrote:
>> Obviously the signature will only verify if it is DER encoded. So,
>> there's generally not much point in supporting other encodings.
> 
> Well, that brings up a good point, which I neglected to make clear.
> The SAML profile that makes use of the XML structure posted earlier
> does not require that the certificate in question be validated by the
> receiving party.  The certificate is merely a container for a public
> key, for which the client proves possession of the corresponding
> private key, nothing more.
> 
> If the receiving party is a SAML identity provider, the presented
> certificate is bound to a SAML assertion (using the XML structure
> posted earlier).  If the receiving party is a SAML service provider,
> the presented certificate is compared to the certificate bound to the
> SAML assertion.  So the actual encoding applied to the certificate is
> not important, except of course the identity provider and the service
> provider need to be on the same page, otherwise certificate comparison
> at the service provider will fail.
> 
> Obviously, if the identity provider is required to bind a base64
> encoding of a DER-encoded certificate, the service provider will have
> no problem (or so it seems), but there are some who are inclined not
> to specify DER explicitly, to future-proof the profile, as it were.

David Kemp already made the point that there are no "magic bits" in
an ASN.1 encoding that identify which encoding rules have been used
(though there are heuristics), so identification of the encoding needs
to be external to the encoding itself. You have two appropriate
choices when embedding an ASN.1 encoding in a protocol message:

(1) specify that one particular encoding is to be used, or

(2) provide a separate field in the protocol that identifies which
     encoding has been used.

In your case, since (I presume) there is currently no separate field
associated with <ds:X509Certificate> to identify the encoding, and it
seems everyone is assuming that the encoding is DER, you might as well
formally specify that, i.e., use option (1). If and when it becomes
necessary to allow for alternative encodings of the certificate, then
an XML attribute could be added to <ds:X509Certificate> to indicate
that an encoding other than DER has been used.

Regards,
Steven

> 
> I hope this helps to clarify.  I had hoped to avoid the details but I
> see that may not be possible.
> 
> Thanks,
> Tom
> 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA6MIbNH048671 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Nov 2008 15:18:37 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA6MIbCV048670; Thu, 6 Nov 2008 15:18:37 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [8.8.40.152]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mA6MIQbl048650 for <[e-mail]>; Thu, 6 Nov 2008 15:18:36 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Received: (qmail 15334 invoked by uid 0); 6 Nov 2008 22:18:18 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (96.255.143.189) by woodstock.binhost.com with SMTP; 6 Nov 2008 22:18:18 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Thu, 06 Nov 2008 17:18:23 -0500
To: "Tom Scavo" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: encoding an X.509 certificate
Cc: [e-mail]
In-Reply-To: <[e-mail] m>
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>

Please use DER.  If you use BER, then the recipient will have to 
decode the certificate and re-encode it with DER in order to validate 
the signature, wasting much effort.

Russ

At 12:49 PM 11/6/2008, Tom Scavo wrote:

>I've asked the following question in a number of forums with no luck.
>I'm hoping someone with intimate knowledge of ASN.1 encodings can help
>me out here.  Many thanks in advance.
>
>Currently there are three profiles before the OASIS Security Services
>Technical Committee (SSTC) that rely on XML elements of the form:
>
><ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
>  <ds:X509Data>
>    <ds:X509Certificate>
>MII...
>    </ds:X509Certificate>
>  </ds:X509Data>
></ds:KeyInfo>
>
>Interestingly, the above element has sparked a vigorous debate within
>the SSTC, which has since spread to the W3C XML Signature WG.  The
>issue involves the ASN.1 encoding of the underlying certificate (which
>is base64 encoded in the XML).  Specifically, should the certificate
>be DER-encoded or should the encoding be left unspecified?
>
>So my question is:  If you were given an X.509 certificate of unknown
>encoding, could you determine the encoding by simply inspecting the
>bytes?  Does your favorite ASN.1 library support such a function?
>
>Thanks for shedding some light on this issue.
>
>Tom Scavo
>NCSA



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA6M4w1o047302 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Nov 2008 15:04:58 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA6M4ws7047301; Thu, 6 Nov 2008 15:04:58 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pne-smtpout2-sn2.hy.skanova.net (pne-smtpout2-sn2.hy.skanova.net [81.228.8.164]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA6M4lwJ047273 for <[e-mail]>; Thu, 6 Nov 2008 15:04:57 -0700 (MST) (envelope-from [e-mail])
Received: from AndersPC (81.232.45.215) by pne-smtpout2-sn2.hy.skanova.net (7.3.129) id 4873CA9501DD8C0C; Thu, 6 Nov 2008 23:04:44 +0100
Message-ID: <DFB7DD109CC849A79272F24A1699CC9E@AndersPC>
From: "Anders Rundgren" <[e-mail]>
To: "Tom Scavo" <[e-mail]>, "Ben Laurie" <[e-mail]>
Cc: "pkix" <[e-mail]>
References: <[e-mail]> <[e-mail]> <3AFA0E5E3C2F40D8BDB10F80185A69B3@AndersPC> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: Re: encoding an X.509 certificate
Date: Thu, 6 Nov 2008 23:04:45 +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 Windows Mail 6.0.6000.20661
X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16669
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tom,
I would be very surprised if X509Certificate elements in SAML assertions (or in other XML schemes) 
would pass many implementations if they were not correctly (DER) encoded because otherwise you 
cannot really be sure that you even got the public key.

I think you can safely conclude based on the number of people responding to this request that it is 
DER and nothing else that's counts.  At least if compatibility with the existing code-base, and 
habits is wanted.

Anders
who do not even know how to do a BER, PER, CER, or XER encoded certificate

----- Original Message ----- 
From: "Tom Scavo" <[e-mail]>
To: "Ben Laurie" <[e-mail]>
Cc: "Anders Rundgren" <[e-mail]>; "pkix" <[e-mail]>
Sent: Thursday, November 06, 2008 22:38
Subject: Re: encoding an X.509 certificate


On Thu, Nov 6, 2008 at 3:36 PM, Ben Laurie <[e-mail]> wrote:
>
> Obviously the signature will only verify if it is DER encoded. So,
> there's generally not much point in supporting other encodings.

Well, that brings up a good point, which I neglected to make clear.
The SAML profile that makes use of the XML structure posted earlier
does not require that the certificate in question be validated by the
receiving party.  The certificate is merely a container for a public
key, for which the client proves possession of the corresponding
private key, nothing more.

If the receiving party is a SAML identity provider, the presented
certificate is bound to a SAML assertion (using the XML structure
posted earlier).  If the receiving party is a SAML service provider,
the presented certificate is compared to the certificate bound to the
SAML assertion.  So the actual encoding applied to the certificate is
not important, except of course the identity provider and the service
provider need to be on the same page, otherwise certificate comparison
at the service provider will fail.

Obviously, if the identity provider is required to bind a base64
encoding of a DER-encoded certificate, the service provider will have
no problem (or so it seems), but there are some who are inclined not
to specify DER explicitly, to future-proof the profile, as it were.

I hope this helps to clarify.  I had hoped to avoid the details but I
see that may not be possible.

Thanks,
Tom 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA6LcECq044748 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Nov 2008 14:38:14 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA6LcEsj044747; Thu, 6 Nov 2008 14:38:14 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yx-out-1718.google.com (yx-out-1718.google.com [74.125.44.153]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA6LcDEU044727 for <[e-mail]>; Thu, 6 Nov 2008 14:38:14 -0700 (MST) (envelope-from [e-mail])
Received: by yx-out-1718.google.com with SMTP id 36so396862yxh.4 for <[e-mail]>; Thu, 06 Nov 2008 13:38:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=yVcR467vTZbjPPVEUwtG+F/W/8IjPC9vf+6u/ZV8FYA=; b=jIXVlThbvxv6QEodL18aVb4A7DKNSKC6oWdJxlnFyUqji/VHx/p5P/Aw/DxdJP1PFy QdRE7CHgqo5pzzBP2I/DIB5yBQoq6pAhUwFK5wAxp60hECtm99ZNKHD67YvCf+ip+Aji BLNvL7XpGZZF65DEXmXmSwBOmiG8fn/aHAXaA=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=WKRYrJTk+HT/a+31LApvQgfFZu5QM4s7Z4CZB3OwKqdkDZy8i3AQLSDLb315VBj297 TGZKcozRo1E/+ZAId1a+RPBWj4iqdxeTuASYZC9DDWLGC1Y7QwoCdFyI7Psk2kF2o8mZ +h791ksn7XD9lYyZWi68TyHF1LWaRBdCVk/mk=
Received: by 10.150.228.19 with SMTP id a19mr2125064ybh.49.1226007493078; Thu, 06 Nov 2008 13:38:13 -0800 (PST)
Received: by 10.150.152.5 with HTTP; Thu, 6 Nov 2008 13:38:13 -0800 (PST)
Message-ID: <[e-mail]>
Date: Thu, 6 Nov 2008 16:38:13 -0500
From: "Tom Scavo" <[e-mail]>
To: "Ben Laurie" <[e-mail]>
Subject: Re: encoding an X.509 certificate
Cc: "Anders Rundgren" <[e-mail]>, pkix <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <[e-mail]> <[e-mail]> <3AFA0E5E3C2F40D8BDB10F80185A69B3@AndersPC> <[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>

On Thu, Nov 6, 2008 at 3:36 PM, Ben Laurie <[e-mail]> wrote:
>
> Obviously the signature will only verify if it is DER encoded. So,
> there's generally not much point in supporting other encodings.

Well, that brings up a good point, which I neglected to make clear.
The SAML profile that makes use of the XML structure posted earlier
does not require that the certificate in question be validated by the
receiving party.  The certificate is merely a container for a public
key, for which the client proves possession of the corresponding
private key, nothing more.

If the receiving party is a SAML identity provider, the presented
certificate is bound to a SAML assertion (using the XML structure
posted earlier).  If the receiving party is a SAML service provider,
the presented certificate is compared to the certificate bound to the
SAML assertion.  So the actual encoding applied to the certificate is
not important, except of course the identity provider and the service
provider need to be on the same page, otherwise certificate comparison
at the service provider will fail.

Obviously, if the identity provider is required to bind a base64
encoding of a DER-encoded certificate, the service provider will have
no problem (or so it seems), but there are some who are inclined not
to specify DER explicitly, to future-proof the profile, as it were.

I hope this helps to clarify.  I had hoped to avoid the details but I
see that may not be possible.

Thanks,
Tom



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA6LJPVK042733 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Nov 2008 14:19:25 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA6LJPZf042732; Thu, 6 Nov 2008 14:19:25 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.seguridata.com (mail.seguridata.com [201.148.141.170]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA6LJEvb042699 for <[e-mail]>; Thu, 6 Nov 2008 14:19:24 -0700 (MST) (envelope-from [e-mail])
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C94055.5D53766F"
Subject: RE: encoding an X.509 certificate
Date: Thu, 6 Nov 2008 15:19:33 -0600
Message-ID: <801F0AF0A50D1F48A1E4DA25881C1CB43C3FEE@exch-bck>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: encoding an X.509 certificate
Thread-Index: AclAPYVob7qFDPyrSpKjfhghMBSHxwABZ8IgAAPGPlM=
References: <[e-mail]> <[e-mail]> <[e-mail]>
From: "Juan Gonzalez" <[e-mail]>
To: "Kemp, David P." <[e-mail]>, "Tom Scavo" <[e-mail]>, "pkix" <[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>

This is a multi-part message in MIME format.

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

Tom:
=20
>From my pont of view, the X.509 standard assumes DER encoding for =
certificates.
=20
I'm not shure if it mandates DER, but the certificate concept is applied =
in other
standards such as ISO 9735 (EDIFACT), where a series of "segments" =
represent the serial number,
the issuer name, the validity period, the subject names, the public key =
and the signature
- including algorithms for digest and signature.
=20
In EDIFACT there are no attributes.  We have software that "converts" =
from DER encoding to
EDIFACT (using of course, aditional attributes that contain the EDIFACT =
signature and parameters)
=20
About how to distinguish a DER encoding from a Base64 encoding, you can =
analize the
first three bytes:
=20
1. If first byte is "0" (0x30) it is likely to be DER encoded (possibly =
BER/CER.  More analysis would be needed)
2. If first bytes are "MII" (0x4D, 0x49, 0x49) it is likely to be Base64 =
containing a DER/BER/CER encoded certificate
      More analysis would be needed to determine DER/BER/CER encoding
3. If first bytes are "USC" it is likely to be an EDIFACT Public Key =
(let's call it an "EDIFACT certificate")
4. If first byte were "<" (0x3c) it would be likely to be an XML encoded =
certificate (does it exist?, I don't know...)
=20
Juan
SeguriDATA

________________________________

De: [e-mail] en nombre de Kemp, David P.
Enviado el: jue 06/11/2008 01:21
Para: Tom Scavo; pkix
Asunto: RE: encoding an X.509 certificate




There is no header ("magic bits") at the beginning of an encoded
transfer string, so there is not a deterministic mechanism for
determining an arbitrary encoding.  However, heuristically it is trivial
to examine a transfer string and determine that it is a) BER/DER/CER
encoded, b) XER endoded, or c) PER encoded.  In practice, if you were
given an X.509 certificate of unknown encoding, there is only one
encoding that it could possibly be (DER) because no other encoding is
ever used.  Because the signature is computed over the DER-encoded
transfer string, a certificate in any other format would need to be
re-encoded into DER before validating the signature, and that's too much
effort for most applications.

Dave


-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Tom Scavo
Sent: Thursday, November 06, 2008 12:49 PM
To: pkix
Subject: encoding an X.509 certificate


I've asked the following question in a number of forums with no luck.
I'm hoping someone with intimate knowledge of ASN.1 encodings can help
me out here.  Many thanks in advance.

Currently there are three profiles before the OASIS Security Services
Technical Committee (SSTC) that rely on XML elements of the form:

<ds:KeyInfo xmlns:ds=3D"http://www.w3.org/2000/09/xmldsig#">
 <ds:X509Data>
   <ds:X509Certificate>
MII...
   </ds:X509Certificate>
 </ds:X509Data>
</ds:KeyInfo>

Interestingly, the above element has sparked a vigorous debate within
the SSTC, which has since spread to the W3C XML Signature WG.  The
issue involves the ASN.1 encoding of the underlying certificate (which
is base64 encoded in the XML).  Specifically, should the certificate
be DER-encoded or should the encoding be left unspecified?

So my question is:  If you were given an X.509 certificate of unknown
encoding, could you determine the encoding by simply inspecting the
bytes?  Does your favorite ASN.1 library support such a function?

Thanks for shedding some light on this issue.

Tom Scavo
NCSA




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

<HTML dir=3Dltr><HEAD><TITLE>RE: encoding an X.509 certificate</TITLE>=0A=
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dunicode">=0A=
<META content=3D"MSHTML 6.00.6001.18148" name=3DGENERATOR></HEAD>=0A=
<BODY>=0A=
<DIV id=3DidOWAReplyText32396 dir=3Dltr>=0A=
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 =
size=3D2>Tom:</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>From my pont of view, the =
X.509 standard assumes DER encoding for certificates</FONT><FONT =
face=3DArial size=3D2>.</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>I'm not shure if it mandates =
DER, but the certificate concept is applied in other</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>standards such as ISO 9735 =
(EDIFACT), where a series of&nbsp;"segments" represent the serial =
number,</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>the issuer name, the validity =
period, the subject names, the public key and the signature</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>- including algorithms for =
digest and signature.</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>In EDIFACT there are no =
attributes.&nbsp; </FONT><FONT face=3DArial size=3D2>We have software =
that "converts" from DER encoding to</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>EDIFACT (using of =
course,&nbsp;aditional attributes that </FONT><FONT face=3DArial =
size=3D2>contain the EDIFACT signature and parameters)</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>About how to distinguish a =
DER encoding from a Base64 encoding, you can analize the</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>first three =
bytes:</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>1. If first byte is "0" =
(0x30) it is likely to be DER encoded (possibly BER/CER.&nbsp; More =
analysis would be needed)</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>2. If first bytes are "MII" =
(0x4D, 0x49, 0x49) it is likely to be Base64 containing =
a&nbsp;DER/BER/CER encoded certificate</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; More analysis would be needed to =
determine DER/BER/CER encoding</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>3. If first bytes are "USC" =
it is likely to be an EDIFACT Public Key (let's call it an "EDIFACT =
certificate")</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>4. If first byte were "&lt;" =
(0x3c) it would be likely to be an XML encoded certificate (does it =
exist?, I don't know...)</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 =
size=3D2>Juan</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>SeguriDATA</FONT></DIV></DIV>=0A=
<DIV dir=3Dltr><BR>=0A=
<HR tabIndex=3D-1>=0A=
<FONT face=3DTahoma size=3D2><B>De:</B> [e-mail] en =
nombre de Kemp, David P.<BR><B>Enviado el:</B> jue 06/11/2008 =
01:21<BR><B>Para:</B> Tom Scavo; pkix<BR><B>Asunto:</B> RE: encoding an =
X.509 certificate<BR></FONT><BR></DIV>=0A=
<DIV><BR>=0A=
<P><FONT size=3D2>There is no header ("magic bits") at the beginning of =
an encoded<BR>transfer string, so there is not a deterministic mechanism =
for<BR>determining an arbitrary encoding.&nbsp; However, heuristically =
it is trivial<BR>to examine a transfer string and determine that it is =
a) BER/DER/CER<BR>encoded, b) XER endoded, or c) PER encoded.&nbsp; In =
practice, if you were<BR>given an X.509 certificate of unknown encoding, =
there is only one<BR>encoding that it could possibly be (DER) because no =
other encoding is<BR>ever used.&nbsp; Because the signature is computed =
over the DER-encoded<BR>transfer string, a certificate in any other =
format would need to be<BR>re-encoded into DER before validating the =
signature, and that's too much<BR>effort for most =
applications.<BR><BR>Dave<BR><BR><BR>-----Original Message-----<BR>From: =
[e-mail] [<A =
href=3D"mailto:[e-mail]">mailto:owner-ietf-pkix@mail.=
imc.org</A>]<BR>On Behalf Of Tom Scavo<BR>Sent: Thursday, November 06, =
2008 12:49 PM<BR>To: pkix<BR>Subject: encoding an X.509 =
certificate<BR><BR><BR>I've asked the following question in a number of =
forums with no luck.<BR>I'm hoping someone with intimate knowledge of =
ASN.1 encodings can help<BR>me out here.&nbsp; Many thanks in =
advance.<BR><BR>Currently there are three profiles before the OASIS =
Security Services<BR>Technical Committee (SSTC) that rely on XML =
elements of the form:<BR><BR>&lt;ds:KeyInfo xmlns:ds=3D"<A =
href=3D"http://www.w3.org/2000/09/xmldsig">http://www.w3.org/2000/09/xmld=
sig</A>#"&gt;<BR>&nbsp;&lt;ds:X509Data&gt;<BR>&nbsp;&nbsp; =
&lt;ds:X509Certificate&gt;<BR>MII...<BR>&nbsp;&nbsp; =
&lt;/ds:X509Certificate&gt;<BR>&nbsp;&lt;/ds:X509Data&gt;<BR>&lt;/ds:KeyI=
nfo&gt;<BR><BR>Interestingly, the above element has sparked a vigorous =
debate within<BR>the SSTC, which has since spread to the W3C XML =
Signature WG.&nbsp; The<BR>issue involves the ASN.1 encoding of the =
underlying certificate (which<BR>is base64 encoded in the XML).&nbsp; =
Specifically, should the certificate<BR>be DER-encoded or should the =
encoding be left unspecified?<BR><BR>So my question is:&nbsp; If you =
were given an X.509 certificate of unknown<BR>encoding, could you =
determine the encoding by simply inspecting the<BR>bytes?&nbsp; Does =
your favorite ASN.1 library support such a function?<BR><BR>Thanks for =
shedding some light on this issue.<BR><BR>Tom =
Scavo<BR>NCSA<BR><BR></FONT></P></DIV></BODY></HTML>
------_=_NextPart_001_01C94055.5D53766F--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA6LISHl042633 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Nov 2008 14:18:28 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA6LIStB042632; Thu, 6 Nov 2008 14:18:28 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yw-out-1718.google.com (yw-out-1718.google.com [74.125.46.156]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA6LIRF5042624 for <[e-mail]>; Thu, 6 Nov 2008 14:18:27 -0700 (MST) (envelope-from [e-mail])
Received: by yw-out-1718.google.com with SMTP id 5so394312ywr.4 for <[e-mail]>; Thu, 06 Nov 2008 13:18:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=qN5VBCixa+T7nVZfgOUVBVUgA+r+lhH5Bl8bSnYTO7Q=; b=i5Hx6A3mvKr2wySUlCIzaZc0izl28ZIKWAOskX8BZyD5RPhESyUfb6Wm3Cf4fO+b7Z 4GAMJHgsk1sr0xz8NAJohOmv27aD8NjZ0C2W2AYQvT0vJrt6MuQJAZAnjXWs7oNvYo/G diULJZ8HNzavwvBEoYgkf3cApkEI0xnW9zdrQ=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=pQaaxtssi2gllXzifJBdhu5ILh+Ov5bJ8zByj4XYURoLzQioy3ptCpVfw9OkuLlief M0SoAWBkQsv1d37vCTJywkqIIKKLqj4lQdbOCsUoeglfQFYeNKP5zdFLlAkBrDWSw0fp fabRQuPQ4LSZWhuyFYxMj8iPXoZEJSwPeBTyQ=
Received: by 10.151.83.12 with SMTP id k12mr2101857ybl.173.1226006307096; Thu, 06 Nov 2008 13:18:27 -0800 (PST)
Received: by 10.150.152.5 with HTTP; Thu, 6 Nov 2008 13:18:27 -0800 (PST)
Message-ID: <[e-mail]>
Date: Thu, 6 Nov 2008 16:18:27 -0500
From: "Tom Scavo" <[e-mail]>
To: "Ben Laurie" <[e-mail]>
Subject: Re: encoding an X.509 certificate
Cc: pkix <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <[e-mail]> <[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>

On Thu, Nov 6, 2008 at 3:34 PM, Ben Laurie <[e-mail]> wrote:
>
> Surely an X.509 certificate is, by definition, in DER?

Strictly speaking, no, that is not true (at least AFAICT).  That
appears to be true in practice, however.

Tom



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA6KuBA7040269 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Nov 2008 13:56:11 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA6KuBcT040268; Thu, 6 Nov 2008 13:56:11 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mA6Ku9MP040261 for <[e-mail]>; Thu, 6 Nov 2008 13:56:10 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 714 invoked from network); 6 Nov 2008 20:56:24 -0000
Received: from [e-mail] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;06 Nov 2008 20:56:24 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 6 Nov 2008 20:56:24 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: encoding an X.509 certificate
Date: Thu, 6 Nov 2008 15:56:08 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: encoding an X.509 certificate
Thread-Index: AclAUZKaOf4+wRWOQS6+HgQAv+br1QAAErLw
References: <[e-mail]> <[e-mail]> <[e-mail]>
From: "Santosh Chokhani" <[e-mail]>
To: "pkix" <[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 stand corrected.

Certificate and signature could be encoded ways other than DER.  But, in
order to verify the signature you need to encode the payload in DER
since the signature is computed on DER.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Ben Laurie
Sent: Thursday, November 06, 2008 3:34 PM
To: Tom Scavo
Cc: pkix
Subject: Re: encoding an X.509 certificate


Tom Scavo wrote:
> I've asked the following question in a number of forums with no luck.
> I'm hoping someone with intimate knowledge of ASN.1 encodings can help
> me out here.  Many thanks in advance.
>=20
> Currently there are three profiles before the OASIS Security Services
> Technical Committee (SSTC) that rely on XML elements of the form:
>=20
> <ds:KeyInfo xmlns:ds=3D"http://www.w3.org/2000/09/xmldsig#">
>  <ds:X509Data>
>    <ds:X509Certificate>
> MII...
>    </ds:X509Certificate>
>  </ds:X509Data>
> </ds:KeyInfo>
>=20
> Interestingly, the above element has sparked a vigorous debate within
> the SSTC, which has since spread to the W3C XML Signature WG.  The
> issue involves the ASN.1 encoding of the underlying certificate (which
> is base64 encoded in the XML).  Specifically, should the certificate
> be DER-encoded or should the encoding be left unspecified?
>=20
> So my question is:  If you were given an X.509 certificate of unknown
> encoding, could you determine the encoding by simply inspecting the
> bytes?  Does your favorite ASN.1 library support such a function?

Surely an X.509 certificate is, by definition, in DER?

Cheers,

Ben.

--=20
http://www.apache-ssl.org/ben.html           http://www.links.org/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA6KaXxS038080 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Nov 2008 13:36:33 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA6KaX5L038079; Thu, 6 Nov 2008 13:36:33 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.links.org (mail.links.org [217.155.92.109]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA6KaVCb038073 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 6 Nov 2008 13:36:32 -0700 (MST) (envelope-from [e-mail])
Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 13B2633C1E; Thu,  6 Nov 2008 20:37:59 +0000 (GMT)
Message-ID: <[e-mail]>
Date: Thu, 06 Nov 2008 20:36:23 +0000
From: Ben Laurie <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.4.0
MIME-Version: 1.0
To: Tom Scavo <[e-mail]>
CC: Anders Rundgren <[e-mail]>, pkix <[e-mail]>
Subject: Re: encoding an X.509 certificate
References: <[e-mail]>	 <[e-mail]>	 <3AFA0E5E3C2F40D8BDB10F80185A69B3@AndersPC> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset=ISO-8859-1
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>

Tom Scavo wrote:
> On Thu, Nov 6, 2008 at 2:02 PM, Anders Rundgren
> <[e-mail]> wrote:
>> It was fascinating to hear about a debate starting 7 years after the specification became finalized!
> 
> A significant observation, surely.
> 
>> I can't really tell based on the XML Dsig but it appears that the interpretation is DER
>> http://java.sun.com/j2se/1.5.0/docs/api/java/security/cert/Certificate.html#getEncoded()
>> since this is the only decoding available, in at least in standard Java.
> 
> Good point.
> 
>> Presumably other decodings are incompatible with existing libraries as well.
> 
> That is one thing I'm trying to find out, yes.

Obviously the signature will only verify if it is DER encoded. So,
there's generally not much point in supporting other encodings.

>> I would call this a de-facto standard for XML.
> 
> Thanks,
> Tom
> 
> 


-- 
http://www.apache-ssl.org/ben.html           http://www.links.org/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA6KYPNA037924 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Nov 2008 13:34:26 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA6KYPBT037923; Thu, 6 Nov 2008 13:34:25 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.links.org (mail.links.org [217.155.92.109]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA6KYDCW037901 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 6 Nov 2008 13:34:25 -0700 (MST) (envelope-from [e-mail])
Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 4950333C1E; Thu,  6 Nov 2008 20:35:39 +0000 (GMT)
Message-ID: <[e-mail]>
Date: Thu, 06 Nov 2008 20:34:03 +0000
From: Ben Laurie <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.4.0
MIME-Version: 1.0
To: Tom Scavo <[e-mail]>
CC: pkix <[e-mail]>
Subject: Re: encoding an X.509 certificate
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset=ISO-8859-1
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>

Tom Scavo wrote:
> I've asked the following question in a number of forums with no luck.
> I'm hoping someone with intimate knowledge of ASN.1 encodings can help
> me out here.  Many thanks in advance.
> 
> Currently there are three profiles before the OASIS Security Services
> Technical Committee (SSTC) that rely on XML elements of the form:
> 
> <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
>  <ds:X509Data>
>    <ds:X509Certificate>
> MII...
>    </ds:X509Certificate>
>  </ds:X509Data>
> </ds:KeyInfo>
> 
> Interestingly, the above element has sparked a vigorous debate within
> the SSTC, which has since spread to the W3C XML Signature WG.  The
> issue involves the ASN.1 encoding of the underlying certificate (which
> is base64 encoded in the XML).  Specifically, should the certificate
> be DER-encoded or should the encoding be left unspecified?
> 
> So my question is:  If you were given an X.509 certificate of unknown
> encoding, could you determine the encoding by simply inspecting the
> bytes?  Does your favorite ASN.1 library support such a function?

Surely an X.509 certificate is, by definition, in DER?

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html           http://www.links.org/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA6JZ6Tl031916 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Nov 2008 12:35:06 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA6JZ6k7031915; Thu, 6 Nov 2008 12:35:06 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mA6JZ4eb031909 for <[e-mail]>; Thu, 6 Nov 2008 12:35:05 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 32447 invoked from network); 6 Nov 2008 19:35:19 -0000
Received: from [e-mail] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;06 Nov 2008 19:35:19 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 6 Nov 2008 19:35:19 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: encoding an X.509 certificate
Date: Thu, 6 Nov 2008 14:35:03 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: encoding an X.509 certificate
Thread-Index: AclAQ9K/ieAaleWiRB+ZYNmRuxVHiwAAuvog
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Santosh Chokhani" <[e-mail]>
To: "Tom Scavo" <[e-mail]>
Cc: "pkix" <[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>

Tom,

DER

-----Original Message-----
From: Tom Scavo [mailto:[e-mail]]=20
Sent: Thursday, November 06, 2008 2:14 PM
To: Santosh Chokhani
Cc: pkix
Subject: Re: encoding an X.509 certificate

On Thu, Nov 6, 2008 at 1:52 PM, Santosh Chokhani
<[e-mail]> wrote:
> DER Vs Base 64 is not the correct trade-off.

Sorry, I didn't make that very clear.  The XML Signature spec says the
certificate is base64 encoded before it is inserted in the XML but it
says nothing about the encoding of the underlying certificate, so the
question is, what ASN.1 encoding should be applied to the certificate
before it is base64 encoded?

> An X.509 certificate is always DER encoded.

That is the answer I was looking for, yes (although not everyone seems
to agree).

> After that for transport, do you send this as binary or convert the
> binary as base 64 is the trade-off.

The certificate is always base64 encoded before it is inserted in the
XML.

Thanks!

Tom

> -----Original Message-----
> From: [e-mail]
[mailto:[e-mail]]
> On Behalf Of Tom Scavo
> Sent: Thursday, November 06, 2008 12:49 PM
> To: pkix
> Subject: encoding an X.509 certificate
>
>
> I've asked the following question in a number of forums with no luck.
> I'm hoping someone with intimate knowledge of ASN.1 encodings can help
> me out here.  Many thanks in advance.
>
> Currently there are three profiles before the OASIS Security Services
> Technical Committee (SSTC) that rely on XML elements of the form:
>
> <ds:KeyInfo xmlns:ds=3D"http://www.w3.org/2000/09/xmldsig#">
>  <ds:X509Data>
>   <ds:X509Certificate>
> MII...
>   </ds:X509Certificate>
>  </ds:X509Data>
> </ds:KeyInfo>
>
> Interestingly, the above element has sparked a vigorous debate within
> the SSTC, which has since spread to the W3C XML Signature WG.  The
> issue involves the ASN.1 encoding of the underlying certificate (which
> is base64 encoded in the XML).  Specifically, should the certificate
> be DER-encoded or should the encoding be left unspecified?
>
> So my question is:  If you were given an X.509 certificate of unknown
> encoding, could you determine the encoding by simply inspecting the
> bytes?  Does your favorite ASN.1 library support such a function?
>
> Thanks for shedding some light on this issue.
>
> Tom Scavo
> NCSA
>
>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA6JPCZd031054 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Nov 2008 12:25:12 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA6JPCZJ031053; Thu, 6 Nov 2008 12:25:12 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yx-out-1718.google.com (yx-out-1718.google.com [74.125.44.153]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA6JP0kA031030 for <[e-mail]>; Thu, 6 Nov 2008 12:25:11 -0700 (MST) (envelope-from [e-mail])
Received: by yx-out-1718.google.com with SMTP id 36so366116yxh.4 for <[e-mail]>; Thu, 06 Nov 2008 11:25:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=vpsS0lMJM2CKUfWzM1zYEtsq/u4/2BSYM+kqoUz7Sw8=; b=BifTDnp+lkU023ZJdbdJ9/rHOJGSBS4y3D29rYnnTs4Z3+V6qOR6n0411UyMlCtn5c ixvTpTVF3L9OUHAmjw8DESfih12uqTIS+hoS5D/pr0szia7OsQG479byVX5NBhx0/Ag3 adbXk0f4+8vgxLg16PbGigC2huShwQTamx5aw=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=WncYeIz287byN+7/40LBhTQWjec3Y8fcnXq1nerd80JNrPM+aU9Peu6n0VTTziVpN7 tUK/6Pzr11b8lVExyohIOPYT80hUoIXa7Uw5ZsDW99MrSLQHzKZUWCX9V7TkrUX6xPE+ gmBI33/DPG3TjYR8M7u+nsNX2yqOHGWRjRa5k=
Received: by 10.150.181.7 with SMTP id d7mr1932985ybf.83.1225999500359; Thu, 06 Nov 2008 11:25:00 -0800 (PST)
Received: by 10.150.152.5 with HTTP; Thu, 6 Nov 2008 11:25:00 -0800 (PST)
Message-ID: <[e-mail]>
Date: Thu, 6 Nov 2008 14:25:00 -0500
From: "Tom Scavo" <[e-mail]>
To: "Anders Rundgren" <[e-mail]>
Subject: Re: encoding an X.509 certificate
Cc: pkix <[e-mail]>
In-Reply-To: <3AFA0E5E3C2F40D8BDB10F80185A69B3@AndersPC>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <[e-mail]> <[e-mail]> <3AFA0E5E3C2F40D8BDB10F80185A69B3@AndersPC>
Sender: [e-mail]
Precedence: 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 Thu, Nov 6, 2008 at 2:02 PM, Anders Rundgren
<[e-mail]> wrote:
>
> It was fascinating to hear about a debate starting 7 years after the specification became finalized!

A significant observation, surely.

> I can't really tell based on the XML Dsig but it appears that the interpretation is DER
> http://java.sun.com/j2se/1.5.0/docs/api/java/security/cert/Certificate.html#getEncoded()
> since this is the only decoding available, in at least in standard Java.

Good point.

> Presumably other decodings are incompatible with existing libraries as well.

That is one thing I'm trying to find out, yes.

> I would call this a de-facto standard for XML.

Thanks,
Tom



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA6JLYRT030732 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Nov 2008 12:21:34 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA6JLYFX030731; Thu, 6 Nov 2008 12:21:34 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.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 balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA6JLNOY030713 for <[e-mail]>; Thu, 6 Nov 2008 12:21:33 -0700 (MST) (envelope-from [e-mail])
Received: from Augustine.missi.ncsc.mil (augustine.missi.ncsc.mil [144.51.60.33]) by stingray.missi.ncsc.mil with ESMTP id mA6JLMx6001049; Thu, 6 Nov 2008 14:21:22 -0500 (EST)
Received: from DABECK.missi.ncsc.mil ([144.51.60.15]) by Augustine.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Nov 2008 14:19:12 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: encoding an X.509 certificate
Date: Thu, 6 Nov 2008 14:21:19 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: encoding an X.509 certificate
Thread-Index: AclAPYVob7qFDPyrSpKjfhghMBSHxwABZ8Ig
References: <[e-mail]> <[e-mail]>
From: "Kemp, David P." <[e-mail]>
To: "Tom Scavo" <[e-mail]>, "pkix" <[e-mail]>
X-OriginalArrivalTime: 06 Nov 2008 19:19:12.0687 (UTC) FILETIME=[8D270BF0:01C94044]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

There is no header ("magic bits") at the beginning of an encoded
transfer string, so there is not a deterministic mechanism for
determining an arbitrary encoding.  However, heuristically it is trivial
to examine a transfer string and determine that it is a) BER/DER/CER
encoded, b) XER endoded, or c) PER encoded.  In practice, if you were
given an X.509 certificate of unknown encoding, there is only one
encoding that it could possibly be (DER) because no other encoding is
ever used.  Because the signature is computed over the DER-encoded
transfer string, a certificate in any other format would need to be
re-encoded into DER before validating the signature, and that's too much
effort for most applications.

Dave


-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Tom Scavo
Sent: Thursday, November 06, 2008 12:49 PM
To: pkix
Subject: encoding an X.509 certificate


I've asked the following question in a number of forums with no luck.
I'm hoping someone with intimate knowledge of ASN.1 encodings can help
me out here.  Many thanks in advance.

Currently there are three profiles before the OASIS Security Services
Technical Committee (SSTC) that rely on XML elements of the form:

<ds:KeyInfo xmlns:ds=3D"http://www.w3.org/2000/09/xmldsig#">
 <ds:X509Data>
   <ds:X509Certificate>
MII...
   </ds:X509Certificate>
 </ds:X509Data>
</ds:KeyInfo>

Interestingly, the above element has sparked a vigorous debate within
the SSTC, which has since spread to the W3C XML Signature WG.  The
issue involves the ASN.1 encoding of the underlying certificate (which
is base64 encoded in the XML).  Specifically, should the certificate
be DER-encoded or should the encoding be left unspecified?

So my question is:  If you were given an X.509 certificate of unknown
encoding, could you determine the encoding by simply inspecting the
bytes?  Does your favorite ASN.1 library support such a function?

Thanks for shedding some light on this issue.

Tom Scavo
NCSA



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA6JE9SA030091 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Nov 2008 12:14:10 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA6JE9rI030090; Thu, 6 Nov 2008 12:14:09 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from el-out-1112.google.com (el-out-1112.google.com [209.85.162.180]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA6JDwfG030068 for <[e-mail]>; Thu, 6 Nov 2008 12:14:09 -0700 (MST) (envelope-from [e-mail])
Received: by el-out-1112.google.com with SMTP id v27so399929ele.13 for <[e-mail]>; Thu, 06 Nov 2008 11:13:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=OJ+qUPKq77VnQAQwODbEs9vkJjWHO3d5dKOu6QSmYlY=; b=sHau7O0ohbV4IALxGZcDYD7Yjux5KQyM8lQyqbZCcdzptVjnVED6mVLcdCZZ9Yi9Xx lyld5r19ZmsNvfdNV4drU2zg5Oy0fGmceGJW5qkNsT5miA5BBGIQ7OJmYXMaV8FVRkFP 8AsqXo7viEFOE+idPjTv1+O6eNgfkWoUtrfu4=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=ub2ABUFGXCA/GD8da4b2twuqXwgqJXpBJu1siS0t1v6zFbcKgpxLmc/6V3IAd9xnyX vLwHsW9lMXjafCKAKVK1FgF3fwCimuwhcxDZRbnH7Fmic3LegwZN7duc/MAuMJoC5H5z LFtk4gvxXA3Yo90zjcxiSEc5ymPWAhBirioM0=
Received: by 10.150.155.13 with SMTP id c13mr1914217ybe.136.1225998838060; Thu, 06 Nov 2008 11:13:58 -0800 (PST)
Received: by 10.150.152.5 with HTTP; Thu, 6 Nov 2008 11:13:58 -0800 (PST)
Message-ID: <[e-mail]>
Date: Thu, 6 Nov 2008 14:13:58 -0500
From: "Tom Scavo" <[e-mail]>
To: "Santosh Chokhani" <[e-mail]>
Subject: Re: encoding an X.509 certificate
Cc: pkix <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <[e-mail]> <[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>

On Thu, Nov 6, 2008 at 1:52 PM, Santosh Chokhani <[e-mail]> wrote:
> DER Vs Base 64 is not the correct trade-off.

Sorry, I didn't make that very clear.  The XML Signature spec says the
certificate is base64 encoded before it is inserted in the XML but it
says nothing about the encoding of the underlying certificate, so the
question is, what ASN.1 encoding should be applied to the certificate
before it is base64 encoded?

> An X.509 certificate is always DER encoded.

That is the answer I was looking for, yes (although not everyone seems
to agree).

> After that for transport, do you send this as binary or convert the
> binary as base 64 is the trade-off.

The certificate is always base64 encoded before it is inserted in the XML.

Thanks!

Tom

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> On Behalf Of Tom Scavo
> Sent: Thursday, November 06, 2008 12:49 PM
> To: pkix
> Subject: encoding an X.509 certificate
>
>
> I've asked the following question in a number of forums with no luck.
> I'm hoping someone with intimate knowledge of ASN.1 encodings can help
> me out here.  Many thanks in advance.
>
> Currently there are three profiles before the OASIS Security Services
> Technical Committee (SSTC) that rely on XML elements of the form:
>
> <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
>  <ds:X509Data>
>   <ds:X509Certificate>
> MII...
>   </ds:X509Certificate>
>  </ds:X509Data>
> </ds:KeyInfo>
>
> Interestingly, the above element has sparked a vigorous debate within
> the SSTC, which has since spread to the W3C XML Signature WG.  The
> issue involves the ASN.1 encoding of the underlying certificate (which
> is base64 encoded in the XML).  Specifically, should the certificate
> be DER-encoded or should the encoding be left unspecified?
>
> So my question is:  If you were given an X.509 certificate of unknown
> encoding, could you determine the encoding by simply inspecting the
> bytes?  Does your favorite ASN.1 library support such a function?
>
> Thanks for shedding some light on this issue.
>
> Tom Scavo
> NCSA
>
>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA6J5phq029057 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Nov 2008 12:05:51 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA6J5pl9029055; Thu, 6 Nov 2008 12:05:51 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA6J5cB3029042 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for <[e-mail]>; Thu, 6 Nov 2008 12:05:49 -0700 (MST) (envelope-from [e-mail])
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=[e-mail]; q=dns/txt; s=qcdkim; t=1225998349; x=1257534349; h=from:to:date:subject:thread-topic:thread-index: message-id:in-reply-to:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:acceptlanguage: content-type:content-transfer-encoding:mime-version: x-ironport-av; z=From:=20"Perez,=20Aram"=20<[e-mail]>|To:=20PKI X=20<[e-mail]>|Date:=20Thu,=206=20Nov=202008=201 1:05:35=20-0800|Subject:=20Re:=20encoding=20an=20X.509=20 certificate|Thread-Topic:=20encoding=20an=20X.509=20certi ficate|Thread-Index:=20AclAPwS3iyvJirVVSQCi4mwrvLGfnwAA6E Oh|Message-ID:=20<[e-mail]> |In-Reply-To:=20<ea2af9bd0811060949t2462d9fdk93758a3e0935 [e-mail]>|Accept-Language:=20en-US |Content-Language:=20en|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"iso-8859-1" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5425"=3B=20a=3D"12162228"; bh=Vgehnfxw5jkEU+X9zxXBOMmAg0eFE7e+YasFyB1laGM=; b=TyM5JZUeUPpJlWn8m0D1/Tz1Ff4D1qP+2iGOhxRSRb/wvgjbQlGQtaLt 9s/LTJumjltvrWSrKXlTcNcjfL7Sz3UYEkeIIdwB6Wws2Xa5D9Ox6fV/y XHDTo/D//Udy0Vd23r7goBb0LFzdWUFEnGvztiQTelOjKEtiKHVZtatTR A=;
X-IronPort-AV: E=McAfee;i="5300,2777,5425"; a="12162228"
Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Nov 2008 11:05:38 -0800
Received: from msgtransport03.qualcomm.com (msgtransport03.qualcomm.com [129.46.61.154]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id mA6J5cnI024587 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Thu, 6 Nov 2008 11:05:38 -0800
Received: from nasanexhc03.na.qualcomm.com (nasanexhc03.na.qualcomm.com [172.30.33.34]) by msgtransport03.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id mA6J5bYu003970 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for <[e-mail]>; Thu, 6 Nov 2008 11:05:37 -0800
Received: from nasanexhub04.na.qualcomm.com (129.46.134.222) by nasanexhc03.na.qualcomm.com (172.30.33.34) with Microsoft SMTP Server (TLS) id 8.1.311.2; Thu, 6 Nov 2008 11:05:37 -0800
Received: from NASANEXMB05.na.qualcomm.com ([129.46.52.178]) by nasanexhub04.na.qualcomm.com ([129.46.134.222]) with mapi; Thu, 6 Nov 2008 11:05:36 -0800
From: "Perez, Aram" <[e-mail]>
To: PKIX <[e-mail]>
Date: Thu, 6 Nov 2008 11:05:35 -0800
Subject: Re: encoding an X.509 certificate
Thread-Topic: encoding an X.509 certificate
Thread-Index: AclAPwS3iyvJirVVSQCi4mwrvLGfnwAA6EOh
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
Accept-Language: en-US
Content-Language: en
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
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>

Hi Tom,

On 11/6/08 9:49 AM, you wrote:

> I've asked the following question in a number of forums with no luck.
> I'm hoping someone with intimate knowledge of ASN.1 encodings can help
> me out here.  Many thanks in advance.
>=20
> Currently there are three profiles before the OASIS Security Services
> Technical Committee (SSTC) that rely on XML elements of the form:
>=20
> <ds:KeyInfo xmlns:ds=3D"http://www.w3.org/2000/09/xmldsig#">
>  <ds:X509Data>
>    <ds:X509Certificate>
> MII...
>    </ds:X509Certificate>
>  </ds:X509Data>
> </ds:KeyInfo>
>=20
> Interestingly, the above element has sparked a vigorous debate within
> the SSTC, which has since spread to the W3C XML Signature WG.  The
> issue involves the ASN.1 encoding of the underlying certificate (which
> is base64 encoded in the XML).  Specifically, should the certificate
> be DER-encoded or should the encoding be left unspecified?

RFCs 3280 and 5280 clearly state in section 4.1: "The X.509 v3 certificate
basic syntax is as follows.  For signature calculation, the data that is to
be signed is encoded using the ASN.1 distinguished encoding rules (DER)
[X.690].  ASN.1 DER encoding is a tag, length, value encoding system for
each element."

> So my question is:  If you were given an X.509 certificate of unknown
> encoding, could you determine the encoding by simply inspecting the
> bytes?=20

I've never seen an X.509 certificate that is not DER encoded but I'm sure I
may have miss those encoded differently.

> Does your favorite ASN.1 library support such a function?

My BERViewer application (<http://homepage.mac.com/aramperez>) will display
any BER/DER encoded file but it does not tell you the encoding. May Peter
Gutmann's dumpasn1 (<http://www.cs.auckland.ac.nz/~pgut001/dumpasn1.c>)
does.

Regards,
Aram Perez



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA6J2HQj028836 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Nov 2008 12:02:17 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA6J2HPW028835; Thu, 6 Nov 2008 12:02:17 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pne-smtpout1-sn2.hy.skanova.net (pne-smtpout1-sn2.hy.skanova.net [81.228.8.83]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA6J26xJ028821 for <[e-mail]>; Thu, 6 Nov 2008 12:02:17 -0700 (MST) (envelope-from [e-mail])
Received: from AndersPC (81.232.45.215) by pne-smtpout1-sn2.hy.skanova.net (7.3.129) id 48A144C501712511; Thu, 6 Nov 2008 20:02:04 +0100
Message-ID: <3AFA0E5E3C2F40D8BDB10F80185A69B3@AndersPC>
From: "Anders Rundgren" <[e-mail]>
To: "Tom Scavo" <[e-mail]>, "pkix" <[e-mail]>
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: Re: encoding an X.509 certificate
Date: Thu, 6 Nov 2008 20:02:05 +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 Windows Mail 6.0.6000.20661
X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16669
Sender: [e-mail]
Precedence: 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 Tom,

It was fascinating to hear about a debate starting 7 years after the specification became finalized!

I can't really tell based on the XML Dsig but it appears that the interpretation is DER
http://java.sun.com/j2se/1.5.0/docs/api/java/security/cert/Certificate.html#getEncoded()
since this is the only decoding available, in at least in standard Java.

Presumably other decodings are incompatible with existing libraries as well.

I would call this a de-facto standard for XML.

Regards
Anders

----- Original Message ----- 
From: "Tom Scavo" <[e-mail]>
To: "pkix" <[e-mail]>
Sent: Thursday, November 06, 2008 18:49
Subject: encoding an X.509 certificate



I've asked the following question in a number of forums with no luck.
I'm hoping someone with intimate knowledge of ASN.1 encodings can help
me out here.  Many thanks in advance.

Currently there are three profiles before the OASIS Security Services
Technical Committee (SSTC) that rely on XML elements of the form:

<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
 <ds:X509Data>
   <ds:X509Certificate>
MII...
   </ds:X509Certificate>
 </ds:X509Data>
</ds:KeyInfo>

Interestingly, the above element has sparked a vigorous debate within
the SSTC, which has since spread to the W3C XML Signature WG.  The
issue involves the ASN.1 encoding of the underlying certificate (which
is base64 encoded in the XML).  Specifically, should the certificate
be DER-encoded or should the encoding be left unspecified?

So my question is:  If you were given an X.509 certificate of unknown
encoding, could you determine the encoding by simply inspecting the
bytes?  Does your favorite ASN.1 library support such a function?

Thanks for shedding some light on this issue.

Tom Scavo
NCSA



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA6IrEd9028179 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Nov 2008 11:53:14 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA6IrEnk028178; Thu, 6 Nov 2008 11:53:14 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mA6Ir30b028150 for <[e-mail]>; Thu, 6 Nov 2008 11:53:13 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 32053 invoked from network); 6 Nov 2008 18:53:02 -0000
Received: from [e-mail] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;06 Nov 2008 18:53:02 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 6 Nov 2008 18:53:02 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: encoding an X.509 certificate
Date: Thu, 6 Nov 2008 13:52:46 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: encoding an X.509 certificate
Thread-Index: AclAOpXidvPkNNTDQq+NyBP1xV5MeQABgs4w
References: <[e-mail]> <[e-mail]>
From: "Santosh Chokhani" <[e-mail]>
To: "Tom Scavo" <[e-mail]>, "pkix" <[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>

DER Vs Base 64 is not the correct trade-off.

An X.509 certificate is always DER encoded.

After that for transport, do you send this as binary or convert the
binary as base 64 is the trade-off.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Tom Scavo
Sent: Thursday, November 06, 2008 12:49 PM
To: pkix
Subject: encoding an X.509 certificate


I've asked the following question in a number of forums with no luck.
I'm hoping someone with intimate knowledge of ASN.1 encodings can help
me out here.  Many thanks in advance.

Currently there are three profiles before the OASIS Security Services
Technical Committee (SSTC) that rely on XML elements of the form:

<ds:KeyInfo xmlns:ds=3D"http://www.w3.org/2000/09/xmldsig#">
 <ds:X509Data>
   <ds:X509Certificate>
MII...
   </ds:X509Certificate>
 </ds:X509Data>
</ds:KeyInfo>

Interestingly, the above element has sparked a vigorous debate within
the SSTC, which has since spread to the W3C XML Signature WG.  The
issue involves the ASN.1 encoding of the underlying certificate (which
is base64 encoded in the XML).  Specifically, should the certificate
be DER-encoded or should the encoding be left unspecified?

So my question is:  If you were given an X.509 certificate of unknown
encoding, could you determine the encoding by simply inspecting the
bytes?  Does your favorite ASN.1 library support such a function?

Thanks for shedding some light on this issue.

Tom Scavo
NCSA



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA6HnMxh022415 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Nov 2008 10:49:22 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA6HnM1n022414; Thu, 6 Nov 2008 10:49:22 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rn-out-0910.google.com (rn-out-0910.google.com [64.233.170.188]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA6HnBBf022402 for <[e-mail]>; Thu, 6 Nov 2008 10:49:21 -0700 (MST) (envelope-from [e-mail])
Received: by rn-out-0910.google.com with SMTP id m7so611779rnd.3 for <[e-mail]>; Thu, 06 Nov 2008 09:49:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=hsFbyvJ/ofHHt7s/wDRnTKrj2+kh/oHwaF3E/svtQfo=; b=R0CMGizc1TnV5cf5Sa8/YHcdgOGZhmPkyud6t+4mwe7EmrW++PRH6ijxtNYuJv6y6W QxdOjhEihMQffDhBhS9QeERFRHLYD+wNl2Fum6WB2xjS7otirueI/INhWWiWREJrJqsg dnGWb8+DGoCQAihdf31PMBV60qKB283VN+ECo=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=BQ/LM8GIvczW8mD8X817Wt6+egce5vAuSbhsvdBO4SfPhh9khCe85QS4KaUA2Tsj0E M5jDNPt9ygHU5rCZ4teC19kuouegOFqliF1OrdeOOxAQuFkpW+b2cRzl5KOVpKEU4jDD BTS1aSQ9HlUezPfAQt3ONvldwzL0/J16mGPjc=
Received: by 10.151.110.14 with SMTP id n14mr1778033ybm.155.1225993750762; Thu, 06 Nov 2008 09:49:10 -0800 (PST)
Received: by 10.150.152.5 with HTTP; Thu, 6 Nov 2008 09:49:10 -0800 (PST)
Message-ID: <[e-mail]>
Date: Thu, 6 Nov 2008 12:49:10 -0500
From: "Tom Scavo" <[e-mail]>
To: pkix <[e-mail]>
Subject: encoding an X.509 certificate
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <[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 asked the following question in a number of forums with no luck.
I'm hoping someone with intimate knowledge of ASN.1 encodings can help
me out here.  Many thanks in advance.

Currently there are three profiles before the OASIS Security Services
Technical Committee (SSTC) that rely on XML elements of the form:

<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
 <ds:X509Data>
   <ds:X509Certificate>
MII...
   </ds:X509Certificate>
 </ds:X509Data>
</ds:KeyInfo>

Interestingly, the above element has sparked a vigorous debate within
the SSTC, which has since spread to the W3C XML Signature WG.  The
issue involves the ASN.1 encoding of the underlying certificate (which
is base64 encoded in the XML).  Specifically, should the certificate
be DER-encoded or should the encoding be left unspecified?

So my question is:  If you were given an X.509 certificate of unknown
encoding, could you determine the encoding by simply inspecting the
bytes?  Does your favorite ASN.1 library support such a function?

Thanks for shedding some light on this issue.

Tom Scavo
NCSA



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA6B5EHO081201 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Nov 2008 04:05:14 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA6B5Dv4081200; Thu, 6 Nov 2008 04:05:13 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-dub.microsoft.com (smtp-dub.microsoft.com [213.199.138.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA6B50QM081181 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Thu, 6 Nov 2008 04:05:11 -0700 (MST) (envelope-from [e-mail])
Received: from dub-exhub-c302.europe.corp.microsoft.com (65.53.213.92) by DUB-EXGWY-E801.partners.extranet.microsoft.com (10.251.129.1) with Microsoft SMTP Server (TLS) id 8.1.291.1; Thu, 6 Nov 2008 11:04:59 +0000
Received: from EA-EXMSG-C332.europe.corp.microsoft.com ([169.254.2.235]) by DUB-EXHUB-C302.europe.corp.microsoft.com ([65.53.213.92]) with mapi; Thu, 6 Nov 2008 11:04:59 +0000
From: Stefan Santesson <[e-mail]>
To: Stefan Santesson <[e-mail]>, pkix <[e-mail]>
Date: Thu, 6 Nov 2008 11:04:57 +0000
Subject: RE: FINAL CALL: Call for agenda items, Minneapolis IETF
Thread-Topic: FINAL CALL: Call for agenda items, Minneapolis IETF
Thread-Index: Achz4rCMDGHAmfpxQ526+JqfDUXcDzLgnTnwACaLs+A=
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_9F11911AED01D24BAA1C2355723C3D32195ACDA1F6EAEXMSGC332eu_"
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>

--_000_9F11911AED01D24BAA1C2355723C3D32195ACDA1F6EAEXMSGC332eu_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Yeah, we are going to Minneapolis...

No need for any more private e-mails to me pointing that out :)


Stefan Santesson
Senior Program Manager
Windows Security, Standards

From: [e-mail] [mailto:[e-mail]] On=
 Behalf Of Stefan Santesson
Sent: den 5 november 2008 17:52
To: pkix
Subject: FINAL CALL: Call for agenda items, Philadelphia IETF

I have timeslot requests for the following PKIX work items:

*         Trust Anchor Management

*         Other certs extension

*         Clearance attribute and CA clearance constraints

*         PKI resource query protocol

*         RFC3281 updates

I still lack information if any editor wants to address the following WG it=
ems:

*         ECC Subject public key info

*         RFC 4055 update

*         New ASN.1 modules for PKIX

*         Algorithm identifiers for SHA2

*         Traceable anonymous certificates

I have no requests for additional topics.


REQUIRED ACTIONS:
Can someone from each lacking WG item please let me know if you want any ti=
me slot.
We are also still open for other potential topics on the agenda.
But I need all requests by the end of this week.

Thank you.


Stefan Santesson
Senior Program Manager
Windows Security, Standards

From: [e-mail] [mailto:[e-mail]] On=
 Behalf Of Stefan Santesson
Sent: den 20 februari 2008 18:05
To: pkix
Subject: Call for agenda items, Philadelphia IETF

Time to set the agenda for the Philadelphia PKIX meeting.

Anyone wanting a slot should send me an e-mail as soon as possible, no late=
r than EOD Wednesday next week (Feb 27).
As usual I want the lead editor for every current pkix draft to tell me if =
they want a slot or not.

We are currently scheduled as a Monday morning session from 0900-1130, whic=
h means two things.
1) We have 2.5 hours available which should be plenty of time.
2) We need to have everything set, including presentations sent to me by Su=
nday night.


Stefan Santesson
Senior Program Manager
Windows Security, Standards


--_000_9F11911AED01D24BAA1C2355723C3D32195ACDA1F6EAEXMSGC332eu_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:p=3D"urn:schemas-m=
icrosoft-com:office:powerpoint" xmlns:a=3D"urn:schemas-microsoft-com:office=
:access" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s=3D"=
uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs=3D"urn:schemas-microsof=
t-com:rowset" xmlns:z=3D"#RowsetSchema" xmlns:b=3D"urn:schemas-microsoft-co=
m:office:publisher" xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadshee=
t" xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns=
:odc=3D"urn:schemas-microsoft-com:office:odc" xmlns:oa=3D"urn:schemas-micro=
soft-com:office:activation" xmlns:html=3D"http://www.w3.org/TR/REC-html40" =
xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:D=3D"DAV:" xmln=
s:x2=3D"http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ois=3D"ht=
tp://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir=3D"http://schema=
s.microsoft.com/sharepoint/soap/directory/" xmlns:ds=3D"http://www.w3.org/2=
000/09/xmldsig#" xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint/dsp" =
xmlns:udc=3D"http://schemas.microsoft.com/data/udc" xmlns:xsd=3D"http://www=
.w3.org/2001/XMLSchema" xmlns:sub=3D"http://schemas.microsoft.com/sharepoin=
t/soap/2002/1/alerts/" xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#" xmlns=
:sp=3D"http://schemas.microsoft.com/sharepoint/" xmlns:sps=3D"http://schema=
s.microsoft.com/sharepoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001/XMLSc=
hema-instance" xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile=
" xmlns:wf=3D"http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns=
:mver=3D"http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns=
:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns:mrels=3D"http=
://schemas.openxmlformats.org/package/2006/relationships" xmlns:ex12t=3D"ht=
tp://schemas.microsoft.com/exchange/services/2006/types" xmlns:ex12m=3D"htt=
p://schemas.microsoft.com/exchange/services/2006/messages" xmlns:Z=3D"urn:s=
chemas-microsoft-com:" xmlns:st=3D"&#1;" 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=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:"\@SimSun";
	panose-1:2 1 6 0 3 1 1 1 1 1;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
	{mso-style-priority:34;
	margin-top:0cm;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:36.0pt;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
span.EmailStyle18
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.EmailStyle19
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle20
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 @list l0
	{mso-list-id:1027682776;
	mso-list-type:hybrid;
	mso-list-template-ids:-1317393742 69009409 69009411 69009413 69009409 6900=
9411 69009413 69009409 69009411 69009413;}
@list l0:level1
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	font-family:Symbol;}
@list l0:level2
	{mso-level-tab-stop:72.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level3
	{mso-level-tab-stop:108.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level4
	{mso-level-tab-stop:144.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level5
	{mso-level-tab-stop:180.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level6
	{mso-level-tab-stop:216.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level7
	{mso-level-tab-stop:252.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level8
	{mso-level-tab-stop:288.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level9
	{mso-level-tab-stop:324.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l1
	{mso-list-id:1397900729;
	mso-list-type:hybrid;
	mso-list-template-ids:635612220 69009409 69009411 69009413 69009409 690094=
11 69009413 69009409 69009411 69009413;}
@list l1:level1
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	font-family:Symbol;}
@list l1:level2
	{mso-level-tab-stop:72.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l1:level3
	{mso-level-tab-stop:108.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l1:level4
	{mso-level-tab-stop:144.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l1:level5
	{mso-level-tab-stop:180.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l1:level6
	{mso-level-tab-stop:216.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l1:level7
	{mso-level-tab-stop:252.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l1:level8
	{mso-level-tab-stop:288.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l1:level9
	{mso-level-tab-stop:324.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
ol
	{margin-bottom:0cm;}
ul
	{margin-bottom:0cm;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DSV link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><a name=3D"_MailEndCompose"><span lang=3DEN-US style=
=3D'color:
#1F497D'>Yeah, we are going to Minneapolis&#8230;<o:p></o:p></span></a></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'><o:p>&nbsp;=
</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'>No need for=
 any more
private e-mails to me pointing that out </span><span lang=3DEN-US
style=3D'font-family:Wingdings;color:#1F497D'>J</span><span lang=3DEN-US
style=3D'color:#1F497D'><o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'><o:p>&nbsp;=
</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'><o:p>&nbsp;=
</o:p></span></p>

<div>

<p class=3DMsoNormal><b><span lang=3DEN-GB style=3D'font-size:10.0pt;font-f=
amily:
"Arial","sans-serif";color:maroon'>Stefan Santesson</span></b><span lang=3D=
EN-GB
style=3D'font-size:12.0pt;font-family:"Times New Roman","serif";color:#1F49=
7D'><o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-GB style=3D'font-size:10.0pt;font-fami=
ly:"Arial","sans-serif";
color:#400040'>Senior Program Manager</span><span lang=3DEN-GB style=3D'fon=
t-size:
12.0pt;font-family:"Times New Roman","serif";color:navy'><o:p></o:p></span>=
</p>

<p class=3DMsoNormal><b><span lang=3DEN-GB style=3D'font-size:10.0pt;font-f=
amily:
"Arial","sans-serif";color:#400040'>Windows Security, Standards</span></b><=
span
lang=3DEN-US style=3D'color:#1F497D'><o:p></o:p></span></p>

</div>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'><o:p>&nbsp;=
</o:p></span></p>

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

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm =
0cm 0cm'>

<p class=3DMsoNormal><b><span lang=3DEN-US style=3D'font-size:10.0pt;font-f=
amily:
"Tahoma","sans-serif"'>From:</span></b><span lang=3DEN-US style=3D'font-siz=
e:10.0pt;
font-family:"Tahoma","sans-serif"'> [e-mail]
[mailto:[e-mail]] <b>On Behalf Of </b>Stefan Santesson<=
br>
<b>Sent:</b> den 5 november 2008 17:52<br>
<b>To:</b> pkix<br>
<b>Subject:</b> FINAL CALL: Call for agenda items, Philadelphia IETF<o:p></=
o:p></span></p>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'>I have time=
slot
requests for the following PKIX work items:<o:p></o:p></span></p>

<p class=3DMsoListParagraph style=3D'text-indent:-18.0pt;mso-list:l1 level1=
 lfo2'><![if !supportLists]><span
lang=3DEN-US style=3D'font-family:Symbol;color:#1F497D'><span style=3D'mso-=
list:Ignore'>&middot;<span
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;
</span></span></span><![endif]><span lang=3DEN-US style=3D'color:#1F497D'>T=
rust
Anchor Management<o:p></o:p></span></p>

<p class=3DMsoListParagraph style=3D'text-indent:-18.0pt;mso-list:l1 level1=
 lfo2'><![if !supportLists]><span
lang=3DEN-US style=3D'font-family:Symbol;color:#1F497D'><span style=3D'mso-=
list:Ignore'>&middot;<span
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;
</span></span></span><![endif]><span lang=3DEN-US style=3D'color:#1F497D'>O=
ther
certs extension<o:p></o:p></span></p>

<p class=3DMsoListParagraph style=3D'text-indent:-18.0pt;mso-list:l1 level1=
 lfo2'><![if !supportLists]><span
lang=3DEN-US style=3D'font-family:Symbol;color:#1F497D'><span style=3D'mso-=
list:Ignore'>&middot;<span
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;
</span></span></span><![endif]><span lang=3DEN-US style=3D'color:#1F497D'>C=
learance
attribute and CA clearance constraints<o:p></o:p></span></p>

<p class=3DMsoListParagraph style=3D'text-indent:-18.0pt;mso-list:l1 level1=
 lfo2'><![if !supportLists]><span
lang=3DEN-US style=3D'font-family:Symbol;color:#1F497D'><span style=3D'mso-=
list:Ignore'>&middot;<span
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;
</span></span></span><![endif]><span lang=3DEN-US style=3D'color:#1F497D'>P=
KI
resource query protocol<o:p></o:p></span></p>

<p class=3DMsoListParagraph style=3D'text-indent:-18.0pt;mso-list:l1 level1=
 lfo2'><![if !supportLists]><span
lang=3DEN-US style=3D'font-family:Symbol;color:#1F497D'><span style=3D'mso-=
list:Ignore'>&middot;<span
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;
</span></span></span><![endif]><span lang=3DEN-US style=3D'color:#1F497D'>R=
FC3281 updates<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'><o:p>&nbsp;=
</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'>I still lac=
k
information if any editor wants to address the following WG items:<o:p></o:=
p></span></p>

<p class=3DMsoListParagraph style=3D'text-indent:-18.0pt;mso-list:l0 level1=
 lfo4'><![if !supportLists]><span
lang=3DEN-US style=3D'font-family:Symbol;color:#1F497D'><span style=3D'mso-=
list:Ignore'>&middot;<span
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;
</span></span></span><![endif]><span lang=3DEN-US style=3D'color:#1F497D'>E=
CC
Subject public key info <o:p></o:p></span></p>

<p class=3DMsoListParagraph style=3D'text-indent:-18.0pt;mso-list:l0 level1=
 lfo4'><![if !supportLists]><span
lang=3DEN-US style=3D'font-family:Symbol;color:#1F497D'><span style=3D'mso-=
list:Ignore'>&middot;<span
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;
</span></span></span><![endif]><span lang=3DEN-US style=3D'color:#1F497D'>R=
FC 4055
update<o:p></o:p></span></p>

<p class=3DMsoListParagraph style=3D'text-indent:-18.0pt;mso-list:l0 level1=
 lfo4'><![if !supportLists]><span
lang=3DEN-US style=3D'font-family:Symbol;color:#1F497D'><span style=3D'mso-=
list:Ignore'>&middot;<span
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;
</span></span></span><![endif]><span lang=3DEN-US style=3D'color:#1F497D'>N=
ew ASN.1
modules for PKIX<o:p></o:p></span></p>

<p class=3DMsoListParagraph style=3D'text-indent:-18.0pt;mso-list:l0 level1=
 lfo4'><![if !supportLists]><span
lang=3DEN-US style=3D'font-family:Symbol;color:#1F497D'><span style=3D'mso-=
list:Ignore'>&middot;<span
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;
</span></span></span><![endif]><span lang=3DEN-US style=3D'color:#1F497D'>A=
lgorithm
identifiers for SHA2<o:p></o:p></span></p>

<p class=3DMsoListParagraph style=3D'text-indent:-18.0pt;mso-list:l0 level1=
 lfo4'><![if !supportLists]><span
lang=3DEN-US style=3D'font-family:Symbol;color:#1F497D'><span style=3D'mso-=
list:Ignore'>&middot;<span
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;
</span></span></span><![endif]><span lang=3DEN-US style=3D'color:#1F497D'>T=
raceable
anonymous certificates<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'><o:p>&nbsp;=
</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'>I have no r=
equests
for additional topics.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'><o:p>&nbsp;=
</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'><o:p>&nbsp;=
</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'>REQUIRED AC=
TIONS:<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'>Can someone=
 from each
lacking WG item please let me know if you want any time slot.<o:p></o:p></s=
pan></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'>We are also=
 still
open for other potential topics on the agenda.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'>But I need =
all
requests by the end of this week.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'><o:p>&nbsp;=
</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'>Thank you.<=
o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'><o:p>&nbsp;=
</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'><o:p>&nbsp;=
</o:p></span></p>

<div>

<p class=3DMsoNormal><b><span lang=3DEN-GB style=3D'font-size:10.0pt;font-f=
amily:
"Arial","sans-serif";color:maroon'>Stefan Santesson</span></b><span lang=3D=
EN-GB
style=3D'font-size:12.0pt;font-family:"Times New Roman","serif";color:#1F49=
7D'><o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-GB style=3D'font-size:10.0pt;font-fami=
ly:"Arial","sans-serif";
color:#400040'>Senior Program Manager</span><span lang=3DEN-GB style=3D'fon=
t-size:
12.0pt;font-family:"Times New Roman","serif";color:navy'><o:p></o:p></span>=
</p>

<p class=3DMsoNormal><b><span lang=3DEN-GB style=3D'font-size:10.0pt;font-f=
amily:
"Arial","sans-serif";color:#400040'>Windows Security, Standards</span></b><=
span
lang=3DEN-US style=3D'color:#1F497D'><o:p></o:p></span></p>

</div>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'><o:p>&nbsp;=
</o:p></span></p>

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

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm =
0cm 0cm'>

<p class=3DMsoNormal><b><span lang=3DEN-US style=3D'font-size:10.0pt;font-f=
amily:
"Tahoma","sans-serif"'>From:</span></b><span lang=3DEN-US style=3D'font-siz=
e:10.0pt;
font-family:"Tahoma","sans-serif"'> [e-mail]
[mailto:[e-mail]] <b>On Behalf Of </b>Stefan Santesson<=
br>
<b>Sent:</b> den 20 februari 2008 18:05<br>
<b>To:</b> pkix<br>
<b>Subject:</b> Call for agenda items, Philadelphia IETF<o:p></o:p></span><=
/p>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal><span lang=3DEN-US>Time to set the agenda for the Phil=
adelphia
PKIX meeting.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US>Anyone wanting a slot should send m=
e an
e-mail as soon as possible, no later than EOD Wednesday next week (Feb 27).=
<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US>As usual I want the lead editor for=
 every
current pkix draft to tell me if they want a slot or not.<o:p></o:p></span>=
</p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US>We are currently scheduled as a Mon=
day
morning session from 0900-1130, which means two things.<o:p></o:p></span></=
p>

<p class=3DMsoNormal><span lang=3DEN-US>1) We have 2.5 hours available whic=
h should
be plenty of time.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US>2) We need to have everything set,
including presentations sent to me by Sunday night.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><b><span lang=3DEN-GB style=3D'font-size:10.0pt;font-f=
amily:
"Arial","sans-serif";color:maroon'>Stefan Santesson</span></b><span lang=3D=
EN-GB
style=3D'font-size:12.0pt;font-family:"Times New Roman","serif";color:#1F49=
7D'><o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-GB style=3D'font-size:10.0pt;font-fami=
ly:"Arial","sans-serif";
color:#400040'>Senior Program Manager</span><span lang=3DEN-GB style=3D'fon=
t-size:
12.0pt;font-family:"Times New Roman","serif";color:navy'><o:p></o:p></span>=
</p>

<p class=3DMsoNormal><b><span lang=3DEN-GB style=3D'font-size:10.0pt;font-f=
amily:
"Arial","sans-serif";color:#400040'>Windows Security, Standards</span></b><=
span
lang=3DEN-US style=3D'color:#1F497D'><o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

</div>

</div>

</div>

</body>

</html>

--_000_9F11911AED01D24BAA1C2355723C3D32195ACDA1F6EAEXMSGC332eu_--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA6ARHx1078937 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Nov 2008 03:27:17 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA6ARHgI078935; Thu, 6 Nov 2008 03:27:17 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA6AR8om078907 for <[e-mail]>; Thu, 6 Nov 2008 03:27:16 -0700 (MST) (envelope-from [e-mail])
Received: from MSGA-001.frcl.bull.fr (msga-mcl1.frcl.bull.fr [129.184.87.20]) by odin2.bull.net (Bull S.A.) with ESMTP id BF1867903 for <[e-mail]>; Thu,  6 Nov 2008 11:21:26 +0100 (CET)
Received: from FRMYA-SIA24 ([129.182.109.112]) by MSGA-001.frcl.bull.fr (Lotus Domino Release 5.0.11) with SMTP id 2008110611265402:348139 ; Thu, 6 Nov 2008 11:26:54 +0100 
Reply-To: [e-mail]
From: "Denis Pinkas"<[e-mail]>
To: "ietf-pkix"<[e-mail]>
Subject: Re: I-D Action:draft-ietf-pkix-ta-mgmt-reqs-02.txt (second part)
Date: Thu, 6 Nov 2008 11:26:53 +0100
Message-Id: <[e-mail]>
References: <[e-mail]>
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-Mailer: DreamMail 4.4.1.0
X-MIMETrack: Itemize by SMTP Server on MSGA-001/FR/BULL(Release 5.0.11  |July 24, 2002) at 06/11/2008 11:26:54, Serialize by Router on MSGA-001/FR/BULL(Release 5.0.11  |July 24, 2002) at 06/11/2008 11:27:06, Serialize complete at 06/11/2008 11:27:06
Content-Type: multipart/alternative;  boundary="----=_NextPart_08110611265266872518641_002"
Sender: [e-mail]
Precedence: 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_08110611265266872518641_002
Content-Type: text/plain; 
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

In order to keep the message short, two answers are given on this documen=
t.
=20
Comments on draft-ietf-pkix-ta-mgmt-reqs-02
=20
Topic: Clarifications needed about associated data, purpose and=20
constraints.
=20
For most web browsers and Java machines, the current situation is the=20
following:
=20
   - self-signed certificates are used for all purposes, e.g. TLS server,
     TLS client, sending e-mails, receiving e-mails, applets' signatures,
     and
=20
   - it is unknown whether revocation conditions are checked and how.
=20
Suppose (for the time being) that we want to move from the current=20
situation where self-signed certificates are placed in the same storage a=
nd=20
hence used for all purposes to a situation where self-signed certificates=
=20
are no more used for any purpose, e.g. used for sending e-mails or used f=
or=20
receiving e-mails.
=20
There are two possible approaches:
=20
   a) consider a given a *purpose*, e.g. applets' signatures, and then=20
      list all self-signed certificates that can be used for such a
      purpose, or
=20
   b) consider each self-signed certificate and tell for which purpose=20
      that self-signed certificate may be used.
=20
If we take into consideration the "need-to-know" requirement, some=20
applications need to know which self-signed certificates shall be used fo=
r=20
a given purpose and do not need to know if they are also used for a=20
different purpose.
=20
The approach a) fulfils this requirement, but not the approach b).
=20
When a path validation must be done for a given purpose, case a) is rathe=
r=20
straightforward: all the information is under the purpose.
=20
With case b), this would be more difficult, since the application would=20
need to scan every "Trust Anchor" store (?) and look if the given purpose=
=20
is mentioned under a "Trust Anchor".
=20
Case a) allows a clear and clean separation of information. However, it=20
seems that the document has implicitly chosen case b). :-(
=20
It is unclear in the current document what is the relationship between th=
e=20
purpose of use of a self-signed certificate that would be placed in TA, t=
he=20
"Trust Anchor" itself or the "Trust Anchor Store=94.
=20
Is one Trust anchor Store usable for some specific purpose(s)?=20

Hence is the "purpose" part of the Trust Anchor Store rather than=20
the Trust Anchor itself?=20

All this needs to be clarified. Once this will be clarified,=20
it will be possible to address the kind of operations that should be=20
possible on the various objects.
=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=20
In the abstract the text states:
=20
   The public key is used to verify digital
   signatures and the *associated data is used to constrain* the types of
   information for which the trust anchor is authoritative.
=20
This sentence is confusing since the word "constrain" is kept vague and=20
thus does not make the difference between:
=20
   1) the intended purpose,
   2) the constraints that are set by the CA and apply for all purposes,
   3) the constraints that are set by the RP.
=20
Let us now illustrate case 2): the constraints are included into the self=
-
signed certificate. The constraints are set by the CA and apply to all=20
usages of that self-signed certificate, i.e. all "purposes".
=20
Let us now illustrate cases 3): the constraints are external to the self-
signed certificate. The constraints come in addition to those included=20
inside the self-signed certificate and are tailored to the specific=20
purpose.
=20
Case 2) and case 3) may co-exist.=20
=20
However, the current draft does not make the distinction between case 2)=20
and case 3). This is rather fundamental, since a "TA manager" cannot chan=
ge=20
the constraints that are included in a self-signed certificate.
=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
=20
The document defines a Trust Anchor as : "A trust anchor represents an=20
authoritative entity via a public key and associated data". This sentence=
=20
is confusing since the wording "associated data" means everything and thu=
s=20
nothing.=20
=20
This definition is not coherent with RFC 5280 which states on page 76:
=20
   " The trust anchor information includes:
=20
      (1)  the trusted issuer name,
      (2)  the trusted public key algorithm,
      (3)  the trusted public key, and
      (4)  optionally, the trusted public key parameters associated
           with the public key.
=20
The issuer name shall always be present in a trust anchor".
=20
The definition of a TA should also make the difference between:
=20
   a) the constraints that are set by the CA and apply for all purposes,
   b) the constraints that are set by the RP.
=20
Only the later, can be managed when self-signed certificates are used.
Denis

----- Message re=E7u -----=20
De : owner-ietf-pkix=20
=C0 : i-d-announce=20
Date : 2008-10-30, 21:45:01
Sujet : I-D Action:draft-ietf-pkix-ta-mgmt-reqs-02.txt


Pi=E8ce(s) Jointe(s) au message original :
  (1). draft-ietf-pkix-ta-mgmt-reqs-02.txt


  Title : Trust Anchor Management Requirements
  Author(s) : R. Reddy, C. Wallace
  Filename : draft-ietf-pkix-ta-mgmt-reqs-02.txt
  Pages : 19
  Date : 2008-10-30

A trust anchor represents an authoritative entity via a public key
and associated data. The public key is used to verify digital
signatures and the associated data is used to constrain the types of
information for which the trust anchor is authoritative. A relying
party uses trust anchors to determine if a digitally signed object is
valid by verifying a digital signature using the trust anchor's
public key, and by enforcing the constraints expressed in the
associated data for the trust anchor. This document describes some
of the problems associated with the lack of a standard trust anchor
management mechanism and defines requirements for data formats and
protocols designed to address these problems.

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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

------=_NextPart_08110611265266872518641_002
Content-Type: text/html; 
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

<HTML><HEAD><TITLE></TITLE>
<META content=3D"KsDHTMLEDLib.ocx, FreeWare HTML Editor 1.164.2, =A9 Kurt=
 Senfer"=20
name=3DGENERATOR>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-=
1"></HEAD>
<BODY style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Tahoma" leftMargin=3D5 topMa=
rgin=3D5=20
#ffffff>
<DIV>In order to keep the message short, two answers are given on this=20
document.</DIV>
<DIV><SPAN lang=3DEN-GB style=3D"mso-ansi-language: EN-GB"><?xml:namespac=
e prefix =3D=20
o ns =3D "urn:schemas-microsoft-com:office:office" /><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></DIV>
<DIV>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">Comments on=
=20
draft-ietf-pkix-ta-mgmt-reqs-02<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">Topic: Clar=
ifications=20
needed about associated data, purpose and <o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT=20
face=3D"Courier New">constraints.<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">For most we=
b browsers=20
and Java machines, the current situation is the <o:p></o:p></FONT></SPAN>=
</P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT=20
face=3D"Courier New">following:<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>- self-signed certificate=
s are=20
used for all purposes, e.g. TLS server,<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>TLS client, s=
ending=20
e-mails, receiving e-mails, applets' signatures,<o:p></o:p></FONT></SPAN>=
</P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN>and<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>- it is unknown whether r=
evocation=20
conditions are checked and how.<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">Suppose (fo=
r the time=20
being) that we want to move from the current <o:p></o:p></FONT></SPAN></P=
>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">situation w=
here=20
self-signed certificates are placed in the same storage and=20
<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">hence used =
for all=20
purposes to a situation where self-signed certificates=20
<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">are no more=
 used for=20
any purpose, e.g. used for sending e-mails or used for=20
<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">receiving=20
e-mails.<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">There are t=
wo possible=20
approaches:<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>a) consider a given a *pu=
rpose*,=20
e.g. applets' signatures, and then <o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>list al=
l=20
self-signed certificates that can be used for such=20
a<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>purpose=
,=20
or<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>b) consider each self-sig=
ned=20
certificate and tell for which purpose <o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>that se=
lf-signed=20
certificate may be used.<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">If we take =
into=20
consideration the "need-to-know" requirement, some <o:p></o:p></FONT></SP=
AN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">application=
s need to=20
know which self-signed certificates shall be used for=20
<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">a given pur=
pose and do=20
not need to know if they are also used for a <o:p></o:p></FONT></SPAN></P=
>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">different=20
purpose.<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">The approac=
h a)=20
fulfils this requirement, but not the approach b).<o:p></o:p></FONT></SPA=
N></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">When a path=
 validation=20
must be done for a given purpose, case a) is rather=20
<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">straightfor=
ward: all=20
the information is under the purpose.<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">With case b=
), this=20
would be more difficult, since the application would=20
<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">need to sca=
n every=20
"Trust Anchor" store (?) and look if the given purpose=20
<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">is mentione=
d under a=20
"Trust Anchor".<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">Case a) all=
ows a clear=20
and clean separation of information. However, it <o:p></o:p></FONT></SPAN=
></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">seems that =
the=20
document has implicitly chosen case b). :-(<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">It is uncle=
ar in the=20
current document what is the relationship between the=20
<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">purpose of =
use of a=20
self-signed certificate that would be placed in TA, the=20
<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">"Trust Anch=
or" itself=20
or the "Trust Anchor Store=94.<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">Is one Trus=
t anchor=20
Store usable for some specific purpose(s)? </FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT=20
face=3D"Courier New"></FONT></SPAN>&nbsp;</P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">Hence is=20
</FONT></SPAN><SPAN lang=3DEN-GB style=3D"mso-ansi-language: EN-GB"><FONT=
=20
face=3D"Courier New">the "purpose" part of the Trust Anchor Store rather =
than=20
<BR>the Trust A</FONT></SPAN><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">nchor itsel=
f?=20
</FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT=20
face=3D"Courier New"></FONT></SPAN>&nbsp;</P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">All this ne=
eds to be=20
clarified. Once this will be clarified, <o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">it will be =
possible to=20
address the kind of operations that should be <o:p></o:p></FONT></SPAN></=
P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">possible on=
 the=20
various objects.<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p>&nbsp;</o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">In the abst=
ract the=20
text states:<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>The public key is used to=
 verify=20
digital<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>signatures and the *assoc=
iated=20
data is used to constrain* the types of<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>information for which the=
 trust=20
anchor is authoritative.<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">This senten=
ce is=20
confusing since the word "constrain" is kept vague and=20
<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">thus does n=
ot make the=20
difference between:<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>1) the intended=20
purpose,<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>2) the constraints that a=
re set by=20
the CA and apply for all purposes,<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>3) the constraints that a=
re set by=20
the RP.<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">Let us now =
illustrate=20
case 2): the constraints are included into the=20
self-<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">signed cert=
ificate.=20
The constraints are set by the CA and apply to all <o:p></o:p></FONT></SP=
AN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">usages of t=
hat=20
self-signed certificate, i.e. all "purposes".<o:p></o:p></FONT></SPAN></P=
>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">Let us now =
illustrate=20
cases 3): the constraints are external to the self-<o:p></o:p></FONT></SP=
AN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">signed cert=
ificate.=20
The constraints come in addition to those included <o:p></o:p></FONT></SP=
AN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">inside the =
self-signed=20
certificate and are tailored to the specific <o:p></o:p></FONT></SPAN></P=
>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT=20
face=3D"Courier New">purpose.<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">Case 2) and=
 case 3)=20
may co-exist. <o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">However, th=
e current=20
draft does not make the distinction between case 2)=20
<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">and case 3)=
. This is=20
rather fundamental, since a "TA manager" cannot change=20
<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">the constra=
ints that=20
are included in a self-signed certificate.<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p>&nbsp;</o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">The documen=
t defines a=20
Trust Anchor as : "A trust anchor represents an <o:p></o:p></FONT></SPAN>=
</P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">authoritati=
ve entity=20
via a public key and associated data". This sentence=20
<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">is confusin=
g since the=20
wording "associated data" means everything and thus=20
<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">nothing.=20
<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">This defini=
tion is not=20
coherent with RFC 5280 which states on page 76:<o:p></o:p></FONT></SPAN><=
/P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; " </SPAN>The trust anchor inform=
ation=20
includes:<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>(1)<SPA=
N=20
style=3D"mso-spacerun: yes">&nbsp; </SPAN>the trusted issuer=20
name,<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;</SPAN><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;</SPAN>(2)<SPAN=20
style=3D"mso-spacerun: yes">&nbsp; </SPAN>the trusted public key=20
algorithm,<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>(3)<SPAN=20
style=3D"mso-spacerun: yes">&nbsp; </SPAN>the trusted public key,=20
and<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>(4)<SPAN=20
style=3D"mso-spacerun: yes">&nbsp; </SPAN>optionally, the trusted public =
key=20
parameters associated<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;=20
</SPAN>with the public key.<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">The issuer =
name shall=20
always be present in a trust anchor".<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">The definit=
ion of a TA=20
should also make the difference between:<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>a) the constraints that a=
re set by=20
the CA and apply for all purposes,<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>b) the constraints that a=
re set by=20
the RP.<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">Only the la=
ter, can be=20
managed when self-signed certificates are used.<o:p></o:p></FONT></SPAN><=
/P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New"></FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"></SPAN></P></DIV>
<DIV></DIV>
<DIV><!--AID_FROMNAME_BEGIN-->Denis</DIV>
<DIV>&nbsp;</DIV>
<BLOCKQUOTE=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-=
LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV=20
  style=3D"FONT-WEIGHT: normal; FONT-SIZE: 9pt; LINE-HEIGHT: normal; FONT=
-STYLE: normal; FONT-VARIANT: normal">-----=20
  Message re=E7u ----- </DIV>
  <DIV=20
  style=3D"FONT-WEIGHT: normal; FONT-SIZE: 9pt; BACKGROUND: #e4e4e4; LINE=
-HEIGHT: normal; FONT-STYLE: normal; FONT-VARIANT: normal; font-color: bl=
ack"><B>De=20
  :</B> <A href=3D"mailto :[e-mail]">owner-ietf-pkix<=
/A>=20
</DIV>
  <DIV=20
  style=3D"FONT-WEIGHT: normal; FONT-SIZE: 9pt; LINE-HEIGHT: normal; FONT=
-STYLE: normal; FONT-VARIANT: normal"><B>=C0=20
  :</B> <A href=3D"mailto :[e-mail]">i-d-announce</A> </DIV>
  <DIV=20
  style=3D"FONT-WEIGHT: normal; FONT-SIZE: 9pt; LINE-HEIGHT: normal; FONT=
-STYLE: normal; FONT-VARIANT: normal"><B>Date=20
  :</B> 2008-10-30, 21:45:01</DIV>
  <DIV=20
  style=3D"FONT-WEIGHT: normal; FONT-SIZE: 9pt; LINE-HEIGHT: normal; FONT=
-STYLE: normal; FONT-VARIANT: normal"><B>Sujet=20
  :</B> I-D Action:draft-ietf-pkix-ta-mgmt-reqs-02.txt</DIV>
  <DIV><BR></DIV>
  <DIV></DIV>
  <DIV>
  <DIV><U><STRONG>Pi=E8ce(s) Jointe(s) au message original :</STRONG></U>=
</DIV>
  <DIV>&nbsp;&nbsp;(1).&nbsp;draft-ietf-pkix-ta-mgmt-reqs-02.txt</DIV><BR=
></DIV>
  <DIV>
  <DIV>&nbsp;&nbsp;Title : Trust Anchor Management=20
  Requirements<BR>&nbsp;&nbsp;Author(s) : R. Reddy, C.=20
  Wallace<BR>&nbsp;&nbsp;Filename :=20
  draft-ietf-pkix-ta-mgmt-reqs-02.txt<BR>&nbsp;&nbsp;Pages :=20
  19<BR>&nbsp;&nbsp;Date : 2008-10-30<BR><BR>A trust anchor represents an=
=20
  authoritative entity via a public key<BR>and associated data. The publi=
c key=20
  is used to verify digital<BR>signatures and the associated data is used=
 to=20
  constrain the types of<BR>information for which the trust anchor is=20
  authoritative. A relying<BR>party uses trust anchors to determine if a=20
  digitally signed object is<BR>valid by verifying a digital signature us=
ing the=20
  trust anchor's<BR>public key, and by enforcing the constraints expresse=
d in=20
  the<BR>associated data for the trust anchor. This document describes=20
  some<BR>of the problems associated with the lack of a standard trust=20
  anchor<BR>management mechanism and defines requirements for data format=
s=20
  and<BR>protocols designed to address these problems.<BR><BR>A URL for t=
his=20
  Internet-Draft is:<BR><A=20
  href=3D"http://www.ietf.org/internet-drafts/draft-ietf-pkix-ta-mgmt-req=
s-02.txt">http://www.ietf.org/internet-drafts/draft-ietf-pkix-ta-mgmt-req=
s-02.txt</A><BR><BR>Internet-Drafts=20
  are also available by anonymous FTP=20
  at:<BR>ftp://ftp.ietf.org/internet-drafts/<BR><BR>Below is the data whi=
ch will=20
  enable a MIME compliant mail reader<BR>implementation to automatically=20
  retrieve the ASCII version of=20
the<BR>Internet-Draft.<BR><BR></DIV></DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_08110611265266872518641_002--






Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA6ARHpa078936 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Nov 2008 03:27:17 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA6ARHFr078934; Thu, 6 Nov 2008 03:27:17 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA6AR4AK078906 for <[e-mail]>; Thu, 6 Nov 2008 03:27:16 -0700 (MST) (envelope-from [e-mail])
Received: from MSGA-001.frcl.bull.fr (msga-mcl1.frcl.bull.fr [129.184.87.20]) by odin2.bull.net (Bull S.A.) with ESMTP id 991C278C6 for <[e-mail]>; Thu,  6 Nov 2008 11:21:21 +0100 (CET)
Received: from FRMYA-SIA24 ([129.182.109.112]) by MSGA-001.frcl.bull.fr (Lotus Domino Release 5.0.11) with SMTP id 2008110611244073:347989 ; Thu, 6 Nov 2008 11:24:40 +0100 
Reply-To: [e-mail]
From: "Denis Pinkas"<[e-mail]>
To: "ietf-pkix"<[e-mail]>
Subject: Re: I-D Action:draft-ietf-pkix-ta-mgmt-reqs-02.txt
Date: Thu, 6 Nov 2008 11:24:39 +0100
Message-Id: <[e-mail]>
References: <[e-mail]>
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-Mailer: DreamMail 4.4.1.0
X-MIMETrack: Itemize by SMTP Server on MSGA-001/FR/BULL(Release 5.0.11  |July 24, 2002) at 06/11/2008 11:24:41, Serialize by Router on MSGA-001/FR/BULL(Release 5.0.11  |July 24, 2002) at 06/11/2008 11:27:03, Serialize complete at 06/11/2008 11:27:03
Content-Type: multipart/alternative;  boundary="----=_NextPart_08110611243926651453484_002"
Sender: [e-mail]
Precedence: 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_08110611243926651453484_002
Content-Type: text/plain; 
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

In order to keep the message short, two answers are given on this documen=
t.

Comments on draft-ietf-pkix-ta-mgmt-reqs-02
=20
Topic: automatic root key rollover only using trust anchors initially=20
installed.
=20
The document states on page 7:
=20
   Ideally, only the initial set of trust anchors are installed in=20
   a particular trust anchor store should require out-of-band=20
   verification, particularly when the costs of performing out-of-band=20
   checks commensurate with the security requirements of applications=20
   using the trust anchor store are high.
=20
It implicitly means that once an initial set of trust anchors is installe=
d,=20
the renewal should happen automatically.
=20
Unfortunately, this text is only a *statement* within section 2 "Problem=20
Statement" rather than a *requirement* within section 3 "Requirements". I=
t=20
should be transformed into a requirement with section 3.
=20
In practice, we are very close to reach this goal.
=20
The CMP protocol allows RPs to pull the information and to automatically=20
update trust anchors using the old-by-new self-signed certificate and the=
=20
new-by-new self-signed certificate. There are only two additional questio=
ns=20
to be answered:=20
=20
   a) where to fetch these self-signed-certificates ?
   b) when to fetch these self-signed-certificates ?=20
=20
The answer to the first question is:=20
=20
   1) add an LDAP address or an HTTP address, or
   2) use an Authority Information Access extension=20
      within the self-signed certificate.
=20
The answer to the second question is:=20
=20
   1) add a time period for root key renewal, or
   2) use a private key usage extension within the self-signed certificat=
e.
=20
 ... and then we are done when CA issue self-signed certificates, which i=
s=20
what *all* CAs are doing today.
=20
It does not matter where self-signed certificates are stored, e.g. in=20
validation policies or in TA anchors stores (whatever this last term may=20
mean).
=20
It means that the use of self-signed certificates allows automatic root k=
ey=20
rollover and to reach the ideal situation mentioned above.
=20
A major advantage of this approach is the use of a pull model: the proces=
s=20
is initiated from the inside of a company and the number of applications=20
using that self-signed certificate may be hidden to the outside. Denial o=
f=20
service is easier to handle since the first exchange comes from the insid=
e.=20
=20
These considerations should be taken into consideration in the draft.
=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=20
The document states in section 3.1.: Transport independence
=20
   "It MUST work in both session-oriented
   and store-and-forward communications environments as well as in both
   push and pull distribution models".
=20
CMP only works in a pull model. With such sentence CMP would be ruled out=
=20
whereas it is already a standard track protocol.
=20
The document states in section 3.1.: Transport independence
=20
   "connectionless integrity and data origin
   authentication for TA transactions MUST be provided at the
   application layer".
=20
With CMP, the security is obtained directly by the self-signed=20
certificates, i.e. the data itself which is self-protected. With such=20
sentence CMP would be ruled out, whereas it is already a standard track=20
protocol.
=20
The document cannot say on one side that the pull model is allowed and on=
=20
the other side include requirements which rule out the use of CMP (which =
is=20
based on a pull model).

Denis

----- Message re=E7u -----=20
De : owner-ietf-pkix=20
=C0 : i-d-announce=20
Date : 2008-10-30, 21:45:01
Sujet : I-D Action:draft-ietf-pkix-ta-mgmt-reqs-02.txt


Pi=E8ce(s) Jointe(s) au message original :
  (1). draft-ietf-pkix-ta-mgmt-reqs-02.txt


  Title : Trust Anchor Management Requirements
  Author(s) : R. Reddy, C. Wallace
  Filename : draft-ietf-pkix-ta-mgmt-reqs-02.txt
  Pages : 19
  Date : 2008-10-30

A trust anchor represents an authoritative entity via a public key
and associated data. The public key is used to verify digital
signatures and the associated data is used to constrain the types of
information for which the trust anchor is authoritative. A relying
party uses trust anchors to determine if a digitally signed object is
valid by verifying a digital signature using the trust anchor's
public key, and by enforcing the constraints expressed in the
associated data for the trust anchor. This document describes some
of the problems associated with the lack of a standard trust anchor
management mechanism and defines requirements for data formats and
protocols designed to address these problems.

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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

------=_NextPart_08110611243926651453484_002
Content-Type: text/html; 
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

<HTML><HEAD><TITLE></TITLE>
<META content=3D"KsDHTMLEDLib.ocx, FreeWare HTML Editor 1.164.2, =A9 Kurt=
 Senfer"=20
name=3DGENERATOR>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-=
1"></HEAD>
<BODY style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Tahoma" leftMargin=3D5 topMa=
rgin=3D5=20
#ffffff>
<DIV>In order to keep the message short, two answers are given on this=20
document.</DIV>
<DIV>&nbsp;</DIV>
<DIV>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">Comments on=
=20
draft-ietf-pkix-ta-mgmt-reqs-02<?xml:namespace prefix =3D o ns =3D=20
"urn:schemas-microsoft-com:office:office" /><o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">Topic: auto=
matic root=20
key rollover only using trust anchors initially <o:p></o:p></FONT></SPAN>=
</P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT=20
face=3D"Courier New">installed.<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">The documen=
t states on=20
page 7:<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>Ideally, only the initial=
 set of=20
trust anchors are installed in <o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>a particular trust anchor=
 store=20
should require out-of-band <o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>verification, particularl=
y when=20
the costs of performing out-of-band <o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>checks commensurate with =
the=20
security requirements of applications <o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>using the trust anchor st=
ore are=20
high.<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">It implicit=
ly means=20
that once an initial set of trust anchors is installed,=20
<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">the renewal=
 should=20
happen automatically.<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">Unfortunate=
ly, this=20
text is only a *statement* within section 2 "Problem=20
<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">Statement" =
rather than=20
a *requirement* within section 3 "Requirements". It=20
<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">should be t=
ransformed=20
into a requirement with section 3.<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">In practice=
, we are=20
very close to reach this goal.<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">The CMP pro=
tocol=20
allows RPs to pull the information and to automatically=20
<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">update trus=
t anchors=20
using the old-by-new self-signed certificate and the=20
<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">new-by-new =
self-signed=20
certificate. There are only two additional questions=20
<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">to be answe=
red:=20
<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">&nbsp;&nbsp=
; a) where=20
to fetch these self-signed-certificates ?<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">&nbsp; b) w=
hen to=20
fetch these self-signed-certificates ? <o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">The answer =
to the=20
first question is: <o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>1) add an LDAP address or=
 an HTTP=20
address, or<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>2) use an Authority Infor=
mation=20
Access extension <o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>within =
the=20
self-signed certificate.<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">The answer =
to the=20
second question is: <o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>1) add a time period for =
root key=20
renewal, or<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>2) use a private key usag=
e=20
extension within the self-signed certificate.<o:p></o:p></FONT></SPAN></P=
>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;</SPAN>... and then we are done when CA=
 issue=20
self-signed certificates, which is <o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">what *all* =
CAs are=20
doing today.<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">It does not=
 matter=20
where self-signed certificates are stored, e.g. in <o:p></o:p></FONT></SP=
AN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">validation =
policies or=20
in TA anchors stores (whatever this last term may <o:p></o:p></FONT></SPA=
N></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT=20
face=3D"Courier New">mean).<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">It means th=
at the use=20
of self-signed certificates allows automatic root key=20
<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">rollover an=
d to reach=20
the ideal situation mentioned above.<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">A major adv=
antage of=20
this approach is the use of a pull model: the process=20
<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">is initiate=
d from the=20
inside of a company and the number of applications <o:p></o:p></FONT></SP=
AN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">using that =
self-signed=20
certificate may be hidden to the outside. Denial of=20
<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">service is =
easier to=20
handle since the first exchange comes from the inside.=20
<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">These consi=
derations=20
should be taken into consideration in the draft.<o:p></o:p></FONT></SPAN>=
</P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT=20
face=3D"Courier New">=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">The documen=
t states in=20
section 3.1.: Transport independence<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>"It MUST work in both=20
session-oriented<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>and store-and-forward=20
communications environments as well as in both<o:p></o:p></FONT></SPAN></=
P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>push and pull distributio=
n=20
models".<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">CMP only wo=
rks in a=20
pull model. With such sentence CMP would be ruled out=20
<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">whereas it =
is already=20
a standard track protocol.<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">The documen=
t states in=20
section 3.1.: Transport independence<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>"connectionless integrity=
 and data=20
origin<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>authentication for TA tra=
nsactions=20
MUST be provided at the<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>application=20
layer".<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">With CMP, t=
he security=20
is obtained directly by the self-signed <o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">certificate=
s, i.e. the=20
data itself which is self-protected. With such <o:p></o:p></FONT></SPAN><=
/P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">sentence CM=
P would be=20
ruled out, whereas it is already a standard track <o:p></o:p></FONT></SPA=
N></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT=20
face=3D"Courier New">protocol.<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">The documen=
t cannot=20
say on one side that the pull model is allowed and on=20
<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">the other s=
ide include=20
requirements which rule out the use of CMP (which is=20
<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">based on a =
pull=20
model).</FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT=20
face=3D"Courier New"></FONT></SPAN>&nbsp;</P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT=20
face=3D"Courier New">Denis</FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT=20
face=3D"Courier New"></FONT></SPAN>&nbsp;</P></DIV>
<BLOCKQUOTE=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-=
LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV=20
  style=3D"FONT-WEIGHT: normal; FONT-SIZE: 9pt; LINE-HEIGHT: normal; FONT=
-STYLE: normal; FONT-VARIANT: normal">-----=20
  Message re=E7u ----- </DIV>
  <DIV=20
  style=3D"FONT-WEIGHT: normal; FONT-SIZE: 9pt; BACKGROUND: #e4e4e4; LINE=
-HEIGHT: normal; FONT-STYLE: normal; FONT-VARIANT: normal; font-color: bl=
ack"><B>De=20
  :</B> <A href=3D"mailto :[e-mail]">owner-ietf-pkix<=
/A>=20
</DIV>
  <DIV=20
  style=3D"FONT-WEIGHT: normal; FONT-SIZE: 9pt; LINE-HEIGHT: normal; FONT=
-STYLE: normal; FONT-VARIANT: normal"><B>=C0=20
  :</B> <A href=3D"mailto :[e-mail]">i-d-announce</A> </DIV>
  <DIV=20
  style=3D"FONT-WEIGHT: normal; FONT-SIZE: 9pt; LINE-HEIGHT: normal; FONT=
-STYLE: normal; FONT-VARIANT: normal"><B>Date=20
  :</B> 2008-10-30, 21:45:01</DIV>
  <DIV=20
  style=3D"FONT-WEIGHT: normal; FONT-SIZE: 9pt; LINE-HEIGHT: normal; FONT=
-STYLE: normal; FONT-VARIANT: normal"><B>Sujet=20
  :</B> I-D Action:draft-ietf-pkix-ta-mgmt-reqs-02.txt</DIV>
  <DIV><BR></DIV>
  <DIV></DIV>
  <DIV>
  <DIV><U><STRONG>Pi=E8ce(s) Jointe(s) au message original :</STRONG></U>=
</DIV>
  <DIV>&nbsp;&nbsp;(1).&nbsp;draft-ietf-pkix-ta-mgmt-reqs-02.txt</DIV><BR=
></DIV>
  <DIV>
  <DIV>&nbsp;&nbsp;Title : Trust Anchor Management=20
  Requirements<BR>&nbsp;&nbsp;Author(s) : R. Reddy, C.=20
  Wallace<BR>&nbsp;&nbsp;Filename :=20
  draft-ietf-pkix-ta-mgmt-reqs-02.txt<BR>&nbsp;&nbsp;Pages :=20
  19<BR>&nbsp;&nbsp;Date : 2008-10-30<BR><BR>A trust anchor represents an=
=20
  authoritative entity via a public key<BR>and associated data. The publi=
c key=20
  is used to verify digital<BR>signatures and the associated data is used=
 to=20
  constrain the types of<BR>information for which the trust anchor is=20
  authoritative. A relying<BR>party uses trust anchors to determine if a=20
  digitally signed object is<BR>valid by verifying a digital signature us=
ing the=20
  trust anchor's<BR>public key, and by enforcing the constraints expresse=
d in=20
  the<BR>associated data for the trust anchor. This document describes=20
  some<BR>of the problems associated with the lack of a standard trust=20
  anchor<BR>management mechanism and defines requirements for data format=
s=20
  and<BR>protocols designed to address these problems.<BR><BR>A URL for t=
his=20
  Internet-Draft is:<BR><A=20
  href=3D"http://www.ietf.org/internet-drafts/draft-ietf-pkix-ta-mgmt-req=
s-02.txt">http://www.ietf.org/internet-drafts/draft-ietf-pkix-ta-mgmt-req=
s-02.txt</A><BR><BR>Internet-Drafts=20
  are also available by anonymous FTP=20
  at:<BR>ftp://ftp.ietf.org/internet-drafts/<BR><BR>Below is the data whi=
ch will=20
  enable a MIME compliant mail reader<BR>implementation to automatically=20
  retrieve the ASCII version of=20
the<BR>Internet-Draft.<BR><BR></DIV></DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_08110611243926651453484_002--






Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA5HVtfe008323 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Nov 2008 10:31:55 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA5HVtRa008322; Wed, 5 Nov 2008 10:31:55 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mailhost.noorhome.net (adsl-63-194-79-229.dsl.snfc21.pacbell.net [63.194.79.229]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA5HVipG008306 for <[e-mail]>; Wed, 5 Nov 2008 10:31:54 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.noorhome.net (Postfix) with ESMTP id 888983AF1B6; Wed,  5 Nov 2008 12:07:40 -0500 (EST)
X-Spam-Score: -2.886
X-Spam-Level: 
X-Spam-Status: No, score=-2.886 tagged_above=-10 required=6.6 tests=[ALL_TRUSTED=-1.8, BAYES_00=-2.599, DNS_FROM_SECURITYSAGE=1.513]
Received: from mailhost.noorhome.net ([127.0.0.1]) by localhost (mailhost.noorhome.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qdSf6bGPlh+n; Wed,  5 Nov 2008 12:07:38 -0500 (EST)
Received: from poseidon.noorhome.net (poseidon.noorhome.net [192.168.0.9]) by mailhost.noorhome.net (Postfix) with ESMTP id 539F03AF1A6; Wed,  5 Nov 2008 12:07:38 -0500 (EST)
Message-ID: <[e-mail]>
Date: Wed, 05 Nov 2008 09:31:41 -0800
From: Arshad Noor <[e-mail]>
Organization: StrongAuth, Inc.
User-Agent: Thunderbird 2.0.0.16 (X11/20080723)
MIME-Version: 1.0
To: Anders Rundgren <[e-mail]>
CC: [e-mail], ekmi <[e-mail]>
Subject: Re: SKSML Was: Signing and Encrypting with the same key?
References: <[e-mail]> <B9A9F0E608D94D2CA899102A88789787@AndersPC> <[e-mail]> <87FE58DD430A4A48B3B2A522F95DB5AF@AndersPC> <[e-mail]> <BF063727CD004F48A55526D90AABB206@AndersPC> <[e-mail]> <ECC31DDE62B1426589DCCB255AB9F810@AndersPC>
In-Reply-To: <ECC31DDE62B1426589DCCB255AB9F810@AndersPC>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

To paraphrase the Public Review 02 specification (which should be
available on the OASIS site by the end of this week):

"..conforming implementations of the SKSML protocol MUST enclose all 
SKSML messages between participants in an SKMS, in the SOAP Body of a 
SOAP Envelope.  Additionally, the contents of the SOAP Body MUST be 
secured using digital signatures conforming to [XMLSignature] in the 
SOAP Header.  Specifically, the SOAP Header of the SOAP Envelope MUST 
enclose a Security element conforming to [WSS] with a ValueType 
attribute containing the value 
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3."

Yes, all SKMS clients and servers are mandated to use a certain security
convention in SOAP, but the SKSML message is oblivious of its envelope. 
  Secondly, how the digital certificates are constructed, how the client
and server key-pairs are managed, how the PKI is setup, managed and
audited, is not in the SKSML protocol.

That is what I meant by "abstracting the security, implementation,
operations and audit" of an EKMI out of the protocol.

Arshad Noor
StrongAuth, Inc.

Anders Rundgren wrote:
> Arshad,
> 
> Pardon my ignorance but I do not see how you can "abstract out" security solutions in a concrete 
> SOAP specification, either it is there or it is not.  That is, with respect to the particular 
> question and the current draft, you have no real alternative except stating that client and servers 
> must be configured to support a common convention.  Which BTW may be exactly what you meant :-) 
> That KeyGen2 is a 6-pass protocol is for avoiding conventions since the entities involved typically 
> do not belong to the same "IT-domain".  E.g. a consumer with a mobile phone and his/her bank.
> 
> Regarding the separate key stuff, the current strategy is to support it in the protocol, but not in 
> the Open Source client-implementation since no compelling argument actually has been raised for 
> having multiple keys, while there is quite a bunch of arguments against such an arrangement.  How is 
> an SKSML server supposed to know what to encrypt with if you do not send the key in the request?  It 
> seems that an SKSML server must keep an encryption key database or be configured to use LDAP etc. 
> It seems like a more straightforward solution to transfer encryption keys explicitly and validate 
> them at receival in the same way as you do with signature and authentication keys.
> 
> I'm a bit puzzled regarding how you intend to bootstrap SKSML with PKI, if the figures with a myriad 
> of entirely different clients are still valid.  The reason I started the KeyGen2 effort is because 
> this is a veritable nightmare, particularly for mobile devices.  As a comparison I would like to 
> mention the fact that there are some 100M TPM chips out there in major laptops, but they are "mostly 
> of out work" because the bootstrapping issues haven't been fully addressed by the TPM designers.
> 
> Anders
> 
> ----- Original Message ----- 
> From: "Arshad Noor" <[e-mail]>
> To: "Anders Rundgren" <[e-mail]>
> Cc: "Timothy J. Miller" <[e-mail]>; "Peter Gutmann" <[e-mail]>; 
> <[e-mail]>
> Sent: Tuesday, November 04, 2008 22:24
> Subject: Re: Signing and Encrypting with the same key?
> 
> 
> 
> Hi Anders,
> 
> The reason we haven't mentioned it yet is because the TC is going
> to begin the task of creating Implementation, Operations and Audit
> Guidelines for EKMI only in 2009.  It is within these guidelines
> where a recommendation for separating signing & encryption key-pairs
> would be made.
> 
> The SKSML protocol focuses on the minimum necessary syntax to send
> and receive messages related to symmetric-key management.  The
> security, implementation, operations and audit of such Enterprise
> Key Management Infrastructures must be capable of being abstracted
> out of the protocol, layered and managed independently.  Which is
> why there is no mention of separated key-pairs yet.  However, you
> can expect to see it in the Guidelines next year.
> 
> Arshad Noor
> StrongAuth, Inc.
> 
> 
> Anders Rundgren wrote:
>> Hi Arshad,
>> I just skimmed through the non-normative spec and example and from that I could not see any
>> mentioning of separate keys.
>>
>> I digged a bit further but could still not find such references in:
>> http://www.oasis-open.org/committees/download.php/28725/SKSML-1.0-Specification-Normative-DRAFT6.0.pdf
>>
>> I don't know what you have planned, but IMO you need additional elements in the protocol (like
>> giving the client a place to put its encryption key), as well as a standard for how encryption and
>> signature keys link together otherwise the server cannot be sure that it is encrypting for the
>> client that authenticated.  All this is the reason why I'm not overly enthusiastic of having
>> multiple entity-keys in a provisioning protocol, particularly since all attacks I have heard about
>> to date, have been based on flawed implementations, which is moderately interesting from a
>> *protocol-design* point-of-view:
>> http://www.imc.org/ietf-openpgp/mail-archive/msg14307.html
>>
>> But it is possible that SKSML will run in more restricted environments than KeyGen2 and thus can
>> build on that the client and servers use "conventions", keeping the protocol smallish.   KeyGen2 
>> is
>> designed to cope with a fragmented world and thus sports a capability/policy negotiation facility.
>>
>> Anders
>>
>> ----- Original Message ----- 
>> From: "Arshad Noor" <[e-mail]>
>> To: "Anders Rundgren" <[e-mail]>
>> Cc: "Timothy J. Miller" <[e-mail]>; "Peter Gutmann" <[e-mail]>;
>> <[e-mail]>
>> Sent: Tuesday, November 04, 2008 21:11
>> Subject: Re: Signing and Encrypting with the same key?
>>
>>
>> Anders,
>>
>> Just to clarify, the SKSML protocol does not mandate how the
>> digital certificate of SKMS clients and servers should be
>> constructed, or what the keyUsage extension should look like
>> within such certificates.  We believe that that is an
>> implementation detail of the PKI that supports the SKMS.
>>
>> The SKMS only requires that every client and server have a
>> signing key and an encryption key.  They can be the same
>> key-pair or two different key-pairs, depending on the PKI
>> certificate policy of the implementation site.
>>
>> Within the open-source StrongKey software we have, we require
>> two digital certificates to be configured for SKMS clients and
>> servers, to separate signing and encryption uses.  The test
>> certs we bundle with the FOSS, combines signing & encryption
>> merely as a convenience for people "kicking the tires".
>>
>> As a conservative practice, we recommend that PKIs separate
>> the signing and encryption capability into different digital
>> certificates.
>>
>> Arshad Noor
>> StrongAuth, Inc.
>>
>> Anders Rundgren wrote:
>>> Another reference is OASIS EKMI:
>>> http://www.oasis-open.org/committees/download.php/28657/SKSML-1.0-Specification-Non-Normative-DRAFT6.pdf
>>> From what I can deduct they indeed authenticate the requesting client through a signature and 
>>> then
>>> return the key by wrapping it by the public signature key.
>>>
> 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA5GqD2n005647 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Nov 2008 09:52:13 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA5GqDcK005646; Wed, 5 Nov 2008 09:52:13 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-dub.microsoft.com (smtp-dub.microsoft.com [213.199.138.181]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA5Gq1W1005621 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Wed, 5 Nov 2008 09:52:12 -0700 (MST) (envelope-from [e-mail])
Received: from dub-exhub-c302.europe.corp.microsoft.com (65.53.213.92) by DUB-EXGWY-E802.partners.extranet.microsoft.com (10.251.129.2) with Microsoft SMTP Server (TLS) id 8.1.291.1; Wed, 5 Nov 2008 16:51:53 +0000
Received: from EA-EXMSG-C332.europe.corp.microsoft.com ([169.254.2.235]) by DUB-EXHUB-C302.europe.corp.microsoft.com ([65.53.213.92]) with mapi; Wed, 5 Nov 2008 16:51:53 +0000
From: Stefan Santesson <[e-mail]>
To: pkix <[e-mail]>
Date: Wed, 5 Nov 2008 16:51:48 +0000
Subject: FINAL CALL: Call for agenda items, Philadelphia IETF
Thread-Topic: FINAL CALL: Call for agenda items, Philadelphia IETF
Thread-Index: Achz4rCMDGHAmfpxQ526+JqfDUXcDzLgnTnw
Message-ID: <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_9F11911AED01D24BAA1C2355723C3D32195AC47236EAEXMSGC332eu_"
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>

--_000_9F11911AED01D24BAA1C2355723C3D32195AC47236EAEXMSGC332eu_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I have timeslot requests for the following PKIX work items:

*         Trust Anchor Management

*         Other certs extension

*         Clearance attribute and CA clearance constraints

*         PKI resource query protocol

*         RFC3281 updates

I still lack information if any editor wants to address the following WG it=
ems:

*         ECC Subject public key info

*         RFC 4055 update

*         New ASN.1 modules for PKIX

*         Algorithm identifiers for SHA2

*         Traceable anonymous certificates

I have no requests for additional topics.


REQUIRED ACTIONS:
Can someone from each lacking WG item please let me know if you want any ti=
me slot.
We are also still open for other potential topics on the agenda.
But I need all requests by the end of this week.

Thank you.


Stefan Santesson
Senior Program Manager
Windows Security, Standards

From: [e-mail] [mailto:[e-mail]] On=
 Behalf Of Stefan Santesson
Sent: den 20 februari 2008 18:05
To: pkix
Subject: Call for agenda items, Philadelphia IETF

Time to set the agenda for the Philadelphia PKIX meeting.

Anyone wanting a slot should send me an e-mail as soon as possible, no late=
r than EOD Wednesday next week (Feb 27).
As usual I want the lead editor for every current pkix draft to tell me if =
they want a slot or not.

We are currently scheduled as a Monday morning session from 0900-1130, whic=
h means two things.
1) We have 2.5 hours available which should be plenty of time.
2) We need to have everything set, including presentations sent to me by Su=
nday night.


Stefan Santesson
Senior Program Manager
Windows Security, Standards


--_000_9F11911AED01D24BAA1C2355723C3D32195AC47236EAEXMSGC332eu_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:p=3D"urn:schemas-m=
icrosoft-com:office:powerpoint" xmlns:a=3D"urn:schemas-microsoft-com:office=
:access" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s=3D"=
uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs=3D"urn:schemas-microsof=
t-com:rowset" xmlns:z=3D"#RowsetSchema" xmlns:b=3D"urn:schemas-microsoft-co=
m:office:publisher" xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadshee=
t" xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns=
:odc=3D"urn:schemas-microsoft-com:office:odc" xmlns:oa=3D"urn:schemas-micro=
soft-com:office:activation" xmlns:html=3D"http://www.w3.org/TR/REC-html40" =
xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:D=3D"DAV:" xmln=
s:x2=3D"http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ois=3D"ht=
tp://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir=3D"http://schema=
s.microsoft.com/sharepoint/soap/directory/" xmlns:ds=3D"http://www.w3.org/2=
000/09/xmldsig#" xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint/dsp" =
xmlns:udc=3D"http://schemas.microsoft.com/data/udc" xmlns:xsd=3D"http://www=
.w3.org/2001/XMLSchema" xmlns:sub=3D"http://schemas.microsoft.com/sharepoin=
t/soap/2002/1/alerts/" xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#" xmlns=
:sp=3D"http://schemas.microsoft.com/sharepoint/" xmlns:sps=3D"http://schema=
s.microsoft.com/sharepoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001/XMLSc=
hema-instance" xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile=
" xmlns:wf=3D"http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns=
:mver=3D"http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns=
:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns:mrels=3D"http=
://schemas.openxmlformats.org/package/2006/relationships" xmlns:ex12t=3D"ht=
tp://schemas.microsoft.com/exchange/services/2006/types" xmlns:ex12m=3D"htt=
p://schemas.microsoft.com/exchange/services/2006/messages" xmlns:Z=3D"urn:s=
chemas-microsoft-com:" xmlns:st=3D"&#1;" xmlns=3D"http://www.w3.org/TR/REC-=
html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:"\@SimSun";
	panose-1:2 1 6 0 3 1 1 1 1 1;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
	{mso-style-priority:34;
	margin-top:0cm;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:36.0pt;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
span.EmailStyle18
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.EmailStyle19
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 @list l0
	{mso-list-id:1027682776;
	mso-list-type:hybrid;
	mso-list-template-ids:-1317393742 69009409 69009411 69009413 69009409 6900=
9411 69009413 69009409 69009411 69009413;}
@list l0:level1
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	font-family:Symbol;}
@list l1
	{mso-list-id:1397900729;
	mso-list-type:hybrid;
	mso-list-template-ids:635612220 69009409 69009411 69009413 69009409 690094=
11 69009413 69009409 69009411 69009413;}
@list l1:level1
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	font-family:Symbol;}
ol
	{margin-bottom:0cm;}
ul
	{margin-bottom:0cm;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DSV link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><a name=3D"_MailEndCompose"><span lang=3DEN-US style=
=3D'color:
#1F497D'>I have timeslot requests for the following PKIX work items:<o:p></=
o:p></span></a></p>

<p class=3DMsoListParagraph style=3D'text-indent:-18.0pt;mso-list:l1 level1=
 lfo1'><![if !supportLists]><span
lang=3DEN-US style=3D'font-family:Symbol;color:#1F497D'><span style=3D'mso-=
list:Ignore'>&middot;<span
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;
</span></span></span><![endif]><span lang=3DEN-US style=3D'color:#1F497D'>T=
rust
Anchor Management<o:p></o:p></span></p>

<p class=3DMsoListParagraph style=3D'text-indent:-18.0pt;mso-list:l1 level1=
 lfo1'><![if !supportLists]><span
lang=3DEN-US style=3D'font-family:Symbol;color:#1F497D'><span style=3D'mso-=
list:Ignore'>&middot;<span
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;
</span></span></span><![endif]><span lang=3DEN-US style=3D'color:#1F497D'>O=
ther
certs extension<o:p></o:p></span></p>

<p class=3DMsoListParagraph style=3D'text-indent:-18.0pt;mso-list:l1 level1=
 lfo1'><![if !supportLists]><span
lang=3DEN-US style=3D'font-family:Symbol;color:#1F497D'><span style=3D'mso-=
list:Ignore'>&middot;<span
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;
</span></span></span><![endif]><span lang=3DEN-US style=3D'color:#1F497D'>C=
learance
attribute and CA clearance constraints<o:p></o:p></span></p>

<p class=3DMsoListParagraph style=3D'text-indent:-18.0pt;mso-list:l1 level1=
 lfo1'><![if !supportLists]><span
lang=3DEN-US style=3D'font-family:Symbol;color:#1F497D'><span style=3D'mso-=
list:Ignore'>&middot;<span
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;
</span></span></span><![endif]><span lang=3DEN-US style=3D'color:#1F497D'>P=
KI
resource query protocol<o:p></o:p></span></p>

<p class=3DMsoListParagraph style=3D'text-indent:-18.0pt;mso-list:l1 level1=
 lfo1'><![if !supportLists]><span
lang=3DEN-US style=3D'font-family:Symbol;color:#1F497D'><span style=3D'mso-=
list:Ignore'>&middot;<span
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;
</span></span></span><![endif]><span lang=3DEN-US style=3D'color:#1F497D'>R=
FC3281
updates<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'><o:p>&nbsp;=
</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'>I still lac=
k
information if any editor wants to address the following WG items:<o:p></o:=
p></span></p>

<p class=3DMsoListParagraph style=3D'text-indent:-18.0pt;mso-list:l0 level1=
 lfo2'><![if !supportLists]><span
lang=3DEN-US style=3D'font-family:Symbol;color:#1F497D'><span style=3D'mso-=
list:Ignore'>&middot;<span
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;
</span></span></span><![endif]><span lang=3DEN-US style=3D'color:#1F497D'>E=
CC Subject
public key info <o:p></o:p></span></p>

<p class=3DMsoListParagraph style=3D'text-indent:-18.0pt;mso-list:l0 level1=
 lfo2'><![if !supportLists]><span
lang=3DEN-US style=3D'font-family:Symbol;color:#1F497D'><span style=3D'mso-=
list:Ignore'>&middot;<span
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;
</span></span></span><![endif]><span lang=3DEN-US style=3D'color:#1F497D'>R=
FC 4055 update<o:p></o:p></span></p>

<p class=3DMsoListParagraph style=3D'text-indent:-18.0pt;mso-list:l0 level1=
 lfo2'><![if !supportLists]><span
lang=3DEN-US style=3D'font-family:Symbol;color:#1F497D'><span style=3D'mso-=
list:Ignore'>&middot;<span
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;
</span></span></span><![endif]><span lang=3DEN-US style=3D'color:#1F497D'>N=
ew ASN.1
modules for PKIX<o:p></o:p></span></p>

<p class=3DMsoListParagraph style=3D'text-indent:-18.0pt;mso-list:l0 level1=
 lfo2'><![if !supportLists]><span
lang=3DEN-US style=3D'font-family:Symbol;color:#1F497D'><span style=3D'mso-=
list:Ignore'>&middot;<span
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;
</span></span></span><![endif]><span lang=3DEN-US style=3D'color:#1F497D'>A=
lgorithm
identifiers for SHA2<o:p></o:p></span></p>

<p class=3DMsoListParagraph style=3D'text-indent:-18.0pt;mso-list:l0 level1=
 lfo2'><![if !supportLists]><span
lang=3DEN-US style=3D'font-family:Symbol;color:#1F497D'><span style=3D'mso-=
list:Ignore'>&middot;<span
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;
</span></span></span><![endif]><span lang=3DEN-US style=3D'color:#1F497D'>T=
raceable
anonymous certificates<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'><o:p>&nbsp;=
</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'>I have no r=
equests
for additional topics.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'><o:p>&nbsp;=
</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'><o:p>&nbsp;=
</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'>REQUIRED AC=
TIONS:<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'>Can someone=
 from each
lacking WG item please let me know if you want any time slot.<o:p></o:p></s=
pan></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'>We are also=
 still
open for other potential topics on the agenda.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'>But I need =
all
requests by the end of this week.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'><o:p>&nbsp;=
</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'>Thank you.<=
o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'><o:p>&nbsp;=
</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'><o:p>&nbsp;=
</o:p></span></p>

<div>

<p class=3DMsoNormal><b><span lang=3DEN-GB style=3D'font-size:10.0pt;font-f=
amily:
"Arial","sans-serif";color:maroon'>Stefan Santesson</span></b><span lang=3D=
EN-GB
style=3D'font-size:12.0pt;font-family:"Times New Roman","serif";color:#1F49=
7D'><o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-GB style=3D'font-size:10.0pt;font-fami=
ly:"Arial","sans-serif";
color:#400040'>Senior Program Manager</span><span lang=3DEN-GB style=3D'fon=
t-size:
12.0pt;font-family:"Times New Roman","serif";color:navy'><o:p></o:p></span>=
</p>

<p class=3DMsoNormal><b><span lang=3DEN-GB style=3D'font-size:10.0pt;font-f=
amily:
"Arial","sans-serif";color:#400040'>Windows Security, Standards</span></b><=
span
lang=3DEN-US style=3D'color:#1F497D'><o:p></o:p></span></p>

</div>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'><o:p>&nbsp;=
</o:p></span></p>

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

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm =
0cm 0cm'>

<p class=3DMsoNormal><b><span lang=3DEN-US style=3D'font-size:10.0pt;font-f=
amily:
"Tahoma","sans-serif"'>From:</span></b><span lang=3DEN-US style=3D'font-siz=
e:10.0pt;
font-family:"Tahoma","sans-serif"'> [e-mail]
[mailto:[e-mail]] <b>On Behalf Of </b>Stefan Santesson<=
br>
<b>Sent:</b> den 20 februari 2008 18:05<br>
<b>To:</b> pkix<br>
<b>Subject:</b> Call for agenda items, Philadelphia IETF<o:p></o:p></span><=
/p>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal><span lang=3DEN-US>Time to set the agenda for the Phil=
adelphia
PKIX meeting.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US>Anyone wanting a slot should send m=
e an
e-mail as soon as possible, no later than EOD Wednesday next week (Feb 27).=
<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US>As usual I want the lead editor for=
 every
current pkix draft to tell me if they want a slot or not.<o:p></o:p></span>=
</p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US>We are currently scheduled as a Mon=
day morning
session from 0900-1130, which means two things.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US>1) We have 2.5 hours available whic=
h should
be plenty of time.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US>2) We need to have everything set,
including presentations sent to me by Sunday night.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><b><span lang=3DEN-GB style=3D'font-size:10.0pt;font-f=
amily:
"Arial","sans-serif";color:maroon'>Stefan Santesson</span></b><span lang=3D=
EN-GB
style=3D'font-size:12.0pt;font-family:"Times New Roman","serif";color:#1F49=
7D'><o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-GB style=3D'font-size:10.0pt;font-fami=
ly:"Arial","sans-serif";
color:#400040'>Senior Program Manager</span><span lang=3DEN-GB style=3D'fon=
t-size:
12.0pt;font-family:"Times New Roman","serif";color:navy'><o:p></o:p></span>=
</p>

<p class=3DMsoNormal><b><span lang=3DEN-GB style=3D'font-size:10.0pt;font-f=
amily:
"Arial","sans-serif";color:#400040'>Windows Security, Standards</span></b><=
span
lang=3DEN-US style=3D'color:#1F497D'><o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

</div>

</div>

</body>

</html>

--_000_9F11911AED01D24BAA1C2355723C3D32195AC47236EAEXMSGC332eu_--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA58swAU060055 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Nov 2008 01:54:58 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA58swOU060054; Wed, 5 Nov 2008 01:54:58 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pne-smtpout1-sn2.hy.skanova.net (pne-smtpout1-sn2.hy.skanova.net [81.228.8.83]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA58slib060032 for <[e-mail]>; Wed, 5 Nov 2008 01:54:58 -0700 (MST) (envelope-from [e-mail])
Received: from AndersPC (81.232.45.215) by pne-smtpout1-sn2.hy.skanova.net (7.3.129) id 48A144C50168EC09; Wed, 5 Nov 2008 09:54:44 +0100
Message-ID: <ECC31DDE62B1426589DCCB255AB9F810@AndersPC>
From: "Anders Rundgren" <[e-mail]>
To: "Arshad Noor" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]> <B9A9F0E608D94D2CA899102A88789787@AndersPC> <[e-mail]> <87FE58DD430A4A48B3B2A522F95DB5AF@AndersPC> <[e-mail]> <BF063727CD004F48A55526D90AABB206@AndersPC> <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: SKSML Was: Signing and Encrypting with the same key?
Date: Wed, 5 Nov 2008 09:54:30 +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 Windows Mail 6.0.6000.20661
X-MIMEOLE: Produced By Microsoft MimeOLE V6.0.6000.16669
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Arshad,

Pardon my ignorance but I do not see how you can "abstract out" security solutions in a concrete 
SOAP specification, either it is there or it is not.  That is, with respect to the particular 
question and the current draft, you have no real alternative except stating that client and servers 
must be configured to support a common convention.  Which BTW may be exactly what you meant :-) 
That KeyGen2 is a 6-pass protocol is for avoiding conventions since the entities involved typically 
do not belong to the same "IT-domain".  E.g. a consumer with a mobile phone and his/her bank.

Regarding the separate key stuff, the current strategy is to support it in the protocol, but not in 
the Open Source client-implementation since no compelling argument actually has been raised for 
having multiple keys, while there is quite a bunch of arguments against such an arrangement.  How is 
an SKSML server supposed to know what to encrypt with if you do not send the key in the request?  It 
seems that an SKSML server must keep an encryption key database or be configured to use LDAP etc. 
It seems like a more straightforward solution to transfer encryption keys explicitly and validate 
them at receival in the same way as you do with signature and authentication keys.

I'm a bit puzzled regarding how you intend to bootstrap SKSML with PKI, if the figures with a myriad 
of entirely different clients are still valid.  The reason I started the KeyGen2 effort is because 
this is a veritable nightmare, particularly for mobile devices.  As a comparison I would like to 
mention the fact that there are some 100M TPM chips out there in major laptops, but they are "mostly 
of out work" because the bootstrapping issues haven't been fully addressed by the TPM designers.

Anders

----- Original Message ----- 
From: "Arshad Noor" <[e-mail]>
To: "Anders Rundgren" <[e-mail]>
Cc: "Timothy J. Miller" <[e-mail]>; "Peter Gutmann" <[e-mail]>; 
<[e-mail]>
Sent: Tuesday, November 04, 2008 22:24
Subject: Re: Signing and Encrypting with the same key?



Hi Anders,

The reason we haven't mentioned it yet is because the TC is going
to begin the task of creating Implementation, Operations and Audit
Guidelines for EKMI only in 2009.  It is within these guidelines
where a recommendation for separating signing & encryption key-pairs
would be made.

The SKSML protocol focuses on the minimum necessary syntax to send
and receive messages related to symmetric-key management.  The
security, implementation, operations and audit of such Enterprise
Key Management Infrastructures must be capable of being abstracted
out of the protocol, layered and managed independently.  Which is
why there is no mention of separated key-pairs yet.  However, you
can expect to see it in the Guidelines next year.

Arshad Noor
StrongAuth, Inc.


Anders Rundgren wrote:
> Hi Arshad,
> I just skimmed through the non-normative spec and example and from that I could not see any
> mentioning of separate keys.
>
> I digged a bit further but could still not find such references in:
> http://www.oasis-open.org/committees/download.php/28725/SKSML-1.0-Specification-Normative-DRAFT6.0.pdf
>
> I don't know what you have planned, but IMO you need additional elements in the protocol (like
> giving the client a place to put its encryption key), as well as a standard for how encryption and
> signature keys link together otherwise the server cannot be sure that it is encrypting for the
> client that authenticated.  All this is the reason why I'm not overly enthusiastic of having
> multiple entity-keys in a provisioning protocol, particularly since all attacks I have heard about
> to date, have been based on flawed implementations, which is moderately interesting from a
> *protocol-design* point-of-view:
> http://www.imc.org/ietf-openpgp/mail-archive/msg14307.html
>
> But it is possible that SKSML will run in more restricted environments than KeyGen2 and thus can
> build on that the client and servers use "conventions", keeping the protocol smallish.   KeyGen2 
> is
> designed to cope with a fragmented world and thus sports a capability/policy negotiation facility.
>
> Anders
>
> ----- Original Message ----- 
> From: "Arshad Noor" <[e-mail]>
> To: "Anders Rundgren" <[e-mail]>
> Cc: "Timothy J. Miller" <[e-mail]>; "Peter Gutmann" <[e-mail]>;
> <[e-mail]>
> Sent: Tuesday, November 04, 2008 21:11
> Subject: Re: Signing and Encrypting with the same key?
>
>
> Anders,
>
> Just to clarify, the SKSML protocol does not mandate how the
> digital certificate of SKMS clients and servers should be
> constructed, or what the keyUsage extension should look like
> within such certificates.  We believe that that is an
> implementation detail of the PKI that supports the SKMS.
>
> The SKMS only requires that every client and server have a
> signing key and an encryption key.  They can be the same
> key-pair or two different key-pairs, depending on the PKI
> certificate policy of the implementation site.
>
> Within the open-source StrongKey software we have, we require
> two digital certificates to be configured for SKMS clients and
> servers, to separate signing and encryption uses.  The test
> certs we bundle with the FOSS, combines signing & encryption
> merely as a convenience for people "kicking the tires".
>
> As a conservative practice, we recommend that PKIs separate
> the signing and encryption capability into different digital
> certificates.
>
> Arshad Noor
> StrongAuth, Inc.
>
> Anders Rundgren wrote:
>> Another reference is OASIS EKMI:
>> http://www.oasis-open.org/committees/download.php/28657/SKSML-1.0-Specification-Non-Normative-DRAFT6.pdf
>> From what I can deduct they indeed authenticate the requesting client through a signature and 
>> then
>> return the key by wrapping it by the public signature key.
>>
>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA4LOV6k020377 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Nov 2008 14:24:31 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA4LOVpj020376; Tue, 4 Nov 2008 14:24:31 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mailhost.noorhome.net (adsl-63-194-79-229.dsl.snfc21.pacbell.net [63.194.79.229]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA4LOVAl020369 for <[e-mail]>; Tue, 4 Nov 2008 14:24:31 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.noorhome.net (Postfix) with ESMTP id 9FF163AF1D5; Tue,  4 Nov 2008 16:00:32 -0500 (EST)
X-Spam-Score: -2.886
X-Spam-Level: 
X-Spam-Status: No, score=-2.886 tagged_above=-10 required=6.6 tests=[ALL_TRUSTED=-1.8, BAYES_00=-2.599, DNS_FROM_SECURITYSAGE=1.513]
Received: from mailhost.noorhome.net ([127.0.0.1]) by localhost (mailhost.noorhome.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14w6qt0Kf1v7; Tue,  4 Nov 2008 16:00:31 -0500 (EST)
Received: from poseidon.noorhome.net (poseidon.noorhome.net [192.168.0.9]) by mailhost.noorhome.net (Postfix) with ESMTP id F2A2C3AF1A6; Tue,  4 Nov 2008 16:00:30 -0500 (EST)
Message-ID: <[e-mail]>
Date: Tue, 04 Nov 2008 13:24:28 -0800
From: Arshad Noor <[e-mail]>
Organization: StrongAuth, Inc.
User-Agent: Thunderbird 2.0.0.16 (X11/20080723)
MIME-Version: 1.0
To: Anders Rundgren <[e-mail]>
CC: "Timothy J. Miller" <[e-mail]>, Peter Gutmann <[e-mail]>, [e-mail]
Subject: Re: Signing and Encrypting with the same key?
References: <[e-mail]> <B9A9F0E608D94D2CA899102A88789787@AndersPC> <[e-mail]> <87FE58DD430A4A48B3B2A522F95DB5AF@AndersPC> <[e-mail]> <BF063727CD004F48A55526D90AABB206@AndersPC>
In-Reply-To: <BF063727CD004F48A55526D90AABB206@AndersPC>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Anders,

The reason we haven't mentioned it yet is because the TC is going
to begin the task of creating Implementation, Operations and Audit
Guidelines for EKMI only in 2009.  It is within these guidelines
where a recommendation for separating signing & encryption key-pairs
would be made.

The SKSML protocol focuses on the minimum necessary syntax to send
and receive messages related to symmetric-key management.  The
security, implementation, operations and audit of such Enterprise
Key Management Infrastructures must be capable of being abstracted
out of the protocol, layered and managed independently.  Which is
why there is no mention of separated key-pairs yet.  However, you
can expect to see it in the Guidelines next year.

Arshad Noor
StrongAuth, Inc.


Anders Rundgren wrote:
> Hi Arshad,
> I just skimmed through the non-normative spec and example and from that I could not see any
> mentioning of separate keys.
> 
> I digged a bit further but could still not find such references in:
> http://www.oasis-open.org/committees/download.php/28725/SKSML-1.0-Specification-Normative-DRAFT6.0.pdf
> 
> I don't know what you have planned, but IMO you need additional elements in the protocol (like 
> giving the client a place to put its encryption key), as well as a standard for how encryption and 
> signature keys link together otherwise the server cannot be sure that it is encrypting for the 
> client that authenticated.  All this is the reason why I'm not overly enthusiastic of having 
> multiple entity-keys in a provisioning protocol, particularly since all attacks I have heard about 
> to date, have been based on flawed implementations, which is moderately interesting from a 
> *protocol-design* point-of-view:
> http://www.imc.org/ietf-openpgp/mail-archive/msg14307.html
> 
> But it is possible that SKSML will run in more restricted environments than KeyGen2 and thus can 
> build on that the client and servers use "conventions", keeping the protocol smallish.   KeyGen2 is 
> designed to cope with a fragmented world and thus sports a capability/policy negotiation facility.
> 
> Anders
> 
> ----- Original Message ----- 
> From: "Arshad Noor" <[e-mail]>
> To: "Anders Rundgren" <[e-mail]>
> Cc: "Timothy J. Miller" <[e-mail]>; "Peter Gutmann" <[e-mail]>; 
> <[e-mail]>
> Sent: Tuesday, November 04, 2008 21:11
> Subject: Re: Signing and Encrypting with the same key?
> 
> 
> Anders,
> 
> Just to clarify, the SKSML protocol does not mandate how the
> digital certificate of SKMS clients and servers should be
> constructed, or what the keyUsage extension should look like
> within such certificates.  We believe that that is an
> implementation detail of the PKI that supports the SKMS.
> 
> The SKMS only requires that every client and server have a
> signing key and an encryption key.  They can be the same
> key-pair or two different key-pairs, depending on the PKI
> certificate policy of the implementation site.
> 
> Within the open-source StrongKey software we have, we require
> two digital certificates to be configured for SKMS clients and
> servers, to separate signing and encryption uses.  The test
> certs we bundle with the FOSS, combines signing & encryption
> merely as a convenience for people "kicking the tires".
> 
> As a conservative practice, we recommend that PKIs separate
> the signing and encryption capability into different digital
> certificates.
> 
> Arshad Noor
> StrongAuth, Inc.
> 
> Anders Rundgren wrote:
>> Another reference is OASIS EKMI:
>> http://www.oasis-open.org/committees/download.php/28657/SKSML-1.0-Specification-Non-Normative-DRAFT6.pdf
>> From what I can deduct they indeed authenticate the requesting client through a signature and then
>> return the key by wrapping it by the public signature key.
>>
> 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA4L8YWf019254 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Nov 2008 14:08:34 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA4L8YOq019253; Tue, 4 Nov 2008 14:08:34 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pne-smtpout1-sn1.fre.skanova.net (pne-smtpout1-sn1.fre.skanova.net [81.228.11.98]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA4L8NqP019233 for <[e-mail]>; Tue, 4 Nov 2008 14:08:34 -0700 (MST) (envelope-from [e-mail])
Received: from AndersPC (81.232.45.215) by pne-smtpout1-sn1.fre.skanova.net (7.3.129) id 47A979500489F790; Tue, 4 Nov 2008 22:08:18 +0100
Message-ID: <BF063727CD004F48A55526D90AABB206@AndersPC>
From: "Anders Rundgren" <[e-mail]>
To: "Arshad Noor" <[e-mail]>
Cc: "Timothy J. Miller" <[e-mail]>, "Peter Gutmann" <[e-mail]>, <[e-mail]>
References: <[e-mail]> <B9A9F0E608D94D2CA899102A88789787@AndersPC> <[e-mail]> <87FE58DD430A4A48B3B2A522F95DB5AF@AndersPC> <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: Re: Signing and Encrypting with the same key?
Date: Tue, 4 Nov 2008 22:08:01 +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 Windows Mail 6.0.6000.20661
X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16669
Sender: [e-mail]
Precedence: 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 Arshad,
I just skimmed through the non-normative spec and example and from that I could not see any
mentioning of separate keys.

I digged a bit further but could still not find such references in:
http://www.oasis-open.org/committees/download.php/28725/SKSML-1.0-Specification-Normative-DRAFT6.0.pdf

I don't know what you have planned, but IMO you need additional elements in the protocol (like 
giving the client a place to put its encryption key), as well as a standard for how encryption and 
signature keys link together otherwise the server cannot be sure that it is encrypting for the 
client that authenticated.  All this is the reason why I'm not overly enthusiastic of having 
multiple entity-keys in a provisioning protocol, particularly since all attacks I have heard about 
to date, have been based on flawed implementations, which is moderately interesting from a 
*protocol-design* point-of-view:
http://www.imc.org/ietf-openpgp/mail-archive/msg14307.html

But it is possible that SKSML will run in more restricted environments than KeyGen2 and thus can 
build on that the client and servers use "conventions", keeping the protocol smallish.   KeyGen2 is 
designed to cope with a fragmented world and thus sports a capability/policy negotiation facility.

Anders

----- Original Message ----- 
From: "Arshad Noor" <[e-mail]>
To: "Anders Rundgren" <[e-mail]>
Cc: "Timothy J. Miller" <[e-mail]>; "Peter Gutmann" <[e-mail]>; 
<[e-mail]>
Sent: Tuesday, November 04, 2008 21:11
Subject: Re: Signing and Encrypting with the same key?


Anders,

Just to clarify, the SKSML protocol does not mandate how the
digital certificate of SKMS clients and servers should be
constructed, or what the keyUsage extension should look like
within such certificates.  We believe that that is an
implementation detail of the PKI that supports the SKMS.

The SKMS only requires that every client and server have a
signing key and an encryption key.  They can be the same
key-pair or two different key-pairs, depending on the PKI
certificate policy of the implementation site.

Within the open-source StrongKey software we have, we require
two digital certificates to be configured for SKMS clients and
servers, to separate signing and encryption uses.  The test
certs we bundle with the FOSS, combines signing & encryption
merely as a convenience for people "kicking the tires".

As a conservative practice, we recommend that PKIs separate
the signing and encryption capability into different digital
certificates.

Arshad Noor
StrongAuth, Inc.

Anders Rundgren wrote:
>
> Another reference is OASIS EKMI:
> http://www.oasis-open.org/committees/download.php/28657/SKSML-1.0-Specification-Non-Normative-DRAFT6.pdf
> From what I can deduct they indeed authenticate the requesting client through a signature and then
> return the key by wrapping it by the public signature key.
>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA4KBpYm015121 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Nov 2008 13:11:51 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA4KBp0q015120; Tue, 4 Nov 2008 13:11:51 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mailhost.noorhome.net (adsl-63-194-79-229.dsl.snfc21.pacbell.net [63.194.79.229]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA4KBeVs015078 for <[e-mail]>; Tue, 4 Nov 2008 13:11:50 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.noorhome.net (Postfix) with ESMTP id E50A83AF1CD; Tue,  4 Nov 2008 14:47:41 -0500 (EST)
X-Spam-Score: -2.886
X-Spam-Level: 
X-Spam-Status: No, score=-2.886 tagged_above=-10 required=6.6 tests=[ALL_TRUSTED=-1.8, BAYES_00=-2.599, DNS_FROM_SECURITYSAGE=1.513]
Received: from mailhost.noorhome.net ([127.0.0.1]) by localhost (mailhost.noorhome.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jYb+Gyf7mMsf; Tue,  4 Nov 2008 14:47:40 -0500 (EST)
Received: from poseidon.noorhome.net (poseidon.noorhome.net [192.168.0.9]) by mailhost.noorhome.net (Postfix) with ESMTP id E1CE13AF1A6; Tue,  4 Nov 2008 14:47:40 -0500 (EST)
Message-ID: <[e-mail]>
Date: Tue, 04 Nov 2008 12:11:37 -0800
From: Arshad Noor <[e-mail]>
Organization: StrongAuth, Inc.
User-Agent: Thunderbird 2.0.0.16 (X11/20080723)
MIME-Version: 1.0
To: Anders Rundgren <[e-mail]>
CC: "Timothy J. Miller" <[e-mail]>, Peter Gutmann <[e-mail]>, [e-mail]
Subject: Re: Signing and Encrypting with the same key?
References: <[e-mail]> <B9A9F0E608D94D2CA899102A88789787@AndersPC> <[e-mail]> <87FE58DD430A4A48B3B2A522F95DB5AF@AndersPC>
In-Reply-To: <87FE58DD430A4A48B3B2A522F95DB5AF@AndersPC>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Anders,

Just to clarify, the SKSML protocol does not mandate how the
digital certificate of SKMS clients and servers should be
constructed, or what the keyUsage extension should look like
within such certificates.  We believe that that is an
implementation detail of the PKI that supports the SKMS.

The SKMS only requires that every client and server have a
signing key and an encryption key.  They can be the same
key-pair or two different key-pairs, depending on the PKI
certificate policy of the implementation site.

Within the open-source StrongKey software we have, we require
two digital certificates to be configured for SKMS clients and
servers, to separate signing and encryption uses.  The test
certs we bundle with the FOSS, combines signing & encryption
merely as a convenience for people "kicking the tires".

As a conservative practice, we recommend that PKIs separate
the signing and encryption capability into different digital
certificates.

Arshad Noor
StrongAuth, Inc.

Anders Rundgren wrote:
> 
> Another reference is OASIS EKMI:
> http://www.oasis-open.org/committees/download.php/28657/SKSML-1.0-Specification-Non-Normative-DRAFT6.pdf
> From what I can deduct they indeed authenticate the requesting client through a signature and then
> return the key by wrapping it by the public signature key.
> 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA3MdEgU004266 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Nov 2008 15:39:14 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA3MdECn004265; Mon, 3 Nov 2008 15:39:14 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.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 balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA3MdDg8004259 for <[e-mail]>; Mon, 3 Nov 2008 15:39:13 -0700 (MST) (envelope-from [e-mail])
Received: from Augustine.missi.ncsc.mil (augustine.missi.ncsc.mil [144.51.60.33]) by stingray.missi.ncsc.mil with ESMTP id mA3MdDM8005885 for <[e-mail]>; Mon, 3 Nov 2008 17:39:13 -0500 (EST)
Received: from DABECK.missi.ncsc.mil ([144.51.60.15]) by Augustine.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.3959); Mon, 3 Nov 2008 17:37:08 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C93E04.FEA9D2D6"
Subject: RE: Comments on the TA requirements document
Date: Mon, 3 Nov 2008 17:39:13 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Comments on the TA requirements document
Thread-Index: Ack1Gw5RwCiacYlDQg28ouWioo7jOwAAqt+wAADFKSAAAPbXgAAKFblQAD7RurAB7h3cUA==
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Kemp, David P." <[e-mail]>
To: <[e-mail]>
X-OriginalArrivalTime: 03 Nov 2008 22:37:08.0359 (UTC) FILETIME=[B45D8970:01C93E04]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C93E04.FEA9D2D6
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

Stefan,

=20

I can understand a distinction between "what must be done" and "how to
do it".  I can also draw a correlation between the XCCDF language that
specifies security configuration checklists and the OVAL language that
supports platform-dependent execution and reporting for checklist items
(http://scap.nist.gov).  What I don't understand is how:

=20

3.3.1.  Functional Requirements

=20

   A protocol for TA management must allow a TA management transaction

   to be directed to:

=20

      All TA stores for which the manager is responsible

      An enumerated list of one or more groups of trust anchor stores

      An individual trust anchor store

=20

would be considered to favor combined specification/execution over
separate specification of what to keys to trust and how to obtain them.
Would it help if it said "A protocol *suite* for TA management ..." to
encompass the possibility of multiple languages / stages of execution?

=20

(It may not be immediately obvious that PKIX is the correct WG to
develop a TAM suite if the end product would be implemented under SCAP,
but the TA-specific expertise is undeniably in this group.)

=20

Dave

=20

=20

From: Stefan Santesson [mailto:[e-mail]]=20
Sent: Friday, October 24, 2008 10:48 PM
To: Kemp, David P.; [e-mail]
Subject: RE: Comments on the TA requirements document

=20

Dave

=20

This is not a matter of transport protocol. This is a matter of how you
manage policies and what protocols you need to support both management
and execution of these policies.

=20

The current requirement document mix together policy management and
policy execution in one bucket for TA management.

=20

The policy management part deals with ensuring that all hosts knows what
keys they are allowed to trust.

The policy execution part deals with obtaining the keys and parameters
associated with managed policies and to put them in use in a compliant
manner.

=20

Policy management is always initiated and managed centrally and pushed
down to users/hosts, or at least enforced upon users/hosts in some way
or another. There are many ways to do this, but it always involves some
kind of central management. One way to do this that is very common in my
world, is to use a directory as the central mechanism to publish
policies combined with other functions (like system health checks) to
make sure hat policies has been downloaded and implemented. In these
common cases, there is no need for any new protocol.

=20

Policy execution is something that is carried out by the user/host,
based on the centrally distributed policy. One part of policy execution
in this case is to obtain/download the TAs that are considered
trustworthy by the distributed policy. Since the user/host is in control
and thus responsible for policy execution, they can also "pull" down any
key data associated with the TA policy. The only thing they would need
in order to do that, is a common data format for TA keys and their
parameters, signed by some kind of "master" TA policy management key.
That common data format for TA key information is all I currently need.

We may convince ourselves that we can make a central manager in control
of policy execution on behalf of users/hosts if we write a super smart
protocol (like PKIX TAM), but that would be an illusion. To some extent
we will always need to trust the user/host to carry out the policy in an
appropriate manner.

=20

This is the world I'm coming from when approaching this subject. When I
read the req document for TA management I do not recognize any protocol
that fit the needs of my environment.=20

This is why I have problems providing constructive feedback on it.

=20

=20

Stefan Santesson

Senior Program Manager

Windows Security, Standards

=20


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

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" =
xmlns:p=3D"urn:schemas-microsoft-com:office:powerpoint" =
xmlns:a=3D"urn:schemas-microsoft-com:office:access" =
xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" =
xmlns:s=3D"uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" =
xmlns:rs=3D"urn:schemas-microsoft-com:rowset" xmlns:z=3D"#RowsetSchema" =
xmlns:b=3D"urn:schemas-microsoft-com:office:publisher" =
xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadsheet" =
xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" =
xmlns:odc=3D"urn:schemas-microsoft-com:office:odc" =
xmlns:oa=3D"urn:schemas-microsoft-com:office:activation" =
xmlns:html=3D"http://www.w3.org/TR/REC-html40" =
xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:D=3D"DAV:" =
xmlns:x2=3D"http://schemas.microsoft.com/office/excel/2003/xml" =
xmlns:ois=3D"http://schemas.microsoft.com/sharepoint/soap/ois/" =
xmlns:dir=3D"http://schemas.microsoft.com/sharepoint/soap/directory/" =
xmlns:ds=3D"http://www.w3.org/2000/09/xmldsig#" =
xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint/dsp" =
xmlns:udc=3D"http://schemas.microsoft.com/data/udc" =
xmlns:xsd=3D"http://www.w3.org/2001/XMLSchema" =
xmlns:sub=3D"http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/"=
 xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#" =
xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" =
xmlns:sps=3D"http://schemas.microsoft.com/sharepoint/soap/" =
xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance" =
xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" =
xmlns:wf=3D"http://schemas.microsoft.com/sharepoint/soap/workflow/" =
xmlns:mver=3D"http://schemas.openxmlformats.org/markup-compatibility/2006=
" xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns:mrels=3D"http://schemas.openxmlformats.org/package/2006/relationshi=
ps" =
xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/2006/types"=
 =
xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/2006/messag=
es" xmlns:Z=3D"urn:schemas-microsoft-com:" xmlns:st=3D"&#1;" =
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=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p
	{mso-style-priority:99;
	mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
pre
	{mso-style-priority:99;
	mso-style-link:"HTML Preformatted Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Courier New";}
span.HTMLPreformattedChar
	{mso-style-name:"HTML Preformatted Char";
	mso-style-priority:99;
	mso-style-link:"HTML Preformatted";
	font-family:"Courier New";}
span.EmailStyle20
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.EmailStyle21
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.h41
	{mso-style-name:h41;
	font-family:"Courier New";
	font-weight:bold;}
span.EmailStyle23
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle24
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle25
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:8.5in 11.0in;
	margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'>Stefan,<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>I can understand a =
distinction
between &#8220;what must be done&#8221; and &#8220;how to do =
it&#8221;.&nbsp; I can also draw a correlation
between the XCCDF language that specifies security configuration =
checklists and
the OVAL language that supports platform-dependent execution and =
reporting for
checklist items (http://scap.nist.gov).&nbsp; What I don&#8217;t =
understand is how:<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><b><span lang=3DEN =
style=3D'font-size:12.0pt;font-family:"Courier New"'>3.3.1.&nbsp;
Functional Requirements</span></b><span lang=3DEN =
style=3D'font-size:12.0pt;
font-family:"Courier New"'><o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN =
style=3D'font-size:12.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN =
style=3D'font-size:12.0pt;font-family:"Courier New"'>&nbsp;&nbsp;
A protocol for TA management must allow a TA management =
transaction<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN =
style=3D'font-size:12.0pt;font-family:"Courier New"'>&nbsp;&nbsp;
to be directed to:<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN =
style=3D'font-size:12.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN =
style=3D'font-size:12.0pt;font-family:"Courier =
New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
All TA stores for which the manager is responsible<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN =
style=3D'font-size:12.0pt;font-family:"Courier =
New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
An enumerated list of one or more groups of trust anchor =
stores<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN =
style=3D'font-size:12.0pt;font-family:"Courier =
New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
An individual trust anchor store<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>would be considered =
to favor
combined specification/execution over separate specification of what to =
keys to
trust and how to obtain them.&nbsp; &nbsp;Would it help if it said =
&#8220;A protocol *<b>suite</b>*
for TA management &#8230;&#8221; to encompass the possibility of =
multiple languages /
stages of execution?<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>(It may not be =
immediately
obvious that PKIX is the correct WG to develop a TAM suite if the end =
product would
be implemented under SCAP, but the TA-specific expertise is undeniably =
in this
group.)<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'>Dave<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt =
0in 0in 0in'>

<p class=3DMsoNormal><b><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span>=
</b><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Stefan =
Santesson
[mailto:[e-mail]] <br>
<b>Sent:</b> Friday, October 24, 2008 10:48 PM<br>
<b>To:</b> Kemp, David P.; [e-mail]<br>
<b>Subject:</b> RE: Comments on the TA requirements =
document<o:p></o:p></span></p>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal><a name=3D"_MailEndCompose"><span =
style=3D'color:#1F497D'>Dave</span></a><span
style=3D'color:#1F497D'><o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>This is not a matter =
of
transport protocol. This is a matter of how you manage policies and what
protocols you need to support both management and execution of these =
policies.<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>The current =
requirement document
mix together policy management and policy execution in one bucket for TA
management.<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>The policy management =
part deals
with ensuring that all hosts knows what keys they are allowed to =
trust.<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>The policy execution =
part deals
with obtaining the keys and parameters associated with managed policies =
and to
put them in use in a compliant manner.<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>Policy management is =
always
initiated and managed centrally and pushed down to users/hosts, or at =
least
enforced upon users/hosts in some way or another. There are many ways to =
do
this, but it always involves some kind of central management. One way to =
do
this that is very common in my world, is to use a directory as the =
central
mechanism to publish policies combined with other functions (like system =
health
checks) to make sure hat policies has been downloaded and implemented. =
In these
common cases, there is no need for any new =
protocol.<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>Policy execution is =
something
that is carried out by the user/host, based on the centrally distributed
policy. One part of policy execution in this case is to obtain/download =
the TAs
that are considered trustworthy by the distributed policy. Since the =
user/host
is in control and thus responsible for policy execution, they can also =
&#8220;pull&#8221;
down any key data associated with the TA policy. The only thing they =
would need
in order to do that, is a common data format for TA keys and their =
parameters,
signed by some kind of &#8220;master&#8221; TA policy management key. =
That common data
format for TA key information is all I currently =
need.<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>We may convince =
ourselves that
we can make a central manager in control of policy execution on behalf =
of
users/hosts if we write a super smart protocol (like PKIX TAM), but that =
would
be an illusion. To some extent we will always need to trust the =
user/host to
carry out the policy in an appropriate manner.<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>This is the world =
I&#8217;m coming
from when approaching this subject. When I read the req document for TA
management I do not recognize any protocol that fit the needs of my
environment. <o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>This is why I have =
problems
providing constructive feedback on it.<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div>

<p class=3DMsoNormal><b><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:
"Arial","sans-serif";color:maroon'>Stefan Santesson</span></b><span =
lang=3DEN-GB
style=3D'font-size:12.0pt;font-family:"Times New =
Roman","serif";color:#1F497D'><o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:#400040'>Senior Program Manager</span><span lang=3DEN-GB =
style=3D'font-size:
12.0pt;font-family:"Times New =
Roman","serif";color:navy'><o:p></o:p></span></p>

<p class=3DMsoNormal><b><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:
"Arial","sans-serif";color:#400040'>Windows Security, =
Standards</span></b><span
style=3D'color:#1F497D'><o:p></o:p></span></p>

</div>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>

</div>

</body>

</html>

------_=_NextPart_001_01C93E04.FEA9D2D6--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA3M3LnE000388 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Nov 2008 15:03:21 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA3M3Lgi000387; Mon, 3 Nov 2008 15:03:21 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.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 balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA3M3AYN000352 for <[e-mail]>; Mon, 3 Nov 2008 15:03:21 -0700 (MST) (envelope-from [e-mail])
Received: from Augustine.missi.ncsc.mil (augustine.missi.ncsc.mil [144.51.60.33]) by stingray.missi.ncsc.mil with ESMTP id mA3M397M004255 for <[e-mail]>; Mon, 3 Nov 2008 17:03:09 -0500 (EST)
Received: from DABECK.missi.ncsc.mil ([144.51.60.15]) by Augustine.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.3959); Mon, 3 Nov 2008 17:01:04 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Processing rules for non-critical extensions (Re: Rationales for CA clearance constraints)
Date: Mon, 3 Nov 2008 17:03:09 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Processing rules for non-critical extensions (Re: Rationales for CA clearance constraints)
Thread-Index: Ack971/XsFJVbdLKQNmHtJ8saq3VzQABL88w
References: <[e-mail] osoft.com> <p06240500c52b6b1ec3cf@[10.242.22.83]> <[e-mail] osoft.com> <p0624081ac52c289bcda0@[10.20.30.152]> <[e-mail]> <p06240512c52c94298261@[193.0.24.250]> <[e-mail]> <p06240507c52d9fe588ca@[193.0.24.250]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Kemp, David P." <[e-mail]>
To: <[e-mail]>
X-OriginalArrivalTime: 03 Nov 2008 22:01:04.0937 (UTC) FILETIME=[AADD8990:01C93DFF]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

CAs and application developers look to X.509 to understand the meaning
of an extension.  If a hypothetical discussion resulted in consensus to
change X.509's treatment of name constraints to not depend on
criticality, then a [non-PKIX] CA's decision to mark name constraints
non-critical would be based on the behavior described in the new X.509.

My "assumption" is of course contrary to X.509, otherwise there would be
no basis for a proposed change.  From 5280:

   If a name constraints extension that is marked as critical
   imposes constraints on a particular name form, and an instance of
   that name form appears in the subject field or subjectAltName
   extension of a subsequent certificate, then the application MUST
   either process the constraint or reject the certificate.

This does not say that *any* unsupported constraint would reject the
certificate, only an unsupported constraint on any subject name form
used in the path.  An application that *uses* a name form (for example,
dNSName) must be able to understand that name form, and arguably should
be required to also support constraints on that name form (where
constraints can be defined).  For name forms that appear in the cert
path but are ignored by the application, constraints are trivially
"processed" and satisfied without any explicit action.

So the argument to the X.500 WG would be that for a critical or
non-critical nameConstraints, the "best" course of action would be
similar to (1) below: reject the certificate since it cannot process
every element of the extension that (a) applies to any subject of a
subsequent certificate that (b) is used by the application.
Why would any CA believe it worthwhile to specify constraints that
applications are permitted to selectively enforce?

Am I planning to propose such a change?  No.  But if a discussion of
criticality happened to occur, I would advocate the position of equal
treatment.

Dave



-----Original Message-----

> Thus a client that can process nameConstraints on some name forms but=20
> that encounters a non-critical nameConstraints extension with a name=20
> form that it cannot process must do one of the following: (1) reject
the=20
> certificate since it cannot process every element of the extension;
(2)=20
> ignore the extension entirely; or (3) process the extension to the=20
> degree possible and ignore the presence of the name forms that it
cannot=20
> process.  Option (3) is the one specified by X.509.  Isn't it also the

> option that most closely aligns with the CA's intention in marking the

> extension non-critical?



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA3K4O2X085531 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Nov 2008 13:04:24 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA3K4OA9085530; Mon, 3 Nov 2008 13:04:24 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA3K4LsQ085520 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 3 Nov 2008 13:04:23 -0700 (MST) (envelope-from [e-mail])
Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mA3K4Idf027711; Mon, 3 Nov 2008 15:04:18 -0500
Received: from st26.ncsl.nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.13.1/8.13.1) with ESMTP id mA3K47RK029694; Mon, 3 Nov 2008 15:04:08 -0500
Message-ID: <[e-mail]>
Date: Mon, 03 Nov 2008 15:04:02 -0500
From: "David A. Cooper" <[e-mail]>
User-Agent: Thunderbird 2.0.0.17 (X11/20080926)
MIME-Version: 1.0
To: "Kemp, David P." <[e-mail]>
CC: [e-mail]
Subject: Processing rules for non-critical extensions (Re: Rationales for CA clearance constraints)
References: <[e-mail] osoft.com> <p06240500c52b6b1ec3cf@[10.242.22.83]> <[e-mail] osoft.com> <p0624081ac52c289bcda0@[10.20.30.152]> <[e-mail]> <p06240512c52c94298261@[193.0.24.250]> <[e-mail]> <p06240507c52d9fe588ca@[193.0.24.250]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-NIST-MailScanner-Information: 
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Kemp, David P. wrote:
> Dave C,
>
> I start with the assumption that an extension marked critical must be
> processed identically to an extension marked non-critical if it is
> processed at all, and that processing requirements that refer to
> criticality are therefore incorrect.  Name constraints has two such
> statements (here is one) ...
>   
David,

You may choose to start with this assumption, but as I noted in my 
previous email, this is contrary to X.509, which specifically allows 
(requires) clients to ignore some unknown elements in a non-critical 
extension but not in a critical extension:

  If unknown elements appear within the extension, and the extension
  is not marked critical, those unknown elements shall be ignored
  according to the rules of extensibility documented in 12.2.2 in
  ITU-T Rec. X.519 | ISO/IEC 9594-5.

I do not understand your logic below with respect to the nameConstraints 
extension.  You proposed the following text:
  
   A certificate-using system MUST reject the certificate if it
   encounters a critical extension that it cannot process.  If a
   certificate-using system encounters a non-critical extension,
   it MUST either process the extension as if it were marked
   critical or ignore the extension entirely.

As I interpret this, a client that encounters a non-critical 
nameConstraints extension that includes a name form that it cannot 
process MUST ignore the extension entirely since it cannot process the 
extension as if it were marked critical.   Below you seem to be 
proposing, for the nameConstraints extension, that clients should be 
required to process a non-critical nameConstraints extension as if it 
were critical.  This would mean that a client that can process name 
constraints for some name forms would be required to reject a 
certificate if it encountered a non-critical nameConstraints extension 
that included a name form that it could not process even though a client 
that did not recognize the OID for the nameConstraints extension at all 
would be permitted to accept the certificate.  Not only does this seem 
to be contrary to the idea behind allowing an extension to be marked 
non-critical, it directly contradicts X.509.  Unlike RFC 5280, X.509 
specifically allows for the nameConstraints extension to be marked 
non-critical and it includes the following text:

   Conformant implementations are not required to recognize
   all possible name forms. If the extension is flagged critical
   and a certificate-using implementation does not recognize
   a name form used in any base component, the certificate
   shall be handled as if an unrecognized critical extension
   had been encountered. If the extension is flagged
   non-critical and a certificate-using implementation does
   not recognize a name form used in any base component,
   then that subtree may be ignored.

>    If a name constraints extension that is marked as critical
>    imposes constraints on a particular name form, and an instance of
>    that name form appears in the subject field or subjectAltName
>    extension of a subsequent certificate, then the application MUST
>    either process the constraint or reject the certificate.
>
> ... and conforming CAs MUST mark name constraints as critical.  If an
> application finds a non-critical name constraints and a path contains
> SANs using dNSname form and the application cannot process that form,
> then it is better to reject the certificate than to constrain subject DN
> while allowing dNSname to pass unconstrained.  Under what circumstances
> would it ever be a good thing to process some name constraints while
> silently ignoring others?

Under what circumstances would it be a good thing to ignore all name 
constraints simply because some cannot be processed?  Remember that we 
are only considering the case in which the CA has chosen to mark the 
extension non-critical.  The fact that RFC 5280 states that conforming 
CAs must always mark the extension as critical is irrelevant as is any 
discussion of whether it ever makes sense for a CA to mark the extension 
non-critical.  If the CA has chosen to mark the extension non-critical, 
then it is indicating that it does not wish to require clients to reject 
the certificate simply because they that cannot process the extension.  
Thus a client that can process nameConstraints on some name forms but 
that encounters a non-critical nameConstraints extension with a name 
form that it cannot process must do one of the following: (1) reject the 
certificate since it cannot process every element of the extension; (2) 
ignore the extension entirely; or (3) process the extension to the 
degree possible and ignore the presence of the name forms that it cannot 
process.  Option (3) is the one specified by X.509.  Isn't it also the 
option that most closely aligns with the CA's intention in marking the 
extension non-critical?

> To answer your last question below, "no".  But the same behavior
> (processing what it can and ignoring the rest) should be required where
> appropriate (as with AIA and EKU) if the extension is marked critical.
> Name constraints should be fixed so that the appropriate behavior
> (constrain all present subject names or reject) is required even if the
> constraint is non-critical.
>   

Isn't this essentially saying that the profile should override the 
express wishes of the issuing CA since you believe the CA must have been 
mistaken in choosing the mark the extension non-critical?

Dave



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA3FVU7V050614 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Nov 2008 08:31:30 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA3FVUBA050613; Mon, 3 Nov 2008 08:31:30 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pne-smtpout2-sn1.fre.skanova.net (pne-smtpout2-sn1.fre.skanova.net [81.228.11.159]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA3FVJa3050569 for <[e-mail]>; Mon, 3 Nov 2008 08:31:29 -0700 (MST) (envelope-from [e-mail])
Received: from AndersPC (81.232.45.215) by pne-smtpout2-sn1.fre.skanova.net (7.3.129) id 4843FAEB0247BA3E; Mon, 3 Nov 2008 16:31:08 +0100
Message-ID: <C69EBC5AE9A6475EA6DC630A3C0983A1@AndersPC>
From: "Anders Rundgren" <[e-mail]>
To: "Timothy J. Miller" <[e-mail]>
Cc: "Peter Gutmann" <[e-mail]>, <[e-mail]>
References: <[e-mail]> <B9A9F0E608D94D2CA899102A88789787@AndersPC> <[e-mail]> <87FE58DD430A4A48B3B2A522F95DB5AF@AndersPC> <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: Re: Signing and Encrypting with the same key?
Date: Mon, 3 Nov 2008 16:31:14 +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 Windows Mail 6.0.6000.20661
X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16669
Sender: [e-mail]
Precedence: 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 depends on the *other* uses to which that key can be put, doesn't
>it?  If it's only used for bootstrapping, there's no escrow requirement.
>  But if the device API allows it to be accessed for other uses...?

Tim,
I believe we are practically on the same page now :-)

The intention with the described scheme is that the device encryption key (be it specific or 
"universal") should not be exposed in the general pool of keys, but be limited to key-provisioning.

That it might be hard to thwart misuse in some operating systems is true, but for the primary target 
mobile phones, I don't expect any real problems since these systems anyway must support a more 
granular way of identifying software and capabilities, due to the lack of the concept User, Guest or 
Administrator when operating in the consumer space.  In practical terms that means that a software 
that wants to provision keys must be declared with that capability which in turn will require that 
it is signed by an external clearing house (or device vendor) rather than by a developer.

An app that "only" wants to use user-keys, probably will not need external signing, unless it wants 
to use keys in "silent mode", something that the key-provisioning system also can deal with on a 
per-key basis.

Oops, I slided off the core subject a bit, but you get the point; this is a [rather small but 
crucial] piece of a huge and quite interesting puzzle that a large number of people is working with, 
and mostly in a completely unsynchronized way...

Regards
Anders 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA3Eu0H6043889 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Nov 2008 07:56:00 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA3Eu0P3043888; Mon, 3 Nov 2008 07:56:00 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA3EtwGU043879 for <[e-mail]>; Mon, 3 Nov 2008 07:55:58 -0700 (MST) (envelope-from [e-mail])
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id mA3Etvwo015346 for <[e-mail]>; Mon, 3 Nov 2008 09:55:57 -0500
Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id mA3EtvFP015342; Mon, 3 Nov 2008 09:55:57 -0500
Received: from [129.83.200.3] (129.83.200.3) by imchub2.MITRE.ORG (129.83.29.74) with Microsoft SMTP Server (TLS) id 8.1.311.2; Mon, 3 Nov 2008 09:55:57 -0500
Message-ID: <[e-mail]>
Date: Mon, 3 Nov 2008 08:55:54 -0600
From: "Timothy J. Miller" <[e-mail]>
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: Anders Rundgren <[e-mail]>
CC: Peter Gutmann <[e-mail]>, [e-mail]
Subject: Re: Signing and Encrypting with the same key?
References: <[e-mail]> <B9A9F0E608D94D2CA899102A88789787@AndersPC> <[e-mail]> <87FE58DD430A4A48B3B2A522F95DB5AF@AndersPC>
In-Reply-To: <87FE58DD430A4A48B3B2A522F95DB5AF@AndersPC>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050203050809050700000408"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

Anders Rundgren wrote:

> The reason for having key escrow is to recover lost data.

Correct.

> If you feel that key-import (bootstrapping) keys also should be escrowable, I encourage you to 
> interact with these guys:

That depends on the *other* uses to which that key can be put, doesn't 
it?  If it's only used for bootstrapping, there's no escrow requirement. 
  But if the device API allows it to be accessed for other uses...?

-- Tim

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKvjCC
A2cwggJPoAMCAQICAh8FMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEe
MBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3Jh
dGlvbiBQcmltYXJ5IENBLTEwHhcNMDgwODIxMTUzMTI5WhcNMTAwMjEyMTUzMTI5WjBaMRIw
EAYDVQQKEwltaXRyZS5vcmcxDzANBgNVBAsTBnBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3Rt
aWxsZXIxGjAYBgNVBAMTEU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQCTxM+z5fDKvmBInGatv0DkVwuOxd69S2M2jho8QkOltYJK/4JUm9uK0UtQZkyI
bEjmCpmXLw17iMCgA0SjwuUfJxdF8ntTys8keyMjRdlKSwFnkgZl9tL7o060LBtZQYzI5ajr
W9k3N768G/k1bZS5UYiMGHU5+Ygl4IwVhmQv3wIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF
4DAdBgNVHQ4EFgQUSXARqmj5Bl2Lz7RLoUIkuOHl0MkwHwYDVR0jBBgwFoAUh7QPSI1iM0LB
LVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL3d3dy5taXRyZS5vcmcvdGVj
aC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1UdEQQVMBOBEXRtaWxsZXJAbWl0cmUu
b3JnMA0GCSqGSIb3DQEBBQUAA4IBAQAbA1PH/hed/rryO1f0yfTRJnD/vL1rFTduUut/irL7
FSXHGybuPHxydfyGPvJ4qj+T8hs1W0jTa2zQnaPR52tms3hefl76CNVP9vJoVmaM9svFX4DX
6eJh/4SAI81tAuBIK8gxsWd1Va/Bnnh1/wsZLc8w2jkojVqkT2AHPaHS3DBKX7QAWovXVSxY
QlqMIH4zvSNSVfpvpIf0MWJWRBPvgerVSbJsA4dz6ziKvXDWySTV9zwSuNjikNqL//nIKwjb
r3ZOfSUOxSuhW58an2Ha4TdORvG4dGJEsMzxbpTB+wt/s6tK6roONV4uiDtODBNVAG+XGofe
McsS0b7iXdxDMIIDZzCCAk+gAwIBAgICHwUwDQYJKoZIhvcNAQEFBQAwXTESMBAGA1UEChMJ
bWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAlBgNVBAMTHk1J
VFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMTAeFw0wODA4MjExNTMxMjlaFw0xMDAyMTIx
NTMxMjlaMFoxEjAQBgNVBAoTCW1pdHJlLm9yZzEPMA0GA1UECxMGcGVvcGxlMRcwFQYKCZIm
iZPyLGQBARMHdG1pbGxlcjEaMBgGA1UEAxMRTWlsbGVyIFRpbW90aHkgSi4wgZ8wDQYJKoZI
hvcNAQEBBQADgY0AMIGJAoGBAJPEz7Pl8Mq+YEicZq2/QORXC47F3r1LYzaOGjxCQ6W1gkr/
glSb24rRS1BmTIhsSOYKmZcvDXuIwKADRKPC5R8nF0Xye1PKzyR7IyNF2UpLAWeSBmX20vuj
TrQsG1lBjMjlqOtb2Tc3vrwb+TVtlLlRiIwYdTn5iCXgjBWGZC/fAgMBAAGjgbcwgbQwDgYD
VR0PAQH/BAQDAgXgMB0GA1UdDgQWBBRJcBGqaPkGXYvPtEuhQiS44eXQyTAfBgNVHSMEGDAW
gBSHtA9IjWIzQsEtURpIHsKeuwqxrTBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vd3d3Lm1p
dHJlLm9yZy90ZWNoL21paS9wa2kvY2ExX21pdHJlX29yZy5jcmwwHAYDVR0RBBUwE4ERdG1p
bGxlckBtaXRyZS5vcmcwDQYJKoZIhvcNAQEFBQADggEBABsDU8f+F53+uvI7V/TJ9NEmcP+8
vWsVN25S63+KsvsVJccbJu48fHJ1/IY+8niqP5PyGzVbSNNrbNCdo9Hna2azeF5+XvoI1U/2
8mhWZoz2y8VfgNfp4mH/hIAjzW0C4EgryDGxZ3VVr8GeeHX/CxktzzDaOSiNWqRPYAc9odLc
MEpftABai9dVLFhCWowgfjO9I1JV+m+kh/QxYlZEE++B6tVJsmwDh3PrOIq9cNbJJNX3PBK4
2OKQ2ov/+cgrCNuvdk59JQ7FK6FbnxqfYdrhN05G8bh0YkSwzPFulMH7C3+zq0rqug41Xi6I
O04ME1UAb5cah94xyxLRvuJd3EMwggPkMIICzKADAgECAgEFMA0GCSqGSIb3DQEBBQUAMFox
EjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MSQw
IgYDVQQDExtNSVRSRSBDb3Jwb3JhdGlvbiBSb290IENBLTEwHhcNMDYwNjAzMTcxMzIyWhcN
MTIwNjAzMTcxMzIyWjBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmlj
YXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0x
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyPB7Vl0QgqgQt0u8Q2duRs7eZUPn
hlflKPFPMXGG+iqGpImYs6nfbFPsn0q8FqklFsm/UEV2JJQ3c7Srwfrqe9CrCbVFh761OxZI
7fnUWiUasNP2ING19aAfrQ8IoJsAEtGzHeIacS+M5CN4C0yfUC6CpBZTc9ZldjLUatvJr407
K1i+7WnrRsMVKhICfgmiO/XiVR9YeXyzeRqFrLy6YtJCJuJd0QRfwKtKRpek5oU67Izr7ClH
DtPJs7UOTjMYBS2fTzztC+wwOTp6+A3ZbEymuQcAZRwmGkjVBe2R8MiX26R02Iigz+903ZAL
/6bpvx0DnkrlR2UFr1KBGfBqmQIDAQABo4GxMIGuMBIGA1UdEwEB/wQIMAYBAf8CAQIwDgYD
VR0PAQH/BAQDAgGGMB0GA1UdDgQWBBSHtA9IjWIzQsEtURpIHsKeuwqxrTAfBgNVHSMEGDAW
gBTHcFEA2E3+5AHUaJbFPZ+al/50LzBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vd3d3Lm1p
dHJlLm9yZy90ZWNoL21paS9wa2kvcm9vdGNhMV9taXRyZV9vcmcuY3JsMA0GCSqGSIb3DQEB
BQUAA4IBAQBNbm7rrins3SICPbteX9qSN1+RJClqix/pw3IAe7u60LK0V9jVZ9E2a+c0MZiS
ojdcwU5rXxI2OI2wwIf6wVBo76jIOc+IiQRlC+V8YatGmoibqP/8WDPzlud/WQAzkjrU2nuh
8KdyJG+n1kH/6772Lbra2CIk8mu8FypeaB5P2uIJzdE+PGo82ZiyU680ukiJ9yF6UmEXuciB
77tGQBRxMl6ePzIrArQnf48SmBhFD5XYLraueOiG7E+AzD99ig1M6WHcxWXtp3DIrVqE/DZr
146NJaCWqg9NoE14cmpEllnpWLtLnn5UBYJ+QCozmbe1SJXOOynZ0VxMnGdh7NqgMYICqDCC
AqQCAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1
dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTAJ
BgUrDgMCGgUAoIIBmzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0wODExMDMxNDU1NTRaMCMGCSqGSIb3DQEJBDEWBBRbTN9ZSpJ9m4BWDTvlpTs7eVxnZTBS
BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D
AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNV
BAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQD
Ex5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAh8FMHQGCyqGSIb3DQEJEAILMWWg
YzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0
eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTANBgkqhkiG
9w0BAQEFAASBgGZ5U/OUdu2zV314aa5uRMH1xcwNHdjgPqvbyeSxUlxb7mwdDMKsOLnYP1gS
vL7FA2EaQDnUMcY+79OdouVuNtcIo+QGAix5qagze6WBwtXuOQwUfETPPuYivQA/OP+jw89D
UDP383h80fc4QjtLZMXAubTsoHuqSmEmiBd44jdgAAAAAAAA
--------------ms050203050809050700000408--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA3Ehx1Q041834 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Nov 2008 07:43:59 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA3EhxRT041833; Mon, 3 Nov 2008 07:43:59 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pne-smtpout1-sn1.fre.skanova.net (pne-smtpout1-sn1.fre.skanova.net [81.228.11.98]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA3EhmVB041797 for <[e-mail]>; Mon, 3 Nov 2008 07:43:59 -0700 (MST) (envelope-from [e-mail])
Received: from AndersPC (81.232.45.215) by pne-smtpout1-sn1.fre.skanova.net (7.3.129) id 47A979500482A193; Mon, 3 Nov 2008 15:43:41 +0100
Message-ID: <87FE58DD430A4A48B3B2A522F95DB5AF@AndersPC>
From: "Anders Rundgren" <[e-mail]>
To: "Timothy J. Miller" <[e-mail]>
Cc: "Peter Gutmann" <[e-mail]>, <[e-mail]>
References: <[e-mail]> <B9A9F0E608D94D2CA899102A88789787@AndersPC> <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: Re: Signing and Encrypting with the same key?
Date: Mon, 3 Nov 2008 15:43:46 +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 Windows Mail 6.0.6000.20661
X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16669
Sender: [e-mail]
Precedence: 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,
The reason for having key escrow is to recover lost data.

If you feel that key-import (bootstrapping) keys also should be escrowable, I encourage you to 
interact with these guys:
https://www.trustedcomputinggroup.org/specs/TPM
Since they need a whopping 700 pages just for describing the API, they should be able to cope *any* 
requirement.

Another reference is OASIS EKMI:
http://www.oasis-open.org/committees/download.php/28657/SKSML-1.0-Specification-Non-Normative-DRAFT6.pdf
>From what I can deduct they indeed authenticate the requesting client through a signature and then
return the key by wrapping it by the public signature key.

Anders

----- Original Message ----- 
From: "Timothy J. Miller" <[e-mail]>
To: "Anders Rundgren" <[e-mail]>
Cc: "Peter Gutmann" <[e-mail]>; <[e-mail]>
Sent: Monday, November 03, 2008 15:08
Subject: Re: Signing and Encrypting with the same key?


Anders Rundgren wrote:

> There appears to be three possibilities for this position.

> 2. Encryption keys may be backed-up while signature keys may not

This is the NIST rationale, as I've understood it from 800-57's authors.

> Point #2 don't apply to device-keys.

That's an unwarranted assumption.  If the device key is used for
encryption, then there's very likely a compelling enterprise need to
escrow that key.

-- Tim



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA3EWKMw039690 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Nov 2008 07:32:20 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA3EWKP5039689; Mon, 3 Nov 2008 07:32:20 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mA3EW9cI039643 for <[e-mail]>; Mon, 3 Nov 2008 07:32:19 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 29573 invoked from network); 3 Nov 2008 14:32:28 -0000
Received: from [e-mail] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;03 Nov 2008 14:32:28 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 3 Nov 2008 14:32:28 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: Signing and Encrypting with the same key?
Date: Mon, 3 Nov 2008 09:32:07 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Signing and Encrypting with the same key?
Thread-Index: Ack9wAVzuyJMo+PGQB2+3r4sez0iQgAAKMUw
References: <[e-mail]> <B9A9F0E608D94D2CA899102A88789787@AndersPC> <[e-mail]>
From: "Santosh Chokhani" <[e-mail]>
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>

There are several reasons due to which device keys are generally not
escrowed.

They are used in real-time communications which need not be recovered
(unlike e-mail).

The same key is used for both signing and encrypting.

The key may be used in cryptographic protocols that provide perfect
forward secrecy, rendering the escrow of the device key useless.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Timothy J. Miller
Sent: Monday, November 03, 2008 9:08 AM
To: Anders Rundgren
Cc: Peter Gutmann; [e-mail]
Subject: Re: Signing and Encrypting with the same key?

Anders Rundgren wrote:

> There appears to be three possibilities for this position.

> 2. Encryption keys may be backed-up while signature keys may not

This is the NIST rationale, as I've understood it from 800-57's authors.

> Point #2 don't apply to device-keys.

That's an unwarranted assumption.  If the device key is used for=20
encryption, then there's very likely a compelling enterprise need to=20
escrow that key.

-- Tim



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA3E8ipm036076 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Nov 2008 07:08:44 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA3E8iJf036075; Mon, 3 Nov 2008 07:08:44 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA3E8W0G036041 for <[e-mail]>; Mon, 3 Nov 2008 07:08:42 -0700 (MST) (envelope-from [e-mail])
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id mA3E8VdI030830 for <[e-mail]>; Mon, 3 Nov 2008 09:08:31 -0500
Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id mA3E8VCp030826; Mon, 3 Nov 2008 09:08:31 -0500
Received: from [129.83.200.3] (129.83.200.3) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server (TLS) id 8.1.311.2; Mon, 3 Nov 2008 09:08:30 -0500
Message-ID: <[e-mail]>
Date: Mon, 3 Nov 2008 08:08:28 -0600
From: "Timothy J. Miller" <[e-mail]>
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: Anders Rundgren <[e-mail]>
CC: Peter Gutmann <[e-mail]>, [e-mail]
Subject: Re: Signing and Encrypting with the same key?
References: <[e-mail]> <B9A9F0E608D94D2CA899102A88789787@AndersPC>
In-Reply-To: <B9A9F0E608D94D2CA899102A88789787@AndersPC>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000704010900040405060202"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

Anders Rundgren wrote:

> There appears to be three possibilities for this position.

> 2. Encryption keys may be backed-up while signature keys may not

This is the NIST rationale, as I've understood it from 800-57's authors.

> Point #2 don't apply to device-keys.

That's an unwarranted assumption.  If the device key is used for 
encryption, then there's very likely a compelling enterprise need to 
escrow that key.

-- Tim

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKvjCC
A2cwggJPoAMCAQICAh8FMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEe
MBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3Jh
dGlvbiBQcmltYXJ5IENBLTEwHhcNMDgwODIxMTUzMTI5WhcNMTAwMjEyMTUzMTI5WjBaMRIw
EAYDVQQKEwltaXRyZS5vcmcxDzANBgNVBAsTBnBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3Rt
aWxsZXIxGjAYBgNVBAMTEU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQCTxM+z5fDKvmBInGatv0DkVwuOxd69S2M2jho8QkOltYJK/4JUm9uK0UtQZkyI
bEjmCpmXLw17iMCgA0SjwuUfJxdF8ntTys8keyMjRdlKSwFnkgZl9tL7o060LBtZQYzI5ajr
W9k3N768G/k1bZS5UYiMGHU5+Ygl4IwVhmQv3wIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF
4DAdBgNVHQ4EFgQUSXARqmj5Bl2Lz7RLoUIkuOHl0MkwHwYDVR0jBBgwFoAUh7QPSI1iM0LB
LVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL3d3dy5taXRyZS5vcmcvdGVj
aC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1UdEQQVMBOBEXRtaWxsZXJAbWl0cmUu
b3JnMA0GCSqGSIb3DQEBBQUAA4IBAQAbA1PH/hed/rryO1f0yfTRJnD/vL1rFTduUut/irL7
FSXHGybuPHxydfyGPvJ4qj+T8hs1W0jTa2zQnaPR52tms3hefl76CNVP9vJoVmaM9svFX4DX
6eJh/4SAI81tAuBIK8gxsWd1Va/Bnnh1/wsZLc8w2jkojVqkT2AHPaHS3DBKX7QAWovXVSxY
QlqMIH4zvSNSVfpvpIf0MWJWRBPvgerVSbJsA4dz6ziKvXDWySTV9zwSuNjikNqL//nIKwjb
r3ZOfSUOxSuhW58an2Ha4TdORvG4dGJEsMzxbpTB+wt/s6tK6roONV4uiDtODBNVAG+XGofe
McsS0b7iXdxDMIIDZzCCAk+gAwIBAgICHwUwDQYJKoZIhvcNAQEFBQAwXTESMBAGA1UEChMJ
bWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAlBgNVBAMTHk1J
VFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMTAeFw0wODA4MjExNTMxMjlaFw0xMDAyMTIx
NTMxMjlaMFoxEjAQBgNVBAoTCW1pdHJlLm9yZzEPMA0GA1UECxMGcGVvcGxlMRcwFQYKCZIm
iZPyLGQBARMHdG1pbGxlcjEaMBgGA1UEAxMRTWlsbGVyIFRpbW90aHkgSi4wgZ8wDQYJKoZI
hvcNAQEBBQADgY0AMIGJAoGBAJPEz7Pl8Mq+YEicZq2/QORXC47F3r1LYzaOGjxCQ6W1gkr/
glSb24rRS1BmTIhsSOYKmZcvDXuIwKADRKPC5R8nF0Xye1PKzyR7IyNF2UpLAWeSBmX20vuj
TrQsG1lBjMjlqOtb2Tc3vrwb+TVtlLlRiIwYdTn5iCXgjBWGZC/fAgMBAAGjgbcwgbQwDgYD
VR0PAQH/BAQDAgXgMB0GA1UdDgQWBBRJcBGqaPkGXYvPtEuhQiS44eXQyTAfBgNVHSMEGDAW
gBSHtA9IjWIzQsEtURpIHsKeuwqxrTBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vd3d3Lm1p
dHJlLm9yZy90ZWNoL21paS9wa2kvY2ExX21pdHJlX29yZy5jcmwwHAYDVR0RBBUwE4ERdG1p
bGxlckBtaXRyZS5vcmcwDQYJKoZIhvcNAQEFBQADggEBABsDU8f+F53+uvI7V/TJ9NEmcP+8
vWsVN25S63+KsvsVJccbJu48fHJ1/IY+8niqP5PyGzVbSNNrbNCdo9Hna2azeF5+XvoI1U/2
8mhWZoz2y8VfgNfp4mH/hIAjzW0C4EgryDGxZ3VVr8GeeHX/CxktzzDaOSiNWqRPYAc9odLc
MEpftABai9dVLFhCWowgfjO9I1JV+m+kh/QxYlZEE++B6tVJsmwDh3PrOIq9cNbJJNX3PBK4
2OKQ2ov/+cgrCNuvdk59JQ7FK6FbnxqfYdrhN05G8bh0YkSwzPFulMH7C3+zq0rqug41Xi6I
O04ME1UAb5cah94xyxLRvuJd3EMwggPkMIICzKADAgECAgEFMA0GCSqGSIb3DQEBBQUAMFox
EjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MSQw
IgYDVQQDExtNSVRSRSBDb3Jwb3JhdGlvbiBSb290IENBLTEwHhcNMDYwNjAzMTcxMzIyWhcN
MTIwNjAzMTcxMzIyWjBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmlj
YXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0x
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyPB7Vl0QgqgQt0u8Q2duRs7eZUPn
hlflKPFPMXGG+iqGpImYs6nfbFPsn0q8FqklFsm/UEV2JJQ3c7Srwfrqe9CrCbVFh761OxZI
7fnUWiUasNP2ING19aAfrQ8IoJsAEtGzHeIacS+M5CN4C0yfUC6CpBZTc9ZldjLUatvJr407
K1i+7WnrRsMVKhICfgmiO/XiVR9YeXyzeRqFrLy6YtJCJuJd0QRfwKtKRpek5oU67Izr7ClH
DtPJs7UOTjMYBS2fTzztC+wwOTp6+A3ZbEymuQcAZRwmGkjVBe2R8MiX26R02Iigz+903ZAL
/6bpvx0DnkrlR2UFr1KBGfBqmQIDAQABo4GxMIGuMBIGA1UdEwEB/wQIMAYBAf8CAQIwDgYD
VR0PAQH/BAQDAgGGMB0GA1UdDgQWBBSHtA9IjWIzQsEtURpIHsKeuwqxrTAfBgNVHSMEGDAW
gBTHcFEA2E3+5AHUaJbFPZ+al/50LzBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vd3d3Lm1p
dHJlLm9yZy90ZWNoL21paS9wa2kvcm9vdGNhMV9taXRyZV9vcmcuY3JsMA0GCSqGSIb3DQEB
BQUAA4IBAQBNbm7rrins3SICPbteX9qSN1+RJClqix/pw3IAe7u60LK0V9jVZ9E2a+c0MZiS
ojdcwU5rXxI2OI2wwIf6wVBo76jIOc+IiQRlC+V8YatGmoibqP/8WDPzlud/WQAzkjrU2nuh
8KdyJG+n1kH/6772Lbra2CIk8mu8FypeaB5P2uIJzdE+PGo82ZiyU680ukiJ9yF6UmEXuciB
77tGQBRxMl6ePzIrArQnf48SmBhFD5XYLraueOiG7E+AzD99ig1M6WHcxWXtp3DIrVqE/DZr
146NJaCWqg9NoE14cmpEllnpWLtLnn5UBYJ+QCozmbe1SJXOOynZ0VxMnGdh7NqgMYICqDCC
AqQCAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1
dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTAJ
BgUrDgMCGgUAoIIBmzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0wODExMDMxNDA4MjhaMCMGCSqGSIb3DQEJBDEWBBTve4S0zkWjL9IrkHKQR3OkvMfoATBS
BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D
AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNV
BAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQD
Ex5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAh8FMHQGCyqGSIb3DQEJEAILMWWg
YzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0
eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTANBgkqhkiG
9w0BAQEFAASBgHTz+exODNfkRoqDHwXAKBO2p6DI0Oc8JIAJITLMEnf8YgvsQ5K6SgomScIq
M7fTTqz648UkE5Pp8cyu84UTGSnY85jQloE7z1j2bmtyk8OkzA3MT1sS2xhVLiy2wzf3DBD5
3eKHpekplvANO7RdtORsipdJe3r7zvm/Q1vGPPd1AAAAAAAA
--------------ms000704010900040405060202--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA3CV2aA024224 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Nov 2008 05:31:02 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA3CV27N024223; Mon, 3 Nov 2008 05:31:02 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail02.dandomain.dk (mail02.dandomain.dk [194.150.112.202]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA3CUoWs024195 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 3 Nov 2008 05:31:01 -0700 (MST) (envelope-from [e-mail])
Received: from ERA1 ([194.209.131.192]) by mail02.dandomain.dk (DanDomain Mailserver) with ASMTP id JXH55348 for <[e-mail]>; Mon, 03 Nov 2008 13:30:48 +0100
From: "Erik Andersen" <[e-mail]>
To: <[e-mail]>
Subject: RE: Edition 6 of X.500, including X.509
Date: Mon, 3 Nov 2008 13:30:39 +0100
Message-ID: <7D57363B04AC47FDBD9CC45DBD3A5280@ERA1>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6838
Thread-Index: Ack8oNv9adO0cpxyT3iNjQ2xXF6wHABDnPkQ
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
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>

Hi Peter,

Do not confuse versions with editions. You still write X.509v3 when
referring to Version 3 of certs. A new edition may change or a lot of =
things
without touching the structure of a certificate, e.g.; add new =
extensions.

Regards,

Erik Andersen
Andersen's L-Service
Elsevej 48, DK-3500 Vaerloese
Denmark
Mobile: [phone]
email: [e-mail]
www.x500.eu
www.x500standard.com
=20

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] =
On
Behalf Of Peter Gutmann
Sent: 2. november 2008 04:18
To: [e-mail]; [e-mail]
Subject: Re: Edition 6 of X.500, including X.509


"Erik Andersen" <[e-mail]> writes:

>This is just to make you aware that the sixth edition of X.509 is =
competed
>from the editor's hand. X.509 now includes federated PMI and several
>corrections as documented in two corrigenda to the fifth edition.

A slightly off-topic question, but how does one refer to this?  X.509
version=20
6?  X.509v3 revision 6?  X.509v3.6?

Peter.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA38cx8H006512 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Nov 2008 01:39:00 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA38cxrK006511; Mon, 3 Nov 2008 01:38:59 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pne-smtpout1-sn1.fre.skanova.net (pne-smtpout1-sn1.fre.skanova.net [81.228.11.98]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA38cm8l006489 for <[e-mail]>; Mon, 3 Nov 2008 01:38:59 -0700 (MST) (envelope-from [e-mail])
Received: from AndersPC (81.232.45.215) by pne-smtpout1-sn1.fre.skanova.net (7.3.129) id 47A979500480ADDF; Mon, 3 Nov 2008 09:38:43 +0100
Message-ID: <4E7741B1711C4C3D99C24DBDCB1B428A@AndersPC>
From: "Anders Rundgren" <[e-mail]>
To: "Manger, James H" <[e-mail]>, <[e-mail]>
References: <[e-mail]> <B9A9F0E608D94D2CA899102A88789787@AndersPC> <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: Re: Signing and Encrypting with the same key?
Date: Mon, 3 Nov 2008 09:38:51 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Windows Mail 6.0.6000.20661
X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16669
Sender: [e-mail]
Precedence: 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,
Thank you for the MMA references!

Although I'm not an expert in cryptography (which is the reason I asked for assistance from the 
crypto collective), I have based on published reports found that the mentioned algorithm still is 
used by most TLS implementations because the MMA attacks were enabled by somewhat "unsuspicious" 
server code which subsequently has been corrected, right?

In the use-case I have described (which is very different to TLS), there is as I have pointed out, 
no persistent data whatsoever to encrypt or sign, which (in my maybe overly naive world), should 
make a difference.

In addition, the key in question would during its life-time seldom or never exceed a few thousand 
uses because there is a limit to how many web-sites a user finds worth signing up to.  Yes, this 
piece (of junk?) is the first serious stab at retiring passwords as the primary authentication 
mechanism on the web by hosting all your credentials (except for a few specials like PIV)  in an 
NFC/WLAN-connected mobile phone.  I.e. it is a de-facto standard in early preparation, intended to 
be rolled-out in the same way as Microsoft has done with their brilliant Information Card 
initiative.  The scheme is of course fully compliant with Information Cards as well since fighting 
Microsoft is neither fun, nor possible.  That Microsoft is also experimenting with supporting 
virtual credit-cards doesn't make things less interesting.

The reason why I raised this open question is that multiple keys for user-key bootstrapping would 
effectively require standardization of associated certificates as well in order to regardless of 
operation, uniquely identify the crypto device.  Although indeed quite feasible, a multi-key 
approach greatly complicates the scheme and based on hands-on experience with Internet standards 
since 1995, I see that complexity is a major source to failure.  Less actually seems to be more :-)

Anders Rundgren

----- Original Message ----- 
From: "Manger, James H" <[e-mail]>
To: <[e-mail]>
Sent: Monday, November 03, 2008 00:48
Subject: RE: Signing and Encrypting with the same key?


Anders,

Daniel Bleichenbacher's "million message attack" showed how RSA encryption according to PKCS#1 v1.5 
block-type 2 padding could be attacked by sending about a million chosen ciphertexts to a TLS (eg 
HTTPS) server. The result was recovery of one encrypted session key.

A variation on the attack allows a signature to be forged. An attacker chooses the message they want 
signed, sends about a million ciphertexts to a TLS server, and by watching the responses can forge 
the signature.

This attack showed that a weakness in an encryption algorithm can lead to exploits against a 
signature algorithm (that was otherwise "safe") if the same key is used with both.


James Manger

See RFC 3218 "Preventing the Million Message Attack on CMS" -- though it does not discuss the 
signature-forging aspect.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA38FsQM005409 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Nov 2008 01:15:55 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA38FsHV005408; Mon, 3 Nov 2008 01:15:54 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from posta.ica.cz (fw1.ica.cz [195.47.14.200]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA38Ffw5005386 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 3 Nov 2008 01:15:54 -0700 (MST) (envelope-from prvs=01934fb2c3=[e-mail])
Received: from [195.47.8.235] (port=49830 helo=ef) by posta.ica.cz with esmtp (Exim 4.69) (envelope-from <[e-mail]>) id 1Kwub5-0008S4-1k for [e-mail]; Mon, 03 Nov 2008 09:15:39 +0100
From: "Eduard Formanek" <[e-mail]>
To: <[e-mail]>
Subject: serialNumber in Subject
Date: Mon, 3 Nov 2008 09:15:39 +0100
Message-ID: <000c01c93d8c$5b610310$12230930$@cz>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_000D_01C93D94.BD256B10"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ack9jFs2Pb32fwCpS1CcYOHUO+wxHw==
Content-Language: cs
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Toto je zprava s vmce hastmi ve formatu MIME.

------=_NextPart_000_000D_01C93D94.BD256B10
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hello,

 

It is possible to have the multiple appearance of the atribut serialNumber
in issuer/subject names (RFC5280,  Section 4.1.2.4) ?

 

Thank you very much for your answer.

 

Eda

 


------=_NextPart_000_000D_01C93D94.BD256B10
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
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=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.StylE-mailovZprvy17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DCS link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal>Hello,<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>It is possible to have the multiple appearance of =
the atribut
serialNumber in issuer/subject names <span lang=3DEN-US>(RFC5280, =
&nbsp;</span>Section
4.1.2.4<span lang=3DEN-US>)</span><span lang=3DEN-US> =
</span>?<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>Thank you very much for your answer.<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>Eda<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

</div>

 <BR><BR>__________ Informace od ESET NOD32 Antivirus, verze databaze =
3576 (20081102) __________<BR><BR>Tuto zpravu proveril ESET NOD32 =
Antivirus.<BR><BR><A =
HREF=3D"http://www.eset.cz">http://www.eset.cz</A><BR> </body>

</html>

------=_NextPart_000_000D_01C93D94.BD256B10--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA2NmUIU077241 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 2 Nov 2008 16:48:30 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA2NmUNJ077240; Sun, 2 Nov 2008 16:48:30 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mailipao.ntcif.telstra.com.au (mailipao.ntcif.telstra.com.au [202.12.233.27]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA2NmHNN077230 for <[e-mail]>; Sun, 2 Nov 2008 16:48:29 -0700 (MST) (envelope-from [e-mail])
Received: from unknown (HELO mailai.ntcif.telstra.com.au) ([202.12.162.17]) by mailipai.ntcif.telstra.com.au with ESMTP; 03 Nov 2008 10:48:03 +1100
Received: from mail.cdn.telstra.com.au (localhost [127.0.0.1]) by mailai.ntcif.telstra.com.au (Postfix) with ESMTP id 17072FF84 for <[e-mail]>; Mon,  3 Nov 2008 10:48:03 +1100 (EST)
Received: from WSMSG3702.srv.dir.telstra.com (wsmsg3702.srv.dir.telstra.com [172.49.40.170]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id KAA02218 for <[e-mail]>; Mon, 3 Nov 2008 10:48:02 +1100 (EST)
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3702.srv.dir.telstra.com ([172.49.40.170]) with mapi; Mon, 3 Nov 2008 10:48:02 +1100
From: "Manger, James H" <[e-mail]>
To: "[e-mail]" <[e-mail]>
Date: Mon, 3 Nov 2008 10:48:01 +1100
Subject: RE: Signing and Encrypting with the same key?
Thread-Topic: Signing and Encrypting with the same key?
Thread-Index: Ack80T650tiy2gzSQq2cnHlWAuXDywAcB4nQ
Message-ID: <[e-mail]>
References: <[e-mail]> <B9A9F0E608D94D2CA899102A88789787@AndersPC>
In-Reply-To: <B9A9F0E608D94D2CA899102A88789787@AndersPC>
Accept-Language: en-US, en-AU
Content-Language: en-US
acceptlanguage: en-US, en-AU
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
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>

QW5kZXJzLA0KDQpEYW5pZWwgQmxlaWNoZW5iYWNoZXIncyAibWlsbGlvbiBtZXNzYWdlIGF0dGFj
ayIgc2hvd2VkIGhvdyBSU0EgZW5jcnlwdGlvbiBhY2NvcmRpbmcgdG8gUEtDUyMxIHYxLjUgYmxv
Y2stdHlwZSAyIHBhZGRpbmcgY291bGQgYmUgYXR0YWNrZWQgYnkgc2VuZGluZyBhYm91dCBhIG1p
bGxpb24gY2hvc2VuIGNpcGhlcnRleHRzIHRvIGEgVExTIChlZyBIVFRQUykgc2VydmVyLiBUaGUg
cmVzdWx0IHdhcyByZWNvdmVyeSBvZiBvbmUgZW5jcnlwdGVkIHNlc3Npb24ga2V5Lg0KDQpBIHZh
cmlhdGlvbiBvbiB0aGUgYXR0YWNrIGFsbG93cyBhIHNpZ25hdHVyZSB0byBiZSBmb3JnZWQuIEFu
IGF0dGFja2VyIGNob29zZXMgdGhlIG1lc3NhZ2UgdGhleSB3YW50IHNpZ25lZCwgc2VuZHMgYWJv
dXQgYSBtaWxsaW9uIGNpcGhlcnRleHRzIHRvIGEgVExTIHNlcnZlciwgYW5kIGJ5IHdhdGNoaW5n
IHRoZSByZXNwb25zZXMgY2FuIGZvcmdlIHRoZSBzaWduYXR1cmUuDQoNClRoaXMgYXR0YWNrIHNo
b3dlZCB0aGF0IGEgd2Vha25lc3MgaW4gYW4gZW5jcnlwdGlvbiBhbGdvcml0aG0gY2FuIGxlYWQg
dG8gZXhwbG9pdHMgYWdhaW5zdCBhIHNpZ25hdHVyZSBhbGdvcml0aG0gKHRoYXQgd2FzIG90aGVy
d2lzZSAic2FmZSIpIGlmIHRoZSBzYW1lIGtleSBpcyB1c2VkIHdpdGggYm90aC4NCg0KDQpKYW1l
cyBNYW5nZXINCg0KU2VlIFJGQyAzMjE4ICJQcmV2ZW50aW5nIHRoZSBNaWxsaW9uIE1lc3NhZ2Ug
QXR0YWNrIG9uIENNUyIgLS0gdGhvdWdoIGl0IGRvZXMgbm90IGRpc2N1c3MgdGhlIHNpZ25hdHVy
ZS1mb3JnaW5nIGFzcGVjdC4NCg==



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA29B8x7020399 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 2 Nov 2008 02:11:08 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA29B8L3020398; Sun, 2 Nov 2008 02:11:08 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pne-smtpout2-sn1.fre.skanova.net (pne-smtpout2-sn1.fre.skanova.net [81.228.11.159]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA29Avil020375 for <[e-mail]>; Sun, 2 Nov 2008 02:11:07 -0700 (MST) (envelope-from [e-mail])
Received: from AndersPC (81.232.45.215) by pne-smtpout2-sn1.fre.skanova.net (7.3.129) id 4843FAEB0242538A; Sun, 2 Nov 2008 10:10:55 +0100
Message-ID: <B9A9F0E608D94D2CA899102A88789787@AndersPC>
From: "Anders Rundgren" <[e-mail]>
To: "Peter Gutmann" <[e-mail]>, <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: Re: Signing and Encrypting with the same key?
Date: Sun, 2 Nov 2008 10:11:04 +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 Windows Mail 6.0.6000.20661
X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16669
Sender: [e-mail]
Precedence: 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,
If we put implementation errors aside and only look on the mathematical side of things, could you
please comment on the following?

First the use-case:  This discussion is about the possible (mis) use of a single embedded (device)
private key in a cryptographic container along the lines shown in this document:
http://keycenter.webpki.org/javadoc/keystore/phone/keystore/crypto/VirtualSE.html
http://webpki.org/papers/keygen2/keygen-all-protocol-steps.html

Thesis: "You shouldn't use a signing key for encryption" which is (with other wording) stated in
NIST's SP 800-57.

There appears to be three possibilities for this position.
1. Signatures could be forged and/or private keys could be revealed
2. Encryption keys may be backed-up while signature keys may not
3. Encrypted data could be exposed in clear

We can safely drop #1 since there is no way you can prevent somebody from encrypting arbitrary data
with a public signature key.  If there actually is a problem here, we might as well quit using PKI
altogether!

Point #2 don't apply to device-keys.

So the remaining issue must be that encrypted data could be exposed in some way by "correlating"
encrypted data with signed data, right?

Why I am not that worried?  Well,

C1.  Signed and encrypted input data in KeyGen2 is always padded with PKCS 1 which means that the
raw decryption and encryption algorithms never operate on the same data even when the original data
actually is identical (see C2 and C3)

C2.  There is no correlation whatsoever between signed and encrypted input data in KeyGen2

C3.  Signed and encrypted input data in KeyGen2 requires crypto-level entropy making any kind of
correlation infeasible for practical purposes.  In fact, if the entropy is low, the integrity of the
whole scheme is jeopardized irrespective of other issues

P1.  Although a slightly lamer argument, in most (if not all) cases communications would take place
over HTTPS further reducing "leakage" and attack space

P2.  That many existing PKIs rely on universal keys, including VeriSign's e-mail PKI, is maybe not a
strong technical argument, but shows that commercial PKI vendors as well as enterprises are
concerned about the additional "fuzz" multiple keys introduce.

C = Crypto, P = Practice

Comments are welcome!  I don't claim to have all the answers, but quite a few questions...

Regards
Anders R
----- Original Message ----- 
From: "Peter Gutmann" <[e-mail]>
To: <[e-mail]>; <[e-mail]>
Sent: Sunday, November 02, 2008 04:14
Subject: Re: Signing and Encrypting with the same key?



Julien Stern <[e-mail]> writes:

>As far as I remember, there are no known attacks, but there aren't any
>proofs that it does not weaken security (actually, I believe someone
>published a paper with some hints that there may be a theoretical
>weakness, but that was really long time ago, maybe someone else would know).

There are a pile of fault attacks (that's including inadvertent memory
corruption in the category of "attacks", so it's something that can happen
without any overt attack) that will leak the private key on signing but not on
decrypt, so technically there are known attacks that'll exploit the same key
being used for signing and decryption.

Peter.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA23IrPB063713 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 1 Nov 2008 20:18:54 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA23InYY063689; Sat, 1 Nov 2008 20:18:49 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mailhost.auckland.ac.nz (larry.its.auckland.ac.nz [130.216.12.34]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA23IRJr063377 for <[e-mail]>; Sat, 1 Nov 2008 20:18:38 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 98DEC19A02; Sun,  2 Nov 2008 16:18:26 +1300 (NZDT)
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (larry.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1LwMYl5L3+uq; Sun,  2 Nov 2008 16:18:26 +1300 (NZDT)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 7E5F7199FA; Sun,  2 Nov 2008 16:18:26 +1300 (NZDT)
Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 07B4519EC0BA; Sun,  2 Nov 2008 16:18:26 +1300 (NZDT)
Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from <[e-mail]>) id 1KwTTt-0003on-Tl; Sun, 02 Nov 2008 16:18:25 +1300
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Edition 6 of X.500, including X.509
In-Reply-To: <C11EC9C66E7944C6BD6CA88092BC0409@ERA1>
Message-Id: <[e-mail]>
Date: Sun, 02 Nov 2008 16:18:25 +1300
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Erik Andersen" <[e-mail]> writes:

>This is just to make you aware that the sixth edition of X.509 is competed
>from the editor's hand. X.509 now includes federated PMI and several
>corrections as documented in two corrigenda to the fifth edition.

A slightly off-topic question, but how does one refer to this?  X.509 version 
6?  X.509v3 revision 6?  X.509v3.6?

Peter.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA23Eu2Q062774 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 1 Nov 2008 20:14:56 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA23EuHN062773; Sat, 1 Nov 2008 20:14:56 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mailhost.auckland.ac.nz (moe.its.auckland.ac.nz [130.216.12.35]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA23EhE1062734 for <[e-mail]>; Sat, 1 Nov 2008 20:14:55 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 73D5F4813D9; Sun,  2 Nov 2008 16:14:42 +1300 (NZDT)
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (moe.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G+NjgM9xCDjJ; Sun,  2 Nov 2008 16:14:42 +1300 (NZDT)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id BA81E4813BC; Sun,  2 Nov 2008 16:14:41 +1300 (NZDT)
Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id AD17B19EC0BA; Sun,  2 Nov 2008 16:14:40 +1300 (NZDT)
Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from <[e-mail]>) id 1KwTQG-0003Ms-IF; Sun, 02 Nov 2008 16:14:40 +1300
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Signing and Encrypting with the same key?
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
Date: Sun, 02 Nov 2008 16:14:40 +1300
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Julien Stern <[e-mail]> writes:

>As far as I remember, there are no known attacks, but there aren't any 
>proofs that it does not weaken security (actually, I believe someone 
>published a paper with some hints that there may be a theoretical 
>weakness, but that was really long time ago, maybe someone else would know).

There are a pile of fault attacks (that's including inadvertent memory 
corruption in the category of "attacks", so it's something that can happen 
without any overt attack) that will leak the private key on signing but not on 
decrypt, so technically there are known attacks that'll exploit the same key 
being used for signing and decryption.

Peter.