Renew/Rekey/Modification

[Stephen Wilson <[e-mail]>]

Colleagues,

There are a few things about certificate "renewal" and "re-key" that 
have long confounded me.  Things only seem to have got more convoluted 
in RFC 3647 and -- no offence! -- in newer Certificate Policies like the 
US FPKI Policy Authority document.   Can anyone help me understand the 
rationale for the some of the following scenarios?  Thanks in advance!



Re-key is said (in the FPKI CP) to be a good idea because the older a 
key gets, the more susceptible it is to loss and compromise.  Fair 
enough, but why wouldn't that consideration be factored into the chosen 
certificate validity period?


Is there ever a real world scenario when a Subject would of their own 
accord request re-key because they feel the key is getting old?  If so, 
why wouldn't they revoke as well?  The FPKI CA says that after re-key 
"The old certificate may or may not be revoked".  Why would you not 
revoke, given the possibility that the key has got too old?  I don't 
think it would ever be sensible to keep using an old original key and a 
fresh key.  And if I were a Relying Party, I might like to know about 
this possible quality difference, yet there would be nothing in a CRL or 
anywhere else to mark the fact that the Subscriber has re-keyed.


The FPKI CA goes on to say that after re-key "The old certificate ... 
must not be further re-keyed, renewed, or modified".  This seems almost 
oxymoronic.  Consider that I have certificate A and then I re-key A to 
create certificate B.  And then I re-key B to create certificate C.  I 
would say that C is indistinguishable from a re-keyed A since A, B and C 
will only differ by key value.  So how is it meaningful to forbid 
re-keying A more than once? 


Finally, why does RFC 3647 bother to describe "Certificate Modification" 
at all?  The term is inherently confusing since one of the most obvious 
characteristics of a digital certificate is that it cannot be tampered 
with.  I question the need for a special bit of counter intuitive jargon 
(and a whole slab of the RFC) to cover what is really a mundane 
scenario; viz a certificate Subject needs a certificate with different 
details in it.  That is, it's just a new certificate.  Why is it treated 
any differently from an original certificate application?


Cheers,

Stephen Wilson
Lockstep Technologies
www.lockstep.com.au/technologies.



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 n312gIWc029889 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 31 Mar 2009 19:42:18 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n312gIZb029888; Tue, 31 Mar 2009 19:42:18 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp192.iad.emailsrvr.com (smtp192.iad.emailsrvr.com [207.97.245.192]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n312g6m2029876 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 31 Mar 2009 19:42:17 -0700 (MST) (envelope-from [e-mail])
Received: from relay19.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay19.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id EEDB61B400F for <[e-mail]>; Tue, 31 Mar 2009 22:42:00 -0400 (EDT)
Received: by relay19.relay.iad.mlsrvr.com (Authenticated sender: swilson-AT-lockstep.com.au) with ESMTPSA id 684C91B4008 for <[e-mail]>; Tue, 31 Mar 2009 22:42:00 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Wed, 01 Apr 2009 13:41:58 +1100
From: Stephen Wilson <[e-mail]>
Reply-To: [e-mail]
Organization: Lockstep
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: [e-mail]
Subject: Renew/Rekey/Modification
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>

Colleagues,

There are a few things about certificate "renewal" and "re-key" that 
have long confounded me.  Things only seem to have got more convoluted 
in RFC 3647 and -- no offence! -- in newer Certificate Policies like the 
US FPKI Policy Authority document.   Can anyone help me understand the 
rationale for the some of the following scenarios?  Thanks in advance!



Re-key is said (in the FPKI CP) to be a good idea because the older a 
key gets, the more susceptible it is to loss and compromise.  Fair 
enough, but why wouldn't that consideration be factored into the chosen 
certificate validity period?


Is there ever a real world scenario when a Subject would of their own 
accord request re-key because they feel the key is getting old?  If so, 
why wouldn't they revoke as well?  The FPKI CA says that after re-key 
"The old certificate may or may not be revoked".  Why would you not 
revoke, given the possibility that the key has got too old?  I don't 
think it would ever be sensible to keep using an old original key and a 
fresh key.  And if I were a Relying Party, I might like to know about 
this possible quality difference, yet there would be nothing in a CRL or 
anywhere else to mark the fact that the Subscriber has re-keyed.


The FPKI CA goes on to say that after re-key "The old certificate ... 
must not be further re-keyed, renewed, or modified".  This seems almost 
oxymoronic.  Consider that I have certificate A and then I re-key A to 
create certificate B.  And then I re-key B to create certificate C.  I 
would say that C is indistinguishable from a re-keyed A since A, B and C 
will only differ by key value.  So how is it meaningful to forbid 
re-keying A more than once? 


Finally, why does RFC 3647 bother to describe "Certificate Modification" 
at all?  The term is inherently confusing since one of the most obvious 
characteristics of a digital certificate is that it cannot be tampered 
with.  I question the need for a special bit of counter intuitive jargon 
(and a whole slab of the RFC) to cover what is really a mundane 
scenario; viz a certificate Subject needs a certificate with different 
details in it.  That is, it's just a new certificate.  Why is it treated 
any differently from an original certificate application?


Cheers,

Stephen Wilson
Lockstep Technologies
www.lockstep.com.au/technologies.




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 n2VGpcuL091174 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 31 Mar 2009 09:51:38 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2VGpcRL091173; Tue, 31 Mar 2009 09:51:38 -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 n2VGpQIO091155 for <[e-mail]>; Tue, 31 Mar 2009 09:51:37 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 1680 invoked from network); 31 Mar 2009 16:50:24 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 31 Mar 2009 16:50: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: OCSP RFC (RFC 2560) Dependence on SHA-1
Date: Tue, 31 Mar 2009 12:51:25 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: OCSP RFC (RFC 2560) Dependence on SHA-1
Thread-Index: AcmyIGh4vURVLwB0QOmggx7xJi+ihAAAFOIw
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Santosh Chokhani" <[e-mail]>
To: "Massimiliano Pala" <[e-mail]>, "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>

Max,

I do not see where and what extension we need to add for other digest
algorithm.

For key id, we need to enhance or broaden the options.=20

> -----Original Message-----
> From: [e-mail]=20
> [mailto:[e-mail]] On Behalf Of Massimiliano Pala
> Sent: Tuesday, March 31, 2009 1:37 PM
> To: IETF-pkix
> Subject: Re: OCSP RFC (RFC 2560) Dependence on SHA-1
>=20
> Hi all,
>=20
> as I said during last meeting - as the use of SHA-1 does not=20
> have any security implication in the OCSP, another viable way=20
> would be to define an extension where other digest algorithms=20
> can be added to the request/responses.
>=20
> It is a simple addition and does not require any change in=20
> the RFC, it can be done as a separate document for those who=20
> what to use other digest algorithms.
>=20
> After all, isn't this an example of why we allow extensions=20
> to the messages ?
>=20
> Later,
> Max
>=20
>=20
> Santosh Chokhani wrote:
> > Tom,
> >=20
> > Adding a new choice and aligning it with 5280 SKID is fine.
> >=20
> > I would not add anything about matching this field with=20
> anything since=20
> > RFC 2560 does not say anything about it.
> >=20
> > If one were to add something, one should describe how this=20
> field can=20
> > be used to select from multiple Responder certificates.
> >=20
> >> -----Original Message-----
> >> From: Tom Gindin [mailto:[e-mail]]
> >> Sent: Monday, March 30, 2009 7:46 PM
> >> To: Santosh Chokhani
> >> Cc: IETF-pkix
> >> Subject: Re: OCSP RFC (RFC 2560) Dependence on SHA-1
> >>
> >>         Santosh:
> >>
> >>         The RFC 5280 method just describes "two common methods for=20
> >> generating key identifiers from the public key"
> >> and says that other methods are acceptable.  The comment=20
> to KeyHash=20
> >> in RFC 2560 4.2.1 is not as permissive.  Of course, it's the same=20
> >> field as SKID, and I would support either stating "if the=20
> KeyHash is=20
> >> not precisely 20 octets long, it should be matched against the=20
> >> Subject Key Identifier extension of the signing certificate" or=20
> >> adding another choice like byID [3] OCTET STRING --=20
> matches the value=20
> >> of SKID.
> >>
> >>                 Tom Gindin
> >>
> >> P.S. - The above opinions are mine, and not necessarily=20
> those of my=20
> >> employer
> >>
> >>
> >>
> >>
> >> "Santosh Chokhani" <[e-mail]> Sent by:=20
> >> [e-mail]
> >> 03/26/2009 10:39 PM
> >>
> >> To
> >> "IETF-pkix" <[e-mail]>
> >> cc
> >>
> >> Subject
> >> OCSP RFC (RFC 2560) Dependence on SHA-1
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> RFC 2560 dependence on SHA-1 does not appear to be=20
> difficult to deal=20
> >> with.
> >>
> >> Section 4.3 lists SHA-1 as mandatory and RSA as optional.  We can=20
> >> update this to add SHA-2 series as optional.
> >>
> >> The Responder ID has SHA-1 hardwired.  But, that is no=20
> different than=20
> >> key ID extensions in RFC 5280.  Here are some options in order of
> >> preference:
> >>
> >> 1.  Align the language with subject key ID language in RFC 5280.
> >>
> >> 2.  Keep on using SHA-1.  This field is not security=20
> relevant.  RFC=20
> >> 2560 does not even describe how to use this field.  So,=20
> having SHA-1=20
> >> and accidental or intentional collisions will not hurt the=20
> security=20
> >> of the protocol.
> >>
> >> 3.  If you do not believe in KISS principle, you can=20
> define another=20
> >> response type and enhance the key ID ASN.1 syntax so that hash=20
> >> algorithm is identified.
> >>
> >> 4.  Another option is for the Responder to use the same hashing=20
> >> algorithm as the one in the first certID entry.
> >>
> >>
> >> Santosh Chokhani
> >> CygnaCom Solutions
> >>
> >>
> >>
> >>
> >=20
> >=20
>=20
>=20
> --=20
>=20
> Best Regards,
>=20
> 	Massimiliano Pala
>=20
> --o-----------------------------------------------------------
> -------------
> Massimiliano Pala [OpenCA Project Manager] =20
> [e-mail]
>                                                  =20
> [e-mail]
>=20
> Dartmouth Computer Science Dept               Home Phone: +1=20
> [phone]
> PKI/Trust Laboratory                          Work Phone: +1=20
> [phone]
> --o-----------------------------------------------------------
> -------------
>=20
> People who think they know everything are a great annoyance=20
> to those of us who do.
> 							   --=20
> Isaac Asimov
>=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 n2VGWh4W089748 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 31 Mar 2009 09:32:43 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2VGWhVZ089747; Tue, 31 Mar 2009 09:32:43 -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 n2VGWVpX089733 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 31 Mar 2009 09:32:42 -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 n2VGWROa016995 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Tue, 31 Mar 2009 12:32:30 -0400
Message-ID: <[e-mail]>
Date: Tue, 31 Mar 2009 13:37:07 -0400
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: IETF-pkix <[e-mail]>
Subject: Re: OCSP RFC (RFC 2560) Dependence on SHA-1
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090900050008070406030401"
Sender: [e-mail]
Precedence: 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.

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

Hi all,

as I said during last meeting - as the use of SHA-1 does not have
any security implication in the OCSP, another viable way would be
to define an extension where other digest algorithms can be added
to the request/responses.

It is a simple addition and does not require any change in the RFC,
it can be done as a separate document for those who what to use
other digest algorithms.

After all, isn't this an example of why we allow extensions to the
messages ?

Later,
Max


Santosh Chokhani wrote:
> Tom,
> 
> Adding a new choice and aligning it with 5280 SKID is fine.
> 
> I would not add anything about matching this field with anything since
> RFC 2560 does not say anything about it.
> 
> If one were to add something, one should describe how this field can be
> used to select from multiple Responder certificates.
> 
>> -----Original Message-----
>> From: Tom Gindin [mailto:[e-mail]] 
>> Sent: Monday, March 30, 2009 7:46 PM
>> To: Santosh Chokhani
>> Cc: IETF-pkix
>> Subject: Re: OCSP RFC (RFC 2560) Dependence on SHA-1
>>
>>         Santosh:
>>
>>         The RFC 5280 method just describes "two common 
>> methods for generating key identifiers from the public key" 
>> and says that other methods are acceptable.  The comment to 
>> KeyHash in RFC 2560 4.2.1 is not as permissive.  Of course, 
>> it's the same field as SKID, and I would support either 
>> stating "if the KeyHash is not precisely 20 octets long, it 
>> should be matched against the Subject Key Identifier 
>> extension of the signing certificate" or adding another 
>> choice like byID [3] OCTET STRING -- matches the value of SKID.
>>
>>                 Tom Gindin
>>
>> P.S. - The above opinions are mine, and not necessarily those 
>> of my employer
>>
>>
>>
>>
>> "Santosh Chokhani" <[e-mail]> 
>> Sent by: [e-mail]
>> 03/26/2009 10:39 PM
>>
>> To
>> "IETF-pkix" <[e-mail]>
>> cc
>>
>> Subject
>> OCSP RFC (RFC 2560) Dependence on SHA-1
>>
>>
>>
>>
>>
>>
>>
>> RFC 2560 dependence on SHA-1 does not appear to be difficult to deal
>> with.
>>
>> Section 4.3 lists SHA-1 as mandatory and RSA as optional.  We 
>> can update
>> this to add SHA-2 series as optional.
>>
>> The Responder ID has SHA-1 hardwired.  But, that is no different than
>> key ID extensions in RFC 5280.  Here are some options in order of
>> preference:
>>
>> 1.  Align the language with subject key ID language in RFC 5280.
>>
>> 2.  Keep on using SHA-1.  This field is not security 
>> relevant.  RFC 2560
>> does not even describe how to use this field.  So, having SHA-1 and
>> accidental or intentional collisions will not hurt the security of the
>> protocol.
>>
>> 3.  If you do not believe in KISS principle, you can define another
>> response type and enhance the key ID ASN.1 syntax so that 
>> hash algorithm
>> is identified.
>>
>> 4.  Another option is for the Responder to use the same hashing
>> algorithm as the one in the first certID entry.
>>
>>
>> Santosh Chokhani
>> CygnaCom Solutions
>>
>>
>>
>>
> 
> 


-- 

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

--------------ms090900050008070406030401
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
AKCCAdEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwMzMx
MTczNzA3WjAjBgkqhkiG9w0BCQQxFgQUpnJdVbvoGYq4+tbtX36o6WEtEIYwUgYJKoZIhvcN
AQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYF
Kw4DAgcwDQYIKoZIhvcNAwICASgwgYwGCSsGAQQBgjcQBDF/MH0wdzETMBEGCgmSJomT8ixk
ARkWA2VkdTEZMBcGCgmSJomT8ixkARkWCWRhcnRtb3V0aDELMAkGA1UEBhMCVVMxGjAYBgNV
BAoTEURhcnRtb3V0aCBDb2xsZWdlMRwwGgYDVQQDExNEYXJ0bW91dGggQ2VydEF1dGgxAgIa
UzCBjgYLKoZIhvcNAQkQAgsxf6B9MHcxEzARBgoJkiaJk/IsZAEZFgNlZHUxGTAXBgoJkiaJ
k/IsZAEZFglkYXJ0bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91dGggQ29s
bGVnZTEcMBoGA1UEAxMTRGFydG1vdXRoIENlcnRBdXRoMQICGlMwDQYJKoZIhvcNAQEBBQAE
gYCkbYkqTg0h7eJbvKZaPgW9CRMH6rdv9vLo/hXaFg/kruWaYUTnYiUKGTNknvAfnBZewK3Q
mSHorxs1xwtBqspFHYnI0x7QMQ9dAXnzMNAG9+LnTDMCcT8nch7Vv7j+P2KsmGpXVogkqTNj
SWEJHihNnnBORZ3/DGyqRgnpwNjJWQAAAAAAAA==
--------------ms090900050008070406030401--



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 n2VDTFj9076733 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 31 Mar 2009 06:29:16 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2VDTFWP076732; Tue, 31 Mar 2009 06:29:15 -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 n2VDT4S0076720 for <[e-mail]>; Tue, 31 Mar 2009 06:29:14 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 32252 invoked from network); 31 Mar 2009 13:28:01 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 31 Mar 2009 13:28:01 -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: OCSP RFC (RFC 2560) Dependence on SHA-1
Date: Tue, 31 Mar 2009 09:29:02 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: OCSP RFC (RFC 2560) Dependence on SHA-1
Thread-Index: AcmxkcJvbll2uUH9THe1WDhkObGE/wAcpH5A
References: <[e-mail]> <[e-mail]>
From: "Santosh Chokhani" <[e-mail]>
To: "Tom Gindin" <[e-mail]>
Cc: "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>

Tom,

Adding a new choice and aligning it with 5280 SKID is fine.

I would not add anything about matching this field with anything since
RFC 2560 does not say anything about it.

If one were to add something, one should describe how this field can be
used to select from multiple Responder certificates.

> -----Original Message-----
> From: Tom Gindin [mailto:[e-mail]]=20
> Sent: Monday, March 30, 2009 7:46 PM
> To: Santosh Chokhani
> Cc: IETF-pkix
> Subject: Re: OCSP RFC (RFC 2560) Dependence on SHA-1
>=20
>         Santosh:
>=20
>         The RFC 5280 method just describes "two common=20
> methods for generating key identifiers from the public key"=20
> and says that other methods are acceptable.  The comment to=20
> KeyHash in RFC 2560 4.2.1 is not as permissive.  Of course,=20
> it's the same field as SKID, and I would support either=20
> stating "if the KeyHash is not precisely 20 octets long, it=20
> should be matched against the Subject Key Identifier=20
> extension of the signing certificate" or adding another=20
> choice like byID [3] OCTET STRING -- matches the value of SKID.
>=20
>                 Tom Gindin
>=20
> P.S. - The above opinions are mine, and not necessarily those=20
> of my employer
>=20
>=20
>=20
>=20
> "Santosh Chokhani" <[e-mail]>=20
> Sent by: [e-mail]
> 03/26/2009 10:39 PM
>=20
> To
> "IETF-pkix" <[e-mail]>
> cc
>=20
> Subject
> OCSP RFC (RFC 2560) Dependence on SHA-1
>=20
>=20
>=20
>=20
>=20
>=20
>=20
> RFC 2560 dependence on SHA-1 does not appear to be difficult to deal
> with.
>=20
> Section 4.3 lists SHA-1 as mandatory and RSA as optional.  We=20
> can update
> this to add SHA-2 series as optional.
>=20
> The Responder ID has SHA-1 hardwired.  But, that is no different than
> key ID extensions in RFC 5280.  Here are some options in order of
> preference:
>=20
> 1.  Align the language with subject key ID language in RFC 5280.
>=20
> 2.  Keep on using SHA-1.  This field is not security=20
> relevant.  RFC 2560
> does not even describe how to use this field.  So, having SHA-1 and
> accidental or intentional collisions will not hurt the security of the
> protocol.
>=20
> 3.  If you do not believe in KISS principle, you can define another
> response type and enhance the key ID ASN.1 syntax so that=20
> hash algorithm
> is identified.
>=20
> 4.  Another option is for the Responder to use the same hashing
> algorithm as the one in the first certID entry.
>=20
>=20
> Santosh Chokhani
> CygnaCom Solutions
>=20
>=20
>=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 n2UNkuar020210 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Mar 2009 16:46:56 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2UNku2J020209; Mon, 30 Mar 2009 16:46:56 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.141]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2UNkinS020194 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Mon, 30 Mar 2009 16:46:55 -0700 (MST) (envelope-from [e-mail])
Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e1.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id n2UNhhcV014289 for <[e-mail]>; Mon, 30 Mar 2009 19:43:43 -0400
Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n2UNkRPf181714 for <[e-mail]>; Mon, 30 Mar 2009 19:46:27 -0400
Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n2UNkRMn015719 for <[e-mail]>; Mon, 30 Mar 2009 19:46:27 -0400
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.56.228.115]) by d01av03.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n2UNkROi015714; Mon, 30 Mar 2009 19:46:27 -0400
In-Reply-To: <[e-mail]>
To: "Santosh Chokhani" <[e-mail]>
Cc: "IETF-pkix" <[e-mail]>
MIME-Version: 1.0
Subject: Re: OCSP RFC (RFC 2560) Dependence on SHA-1
X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006
From: Tom Gindin <[e-mail]>
Message-ID: <[e-mail]>
Date: Mon, 30 Mar 2009 19:46:25 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 8.0.1 HF8|December 19, 2008) at 03/30/2009 19:46:27, Serialize complete at 03/30/2009 19:46:27
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>

        Santosh:

        The RFC 5280 method just describes "two common methods for 
generating key identifiers from the public key" and says that other 
methods are acceptable.  The comment to KeyHash in RFC 2560 4.2.1 is not 
as permissive.  Of course, it's the same field as SKID, and I would 
support either stating "if the KeyHash is not precisely 20 octets long, it 
should be matched against the Subject Key Identifier extension of the 
signing certificate" or adding another choice like
byID [3] OCTET STRING -- matches the value of SKID.

                Tom Gindin

P.S. - The above opinions are mine, and not necessarily those of my 
employer




"Santosh Chokhani" <[e-mail]> 
Sent by: [e-mail]
03/26/2009 10:39 PM

To
"IETF-pkix" <[e-mail]>
cc

Subject
OCSP RFC (RFC 2560) Dependence on SHA-1







RFC 2560 dependence on SHA-1 does not appear to be difficult to deal
with.

Section 4.3 lists SHA-1 as mandatory and RSA as optional.  We can update
this to add SHA-2 series as optional.

The Responder ID has SHA-1 hardwired.  But, that is no different than
key ID extensions in RFC 5280.  Here are some options in order of
preference:

1.  Align the language with subject key ID language in RFC 5280.

2.  Keep on using SHA-1.  This field is not security relevant.  RFC 2560
does not even describe how to use this field.  So, having SHA-1 and
accidental or intentional collisions will not hurt the security of the
protocol.

3.  If you do not believe in KISS principle, you can define another
response type and enhance the key ID ASN.1 syntax so that hash algorithm
is identified.

4.  Another option is for the Responder to use the same hashing
algorithm as the one in the first certID entry.


Santosh Chokhani
CygnaCom Solutions





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 n2RKmR1q095396 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Mar 2009 13:48:27 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2RKmRmH095395; Fri, 27 Mar 2009 13:48:27 -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 n2RKmQvD095388 for <[e-mail]>; Fri, 27 Mar 2009 13:48:26 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 30) id 423113A6CBC; Fri, 27 Mar 2009 13:47:31 -0700 (PDT)
X-idtracker: yes
To: IETF-Announce <[e-mail]>
From: The IESG <[e-mail]>
Subject: Last Call: draft-ietf-pkix-3281update (An Internet Attribute  Certificate Profile for Authorization) to Proposed Standard 
Reply-to: [e-mail]
CC: <[e-mail]>
Message-Id: <[e-mail]>
Date: Fri, 27 Mar 2009 13:47:31 -0700 (PDT)
Sender: [e-mail]
Precedence: 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:

- 'An Internet Attribute Certificate Profile for Authorization '
   <draft-ietf-pkix-3281update-04.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 2009-04-10. 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-3281update-04.txt


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

The following IPR Declarations may be related to this I-D:





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 n2R2e9Ia026422 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Mar 2009 19:40:09 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2R2e9M8026421; Thu, 26 Mar 2009 19:40:09 -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 n2R2dvTY026404 for <[e-mail]>; Thu, 26 Mar 2009 19:40:08 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 27002 invoked from network); 27 Mar 2009 02:39:02 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 27 Mar 2009 02:39: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: OCSP RFC (RFC 2560) Dependence on SHA-1
Date: Thu, 26 Mar 2009 22:39:56 -0400
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: OCSP RFC (RFC 2560) Dependence on SHA-1
Thread-Index: AcmuhVC3FsiP4JiPR56xXzTb2kNjZg==
From: "Santosh Chokhani" <[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>

RFC 2560 dependence on SHA-1 does not appear to be difficult to deal
with.

Section 4.3 lists SHA-1 as mandatory and RSA as optional.  We can update
this to add SHA-2 series as optional.

The Responder ID has SHA-1 hardwired.  But, that is no different than
key ID extensions in RFC 5280.  Here are some options in order of
preference:

1.  Align the language with subject key ID language in RFC 5280.

2.  Keep on using SHA-1.  This field is not security relevant.  RFC 2560
does not even describe how to use this field.  So, having SHA-1 and
accidental or intentional collisions will not hurt the security of the
protocol.

3.  If you do not believe in KISS principle, you can define another
response type and enhance the key ID ASN.1 syntax so that hash algorithm
is identified.

4.  Another option is for the Responder to use the same hashing
algorithm as the one in the first certID entry.


Santosh Chokhani
CygnaCom Solutions



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 n2R0IP2l018898 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Mar 2009 17:18:25 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2R0IPEl018897; Thu, 26 Mar 2009 17:18:25 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from e9.ny.us.ibm.com (e9.ny.us.ibm.com [32.97.182.139]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2R0IDfk018872 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Thu, 26 Mar 2009 17:18:24 -0700 (MST) (envelope-from [e-mail])
Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e9.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id n2R08t94030415 for <[e-mail]>; Thu, 26 Mar 2009 20:08:55 -0400
Received: from d01av05.pok.ibm.com (d01av05.pok.ibm.com [9.56.224.195]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n2R0ICsX184518 for <[e-mail]>; Thu, 26 Mar 2009 20:18:12 -0400
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 n2R0ICVW007273 for <[e-mail]>; Thu, 26 Mar 2009 20:18:12 -0400
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 n2R0ICgp007266; Thu, 26 Mar 2009 20:18:12 -0400
In-Reply-To: <[e-mail]>
To: Sean Turner <[e-mail]>
Cc: [e-mail], Jan Vilhuber <[e-mail]>
MIME-Version: 1.0
Subject: Re: Nitpicking between CMS and CMC
X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006
From: Tom Gindin <[e-mail]>
Message-ID: <[e-mail]>
Date: Thu, 26 Mar 2009 20:18:11 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 8.0.1 HF8|December 19, 2008) at 03/26/2009 20:18:12, Serialize complete at 03/26/2009 20:18:12
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>

        The definition of "sid" in CMS section 5.3 says, in part "When 
other certificate formats are referenced, the documents that specify the 
certificate format and their use with the CMS must include details on 
matching the key identifier to the appropriate certificate field."  Except 
for the fact that the certification request is not a certificate, this is 
met by CMC.
        A PKCS #10 certification request and a self-signed certificate are 
not that different in semantics or in trustworthiness.  Since a 
self-signed certificate has issuer == subject by definition and signature 
== signatureAlgorithm by RFC 5280 section 4.1.2.3, the only mandatory 
fields in a self-signed certificate whose value couldn't be derived from a 
certification request are serialNumber and validity.  The signature comes 
from the subject in both cases, and is only trusted through out-of-band 
procedures.
        Should the wording in section 5 change from "uniquely identifies 
the certificate containing" to "uniquely identifies the certificate or 
certification request containing"?  If so, another sentence about 
certification requests gets added to 5.3, like "When certification request 
formats are referenced, the documents that specify the request format and 
their use with the CMS must include details on matching the key identifier 
to the appropriate request field."

                Tom Gindin





Sean Turner <[e-mail]> 
Sent by: [e-mail]
03/26/2009 05:57 PM

To
Jan Vilhuber <[e-mail]>
cc
[e-mail]
Subject
Re: Nitpicking between CMS and CMC







I think mandating a self-signed certificates is not the way to go.

spt

Jan Vilhuber wrote:
> I noticed the following discrepancy between CMC and CMS, which could 
> very accurately be described as nitpicking (but them isn't that what 
> standards are about?):
> 
> CMS RFC, section 5. Signed-data Content Type:
> <quote>
> 
>    A recipient independently computes the message digest.  This message
>    digest and the signer's public key are used to verify the signature
>    value.  The signer's public key is referenced either by an issuer
>    distinguished name along with an issuer-specific serial number or by
>    a subject key identifier that uniquely identifies the certificate
>    containing the public key.  The signer's certificate can be included
>    in the SignedData certificates field.
> 
> </quote>
> 
> Specifically: "... or by a subject key identifier that uniquely 
identifies the certificate containing the public key".
> 
> CMC RFC, Section 3.2.  Full PKI Request
> 
> <quote>
> If SignedData is used, the signature can be generated using either the 
> private key material of an embedded signature certification request 
> (i.e., included in the TaggedRequest tcr or crm fields) or a previously 
> certified signature key. If the private key of a signature certification 

> request is used, then:
> 
> a.  The certification request containing the corresponding public key
>        MUST include a Subject Key Identifier extension
> 
>  b.  The subjectKeyIdentifier form of the signerIdentifier in
>        SignerInfo MUST be used.
> 
> c.  The value of the subjectKeyIdentifier form of SignerInfo MUST be
>        the Subject Key Identifier specified in the corresponding
>        certification request.  (The subjectKeyIdentifier form of
>        SignerInfo is used here because no certificates have yet been
>        issued for the signing key.)  If the request key is used for
>        signing, there MUST be only one SignerInfo in the SignedData.
> 
> </quote>
> 
> So CMC allows the SignedData to use the SubjectKeyIdentifier, but 
pointing to the certificate request it is encapsulating. While I don't 
mind this usage, the CMS rfc specifically mentions that the 
SubjectKeyIdentifier "uniquely identifies the certificate containing the 
public key".
> 
> So if we want to be nitpicky about it, then the CMC rfc is asking for 
something which is illegal as per the CMS RFC. This can be cleaned up in 
either place, i.e. either mandating in CMC that a self-signed certificate 
be included when no previous certificate has been issued (thus making it 
conform to CMS), or modify CMS to allow a more liberal application of 
where to find the public key in question.
> 
> Thoughts?
> 
> jan
> 
> 
> 





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 n2QN2lN3012622 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Mar 2009 16:02:47 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2QN2lNg012620; Thu, 26 Mar 2009 16:02:47 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp105.biz.mail.mud.yahoo.com (smtp105.biz.mail.mud.yahoo.com [68.142.200.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n2QN2aDd012573 for <[e-mail]>; Thu, 26 Mar 2009 16:02:46 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 98248 invoked from network); 26 Mar 2009 23:02:36 -0000
Received: from unknown (HELO dhcp-179d.meeting.ietf.org) (turners@130.129.23.157 with plain) by smtp105.biz.mail.mud.yahoo.com with SMTP; 26 Mar 2009 23:02:35 -0000
X-Yahoo-SMTP: qPTWNAeswBAtDTSn9GKlmmL3C90ke7grn_5n9To-
X-YMail-OSG: 6nFrWVAVM1mxkx_S3raAV.fG9_BHPP1TbNICQnM.cKN0WmmatF061cPAAVbkfGdzq7yYQZchgFkdTHzZmGJ__M_hqSCCivWgq_ZW35pAd6AOLje6syMs70crvU6zrb3jbGKiXhefI1IG6PumT5M0VtEroVkhms05G3YcmpQalJYnGEBdxldG2bNHrPNt8xnGfxkP3hWcTyRgxwLWrYetePEQOb4-
X-Yahoo-Newman-Property: ymail-3
Message-ID: <[e-mail]>
Date: Thu, 26 Mar 2009 16:02:34 -0700
From: Sean Turner <[e-mail]>
User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-authorityclearanceconstraints-02.txt
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This version puts the correct OID for clearance (2.5.4.55) in the 
document (Kurt thanks for catching this), updates references/dates, and 
that's it.

spt

[e-mail] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.
> 
> 	Title		: Clearance Attribute and Authority Clearance Constraints 
> Certificate Extension
> 	Author(s)	: S. Chokhani, S. Turner
> 	Filename	: draft-ietf-pkix-authorityclearanceconstraints-02.txt
> 	Pages		: 19
> 	Date		: 2009-3-26
> 	
> 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-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.



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 n2QN2h3Y012593 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Mar 2009 16:02:43 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2QN2hUl012592; Thu, 26 Mar 2009 16:02:43 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2QN2gBi012580 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL); Thu, 26 Mar 2009 16:02:42 -0700 (MST) (envelope-from [e-mail])
X-IronPort-AV: E=Sophos;i="4.38,428,1233532800";  d="scan'208";a="274948011"
Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 26 Mar 2009 23:02:41 +0000
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n2QN2cGS005876; Thu, 26 Mar 2009 16:02:38 -0700
Received: from [10.32.241.22] ([10.32.241.22]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n2QN2b8G017592; Thu, 26 Mar 2009 23:02:38 GMT
Cc: Carl Wallace <[e-mail]>, [e-mail], [e-mail]
Message-Id: <[e-mail]>
From: Jan Vilhuber <[e-mail]>
To: Sean Turner <[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 v930.3)
Subject: Re: Nitpicking between CMS and CMC
Date: Thu, 26 Mar 2009 17:02:36 -0600
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.930.3)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4532; t=1238108558; x=1238972558; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Jan=20Vilhuber=20<[e-mail]> |Subject:=20Re=3A=20Nitpicking=20between=20CMS=20and=20CMC |Sender:=20; bh=uNDYgqacPtAymImotLGgPZD3KExPcr0ZYiVNSxAOXmM=; b=esqYo7CmcCvNJHpPFXzfJ+KOo4vrhN7XtgtOy1pZDLJMzulZTHmM0YhM+1 MOWdhxHyYyTGc0lkCH0jjDtPm908TB9OnBwwnsv81jdBws0hJkA0EbAR023I 8FJY2F0UCNufjm71eucoz/jPO9J8iXWP2JRuSV1Wumxni3lY+TY8E=;
Authentication-Results: sj-dkim-1; header.From=[e-mail]; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Sounds good then.

Thanks!
jan

On Mar 26, 2009, at 4:59 PM, Sean Turner wrote:

> I agree an errata is better/quicker.
>
> spt
>
> Carl Wallace wrote:
>> This can be addressed with an errata report:
>> http://www.rfc-editor.org/errata.php. -----Original Message-----
>> From: Jan Vilhuber [mailto:[e-mail]] Sent: Thursday,  
>> March 26, 2009 3:43 PM
>> To: Carl Wallace
>> Cc: Sean Turner; [e-mail]
>> Subject: Re: Nitpicking between CMS and CMC
>> Hi Carl!
>> Works for me. Is this something that needs fixed in a new CMS   
>> revision? How does this work?
>> jan
>> On Mar 26, 2009, at 4:12 PM, Carl Wallace wrote:
>>> The "uniquely identifies" clause really only applies to the
>>> issDN/serialNum bit.  Moving it gives:
>>>
>>> A recipient independently computes the message digest.  This message
>>> digest and the signer's public key are used to verify the signature
>>> value.  The signer's public key is referenced either by an issuer
>>> distinguished name along with an issuer-specific serial number
>>> that uniquely identifies the certificate containing the public  
>>> key  or by
>>> a subject key identifier.
>>>
>>> -----Original Message-----
>>> From: [e-mail]
>> [mailto:[e-mail]
>>> ]
>>> On Behalf Of Sean Turner
>>> Sent: Thursday, March 26, 2009 2:58 PM
>>> To: Jan Vilhuber
>>> Cc: [e-mail]
>>> Subject: Re: Nitpicking between CMS and CMC
>>>
>>>
>>> I think mandating a self-signed certificates is not the way to go.
>>>
>>> spt
>>>
>>> Jan Vilhuber wrote:
>>>> I noticed the following discrepancy between CMC and CMS, which  
>>>> could
>>>> very accurately be described as nitpicking (but them isn't that  
>>>> what
>>>> standards are about?):
>>>>
>>>> CMS RFC, section 5. Signed-data Content Type:
>>>> <quote>
>>>>
>>>>  A recipient independently computes the message digest.  This
>>> message
>>>>  digest and the signer's public key are used to verify the  
>>>> signature
>>>>  value.  The signer's public key is referenced either by an issuer
>>>>  distinguished name along with an issuer-specific serial number or
>>> by
>>>>  a subject key identifier that uniquely identifies the certificate
>>>>  containing the public key.  The signer's certificate can be
>>> included
>>>>  in the SignedData certificates field.
>>>>
>>>> </quote>
>>>>
>>>> Specifically: "... or by a subject key identifier that uniquely
>>> identifies the certificate containing the public key".
>>>> CMC RFC, Section 3.2.  Full PKI Request
>>>>
>>>> <quote>
>>>> If SignedData is used, the signature can be generated using  
>>>> either  the
>>>> private key material of an embedded signature certification request
>>>> (i.e., included in the TaggedRequest tcr or crm fields) or a
>>> previously
>>>> certified signature key. If the private key of a signature
>>> certification
>>>> request is used, then:
>>>>
>>>> a.  The certification request containing the corresponding public  
>>>> key
>>>>      MUST include a Subject Key Identifier extension
>>>>
>>>> b.  The subjectKeyIdentifier form of the signerIdentifier in
>>>>      SignerInfo MUST be used.
>>>>
>>>> c.  The value of the subjectKeyIdentifier form of SignerInfo MUST  
>>>> be
>>>>      the Subject Key Identifier specified in the corresponding
>>>>      certification request.  (The subjectKeyIdentifier form of
>>>>      SignerInfo is used here because no certificates have yet been
>>>>      issued for the signing key.)  If the request key is used for
>>>>      signing, there MUST be only one SignerInfo in the SignedData.
>>>>
>>>> </quote>
>>>>
>>>> So CMC allows the SignedData to use the SubjectKeyIdentifier, but
>>> pointing to the certificate request it is encapsulating. While I  
>>> don't
>>> mind this usage, the CMS rfc specifically mentions that the
>>> SubjectKeyIdentifier "uniquely identifies the certificate  
>>> containing  the
>>> public key".
>>>> So if we want to be nitpicky about it, then the CMC rfc is asking  
>>>> for
>>> something which is illegal as per the CMS RFC. This can be  
>>> cleaned  up in
>>> either place, i.e. either mandating in CMC that a self-signed
>>> certificate be included when no previous certificate has been issued
>>> (thus making it conform to CMS), or modify CMS to allow a more  
>>> liberal
>>> application of where to find the public key in question.
>>>> Thoughts?
>>>>
>>>> jan
>>>>
>>>>
>>>>



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 n2QMx4Yh012281 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Mar 2009 15:59:04 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2QMx4Oi012279; Thu, 26 Mar 2009 15:59:04 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp108.biz.mail.mud.yahoo.com (smtp108.biz.mail.mud.yahoo.com [68.142.201.177]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n2QMx2Yv012267 for <[e-mail]>; Thu, 26 Mar 2009 15:59:03 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 76534 invoked from network); 26 Mar 2009 22:59:02 -0000
Received: from unknown (HELO dhcp-179d.meeting.ietf.org) (turners@130.129.23.157 with plain) by smtp108.biz.mail.mud.yahoo.com with SMTP; 26 Mar 2009 22:59:02 -0000
X-Yahoo-SMTP: qPTWNAeswBAtDTSn9GKlmmL3C90ke7grn_5n9To-
X-YMail-OSG: Vp9q.yUVM1k0QPm4AfA7pWGPBMuZEFSVIeul7gQxObkCfteoDZbpTtYwnpmYCglFor4DOB1uDmF3zs2byv_mBwgKAWKEfJmQz0dBz_52yqc1D6P7txK558C2okjXbWHuqIB2YnVyP57OpFxhnVsj3Tq6.V9VQNKw98cDkmpxmQgjokrJp5q_CrA752Xk1PJhTXB7UjAIv9dfGI4K3h1Hc0luig--
X-Yahoo-Newman-Property: ymail-3
Message-ID: <[e-mail]>
Date: Thu, 26 Mar 2009 15:59:00 -0700
From: Sean Turner <[e-mail]>
User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302)
MIME-Version: 1.0
To: Carl Wallace <[e-mail]>
CC: Jan Vilhuber <[e-mail]>, [e-mail], [e-mail]
Subject: Re: Nitpicking between CMS and CMC
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>

I agree an errata is better/quicker.

spt

Carl Wallace wrote:
> This can be addressed with an errata report:
> http://www.rfc-editor.org/errata.php. 
> 
> -----Original Message-----
> From: Jan Vilhuber [mailto:[e-mail]] 
> Sent: Thursday, March 26, 2009 3:43 PM
> To: Carl Wallace
> Cc: Sean Turner; [e-mail]
> Subject: Re: Nitpicking between CMS and CMC
> 
> Hi Carl!
> 
> Works for me. Is this something that needs fixed in a new CMS  
> revision? How does this work?
> 
> jan
> 
> On Mar 26, 2009, at 4:12 PM, Carl Wallace wrote:
> 
>> The "uniquely identifies" clause really only applies to the
>> issDN/serialNum bit.  Moving it gives:
>>
>> A recipient independently computes the message digest.  This message
>> digest and the signer's public key are used to verify the signature
>> value.  The signer's public key is referenced either by an issuer
>> distinguished name along with an issuer-specific serial number
>> that uniquely identifies the certificate containing the public key  
>> or by
>> a subject key identifier.
>>
>> -----Original Message-----
>> From: [e-mail]
> [mailto:[e-mail] 
>> ]
>> On Behalf Of Sean Turner
>> Sent: Thursday, March 26, 2009 2:58 PM
>> To: Jan Vilhuber
>> Cc: [e-mail]
>> Subject: Re: Nitpicking between CMS and CMC
>>
>>
>> I think mandating a self-signed certificates is not the way to go.
>>
>> spt
>>
>> Jan Vilhuber wrote:
>>> I noticed the following discrepancy between CMC and CMS, which could
>>> very accurately be described as nitpicking (but them isn't that what
>>> standards are about?):
>>>
>>> CMS RFC, section 5. Signed-data Content Type:
>>> <quote>
>>>
>>>   A recipient independently computes the message digest.  This
>> message
>>>   digest and the signer's public key are used to verify the signature
>>>   value.  The signer's public key is referenced either by an issuer
>>>   distinguished name along with an issuer-specific serial number or
>> by
>>>   a subject key identifier that uniquely identifies the certificate
>>>   containing the public key.  The signer's certificate can be
>> included
>>>   in the SignedData certificates field.
>>>
>>> </quote>
>>>
>>> Specifically: "... or by a subject key identifier that uniquely
>> identifies the certificate containing the public key".
>>> CMC RFC, Section 3.2.  Full PKI Request
>>>
>>> <quote>
>>> If SignedData is used, the signature can be generated using either  
>>> the
>>> private key material of an embedded signature certification request
>>> (i.e., included in the TaggedRequest tcr or crm fields) or a
>> previously
>>> certified signature key. If the private key of a signature
>> certification
>>> request is used, then:
>>>
>>> a.  The certification request containing the corresponding public key
>>>       MUST include a Subject Key Identifier extension
>>>
>>> b.  The subjectKeyIdentifier form of the signerIdentifier in
>>>       SignerInfo MUST be used.
>>>
>>> c.  The value of the subjectKeyIdentifier form of SignerInfo MUST be
>>>       the Subject Key Identifier specified in the corresponding
>>>       certification request.  (The subjectKeyIdentifier form of
>>>       SignerInfo is used here because no certificates have yet been
>>>       issued for the signing key.)  If the request key is used for
>>>       signing, there MUST be only one SignerInfo in the SignedData.
>>>
>>> </quote>
>>>
>>> So CMC allows the SignedData to use the SubjectKeyIdentifier, but
>> pointing to the certificate request it is encapsulating. While I don't
>> mind this usage, the CMS rfc specifically mentions that the
>> SubjectKeyIdentifier "uniquely identifies the certificate containing  
>> the
>> public key".
>>> So if we want to be nitpicky about it, then the CMC rfc is asking for
>> something which is illegal as per the CMS RFC. This can be cleaned  
>> up in
>> either place, i.e. either mandating in CMC that a self-signed
>> certificate be included when no previous certificate has been issued
>> (thus making it conform to CMS), or modify CMS to allow a more liberal
>> application of where to find the public key in question.
>>> Thoughts?
>>>
>>> jan
>>>
>>>
>>>
> 
> 



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 n2QMmFnT011478 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Mar 2009 15:48:15 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2QMmFjS011477; Thu, 26 Mar 2009 15:48:15 -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 n2QMmEUk011471 for <[e-mail]>; Thu, 26 Mar 2009 15:48:14 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 24919 invoked from network); 26 Mar 2009 22:47:19 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 26 Mar 2009 22:47: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: Nitpicking between CMS and CMC
Date: Thu, 26 Mar 2009 18:48:09 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Nitpicking between CMS and CMC
Thread-Index: AcmuZDTgDSVWEVwBRjWdLHdECaP61gAACwTg
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Carl Wallace" <[e-mail]>
To: "Jan Vilhuber" <[e-mail]>
Cc: "Sean Turner" <[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>

This can be addressed with an errata report:
http://www.rfc-editor.org/errata.php.=20

-----Original Message-----
From: Jan Vilhuber [mailto:[e-mail]]=20
Sent: Thursday, March 26, 2009 3:43 PM
To: Carl Wallace
Cc: Sean Turner; [e-mail]
Subject: Re: Nitpicking between CMS and CMC

Hi Carl!

Works for me. Is this something that needs fixed in a new CMS =20
revision? How does this work?

jan

On Mar 26, 2009, at 4:12 PM, Carl Wallace wrote:

> The "uniquely identifies" clause really only applies to the
> issDN/serialNum bit.  Moving it gives:
>
> A recipient independently computes the message digest.  This message
> digest and the signer's public key are used to verify the signature
> value.  The signer's public key is referenced either by an issuer
> distinguished name along with an issuer-specific serial number
> that uniquely identifies the certificate containing the public key =20
> or by
> a subject key identifier.
>
> -----Original Message-----
> From: [e-mail]
[mailto:[e-mail]=20
> ]
> On Behalf Of Sean Turner
> Sent: Thursday, March 26, 2009 2:58 PM
> To: Jan Vilhuber
> Cc: [e-mail]
> Subject: Re: Nitpicking between CMS and CMC
>
>
> I think mandating a self-signed certificates is not the way to go.
>
> spt
>
> Jan Vilhuber wrote:
>> I noticed the following discrepancy between CMC and CMS, which could
>> very accurately be described as nitpicking (but them isn't that what
>> standards are about?):
>>
>> CMS RFC, section 5. Signed-data Content Type:
>> <quote>
>>
>>   A recipient independently computes the message digest.  This
> message
>>   digest and the signer's public key are used to verify the signature
>>   value.  The signer's public key is referenced either by an issuer
>>   distinguished name along with an issuer-specific serial number or
> by
>>   a subject key identifier that uniquely identifies the certificate
>>   containing the public key.  The signer's certificate can be
> included
>>   in the SignedData certificates field.
>>
>> </quote>
>>
>> Specifically: "... or by a subject key identifier that uniquely
> identifies the certificate containing the public key".
>>
>> CMC RFC, Section 3.2.  Full PKI Request
>>
>> <quote>
>> If SignedData is used, the signature can be generated using either =20
>> the
>
>> private key material of an embedded signature certification request
>> (i.e., included in the TaggedRequest tcr or crm fields) or a
> previously
>> certified signature key. If the private key of a signature
> certification
>> request is used, then:
>>
>> a.  The certification request containing the corresponding public key
>>       MUST include a Subject Key Identifier extension
>>
>> b.  The subjectKeyIdentifier form of the signerIdentifier in
>>       SignerInfo MUST be used.
>>
>> c.  The value of the subjectKeyIdentifier form of SignerInfo MUST be
>>       the Subject Key Identifier specified in the corresponding
>>       certification request.  (The subjectKeyIdentifier form of
>>       SignerInfo is used here because no certificates have yet been
>>       issued for the signing key.)  If the request key is used for
>>       signing, there MUST be only one SignerInfo in the SignedData.
>>
>> </quote>
>>
>> So CMC allows the SignedData to use the SubjectKeyIdentifier, but
> pointing to the certificate request it is encapsulating. While I don't
> mind this usage, the CMS rfc specifically mentions that the
> SubjectKeyIdentifier "uniquely identifies the certificate containing =20
> the
> public key".
>>
>> So if we want to be nitpicky about it, then the CMC rfc is asking for
> something which is illegal as per the CMS RFC. This can be cleaned =20
> up in
> either place, i.e. either mandating in CMC that a self-signed
> certificate be included when no previous certificate has been issued
> (thus making it conform to CMS), or modify CMS to allow a more liberal
> application of where to find the public key in question.
>>
>> Thoughts?
>>
>> jan
>>
>>
>>
>



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 n2QMgrVf011150 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Mar 2009 15:42:53 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2QMgrwj011149; Thu, 26 Mar 2009 15:42:53 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2QMgqA0011143 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for <[e-mail]>; Thu, 26 Mar 2009 15:42:53 -0700 (MST) (envelope-from [e-mail])
X-IronPort-AV: E=Sophos;i="4.38,428,1233532800";  d="scan'208";a="162347942"
Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 26 Mar 2009 22:42:52 +0000
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n2QMgqOQ027909; Thu, 26 Mar 2009 15:42:52 -0700
Received: from [10.32.241.22] ([10.32.241.22]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n2QMgpH0024677; Thu, 26 Mar 2009 22:42:52 GMT
Cc: "Sean Turner" <[e-mail]>, <[e-mail]>
Message-Id: <[e-mail]>
From: Jan Vilhuber <[e-mail]>
To: Carl Wallace <[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 v930.3)
Subject: Re: Nitpicking between CMS and CMC
Date: Thu, 26 Mar 2009 16:42:51 -0600
References: <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.930.3)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3813; t=1238107372; x=1238971372; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Jan=20Vilhuber=20<[e-mail]> |Subject:=20Re=3A=20Nitpicking=20between=20CMS=20and=20CMC |Sender:=20; bh=VLMgTeVXSiCcTtgFMCU44s8qw38c3URL90yz4Y1g8Kg=; b=ClSiK8PO7gxe5kEWI5SISaRzqp0tQQa6R6311EPTF7ExFXqw0OCyZZA0ZC NR1iWVKI1ch4WqlFu2zaLAUmUX6MQ1qVvvDz/x20+Yt7L94Hz3w+28D7bFGg mlmRqYJ2HyNlPuSvv9kjMcgo5suX2bO7kGe/RFUo1TpC71tdFz5RQ=;
Authentication-Results: sj-dkim-1; header.From=[e-mail]; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); 
Sender: [e-mail]
Precedence: 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 Carl!

Works for me. Is this something that needs fixed in a new CMS  
revision? How does this work?

jan

On Mar 26, 2009, at 4:12 PM, Carl Wallace wrote:

> The "uniquely identifies" clause really only applies to the
> issDN/serialNum bit.  Moving it gives:
>
> A recipient independently computes the message digest.  This message
> digest and the signer's public key are used to verify the signature
> value.  The signer's public key is referenced either by an issuer
> distinguished name along with an issuer-specific serial number
> that uniquely identifies the certificate containing the public key  
> or by
> a subject key identifier.
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail] 
> ]
> On Behalf Of Sean Turner
> Sent: Thursday, March 26, 2009 2:58 PM
> To: Jan Vilhuber
> Cc: [e-mail]
> Subject: Re: Nitpicking between CMS and CMC
>
>
> I think mandating a self-signed certificates is not the way to go.
>
> spt
>
> Jan Vilhuber wrote:
>> I noticed the following discrepancy between CMC and CMS, which could
>> very accurately be described as nitpicking (but them isn't that what
>> standards are about?):
>>
>> CMS RFC, section 5. Signed-data Content Type:
>> <quote>
>>
>>   A recipient independently computes the message digest.  This
> message
>>   digest and the signer's public key are used to verify the signature
>>   value.  The signer's public key is referenced either by an issuer
>>   distinguished name along with an issuer-specific serial number or
> by
>>   a subject key identifier that uniquely identifies the certificate
>>   containing the public key.  The signer's certificate can be
> included
>>   in the SignedData certificates field.
>>
>> </quote>
>>
>> Specifically: "... or by a subject key identifier that uniquely
> identifies the certificate containing the public key".
>>
>> CMC RFC, Section 3.2.  Full PKI Request
>>
>> <quote>
>> If SignedData is used, the signature can be generated using either  
>> the
>
>> private key material of an embedded signature certification request
>> (i.e., included in the TaggedRequest tcr or crm fields) or a
> previously
>> certified signature key. If the private key of a signature
> certification
>> request is used, then:
>>
>> a.  The certification request containing the corresponding public key
>>       MUST include a Subject Key Identifier extension
>>
>> b.  The subjectKeyIdentifier form of the signerIdentifier in
>>       SignerInfo MUST be used.
>>
>> c.  The value of the subjectKeyIdentifier form of SignerInfo MUST be
>>       the Subject Key Identifier specified in the corresponding
>>       certification request.  (The subjectKeyIdentifier form of
>>       SignerInfo is used here because no certificates have yet been
>>       issued for the signing key.)  If the request key is used for
>>       signing, there MUST be only one SignerInfo in the SignedData.
>>
>> </quote>
>>
>> So CMC allows the SignedData to use the SubjectKeyIdentifier, but
> pointing to the certificate request it is encapsulating. While I don't
> mind this usage, the CMS rfc specifically mentions that the
> SubjectKeyIdentifier "uniquely identifies the certificate containing  
> the
> public key".
>>
>> So if we want to be nitpicky about it, then the CMC rfc is asking for
> something which is illegal as per the CMS RFC. This can be cleaned  
> up in
> either place, i.e. either mandating in CMC that a self-signed
> certificate be included when no previous certificate has been issued
> (thus making it conform to CMS), or modify CMS to allow a more liberal
> application of where to find the public key in question.
>>
>> Thoughts?
>>
>> jan
>>
>>
>>
>



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 n2QMD2jW009634 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Mar 2009 15:13:02 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2QMD23d009633; Thu, 26 Mar 2009 15:13:02 -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 n2QMCpbV009607 for <[e-mail]>; Thu, 26 Mar 2009 15:13:01 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 24481 invoked from network); 26 Mar 2009 22:11:55 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 26 Mar 2009 22:11: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: Nitpicking between CMS and CMC
Date: Thu, 26 Mar 2009 18:12:49 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Nitpicking between CMS and CMC
Thread-Index: AcmuX3KJ68Ca+Pf4T7K+4iAg/JpsBwAAEgFQ
References: <[e-mail]> <[e-mail]>
From: "Carl Wallace" <[e-mail]>
To: "Sean Turner" <[e-mail]>, "Jan Vilhuber" <[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>

The "uniquely identifies" clause really only applies to the
issDN/serialNum bit.  Moving it gives:

A recipient independently computes the message digest.  This message
digest and the signer's public key are used to verify the signature
value.  The signer's public key is referenced either by an issuer
distinguished name along with an issuer-specific serial number=20
that uniquely identifies the certificate containing the public key or by
a subject key identifier. =20

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Sean Turner
Sent: Thursday, March 26, 2009 2:58 PM
To: Jan Vilhuber
Cc: [e-mail]
Subject: Re: Nitpicking between CMS and CMC


I think mandating a self-signed certificates is not the way to go.

spt

Jan Vilhuber wrote:
> I noticed the following discrepancy between CMC and CMS, which could=20
> very accurately be described as nitpicking (but them isn't that what=20
> standards are about?):
>=20
> CMS RFC, section 5. Signed-data Content Type:
> <quote>
>=20
>    A recipient independently computes the message digest.  This
message
>    digest and the signer's public key are used to verify the signature
>    value.  The signer's public key is referenced either by an issuer
>    distinguished name along with an issuer-specific serial number or
by
>    a subject key identifier that uniquely identifies the certificate
>    containing the public key.  The signer's certificate can be
included
>    in the SignedData certificates field.
>=20
> </quote>
>=20
> Specifically: "... or by a subject key identifier that uniquely
identifies the certificate containing the public key".
>=20
> CMC RFC, Section 3.2.  Full PKI Request
>=20
> <quote>
> If SignedData is used, the signature can be generated using either the

> private key material of an embedded signature certification request=20
> (i.e., included in the TaggedRequest tcr or crm fields) or a
previously=20
> certified signature key. If the private key of a signature
certification=20
> request is used, then:
>=20
> a.  The certification request containing the corresponding public key
>        MUST include a Subject Key Identifier extension
>=20
>  b.  The subjectKeyIdentifier form of the signerIdentifier in
>        SignerInfo MUST be used.
>=20
> c.  The value of the subjectKeyIdentifier form of SignerInfo MUST be
>        the Subject Key Identifier specified in the corresponding
>        certification request.  (The subjectKeyIdentifier form of
>        SignerInfo is used here because no certificates have yet been
>        issued for the signing key.)  If the request key is used for
>        signing, there MUST be only one SignerInfo in the SignedData.
>=20
> </quote>
>=20
> So CMC allows the SignedData to use the SubjectKeyIdentifier, but
pointing to the certificate request it is encapsulating. While I don't
mind this usage, the CMS rfc specifically mentions that the
SubjectKeyIdentifier "uniquely identifies the certificate containing the
public key".
>=20
> So if we want to be nitpicky about it, then the CMC rfc is asking for
something which is illegal as per the CMS RFC. This can be cleaned up in
either place, i.e. either mandating in CMC that a self-signed
certificate be included when no previous certificate has been issued
(thus making it conform to CMS), or modify CMS to allow a more liberal
application of where to find the public key in question.
>=20
> Thoughts?
>=20
> jan
>=20
>=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 n2QLvo5B008585 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Mar 2009 14:57:50 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2QLvole008584; Thu, 26 Mar 2009 14:57:50 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp108.biz.mail.mud.yahoo.com (smtp108.biz.mail.mud.yahoo.com [68.142.201.177]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n2QLvdJt008574 for <[e-mail]>; Thu, 26 Mar 2009 14:57:49 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 5263 invoked from network); 26 Mar 2009 21:57:38 -0000
Received: from unknown (HELO dhcp-179d.meeting.ietf.org) (turners@130.129.23.157 with plain) by smtp108.biz.mail.mud.yahoo.com with SMTP; 26 Mar 2009 21:57:38 -0000
X-Yahoo-SMTP: qPTWNAeswBAtDTSn9GKlmmL3C90ke7grn_5n9To-
X-YMail-OSG: 0KIVagsVM1nXMN3iQNF2ujMyeac5s3hOrZGJ9YwHNKkD.jzm7zX1mOobEXN4nKtgmlTH2wrXc7mkTFUO2d28duO1C_it5r68OHJqJQTjdaciQUBTtczWd5zxUuS6m3XGjYr0yll4_Fp.ma0Kf72lS9QAk0bTP1_Mo_HYWkwteK5Gd6eFvURaDOW7MqPB
X-Yahoo-Newman-Property: ymail-3
Message-ID: <[e-mail]>
Date: Thu, 26 Mar 2009 14:57:37 -0700
From: Sean Turner <[e-mail]>
User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302)
MIME-Version: 1.0
To: Jan Vilhuber <[e-mail]>
CC: [e-mail]
Subject: Re: Nitpicking between CMS and CMC
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I think mandating a self-signed certificates is not the way to go.

spt

Jan Vilhuber wrote:
> I noticed the following discrepancy between CMC and CMS, which could 
> very accurately be described as nitpicking (but them isn't that what 
> standards are about?):
> 
> CMS RFC, section 5. Signed-data Content Type:
> <quote>
> 
>    A recipient independently computes the message digest.  This message
>    digest and the signer's public key are used to verify the signature
>    value.  The signer's public key is referenced either by an issuer
>    distinguished name along with an issuer-specific serial number or by
>    a subject key identifier that uniquely identifies the certificate
>    containing the public key.  The signer's certificate can be included
>    in the SignedData certificates field.
> 
> </quote>
> 
> Specifically: "... or by a subject key identifier that uniquely identifies the certificate containing the public key".
> 
> CMC RFC, Section 3.2.  Full PKI Request
> 
> <quote>
> If SignedData is used, the signature can be generated using either the 
> private key material of an embedded signature certification request 
> (i.e., included in the TaggedRequest tcr or crm fields) or a previously 
> certified signature key. If the private key of a signature certification 
> request is used, then:
> 
> a.  The certification request containing the corresponding public key
>        MUST include a Subject Key Identifier extension
> 
>  b.  The subjectKeyIdentifier form of the signerIdentifier in
>        SignerInfo MUST be used.
> 
> c.  The value of the subjectKeyIdentifier form of SignerInfo MUST be
>        the Subject Key Identifier specified in the corresponding
>        certification request.  (The subjectKeyIdentifier form of
>        SignerInfo is used here because no certificates have yet been
>        issued for the signing key.)  If the request key is used for
>        signing, there MUST be only one SignerInfo in the SignedData.
> 
> </quote>
> 
> So CMC allows the SignedData to use the SubjectKeyIdentifier, but pointing to the certificate request it is encapsulating. While I don't mind this usage, the CMS rfc specifically mentions that the SubjectKeyIdentifier "uniquely identifies the certificate containing the public key".
> 
> So if we want to be nitpicky about it, then the CMC rfc is asking for something which is illegal as per the CMS RFC. This can be cleaned up in either place, i.e. either mandating in CMC that a self-signed certificate be included when no previous certificate has been issued (thus making it conform to CMS), or modify CMS to allow a more liberal application of where to find the public key in question.
> 
> Thoughts?
> 
> jan
> 
> 
> 



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 n2QLjv9E007828 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Mar 2009 14:45:57 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2QLjuwF007827; Thu, 26 Mar 2009 14:45:56 -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 n2QLjuZG007821 for <[e-mail]>; Thu, 26 Mar 2009 14:45:56 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id DA8BE28C18D; Thu, 26 Mar 2009 14:45:01 -0700 (PDT)
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-authorityclearanceconstraints-02.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Thu, 26 Mar 2009 14:45:01 -0700 (PDT)
Sender: [e-mail]
Precedence: 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-02.txt
	Pages		: 19
	Date		: 2009-3-26
	
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-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
Content-Type: Message/External-body;
	name="draft-ietf-pkix-authorityclearanceconstraints-02.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 n2QLEoLh006097 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Mar 2009 14:14:50 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2QLEoYe006096; Thu, 26 Mar 2009 14:14:50 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2QLEdd3006056 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for <[e-mail]>; Thu, 26 Mar 2009 14:14:49 -0700 (MST) (envelope-from [e-mail])
X-IronPort-AV: E=Sophos;i="4.38,428,1233532800";  d="scan'208,217";a="162291252"
Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 26 Mar 2009 21:14:39 +0000
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n2QLEdNv018683 for <[e-mail]>; Thu, 26 Mar 2009 14:14:39 -0700
Received: from [10.32.241.22] ([10.32.241.22]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n2QLEc9C021108 for <[e-mail]>; Thu, 26 Mar 2009 21:14:38 GMT
Message-Id: <[e-mail]>
From: Jan Vilhuber <[e-mail]>
To: [e-mail]
Content-Type: multipart/alternative; boundary=Apple-Mail-28--50643191
Mime-Version: 1.0 (Apple Message framework v930.3)
Subject: Nitpicking between CMS and CMC
Date: Thu, 26 Mar 2009 15:14:38 -0600
X-Mailer: Apple Mail (2.930.3)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8493; t=1238102079; x=1238966079; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Jan=20Vilhuber=20<[e-mail]> |Subject:=20Nitpicking=20between=20CMS=20and=20CMC |Sender:=20; bh=2seJ7KbfX2pvRXi2ic1DbjSNMVcL+NXGA91pUjmj+yw=; b=NKHN2fkppfVmuFB+9fd53eCZ1XJa7kv28DnQNzYvbisbzxbnmLjQwo8Ywd J5SS0G6mkSnT+5+s89WYw7aJzRIrSmOxJ8h7eeZFuFBQeFsN0JSeNOgimhiU AuPdxKZUMj;
Authentication-Results: sj-dkim-3; header.From=[e-mail]; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); 
Sender: [e-mail]
Precedence: 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-28--50643191
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: 7bit

I noticed the following discrepancy between CMC and CMS, which could  
very accurately be described as nitpicking (but them isn't that what  
standards are about?):

CMS RFC, section 5. Signed-data Content Type:
<quote>
A recipient independently computes the message digest. This message  
digest and the signer's public key are used to verify the signature  
value. The signer's public key is referenced either by an issuer  
distinguished name along with an issuer-specific serial number or by a  
subject key identifier that uniquely identifies the certificate  
containing the public key. The signer's certificate can be included in  
the SignedData certificates field.
</quote>
Specifically: "... or by a subject key identifier that uniquely  
identifies the certificate containing the public key".
CMC RFC, Section 3.2. Full PKI Request
<quote>
If SignedData is used, the signature can be generated using either the  
private key material of an embedded signature certification request  
(i.e., included in the TaggedRequest tcr or crm fields) or a  
previously certified signature key. If the private key of a signature  
certification request is used, then:
a. The certification request containing the corresponding public key  
MUST include a Subject Key Identifier extension
  b. The subjectKeyIdentifier form of the signerIdentifier in  
SignerInfo MUST be used.
c. The value of the subjectKeyIdentifier form of SignerInfo MUST be  
the Subject Key Identifier specified in the corresponding  
certification request. (The subjectKeyIdentifier form of SignerInfo is  
used here because no certificates have yet been issued for the signing  
key.) If the request key is used for signing, there MUST be only one  
SignerInfo in the SignedData.
</quote>
So CMC allows the SignedData to use the SubjectKeyIdentifier, but  
pointing to the certificate request it is encapsulating. While I don't  
mind this usage, the CMS rfc specifically mentions that the  
SubjectKeyIdentifier "uniquely identifies the certificate containing  
the public key".
So if we want to be nitpicky about it, then the CMC rfc is asking for  
something which is illegal as per the CMS RFC. This can be cleaned up  
in either place, i.e. either mandating in CMC that a self-signed  
certificate be included when no previous certificate has been issued  
(thus making it conform to CMS), or modify CMS to allow a more liberal  
application of where to find the public key in question.
Thoughts?
jan



--Apple-Mail-28--50643191
Content-Type: text/html;
	charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

<html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; ">I noticed the following =
discrepancy between CMC and CMS, which could very accurately be =
described as nitpicking (but them isn't that what standards are =
about?):<div><br></div><div>CMS RFC, section&nbsp;5.  Signed-data =
Content Type:</div><div>&lt;quote><br></div><div><pre><font =
class=3D"Apple-style-span" size=3D"4" face=3D"Helvetica"><span =
class=3D"Apple-style-span" style=3D"font-size: 16px; white-space: =
normal;">   A recipient independently computes the message digest.  This =
message
   digest and the signer's public key are used to verify the signature
   value.  The signer's public key is referenced either by an issuer
   distinguished name along with an issuer-specific serial number or by
   a subject key identifier that uniquely identifies the certificate
   containing the public key.  The signer's certificate can be included
   in the SignedData certificates field.
</span></font><font class=3D"Apple-style-span" size=3D"4" =
face=3D"Helvetica"><span class=3D"Apple-style-span" style=3D"font-size: =
16px; white-space: normal;">
</span></font></pre><pre><font class=3D"Apple-style-span" size=3D"4" =
face=3D"Helvetica"><span class=3D"Apple-style-span" style=3D"font-size: =
16px; white-space: normal;">&lt;/quote></span></font></pre><pre><font =
class=3D"Apple-style-span" size=3D"4" face=3D"Helvetica"><span =
class=3D"Apple-style-span" style=3D"font-size: 16px; white-space: =
normal;"><pre><span class=3D"Apple-style-span" style=3D"font-family: =
Helvetica; white-space: normal; ">Specifically: "...&nbsp;or by a =
subject key identifier that uniquely identifies the certificate =
containing the public key".</span></pre></span></font></pre><pre><span =
class=3D"Apple-style-span" style=3D"font-size: 16px; white-space: =
normal; font-family: Helvetica; ">CMC RFC, Section&nbsp;3.2.  Full PKI =
Request</span></pre><pre><font class=3D"Apple-style-span" =
face=3D"Helvetica" size=3D"4"><span class=3D"Apple-style-span" =
style=3D"font-size: 16px; white-space: =
normal;"><div>&lt;quote></div><div>If SignedData is used, the signature =
can be generated using either
   the private key material of an embedded signature certification
   request (i.e., included in the TaggedRequest tcr or crm fields) or a
   previously certified signature key.  If the private key of a
   signature certification request is used, then:</div><pre><font =
class=3D"Apple-style-span" face=3D"Helvetica"><span =
class=3D"Apple-style-span" style=3D"white-space: normal;">a.  The =
certification request containing the corresponding public key
       MUST include a Subject Key Identifier =
extension</span></font></pre><pre><font class=3D"Apple-style-span" =
face=3D"Helvetica"><span class=3D"Apple-style-span" style=3D"white-space: =
normal;">&nbsp;b.  The subjectKeyIdentifier form of the signerIdentifier =
in
       SignerInfo MUST be used.</span></font></pre><pre><font =
class=3D"Apple-style-span" face=3D"Helvetica"><span =
class=3D"Apple-style-span" style=3D"white-space: normal;">c.  The value =
of the subjectKeyIdentifier form of SignerInfo MUST be
       the Subject Key Identifier specified in the corresponding
       certification request.  (The subjectKeyIdentifier form of
       SignerInfo is used here because no certificates have yet been
       issued for the signing key.)  If the request key is used for
       signing, there MUST be only one SignerInfo in the SignedData.
</span></font><font class=3D"Apple-style-span" face=3D"Helvetica"><span =
class=3D"Apple-style-span" style=3D"white-space: normal;">
</span></font></pre><pre><font class=3D"Apple-style-span" =
face=3D"Helvetica"><span class=3D"Apple-style-span" style=3D"white-space: =
normal;"><pre><font class=3D"Apple-style-span" face=3D"Helvetica"><span =
class=3D"Apple-style-span" style=3D"white-space: =
normal;">&lt;/quote></span></font></pre><pre><font =
class=3D"Apple-style-span" face=3D"Helvetica"><span =
class=3D"Apple-style-span" style=3D"white-space: normal;">So CMC allows =
the SignedData to use the SubjectKeyIdentifier, but pointing to the =
certificate request it is encapsulating. While I don't mind this usage, =
the CMS rfc specifically mentions that the SubjectKeyIdentifier =
"uniquely identifies the certificate containing the public =
key".</span></font></pre><pre><font class=3D"Apple-style-span" =
face=3D"Helvetica"><span class=3D"Apple-style-span" style=3D"white-space: =
normal;">So if we want to be nitpicky about it, then the CMC rfc is =
asking for something which is illegal as per the CMS RFC. This can be =
cleaned up in either place, i.e. either mandating in CMC that a =
self-signed certificate be included when no previous certificate has =
been issued (thus making it conform to CMS), or modify CMS to allow a =
more liberal application of where to find the public key in =
question.</span></font></pre><pre><font class=3D"Apple-style-span" =
face=3D"Helvetica"><span class=3D"Apple-style-span" style=3D"white-space: =
normal;">Thoughts?</span></font></pre><pre><font =
class=3D"Apple-style-span" face=3D"Helvetica"><span =
class=3D"Apple-style-span" style=3D"white-space: =
normal;">jan</span></font></pre><pre><font class=3D"Apple-style-span" =
face=3D"Helvetica"><span class=3D"Apple-style-span" style=3D"white-space: =
normal;"><br></span></font></pre></span></font></pre><pre><font =
class=3D"Apple-style-span" face=3D"Helvetica"><span =
class=3D"Apple-style-span" style=3D"white-space: =
normal;"><br></span></font></pre></span></font></pre></div></body></html>=

--Apple-Mail-28--50643191--



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 n2Q5b7N1043365 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Mar 2009 22: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 n2Q5b7vV043364; Wed, 25 Mar 2009 22: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 smtp103.biz.mail.mud.yahoo.com (smtp103.biz.mail.mud.yahoo.com [68.142.200.238]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n2Q5auBh043348 for <[e-mail]>; Wed, 25 Mar 2009 22:37:06 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 44554 invoked from network); 26 Mar 2009 05:36:55 -0000
Received: from unknown (HELO sean-turners-macbook.local) (turners@66.114.246.35 with plain) by smtp103.biz.mail.mud.yahoo.com with SMTP; 26 Mar 2009 05:36:55 -0000
X-Yahoo-SMTP: qPTWNAeswBAtDTSn9GKlmmL3C90ke7grn_5n9To-
X-YMail-OSG: 5djsFmgVM1lNVk9UO5JmX1BM.ERDuaFunoxxsDYw2V4BoYKMRGHX_KKAt4DQwnBsbGO0VSD7noqCpGyZJX4g.edKyxTiv.Yy.GjJhLJeFS1k59l6RXuX4hnriAXRf6NwTLafvkld9.1Zph3FS8IWXg1WdMyLI0lOcNwq7h5F1Rp8VSV8YEQazJ9VznfZ0Wia_dPpw4AEsBGScDf2Bp_uyK93ANmim_6ecF0-
X-Yahoo-Newman-Property: ymail-3
Message-ID: <[e-mail]>
Date: Wed, 25 Mar 2009 22:36:43 -0700
From: Sean Turner <[e-mail]>
User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302)
MIME-Version: 1.0
To: Massimiliano Pala <[e-mail]>
CC: Stefan Santesson <[e-mail]>, Paul Hoffman <[e-mail]>, pkix <[e-mail]>
Subject: Re: PRQP - Split document in two ?
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

+1

Stefan Santesson wrote:
> I tend to agree with Paul. Unless there is a compelling reason to split the
> document, then having one is better.
> 
> /Stefan
> 
> On 3/25/09 5:06 PM, "Massimiliano Pala" <[e-mail]>
> wrote:
> 
>> Thanks Paul, that's a good point... :D
>>
>> If nobody says anything in favor of the opposite solution.. we'll go with
>> one document only (I do agree that from an implementer's point of view it
>> might be confusing having multiple docs...).
>>
>> Later,
>> Max
>>
>> Paul Hoffman wrote:
>> [...]
>>> Please don't. It just causes implementers to look for two RFCs. It is not a
>>> big deal to
>>> update part of an RFC.
> 
> 
> 



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 n2Q2IvTe035392 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Mar 2009 19: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 n2Q2IvdW035390; Wed, 25 Mar 2009 19: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 s87.loopia.se (s87.loopia.se [194.9.95.112]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2Q2IhTn035370 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 25 Mar 2009 19:18:55 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 96575 invoked from network); 26 Mar 2009 02:18:52 -0000
Received: from s34.loopia.se (HELO s19.loopia.se) ([194.9.94.70]) (envelope-sender <[e-mail]>) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for <[e-mail]>; 26 Mar 2009 02:18:52 -0000
Received: (qmail 47126 invoked from network); 26 Mar 2009 02:18:41 -0000
Received: from dhcp-16a2.meeting.ietf.org (HELO [130.129.22.162]) ([e-mail]@[130.129.22.162]) (envelope-sender <[e-mail]>) by s19.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <[e-mail]>; 26 Mar 2009 02:18:41 -0000
User-Agent: Microsoft-Entourage/12.15.0.081119
Date: Wed, 25 Mar 2009 19:18:31 -0700
Subject: Re: PRQP - Split document in two ?
From: Stefan Santesson <[e-mail]>
To: Massimiliano Pala <[e-mail]>, Paul Hoffman <[e-mail]>, pkix <[e-mail]>
Message-ID: <[e-mail]>
Thread-Topic: PRQP - Split document in two ?
Thread-Index: AcmtuSgYtbrlq5+dS0qxTxj5zMSG+g==
In-Reply-To: <[e-mail]>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I tend to agree with Paul. Unless there is a compelling reason to split the
document, then having one is better.

/Stefan

On 3/25/09 5:06 PM, "Massimiliano Pala" <[e-mail]>
wrote:

> Thanks Paul, that's a good point... :D
> 
> If nobody says anything in favor of the opposite solution.. we'll go with
> one document only (I do agree that from an implementer's point of view it
> might be confusing having multiple docs...).
> 
> Later,
> Max
> 
> Paul Hoffman wrote:
> [...]
>> Please don't. It just causes implementers to look for two RFCs. It is not a
>> big deal to
>> update part of an RFC.




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 n2Q029bs027126 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Mar 2009 17: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 n2Q029dl027125; Wed, 25 Mar 2009 17: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 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 n2Q01vUH027103 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 25 Mar 2009 17:02:08 -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 n2Q01srK005386 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 25 Mar 2009 20:01:56 -0400
Message-ID: <[e-mail]>
Date: Wed, 25 Mar 2009 17:06:38 -0700
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: Paul Hoffman <[e-mail]>, pkix <[e-mail]>
Subject: Re: PRQP - Split document in two ?
References: <[e-mail]> <p06240838c5f06b510483@[130.129.17.206]>
In-Reply-To: <p06240838c5f06b510483@[130.129.17.206]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020408080305020702030805"
Sender: [e-mail]
Precedence: 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.

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

Thanks Paul, that's a good point... :D

If nobody says anything in favor of the opposite solution.. we'll go with
one document only (I do agree that from an implementer's point of view it
might be confusing having multiple docs...).

Later,
Max

Paul Hoffman wrote:
[...]
> Please don't. It just causes implementers to look for two RFCs. It is not a big deal to
> update part of an RFC.

-- 

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

--------------ms020408080305020702030805
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
AKCCAdEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwMzI2
MDAwNjM4WjAjBgkqhkiG9w0BCQQxFgQU41KzyZGCKWRJX2cVlthAx4r0xVYwUgYJKoZIhvcN
AQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYF
Kw4DAgcwDQYIKoZIhvcNAwICASgwgYwGCSsGAQQBgjcQBDF/MH0wdzETMBEGCgmSJomT8ixk
ARkWA2VkdTEZMBcGCgmSJomT8ixkARkWCWRhcnRtb3V0aDELMAkGA1UEBhMCVVMxGjAYBgNV
BAoTEURhcnRtb3V0aCBDb2xsZWdlMRwwGgYDVQQDExNEYXJ0bW91dGggQ2VydEF1dGgxAgIa
UzCBjgYLKoZIhvcNAQkQAgsxf6B9MHcxEzARBgoJkiaJk/IsZAEZFgNlZHUxGTAXBgoJkiaJ
k/IsZAEZFglkYXJ0bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91dGggQ29s
bGVnZTEcMBoGA1UEAxMTRGFydG1vdXRoIENlcnRBdXRoMQICGlMwDQYJKoZIhvcNAQEBBQAE
gYCUi+Rc0KhU84QSwCaJD0Et93bExdYh0wN06jfbMFYufWiBXpIpy3OYEVUMG6LTlWLalmC1
aLWKPehmyRSz0x1q8tIQClwf0H6Qf1oMtLB+2QLgeJRb/x/RD0NTMvSSzHYPdAg2J6Ureey4
9Z1RZqWYvpv5Vk+ftAdnl8AYAwd2wgAAAAAAAA==
--------------ms020408080305020702030805--



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 n2PNFirA025037 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Mar 2009 16:15:44 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2PNFim6025036; Wed, 25 Mar 2009 16:15:44 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from [130.129.17.206] (dhcp-11ce.meeting.ietf.org [130.129.17.206]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2PNFcF1025030 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Mar 2009 16:15:39 -0700 (MST) (envelope-from [e-mail])
Mime-Version: 1.0
Message-Id: <p06240838c5f06b510483@[130.129.17.206]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Wed, 25 Mar 2009 16:15:37 -0700
To: Massimiliano Pala <[e-mail]>, pkix <[e-mail]>
From: Paul Hoffman <[e-mail]>
Subject: Re: PRQP - Split document in two ?
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 11:37 AM -0700 3/25/09, Massimiliano Pala wrote:
>Hi all,
>
>thinking about the document I think that there might be good reasons to
>split the document in two. In particular it would be worth considering
>splitting the document in:
>- Specification of the Protocol
>- List of service/repositories OIDs and their description
>In this way the two different part of the document can be updated independently.
>More specifically, I see the list of OIDs to be more subject to changes than
>the PRQP core itself.
>
>What does the WG and the WG Chairs think about it ? Worth exploring or it is
>better to go with what we have now and proceed as decided in the meeting ?

Please don't. It just causes implementers to look for two RFCs. It is not a big deal to update part of an RFC.

--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 n2PIWdDe007375 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Mar 2009 11:32:39 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2PIWdDE007374; Wed, 25 Mar 2009 11:32:39 -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 n2PIWQ7n007336 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 25 Mar 2009 11:32:38 -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 n2PIWIEn001055 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Wed, 25 Mar 2009 14:32:23 -0400
Message-ID: <[e-mail]>
Date: Wed, 25 Mar 2009 11:37:03 -0700
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: PRQP - Split document in two ?
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070103090808090100030905"
Sender: [e-mail]
Precedence: 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.

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

Hi all,

thinking about the document I think that there might be good reasons to
split the document in two. In particular it would be worth considering
splitting the document in:
- Specification of the Protocol
- List of service/repositories OIDs and their description
In this way the two different part of the document can be updated independently.
More specifically, I see the list of OIDs to be more subject to changes than
the PRQP core itself.

What does the WG and the WG Chairs think about it ? Worth exploring or it is
better to go with what we have now and proceed as decided in the meeting ?

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

--------------ms070103090808090100030905
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
AKCCAdEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwMzI1
MTgzNzAzWjAjBgkqhkiG9w0BCQQxFgQU1ApJtPyBcFXmFvfy0sMdPnIupV4wUgYJKoZIhvcN
AQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYF
Kw4DAgcwDQYIKoZIhvcNAwICASgwgYwGCSsGAQQBgjcQBDF/MH0wdzETMBEGCgmSJomT8ixk
ARkWA2VkdTEZMBcGCgmSJomT8ixkARkWCWRhcnRtb3V0aDELMAkGA1UEBhMCVVMxGjAYBgNV
BAoTEURhcnRtb3V0aCBDb2xsZWdlMRwwGgYDVQQDExNEYXJ0bW91dGggQ2VydEF1dGgxAgIa
UzCBjgYLKoZIhvcNAQkQAgsxf6B9MHcxEzARBgoJkiaJk/IsZAEZFgNlZHUxGTAXBgoJkiaJ
k/IsZAEZFglkYXJ0bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91dGggQ29s
bGVnZTEcMBoGA1UEAxMTRGFydG1vdXRoIENlcnRBdXRoMQICGlMwDQYJKoZIhvcNAQEBBQAE
gYBfrK8sBfEoL1y2NhoiiIlyIZZuFPsYHSFfjZfkrLztaRDLyDxYioJiuPpN2c+Mo0f1FmhR
U2e+1ZdDgG7yjLUrhkr4TEwsVHry+7bZGpdAsIADOAsZXnhRRgfPVwUvcwy28YjBQGWNdbNG
UVzoyAzY8JyqWKet/jcRXrawMCMsKQAAAAAAAA==
--------------ms070103090808090100030905--



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 n2OGbnna020904 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Mar 2009 09:37:49 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2OGbnes020903; Tue, 24 Mar 2009 09:37:49 -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 (rimp1.nist.gov [129.6.16.226]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2OGbbJH020877 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 24 Mar 2009 09:37:48 -0700 (MST) (envelope-from [e-mail])
Received: from postmark.nist.gov (emailha2.nist.gov [129.6.16.198]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id n2OGbV4b032112; Tue, 24 Mar 2009 12:37:31 -0400
Received: from dhcp-10ac.meeting.ietf.org (h222149.nist.gov [129.6.222.149]) by postmark.nist.gov (8.13.1/8.13.1) with ESMTP id n2OGbH9w018131; Tue, 24 Mar 2009 12:37:20 -0400
Message-ID: <[e-mail]>
Date: Tue, 24 Mar 2009 09:37:17 -0700
From: "David A. Cooper" <[e-mail]>
User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209)
MIME-Version: 1.0
To: Bill Russell <[e-mail]>
CC: [e-mail], PKIX <[e-mail]>
Subject: Re: [x500standard] Re: User certificates
References: <B8D3935E5B484BFABE39B26AE82E33DF@ERA1> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit
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>

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=windows-1252"
 http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Bill,<br>
<br>
Here is the definition from X.509:<br>
<blockquote type="cite">A user may obtain one or more public-key
certificates from one or more
CAs. The userCertificate attribute type contains the public-key
certificates a user has obtained from one or more CAs.</blockquote>
So, it cannot be used to hold attribute certificates.  There is a
separate set of attributes to hold attribute certificates.  For
example, attributeCertificateAttribute:<br>
<blockquote type="cite">The [attributeCertificateAttribute] contains
attribute certificates issued to a specific holder and is stored in the
directory entry of that holder. </blockquote>
<br>
But, I am surprised to hear that most applications assume only one
certificate in the userCertificate attribute.  In most directory
entries that I see for end users, there are two certificates in the
userCertificate attribute: a digital signature certificate and a key
management certificate.<br>
<br>
Dave<br>
<br>
<br>
Bill Russell wrote:
<blockquote
 cite="mid:[e-mail]"
 type="cite">
  <meta http-equiv="Content-Type" content="text/html; ">
  <style>@font-face {
	font-family: Helvetica;
}
@font-face {
	font-family: Times;
}
@page Section1 {margin: 72.0pt 90.0pt 72.0pt 90.0pt; }
P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"
}
H3 {
	FONT-SIZE: 10pt; MARGIN: 9.05pt 0cm 6pt; FONT-FAMILY: Times; TEXT-ALIGN: justify
}
P.MsoToc4 {
	FONT-SIZE: 10pt; MARGIN: 0cm 0cm 0pt 87.9pt; TEXT-INDENT: -45.35pt; FONT-FAMILY: "Times New Roman"; TEXT-ALIGN: justify
}
LI.MsoToc4 {
	FONT-SIZE: 10pt; MARGIN: 0cm 0cm 0pt 87.9pt; TEXT-INDENT: -45.35pt; FONT-FAMILY: "Times New Roman"; TEXT-ALIGN: justify
}
DIV.MsoToc4 {
	FONT-SIZE: 10pt; MARGIN: 0cm 0cm 0pt 87.9pt; TEXT-INDENT: -45.35pt; FONT-FAMILY: "Times New Roman"; TEXT-ALIGN: justify
}
P.MsoToc5 {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt 48pt; FONT-FAMILY: "Times New Roman"
}
LI.MsoToc5 {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt 48pt; FONT-FAMILY: "Times New Roman"
}
DIV.MsoToc5 {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt 48pt; FONT-FAMILY: "Times New Roman"
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline
}
A:visited {
	COLOR: purple; TEXT-DECORATION: underline
}
SPAN.MsoHyperlinkFollowed {
	COLOR: purple; TEXT-DECORATION: underline
}
P.MsoAutoSig {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"
}
LI.MsoAutoSig {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"
}
DIV.MsoAutoSig {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"
}
P.ASN1 {
	FONT-WEIGHT: bold; FONT-SIZE: 9pt; MARGIN: 6.8pt 0cm 0pt; FONT-FAMILY: Helvetica
}
LI.ASN1 {
	FONT-WEIGHT: bold; FONT-SIZE: 9pt; MARGIN: 6.8pt 0cm 0pt; FONT-FAMILY: Helvetica
}
DIV.ASN1 {
	FONT-WEIGHT: bold; FONT-SIZE: 9pt; MARGIN: 6.8pt 0cm 0pt; FONT-FAMILY: Helvetica
}
SPAN.EmailStyle20 {
	COLOR: windowtext; FONT-FAMILY: Arial
}
DIV.Section1 {
	
}
  </style>
  <meta content="MSHTML 6.00.6001.18203" name="GENERATOR">
  <style title="owaParaStyle">P {
	MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
  </style>
  <div dir="ltr"><font color="#000000" face="Tahoma" size="2">I believe
the directory attribute userCertificate is a multivalue attribute. I
see no reason why it cannot be used to store an attribute certificate.
However, some applications may get confused. I think in practice, most
apps assume only one certificate in the userCertificate.</font></div>
  <div dir="ltr"> </div>
  <div dir="ltr"><font face="tahoma" size="2">The term "user" has
proved ambiguous; so, I'd agree that there would be some value in
defining it. However, I would not define it to exclude attribute
certificates.</font></div>
  <div id="divRpF623000" style="direction: ltr;">
  <hr tabindex="-1"><font face="Tahoma" size="2"><b><br>
  </b></font></div>
</blockquote>
<br>
</body>
</html>



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 n2OE5XC1009676 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Mar 2009 07:05:33 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2OE5XxM009675; Tue, 24 Mar 2009 07:05:33 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from calypso.bi.lt (calypso.bi.lt [213.226.153.10]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2OE5M9Z009662 for <[e-mail]>; Tue, 24 Mar 2009 07:05:32 -0700 (MST) (envelope-from [e-mail])
Received: from calypso.bi.lt (localhost [127.0.0.1]) by calypso.bi.lt (Postfix) with ESMTP id 497F74842C7; Tue, 24 Mar 2009 16:05:21 +0200 (EET)
Received: from [10.2.11.218] (unknown [10.2.11.218]) by calypso.bi.lt (Postfix) with ESMTP id D90D6484294; Tue, 24 Mar 2009 16:05:19 +0200 (EET)
From: "Moudrick M. Dadashov" <[e-mail]>
Reply-to: "Moudrick M. Dadashov" <[e-mail]>
To: "Erik Andersen" <[e-mail]>
Cc: "Directory list" <[e-mail]>, "PKIX" <[e-mail]>
Subject: RE: User certificates
Date: Tue, 24 Mar 2009 16:05:16 +0200
Message-ID: <[e-mail]>
X-Mailer: EPOC Email Version 2.10
MIME-Version: 1.0
Content-Language: i-default
Content-Type: text/plain; charset=UTF-8
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>

Is 'user certificate' the same as 'end entity' certificate used more =
often?

M.D.
Cell: [phone]=20

-original message-
Subject: User certificates
From: "Erik Andersen" <[e-mail]>
Date: 24.03.2009 16:00

The term "user certificate" is used in X.509 (and X.511) without =
being
defined. I assume that a user certificate is a public-key certificate =
issued
to  an end-user. There is an attribute type called userCertificate, =
which
has the syntax of public-key certificates. It seems therefore clear that =
a
user certificate cannot be an attribute certificate.

=20

In the "8.6.2.7 AA Issuing Distribution Point extension" the term =
user
certificate is mentioned in last the paragraph just before the three =
notes.
Is that correct?

=20

The term "user certificate" should be defined.

=20

Any comments?

=20

Erik Andersen

Andersen's L-Service

Elsevej 48, DK-3500 Vaerloese

Denmark

Mobile: [phone]

email: [e-mail]

www.x500.eu

www.x500standard.com

=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 n2ODdcTo007614 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Mar 2009 06:39:38 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2ODdbSb007613; Tue, 24 Mar 2009 06:39:37 -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 n2ODdPqa007601 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 24 Mar 2009 06:39:37 -0700 (MST) (envelope-from [e-mail])
Received: from ERA1 ([94.191.245.43]) by mail02.dandomain.dk (DanDomain Mailserver) with ASMTP id FQL00822; Tue, 24 Mar 2009 14:39:22 +0100
From: "Erik Andersen" <[e-mail]>
To: "Directory list" <[e-mail]>, "PKIX" <[e-mail]>
Subject: User certificates
Date: Tue, 24 Mar 2009 14:39:17 +0100
Message-ID: <B8D3935E5B484BFABE39B26AE82E33DF@ERA1>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0020_01C9AC8E.55125C90"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6838
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
thread-index: Acmshe2AVcny+5O6RnOBNNTE++h9Vw==
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0020_01C9AC8E.55125C90
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

The term "user certificate" is used in X.509 (and X.511) without being
defined. I assume that a user certificate is a public-key certificate =
issued
to  an end-user. There is an attribute type called userCertificate, =
which
has the syntax of public-key certificates. It seems therefore clear that =
a
user certificate cannot be an attribute certificate.

=20

In the "8.6.2.7 AA Issuing Distribution Point extension" the term user
certificate is mentioned in last the paragraph just before the three =
notes.
Is that correct?

=20

The term "user certificate" should be defined.

=20

Any comments?

=20

Erik Andersen

Andersen's L-Service

Elsevej 48, DK-3500 Vaerloese

Denmark

Mobile: [phone]

email: [e-mail]

www.x500.eu

www.x500standard.com

=20


------=_NextPart_000_0020_01C9AC8E.55125C90
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html>

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">


<meta name=3DGenerator content=3D"Microsoft Word 10 (filtered)">

<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Helvetica;
	panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
	{font-family:Times;
	panose-1:2 2 6 3 5 4 5 2 3 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
h3
	{margin-top:9.05pt;
	margin-right:0cm;
	margin-bottom:6.0pt;
	margin-left:0cm;
	text-align:justify;
	page-break-after:avoid;
	font-size:10.0pt;
	font-family:Times;}
p.MsoToc4, li.MsoToc4, div.MsoToc4
	{margin-top:0cm;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:87.9pt;
	margin-bottom:.0001pt;
	text-align:justify;
	text-indent:-45.35pt;
	font-size:10.0pt;
	font-family:"Times New Roman";}
p.MsoToc5, li.MsoToc5, div.MsoToc5
	{margin-top:0cm;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:48.0pt;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p.MsoAutoSig, li.MsoAutoSig, div.MsoAutoSig
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
p.ASN1, li.ASN1, div.ASN1
	{margin-top:6.8pt;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:0cm;
	margin-bottom:.0001pt;
	punctuation-wrap:simple;
	text-autospace:none;
	font-size:9.0pt;
	font-family:Helvetica;
	font-weight:bold;}
span.EmailStyle20
	{font-family:Arial;
	color:windowtext;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

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

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>The term &#8220;user certificate&#8221; is =
used in
X.509 (and X.511) without being defined. I assume that a user =
certificate is a
public-key certificate issued to &nbsp;an end-user. There is an =
attribute type called
userCertificate, which has the syntax of public-key certificates. It =
seems therefore
clear that a user certificate cannot be an attribute =
certificate.</span></font></p>

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

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>In the <a =
name=3D"_Toc209430490">&#8220;8.6.2.7 AA
Issuing Distribution Point extension</a>&#8221; the term user =
certificate is
mentioned in last the paragraph just before the three notes. Is that =
correct?</span></font></p>

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

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>The term &#8220;user certificate&#8221; should =
be defined.</span></font></p>

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

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>Any comments?</span></font></p>

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

<p class=3DMsoAutoSig><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Erik Andersen</span></font></p>

<p class=3DMsoAutoSig><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Andersen's L-Service</span></font></p>

<p class=3DMsoAutoSig><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Elsevej 48, DK-3500 Vaerloese</span></font></p>

<p class=3DMsoAutoSig><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Denmark</span></font></p>

<p class=3DMsoAutoSig><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>Mobile: [phone]</span></font></p>

<p class=3DMsoAutoSig><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>email: </span></font><font size=3D2 =
face=3DArial><span
 lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:Arial'>[e-mail]</span></font></p=
>

<p class=3DMsoAutoSig><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>www.x500.eu</span></font></p>

<p class=3DMsoAutoSig><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>www.x500standard.com</span></font></p>

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

</div>

</body>

</html>

------=_NextPart_000_0020_01C9AC8E.55125C90--



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 n2OBugw2099770 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Mar 2009 04:56:42 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2OBugpu099769; Tue, 24 Mar 2009 04:56:42 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.multicert.com (mail.multicert.com [62.48.217.200]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2OBuTau099755 for <[e-mail]>; Tue, 24 Mar 2009 04:56:40 -0700 (MST) (envelope-from [e-mail])
Received: from 10.0.0.194 (webmail.multicert.com [10.0.0.194]) by mail.multicert.prod (Postfix) with SMTP id 6207472DF1; Tue, 24 Mar 2009 11:56:29 +0000 (WET)
X-Spambayes-Classification: ham; 0.00
Received: from [192.168.128.136] (33.14.103.87.rev.vodafone.pt [87.103.14.33]) by mail.multicert.com (Postfix) with ESMTP id 7DF8D72DEF; Tue, 24 Mar 2009 11:56:28 +0000 (WET)
Message-ID: <[e-mail]>
Date: Tue, 24 Mar 2009 11:56:26 +0000
From: Nuno Ponte <[e-mail]>
Organization: MULTICERT - =?ISO-8859-1?Q?Servi=E7os_de_Certifica=E7=E3?= =?ISO-8859-1?Q?o_Electr=F3nica=2C_S=2EA=2E?=
User-Agent: Mozilla/5.0 (X11; U; Linux i686; pt-PT; rv:1.9.1b3pre) Gecko/20090223 Lightning/1.0pre Thunderbird/3.0b2
MIME-Version: 1.0
To: "David A. Cooper" <[e-mail]>
Cc: pkix <[e-mail]>
Subject: Re: Need help finding implementations of certain RFC 5280 features
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080800010409080007000707"
Sender: [e-mail]
Precedence: 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.

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

Em 05-03-2009 22:55, David A. Cooper escreveu:
>
> All,
>
> I have been asked to work on finding two independent implementations=20
> of every feature in RFC 5280 in order to support the process of=20
> advancing RFC 5280 to Draft Standard.  I have been fairly successful=20
> so far, but there are a lot of features in RFC 5280 that need to be=20
> covered.  So, this will likely be the first of many emails requesting=20
> help in finding implementations of certain features.
>
> So, please let me know if you are aware of any certificates that=20
> satisfy either of the following requirements:
>
> 1) From Section 4.2.1.4 (Certificate Policies):
>
>      An explicitText field includes the textual statement directly in
>      the certificate.  The explicitText field is a string with a
>      maximum size of 200 characters.  Conforming CAs SHOULD use the
>      UTF8String encoding for explicitText, but MAY use IA5String.
>      Conforming CAs MUST NOT encode explicitText as VisibleString or
>      BMPString.  The explicitText string SHOULD NOT include any control=

>      characters (e.g., U+0000 to U+001F and U+007F to U+009F).  When
>      the UTF8String encoding is used, all character sequences SHOULD be=

>      normalized according to Unicode normalization form C (NFC) [NFC].
>
> I have found several certificates that include a userNotice policy=20
> qualifier with explicitText, but every one of them encodes the=20
> explicitText as VisibleString.

     I think this is due to the lack of support for UserNotices in=20
UTF8String on older versions of Microsoft Internet Explorer (as far as I =

remember, IE6 still had this problem).
     As an example, the EJBCA software (http://www.ejbca.org) has a=20
configuration to choose whether the UserNotice is encoded in UTF8String=20
or BMPString.

>
> 2) From Section 4.2.2.1 (Authority Information Access):
>
>   HTTP server implementations accessed via the URI SHOULD specify the
>   media type application/pkix-cert [RFC2585] in the content-type header=

>   field of the response for a single DER encoded certificate....
>
> I have found several certificates that include an AIA extension with=20
> an id-ad-caIssuers access method with an HTTP URI that points to a=20
> single certificate, but none of the HTTP servers specify the media=20
> type as application/pkix-cert.  Most specify the media type as=20
> application/x-x509-ca-cert and a few specify the media type as=20
> text/plain.
>
>
> Thanks in advance for any help you can give me locating certificates=20
> (and HTTP servers) that can be used to demonstrate the existence of=20
> implementations of these features.
>
> Dave
>
>
>
>



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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRKzCC
BCEwggOKoAMCAQICBAQAA9QwDQYJKoZIhvcNAQEFBQAwdTELMAkGA1UEBhMCVVMxGDAWBgNV
BAoTD0dURSBDb3Jwb3JhdGlvbjEnMCUGA1UECxMeR1RFIEN5YmVyVHJ1c3QgU29sdXRpb25z
LCBJbmMuMSMwIQYDVQQDExpHVEUgQ3liZXJUcnVzdCBHbG9iYWwgUm9vdDAeFw0wNTA1MDUx
NDA3MDBaFw0xMjA1MDUyMzU5MDBaMD4xCzAJBgNVBAYTAnB0MRUwEwYDVQQKEwxNVUxUSUNF
UlQtQ0ExGDAWBgNVBAMTD01VTFRJQ0VSVC1DQSAwMjCCASIwDQYJKoZIhvcNAQEBBQADggEP
ADCCAQoCggEBAN0N2tOSOeBzmTNW52Z0lF8dai+9/j7REYIiJfjG2GrD/lC/pd8kBHaZZtYQ
Yo6QuoD8Rz1y6Mz9+bZEgm9r+E7HWOoBPIeuVF2Q3Tol/4gcnBvNeubCwMtjQJYnz2zHiho8
iPRXmtDLfWkXzVzPtUgsjooZh1w1ePr95tdiF4+fjv5eUcYn/27Oxj0Gy+FwCU9nAKZ2nO8g
/92NgJZOP1uQgap4+GBlAK3xKyGkj0WohkhAGYhEuvfol8aeS7Hgq9EmeCqvpVIIJc+jORHs
HAzG+69xAiTN+KZf3LsJc47QDQibzU4kcifaLfBk/+vuZf9GX/QYAcifB3cvKBqP4jcCAwEA
AaOCAW8wggFrMEUGA1UdHwQ+MDwwOqA4oDaGNGh0dHA6Ly93d3cucHVibGljLXRydXN0LmNv
bS9jZ2ktYmluL0NSTC8yMDE4L2NkcC5jcmwwHQYDVR0OBBYEFB3DuYilGL5gpyymY8pmKvwM
J8G9MFMGA1UdIARMMEowSAYJKwYBBAGxPgEAMDswOQYIKwYBBQUHAgEWLWh0dHA6Ly93d3cu
cHVibGljLXRydXN0LmNvbS9DUFMvT21uaVJvb3QuaHRtbDCBiQYDVR0jBIGBMH+heaR3MHUx
CzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9HVEUgQ29ycG9yYXRpb24xJzAlBgNVBAsTHkdURSBD
eWJlclRydXN0IFNvbHV0aW9ucywgSW5jLjEjMCEGA1UEAxMaR1RFIEN5YmVyVHJ1c3QgR2xv
YmFsIFJvb3SCAgGlMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEBMA0GCSqG
SIb3DQEBBQUAA4GBABe6tGhEuFeobKVmaJmt7Qq84Na2i6IazEX4vp720nXMT+VS3UsP5btB
Y3uvIETXOZKaG9/bRVEtJH6smOyFVvqdRRGKS0DYnMesAIIvckozZBSen2/+X/qP0W7WCWXo
mlJUIMwLN2J3Br6XTCof68TEVpdw+Y0qvxZUKw2Qd/SGMIIGfzCCBWegAwIBAgIEQmnyPDAN
BgkqhkiG9w0BAQUFADA+MQswCQYDVQQGEwJwdDEVMBMGA1UEChMMTVVMVElDRVJULUNBMRgw
FgYDVQQDEw9NVUxUSUNFUlQtQ0EgMDIwHhcNMDgwNDE3MTYyNTE0WhcNMDkwODAyMTYzNzIx
WjCCAQoxCzAJBgNVBAYTAlBUMRUwEwYDVQQKEwxNVUxUSUNFUlQtQ0ExFjAUBgNVBAsTDUNF
UlRJUE9SIC0gUkExEjAQBgNVBAsTCUNvcnBvcmF0ZTE+MDwGA1UECxM1TVVMVElDRVJUIC0g
U2Vydmljb3MgZGUgQ2VydGlmaWNhY2FvIEVsZWN0cm9uaWNhIFMuQS4xMTAvBgNVBAsTKElu
dGVncmFjYW8gRGVzZW52b2x2aW1lbnRvIGUgQ29uc3VsdG9yaWExFDASBgNVBAsTC1BlcnNv
bmFsIElEMS8wLQYDVQQDEyZOdW5vIE1pZ3VlbCBBcmllaXJvIFJvZHJpZ3VlcyBkYSBQb250
ZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMlVuImUD9fjTFbxpk8GZx2dcPhf
nV45izmuh2jjUD6leaFBMP//YIRkGsO5ee9+c3WF+5YM6Rw863LsWfQFfoUru03buXiBhDey
+lNkQyuEEcU+wgDTy1HDuSr+F6nlJTGRdDK32AnnWoqc/SzxkfRlqChPGPHcLjLOLGR/54pm
tUXrtcQqJ4hC2fmArO7s1Aax8RllVBnFo1RFywK77xtCbVKrM3F/Bu7Bcls4kn2VoG4EoRnG
pXmHdOnCsPLnEIpz+/uzbOQANhCQUILpkvHg53NdoHITbhvyq9L/yGqCx9x/Idx8B3fFKWsq
IX3qtOMbvlnuJQiecBuLnMB+lzUCAwEAAaOCArUwggKxMAsGA1UdDwQEAwID+DA4BggrBgEF
BQcBAQQsMCowKAYIKwYBBQUHMAGBHGh0dHA6Ly9vY3NwLm11bHRpY2VydC5jb20vY2EwgeAG
A1UdIASB2DCB1TBNBgkrBgEEAbA8CgIwQDA+BggrBgEFBQcCARYyaHR0cDovL3d3dy5tdWx0
aWNlcnQuY29tL2Nwcy9tdWx0aWNlcnQtY2EtY3BzLmh0bWwwgYMGCysGAQQBsDwKAodtMHQw
cgYIKwYBBQUHAgIwZh5kAGgAdAB0AHAAOgAvAC8AdwB3AHcALgBtAHUAbAB0AGkAYwBlAHIA
dAAuAGMAbwBtAC8AYwBwAC8AbQB1AGwAdABpAGMAZQByAHQALQBjAGEALQAxADAAMAA1AC4A
aAB0AG0AbDARBglghkgBhvhCAQEEBAMCBaAwIwYDVR0RBBwwGoEYbnVuby5wb250ZUBtdWx0
aWNlcnQuY29tMIIBAAYDVR0fBIH4MIH1MIGaoIGXoIGUhi9odHRwOi8vd3d3Lm11bHRpY2Vy
dC5jb20vY2EvbXVsdGljZXJ0LWNhLTAyLmNybIZhbGRhcDovL2xkYXAubXVsdGljZXJ0LmNv
bS9jbj1NVUxUSUNFUlQtQ0ElMjAwMixvPU1VTFRJQ0VSVC1DQSxjPVBUP2NlcnRpZmljYXRl
UmV2b2NhdGlvbkxpc3Q/YmFzZTBWoFSgUqRQME4xCzAJBgNVBAYTAnB0MRUwEwYDVQQKEwxN
VUxUSUNFUlQtQ0ExGDAWBgNVBAMTD01VTFRJQ0VSVC1DQSAwMjEOMAwGA1UEAxMFQ1JMNzEw
HwYDVR0jBBgwFoAUHcO5iKUYvmCnLKZjymYq/Awnwb0wHQYDVR0OBBYEFKCTcs+ugAbPdt2O
kYHBlGKcaNKuMAkGA1UdEwQCMAAwDQYJKoZIhvcNAQEFBQADggEBADDVblqFDMEgouIWUbT5
MHZKChTSV03e0nNw7GySueMYoIv2MAG20TbaKbXLQm8At90l4AO7xTwoi5KYHXqKq4KcFcQt
y0La78REDHLLf+ks1UIhpStjjHx8gi84h+f0hj5bg4QSjLhZf03G0GP4s3lwkWDTan72Ktnq
54SJOs7Uyvv4gSlQLJx6mE0/qlRTYe77ATPNqeSww89gs4TEH69iBkFovFs5hl512Bm3rM4Z
H0ac6gfamoWMfdBy8kCzhao9kuHz30wfnE0Q86e6+bJRZwz579h7qfEqEmEjwnLPqP7XC1KQ
P7TGB2ZrWo0AfFNJm15fqSAg3ifGNjsOV/MwggZ/MIIFZ6ADAgECAgRCafI8MA0GCSqGSIb3
DQEBBQUAMD4xCzAJBgNVBAYTAnB0MRUwEwYDVQQKEwxNVUxUSUNFUlQtQ0ExGDAWBgNVBAMT
D01VTFRJQ0VSVC1DQSAwMjAeFw0wODA0MTcxNjI1MTRaFw0wOTA4MDIxNjM3MjFaMIIBCjEL
MAkGA1UEBhMCUFQxFTATBgNVBAoTDE1VTFRJQ0VSVC1DQTEWMBQGA1UECxMNQ0VSVElQT1Ig
LSBSQTESMBAGA1UECxMJQ29ycG9yYXRlMT4wPAYDVQQLEzVNVUxUSUNFUlQgLSBTZXJ2aWNv
cyBkZSBDZXJ0aWZpY2FjYW8gRWxlY3Ryb25pY2EgUy5BLjExMC8GA1UECxMoSW50ZWdyYWNh
byBEZXNlbnZvbHZpbWVudG8gZSBDb25zdWx0b3JpYTEUMBIGA1UECxMLUGVyc29uYWwgSUQx
LzAtBgNVBAMTJk51bm8gTWlndWVsIEFyaWVpcm8gUm9kcmlndWVzIGRhIFBvbnRlMIIBIjAN
BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyVW4iZQP1+NMVvGmTwZnHZ1w+F+dXjmLOa6H
aONQPqV5oUEw//9ghGQaw7l5735zdYX7lgzpHDzrcuxZ9AV+hSu7Tdu5eIGEN7L6U2RDK4QR
xT7CANPLUcO5Kv4XqeUlMZF0MrfYCedaipz9LPGR9GWoKE8Y8dwuMs4sZH/nima1Reu1xCon
iELZ+YCs7uzUBrHxGWVUGcWjVEXLArvvG0JtUqszcX8G7sFyWziSfZWgbgShGcaleYd06cKw
8ucQinP7+7Ns5AA2EJBQgumS8eDnc12gchNuG/Kr0v/IaoLH3H8h3HwHd8Upayohfeq04xu+
We4lCJ5wG4ucwH6XNQIDAQABo4ICtTCCArEwCwYDVR0PBAQDAgP4MDgGCCsGAQUFBwEBBCww
KjAoBggrBgEFBQcwAYEcaHR0cDovL29jc3AubXVsdGljZXJ0LmNvbS9jYTCB4AYDVR0gBIHY
MIHVME0GCSsGAQQBsDwKAjBAMD4GCCsGAQUFBwIBFjJodHRwOi8vd3d3Lm11bHRpY2VydC5j
b20vY3BzL211bHRpY2VydC1jYS1jcHMuaHRtbDCBgwYLKwYBBAGwPAoCh20wdDByBggrBgEF
BQcCAjBmHmQAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAG0AdQBsAHQAaQBjAGUAcgB0AC4AYwBv
AG0ALwBjAHAALwBtAHUAbAB0AGkAYwBlAHIAdAAtAGMAYQAtADEAMAAwADUALgBoAHQAbQBs
MBEGCWCGSAGG+EIBAQQEAwIFoDAjBgNVHREEHDAagRhudW5vLnBvbnRlQG11bHRpY2VydC5j
b20wggEABgNVHR8EgfgwgfUwgZqggZeggZSGL2h0dHA6Ly93d3cubXVsdGljZXJ0LmNvbS9j
YS9tdWx0aWNlcnQtY2EtMDIuY3JshmFsZGFwOi8vbGRhcC5tdWx0aWNlcnQuY29tL2NuPU1V
TFRJQ0VSVC1DQSUyMDAyLG89TVVMVElDRVJULUNBLGM9UFQ/Y2VydGlmaWNhdGVSZXZvY2F0
aW9uTGlzdD9iYXNlMFagVKBSpFAwTjELMAkGA1UEBhMCcHQxFTATBgNVBAoTDE1VTFRJQ0VS
VC1DQTEYMBYGA1UEAxMPTVVMVElDRVJULUNBIDAyMQ4wDAYDVQQDEwVDUkw3MTAfBgNVHSME
GDAWgBQdw7mIpRi+YKcspmPKZir8DCfBvTAdBgNVHQ4EFgQUoJNyz66ABs923Y6RgcGUYpxo
0q4wCQYDVR0TBAIwADANBgkqhkiG9w0BAQUFAAOCAQEAMNVuWoUMwSCi4hZRtPkwdkoKFNJX
Td7Sc3DsbJK54xigi/YwAbbRNtoptctCbwC33SXgA7vFPCiLkpgdeoqrgpwVxC3LQtrvxEQM
cst/6SzVQiGlK2OMfHyCLziH5/SGPluDhBKMuFl/TcbQY/izeXCRYNNqfvYq2ernhIk6ztTK
+/iBKVAsnHqYTT+qVFNh7vsBM82p5LDDz2CzhMQfr2IGQWi8WzmGXnXYGbeszhkfRpzqB9qa
hYx90HLyQLOFqj2S4fPfTB+cTRDzp7r5slFnDPnv2Hup8SoSYSPCcs+o/tcLUpA/tMYHZmta
jQB8U0mbXl+pICDeJ8Y2Ow5X8zGCAt8wggLbAgEBMEYwPjELMAkGA1UEBhMCcHQxFTATBgNV
BAoTDE1VTFRJQ0VSVC1DQTEYMBYGA1UEAxMPTVVMVElDRVJULUNBIDAyAgRCafI8MAkGBSsO
AwIaBQCgggFuMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA5
MDMyNDExNTYyNlowIwYJKoZIhvcNAQkEMRYEFOnfhq8zjBUdwZI9y1W31b/Ui6PoMFUGCSsG
AQQBgjcQBDFIMEYwPjELMAkGA1UEBhMCcHQxFTATBgNVBAoTDE1VTFRJQ0VSVC1DQTEYMBYG
A1UEAxMPTVVMVElDRVJULUNBIDAyAgRCafI8MFcGCyqGSIb3DQEJEAILMUigRjA+MQswCQYD
VQQGEwJwdDEVMBMGA1UEChMMTVVMVElDRVJULUNBMRgwFgYDVQQDEw9NVUxUSUNFUlQtQ0Eg
MDICBEJp8jwwXwYJKoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYI
KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMA0G
CSqGSIb3DQEBAQUABIIBAHikKEjJdG/HuhPGTs/eVEj84OwL4ZPBBw4rNuYlUsp8BMW01RsF
np2bR28MrNLBXaSsWzvY79c+3KEZji2rqbdWRQyEcENTFeSgG4XZy0O6tkKVdxSpigywgfD/
ySq4BSWfvnrhpu3ZAWE/V8+aM+Xy14LLO5Ck5FQlT91IULMOLMR1jr05siJJLIFx6IkNIEbt
i2BJAuB0aCHcimDJ/jEWbPP3qfDsSx9F9acXyB30rMQG37m+xCugP9QQyyFLVWKR+LugCu2P
UzGnrysss6MHDuSyARa3jbiLsW6NJaO0jc8Y6zvy+fbxqojwYTu2yAK5jCALKBJ30ghM4d2l
dYcAAAAAAAA=
--------------ms080800010409080007000707--



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 n2NNm6wE056451 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Mar 2009 16:48:06 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2NNm6bj056450; Mon, 23 Mar 2009 16:48:06 -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 n2NNltr2056435 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 23 Mar 2009 16:48:06 -0700 (MST) (envelope-from [e-mail])
Received: from dommiel.bbn.com ([192.1.122.15] helo=[130.129.16.179]) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from <[e-mail]>) id 1Llts2-0002vj-9r for [e-mail]; Mon, 23 Mar 2009 19:47:54 -0400
Mime-Version: 1.0
Message-Id: <p06240804c5edcf8f1b46@[130.129.16.179]>
Date: Mon, 23 Mar 2009 19:47:51 -0400
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: draft minutes available
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,

I have uploaded the draft minutes for today's meeting:

http://www.ietf.org/proceedings/09mar/minutes/pkix.htm


Please review and comment.  I will process the comments for the next 
few days, and then when I return from vacation on 4/13.

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 n2NJtt4X043557 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Mar 2009 12: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 n2NJttf5043556; Mon, 23 Mar 2009 12: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 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 n2NJtiIg043543 for <[e-mail]>; Mon, 23 Mar 2009 12:55:55 -0700 (MST) (envelope-from [e-mail])
Received: from AndersPC (81.232.45.215) by pne-smtpout1-sn2.hy.skanova.net (7.3.129) id 48A144C503566F25; Mon, 23 Mar 2009 20:55:39 +0100
Message-ID: <98066547CDC046F68FBAFCE5F72A83B0@AndersPC>
From: "Anders Rundgren" <[e-mail]>
To: "Nuno Ponte" <[e-mail]>
Cc: "Stefan Santesson" <[e-mail]>, "'IETF-pkix'" <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: Re: PKIX bar discussion: <keygen>. Re: Agenda update and slides reminder
Date: Mon, 23 Mar 2009 20:55:59 +0100
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0119_01C9ABF9.C4EAFA30"
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_0119_01C9ABF9.C4EAFA30
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi Nuno,

Yes, generateCRMFRequest () could serve as a starting point.

That it doesn't support PIN policies which for example IETF's KEYPROV
activity does for symmetric keys, indicates that generateCRMFRequest will
though unlikely suffice as an end point.

The lack of support for subject key attestations like for example specified by
the TrustedComputingGroup is IMHO a disqualifying factor for all existing
browser key-gen schemes.

Regards
Anders

----- Original Message ----- 
From: "Nuno Ponte" <[e-mail]>
To: "Anders Rundgren" <[e-mail]>
Cc: "Stefan Santesson" <[e-mail]>; "'IETF-pkix'" <[e-mail]>
Sent: Monday, March 23, 2009 17:12
Subject: Re: PKIX bar discussion: <keygen>. Re: Agenda update and slides reminder


     Besides the old keygen tag, Mozilla offers a more powerful method 
for key provisioning, based in Javascript:

https://developer.mozilla.org/en/JavaScript_crypto

     It may be a starting point...

     Regards,

                     Nuno Ponte

Em 23-03-2009 14:37, Anders Rundgren escreveu:
>
> I'm sorry about not being able to visit the IETF.
>
> In case there will be any interesting evening discussions may I add
> something that you could talk about?
>
> As some of you may know the <keygen> tag was dismissed from
> the HTML5 WG spec. because it was found to be inferior.
> <keygen> is currently used by Apple, Mozilla, Nokia and Google browsers.
>
> The idea of putting a key-generation mechanism in a page-description
> language was more like a patch by Netscape more than a decade ago.
>
> Microsoft's counterpart to <keygen>, CertEnroll has AFAIK not been
> proposed as the foundation for a standard.
>
> I think it is about time to create something more thought-through that
> also supports smart cards and similar crypto containers:
> http://webpki.org/papers/keygen2/keygen2-fips140-2.pdf
>
> It is worth noting that the scheme above does not work with PKCS #11,
> JCE, or CryptoAPI for key provisioning (since they do not support
> key attestations), but for key usage.
>
> Although not exploited in the current spec., key attestations can also
> be extended to bind declared PIN policies to generated keys.   This
> potentially enables a technical security for out-in-the-field on-line
> key provisioning that is in par with in-house production.  The use-case
> for this includes:
> - Consumer PKIs
> - Spare cards for employees that are far from their homebase
> - Mobile devices with build-in crypto HW
>
> The realization of this project is not going particularly quick (it is
> not my day-job), but it is not standing completely still either.
>
> Anders
>
> Stefan Santesson wrote:
>> I have posted a hopefully final agenda to the PKIX meeting available at:
>> http://www.ietf.org/proceedings/09mar/agenda/pkix.txt
>>
>> Meeting materials received so far are available at:
>> https://datatracker.ietf.org/meeting/74/materials.html
>>
>> I need all presentations sent to me before 17.00 San Francisco time 
>> on Sunday so I can have them all posted before the meeting starts at 
>> 0900 Monday morning.
>>
>> Thank you
>>
>> *Stefan Santesson
>> *AAA-sec.com
>>
>>
>
>
>
>



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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAMYIBsDCCAawC
AQEwTTBDMRMwEQYKCZImiZPyLGQBGRMDb3JnMRYwFAYKCZImiZPyLGQBGRMGd2VicGtpMRQwEgYD
VQQDEwtEZW1vIFN1YiBDQQIGAReGp2GAMAkGBSsOAwIaBQCggbowGAYJKoZIhvcNAQkDMQsGCSqG
SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwMzIzMTk1NTU5WjAjBgkqhkiG9w0BCQQxFgQUjti5
EYVVRFFrm3X5C9lopmdq/ZwwWwYJKoZIhvcNAQkPMU4wTDAKBggqhkiG9w0DBzAOBggqhkiG9w0D
AgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwBwYFKw4DAh0wDQYJ
KoZIhvcNAQEBBQAEgYBt0Jrj+AO/qBv0cGvdDVB5yLa3cOYjvHXrouXRVst4NU+WaMvHpZSXQ1kq
9tnjrFKgf56YsC10I9HzgEdhe9VkHRn/7ZLBMn8SaZT86x+0xfiVgNMhVPxvwGLOd3rXgcPGPjI2
qWwo5bbW1tDKgkgpetcantyHcm2fSavCzuDMqgAAAAAAAA==

------=_NextPart_000_0119_01C9ABF9.C4EAFA30--



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 n2NI6QpI036083 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Mar 2009 11:06:26 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2NI6QhR036082; Mon, 23 Mar 2009 11:06:26 -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 n2NI6Dha036064 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 23 Mar 2009 11:06:24 -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 n2NI630k018215 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 23 Mar 2009 14:06:07 -0400
Message-ID: <[e-mail]>
Date: Mon, 23 Mar 2009 11:06:48 -0700
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: Nuno Ponte <[e-mail]>
CC: Anders Rundgren <[e-mail]>, Stefan Santesson <[e-mail]>, "'IETF-pkix'" <[e-mail]>
Subject: Re: PKIX bar discussion: <keygen>
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010903010905040907090401"
Sender: [e-mail]
Precedence: 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.

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

Ciao,

as a practitioner in the PKI area, I have to say that we need to have a
more powerful tool than the <keygen> tag. This said, I have to underline
that as a developer *I LOVED* the <keygen> tag because it worked all the
times, for many years, it was simple and easy to support.

Supporting other solutions took me a lot of development work and supporting
them was time and resource-consuming.

We need one standard, and we need to address *USABILITY* from three point
of view:
- Users
- Developers (Browsers)
- Developers (CAs - PKI Deployers)

So.. is there going to be some discussion about this ``at the bar'', offline
or somewhere else ?

Later,
Max


Nuno Ponte wrote:
>     Besides the old keygen tag, Mozilla offers a more powerful method 
> for key provisioning, based in Javascript:
> 
> https://developer.mozilla.org/en/JavaScript_crypto
> 
>     It may be a starting point...
> 
>     Regards,
> 
>                     Nuno Ponte
> 
> Em 23-03-2009 14:37, Anders Rundgren escreveu:
>>
>> I'm sorry about not being able to visit the IETF.
>>
>> In case there will be any interesting evening discussions may I add
>> something that you could talk about?
>>
>> As some of you may know the <keygen> tag was dismissed from
>> the HTML5 WG spec. because it was found to be inferior.
>> <keygen> is currently used by Apple, Mozilla, Nokia and Google browsers.
>>
>> The idea of putting a key-generation mechanism in a page-description
>> language was more like a patch by Netscape more than a decade ago.
>>
>> Microsoft's counterpart to <keygen>, CertEnroll has AFAIK not been
>> proposed as the foundation for a standard.
>>
>> I think it is about time to create something more thought-through that
>> also supports smart cards and similar crypto containers:
>> http://webpki.org/papers/keygen2/keygen2-fips140-2.pdf
>>
>> It is worth noting that the scheme above does not work with PKCS #11,
>> JCE, or CryptoAPI for key provisioning (since they do not support
>> key attestations), but for key usage.
>>
>> Although not exploited in the current spec., key attestations can also
>> be extended to bind declared PIN policies to generated keys.   This
>> potentially enables a technical security for out-in-the-field on-line
>> key provisioning that is in par with in-house production.  The use-case
>> for this includes:
>> - Consumer PKIs
>> - Spare cards for employees that are far from their homebase
>> - Mobile devices with build-in crypto HW
>>
>> The realization of this project is not going particularly quick (it is
>> not my day-job), but it is not standing completely still either.
>>
>> Anders
>>
>> Stefan Santesson wrote:
>>> I have posted a hopefully final agenda to the PKIX meeting available at:
>>> http://www.ietf.org/proceedings/09mar/agenda/pkix.txt
>>>
>>> Meeting materials received so far are available at:
>>> https://datatracker.ietf.org/meeting/74/materials.html
>>>
>>> I need all presentations sent to me before 17.00 San Francisco time 
>>> on Sunday so I can have them all posted before the meeting starts at 
>>> 0900 Monday morning.
>>>
>>> Thank you
>>>
>>> *Stefan Santesson
>>> *AAA-sec.com
>>>
>>>
>>
>>
>>
>>
> 
> 


-- 

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

--------------ms010903010905040907090401
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
AKCCAdEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwMzIz
MTgwNjQ4WjAjBgkqhkiG9w0BCQQxFgQUl90FMnheg9HJ2I/j3FiwdfFhf4UwUgYJKoZIhvcN
AQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYF
Kw4DAgcwDQYIKoZIhvcNAwICASgwgYwGCSsGAQQBgjcQBDF/MH0wdzETMBEGCgmSJomT8ixk
ARkWA2VkdTEZMBcGCgmSJomT8ixkARkWCWRhcnRtb3V0aDELMAkGA1UEBhMCVVMxGjAYBgNV
BAoTEURhcnRtb3V0aCBDb2xsZWdlMRwwGgYDVQQDExNEYXJ0bW91dGggQ2VydEF1dGgxAgIa
UzCBjgYLKoZIhvcNAQkQAgsxf6B9MHcxEzARBgoJkiaJk/IsZAEZFgNlZHUxGTAXBgoJkiaJ
k/IsZAEZFglkYXJ0bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91dGggQ29s
bGVnZTEcMBoGA1UEAxMTRGFydG1vdXRoIENlcnRBdXRoMQICGlMwDQYJKoZIhvcNAQEBBQAE
gYAjpvKnDfRgJppK928JD/ZaGvSUnkHntuK53I/UjqulOU1TsoyxEL4iwbXXtYSLsYD8gGmV
YZFbBQNoUuqCo71tO9nsmZFp7UyQjYuyF/YWFxraxi6yh9qeM0y8dmhkDGThwOnPwJF+pq9C
p51T5LRw6zPP0FkjA2wDJh20mTre/gAAAAAAAA==
--------------ms010903010905040907090401--



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 n2NGCPl7028597 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Mar 2009 09:12:25 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2NGCPxI028596; Mon, 23 Mar 2009 09:12: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.multicert.com (mail.multicert.com [62.48.217.200]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2NGCCwq028565 for <[e-mail]>; Mon, 23 Mar 2009 09:12:23 -0700 (MST) (envelope-from [e-mail])
Received: from 10.0.0.194 (webmail.multicert.com [10.0.0.194]) by mail.multicert.prod (Postfix) with SMTP id 37FFD72DF5; Mon, 23 Mar 2009 16:12:12 +0000 (WET)
X-Spambayes-Classification: ham; 0.00
Received: from [192.168.128.136] (33.14.103.87.rev.vodafone.pt [87.103.14.33]) by mail.multicert.com (Postfix) with ESMTP id E635672DED; Mon, 23 Mar 2009 16:12:08 +0000 (WET)
Message-ID: <[e-mail]>
Date: Mon, 23 Mar 2009 16:12:05 +0000
From: Nuno Ponte <[e-mail]>
Organization: MULTICERT - =?ISO-8859-1?Q?Servi=E7os_de_Certifica=E7=E3?= =?ISO-8859-1?Q?o_Electr=F3nica=2C_S=2EA=2E?=
User-Agent: Mozilla/5.0 (X11; U; Linux i686; pt-PT; rv:1.9.1b3pre) Gecko/20090223 Lightning/1.0pre Thunderbird/3.0b2
MIME-Version: 1.0
To: Anders Rundgren <[e-mail]>
Cc: Stefan Santesson <[e-mail]>, "'IETF-pkix'" <[e-mail]>
Subject: Re: PKIX bar discussion: <keygen>. Re: Agenda update and slides reminder
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020209070405050702090006"
Sender: [e-mail]
Precedence: 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.

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

     Besides the old keygen tag, Mozilla offers a more powerful method=20
for key provisioning, based in Javascript:

https://developer.mozilla.org/en/JavaScript_crypto

     It may be a starting point...

     Regards,

                     Nuno Ponte

Em 23-03-2009 14:37, Anders Rundgren escreveu:
>
> I'm sorry about not being able to visit the IETF.
>
> In case there will be any interesting evening discussions may I add
> something that you could talk about?
>
> As some of you may know the <keygen> tag was dismissed from
> the HTML5 WG spec. because it was found to be inferior.
> <keygen> is currently used by Apple, Mozilla, Nokia and Google browsers=
=2E
>
> The idea of putting a key-generation mechanism in a page-description
> language was more like a patch by Netscape more than a decade ago.
>
> Microsoft's counterpart to <keygen>, CertEnroll has AFAIK not been
> proposed as the foundation for a standard.
>
> I think it is about time to create something more thought-through that
> also supports smart cards and similar crypto containers:
> http://webpki.org/papers/keygen2/keygen2-fips140-2.pdf
>
> It is worth noting that the scheme above does not work with PKCS #11,
> JCE, or CryptoAPI for key provisioning (since they do not support
> key attestations), but for key usage.
>
> Although not exploited in the current spec., key attestations can also
> be extended to bind declared PIN policies to generated keys.   This
> potentially enables a technical security for out-in-the-field on-line
> key provisioning that is in par with in-house production.  The use-case=

> for this includes:
> - Consumer PKIs
> - Spare cards for employees that are far from their homebase
> - Mobile devices with build-in crypto HW
>
> The realization of this project is not going particularly quick (it is
> not my day-job), but it is not standing completely still either.
>
> Anders
>
> Stefan Santesson wrote:
>> I have posted a hopefully final agenda to the PKIX meeting available a=
t:
>> http://www.ietf.org/proceedings/09mar/agenda/pkix.txt
>>
>> Meeting materials received so far are available at:
>> https://datatracker.ietf.org/meeting/74/materials.html
>>
>> I need all presentations sent to me before 17.00 San Francisco time=20
>> on Sunday so I can have them all posted before the meeting starts at=20
>> 0900 Monday morning.
>>
>> Thank you
>>
>> *Stefan Santesson
>> *AAA-sec.com
>>
>>
>
>
>
>



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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRKzCC
BCEwggOKoAMCAQICBAQAA9QwDQYJKoZIhvcNAQEFBQAwdTELMAkGA1UEBhMCVVMxGDAWBgNV
BAoTD0dURSBDb3Jwb3JhdGlvbjEnMCUGA1UECxMeR1RFIEN5YmVyVHJ1c3QgU29sdXRpb25z
LCBJbmMuMSMwIQYDVQQDExpHVEUgQ3liZXJUcnVzdCBHbG9iYWwgUm9vdDAeFw0wNTA1MDUx
NDA3MDBaFw0xMjA1MDUyMzU5MDBaMD4xCzAJBgNVBAYTAnB0MRUwEwYDVQQKEwxNVUxUSUNF
UlQtQ0ExGDAWBgNVBAMTD01VTFRJQ0VSVC1DQSAwMjCCASIwDQYJKoZIhvcNAQEBBQADggEP
ADCCAQoCggEBAN0N2tOSOeBzmTNW52Z0lF8dai+9/j7REYIiJfjG2GrD/lC/pd8kBHaZZtYQ
Yo6QuoD8Rz1y6Mz9+bZEgm9r+E7HWOoBPIeuVF2Q3Tol/4gcnBvNeubCwMtjQJYnz2zHiho8
iPRXmtDLfWkXzVzPtUgsjooZh1w1ePr95tdiF4+fjv5eUcYn/27Oxj0Gy+FwCU9nAKZ2nO8g
/92NgJZOP1uQgap4+GBlAK3xKyGkj0WohkhAGYhEuvfol8aeS7Hgq9EmeCqvpVIIJc+jORHs
HAzG+69xAiTN+KZf3LsJc47QDQibzU4kcifaLfBk/+vuZf9GX/QYAcifB3cvKBqP4jcCAwEA
AaOCAW8wggFrMEUGA1UdHwQ+MDwwOqA4oDaGNGh0dHA6Ly93d3cucHVibGljLXRydXN0LmNv
bS9jZ2ktYmluL0NSTC8yMDE4L2NkcC5jcmwwHQYDVR0OBBYEFB3DuYilGL5gpyymY8pmKvwM
J8G9MFMGA1UdIARMMEowSAYJKwYBBAGxPgEAMDswOQYIKwYBBQUHAgEWLWh0dHA6Ly93d3cu
cHVibGljLXRydXN0LmNvbS9DUFMvT21uaVJvb3QuaHRtbDCBiQYDVR0jBIGBMH+heaR3MHUx
CzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9HVEUgQ29ycG9yYXRpb24xJzAlBgNVBAsTHkdURSBD
eWJlclRydXN0IFNvbHV0aW9ucywgSW5jLjEjMCEGA1UEAxMaR1RFIEN5YmVyVHJ1c3QgR2xv
YmFsIFJvb3SCAgGlMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEBMA0GCSqG
SIb3DQEBBQUAA4GBABe6tGhEuFeobKVmaJmt7Qq84Na2i6IazEX4vp720nXMT+VS3UsP5btB
Y3uvIETXOZKaG9/bRVEtJH6smOyFVvqdRRGKS0DYnMesAIIvckozZBSen2/+X/qP0W7WCWXo
mlJUIMwLN2J3Br6XTCof68TEVpdw+Y0qvxZUKw2Qd/SGMIIGfzCCBWegAwIBAgIEQmnyPDAN
BgkqhkiG9w0BAQUFADA+MQswCQYDVQQGEwJwdDEVMBMGA1UEChMMTVVMVElDRVJULUNBMRgw
FgYDVQQDEw9NVUxUSUNFUlQtQ0EgMDIwHhcNMDgwNDE3MTYyNTE0WhcNMDkwODAyMTYzNzIx
WjCCAQoxCzAJBgNVBAYTAlBUMRUwEwYDVQQKEwxNVUxUSUNFUlQtQ0ExFjAUBgNVBAsTDUNF
UlRJUE9SIC0gUkExEjAQBgNVBAsTCUNvcnBvcmF0ZTE+MDwGA1UECxM1TVVMVElDRVJUIC0g
U2Vydmljb3MgZGUgQ2VydGlmaWNhY2FvIEVsZWN0cm9uaWNhIFMuQS4xMTAvBgNVBAsTKElu
dGVncmFjYW8gRGVzZW52b2x2aW1lbnRvIGUgQ29uc3VsdG9yaWExFDASBgNVBAsTC1BlcnNv
bmFsIElEMS8wLQYDVQQDEyZOdW5vIE1pZ3VlbCBBcmllaXJvIFJvZHJpZ3VlcyBkYSBQb250
ZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMlVuImUD9fjTFbxpk8GZx2dcPhf
nV45izmuh2jjUD6leaFBMP//YIRkGsO5ee9+c3WF+5YM6Rw863LsWfQFfoUru03buXiBhDey
+lNkQyuEEcU+wgDTy1HDuSr+F6nlJTGRdDK32AnnWoqc/SzxkfRlqChPGPHcLjLOLGR/54pm
tUXrtcQqJ4hC2fmArO7s1Aax8RllVBnFo1RFywK77xtCbVKrM3F/Bu7Bcls4kn2VoG4EoRnG
pXmHdOnCsPLnEIpz+/uzbOQANhCQUILpkvHg53NdoHITbhvyq9L/yGqCx9x/Idx8B3fFKWsq
IX3qtOMbvlnuJQiecBuLnMB+lzUCAwEAAaOCArUwggKxMAsGA1UdDwQEAwID+DA4BggrBgEF
BQcBAQQsMCowKAYIKwYBBQUHMAGBHGh0dHA6Ly9vY3NwLm11bHRpY2VydC5jb20vY2EwgeAG
A1UdIASB2DCB1TBNBgkrBgEEAbA8CgIwQDA+BggrBgEFBQcCARYyaHR0cDovL3d3dy5tdWx0
aWNlcnQuY29tL2Nwcy9tdWx0aWNlcnQtY2EtY3BzLmh0bWwwgYMGCysGAQQBsDwKAodtMHQw
cgYIKwYBBQUHAgIwZh5kAGgAdAB0AHAAOgAvAC8AdwB3AHcALgBtAHUAbAB0AGkAYwBlAHIA
dAAuAGMAbwBtAC8AYwBwAC8AbQB1AGwAdABpAGMAZQByAHQALQBjAGEALQAxADAAMAA1AC4A
aAB0AG0AbDARBglghkgBhvhCAQEEBAMCBaAwIwYDVR0RBBwwGoEYbnVuby5wb250ZUBtdWx0
aWNlcnQuY29tMIIBAAYDVR0fBIH4MIH1MIGaoIGXoIGUhi9odHRwOi8vd3d3Lm11bHRpY2Vy
dC5jb20vY2EvbXVsdGljZXJ0LWNhLTAyLmNybIZhbGRhcDovL2xkYXAubXVsdGljZXJ0LmNv
bS9jbj1NVUxUSUNFUlQtQ0ElMjAwMixvPU1VTFRJQ0VSVC1DQSxjPVBUP2NlcnRpZmljYXRl
UmV2b2NhdGlvbkxpc3Q/YmFzZTBWoFSgUqRQME4xCzAJBgNVBAYTAnB0MRUwEwYDVQQKEwxN
VUxUSUNFUlQtQ0ExGDAWBgNVBAMTD01VTFRJQ0VSVC1DQSAwMjEOMAwGA1UEAxMFQ1JMNzEw
HwYDVR0jBBgwFoAUHcO5iKUYvmCnLKZjymYq/Awnwb0wHQYDVR0OBBYEFKCTcs+ugAbPdt2O
kYHBlGKcaNKuMAkGA1UdEwQCMAAwDQYJKoZIhvcNAQEFBQADggEBADDVblqFDMEgouIWUbT5
MHZKChTSV03e0nNw7GySueMYoIv2MAG20TbaKbXLQm8At90l4AO7xTwoi5KYHXqKq4KcFcQt
y0La78REDHLLf+ks1UIhpStjjHx8gi84h+f0hj5bg4QSjLhZf03G0GP4s3lwkWDTan72Ktnq
54SJOs7Uyvv4gSlQLJx6mE0/qlRTYe77ATPNqeSww89gs4TEH69iBkFovFs5hl512Bm3rM4Z
H0ac6gfamoWMfdBy8kCzhao9kuHz30wfnE0Q86e6+bJRZwz579h7qfEqEmEjwnLPqP7XC1KQ
P7TGB2ZrWo0AfFNJm15fqSAg3ifGNjsOV/MwggZ/MIIFZ6ADAgECAgRCafI8MA0GCSqGSIb3
DQEBBQUAMD4xCzAJBgNVBAYTAnB0MRUwEwYDVQQKEwxNVUxUSUNFUlQtQ0ExGDAWBgNVBAMT
D01VTFRJQ0VSVC1DQSAwMjAeFw0wODA0MTcxNjI1MTRaFw0wOTA4MDIxNjM3MjFaMIIBCjEL
MAkGA1UEBhMCUFQxFTATBgNVBAoTDE1VTFRJQ0VSVC1DQTEWMBQGA1UECxMNQ0VSVElQT1Ig
LSBSQTESMBAGA1UECxMJQ29ycG9yYXRlMT4wPAYDVQQLEzVNVUxUSUNFUlQgLSBTZXJ2aWNv
cyBkZSBDZXJ0aWZpY2FjYW8gRWxlY3Ryb25pY2EgUy5BLjExMC8GA1UECxMoSW50ZWdyYWNh
byBEZXNlbnZvbHZpbWVudG8gZSBDb25zdWx0b3JpYTEUMBIGA1UECxMLUGVyc29uYWwgSUQx
LzAtBgNVBAMTJk51bm8gTWlndWVsIEFyaWVpcm8gUm9kcmlndWVzIGRhIFBvbnRlMIIBIjAN
BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyVW4iZQP1+NMVvGmTwZnHZ1w+F+dXjmLOa6H
aONQPqV5oUEw//9ghGQaw7l5735zdYX7lgzpHDzrcuxZ9AV+hSu7Tdu5eIGEN7L6U2RDK4QR
xT7CANPLUcO5Kv4XqeUlMZF0MrfYCedaipz9LPGR9GWoKE8Y8dwuMs4sZH/nima1Reu1xCon
iELZ+YCs7uzUBrHxGWVUGcWjVEXLArvvG0JtUqszcX8G7sFyWziSfZWgbgShGcaleYd06cKw
8ucQinP7+7Ns5AA2EJBQgumS8eDnc12gchNuG/Kr0v/IaoLH3H8h3HwHd8Upayohfeq04xu+
We4lCJ5wG4ucwH6XNQIDAQABo4ICtTCCArEwCwYDVR0PBAQDAgP4MDgGCCsGAQUFBwEBBCww
KjAoBggrBgEFBQcwAYEcaHR0cDovL29jc3AubXVsdGljZXJ0LmNvbS9jYTCB4AYDVR0gBIHY
MIHVME0GCSsGAQQBsDwKAjBAMD4GCCsGAQUFBwIBFjJodHRwOi8vd3d3Lm11bHRpY2VydC5j
b20vY3BzL211bHRpY2VydC1jYS1jcHMuaHRtbDCBgwYLKwYBBAGwPAoCh20wdDByBggrBgEF
BQcCAjBmHmQAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAG0AdQBsAHQAaQBjAGUAcgB0AC4AYwBv
AG0ALwBjAHAALwBtAHUAbAB0AGkAYwBlAHIAdAAtAGMAYQAtADEAMAAwADUALgBoAHQAbQBs
MBEGCWCGSAGG+EIBAQQEAwIFoDAjBgNVHREEHDAagRhudW5vLnBvbnRlQG11bHRpY2VydC5j
b20wggEABgNVHR8EgfgwgfUwgZqggZeggZSGL2h0dHA6Ly93d3cubXVsdGljZXJ0LmNvbS9j
YS9tdWx0aWNlcnQtY2EtMDIuY3JshmFsZGFwOi8vbGRhcC5tdWx0aWNlcnQuY29tL2NuPU1V
TFRJQ0VSVC1DQSUyMDAyLG89TVVMVElDRVJULUNBLGM9UFQ/Y2VydGlmaWNhdGVSZXZvY2F0
aW9uTGlzdD9iYXNlMFagVKBSpFAwTjELMAkGA1UEBhMCcHQxFTATBgNVBAoTDE1VTFRJQ0VS
VC1DQTEYMBYGA1UEAxMPTVVMVElDRVJULUNBIDAyMQ4wDAYDVQQDEwVDUkw3MTAfBgNVHSME
GDAWgBQdw7mIpRi+YKcspmPKZir8DCfBvTAdBgNVHQ4EFgQUoJNyz66ABs923Y6RgcGUYpxo
0q4wCQYDVR0TBAIwADANBgkqhkiG9w0BAQUFAAOCAQEAMNVuWoUMwSCi4hZRtPkwdkoKFNJX
Td7Sc3DsbJK54xigi/YwAbbRNtoptctCbwC33SXgA7vFPCiLkpgdeoqrgpwVxC3LQtrvxEQM
cst/6SzVQiGlK2OMfHyCLziH5/SGPluDhBKMuFl/TcbQY/izeXCRYNNqfvYq2ernhIk6ztTK
+/iBKVAsnHqYTT+qVFNh7vsBM82p5LDDz2CzhMQfr2IGQWi8WzmGXnXYGbeszhkfRpzqB9qa
hYx90HLyQLOFqj2S4fPfTB+cTRDzp7r5slFnDPnv2Hup8SoSYSPCcs+o/tcLUpA/tMYHZmta
jQB8U0mbXl+pICDeJ8Y2Ow5X8zGCAt8wggLbAgEBMEYwPjELMAkGA1UEBhMCcHQxFTATBgNV
BAoTDE1VTFRJQ0VSVC1DQTEYMBYGA1UEAxMPTVVMVElDRVJULUNBIDAyAgRCafI8MAkGBSsO
AwIaBQCgggFuMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA5
MDMyMzE2MTIwNVowIwYJKoZIhvcNAQkEMRYEFLgSir23E+xSG+rw2KW5wjrrorBkMFUGCSsG
AQQBgjcQBDFIMEYwPjELMAkGA1UEBhMCcHQxFTATBgNVBAoTDE1VTFRJQ0VSVC1DQTEYMBYG
A1UEAxMPTVVMVElDRVJULUNBIDAyAgRCafI8MFcGCyqGSIb3DQEJEAILMUigRjA+MQswCQYD
VQQGEwJwdDEVMBMGA1UEChMMTVVMVElDRVJULUNBMRgwFgYDVQQDEw9NVUxUSUNFUlQtQ0Eg
MDICBEJp8jwwXwYJKoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYI
KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMA0G
CSqGSIb3DQEBAQUABIIBAE3bGmfcmEtK5WVa+vLYd2VMB0txEzAcDvXtcD5XLuNFgodh2U6c
BctJIy50myAawaVbbLtqKB3iRpcdl5+4TMWo+INRQKruzwxbLuzK1Q1SwF6zcWURsvRWsOaT
deOUGxcnAQBfy51hcgg4zK8xmX1c05SpMlv9ANdi9MPfOaYGUof0MFnHq+L4FqaGrl6LFjeo
1jcZ59yRgUepLjQelV+xEJdCi18NAlWK8yjRqStNlg/iCJJmtnbzdFlRClOD89TWtJfNvhFQ
dm3DfKx3v+iEtvPC1v/xps+lU+J0ubFtnHBsss3gyVonFtk9+NOP398ONYJeXnOP4ktqZ26w
lBQAAAAAAAA=
--------------ms020209070405050702090006--



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 n2NEc6Dw020983 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Mar 2009 07:38:06 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2NEc6gu020982; Mon, 23 Mar 2009 07:38:06 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.primekey.se (walter.primekey.se [195.149.137.135]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2NEbrqp020968 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 23 Mar 2009 07:38:05 -0700 (MST) (envelope-from [e-mail])
Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.primekey.se (Postfix) with ESMTP id 3FDB0C3E12; Mon, 23 Mar 2009 15:37:52 +0100 (CET)
Message-ID: <[e-mail]>
Date: Mon, 23 Mar 2009 15:37:51 +0100
From: Anders Rundgren <[e-mail]>
User-Agent: Thunderbird 2.0.0.19 (X11/20090105)
MIME-Version: 1.0
To: Stefan Santesson <[e-mail]>
CC: "'IETF-pkix'" <[e-mail]>
Subject: PKIX bar discussion: <keygen>. Re: Agenda update and slides reminder
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I'm sorry about not being able to visit the IETF.

In case there will be any interesting evening discussions may I add
something that you could talk about?

As some of you may know the <keygen> tag was dismissed from
the HTML5 WG spec. because it was found to be inferior.
<keygen> is currently used by Apple, Mozilla, Nokia and Google browsers.

The idea of putting a key-generation mechanism in a page-description
language was more like a patch by Netscape more than a decade ago.

Microsoft's counterpart to <keygen>, CertEnroll has AFAIK not been
proposed as the foundation for a standard.

I think it is about time to create something more thought-through that
also supports smart cards and similar crypto containers:
http://webpki.org/papers/keygen2/keygen2-fips140-2.pdf

It is worth noting that the scheme above does not work with PKCS #11,
JCE, or CryptoAPI for key provisioning (since they do not support
key attestations), but for key usage.

Although not exploited in the current spec., key attestations can also
be extended to bind declared PIN policies to generated keys.   This
potentially enables a technical security for out-in-the-field on-line
key provisioning that is in par with in-house production.  The use-case
for this includes:
- Consumer PKIs
- Spare cards for employees that are far from their homebase
- Mobile devices with build-in crypto HW

The realization of this project is not going particularly quick (it is
not my day-job), but it is not standing completely still either.

Anders

Stefan Santesson wrote:
> I have posted a hopefully final agenda to the PKIX meeting available at:
> http://www.ietf.org/proceedings/09mar/agenda/pkix.txt
>
> Meeting materials received so far are available at:
> https://datatracker.ietf.org/meeting/74/materials.html
>
> I need all presentations sent to me before 17.00 San Francisco time on 
> Sunday so I can have them all posted before the meeting starts at 0900 
> Monday morning.
>
> Thank you
>
> *Stefan Santesson
> *AAA-sec.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 n2KGikTI016481 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Mar 2009 09:44:46 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2KGikW1016480; Fri, 20 Mar 2009 09:44:46 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from QMTA13.emeryville.ca.mail.comcast.net (qmta13.emeryville.ca.mail.comcast.net [76.96.27.243]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2KGij7r016465 for <[e-mail]>; Fri, 20 Mar 2009 09:44:45 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Received: from OMTA05.emeryville.ca.mail.comcast.net ([76.96.30.43]) by QMTA13.emeryville.ca.mail.comcast.net with comcast id VR751b00A0vp7WLADUkmcs; Fri, 20 Mar 2009 16:44:46 +0000
Received: from MIKES-LAPTOM.comcast.net ([216.129.123.44]) by OMTA05.emeryville.ca.mail.comcast.net with comcast id VUkT1b0060xb3EY8RUkVzm; Fri, 20 Mar 2009 16:44:44 +0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Fri, 20 Mar 2009 12:44:24 -0400
To: Tom Gindin <[e-mail]>, "Miller, Timothy J." <[e-mail]>
From: Michael StJohns <[e-mail]>
Subject: RE: RFC4134 email mismatch in examples 4.8 and 4.9
Cc: "'Jim Schaad'" <[e-mail]>, <[e-mail]>, "'Maxim Masiutin'" <[e-mail]>, <[e-mail]>
In-Reply-To: <OFE8BB6164.DAAF4BC1-ON8525757C.00528F76-8525757D.000409D4@ us.ibm.com>
References: <[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>

Umm...

even with case insensitivity, these two email addresses don't match...

example.com vs
examples.com

I didn't parse the BASE64 in the 4.8 example (which has an email from [e-mail]) but the asn1 dump in 4.10 has the data signed by [e-mail]

Mike


At 08:44 PM 3/17/2009, Tom Gindin wrote:

>        RFC 1274 section 9.3.3 is also on Jim's side, since the syntax of 
>the rfc822Mailbox attribute is caseIgnoreIA5StringSyntax.  It's still 
>probably better to fix the example so that it doesn't raise this vexed 
>question.
>
>                Tom Gindin
>
>
>
>
>"Miller, Timothy J." <[e-mail]> 
>Sent by: [e-mail]
>03/16/2009 11:32 AM
>
>To
>"'Jim Schaad'" <[e-mail]>, "'Maxim Masiutin'" 
><[e-mail]>, "[e-mail]" <[e-mail]>
>cc
>"[e-mail]" <[e-mail]>
>Subject
>RE: RFC4134 email mismatch in examples 4.8 and 4.9
>
>
>
>
>
>
>Not correct.  Mail address local parts are *case sensitive*.
>
>RFC5322 Section 3.4.1:
>
>"""
>The local-part portion is a domain-dependent string.
>"""
>
>RFC5321:
>
>"""
>2.4.  General Syntax Principles and Transaction Model
>
>   [...]
> 
>The
>   local-part of a mailbox MUST BE treated as case sensitive.
>   Therefore, SMTP implementations MUST take care to preserve the case
>   of mailbox local-parts.  In particular, for some hosts, the user
>   "smith" is different from the user "Smith".  However, exploiting the
>   case sensitivity of mailbox local-parts impedes interoperability and
>   is discouraged.  Mailbox domains follow normal DNS rules and are
>   hence not case sensitive.
>"""
>
>Discouraged != (MUST NOT || SHOULD NOT)
>
>We went through this argument (at my instigation) last year on the S/MIME
>list:
>
>http://osdir.com/ml/ietf.smime/2007-09/msg00004.html
>
>-- Tim
>
>>-----Original Message-----
>>From: [e-mail] [mailto:[e-mail]]
>>On Behalf Of Jim Schaad
>>Sent: Saturday, March 14, 2009 4:53 PM
>>To: 'Maxim Masiutin'; [e-mail]
>>Cc: [e-mail]
>>Subject: RE: RFC4134 email mismatch in examples 4.8 and 4.9
>>
>>
>>For the purposes of S/MIME all RFC822 addresses are considered to be
>>case
>>insensitive.
>>
>>Jim
>>
>>
>>> -----Original Message-----
>>> From: [e-mail] [mailto:owner-ietf-
>>> [e-mail]] On Behalf Of Maxim Masiutin
>>> Sent: Saturday, March 14, 2009 2:22 PM
>>> To: [e-mail]
>>> Cc: [e-mail]
>>> Subject: RFC4134 email mismatch in examples 4.8 and 4.9
>>>
>>> Hello,
>>>
>>> I have a question about RFC4134, Examples 4.8 and 4.9.
>>>
>>> "From" line of the RFC-822 message is [e-mail], while the
>>> certificate's SubjectAlternativeName contains Rfc822Name =
>>> [e-mail]
>>>
>>> So the two emails are different in the host part.
>>>
>>> Is it OK for them to be different?
>>>
>>>
>>> --
>>> Best regards,
>>> Maxim Masiutin
>>> Ritlabs SRL
>>> http://www.ritlabs.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 n2KFIQEC011153 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Mar 2009 08:18:26 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2KFIQUZ011152; Fri, 20 Mar 2009 08:18:26 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from s87.loopia.se (s87.loopia.se [194.9.95.112]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2KFIDfu011129 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Fri, 20 Mar 2009 08:18:25 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 9077 invoked from network); 20 Mar 2009 15:18:17 -0000
Received: from s34.loopia.se (HELO s24.loopia.se) ([194.9.94.70]) (envelope-sender <[e-mail]>) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for <[e-mail]>; 20 Mar 2009 15:18:17 -0000
Received: (qmail 97452 invoked from network); 20 Mar 2009 15:18:11 -0000
Received: from 90-229-233-249-no153.tbcn.telia.com (HELO [192.168.0.17]) ([e-mail]@[90.229.233.249]) (envelope-sender <[e-mail]>) by s24.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <[e-mail]>; 20 Mar 2009 15:18:11 -0000
User-Agent: Microsoft-Entourage/12.15.0.081119
Date: Fri, 20 Mar 2009 16:18:10 +0100
Subject: Agenda update and slides reminder
From: Stefan Santesson <[e-mail]>
To: "'IETF-pkix'" <[e-mail]>
Message-ID: <[e-mail]>
Thread-Topic: Agenda update and slides reminder
Thread-Index: AcmpbxQSrSgdOw0jCUun1hFgw5ruQw==
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3320410691_6010694"
Sender: [e-mail]
Precedence: 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 message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3320410691_6010694
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit

I have posted a hopefully final agenda to the PKIX meeting available at:
http://www.ietf.org/proceedings/09mar/agenda/pkix.txt

Meeting materials received so far are available at:
https://datatracker.ietf.org/meeting/74/materials.html

I need all presentations sent to me before 17.00 San Francisco time on
Sunday so I can have them all posted before the meeting starts at 0900
Monday morning.

Thank you

Stefan Santesson
AAA-sec.com




--B_3320410691_6010694
Content-type: text/html;
	charset="US-ASCII"
Content-transfer-encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Agenda update and slides reminder</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt=
'>I have posted a hopefully final agenda to the PKIX meeting available at:<B=
R>
<a href=3D"http://www.ietf.org/proceedings/09mar/agenda/pkix.txt">http://www.=
ietf.org/proceedings/09mar/agenda/pkix.txt</a><BR>
<BR>
Meeting materials received so far are available at:<BR>
<a href=3D"https://datatracker.ietf.org/meeting/74/materials.html">https://da=
tatracker.ietf.org/meeting/74/materials.html</a><BR>
<BR>
I need all presentations sent to me before 17.00 San Francisco time on Sund=
ay so I can have them all posted before the meeting starts at 0900 Monday mo=
rning.<BR>
<BR>
Thank you<BR>
</SPAN></FONT><FONT COLOR=3D"#333333"><FONT SIZE=3D"2"><FONT FACE=3D"Tahoma, Verd=
ana, Helvetica, Arial"><SPAN STYLE=3D'font-size:10pt'><BR>
</SPAN></FONT></FONT></FONT><FONT SIZE=3D"2"><SPAN STYLE=3D'font-size:10pt'><FO=
NT COLOR=3D"#008080"><FONT FACE=3D"Cambria"><B>Stefan Santesson<BR>
</B></FONT></FONT><FONT FACE=3D"Cambria">AAA-sec.com<BR>
<BR>
</FONT></SPAN></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN =
STYLE=3D'font-size:11pt'><BR>
</SPAN></FONT>
</BODY>
</HTML>


--B_3320410691_6010694--




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 n2JLFT1H055430 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Mar 2009 14:15:29 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2JLFTMV055428; Thu, 19 Mar 2009 14:15:29 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2JLFRvD055420 for <[e-mail]>; Thu, 19 Mar 2009 14:15:27 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 902169A47AF; Thu, 19 Mar 2009 17:15:27 -0400 (EDT)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id lyb6jSwuJl-z; Thu, 19 Mar 2009 17:15:25 -0400 (EDT)
Received: from THINKPADR52.vigilsec.com (pool-96-255-144-212.washdc.fios.verizon.net [96.255.144.212]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id A799F9A4783; Thu, 19 Mar 2009 17:15:26 -0400 (EDT)
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Thu, 19 Mar 2009 16:52:09 -0400
To: Peter Sylvester <[e-mail]>, [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: draft-ietf-pkix-rfc3161bis-01.txt
Cc: ietf-pkix <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
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>

Peter:

>The disaster of contentCommitment vs nonRepudiation MUST
>not be repeated.

I agree!  The PKIX specification continue to use the older name 
(nonRepudiation instead on contentCommitment) , and I strongly 
believe that is the right thing to do as Peter argues.  Gratuitous 
name changes really need to be avoided.

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 n2JDHpOG025043 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Mar 2009 06:17:51 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2JDHp3Z025042; Thu, 19 Mar 2009 06:17:51 -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 n2JDHYFk025023 for <[e-mail]>; Thu, 19 Mar 2009 06:17:49 -0700 (MST) (envelope-from [e-mail])
Received: from varuna.puteaux.on-x (varuna.puteaux.on-x [192.168.10.6]) by ganymede.on-x.com (Postfix) with ESMTP id B5F2B77; Thu, 19 Mar 2009 14:17:11 +0100 (CET)
Received: from smtps.on-x.com (mintaka.puteaux.on-x [192.168.14.11]) by varuna.puteaux.on-x (Postfix) with ESMTP id BA86C16FD3; Thu, 19 Mar 2009 14:17:10 +0100 (CET)
Received: from [192.168.0.13] (gut75-3-82-227-163-182.fbx.proxad.net [82.227.163.182]) by smtps.on-x.com (Postfix) with ESMTP id 9730077DC; Thu, 19 Mar 2009 14:17:08 +0100 (CET)
Message-ID: <[e-mail]>
Date: Thu, 19 Mar 2009 14:16:54 +0100
From: Peter Sylvester <[e-mail]>
User-Agent: Thunderbird 2.0.0.19 (X11/20090105)
MIME-Version: 1.0
To: [e-mail]
Cc: ietf-pkix <[e-mail]>
Subject: Re: draft-ietf-pkix-rfc3161bis-01.txt
References: <[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>

>
>
>     In 3161, a TSA is merely a technical service similar to what is
>     said in 3161bis for a TSU. A TSA in 3161bis does not really
>     have a defined technical role.
>      
>     [Denis]  The key point is that the certificate belongs to one TSU,
>     not to one TSA.
>
No. in RFC3161 a certficate belongs to a TSA. This is a technical entity
that has the authority to create time stamps.

all organisational aspects are not part of 3161.
>
>      
>     A TSU certificate may be revoked. A TSA has no certificate and
>     thus is not revoked if one of its TSUs is compromised.
>     A TSA is the administrative entity responsible for managing one or
>     more TSUs.
>
not in RFC 3161. Besides that to me the words

  "administrative entity responsible for managing"

are ambiguous.

>
>     On the other hand the field tsa in a response refers to a TSA,
>     and to a certficate that validates it. But a TSA does no longer
>     have a certificate, only TSUs.
>     [Denis]  In the proposal, I kept the same names for the fields.
>     Maybe this is not the best choice, and "tsa" should be changed
>     into "tsu" to reflect better the difference.
>
Some people use ASN.1 compilers that generate variable names
based on asn.1 types. Changing a name is  a problem even
if the bits on the wire are the same.  Furthermore, user interfaces
may also more or less directly use the names. Think
also about a XER representation which would be used as
an intermediate format.

The disaster of contentCommitment vs nonRepudiation MUST
not be repeated.


>
>     As a consequence, the following paragraph cannot mention TSA
>     but at best a TSU.
>     Besides that it should also mentiion ESSCertIDv2.)
>
>         The purpose of the tsa field is to give a hint in identifying the
>         name of the TSA. If present, it MUST correspond to one of the
>         subject names included in the certificate that is to be used to
>         verify the token. However, the actual identification of the entity
>         that signed the response will always occur through the use of the
>         certificate identifier (ESSCertID Attribute) inside a
>         SigningCertificate attribute which is part of the signerInfo
>         (See Section 5 of [ESS]).
>
>
>     Chapter 3.3 does not use the 2119 terminology in the first phrase but
>     rather the ISO terminoilogy.
>      
>     [Denis]  Do you mean "shall" should be changed into" SHALL" ?
>
As far as I remember a 'shall' in
iso terms is the same as MUST. 

But I do not know what you intend? Do you want to
prohibit organisationalUnit for example, or not?
>
>      
>     3.3 is not relevant for the function of
>     a time stamp service. (Although it is likely that TSA actually
>     have filled all the REQUIRED 'shall) attributes in the DN)
>
>     The following text is extremely fuzzy:
>
>         The name of the issuing TSU shall contain an appropriate subset of
>         the following attributes (defined in ISO 9594-6 [ISO9594-6] and
>         ITU-T Recommendation X.520 [X.520]):
>
>             - countryName;
>             - stateOrProvinceName;
>             - organizationName;
>             - commonName.
>
>     What means "appropriate subset". The text does not exclude
>     other attributs. So in fact, it says: The TSU MUST have a subjectDN?
>     It is not defined what name identifies a TSA? for example,
>     everything except
>     the common name?
>      
>     [Denis]  The text is very explicit: "organizationName shall be
>     present". Other fields are optional.
>

Right, organisation 'shall' == MUST be present. So, if nothing else, then
you would only have one TSU of this TSA?

  "It is not defined what name identifies a TSA".


>
>     4.3 :
>
>     As it had been mentioned before the socket protocol as it is defined
>     has some problems: Since it was taken texto from CMP, there are
>     some features
>     that are may require some complexity in clients:
>     Only 00, 05, and 06 seem useful to me. If a TSA/U is not able to sign
>     a response within a few milliseconds with a TCP connection kept open,
>     I wouldn't call this a service.
>      
>     [Denis]  I care for backwards compatibility first.
>     If some cases may not exist, then we can suppress them.
>     If they may exist, then we should keep them.
>
You should think at conformance. If a client implementation
claims conformance and support of the socket protocol, does it
need to implement all these polling features?

>
>     For HTTP, a server cannot return a poll indication as a comparison.
>
>     If a client does not send a pollReq, what will happen with a pending
>     response?
>
>     The protocol does not specify who terminates the connection. Is it the
>     server that closes after one exchange?
>
>     If multiple requests and responses can be exchanged over the same
>     connection,
>     what is the dialogue model? request/response, pipelining, etc?
>
>     [Denis]  If you have a proposal , please post it to the list.*
>
I care for backward compatibility. I don't know what implementations
do. A proposal existed, you may want to recover the text from
an update to cmp.

-connection usage: Typically, a client establises a connection.
Since it is not specified who terminates it, the following
cases can occur:

- a client assumes that the connection is closed by the server.
- a client closes a connection after having received a response.
- a client may maintain a connection in order to send other
  requests.

When a client uses the third variant, it should be prepared
for the connection being closed by the server.


>
>     What is a TSU message? I think it should be TSP message. Old text was
>     TSA, which was also somewhat wrong.
>     [Denis]  A TSU Message is simply a message from a TSU.
>
I wonder whether you got the point.
>
>
>     Security section point 1 seems not quite correct:
>
>     Instead of :
>     it SHALL be set either to unspecified (0), affiliationChanged (3),
>            superseded (4) or cessationOfOperation (5). In that case,
>
>     it should say
>
>     In the case when the reasonCode is set to either
>            affiliationChanged (3),
>            superseded (4) or cessationOfOperation (5)
>
>     Unspecified means that ther can be a key compromise IMO?
>     [Denis]. Good catch. Let us delete "unspecified (0)"
>      
>
The question was: "do we need all that?"

I don't think thar



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 n2I0iLWx091002 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Mar 2009 17:44:21 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2I0iLEo091001; Tue, 17 Mar 2009 17:44:21 -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 n2I0i8hw090991 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 17 Mar 2009 17:44:19 -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 n2I0a9a4024734; Tue, 17 Mar 2009 20:36:09 -0400
Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n2I0i7ZB196374; Tue, 17 Mar 2009 20:44:07 -0400
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 n2I0i6jl022788; Tue, 17 Mar 2009 20:44:06 -0400
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 n2I0i6SY022783; Tue, 17 Mar 2009 20:44:06 -0400
In-Reply-To: <[e-mail]>
To: "Miller, Timothy J." <[e-mail]>
Cc: "'Jim Schaad'" <[e-mail]>, <[e-mail]>, "'Maxim Masiutin'" <[e-mail]>, <[e-mail]>
MIME-Version: 1.0
Subject: RE: RFC4134 email mismatch in examples 4.8 and 4.9
X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006
From: Tom Gindin <[e-mail]>
Message-ID: <[e-mail]>
Date: Tue, 17 Mar 2009 20:44:05 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 8.0.1 HF8|December 19, 2008) at 03/17/2009 20:44:06, Serialize complete at 03/17/2009 20:44:06
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>

        RFC 1274 section 9.3.3 is also on Jim's side, since the syntax of 
the rfc822Mailbox attribute is caseIgnoreIA5StringSyntax.  It's still 
probably better to fix the example so that it doesn't raise this vexed 
question.

                Tom Gindin




"Miller, Timothy J." <[e-mail]> 
Sent by: [e-mail]
03/16/2009 11:32 AM

To
"'Jim Schaad'" <[e-mail]>, "'Maxim Masiutin'" 
<[e-mail]>, "[e-mail]" <[e-mail]>
cc
"[e-mail]" <[e-mail]>
Subject
RE: RFC4134 email mismatch in examples 4.8 and 4.9






Not correct.  Mail address local parts are *case sensitive*.

RFC5322 Section 3.4.1:

"""
The local-part portion is a domain-dependent string.
"""

RFC5321:

"""
2.4.  General Syntax Principles and Transaction Model

   [...]
 
The
   local-part of a mailbox MUST BE treated as case sensitive.
   Therefore, SMTP implementations MUST take care to preserve the case
   of mailbox local-parts.  In particular, for some hosts, the user
   "smith" is different from the user "Smith".  However, exploiting the
   case sensitivity of mailbox local-parts impedes interoperability and
   is discouraged.  Mailbox domains follow normal DNS rules and are
   hence not case sensitive.
"""

Discouraged != (MUST NOT || SHOULD NOT)

We went through this argument (at my instigation) last year on the S/MIME
list:

http://osdir.com/ml/ietf.smime/2007-09/msg00004.html

-- Tim

>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]]
>On Behalf Of Jim Schaad
>Sent: Saturday, March 14, 2009 4:53 PM
>To: 'Maxim Masiutin'; [e-mail]
>Cc: [e-mail]
>Subject: RE: RFC4134 email mismatch in examples 4.8 and 4.9
>
>
>For the purposes of S/MIME all RFC822 addresses are considered to be
>case
>insensitive.
>
>Jim
>
>
>> -----Original Message-----
>> From: [e-mail] [mailto:owner-ietf-
>> [e-mail]] On Behalf Of Maxim Masiutin
>> Sent: Saturday, March 14, 2009 2:22 PM
>> To: [e-mail]
>> Cc: [e-mail]
>> Subject: RFC4134 email mismatch in examples 4.8 and 4.9
>>
>> Hello,
>>
>> I have a question about RFC4134, Examples 4.8 and 4.9.
>>
>> "From" line of the RFC-822 message is [e-mail], while the
>> certificate's SubjectAlternativeName contains Rfc822Name =
>> [e-mail]
>>
>> So the two emails are different in the host part.
>>
>> Is it OK for them to be different?
>>
>>
>> --
>> Best regards,
>> Maxim Masiutin
>> Ritlabs SRL
>> http://www.ritlabs.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 n2HH6aBj062556 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Mar 2009 10:06:36 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2HH6aff062555; Tue, 17 Mar 2009 10:06:36 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from s87.loopia.se (s87.loopia.se [194.9.95.112]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2HH6Xet062543 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 17 Mar 2009 10:06:34 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 41110 invoked from network); 17 Mar 2009 17:06:38 -0000
Received: from s34.loopia.se (HELO s128.loopia.se) ([194.9.94.70]) (envelope-sender <[e-mail]>) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for <[e-mail]>; 17 Mar 2009 17:06:38 -0000
Received: (qmail 57939 invoked from network); 17 Mar 2009 17:06:23 -0000
Received: from gw-guest.ac.upc.edu (HELO [192.168.50.195]) ([e-mail]@[147.83.30.131]) (envelope-sender <[e-mail]>) by s128.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <[e-mail]>; 17 Mar 2009 17:06:23 -0000
User-Agent: Microsoft-Entourage/12.15.0.081119
Date: Tue, 17 Mar 2009 18:06:13 +0100
Subject: Re: Do we need rfc 3161bis?
From: Stefan Santesson <[e-mail]>
To: <[e-mail]>
CC: Jim Schaad <[e-mail]>, "'Santosh Chokhani'" <[e-mail]>, "'IETF-pkix'" <[e-mail]>
Message-ID: <[e-mail]>
Thread-Topic: Do we need rfc 3161bis?
Thread-Index: AcmnIq0A0j3IJtlvz0WcHSMbpc3q7Q==
In-Reply-To: <[e-mail]>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3320157984_11999033"
Sender: [e-mail]
Precedence: 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 message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3320157984_11999033
Content-type: text/plain;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

Denis,

On your first remark    :D

On your second remark:
Good, even that level of agreement is a great step forward. I think 1 and 2
was more an agreement between me and Julien. But since the conclusion is to
allow essCertIDv2, point 1 and 2 is of less importance.

/Stefan

On 3/17/09 4:02 PM, "[e-mail]" <[e-mail]> wrote:

> Stefan wrote his e-mail during a meeting where the priority is to listen =
to
> the meeting rather than sending e-mails
>=20
> =20
> I disagree with points 1 and 2. Point 6 is one way to move forwards, but =
is
> not the single way.
> =20
> Denis
> =20
> [e-mail] wrote: -----
>=20
> To: Stefan Santesson <[e-mail]>, Jim Schaad
> <[e-mail]>, "'Santosh Chokhani'" <[e-mail]>,
> "'IETF-pkix'" <[e-mail]>
> From: Stefan Santesson <[e-mail]>
> Sent by: [e-mail]
> Date: 03/17/2009 03:29PM
> Subject: Re: Do we need rfc 3161bis?
>=20
> I had an informal face2face meeting here in Barcelona between me, Julien =
Stern
> and Denis Pinkas.
>=20
> I will dare myself to write down some conclusion and trust Julien and Den=
is to
> correct me if they disagree.
>=20
> 1. There is no known threat for which the essCertIDv2 is needed.
> 2. It is extremely hard to prove that there will not be any threat or att=
ack
> made up in the future where essCertIDv2 would be useful
> 3. As essCertIDv2 is standardized and has been a focus for EU work in rel=
ation
> to time stamps, it is probably reasonable to allow essCertIDv2 to be used=
 with
> RFC 3161 time stamps.
> 4. For the sake of specifying the time stamp protocol, we only need one n=
amed
> entity representing the signer of the time stamp token (currently TSA in =
RFC
> 3161).=20
> 5. There is currently a disconnect between terminology in RFC 3161 and RF=
C
> 3628 (the policy document)
> 6. A solution that would satisfy all parties of this meeting would be to =
write
> an update RFC (not a replacement as current proposal). This update RFC wo=
uld
> add the option to use essCertIDv2 AND would include an informational Anne=
x
> explaining the basic difference in terminology between RFC 3161 and RFC 3=
628.
> Most importantly this informational text would explain that TSU in the po=
licy
> document corresponds to TSA in the protocol.
>=20
> I support these conclusions.
>=20
> /Stefan
>=20
>=20
>=20
> On 3/17/09 7:55 AM, "Stefan Santesson" <[e-mail]> wrote:
>=20
>> Exactly as Jim says. Maybe we should add further that this is a bout
>> substituting one valid TSA certificate with another valid TSA certificat=
e
>> since the TSA for some reason has two TSA certificates for the same publ=
ic
>> key which when hashed, have the same SHA-1 hash.
>>=20
>> /Stefan
>>=20
>>=20
>> On 3/17/09 6:26 AM, "Jim Schaad" <[e-mail]> wrote:
>>=20
>>> The attack we are looking at is a certificate substitution attack with =
the
>>> TSA certificate being changed to a different certificate.  This is not
>>> question of trusting the TSA itself.  Unless of course it is the one tr=
ying
>>> the attack for some reason.
>>> =20
>>> =20
>>>=20
>>> From: Santosh Chokhani [mailto:[e-mail]]
>>> Sent: Monday, March 16, 2009 9:25 PM
>>> To: Stefan Santesson; Jim Schaad; IETF-pkix
>>> Subject: RE: Do we need rfc 3161bis?
>>> =20
>>> I have not followed the thread well.  But, are we losing forest for the
>>> trees here?
>>> =20
>>> Do we not trust the TSA enough to not create collision attack?
>>>> =20
>>>>=20
>>>>=20
>>>> From: [e-mail] [mailto:[e-mail]=
g] On
>>>> Behalf Of Stefan Santesson
>>>> Sent: Monday, March 16, 2009 9:01 PM
>>>> To: Jim Schaad; 'IETF-pkix'
>>>> Subject: Re: Do we need rfc 3161bis?
>>>> OK,
>>>>=20
>>>> The prefix attack only works, as you say yourself, on the tbs bits to
>>>> create two certs with the same signature. This is ONLY possible if the
>>>> signature hash algorithm is broken. The hash in the essCertID is calcu=
lated
>>>> on the complete certificates (including signatures), not only the tbs =
bits.
>>>> Thus, the prefix attack is pretty useless if you have a large chunk of
>>>> random bits in the end that is bound to be different for each cert. An=
d
>>>> they will be different IF the signature algorithm of the certificates =
is
>>>> not broken.
>>>>=20
>>>> The second question, sorry for missing it, is broader than just RFC
>>>> 3161bis.
>>>>=20
>>>> I think we have many protocols, where collision resistance is not an i=
ssue,
>>>> where we don=B9t provide algorithm agility for all uses of SHA-1. I do t=
hink
>>>> there is a use of SHA-1 in OCSP that is not part of the current update
>>>> proposal and there is currently a similar discussion in TLS where stro=
ng
>>>> arguments are raised against adding algorithm negotiation complexity w=
hen
>>>> collision resistance is not a security issue. This problem is more
>>>> political than technical. But if there is any reason to do this, it
>>>> probably is for political reasons, so your point is valid.
>>>>=20
>>>> /Stefan
>>>>=20
>>>> On 3/17/09 1:20 AM, "Jim Schaad" <[e-mail]> wrote:
>>>> Stefan,
>>>> =20
>>>> First I don=B9t know that I agree.  I think that the entirety of your
>>>> protection is actually given by the leading sequence/length bytes.  Th=
e
>>>> object is to prevent a prefix attack.  One can create a prefix attack
>>>> against the TBS bytes =AD leading to identical signatures for both versi=
ons
>>>> of the certificate.  However adding the leading sequence/length octets
>>>> probably means that you need to have two different prefix attacks =AD a =
much
>>>> harder condition, but maybe doable.
>>>> =20
>>>> However I don=B9t believe that you addressed my second point at all.  Th=
at is
>>>> people completely migrate away from SHA-1 because it is considered to =
be
>>>> broken.
>>>> =20
>>>> jim
>>>> =20
>>>>=20
>>>> From: Stefan Santesson [mailto:[e-mail]]
>>>> Sent: Monday, March 16, 2009 5:09 PM
>>>> To: Jim Schaad; 'IETF-pkix'
>>>> Subject: Re: Do we need rfc 3161bis?
>>>>=20
>>>> Jim,
>>>>=20
>>>> You ask,
>>>> The question becomes can I create two certificates that can have the s=
ame
>>>> hash, NOT will it happen by chance.
>>>>=20
>>>> I totally agree. And I don=B9t think you can.
>>>>=20
>>>> Not if the two certificates are signed with a good signature algorithm=
.
>>>> If these certificates are signed with a bad signature algorithm that a=
llows
>>>> different certificates to share the same signature, then all bets are =
off
>>>> anyway.
>>>>=20
>>>> If the signature algorithms are good, then the signatures of these
>>>> certificates will be composed of a substantial amount of vastly differ=
ent
>>>> bits. As the signature algorithm is good, you can=B9t control the bits o=
f
>>>> these signatures in any meaningful way, leaving you basically with a t=
rial
>>>> and error approach. That even if SHA-1 is broken.
>>>>=20
>>>> /Stefan
>>>>=20
>>>>=20
>>>> On 3/16/09 8:17 PM, "Jim Schaad" <[e-mail]> wrote:
>>>> Stefan,
>>>> =20
>>>> The property that is being used is not the randomness property, it is =
a
>>>> collision property.  (Or more specifically resistance to collisions.) =
  The
>>>> question becomes can I create two certificates that can have the same =
hash,
>>>> NOT will it happen by chance.   If I can do so then I have a successfu=
l
>>>> attack at this point.
>>>> =20
>>>> However one needs to assume that if SHA-1 is significantly broken, peo=
ple
>>>> will be removing it from the trusted algorithm list and would then nee=
d a
>>>> migration path of what to put in place of the current SHA-1 attribute.
>>>> This is the main reason for doing the update.
>>>> =20
>>>> jim
>>>> =20
>>>>=20
>>>> From: [e-mail] [mailto:[e-mail]=
g] On
>>>> Behalf Of Stefan Santesson
>>>> Sent: Saturday, March 14, 2009 5:54 PM
>>>> To: Jim Schaad; 'IETF-pkix'
>>>> Subject: Re: Do we need rfc 3161bis?
>>>>=20
>>>> Yes, a good question indeed.
>>>>=20
>>>> Say that SHA-1 is completely broken in the sense that we can produce
>>>> collisions at will, of all sorts and forms.
>>>> Say also that we have a few valid TSA certificates issued for the same=
 key
>>>> pair, signed using good hash algorithms (or else all bets are off anyw=
ay).
>>>>=20
>>>> The randomness properties of SHA-1 will remain intact even if SHA-1 is
>>>> broken. This means that the risk/chance that two valid certificates, s=
igned
>>>> with safe signature algorithms, will by chance produce collisions, is =
still
>>>> totally negligible.
>>>>=20
>>>> Where am I thinking wrong here?
>>>>=20
>>>> /Stefan
>>>>=20
>>>>=20
>>>>=20
>>>> On 3/14/09 8:00 PM, "Jim Schaad" <[e-mail]> wrote:
>>>> Stefan,
>>>> =20
>>>> The question you need to be asking is =AD Do you believe that SHA-1 will=
 be
>>>> broken one day, and if it is broken do you want to have in place a sol=
ution
>>>> to deal with it.
>>>> =20
>>>> Jim
>>>> =20
>>>> =20
>>>>=20
>>>> From: [e-mail] [mailto:[e-mail]=
g] On
>>>> Behalf Of Stefan Santesson
>>>> Sent: Saturday, March 14, 2009 7:06 AM
>>>> To: IETF-pkix
>>>> Subject: Do we need rfc 3161bis?
>>>>=20
>>>> The more I look into this the more I get to doubt that we actually nee=
d
>>>> 3161bis.
>>>>=20
>>>> The only substantial technical change I know of is to allow the update=
d ESS
>>>> certIDv2 to be used to identify the signer=B9s certificate IF the TSA fo=
r
>>>> some reason choose to hash its certificate with another hash then SHA-=
1.
>>>>=20
>>>> The rationale for the certID identifier is given in section 5 of RFC 2=
634
>>>> and describes attacks where one valid certificate is substituted by an=
other
>>>> valid certificate (exceopt for some DoS case that I don=B9t think is rel=
evant
>>>> here).
>>>> Now I have to ask myself. How likely is it that a legitimate TSA has 2=
  or
>>>> more legitimate certificates for the same public key with conflicting
>>>> information (or information different enough to actually have a securi=
ty
>>>> impact) AND where the hash of these certificates produce a SHA-1 colli=
sion.
>>>>=20
>>>> This is not the previously discussed certificate collision attack usin=
g
>>>> weak certificate signing hash, where I may prepare a certificate reque=
st in
>>>> a way where I can fool the CA to produce two valid certificates with t=
he
>>>> same certificate signature. If I would use that technique I would have=
 to
>>>> find a way to prepare the TSA certificate requests, the TSA certificat=
e
>>>> hash need to be weak in addition to the certID hash AND In addition to=
 that
>>>> the complete certificates (not only the to be signed part) need to cre=
ate a
>>>> hash collision when computing the certID.
>>>>=20
>>>> So, my first question is if this change addresses any real security th=
reat?
>>>> Can someone provide a reasonable threat analysis?
>>>> And consequently, if there are no real threats to solve, does this upd=
ate
>>>> motivate the potential interoperability issues that might be the resul=
t of
>>>> by allowing ESS CertIDv2 in time stamp tokens?
>>>>=20
>>>>=20
>>>> If we do come to the conclusion that it is worth it, then why not just
>>>> create an update RFC updating RFC 3161 instead of replacing it?
>>>>=20
>>>> This update does not change any bits on the wire for implementations o=
f the
>>>> current protocol. The only thing it does is to add an option to use ES=
S
>>>> certIDv2 IF SHA-1 is not used as hash to identify the TSA=B9s certificat=
e.
>>>> This seems like a perfect thing for an update RFC. Another argument is=
 that
>>>> the old editors that rightfully should have the credit for RFC 3161 ar=
e not
>>>> part of this minor amendment but are completely erased from the update=
.
>>>> That may be reasonable if the changes are major but I=B9m not so sure in=
 this
>>>> case.
>>>>=20
>>>>=20


--B_3320157984_11999033
Content-type: text/html;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Re: Do we need rfc 3161bis?</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt'>Denis,<=
BR>
<BR>
On your first remark &nbsp;&nbsp;&nbsp;:D<BR>
<BR>
On your second remark:<BR>
</SPAN></FONT><SPAN STYLE=3D'font-size:11pt'><FONT FACE=3D"Calibri, Verdana, He=
lvetica, Arial">Good, even that level of agreement is a great step forward. =
I think 1 and 2 was more an agreement between me and Julien. But since the c=
onclusion is to allow essCertIDv2, point 1 and 2 is of less importance.<BR>
<BR>
</FONT><FONT FACE=3D"Verdana, Helvetica, Arial">/Stefan<BR>
</FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><BR>
On 3/17/09 4:02 PM, &quot;<a href=3D"[e-mail]">denis.pinkas@bull=
.net</a>&quot; &lt;<a href=3D"[e-mail]">[e-mail]</a>=
&gt; wrote:<BR>
<BR>
</FONT></SPAN><BLOCKQUOTE><SPAN STYLE=3D'font-size:11pt'><FONT FACE=3D"Verdana,=
 Helvetica, Arial">Stefan wrote his e-mail during a meeting where the priori=
ty is to listen to the meeting rather than sending e-mails<BR>
<BR>
&nbsp;<BR>
I disagree with points 1 and 2. Point 6 is one way to move forwards, but is=
 not the single way.<BR>
&nbsp;<BR>
Denis<BR>
&nbsp;<BR>
<FONT COLOR=3D"#990099"><a href=3D"[e-mail]">-----owne=
[e-mail]</a> wrote: -----<BR>
<BR>
</FONT>To: Stefan Santesson &lt;<a href=3D"[e-mail]">stefans@exmsft=
.com</a>&gt;, Jim Schaad &lt;<a href=3D"[e-mail]">ietf@augustcel=
lars.com</a>&gt;, &quot;'Santosh Chokhani'&quot; &lt;<a href=3D"SChokhani@cygn=
acom.com">[e-mail]</a>&gt;, &quot;'IETF-pkix'&quot; &lt;<a hre=
f=3D"[e-mail]">[e-mail]</a>&gt;<BR>
From: Stefan Santesson &lt;<a href=3D"[e-mail]">[e-mail]<=
/a>&gt;<BR>
Sent by: <a href=3D"[e-mail]">[e-mail]=
g</a><BR>
Date: 03/17/2009 03:29PM<BR>
Subject: Re: Do we need rfc 3161bis?<BR>
<BR>
</FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial">I had an informal fa=
ce2face meeting here in Barcelona between me, Julien Stern and Denis Pinkas.=
<BR>
<BR>
I will dare myself to write down some conclusion and trust Julien and Denis=
 to correct me if they disagree.<BR>
<BR>
</FONT></SPAN><OL><LI><SPAN STYLE=3D'font-size:11pt'><FONT FACE=3D"Calibri, Ver=
dana, Helvetica, Arial">There is no known threat for which the essCertIDv2 i=
s needed.
</FONT></SPAN><LI><SPAN STYLE=3D'font-size:11pt'><FONT FACE=3D"Calibri, Verdana=
, Helvetica, Arial">It is extremely hard to prove that there will not be any=
 threat or attack made up in the future where essCertIDv2 would be useful
</FONT></SPAN><LI><SPAN STYLE=3D'font-size:11pt'><FONT FACE=3D"Calibri, Verdana=
, Helvetica, Arial">As essCertIDv2 is standardized and has been a focus for =
EU work in relation to time stamps, it is probably reasonable to allow essCe=
rtIDv2 to be used with RFC 3161 time stamps.
</FONT></SPAN><LI><SPAN STYLE=3D'font-size:11pt'><FONT FACE=3D"Calibri, Verdana=
, Helvetica, Arial">For the sake of specifying the time stamp protocol, we o=
nly need one named entity representing the signer of the time stamp token (c=
urrently TSA in RFC 3161).
</FONT></SPAN><LI><SPAN STYLE=3D'font-size:11pt'><FONT FACE=3D"Calibri, Verdana=
, Helvetica, Arial">There is currently a disconnect between terminology in R=
FC 3161 and RFC 3628 (the policy document)
</FONT></SPAN><LI><SPAN STYLE=3D'font-size:11pt'><FONT FACE=3D"Calibri, Verdana=
, Helvetica, Arial">A solution that would satisfy all parties of this meetin=
g would be to write an update RFC (not a replacement as current proposal). T=
his update RFC would add the option to use essCertIDv2 AND would include an =
informational Annex &nbsp;explaining the basic difference in terminology bet=
ween RFC 3161 and RFC 3628. Most importantly this informational text would e=
xplain that TSU in the policy document corresponds to TSA in the protocol. <=
BR>
</FONT></SPAN></OL><SPAN STYLE=3D'font-size:11pt'><FONT FACE=3D"Calibri, Verdan=
a, Helvetica, Arial"><BR>
I support these conclusions.<BR>
<BR>
/Stefan<BR>
<BR>
<BR>
<BR>
On 3/17/09 7:55 AM, &quot;Stefan Santesson&quot; &lt;<a href=3D"stefans@exmsf=
t.com">[e-mail]</a>&gt; wrote:<BR>
<BR>
</FONT></SPAN><BLOCKQUOTE><SPAN STYLE=3D'font-size:11pt'><FONT FACE=3D"Calibri,=
 Verdana, Helvetica, Arial">Exactly as Jim says. Maybe we should add further=
 that this is a bout substituting one valid TSA certificate with another val=
id TSA certificate since the TSA for some reason has two TSA certificates fo=
r the same public key which when hashed, have the same SHA-1 hash.<BR>
<BR>
/Stefan<BR>
<BR>
<BR>
On 3/17/09 6:26 AM, &quot;Jim Schaad&quot; &lt;<a href=3D"ietf@augustcellars.=
com">[e-mail]</a>&gt; wrote:<BR>
<BR>
</FONT></SPAN><BLOCKQUOTE><SPAN STYLE=3D'font-size:11pt'><FONT FACE=3D"Calibri,=
 Verdana, Helvetica, Arial"><FONT COLOR=3D"#1F497D">The attack we are looking =
at is a certificate substitution attack with the TSA certificate being chang=
ed to a different certificate. &nbsp;This is not &nbsp;question of trusting =
the TSA itself. &nbsp;Unless of course it is the one trying the attack for s=
ome reason.<BR>
&nbsp;<BR>
&nbsp;<BR>
</FONT><BR>
</FONT><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial"><B>From:</B> Santosh =
Chokhani [<a href=3D"mailto:[e-mail]">mailto:SChokhani@cygnacom.=
com</a>] <BR>
<B>Sent:</B> Monday, March 16, 2009 9:25 PM<BR>
<B>To:</B> Stefan Santesson; Jim Schaad; IETF-pkix<BR>
<B>Subject:</B> RE: Do we need rfc 3161bis?<BR>
</FONT><FONT FACE=3D"Times New Roman"> <BR>
</FONT><FONT COLOR=3D"#0000FF"><FONT FACE=3D"Arial">I have not followed the thr=
ead well. &nbsp;But, are we losing forest for the trees here?<BR>
</FONT></FONT><FONT FACE=3D"Times New Roman"> <BR>
</FONT><FONT COLOR=3D"#0000FF"><FONT FACE=3D"Arial">Do we not trust the TSA eno=
ugh to not create collision attack?<BR>
</FONT></FONT></SPAN><BLOCKQUOTE><SPAN STYLE=3D'font-size:11pt'><FONT FACE=3D"T=
imes New Roman">=20
</FONT></SPAN>
<P ALIGN=3DCENTER>
<SPAN STYLE=3D'font-size:11pt'><FONT FACE=3D"Times New Roman"><HR ALIGN=3DCENTER =
SIZE=3D"2" WIDTH=3D"100%"></FONT></SPAN>
<P>
<SPAN STYLE=3D'font-size:11pt'><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial=
"><BR>
</FONT><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial"><B>From:</B> <a href=3D=
"[e-mail]">[e-mail]</a> [<a href=3D"ma=
ilto:[e-mail]">mailto:[e-mail]</a>] =
<B>On Behalf Of </B>Stefan Santesson<BR>
<B>Sent:</B> Monday, March 16, 2009 9:01 PM<BR>
<B>To:</B> Jim Schaad; 'IETF-pkix'<BR>
<B>Subject:</B> Re: Do we need rfc 3161bis?<BR>
</FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial">OK,<BR>
<BR>
The prefix attack only works, as you say yourself, on the tbs bits to creat=
e two certs with the same signature. This is ONLY possible if the signature =
hash algorithm is broken. The hash in the essCertID is calculated on the com=
plete certificates (including signatures), not only the tbs bits.<BR>
Thus, the prefix attack is pretty useless if you have a large chunk of rand=
om bits in the end that is bound to be different for each cert. And they wil=
l be different IF the signature algorithm of the certificates is not broken.=
<BR>
<BR>
The second question, sorry for missing it, is broader than just RFC 3161bis=
.<BR>
<BR>
I think we have many protocols, where collision resistance is not an issue,=
 where we don&#8217;t provide algorithm agility for all uses of SHA-1. I do =
think there is a use of SHA-1 in OCSP that is not part of the current update=
 proposal and there is currently a similar discussion in TLS where strong ar=
guments are raised against adding algorithm negotiation complexity when coll=
ision resistance is not a security issue. This problem is more political tha=
n technical. But if there is any reason to do this, it probably is for polit=
ical reasons, so your point is valid.<BR>
<BR>
/Stefan<BR>
<BR>
On 3/17/09 1:20 AM, &quot;Jim Schaad&quot; &lt;<a href=3D"ietf@augustcellars.=
com">[e-mail]</a>&gt; wrote:<BR>
<FONT COLOR=3D"#1F497D">Stefan,<BR>
&nbsp;<BR>
First I don&#8217;t know that I agree. &nbsp;I think that the entirety of y=
our protection is actually given by the leading sequence/length bytes. &nbsp=
;The object is to prevent a prefix attack. &nbsp;One can create a prefix att=
ack against the TBS bytes &#8211; leading to identical signatures for both v=
ersions of the certificate. &nbsp;However adding the leading sequence/length=
 octets probably means that you need to have two different prefix attacks &#=
8211; a much harder condition, but maybe doable.<BR>
&nbsp;<BR>
However I don&#8217;t believe that you addressed my second point at all. &n=
bsp;That is people completely migrate away from SHA-1 because it is consider=
ed to be broken.<BR>
&nbsp;<BR>
jim<BR>
&nbsp;<BR>
</FONT><BR>
</FONT><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial"><B>From:</B> Stefan S=
antesson [<a href=3D"mailto:[e-mail]">mailto:[e-mail]</a>]=
 <BR>
<B>Sent:</B> Monday, March 16, 2009 5:09 PM<BR>
<B>To:</B> Jim Schaad; 'IETF-pkix'<BR>
<B>Subject:</B> Re: Do we need rfc 3161bis?<BR>
</FONT><FONT FACE=3D"Times New Roman"><BR>
</FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial">Jim,<BR>
<BR>
You ask,<BR>
<FONT COLOR=3D"#1E487C">The question becomes can I create two certificates th=
at can have the same hash, NOT will it happen by chance.<BR>
</FONT><BR>
I <B>totally</B> agree. And I don&#8217;t think you can.<BR>
<BR>
Not if the two certificates are signed with a good signature algorithm. <BR=
>
If these certificates are signed with a bad signature algorithm that allows=
 different certificates to share the same signature, then all bets are off a=
nyway.<BR>
<BR>
If the signature algorithms are good, then the signatures of these certific=
ates will be composed of a substantial amount of vastly different bits. As t=
he signature algorithm is good, you can&#8217;t control the bits of these si=
gnatures in any meaningful way, leaving you basically with a trial and error=
 approach. That even if SHA-1 is broken.<BR>
<BR>
/Stefan<BR>
<BR>
<BR>
On 3/16/09 8:17 PM, &quot;Jim Schaad&quot; &lt;<a href=3D"ietf@augustcellars.=
com">[e-mail]</a>&gt; wrote:<BR>
<FONT COLOR=3D"#1F497D">Stefan,<BR>
&nbsp;<BR>
The property that is being used is not the randomness property, it is a col=
lision property. &nbsp;(Or more specifically resistance to collisions.) &nbs=
p;&nbsp;The question becomes can I create two certificates that can have the=
 same hash, NOT will it happen by chance. &nbsp;&nbsp;If I can do so then I =
have a successful attack at this point.<BR>
&nbsp;<BR>
However one needs to assume that if SHA-1 is significantly broken, people w=
ill be removing it from the trusted algorithm list and would then need a mig=
ration path of what to put in place of the current SHA-1 attribute. &nbsp;Th=
is is the main reason for doing the update.<BR>
&nbsp;<BR>
jim<BR>
&nbsp;<BR>
</FONT><BR>
</FONT><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial"><B>From:</B> <a href=3D=
"[e-mail]">[e-mail]</a> [<a href=3D"ma=
ilto:[e-mail]">mailto:[e-mail]</a>] =
<B>On Behalf Of </B>Stefan Santesson<BR>
<B>Sent:</B> Saturday, March 14, 2009 5:54 PM<BR>
<B>To:</B> Jim Schaad; 'IETF-pkix'<BR>
<B>Subject:</B> Re: Do we need rfc 3161bis?<BR>
</FONT><FONT FACE=3D"Times New Roman"><BR>
</FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial">Yes, a good question=
 indeed.<BR>
<BR>
Say that SHA-1 is completely broken in the sense that we can produce collis=
ions at will, of all sorts and forms.<BR>
Say also that we have a few valid TSA certificates issued for the same key =
pair, signed using good hash algorithms (or else all bets are off anyway).<B=
R>
<BR>
The randomness properties of SHA-1 will remain intact even if SHA-1 is brok=
en. This means that the risk/chance that two valid certificates, signed with=
 safe signature algorithms, will by chance produce collisions, is still tota=
lly negligible.<BR>
<BR>
Where am I thinking wrong here?<BR>
<BR>
/Stefan<BR>
<BR>
<BR>
<BR>
On 3/14/09 8:00 PM, &quot;Jim Schaad&quot; &lt;<a href=3D"ietf@augustcellars.=
com">[e-mail]</a>&gt; wrote:<BR>
<FONT COLOR=3D"#1F497D">Stefan,<BR>
&nbsp;<BR>
The question you need to be asking is &#8211; Do you believe that SHA-1 wil=
l be broken one day, and if it is broken do you want to have in place a solu=
tion to deal with it.<BR>
&nbsp;<BR>
Jim<BR>
&nbsp;<BR>
&nbsp;<BR>
</FONT><BR>
</FONT><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial"><B>From:</B> <a href=3D=
"[e-mail]">[e-mail]</a> [<a href=3D"ma=
ilto:[e-mail]">mailto:[e-mail]</a>] =
<B>On Behalf Of </B>Stefan Santesson<BR>
<B>Sent:</B> Saturday, March 14, 2009 7:06 AM<BR>
<B>To:</B> IETF-pkix<BR>
<B>Subject:</B> Do we need rfc 3161bis?<BR>
</FONT><FONT FACE=3D"Times New Roman"><BR>
</FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial">The more I look into=
 this the more I get to doubt that we actually need 3161bis.<BR>
<BR>
The only substantial technical change I know of is to allow the updated ESS=
 certIDv2 to be used to identify the signer&#8217;s certificate IF the TSA f=
or some reason choose to hash its certificate with another hash then SHA-1.<=
BR>
<BR>
The rationale for the certID identifier is given in section 5 of RFC 2634 a=
nd describes attacks where one valid certificate is substituted by another v=
alid certificate (exceopt for some DoS case that I don&#8217;t think is rele=
vant here).<BR>
Now I have to ask myself. How likely is it that a legitimate TSA has 2 &nbs=
p;or more legitimate certificates for the same public key with conflicting i=
nformation (or information different enough to actually have a security impa=
ct) AND where the hash of these certificates produce a SHA-1 collision.<BR>
<BR>
This is not the previously discussed certificate collision attack using wea=
k certificate signing hash, where I may prepare a certificate request in a w=
ay where I can fool the CA to produce two valid certificates with the same c=
ertificate signature. If I would use that technique I would have to find a w=
ay to prepare the TSA certificate requests, the TSA certificate hash need to=
 be weak in addition to the certID hash AND In addition to that the complete=
 certificates (not only the to be signed part) need to create a hash collisi=
on when computing the certID.<BR>
<BR>
So, my first question is if this change addresses any real security threat?=
<BR>
Can someone provide a reasonable threat analysis?<BR>
And consequently, if there are no real threats to solve, does this update m=
otivate the potential interoperability issues that might be the result of by=
 allowing ESS CertIDv2 in time stamp tokens?<BR>
<BR>
<BR>
If we do come to the conclusion that it is worth it, then why not just crea=
te an update RFC updating RFC 3161 instead of replacing it?<BR>
<BR>
This update does not change any bits on the wire for implementations of the=
 current protocol. The only thing it does is to add an option to use ESS cer=
tIDv2 IF SHA-1 is not used as hash to identify the TSA&#8217;s certificate.<=
BR>
This seems like a perfect thing for an update RFC. Another argument is that=
 the old editors that rightfully should have the credit for RFC 3161 are not=
 part of this minor amendment but are completely erased from the update. Tha=
t may be reasonable if the changes are major but I&#8217;m not so sure in th=
is case.<BR>
<BR>
</FONT></SPAN></BLOCKQUOTE><SPAN STYLE=3D'font-size:11pt'><FONT FACE=3D"Verdana=
, Helvetica, Arial"><BR>
</FONT></SPAN></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE>
</BODY>
</HTML>


--B_3320157984_11999033--




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 n2HF2V5b054330 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Mar 2009 08:02:31 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2HF2V7A054329; Tue, 17 Mar 2009 08:02:31 -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 n2HF2J4m054320 for <[e-mail]>; Tue, 17 Mar 2009 08:02:30 -0700 (MST) (envelope-from [e-mail])
Received: from MSGA-001.frcl.bull.fr (msga-001.frcl.bull.fr [129.184.87.31]) by odin2.bull.net (Bull S.A.) with ESMTP id 1D99C78B1; Tue, 17 Mar 2009 16:01:28 +0100 (CET)
Importance: Normal
X-Priority: 3 (Normal)
Subject: Re: Do we need rfc 3161bis?
MIME-Version: 1.0
From: [e-mail]
To: Stefan Santesson <[e-mail]>
Cc: Stefan Santesson <[e-mail]>, Jim Schaad <[e-mail]>, "'Santosh Chokhani'" <[e-mail]>, "'IETF-pkix'" <[e-mail]>
Date: Tue, 17 Mar 2009 16:02:19 +0100
Message-ID: <[e-mail]>
X-MIMETrack: Serialize by Router on MSGA-001/FR/BULL(Release 5.0.11  |July 24, 2002) at 17/03/2009 16:02:19
MIME-Version: 1.0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: base64
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

PEZPTlQgZmFjZT0iRGVmYXVsdCBTYW5zIFNlcmlmLCBWZXJkYW5hLCBBcmlhbCwgSGVsdmV0aWNh
LCBzYW5zLXNlcmlmIiBzaXplPTI+PERJVj5TdGVmYW4gd3JvdGUgaGlzIGUtbWFpbCBkdXJpbmcg
YSBtZWV0aW5nIHdoZXJlIHRoZSBwcmlvcml0eSBpcyB0byBsaXN0ZW4gdG8gdGhlIG1lZXRpbmcg
cmF0aGVyIHRoYW4gc2VuZGluZyBlLW1haWxzLjwvRElWPjxESVY+Jm5ic3A7PC9ESVY+PERJVj5J
IGRpc2FncmVlIHdpdGggcG9pbnRzIDEgYW5kIDIuIFBvaW50IDYgaXMgb25lIHdheSB0byBtb3Zl
IGZvcndhcmRzLCBidXQgaXMgbm90IHRoZSBzaW5nbGUgd2F5LjwvRElWPjxESVY+Jm5ic3A7PC9E
SVY+PERJVj5EZW5pczwvRElWPjxESVY+Jm5ic3A7PC9ESVY+PEZPTlQgY29sb3I9Izk5MDA5OT4t
LS0tLW93bmVyLWlldGYtcGtpeEBtYWlsLmltYy5vcmcgd3JvdGU6IC0tLS0tPEJSPjxCUj48L0ZP
TlQ+VG86IFN0ZWZhbiBTYW50ZXNzb24gJmx0O3N0ZWZhbnNAZXhtc2Z0LmNvbSZndDssIEppbSBT
Y2hhYWQgJmx0O2lldGZAYXVndXN0Y2VsbGFycy5jb20mZ3Q7LCAiJ1NhbnRvc2ggQ2hva2hhbmkn
IiAmbHQ7U0Nob2toYW5pQGN5Z25hY29tLmNvbSZndDssICInSUVURi1wa2l4JyIgJmx0O2lldGYt
cGtpeEBpbWMub3JnJmd0OzxCUj5Gcm9tOiBTdGVmYW4gU2FudGVzc29uICZsdDtzdGVmYW5zQGV4
bXNmdC5jb20mZ3Q7PEJSPlNlbnQgYnk6IG93bmVyLWlldGYtcGtpeEBtYWlsLmltYy5vcmc8QlI+
RGF0ZTogMDMvMTcvMjAwOSAwMzoyOVBNPEJSPlN1YmplY3Q6IFJlOiBEbyB3ZSBuZWVkIHJmYyAz
MTYxYmlzPzxCUj48QlI+PEZPTlQgRkFDRT0iQ2FsaWJyaSwgVmVyZGFuYSwgSGVsdmV0aWNhLCBB
cmlhbCI+PFNQQU4gPkkgaGFkIGFuIGluZm9ybWFsIGZhY2UyZmFjZSBtZWV0aW5nIGhlcmUgaW4g
QmFyY2Vsb25hIGJldHdlZW4gbWUsIEp1bGllbiBTdGVybiBhbmQgRGVuaXMgUGlua2FzLjxCUj48
QlI+SSB3aWxsIGRhcmUgbXlzZWxmIHRvIHdyaXRlIGRvd24gc29tZSBjb25jbHVzaW9uIGFuZCB0
cnVzdCBKdWxpZW4gYW5kIERlbmlzIHRvIGNvcnJlY3QgbWUgaWYgdGhleSBkaXNhZ3JlZS48QlI+
PEJSPjwvU1BBTj48L0ZPTlQ+PE9MPjxMST48Rk9OVCBGQUNFPSJDYWxpYnJpLCBWZXJkYW5hLCBI
ZWx2ZXRpY2EsIEFyaWFsIj48U1BBTiA+VGhlcmUgaXMgbm8ga25vd24gdGhyZWF0IGZvciB3aGlj
aCB0aGUgZXNzQ2VydElEdjIgaXMgbmVlZGVkLjwvU1BBTj48L0ZPTlQ+PExJPjxGT05UIEZBQ0U9
IkNhbGlicmksIFZlcmRhbmEsIEhlbHZldGljYSwgQXJpYWwiPjxTUEFOID5JdCBpcyBleHRyZW1l
bHkgaGFyZCB0byBwcm92ZSB0aGF0IHRoZXJlIHdpbGwgbm90IGJlIGFueSB0aHJlYXQgb3IgYXR0
YWNrIG1hZGUgdXAgaW4gdGhlIGZ1dHVyZSB3aGVyZSBlc3NDZXJ0SUR2MiB3b3VsZCBiZSB1c2Vm
dWw8L1NQQU4+PC9GT05UPjxMST48Rk9OVCBGQUNFPSJDYWxpYnJpLCBWZXJkYW5hLCBIZWx2ZXRp
Y2EsIEFyaWFsIj48U1BBTiA+QXMgZXNzQ2VydElEdjIgaXMgc3RhbmRhcmRpemVkIGFuZCBoYXMg
YmVlbiBhIGZvY3VzIGZvciBFVSB3b3JrIGluIHJlbGF0aW9uIHRvIHRpbWUgc3RhbXBzLCBpdCBp
cyBwcm9iYWJseSByZWFzb25hYmxlIHRvIGFsbG93IGVzc0NlcnRJRHYyIHRvIGJlIHVzZWQgd2l0
aCBSRkMgMzE2MSB0aW1lIHN0YW1wcy48L1NQQU4+PC9GT05UPjxMST48Rk9OVCBGQUNFPSJDYWxp
YnJpLCBWZXJkYW5hLCBIZWx2ZXRpY2EsIEFyaWFsIj48U1BBTiA+Rm9yIHRoZSBzYWtlIG9mIHNw
ZWNpZnlpbmcgdGhlIHRpbWUgc3RhbXAgcHJvdG9jb2wsIHdlIG9ubHkgbmVlZCBvbmUgbmFtZWQg
ZW50aXR5IHJlcHJlc2VudGluZyB0aGUgc2lnbmVyIG9mIHRoZSB0aW1lIHN0YW1wIHRva2VuIChj
dXJyZW50bHkgVFNBIGluIFJGQyAzMTYxKS48L1NQQU4+PC9GT05UPjxMST48Rk9OVCBGQUNFPSJD
YWxpYnJpLCBWZXJkYW5hLCBIZWx2ZXRpY2EsIEFyaWFsIj48U1BBTiA+VGhlcmUgaXMgY3VycmVu
dGx5IGEgZGlzY29ubmVjdCBiZXR3ZWVuIHRlcm1pbm9sb2d5IGluIFJGQyAzMTYxIGFuZCBSRkMg
MzYyOCAodGhlIHBvbGljeSBkb2N1bWVudCk8L1NQQU4+PC9GT05UPjxMST48Rk9OVCBGQUNFPSJD
YWxpYnJpLCBWZXJkYW5hLCBIZWx2ZXRpY2EsIEFyaWFsIj48U1BBTiA+QSBzb2x1dGlvbiB0aGF0
IHdvdWxkIHNhdGlzZnkgYWxsIHBhcnRpZXMgb2YgdGhpcyBtZWV0aW5nIHdvdWxkIGJlIHRvIHdy
aXRlIGFuIHVwZGF0ZSBSRkMgKG5vdCBhIHJlcGxhY2VtZW50IGFzIGN1cnJlbnQgcHJvcG9zYWwp
LiBUaGlzIHVwZGF0ZSBSRkMgd291bGQgYWRkIHRoZSBvcHRpb24gdG8gdXNlIGVzc0NlcnRJRHYy
IEFORCB3b3VsZCBpbmNsdWRlIGFuIGluZm9ybWF0aW9uYWwgQW5uZXggJm5ic3A7ZXhwbGFpbmlu
ZyB0aGUgYmFzaWMgZGlmZmVyZW5jZSBpbiB0ZXJtaW5vbG9neSBiZXR3ZWVuIFJGQyAzMTYxIGFu
ZCBSRkMgMzYyOC4gTW9zdCBpbXBvcnRhbnRseSB0aGlzIGluZm9ybWF0aW9uYWwgdGV4dCB3b3Vs
ZCBleHBsYWluIHRoYXQgVFNVIGluIHRoZSBwb2xpY3kgZG9jdW1lbnQgY29ycmVzcG9uZHMgdG8g
VFNBIGluIHRoZSBwcm90b2NvbC4gPEJSPjwvU1BBTj48L0ZPTlQ+PC9MST48L09MPjxGT05UIEZB
Q0U9IkNhbGlicmksIFZlcmRhbmEsIEhlbHZldGljYSwgQXJpYWwiPjxTUEFOID48QlI+SSBzdXBw
b3J0IHRoZXNlIGNvbmNsdXNpb25zLjxCUj48QlI+L1N0ZWZhbjxCUj48QlI+PEJSPjxCUj5PbiAz
LzE3LzA5IDc6NTUgQU0sICJTdGVmYW4gU2FudGVzc29uIiAmbHQ7PEEgaHJlZj0ic3RlZmFuc0Bl
eG1zZnQuY29tIiB0YXJnZXQ9YmxhbmsgPnN0ZWZhbnNAZXhtc2Z0LmNvbTwvYT4mZ3Q7IHdyb3Rl
OjxCUj48QlI+PC9TUEFOPjwvRk9OVD48QkxPQ0tRVU9URT48Rk9OVCBGQUNFPSJDYWxpYnJpLCBW
ZXJkYW5hLCBIZWx2ZXRpY2EsIEFyaWFsIj48U1BBTiA+RXhhY3RseSBhcyBKaW0gc2F5cy4gTWF5
YmUgd2Ugc2hvdWxkIGFkZCBmdXJ0aGVyIHRoYXQgdGhpcyBpcyBhIGJvdXQgc3Vic3RpdHV0aW5n
IG9uZSB2YWxpZCBUU0EgY2VydGlmaWNhdGUgd2l0aCBhbm90aGVyIHZhbGlkIFRTQSBjZXJ0aWZp
Y2F0ZSBzaW5jZSB0aGUgVFNBIGZvciBzb21lIHJlYXNvbiBoYXMgdHdvIFRTQSBjZXJ0aWZpY2F0
ZXMgZm9yIHRoZSBzYW1lIHB1YmxpYyBrZXkgd2hpY2ggd2hlbiBoYXNoZWQsIGhhdmUgdGhlIHNh
bWUgU0hBLTEgaGFzaC48QlI+PEJSPi9TdGVmYW48QlI+PEJSPjxCUj5PbiAzLzE3LzA5IDY6MjYg
QU0sICJKaW0gU2NoYWFkIiAmbHQ7PEEgaHJlZj0iaWV0ZkBhdWd1c3RjZWxsYXJzLmNvbSIgdGFy
Z2V0PWJsYW5rID5pZXRmQGF1Z3VzdGNlbGxhcnMuY29tPC9hPiZndDsgd3JvdGU6PEJSPjxCUj48
L1NQQU4+PC9GT05UPjxCTE9DS1FVT1RFPjxGT05UIEZBQ0U9IkNhbGlicmksIFZlcmRhbmEsIEhl
bHZldGljYSwgQXJpYWwiPjxTUEFOID48Rk9OVCBDT0xPUj0iIzFmNDk3ZCI+VGhlIGF0dGFjayB3
ZSBhcmUgbG9va2luZyBhdCBpcyBhIGNlcnRpZmljYXRlIHN1YnN0aXR1dGlvbiBhdHRhY2sgd2l0
aCB0aGUgVFNBIGNlcnRpZmljYXRlIGJlaW5nIGNoYW5nZWQgdG8gYSBkaWZmZXJlbnQgY2VydGlm
aWNhdGUuICZuYnNwO1RoaXMgaXMgbm90ICZuYnNwO3F1ZXN0aW9uIG9mIHRydXN0aW5nIHRoZSBU
U0EgaXRzZWxmLiAmbmJzcDtVbmxlc3Mgb2YgY291cnNlIGl0IGlzIHRoZSBvbmUgdHJ5aW5nIHRo
ZSBhdHRhY2sgZm9yIHNvbWUgcmVhc29uLjxCUj4mbmJzcDs8QlI+Jm5ic3A7PEJSPjwvRk9OVD48
QlI+PC9TUEFOPjwvRk9OVD48Rk9OVCBTSVpFPSIyIj48Rk9OVCBGQUNFPSJUYWhvbWEsIFZlcmRh
bmEsIEhlbHZldGljYSwgQXJpYWwiPjxTUEFOID48Qj5Gcm9tOjwvQj4gU2FudG9zaCBDaG9raGFu
aSBbPEEgaHJlZj0ibWFpbHRvOlNDaG9raGFuaUBjeWduYWNvbS5jb20iIHRhcmdldD1ibGFuayA+
bWFpbHRvOlNDaG9raGFuaUBjeWduYWNvbS5jb208L2E+XSA8QlI+PEI+U2VudDo8L0I+IE1vbmRh
eSwgTWFyY2ggMTYsIDIwMDkgOToyNSBQTTxCUj48Qj5Ubzo8L0I+IFN0ZWZhbiBTYW50ZXNzb247
IEppbSBTY2hhYWQ7IElFVEYtcGtpeDxCUj48Qj5TdWJqZWN0OjwvQj4gUkU6IERvIHdlIG5lZWQg
cmZjIDMxNjFiaXM/PEJSPjwvU1BBTj48L0ZPTlQ+PC9GT05UPjxGT05UIEZBQ0U9IlRpbWVzIE5l
dyBSb21hbiI+PFNQQU4gPiA8QlI+PC9TUEFOPjwvRk9OVD48Rk9OVCBDT0xPUj0iIzAwMDBmZiI+
PEZPTlQgU0laRT0iMiI+PEZPTlQgRkFDRT0iQXJpYWwiPjxTUEFOID5JIGhhdmUgbm90IGZvbGxv
d2VkIHRoZSB0aHJlYWQgd2VsbC4gJm5ic3A7QnV0LCBhcmUgd2UgbG9zaW5nIGZvcmVzdCBmb3Ig
dGhlIHRyZWVzIGhlcmU/PEJSPjwvU1BBTj48L0ZPTlQ+PC9GT05UPjwvRk9OVD48Rk9OVCBGQUNF
PSJUaW1lcyBOZXcgUm9tYW4iPjxTUEFOID4gPEJSPjwvU1BBTj48L0ZPTlQ+PEZPTlQgQ09MT1I9
IiMwMDAwZmYiPjxGT05UIFNJWkU9IjIiPjxGT05UIEZBQ0U9IkFyaWFsIj48U1BBTiA+RG8gd2Ug
bm90IHRydXN0IHRoZSBUU0EgZW5vdWdoIHRvIG5vdCBjcmVhdGUgY29sbGlzaW9uIGF0dGFjaz88
QlI+PC9TUEFOPjwvRk9OVD48L0ZPTlQ+PC9GT05UPjxCTE9DS1FVT1RFPjxGT05UIEZBQ0U9IlRp
bWVzIE5ldyBSb21hbiI+PFNQQU4gPiA8L1NQQU4+PC9GT05UPjxQIEFMSUdOPWNlbnRlcj48Rk9O
VCBGQUNFPSJUaW1lcyBOZXcgUm9tYW4iPjxTUEFOID48SFIgQUxJR049Y2VudGVyIFNJWkU9IjIi
IFdJRFRIPSIxMDAlIj48L1NQQU4+PC9GT05UPjxQPjxGT05UIEZBQ0U9IkNhbGlicmksIFZlcmRh
bmEsIEhlbHZldGljYSwgQXJpYWwiPjxTUEFOID48QlI+PC9TUEFOPjwvRk9OVD48Rk9OVCBTSVpF
PSIyIj48Rk9OVCBGQUNFPSJUYWhvbWEsIFZlcmRhbmEsIEhlbHZldGljYSwgQXJpYWwiPjxTUEFO
ID48Qj5Gcm9tOjwvQj4gPEEgaHJlZj0ib3duZXItaWV0Zi1wa2l4QG1haWwuaW1jLm9yZyIgdGFy
Z2V0PWJsYW5rID5vd25lci1pZXRmLXBraXhAbWFpbC5pbWMub3JnPC9hPiBbPEEgaHJlZj0ibWFp
bHRvOm93bmVyLWlldGYtcGtpeEBtYWlsLmltYy5vcmciIHRhcmdldD1ibGFuayA+bWFpbHRvOm93
bmVyLWlldGYtcGtpeEBtYWlsLmltYy5vcmc8L2E+XSA8Qj5PbiBCZWhhbGYgT2YgPC9CPlN0ZWZh
biBTYW50ZXNzb248QlI+PEI+U2VudDo8L0I+IE1vbmRheSwgTWFyY2ggMTYsIDIwMDkgOTowMSBQ
TTxCUj48Qj5Ubzo8L0I+IEppbSBTY2hhYWQ7ICdJRVRGLXBraXgnPEJSPjxCPlN1YmplY3Q6PC9C
PiBSZTogRG8gd2UgbmVlZCByZmMgMzE2MWJpcz88QlI+PC9TUEFOPjwvRk9OVD48L0ZPTlQ+PEZP
TlQgRkFDRT0iQ2FsaWJyaSwgVmVyZGFuYSwgSGVsdmV0aWNhLCBBcmlhbCI+PFNQQU4gPk9LLDxC
Uj48QlI+VGhlIHByZWZpeCBhdHRhY2sgb25seSB3b3JrcywgYXMgeW91IHNheSB5b3Vyc2VsZiwg
b24gdGhlIHRicyBiaXRzIHRvIGNyZWF0ZSB0d28gY2VydHMgd2l0aCB0aGUgc2FtZSBzaWduYXR1
cmUuIFRoaXMgaXMgT05MWSBwb3NzaWJsZSBpZiB0aGUgc2lnbmF0dXJlIGhhc2ggYWxnb3JpdGht
IGlzIGJyb2tlbi4gVGhlIGhhc2ggaW4gdGhlIGVzc0NlcnRJRCBpcyBjYWxjdWxhdGVkIG9uIHRo
ZSBjb21wbGV0ZSBjZXJ0aWZpY2F0ZXMgKGluY2x1ZGluZyBzaWduYXR1cmVzKSwgbm90IG9ubHkg
dGhlIHRicyBiaXRzLjxCUj5UaHVzLCB0aGUgcHJlZml4IGF0dGFjayBpcyBwcmV0dHkgdXNlbGVz
cyBpZiB5b3UgaGF2ZSBhIGxhcmdlIGNodW5rIG9mIHJhbmRvbSBiaXRzIGluIHRoZSBlbmQgdGhh
dCBpcyBib3VuZCB0byBiZSBkaWZmZXJlbnQgZm9yIGVhY2ggY2VydC4gQW5kIHRoZXkgd2lsbCBi
ZSBkaWZmZXJlbnQgSUYgdGhlIHNpZ25hdHVyZSBhbGdvcml0aG0gb2YgdGhlIGNlcnRpZmljYXRl
cyBpcyBub3QgYnJva2VuLjxCUj48QlI+VGhlIHNlY29uZCBxdWVzdGlvbiwgc29ycnkgZm9yIG1p
c3NpbmcgaXQsIGlzIGJyb2FkZXIgdGhhbiBqdXN0IFJGQyAzMTYxYmlzLjxCUj48QlI+SSB0aGlu
ayB3ZSBoYXZlIG1hbnkgcHJvdG9jb2xzLCB3aGVyZSBjb2xsaXNpb24gcmVzaXN0YW5jZSBpcyBu
b3QgYW4gaXNzdWUsIHdoZXJlIHdlIGRvbpJ0IHByb3ZpZGUgYWxnb3JpdGhtIGFnaWxpdHkgZm9y
IGFsbCB1c2VzIG9mIFNIQS0xLiBJIGRvIHRoaW5rIHRoZXJlIGlzIGEgdXNlIG9mIFNIQS0xIGlu
IE9DU1AgdGhhdCBpcyBub3QgcGFydCBvZiB0aGUgY3VycmVudCB1cGRhdGUgcHJvcG9zYWwgYW5k
IHRoZXJlIGlzIGN1cnJlbnRseSBhIHNpbWlsYXIgZGlzY3Vzc2lvbiBpbiBUTFMgd2hlcmUgc3Ry
b25nIGFyZ3VtZW50cyBhcmUgcmFpc2VkIGFnYWluc3QgYWRkaW5nIGFsZ29yaXRobSBuZWdvdGlh
dGlvbiBjb21wbGV4aXR5IHdoZW4gY29sbGlzaW9uIHJlc2lzdGFuY2UgaXMgbm90IGEgc2VjdXJp
dHkgaXNzdWUuIFRoaXMgcHJvYmxlbSBpcyBtb3JlIHBvbGl0aWNhbCB0aGFuIHRlY2huaWNhbC4g
QnV0IGlmIHRoZXJlIGlzIGFueSByZWFzb24gdG8gZG8gdGhpcywgaXQgcHJvYmFibHkgaXMgZm9y
IHBvbGl0aWNhbCByZWFzb25zLCBzbyB5b3VyIHBvaW50IGlzIHZhbGlkLjxCUj48QlI+L1N0ZWZh
bjxCUj48QlI+T24gMy8xNy8wOSAxOjIwIEFNLCAiSmltIFNjaGFhZCIgJmx0OzxBIGhyZWY9Imll
dGZAYXVndXN0Y2VsbGFycy5jb20iIHRhcmdldD1ibGFuayA+aWV0ZkBhdWd1c3RjZWxsYXJzLmNv
bTwvYT4mZ3Q7IHdyb3RlOjxCUj48Rk9OVCBDT0xPUj0iIzFmNDk3ZCI+U3RlZmFuLDxCUj4mbmJz
cDs8QlI+Rmlyc3QgSSBkb26SdCBrbm93IHRoYXQgSSBhZ3JlZS4gJm5ic3A7SSB0aGluayB0aGF0
IHRoZSBlbnRpcmV0eSBvZiB5b3VyIHByb3RlY3Rpb24gaXMgYWN0dWFsbHkgZ2l2ZW4gYnkgdGhl
IGxlYWRpbmcgc2VxdWVuY2UvbGVuZ3RoIGJ5dGVzLiAmbmJzcDtUaGUgb2JqZWN0IGlzIHRvIHBy
ZXZlbnQgYSBwcmVmaXggYXR0YWNrLiAmbmJzcDtPbmUgY2FuIGNyZWF0ZSBhIHByZWZpeCBhdHRh
Y2sgYWdhaW5zdCB0aGUgVEJTIGJ5dGVzIJYgbGVhZGluZyB0byBpZGVudGljYWwgc2lnbmF0dXJl
cyBmb3IgYm90aCB2ZXJzaW9ucyBvZiB0aGUgY2VydGlmaWNhdGUuICZuYnNwO0hvd2V2ZXIgYWRk
aW5nIHRoZSBsZWFkaW5nIHNlcXVlbmNlL2xlbmd0aCBvY3RldHMgcHJvYmFibHkgbWVhbnMgdGhh
dCB5b3UgbmVlZCB0byBoYXZlIHR3byBkaWZmZXJlbnQgcHJlZml4IGF0dGFja3MgliBhIG11Y2gg
aGFyZGVyIGNvbmRpdGlvbiwgYnV0IG1heWJlIGRvYWJsZS48QlI+Jm5ic3A7PEJSPkhvd2V2ZXIg
SSBkb26SdCBiZWxpZXZlIHRoYXQgeW91IGFkZHJlc3NlZCBteSBzZWNvbmQgcG9pbnQgYXQgYWxs
LiAmbmJzcDtUaGF0IGlzIHBlb3BsZSBjb21wbGV0ZWx5IG1pZ3JhdGUgYXdheSBmcm9tIFNIQS0x
IGJlY2F1c2UgaXQgaXMgY29uc2lkZXJlZCB0byBiZSBicm9rZW4uPEJSPiZuYnNwOzxCUj5qaW08
QlI+Jm5ic3A7PEJSPjwvRk9OVD48QlI+PC9TUEFOPjwvRk9OVD48Rk9OVCBTSVpFPSIyIj48Rk9O
VCBGQUNFPSJUYWhvbWEsIFZlcmRhbmEsIEhlbHZldGljYSwgQXJpYWwiPjxTUEFOID48Qj5Gcm9t
OjwvQj4gU3RlZmFuIFNhbnRlc3NvbiBbPEEgaHJlZj0ibWFpbHRvOnN0ZWZhbnNAZXhtc2Z0LmNv
bSIgdGFyZ2V0PWJsYW5rID5tYWlsdG86c3RlZmFuc0BleG1zZnQuY29tPC9hPl0gPEJSPjxCPlNl
bnQ6PC9CPiBNb25kYXksIE1hcmNoIDE2LCAyMDA5IDU6MDkgUE08QlI+PEI+VG86PC9CPiBKaW0g
U2NoYWFkOyAnSUVURi1wa2l4JzxCUj48Qj5TdWJqZWN0OjwvQj4gUmU6IERvIHdlIG5lZWQgcmZj
IDMxNjFiaXM/PEJSPjwvU1BBTj48L0ZPTlQ+PC9GT05UPjxGT05UIEZBQ0U9IlRpbWVzIE5ldyBS
b21hbiI+PFNQQU4gPjxCUj48L1NQQU4+PC9GT05UPjxGT05UIEZBQ0U9IkNhbGlicmksIFZlcmRh
bmEsIEhlbHZldGljYSwgQXJpYWwiPjxTUEFOID5KaW0sPEJSPjxCUj5Zb3UgYXNrLDxCUj48Rk9O
VCBDT0xPUj0iIzFlNDg3YyI+VGhlIHF1ZXN0aW9uIGJlY29tZXMgY2FuIEkgY3JlYXRlIHR3byBj
ZXJ0aWZpY2F0ZXMgdGhhdCBjYW4gaGF2ZSB0aGUgc2FtZSBoYXNoLCBOT1Qgd2lsbCBpdCBoYXBw
ZW4gYnkgY2hhbmNlLjxCUj48L0ZPTlQ+PEJSPkkgPEI+dG90YWxseTwvQj4gYWdyZWUuIEFuZCBJ
IGRvbpJ0IHRoaW5rIHlvdSBjYW4uPEJSPjxCUj5Ob3QgaWYgdGhlIHR3byBjZXJ0aWZpY2F0ZXMg
YXJlIHNpZ25lZCB3aXRoIGEgZ29vZCBzaWduYXR1cmUgYWxnb3JpdGhtLiA8QlI+SWYgdGhlc2Ug
Y2VydGlmaWNhdGVzIGFyZSBzaWduZWQgd2l0aCBhIGJhZCBzaWduYXR1cmUgYWxnb3JpdGhtIHRo
YXQgYWxsb3dzIGRpZmZlcmVudCBjZXJ0aWZpY2F0ZXMgdG8gc2hhcmUgdGhlIHNhbWUgc2lnbmF0
dXJlLCB0aGVuIGFsbCBiZXRzIGFyZSBvZmYgYW55d2F5LjxCUj48QlI+SWYgdGhlIHNpZ25hdHVy
ZSBhbGdvcml0aG1zIGFyZSBnb29kLCB0aGVuIHRoZSBzaWduYXR1cmVzIG9mIHRoZXNlIGNlcnRp
ZmljYXRlcyB3aWxsIGJlIGNvbXBvc2VkIG9mIGEgc3Vic3RhbnRpYWwgYW1vdW50IG9mIHZhc3Rs
eSBkaWZmZXJlbnQgYml0cy4gQXMgdGhlIHNpZ25hdHVyZSBhbGdvcml0aG0gaXMgZ29vZCwgeW91
IGNhbpJ0IGNvbnRyb2wgdGhlIGJpdHMgb2YgdGhlc2Ugc2lnbmF0dXJlcyBpbiBhbnkgbWVhbmlu
Z2Z1bCB3YXksIGxlYXZpbmcgeW91IGJhc2ljYWxseSB3aXRoIGEgdHJpYWwgYW5kIGVycm9yIGFw
cHJvYWNoLiBUaGF0IGV2ZW4gaWYgU0hBLTEgaXMgYnJva2VuLjxCUj48QlI+L1N0ZWZhbjxCUj48
QlI+PEJSPk9uIDMvMTYvMDkgODoxNyBQTSwgIkppbSBTY2hhYWQiICZsdDs8QSBocmVmPSJpZXRm
QGF1Z3VzdGNlbGxhcnMuY29tIiB0YXJnZXQ9YmxhbmsgPmlldGZAYXVndXN0Y2VsbGFycy5jb208
L2E+Jmd0OyB3cm90ZTo8QlI+PEZPTlQgQ09MT1I9IiMxZjQ5N2QiPlN0ZWZhbiw8QlI+Jm5ic3A7
PEJSPlRoZSBwcm9wZXJ0eSB0aGF0IGlzIGJlaW5nIHVzZWQgaXMgbm90IHRoZSByYW5kb21uZXNz
IHByb3BlcnR5LCBpdCBpcyBhIGNvbGxpc2lvbiBwcm9wZXJ0eS4gJm5ic3A7KE9yIG1vcmUgc3Bl
Y2lmaWNhbGx5IHJlc2lzdGFuY2UgdG8gY29sbGlzaW9ucy4pICZuYnNwOyZuYnNwO1RoZSBxdWVz
dGlvbiBiZWNvbWVzIGNhbiBJIGNyZWF0ZSB0d28gY2VydGlmaWNhdGVzIHRoYXQgY2FuIGhhdmUg
dGhlIHNhbWUgaGFzaCwgTk9UIHdpbGwgaXQgaGFwcGVuIGJ5IGNoYW5jZS4gJm5ic3A7Jm5ic3A7
SWYgSSBjYW4gZG8gc28gdGhlbiBJIGhhdmUgYSBzdWNjZXNzZnVsIGF0dGFjayBhdCB0aGlzIHBv
aW50LjxCUj4mbmJzcDs8QlI+SG93ZXZlciBvbmUgbmVlZHMgdG8gYXNzdW1lIHRoYXQgaWYgU0hB
LTEgaXMgc2lnbmlmaWNhbnRseSBicm9rZW4sIHBlb3BsZSB3aWxsIGJlIHJlbW92aW5nIGl0IGZy
b20gdGhlIHRydXN0ZWQgYWxnb3JpdGhtIGxpc3QgYW5kIHdvdWxkIHRoZW4gbmVlZCBhIG1pZ3Jh
dGlvbiBwYXRoIG9mIHdoYXQgdG8gcHV0IGluIHBsYWNlIG9mIHRoZSBjdXJyZW50IFNIQS0xIGF0
dHJpYnV0ZS4gJm5ic3A7VGhpcyBpcyB0aGUgbWFpbiByZWFzb24gZm9yIGRvaW5nIHRoZSB1cGRh
dGUuPEJSPiZuYnNwOzxCUj5qaW08QlI+Jm5ic3A7PEJSPjwvRk9OVD48QlI+PC9TUEFOPjwvRk9O
VD48Rk9OVCBTSVpFPSIyIj48Rk9OVCBGQUNFPSJUYWhvbWEsIFZlcmRhbmEsIEhlbHZldGljYSwg
QXJpYWwiPjxTUEFOID48Qj5Gcm9tOjwvQj4gPEEgaHJlZj0ib3duZXItaWV0Zi1wa2l4QG1haWwu
aW1jLm9yZyIgdGFyZ2V0PWJsYW5rID5vd25lci1pZXRmLXBraXhAbWFpbC5pbWMub3JnPC9hPiBb
PEEgaHJlZj0ibWFpbHRvOm93bmVyLWlldGYtcGtpeEBtYWlsLmltYy5vcmciIHRhcmdldD1ibGFu
ayA+bWFpbHRvOm93bmVyLWlldGYtcGtpeEBtYWlsLmltYy5vcmc8L2E+XSA8Qj5PbiBCZWhhbGYg
T2YgPC9CPlN0ZWZhbiBTYW50ZXNzb248QlI+PEI+U2VudDo8L0I+IFNhdHVyZGF5LCBNYXJjaCAx
NCwgMjAwOSA1OjU0IFBNPEJSPjxCPlRvOjwvQj4gSmltIFNjaGFhZDsgJ0lFVEYtcGtpeCc8QlI+
PEI+U3ViamVjdDo8L0I+IFJlOiBEbyB3ZSBuZWVkIHJmYyAzMTYxYmlzPzxCUj48L1NQQU4+PC9G
T05UPjwvRk9OVD48Rk9OVCBGQUNFPSJUaW1lcyBOZXcgUm9tYW4iPjxTUEFOID48QlI+PC9TUEFO
PjwvRk9OVD48Rk9OVCBGQUNFPSJDYWxpYnJpLCBWZXJkYW5hLCBIZWx2ZXRpY2EsIEFyaWFsIj48
U1BBTiA+WWVzLCBhIGdvb2QgcXVlc3Rpb24gaW5kZWVkLjxCUj48QlI+U2F5IHRoYXQgU0hBLTEg
aXMgY29tcGxldGVseSBicm9rZW4gaW4gdGhlIHNlbnNlIHRoYXQgd2UgY2FuIHByb2R1Y2UgY29s
bGlzaW9ucyBhdCB3aWxsLCBvZiBhbGwgc29ydHMgYW5kIGZvcm1zLjxCUj5TYXkgYWxzbyB0aGF0
IHdlIGhhdmUgYSBmZXcgdmFsaWQgVFNBIGNlcnRpZmljYXRlcyBpc3N1ZWQgZm9yIHRoZSBzYW1l
IGtleSBwYWlyLCBzaWduZWQgdXNpbmcgZ29vZCBoYXNoIGFsZ29yaXRobXMgKG9yIGVsc2UgYWxs
IGJldHMgYXJlIG9mZiBhbnl3YXkpLjxCUj48QlI+VGhlIHJhbmRvbW5lc3MgcHJvcGVydGllcyBv
ZiBTSEEtMSB3aWxsIHJlbWFpbiBpbnRhY3QgZXZlbiBpZiBTSEEtMSBpcyBicm9rZW4uIFRoaXMg
bWVhbnMgdGhhdCB0aGUgcmlzay9jaGFuY2UgdGhhdCB0d28gdmFsaWQgY2VydGlmaWNhdGVzLCBz
aWduZWQgd2l0aCBzYWZlIHNpZ25hdHVyZSBhbGdvcml0aG1zLCB3aWxsIGJ5IGNoYW5jZSBwcm9k
dWNlIGNvbGxpc2lvbnMsIGlzIHN0aWxsIHRvdGFsbHkgbmVnbGlnaWJsZS48QlI+PEJSPldoZXJl
IGFtIEkgdGhpbmtpbmcgd3JvbmcgaGVyZT88QlI+PEJSPi9TdGVmYW48QlI+PEJSPjxCUj48QlI+
T24gMy8xNC8wOSA4OjAwIFBNLCAiSmltIFNjaGFhZCIgJmx0OzxBIGhyZWY9ImlldGZAYXVndXN0
Y2VsbGFycy5jb20iIHRhcmdldD1ibGFuayA+aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbTwvYT4mZ3Q7
IHdyb3RlOjxCUj48Rk9OVCBDT0xPUj0iIzFmNDk3ZCI+U3RlZmFuLDxCUj4mbmJzcDs8QlI+VGhl
IHF1ZXN0aW9uIHlvdSBuZWVkIHRvIGJlIGFza2luZyBpcyCWIERvIHlvdSBiZWxpZXZlIHRoYXQg
U0hBLTEgd2lsbCBiZSBicm9rZW4gb25lIGRheSwgYW5kIGlmIGl0IGlzIGJyb2tlbiBkbyB5b3Ug
d2FudCB0byBoYXZlIGluIHBsYWNlIGEgc29sdXRpb24gdG8gZGVhbCB3aXRoIGl0LjxCUj4mbmJz
cDs8QlI+SmltPEJSPiZuYnNwOzxCUj4mbmJzcDs8QlI+PC9GT05UPjxCUj48L1NQQU4+PC9GT05U
PjxGT05UIFNJWkU9IjIiPjxGT05UIEZBQ0U9IlRhaG9tYSwgVmVyZGFuYSwgSGVsdmV0aWNhLCBB
cmlhbCI+PFNQQU4gPjxCPkZyb206PC9CPiA8QSBocmVmPSJvd25lci1pZXRmLXBraXhAbWFpbC5p
bWMub3JnIiB0YXJnZXQ9YmxhbmsgPm93bmVyLWlldGYtcGtpeEBtYWlsLmltYy5vcmc8L2E+IFs8
QSBocmVmPSJtYWlsdG86b3duZXItaWV0Zi1wa2l4QG1haWwuaW1jLm9yZyIgdGFyZ2V0PWJsYW5r
ID5tYWlsdG86b3duZXItaWV0Zi1wa2l4QG1haWwuaW1jLm9yZzwvYT5dIDxCPk9uIEJlaGFsZiBP
ZiA8L0I+U3RlZmFuIFNhbnRlc3NvbjxCUj48Qj5TZW50OjwvQj4gU2F0dXJkYXksIE1hcmNoIDE0
LCAyMDA5IDc6MDYgQU08QlI+PEI+VG86PC9CPiBJRVRGLXBraXg8QlI+PEI+U3ViamVjdDo8L0I+
IERvIHdlIG5lZWQgcmZjIDMxNjFiaXM/PEJSPjwvU1BBTj48L0ZPTlQ+PC9GT05UPjxGT05UIEZB
Q0U9IlRpbWVzIE5ldyBSb21hbiI+PFNQQU4gPjxCUj48L1NQQU4+PC9GT05UPjxGT05UIEZBQ0U9
IkNhbGlicmksIFZlcmRhbmEsIEhlbHZldGljYSwgQXJpYWwiPjxTUEFOID5UaGUgbW9yZSBJIGxv
b2sgaW50byB0aGlzIHRoZSBtb3JlIEkgZ2V0IHRvIGRvdWJ0IHRoYXQgd2UgYWN0dWFsbHkgbmVl
ZCAzMTYxYmlzLjxCUj48QlI+VGhlIG9ubHkgc3Vic3RhbnRpYWwgdGVjaG5pY2FsIGNoYW5nZSBJ
IGtub3cgb2YgaXMgdG8gYWxsb3cgdGhlIHVwZGF0ZWQgRVNTIGNlcnRJRHYyIHRvIGJlIHVzZWQg
dG8gaWRlbnRpZnkgdGhlIHNpZ25lcpJzIGNlcnRpZmljYXRlIElGIHRoZSBUU0EgZm9yIHNvbWUg
cmVhc29uIGNob29zZSB0byBoYXNoIGl0cyBjZXJ0aWZpY2F0ZSB3aXRoIGFub3RoZXIgaGFzaCB0
aGVuIFNIQS0xLjxCUj48QlI+VGhlIHJhdGlvbmFsZSBmb3IgdGhlIGNlcnRJRCBpZGVudGlmaWVy
IGlzIGdpdmVuIGluIHNlY3Rpb24gNSBvZiBSRkMgMjYzNCBhbmQgZGVzY3JpYmVzIGF0dGFja3Mg
d2hlcmUgb25lIHZhbGlkIGNlcnRpZmljYXRlIGlzIHN1YnN0aXR1dGVkIGJ5IGFub3RoZXIgdmFs
aWQgY2VydGlmaWNhdGUgKGV4Y2VvcHQgZm9yIHNvbWUgRG9TIGNhc2UgdGhhdCBJIGRvbpJ0IHRo
aW5rIGlzIHJlbGV2YW50IGhlcmUpLjxCUj5Ob3cgSSBoYXZlIHRvIGFzayBteXNlbGYuIEhvdyBs
aWtlbHkgaXMgaXQgdGhhdCBhIGxlZ2l0aW1hdGUgVFNBIGhhcyAyICZuYnNwO29yIG1vcmUgbGVn
aXRpbWF0ZSBjZXJ0aWZpY2F0ZXMgZm9yIHRoZSBzYW1lIHB1YmxpYyBrZXkgd2l0aCBjb25mbGlj
dGluZyBpbmZvcm1hdGlvbiAob3IgaW5mb3JtYXRpb24gZGlmZmVyZW50IGVub3VnaCB0byBhY3R1
YWxseSBoYXZlIGEgc2VjdXJpdHkgaW1wYWN0KSBBTkQgd2hlcmUgdGhlIGhhc2ggb2YgdGhlc2Ug
Y2VydGlmaWNhdGVzIHByb2R1Y2UgYSBTSEEtMSBjb2xsaXNpb24uPEJSPjxCUj5UaGlzIGlzIG5v
dCB0aGUgcHJldmlvdXNseSBkaXNjdXNzZWQgY2VydGlmaWNhdGUgY29sbGlzaW9uIGF0dGFjayB1
c2luZyB3ZWFrIGNlcnRpZmljYXRlIHNpZ25pbmcgaGFzaCwgd2hlcmUgSSBtYXkgcHJlcGFyZSBh
IGNlcnRpZmljYXRlIHJlcXVlc3QgaW4gYSB3YXkgd2hlcmUgSSBjYW4gZm9vbCB0aGUgQ0EgdG8g
cHJvZHVjZSB0d28gdmFsaWQgY2VydGlmaWNhdGVzIHdpdGggdGhlIHNhbWUgY2VydGlmaWNhdGUg
c2lnbmF0dXJlLiBJZiBJIHdvdWxkIHVzZSB0aGF0IHRlY2huaXF1ZSBJIHdvdWxkIGhhdmUgdG8g
ZmluZCBhIHdheSB0byBwcmVwYXJlIHRoZSBUU0EgY2VydGlmaWNhdGUgcmVxdWVzdHMsIHRoZSBU
U0EgY2VydGlmaWNhdGUgaGFzaCBuZWVkIHRvIGJlIHdlYWsgaW4gYWRkaXRpb24gdG8gdGhlIGNl
cnRJRCBoYXNoIEFORCBJbiBhZGRpdGlvbiB0byB0aGF0IHRoZSBjb21wbGV0ZSBjZXJ0aWZpY2F0
ZXMgKG5vdCBvbmx5IHRoZSB0byBiZSBzaWduZWQgcGFydCkgbmVlZCB0byBjcmVhdGUgYSBoYXNo
IGNvbGxpc2lvbiB3aGVuIGNvbXB1dGluZyB0aGUgY2VydElELjxCUj48QlI+U28sIG15IGZpcnN0
IHF1ZXN0aW9uIGlzIGlmIHRoaXMgY2hhbmdlIGFkZHJlc3NlcyBhbnkgcmVhbCBzZWN1cml0eSB0
aHJlYXQ/PEJSPkNhbiBzb21lb25lIHByb3ZpZGUgYSByZWFzb25hYmxlIHRocmVhdCBhbmFseXNp
cz88QlI+QW5kIGNvbnNlcXVlbnRseSwgaWYgdGhlcmUgYXJlIG5vIHJlYWwgdGhyZWF0cyB0byBz
b2x2ZSwgZG9lcyB0aGlzIHVwZGF0ZSBtb3RpdmF0ZSB0aGUgcG90ZW50aWFsIGludGVyb3BlcmFi
aWxpdHkgaXNzdWVzIHRoYXQgbWlnaHQgYmUgdGhlIHJlc3VsdCBvZiBieSBhbGxvd2luZyBFU1Mg
Q2VydElEdjIgaW4gdGltZSBzdGFtcCB0b2tlbnM/PEJSPjxCUj48QlI+SWYgd2UgZG8gY29tZSB0
byB0aGUgY29uY2x1c2lvbiB0aGF0IGl0IGlzIHdvcnRoIGl0LCB0aGVuIHdoeSBub3QganVzdCBj
cmVhdGUgYW4gdXBkYXRlIFJGQyB1cGRhdGluZyBSRkMgMzE2MSBpbnN0ZWFkIG9mIHJlcGxhY2lu
ZyBpdD88QlI+PEJSPlRoaXMgdXBkYXRlIGRvZXMgbm90IGNoYW5nZSBhbnkgYml0cyBvbiB0aGUg
d2lyZSBmb3IgaW1wbGVtZW50YXRpb25zIG9mIHRoZSBjdXJyZW50IHByb3RvY29sLiBUaGUgb25s
eSB0aGluZyBpdCBkb2VzIGlzIHRvIGFkZCBhbiBvcHRpb24gdG8gdXNlIEVTUyBjZXJ0SUR2MiBJ
RiBTSEEtMSBpcyBub3QgdXNlZCBhcyBoYXNoIHRvIGlkZW50aWZ5IHRoZSBUU0GScyBjZXJ0aWZp
Y2F0ZS48QlI+VGhpcyBzZWVtcyBsaWtlIGEgcGVyZmVjdCB0aGluZyBmb3IgYW4gdXBkYXRlIFJG
Qy4gQW5vdGhlciBhcmd1bWVudCBpcyB0aGF0IHRoZSBvbGQgZWRpdG9ycyB0aGF0IHJpZ2h0ZnVs
bHkgc2hvdWxkIGhhdmUgdGhlIGNyZWRpdCBmb3IgUkZDIDMxNjEgYXJlIG5vdCBwYXJ0IG9mIHRo
aXMgbWlub3IgYW1lbmRtZW50IGJ1dCBhcmUgY29tcGxldGVseSBlcmFzZWQgZnJvbSB0aGUgdXBk
YXRlLiBUaGF0IG1heSBiZSByZWFzb25hYmxlIGlmIHRoZSBjaGFuZ2VzIGFyZSBtYWpvciBidXQg
SZJtIG5vdCBzbyBzdXJlIGluIHRoaXMgY2FzZS48L1NQQU4+PC9GT05UPjxQIEFMSUdOPWNlbnRl
cj48Rk9OVCBGQUNFPSJDYWxpYnJpLCBWZXJkYW5hLCBIZWx2ZXRpY2EsIEFyaWFsIj48U1BBTiA+
PC9TUEFOPjwvRk9OVD48UD48Rk9OVCBGQUNFPSJDYWxpYnJpLCBWZXJkYW5hLCBIZWx2ZXRpY2Es
IEFyaWFsIj48U1BBTiA+PEJSPjwvU1BBTj48L0ZPTlQ+PC9QPjwvQkxPQ0tRVU9URT48L0JMT0NL
UVVPVEU+PC9CTE9DS1FVT1RFPjwvRk9OVD4=



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 n2HEUJ53051949 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Mar 2009 07:30:19 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2HEUJ07051948; Tue, 17 Mar 2009 07:30:19 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from s87.loopia.se (s87.loopia.se [194.9.95.112]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2HEU5DL051931 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 17 Mar 2009 07:30:17 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 97617 invoked from network); 17 Mar 2009 14:30:09 -0000
Received: from s34.loopia.se (HELO s128.loopia.se) ([194.9.94.70]) (envelope-sender <[e-mail]>) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for <[e-mail]>; 17 Mar 2009 14:30:09 -0000
Received: (qmail 26187 invoked from network); 17 Mar 2009 14:30:02 -0000
Received: from gw-guest.ac.upc.edu (HELO [192.168.50.195]) ([e-mail]@[147.83.30.131]) (envelope-sender <[e-mail]>) by s128.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <[e-mail]>; 17 Mar 2009 14:30:02 -0000
User-Agent: Microsoft-Entourage/12.15.0.081119
Date: Tue, 17 Mar 2009 15:29:57 +0100
Subject: Re: Do we need rfc 3161bis?
From: Stefan Santesson <[e-mail]>
To: Stefan Santesson <[e-mail]>, Jim Schaad <[e-mail]>, "'Santosh Chokhani'" <[e-mail]>, "'IETF-pkix'" <[e-mail]>
Message-ID: <[e-mail]>
Thread-Topic: Do we need rfc 3161bis?
Thread-Index: Acmkrf0j+yb7f0QChUOhT/ms/PsBpAAKRABQAAxc04EAWKrEYAAKV4S0AABPAXAAAX+tawAHFfSwAAIvI0AAAxzVfAAP4yA+
In-Reply-To: <[e-mail]>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3320148603_11583013"
Sender: [e-mail]
Precedence: 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 message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3320148603_11583013
Content-type: text/plain;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

I had an informal face2face meeting here in Barcelona between me, Julien
Stern and Denis Pinkas.

I will dare myself to write down some conclusion and trust Julien and Denis
to correct me if they disagree.

1. There is no known threat for which the essCertIDv2 is needed.
2. It is extremely hard to prove that there will not be any threat or attac=
k
made up in the future where essCertIDv2 would be useful
3. As essCertIDv2 is standardized and has been a focus for EU work in
relation to time stamps, it is probably reasonable to allow essCertIDv2 to
be used with RFC 3161 time stamps.
4. For the sake of specifying the time stamp protocol, we only need one
named entity representing the signer of the time stamp token (currently TSA
in RFC 3161).=20
5. There is currently a disconnect between terminology in RFC 3161 and RFC
3628 (the policy document)
6. A solution that would satisfy all parties of this meeting would be to
write an update RFC (not a replacement as current proposal). This update RF=
C
would add the option to use essCertIDv2 AND would include an informational
Annex  explaining the basic difference in terminology between RFC 3161 and
RFC 3628. Most importantly this informational text would explain that TSU i=
n
the policy document corresponds to TSA in the protocol.

I support these conclusions.

/Stefan



On 3/17/09 7:55 AM, "Stefan Santesson" <[e-mail]> wrote:

> Exactly as Jim says. Maybe we should add further that this is a bout
> substituting one valid TSA certificate with another valid TSA certificate
> since the TSA for some reason has two TSA certificates for the same publi=
c key
> which when hashed, have the same SHA-1 hash.
>=20
> /Stefan
>=20
>=20
> On 3/17/09 6:26 AM, "Jim Schaad" <[e-mail]> wrote:
>=20
>> The attack we are looking at is a certificate substitution attack with t=
he
>> TSA certificate being changed to a different certificate.  This is not
>> question of trusting the TSA itself.  Unless of course it is the one try=
ing
>> the attack for some reason.
>> =20
>> =20
>>=20
>> From: Santosh Chokhani [mailto:[e-mail]]
>> Sent: Monday, March 16, 2009 9:25 PM
>> To: Stefan Santesson; Jim Schaad; IETF-pkix
>> Subject: RE: Do we need rfc 3161bis?
>> =20
>> I have not followed the thread well.  But, are we losing forest for the =
trees
>> here?
>> =20
>> Do we not trust the TSA enough to not create collision attack?
>>> =20
>>>=20
>>>=20
>>> From: [e-mail] [mailto:[e-mail]=
] On
>>> Behalf Of Stefan Santesson
>>> Sent: Monday, March 16, 2009 9:01 PM
>>> To: Jim Schaad; 'IETF-pkix'
>>> Subject: Re: Do we need rfc 3161bis?
>>> OK,
>>>=20
>>> The prefix attack only works, as you say yourself, on the tbs bits to c=
reate
>>> two certs with the same signature. This is ONLY possible if the signatu=
re
>>> hash algorithm is broken. The hash in the essCertID is calculated on th=
e
>>> complete certificates (including signatures), not only the tbs bits.
>>> Thus, the prefix attack is pretty useless if you have a large chunk of
>>> random bits in the end that is bound to be different for each cert. And=
 they
>>> will be different IF the signature algorithm of the certificates is not
>>> broken.
>>>=20
>>> The second question, sorry for missing it, is broader than just RFC 316=
1bis.
>>>=20
>>> I think we have many protocols, where collision resistance is not an is=
sue,
>>> where we don=B9t provide algorithm agility for all uses of SHA-1. I do th=
ink
>>> there is a use of SHA-1 in OCSP that is not part of the current update
>>> proposal and there is currently a similar discussion in TLS where stron=
g
>>> arguments are raised against adding algorithm negotiation complexity wh=
en
>>> collision resistance is not a security issue. This problem is more poli=
tical
>>> than technical. But if there is any reason to do this, it probably is f=
or
>>> political reasons, so your point is valid.
>>>=20
>>> /Stefan
>>>=20
>>> On 3/17/09 1:20 AM, "Jim Schaad" <[e-mail]> wrote:
>>> Stefan,
>>> =20
>>> First I don=B9t know that I agree.  I think that the entirety of your
>>> protection is actually given by the leading sequence/length bytes.  The
>>> object is to prevent a prefix attack.  One can create a prefix attack
>>> against the TBS bytes =AD leading to identical signatures for both versio=
ns of
>>> the certificate.  However adding the leading sequence/length octets pro=
bably
>>> means that you need to have two different prefix attacks =AD a much harde=
r
>>> condition, but maybe doable.
>>> =20
>>> However I don=B9t believe that you addressed my second point at all.  Tha=
t is
>>> people completely migrate away from SHA-1 because it is considered to b=
e
>>> broken.
>>> =20
>>> jim
>>> =20
>>>=20
>>> From: Stefan Santesson [mailto:[e-mail]]
>>> Sent: Monday, March 16, 2009 5:09 PM
>>> To: Jim Schaad; 'IETF-pkix'
>>> Subject: Re: Do we need rfc 3161bis?
>>>=20
>>> Jim,
>>>=20
>>> You ask,
>>> The question becomes can I create two certificates that can have the sa=
me
>>> hash, NOT will it happen by chance.
>>>=20
>>> I totally agree. And I don=B9t think you can.
>>>=20
>>> Not if the two certificates are signed with a good signature algorithm.
>>> If these certificates are signed with a bad signature algorithm that al=
lows
>>> different certificates to share the same signature, then all bets are o=
ff
>>> anyway.
>>>=20
>>> If the signature algorithms are good, then the signatures of these
>>> certificates will be composed of a substantial amount of vastly differe=
nt
>>> bits. As the signature algorithm is good, you can=B9t control the bits of
>>> these signatures in any meaningful way, leaving you basically with a tr=
ial
>>> and error approach. That even if SHA-1 is broken.
>>>=20
>>> /Stefan
>>>=20
>>>=20
>>> On 3/16/09 8:17 PM, "Jim Schaad" <[e-mail]> wrote:
>>> Stefan,
>>> =20
>>> The property that is being used is not the randomness property, it is a
>>> collision property.  (Or more specifically resistance to collisions.)  =
 The
>>> question becomes can I create two certificates that can have the same h=
ash,
>>> NOT will it happen by chance.   If I can do so then I have a successful
>>> attack at this point.
>>> =20
>>> However one needs to assume that if SHA-1 is significantly broken, peop=
le
>>> will be removing it from the trusted algorithm list and would then need=
 a
>>> migration path of what to put in place of the current SHA-1 attribute. =
 This
>>> is the main reason for doing the update.
>>> =20
>>> jim
>>> =20
>>>=20
>>> From: [e-mail] [mailto:[e-mail]=
] On
>>> Behalf Of Stefan Santesson
>>> Sent: Saturday, March 14, 2009 5:54 PM
>>> To: Jim Schaad; 'IETF-pkix'
>>> Subject: Re: Do we need rfc 3161bis?
>>>=20
>>> Yes, a good question indeed.
>>>=20
>>> Say that SHA-1 is completely broken in the sense that we can produce
>>> collisions at will, of all sorts and forms.
>>> Say also that we have a few valid TSA certificates issued for the same =
key
>>> pair, signed using good hash algorithms (or else all bets are off anywa=
y).
>>>=20
>>> The randomness properties of SHA-1 will remain intact even if SHA-1 is
>>> broken. This means that the risk/chance that two valid certificates, si=
gned
>>> with safe signature algorithms, will by chance produce collisions, is s=
till
>>> totally negligible.
>>>=20
>>> Where am I thinking wrong here?
>>>=20
>>> /Stefan
>>>=20
>>>=20
>>>=20
>>> On 3/14/09 8:00 PM, "Jim Schaad" <[e-mail]> wrote:
>>> Stefan,
>>> =20
>>> The question you need to be asking is =AD Do you believe that SHA-1 will =
be
>>> broken one day, and if it is broken do you want to have in place a solu=
tion
>>> to deal with it.
>>> =20
>>> Jim
>>> =20
>>> =20
>>>=20
>>> From: [e-mail] [mailto:[e-mail]=
] On
>>> Behalf Of Stefan Santesson
>>> Sent: Saturday, March 14, 2009 7:06 AM
>>> To: IETF-pkix
>>> Subject: Do we need rfc 3161bis?
>>>=20
>>> The more I look into this the more I get to doubt that we actually need
>>> 3161bis.
>>>=20
>>> The only substantial technical change I know of is to allow the updated=
 ESS
>>> certIDv2 to be used to identify the signer=B9s certificate IF the TSA for=
 some
>>> reason choose to hash its certificate with another hash then SHA-1.
>>>=20
>>> The rationale for the certID identifier is given in section 5 of RFC 26=
34
>>> and describes attacks where one valid certificate is substituted by ano=
ther
>>> valid certificate (exceopt for some DoS case that I don=B9t think is rele=
vant
>>> here).
>>> Now I have to ask myself. How likely is it that a legitimate TSA has 2 =
 or
>>> more legitimate certificates for the same public key with conflicting
>>> information (or information different enough to actually have a securit=
y
>>> impact) AND where the hash of these certificates produce a SHA-1 collis=
ion.
>>>=20
>>> This is not the previously discussed certificate collision attack using=
 weak
>>> certificate signing hash, where I may prepare a certificate request in =
a way
>>> where I can fool the CA to produce two valid certificates with the same
>>> certificate signature. If I would use that technique I would have to fi=
nd a
>>> way to prepare the TSA certificate requests, the TSA certificate hash n=
eed
>>> to be weak in addition to the certID hash AND In addition to that the
>>> complete certificates (not only the to be signed part) need to create a=
 hash
>>> collision when computing the certID.
>>>=20
>>> So, my first question is if this change addresses any real security thr=
eat?
>>> Can someone provide a reasonable threat analysis?
>>> And consequently, if there are no real threats to solve, does this upda=
te
>>> motivate the potential interoperability issues that might be the result=
 of
>>> by allowing ESS CertIDv2 in time stamp tokens?
>>>=20
>>>=20
>>> If we do come to the conclusion that it is worth it, then why not just
>>> create an update RFC updating RFC 3161 instead of replacing it?
>>>=20
>>> This update does not change any bits on the wire for implementations of=
 the
>>> current protocol. The only thing it does is to add an option to use ESS
>>> certIDv2 IF SHA-1 is not used as hash to identify the TSA=B9s certificate=
.
>>> This seems like a perfect thing for an update RFC. Another argument is =
that
>>> the old editors that rightfully should have the credit for RFC 3161 are=
 not
>>> part of this minor amendment but are completely erased from the update.=
 That
>>> may be reasonable if the changes are major but I=B9m not so sure in this =
case.
>>>=20


--B_3320148603_11583013
Content-type: text/html;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Re: Do we need rfc 3161bis?</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt=
'>I had an informal face2face meeting here in Barcelona between me, Julien S=
tern and Denis Pinkas.<BR>
<BR>
I will dare myself to write down some conclusion and trust Julien and Denis=
 to correct me if they disagree.<BR>
<BR>
</SPAN></FONT><OL><LI><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN=
 STYLE=3D'font-size:11pt'>There is no known threat for which the essCertIDv2 i=
s needed.
</SPAN></FONT><LI><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STY=
LE=3D'font-size:11pt'>It is extremely hard to prove that there will not be any=
 threat or attack made up in the future where essCertIDv2 would be useful
</SPAN></FONT><LI><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STY=
LE=3D'font-size:11pt'>As essCertIDv2 is standardized and has been a focus for =
EU work in relation to time stamps, it is probably reasonable to allow essCe=
rtIDv2 to be used with RFC 3161 time stamps.
</SPAN></FONT><LI><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STY=
LE=3D'font-size:11pt'>For the sake of specifying the time stamp protocol, we o=
nly need one named entity representing the signer of the time stamp token (c=
urrently TSA in RFC 3161).
</SPAN></FONT><LI><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STY=
LE=3D'font-size:11pt'>There is currently a disconnect between terminology in R=
FC 3161 and RFC 3628 (the policy document)
</SPAN></FONT><LI><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STY=
LE=3D'font-size:11pt'>A solution that would satisfy all parties of this meetin=
g would be to write an update RFC (not a replacement as current proposal). T=
his update RFC would add the option to use essCertIDv2 AND would include an =
informational Annex &nbsp;explaining the basic difference in terminology bet=
ween RFC 3161 and RFC 3628. Most importantly this informational text would e=
xplain that TSU in the policy document corresponds to TSA in the protocol. <=
BR>
</SPAN></FONT></OL><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN ST=
YLE=3D'font-size:11pt'><BR>
I support these conclusions.<BR>
<BR>
/Stefan<BR>
<BR>
<BR>
<BR>
On 3/17/09 7:55 AM, &quot;Stefan Santesson&quot; &lt;<a href=3D"stefans@exmsf=
t.com">[e-mail]</a>&gt; wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><=
SPAN STYLE=3D'font-size:11pt'>Exactly as Jim says. Maybe we should add further=
 that this is a bout substituting one valid TSA certificate with another val=
id TSA certificate since the TSA for some reason has two TSA certificates fo=
r the same public key which when hashed, have the same SHA-1 hash.<BR>
<BR>
/Stefan<BR>
<BR>
<BR>
On 3/17/09 6:26 AM, &quot;Jim Schaad&quot; &lt;<a href=3D"ietf@augustcellars.=
com">[e-mail]</a>&gt; wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><=
SPAN STYLE=3D'font-size:11pt'><FONT COLOR=3D"#1F497D">The attack we are looking =
at is a certificate substitution attack with the TSA certificate being chang=
ed to a different certificate. &nbsp;This is not &nbsp;question of trusting =
the TSA itself. &nbsp;Unless of course it is the one trying the attack for s=
ome reason.<BR>
&nbsp;<BR>
&nbsp;<BR>
</FONT><BR>
</SPAN></FONT><FONT SIZE=3D"2"><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:10pt'><B>From:</B> Santosh Chokhani [<a href=3D"mailto=
:[e-mail]">mailto:[e-mail]</a>] <BR>
<B>Sent:</B> Monday, March 16, 2009 9:25 PM<BR>
<B>To:</B> Stefan Santesson; Jim Schaad; IETF-pkix<BR>
<B>Subject:</B> RE: Do we need rfc 3161bis?<BR>
</SPAN></FONT></FONT><FONT FACE=3D"Times New Roman"><SPAN STYLE=3D'font-size:12=
pt'> <BR>
</SPAN></FONT><FONT COLOR=3D"#0000FF"><FONT SIZE=3D"2"><FONT FACE=3D"Arial"><SPAN=
 STYLE=3D'font-size:10pt'>I have not followed the thread well. &nbsp;But, are =
we losing forest for the trees here?<BR>
</SPAN></FONT></FONT></FONT><FONT FACE=3D"Times New Roman"><SPAN STYLE=3D'font-=
size:12pt'> <BR>
</SPAN></FONT><FONT COLOR=3D"#0000FF"><FONT SIZE=3D"2"><FONT FACE=3D"Arial"><SPAN=
 STYLE=3D'font-size:10pt'>Do we not trust the TSA enough to not create collisi=
on attack?<BR>
</SPAN></FONT></FONT></FONT><BLOCKQUOTE><FONT FACE=3D"Times New Roman"><SPAN =
STYLE=3D'font-size:12pt'>=20
</SPAN></FONT>
<P ALIGN=3DCENTER>
<FONT FACE=3D"Times New Roman"><SPAN STYLE=3D'font-size:12pt'><HR ALIGN=3DCENTER =
SIZE=3D"2" WIDTH=3D"100%"></SPAN></FONT>
<P>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt=
'><BR>
</SPAN></FONT><FONT SIZE=3D"2"><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:10pt'><B>From:</B> <a href=3D"[e-mail]=
.org">[e-mail]</a> [<a href=3D"mailto:owner-ietf-pkix@mail=
.imc.org">mailto:[e-mail]</a>] <B>On Behalf Of </B>Stefa=
n Santesson<BR>
<B>Sent:</B> Monday, March 16, 2009 9:01 PM<BR>
<B>To:</B> Jim Schaad; 'IETF-pkix'<BR>
<B>Subject:</B> Re: Do we need rfc 3161bis?<BR>
</SPAN></FONT></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN =
STYLE=3D'font-size:11pt'>OK,<BR>
<BR>
The prefix attack only works, as you say yourself, on the tbs bits to creat=
e two certs with the same signature. This is ONLY possible if the signature =
hash algorithm is broken. The hash in the essCertID is calculated on the com=
plete certificates (including signatures), not only the tbs bits.<BR>
Thus, the prefix attack is pretty useless if you have a large chunk of rand=
om bits in the end that is bound to be different for each cert. And they wil=
l be different IF the signature algorithm of the certificates is not broken.=
<BR>
<BR>
The second question, sorry for missing it, is broader than just RFC 3161bis=
.<BR>
<BR>
I think we have many protocols, where collision resistance is not an issue,=
 where we don&#8217;t provide algorithm agility for all uses of SHA-1. I do =
think there is a use of SHA-1 in OCSP that is not part of the current update=
 proposal and there is currently a similar discussion in TLS where strong ar=
guments are raised against adding algorithm negotiation complexity when coll=
ision resistance is not a security issue. This problem is more political tha=
n technical. But if there is any reason to do this, it probably is for polit=
ical reasons, so your point is valid.<BR>
<BR>
/Stefan<BR>
<BR>
On 3/17/09 1:20 AM, &quot;Jim Schaad&quot; &lt;<a href=3D"ietf@augustcellars.=
com">[e-mail]</a>&gt; wrote:<BR>
<FONT COLOR=3D"#1F497D">Stefan,<BR>
&nbsp;<BR>
First I don&#8217;t know that I agree. &nbsp;I think that the entirety of y=
our protection is actually given by the leading sequence/length bytes. &nbsp=
;The object is to prevent a prefix attack. &nbsp;One can create a prefix att=
ack against the TBS bytes &#8211; leading to identical signatures for both v=
ersions of the certificate. &nbsp;However adding the leading sequence/length=
 octets probably means that you need to have two different prefix attacks &#=
8211; a much harder condition, but maybe doable.<BR>
&nbsp;<BR>
However I don&#8217;t believe that you addressed my second point at all. &n=
bsp;That is people completely migrate away from SHA-1 because it is consider=
ed to be broken.<BR>
&nbsp;<BR>
jim<BR>
&nbsp;<BR>
</FONT><BR>
</SPAN></FONT><FONT SIZE=3D"2"><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:10pt'><B>From:</B> Stefan Santesson [<a href=3D"mailto=
:[e-mail]">mailto:[e-mail]</a>] <BR>
<B>Sent:</B> Monday, March 16, 2009 5:09 PM<BR>
<B>To:</B> Jim Schaad; 'IETF-pkix'<BR>
<B>Subject:</B> Re: Do we need rfc 3161bis?<BR>
</SPAN></FONT></FONT><FONT FACE=3D"Times New Roman"><SPAN STYLE=3D'font-size:12=
pt'><BR>
</SPAN></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'=
font-size:11pt'>Jim,<BR>
<BR>
You ask,<BR>
<FONT COLOR=3D"#1E487C">The question becomes can I create two certificates th=
at can have the same hash, NOT will it happen by chance.<BR>
</FONT><BR>
I <B>totally</B> agree. And I don&#8217;t think you can.<BR>
<BR>
Not if the two certificates are signed with a good signature algorithm. <BR=
>
If these certificates are signed with a bad signature algorithm that allows=
 different certificates to share the same signature, then all bets are off a=
nyway.<BR>
<BR>
If the signature algorithms are good, then the signatures of these certific=
ates will be composed of a substantial amount of vastly different bits. As t=
he signature algorithm is good, you can&#8217;t control the bits of these si=
gnatures in any meaningful way, leaving you basically with a trial and error=
 approach. That even if SHA-1 is broken.<BR>
<BR>
/Stefan<BR>
<BR>
<BR>
On 3/16/09 8:17 PM, &quot;Jim Schaad&quot; &lt;<a href=3D"ietf@augustcellars.=
com">[e-mail]</a>&gt; wrote:<BR>
<FONT COLOR=3D"#1F497D">Stefan,<BR>
&nbsp;<BR>
The property that is being used is not the randomness property, it is a col=
lision property. &nbsp;(Or more specifically resistance to collisions.) &nbs=
p;&nbsp;The question becomes can I create two certificates that can have the=
 same hash, NOT will it happen by chance. &nbsp;&nbsp;If I can do so then I =
have a successful attack at this point.<BR>
&nbsp;<BR>
However one needs to assume that if SHA-1 is significantly broken, people w=
ill be removing it from the trusted algorithm list and would then need a mig=
ration path of what to put in place of the current SHA-1 attribute. &nbsp;Th=
is is the main reason for doing the update.<BR>
&nbsp;<BR>
jim<BR>
&nbsp;<BR>
</FONT><BR>
</SPAN></FONT><FONT SIZE=3D"2"><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:10pt'><B>From:</B> <a href=3D"[e-mail]=
.org">[e-mail]</a> [<a href=3D"mailto:owner-ietf-pkix@mail=
.imc.org">mailto:[e-mail]</a>] <B>On Behalf Of </B>Stefa=
n Santesson<BR>
<B>Sent:</B> Saturday, March 14, 2009 5:54 PM<BR>
<B>To:</B> Jim Schaad; 'IETF-pkix'<BR>
<B>Subject:</B> Re: Do we need rfc 3161bis?<BR>
</SPAN></FONT></FONT><FONT FACE=3D"Times New Roman"><SPAN STYLE=3D'font-size:12=
pt'><BR>
</SPAN></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'=
font-size:11pt'>Yes, a good question indeed.<BR>
<BR>
Say that SHA-1 is completely broken in the sense that we can produce collis=
ions at will, of all sorts and forms.<BR>
Say also that we have a few valid TSA certificates issued for the same key =
pair, signed using good hash algorithms (or else all bets are off anyway).<B=
R>
<BR>
The randomness properties of SHA-1 will remain intact even if SHA-1 is brok=
en. This means that the risk/chance that two valid certificates, signed with=
 safe signature algorithms, will by chance produce collisions, is still tota=
lly negligible.<BR>
<BR>
Where am I thinking wrong here?<BR>
<BR>
/Stefan<BR>
<BR>
<BR>
<BR>
On 3/14/09 8:00 PM, &quot;Jim Schaad&quot; &lt;<a href=3D"ietf@augustcellars.=
com">[e-mail]</a>&gt; wrote:<BR>
<FONT COLOR=3D"#1F497D">Stefan,<BR>
&nbsp;<BR>
The question you need to be asking is &#8211; Do you believe that SHA-1 wil=
l be broken one day, and if it is broken do you want to have in place a solu=
tion to deal with it.<BR>
&nbsp;<BR>
Jim<BR>
&nbsp;<BR>
&nbsp;<BR>
</FONT><BR>
</SPAN></FONT><FONT SIZE=3D"2"><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:10pt'><B>From:</B> <a href=3D"[e-mail]=
.org">[e-mail]</a> [<a href=3D"mailto:owner-ietf-pkix@mail=
.imc.org">mailto:[e-mail]</a>] <B>On Behalf Of </B>Stefa=
n Santesson<BR>
<B>Sent:</B> Saturday, March 14, 2009 7:06 AM<BR>
<B>To:</B> IETF-pkix<BR>
<B>Subject:</B> Do we need rfc 3161bis?<BR>
</SPAN></FONT></FONT><FONT FACE=3D"Times New Roman"><SPAN STYLE=3D'font-size:12=
pt'><BR>
</SPAN></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'=
font-size:11pt'>The more I look into this the more I get to doubt that we ac=
tually need 3161bis.<BR>
<BR>
The only substantial technical change I know of is to allow the updated ESS=
 certIDv2 to be used to identify the signer&#8217;s certificate IF the TSA f=
or some reason choose to hash its certificate with another hash then SHA-1.<=
BR>
<BR>
The rationale for the certID identifier is given in section 5 of RFC 2634 a=
nd describes attacks where one valid certificate is substituted by another v=
alid certificate (exceopt for some DoS case that I don&#8217;t think is rele=
vant here).<BR>
Now I have to ask myself. How likely is it that a legitimate TSA has 2 &nbs=
p;or more legitimate certificates for the same public key with conflicting i=
nformation (or information different enough to actually have a security impa=
ct) AND where the hash of these certificates produce a SHA-1 collision.<BR>
<BR>
This is not the previously discussed certificate collision attack using wea=
k certificate signing hash, where I may prepare a certificate request in a w=
ay where I can fool the CA to produce two valid certificates with the same c=
ertificate signature. If I would use that technique I would have to find a w=
ay to prepare the TSA certificate requests, the TSA certificate hash need to=
 be weak in addition to the certID hash AND In addition to that the complete=
 certificates (not only the to be signed part) need to create a hash collisi=
on when computing the certID.<BR>
<BR>
So, my first question is if this change addresses any real security threat?=
<BR>
Can someone provide a reasonable threat analysis?<BR>
And consequently, if there are no real threats to solve, does this update m=
otivate the potential interoperability issues that might be the result of by=
 allowing ESS CertIDv2 in time stamp tokens?<BR>
<BR>
<BR>
If we do come to the conclusion that it is worth it, then why not just crea=
te an update RFC updating RFC 3161 instead of replacing it?<BR>
<BR>
This update does not change any bits on the wire for implementations of the=
 current protocol. The only thing it does is to add an option to use ESS cer=
tIDv2 IF SHA-1 is not used as hash to identify the TSA&#8217;s certificate.<=
BR>
This seems like a perfect thing for an update RFC. Another argument is that=
 the old editors that rightfully should have the credit for RFC 3161 are not=
 part of this minor amendment but are completely erased from the update. Tha=
t may be reasonable if the changes are major but I&#8217;m not so sure in th=
is case.
</SPAN></FONT>
<P ALIGN=3DCENTER>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt=
'>
</SPAN></FONT>
<P>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt=
'><BR>
</SPAN></FONT></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE>
</BODY>
</HTML>


--B_3320148603_11583013--




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 n2H6tKWg024235 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Mar 2009 23:55:20 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2H6tKD5024234; Mon, 16 Mar 2009 23:55:20 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from s87.loopia.se (s87.loopia.se [194.9.95.112]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2H6t7Sb024220 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 16 Mar 2009 23:55:19 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 19952 invoked from network); 17 Mar 2009 06:55:08 -0000
Received: from s34.loopia.se (HELO s19.loopia.se) ([194.9.94.70]) (envelope-sender <[e-mail]>) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for <[e-mail]>; 17 Mar 2009 06:55:08 -0000
Received: (qmail 43583 invoked from network); 17 Mar 2009 06:55:05 -0000
Received: from 51.red-80-37-109.staticip.rima-tde.net (HELO [192.168.1.154]) ([e-mail]@[80.37.109.51]) (envelope-sender <[e-mail]>) by s19.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <[e-mail]>; 17 Mar 2009 06:55:05 -0000
User-Agent: Microsoft-Entourage/12.15.0.081119
Date: Tue, 17 Mar 2009 07:55:03 +0100
Subject: Re: Do we need rfc 3161bis?
From: Stefan Santesson <[e-mail]>
To: Jim Schaad <[e-mail]>, "'Santosh Chokhani'" <[e-mail]>, "'IETF-pkix'" <[e-mail]>
Message-ID: <[e-mail]>
Thread-Topic: Do we need rfc 3161bis?
Thread-Index: Acmkrf0j+yb7f0QChUOhT/ms/PsBpAAKRABQAAxc04EAWKrEYAAKV4S0AABPAXAAAX+tawAHFfSwAAIvI0AAAxzVfA==
In-Reply-To: <015001c9a6c0$f5d49090$e17db1b0$@com>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3320121305_10619757"
Sender: [e-mail]
Precedence: 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 message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3320121305_10619757
Content-type: text/plain;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

Exactly as Jim says. Maybe we should add further that this is a bout
substituting one valid TSA certificate with another valid TSA certificate
since the TSA for some reason has two TSA certificates for the same public
key which when hashed, have the same SHA-1 hash.

/Stefan


On 3/17/09 6:26 AM, "Jim Schaad" <[e-mail]> wrote:

> The attack we are looking at is a certificate substitution attack with th=
e TSA
> certificate being changed to a different certificate.  This is not  quest=
ion
> of trusting the TSA itself.  Unless of course it is the one trying the at=
tack
> for some reason.
> =20
> =20
>=20
> From: Santosh Chokhani [mailto:[e-mail]]
> Sent: Monday, March 16, 2009 9:25 PM
> To: Stefan Santesson; Jim Schaad; IETF-pkix
> Subject: RE: Do we need rfc 3161bis?
> =20
> I have not followed the thread well.  But, are we losing forest for the t=
rees
> here?
> =20
> Do we not trust the TSA enough to not create collision attack?
>> =20
>>=20
>>=20
>> From: [e-mail] [mailto:[e-mail]]=
 On
>> Behalf Of Stefan Santesson
>> Sent: Monday, March 16, 2009 9:01 PM
>> To: Jim Schaad; 'IETF-pkix'
>> Subject: Re: Do we need rfc 3161bis?
>> OK,
>>=20
>> The prefix attack only works, as you say yourself, on the tbs bits to cr=
eate
>> two certs with the same signature. This is ONLY possible if the signatur=
e
>> hash algorithm is broken. The hash in the essCertID is calculated on the
>> complete certificates (including signatures), not only the tbs bits.
>> Thus, the prefix attack is pretty useless if you have a large chunk of r=
andom
>> bits in the end that is bound to be different for each cert. And they wi=
ll be
>> different IF the signature algorithm of the certificates is not broken.
>>=20
>> The second question, sorry for missing it, is broader than just RFC 3161=
bis.
>>=20
>> I think we have many protocols, where collision resistance is not an iss=
ue,
>> where we don=B9t provide algorithm agility for all uses of SHA-1. I do thi=
nk
>> there is a use of SHA-1 in OCSP that is not part of the current update
>> proposal and there is currently a similar discussion in TLS where strong
>> arguments are raised against adding algorithm negotiation complexity whe=
n
>> collision resistance is not a security issue. This problem is more polit=
ical
>> than technical. But if there is any reason to do this, it probably is fo=
r
>> political reasons, so your point is valid.
>>=20
>> /Stefan
>>=20
>> On 3/17/09 1:20 AM, "Jim Schaad" <[e-mail]> wrote:
>> Stefan,
>> =20
>> First I don=B9t know that I agree.  I think that the entirety of your
>> protection is actually given by the leading sequence/length bytes.  The
>> object is to prevent a prefix attack.  One can create a prefix attack ag=
ainst
>> the TBS bytes =AD leading to identical signatures for both versions of the
>> certificate.  However adding the leading sequence/length octets probably
>> means that you need to have two different prefix attacks =AD a much harder
>> condition, but maybe doable.
>> =20
>> However I don=B9t believe that you addressed my second point at all.  That=
 is
>> people completely migrate away from SHA-1 because it is considered to be
>> broken.
>> =20
>> jim
>> =20
>>=20
>> From: Stefan Santesson [mailto:[e-mail]]
>> Sent: Monday, March 16, 2009 5:09 PM
>> To: Jim Schaad; 'IETF-pkix'
>> Subject: Re: Do we need rfc 3161bis?
>>=20
>> Jim,
>>=20
>> You ask,
>> The question becomes can I create two certificates that can have the sam=
e
>> hash, NOT will it happen by chance.
>>=20
>> I totally agree. And I don=B9t think you can.
>>=20
>> Not if the two certificates are signed with a good signature algorithm.
>> If these certificates are signed with a bad signature algorithm that all=
ows
>> different certificates to share the same signature, then all bets are of=
f
>> anyway.
>>=20
>> If the signature algorithms are good, then the signatures of these
>> certificates will be composed of a substantial amount of vastly differen=
t
>> bits. As the signature algorithm is good, you can=B9t control the bits of =
these
>> signatures in any meaningful way, leaving you basically with a trial and
>> error approach. That even if SHA-1 is broken.
>>=20
>> /Stefan
>>=20
>>=20
>> On 3/16/09 8:17 PM, "Jim Schaad" <[e-mail]> wrote:
>> Stefan,
>> =20
>> The property that is being used is not the randomness property, it is a
>> collision property.  (Or more specifically resistance to collisions.)   =
The
>> question becomes can I create two certificates that can have the same ha=
sh,
>> NOT will it happen by chance.   If I can do so then I have a successful
>> attack at this point.
>> =20
>> However one needs to assume that if SHA-1 is significantly broken, peopl=
e
>> will be removing it from the trusted algorithm list and would then need =
a
>> migration path of what to put in place of the current SHA-1 attribute.  =
This
>> is the main reason for doing the update.
>> =20
>> jim
>> =20
>>=20
>> From: [e-mail] [mailto:[e-mail]]=
 On
>> Behalf Of Stefan Santesson
>> Sent: Saturday, March 14, 2009 5:54 PM
>> To: Jim Schaad; 'IETF-pkix'
>> Subject: Re: Do we need rfc 3161bis?
>>=20
>> Yes, a good question indeed.
>>=20
>> Say that SHA-1 is completely broken in the sense that we can produce
>> collisions at will, of all sorts and forms.
>> Say also that we have a few valid TSA certificates issued for the same k=
ey
>> pair, signed using good hash algorithms (or else all bets are off anyway=
).
>>=20
>> The randomness properties of SHA-1 will remain intact even if SHA-1 is
>> broken. This means that the risk/chance that two valid certificates, sig=
ned
>> with safe signature algorithms, will by chance produce collisions, is st=
ill
>> totally negligible.
>>=20
>> Where am I thinking wrong here?
>>=20
>> /Stefan
>>=20
>>=20
>>=20
>> On 3/14/09 8:00 PM, "Jim Schaad" <[e-mail]> wrote:
>> Stefan,
>> =20
>> The question you need to be asking is =AD Do you believe that SHA-1 will b=
e
>> broken one day, and if it is broken do you want to have in place a solut=
ion
>> to deal with it.
>> =20
>> Jim
>> =20
>> =20
>>=20
>> From: [e-mail] [mailto:[e-mail]]=
 On
>> Behalf Of Stefan Santesson
>> Sent: Saturday, March 14, 2009 7:06 AM
>> To: IETF-pkix
>> Subject: Do we need rfc 3161bis?
>>=20
>> The more I look into this the more I get to doubt that we actually need
>> 3161bis.
>>=20
>> The only substantial technical change I know of is to allow the updated =
ESS
>> certIDv2 to be used to identify the signer=B9s certificate IF the TSA for =
some
>> reason choose to hash its certificate with another hash then SHA-1.
>>=20
>> The rationale for the certID identifier is given in section 5 of RFC 263=
4 and
>> describes attacks where one valid certificate is substituted by another =
valid
>> certificate (exceopt for some DoS case that I don=B9t think is relevant he=
re).
>> Now I have to ask myself. How likely is it that a legitimate TSA has 2  =
or
>> more legitimate certificates for the same public key with conflicting
>> information (or information different enough to actually have a security
>> impact) AND where the hash of these certificates produce a SHA-1 collisi=
on.
>>=20
>> This is not the previously discussed certificate collision attack using =
weak
>> certificate signing hash, where I may prepare a certificate request in a=
 way
>> where I can fool the CA to produce two valid certificates with the same
>> certificate signature. If I would use that technique I would have to fin=
d a
>> way to prepare the TSA certificate requests, the TSA certificate hash ne=
ed to
>> be weak in addition to the certID hash AND In addition to that the compl=
ete
>> certificates (not only the to be signed part) need to create a hash coll=
ision
>> when computing the certID.
>>=20
>> So, my first question is if this change addresses any real security thre=
at?
>> Can someone provide a reasonable threat analysis?
>> And consequently, if there are no real threats to solve, does this updat=
e
>> motivate the potential interoperability issues that might be the result =
of by
>> allowing ESS CertIDv2 in time stamp tokens?
>>=20
>>=20
>> If we do come to the conclusion that it is worth it, then why not just c=
reate
>> an update RFC updating RFC 3161 instead of replacing it?
>>=20
>> This update does not change any bits on the wire for implementations of =
the
>> current protocol. The only thing it does is to add an option to use ESS
>> certIDv2 IF SHA-1 is not used as hash to identify the TSA=B9s certificate.
>> This seems like a perfect thing for an update RFC. Another argument is t=
hat
>> the old editors that rightfully should have the credit for RFC 3161 are =
not
>> part of this minor amendment but are completely erased from the update. =
That
>> may be reasonable if the changes are major but I=B9m not so sure in this c=
ase.
>>=20


--B_3320121305_10619757
Content-type: text/html;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Re: Do we need rfc 3161bis?</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt=
'>Exactly as Jim says. Maybe we should add further that this is a bout subst=
ituting one valid TSA certificate with another valid TSA certificate since t=
he TSA for some reason has two TSA certificates for the same public key whic=
h when hashed, have the same SHA-1 hash.<BR>
<BR>
/Stefan<BR>
<BR>
<BR>
On 3/17/09 6:26 AM, &quot;Jim Schaad&quot; &lt;<a href=3D"ietf@augustcellars.=
com">[e-mail]</a>&gt; wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><=
SPAN STYLE=3D'font-size:11pt'><FONT COLOR=3D"#1F497D">The attack we are looking =
at is a certificate substitution attack with the TSA certificate being chang=
ed to a different certificate. &nbsp;This is not &nbsp;question of trusting =
the TSA itself. &nbsp;Unless of course it is the one trying the attack for s=
ome reason.<BR>
&nbsp;<BR>
&nbsp;<BR>
</FONT><BR>
</SPAN></FONT><FONT SIZE=3D"2"><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:10pt'><B>From:</B> Santosh Chokhani [<a href=3D"mailto=
:[e-mail]">mailto:[e-mail]</a>] <BR>
<B>Sent:</B> Monday, March 16, 2009 9:25 PM<BR>
<B>To:</B> Stefan Santesson; Jim Schaad; IETF-pkix<BR>
<B>Subject:</B> RE: Do we need rfc 3161bis?<BR>
</SPAN></FONT></FONT><FONT FACE=3D"Times New Roman"><SPAN STYLE=3D'font-size:12=
pt'> <BR>
</SPAN></FONT><FONT COLOR=3D"#0000FF"><FONT SIZE=3D"2"><FONT FACE=3D"Arial"><SPAN=
 STYLE=3D'font-size:10pt'>I have not followed the thread well. &nbsp;But, are =
we losing forest for the trees here?<BR>
</SPAN></FONT></FONT></FONT><FONT FACE=3D"Times New Roman"><SPAN STYLE=3D'font-=
size:12pt'> <BR>
</SPAN></FONT><FONT COLOR=3D"#0000FF"><FONT SIZE=3D"2"><FONT FACE=3D"Arial"><SPAN=
 STYLE=3D'font-size:10pt'>Do we not trust the TSA enough to not create collisi=
on attack?<BR>
</SPAN></FONT></FONT></FONT><BLOCKQUOTE><FONT FACE=3D"Times New Roman"><SPAN =
STYLE=3D'font-size:12pt'>=20
</SPAN></FONT>
<P ALIGN=3DCENTER>
<FONT FACE=3D"Times New Roman"><SPAN STYLE=3D'font-size:12pt'><HR ALIGN=3DCENTER =
SIZE=3D"2" WIDTH=3D"100%"></SPAN></FONT>
<P>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt=
'><BR>
</SPAN></FONT><FONT SIZE=3D"2"><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:10pt'><B>From:</B> <a href=3D"[e-mail]=
.org">[e-mail]</a> [<a href=3D"mailto:owner-ietf-pkix@mail=
.imc.org">mailto:[e-mail]</a>] <B>On Behalf Of </B>Stefa=
n Santesson<BR>
<B>Sent:</B> Monday, March 16, 2009 9:01 PM<BR>
<B>To:</B> Jim Schaad; 'IETF-pkix'<BR>
<B>Subject:</B> Re: Do we need rfc 3161bis?<BR>
</SPAN></FONT></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN =
STYLE=3D'font-size:11pt'>OK,<BR>
<BR>
The prefix attack only works, as you say yourself, on the tbs bits to creat=
e two certs with the same signature. This is ONLY possible if the signature =
hash algorithm is broken. The hash in the essCertID is calculated on the com=
plete certificates (including signatures), not only the tbs bits.<BR>
Thus, the prefix attack is pretty useless if you have a large chunk of rand=
om bits in the end that is bound to be different for each cert. And they wil=
l be different IF the signature algorithm of the certificates is not broken.=
<BR>
<BR>
The second question, sorry for missing it, is broader than just RFC 3161bis=
.<BR>
<BR>
I think we have many protocols, where collision resistance is not an issue,=
 where we don&#8217;t provide algorithm agility for all uses of SHA-1. I do =
think there is a use of SHA-1 in OCSP that is not part of the current update=
 proposal and there is currently a similar discussion in TLS where strong ar=
guments are raised against adding algorithm negotiation complexity when coll=
ision resistance is not a security issue. This problem is more political tha=
n technical. But if there is any reason to do this, it probably is for polit=
ical reasons, so your point is valid.<BR>
<BR>
/Stefan<BR>
<BR>
On 3/17/09 1:20 AM, &quot;Jim Schaad&quot; &lt;<a href=3D"ietf@augustcellars.=
com">[e-mail]</a>&gt; wrote:<BR>
<FONT COLOR=3D"#1F497D">Stefan,<BR>
&nbsp;<BR>
First I don&#8217;t know that I agree. &nbsp;I think that the entirety of y=
our protection is actually given by the leading sequence/length bytes. &nbsp=
;The object is to prevent a prefix attack. &nbsp;One can create a prefix att=
ack against the TBS bytes &#8211; leading to identical signatures for both v=
ersions of the certificate. &nbsp;However adding the leading sequence/length=
 octets probably means that you need to have two different prefix attacks &#=
8211; a much harder condition, but maybe doable.<BR>
&nbsp;<BR>
However I don&#8217;t believe that you addressed my second point at all. &n=
bsp;That is people completely migrate away from SHA-1 because it is consider=
ed to be broken.<BR>
&nbsp;<BR>
jim<BR>
&nbsp;<BR>
</FONT><BR>
</SPAN></FONT><FONT SIZE=3D"2"><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:10pt'><B>From:</B> Stefan Santesson [<a href=3D"mailto=
:[e-mail]">mailto:[e-mail]</a>] <BR>
<B>Sent:</B> Monday, March 16, 2009 5:09 PM<BR>
<B>To:</B> Jim Schaad; 'IETF-pkix'<BR>
<B>Subject:</B> Re: Do we need rfc 3161bis?<BR>
</SPAN></FONT></FONT><FONT FACE=3D"Times New Roman"><SPAN STYLE=3D'font-size:12=
pt'><BR>
</SPAN></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'=
font-size:11pt'>Jim,<BR>
<BR>
You ask,<BR>
<FONT COLOR=3D"#1E487C">The question becomes can I create two certificates th=
at can have the same hash, NOT will it happen by chance.<BR>
</FONT><BR>
I <B>totally</B> agree. And I don&#8217;t think you can.<BR>
<BR>
Not if the two certificates are signed with a good signature algorithm. <BR=
>
If these certificates are signed with a bad signature algorithm that allows=
 different certificates to share the same signature, then all bets are off a=
nyway.<BR>
<BR>
If the signature algorithms are good, then the signatures of these certific=
ates will be composed of a substantial amount of vastly different bits. As t=
he signature algorithm is good, you can&#8217;t control the bits of these si=
gnatures in any meaningful way, leaving you basically with a trial and error=
 approach. That even if SHA-1 is broken.<BR>
<BR>
/Stefan<BR>
<BR>
<BR>
On 3/16/09 8:17 PM, &quot;Jim Schaad&quot; &lt;<a href=3D"ietf@augustcellars.=
com">[e-mail]</a>&gt; wrote:<BR>
<FONT COLOR=3D"#1F497D">Stefan,<BR>
&nbsp;<BR>
The property that is being used is not the randomness property, it is a col=
lision property. &nbsp;(Or more specifically resistance to collisions.) &nbs=
p;&nbsp;The question becomes can I create two certificates that can have the=
 same hash, NOT will it happen by chance. &nbsp;&nbsp;If I can do so then I =
have a successful attack at this point.<BR>
&nbsp;<BR>
However one needs to assume that if SHA-1 is significantly broken, people w=
ill be removing it from the trusted algorithm list and would then need a mig=
ration path of what to put in place of the current SHA-1 attribute. &nbsp;Th=
is is the main reason for doing the update.<BR>
&nbsp;<BR>
jim<BR>
&nbsp;<BR>
</FONT><BR>
</SPAN></FONT><FONT SIZE=3D"2"><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:10pt'><B>From:</B> <a href=3D"[e-mail]=
.org">[e-mail]</a> [<a href=3D"mailto:owner-ietf-pkix@mail=
.imc.org">mailto:[e-mail]</a>] <B>On Behalf Of </B>Stefa=
n Santesson<BR>
<B>Sent:</B> Saturday, March 14, 2009 5:54 PM<BR>
<B>To:</B> Jim Schaad; 'IETF-pkix'<BR>
<B>Subject:</B> Re: Do we need rfc 3161bis?<BR>
</SPAN></FONT></FONT><FONT FACE=3D"Times New Roman"><SPAN STYLE=3D'font-size:12=
pt'><BR>
</SPAN></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'=
font-size:11pt'>Yes, a good question indeed.<BR>
<BR>
Say that SHA-1 is completely broken in the sense that we can produce collis=
ions at will, of all sorts and forms.<BR>
Say also that we have a few valid TSA certificates issued for the same key =
pair, signed using good hash algorithms (or else all bets are off anyway).<B=
R>
<BR>
The randomness properties of SHA-1 will remain intact even if SHA-1 is brok=
en. This means that the risk/chance that two valid certificates, signed with=
 safe signature algorithms, will by chance produce collisions, is still tota=
lly negligible.<BR>
<BR>
Where am I thinking wrong here?<BR>
<BR>
/Stefan<BR>
<BR>
<BR>
<BR>
On 3/14/09 8:00 PM, &quot;Jim Schaad&quot; &lt;<a href=3D"ietf@augustcellars.=
com">[e-mail]</a>&gt; wrote:<BR>
<FONT COLOR=3D"#1F497D">Stefan,<BR>
&nbsp;<BR>
The question you need to be asking is &#8211; Do you believe that SHA-1 wil=
l be broken one day, and if it is broken do you want to have in place a solu=
tion to deal with it.<BR>
&nbsp;<BR>
Jim<BR>
&nbsp;<BR>
&nbsp;<BR>
</FONT><BR>
</SPAN></FONT><FONT SIZE=3D"2"><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:10pt'><B>From:</B> <a href=3D"[e-mail]=
.org">[e-mail]</a> [<a href=3D"mailto:owner-ietf-pkix@mail=
.imc.org">mailto:[e-mail]</a>] <B>On Behalf Of </B>Stefa=
n Santesson<BR>
<B>Sent:</B> Saturday, March 14, 2009 7:06 AM<BR>
<B>To:</B> IETF-pkix<BR>
<B>Subject:</B> Do we need rfc 3161bis?<BR>
</SPAN></FONT></FONT><FONT FACE=3D"Times New Roman"><SPAN STYLE=3D'font-size:12=
pt'><BR>
</SPAN></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'=
font-size:11pt'>The more I look into this the more I get to doubt that we ac=
tually need 3161bis.<BR>
<BR>
The only substantial technical change I know of is to allow the updated ESS=
 certIDv2 to be used to identify the signer&#8217;s certificate IF the TSA f=
or some reason choose to hash its certificate with another hash then SHA-1.<=
BR>
<BR>
The rationale for the certID identifier is given in section 5 of RFC 2634 a=
nd describes attacks where one valid certificate is substituted by another v=
alid certificate (exceopt for some DoS case that I don&#8217;t think is rele=
vant here).<BR>
Now I have to ask myself. How likely is it that a legitimate TSA has 2 &nbs=
p;or more legitimate certificates for the same public key with conflicting i=
nformation (or information different enough to actually have a security impa=
ct) AND where the hash of these certificates produce a SHA-1 collision.<BR>
<BR>
This is not the previously discussed certificate collision attack using wea=
k certificate signing hash, where I may prepare a certificate request in a w=
ay where I can fool the CA to produce two valid certificates with the same c=
ertificate signature. If I would use that technique I would have to find a w=
ay to prepare the TSA certificate requests, the TSA certificate hash need to=
 be weak in addition to the certID hash AND In addition to that the complete=
 certificates (not only the to be signed part) need to create a hash collisi=
on when computing the certID.<BR>
<BR>
So, my first question is if this change addresses any real security threat?=
<BR>
Can someone provide a reasonable threat analysis?<BR>
And consequently, if there are no real threats to solve, does this update m=
otivate the potential interoperability issues that might be the result of by=
 allowing ESS CertIDv2 in time stamp tokens?<BR>
<BR>
<BR>
If we do come to the conclusion that it is worth it, then why not just crea=
te an update RFC updating RFC 3161 instead of replacing it?<BR>
<BR>
This update does not change any bits on the wire for implementations of the=
 current protocol. The only thing it does is to add an option to use ESS cer=
tIDv2 IF SHA-1 is not used as hash to identify the TSA&#8217;s certificate.<=
BR>
This seems like a perfect thing for an update RFC. Another argument is that=
 the old editors that rightfully should have the credit for RFC 3161 are not=
 part of this minor amendment but are completely erased from the update. Tha=
t may be reasonable if the changes are major but I&#8217;m not so sure in th=
is case.<BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial">=
<SPAN STYLE=3D'font-size:11pt'><BR>
</SPAN></FONT></BLOCKQUOTE>
</BODY>
</HTML>


--B_3320121305_10619757--




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 n2H5RAPC020011 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Mar 2009 22:27:10 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2H5RA2u020010; Mon, 16 Mar 2009 22:27:10 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.173]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2H5QwjU020002 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <[e-mail]>; Mon, 16 Mar 2009 22:27:09 -0700 (MST) (envelope-from [e-mail])
Received: from GALATIONS (unknown [207.202.179.27]) by smtp3.pacifier.net (Postfix) with ESMTP id 9AFAF7E30; Mon, 16 Mar 2009 22:26:56 -0700 (PDT)
From: "Jim Schaad" <[e-mail]>
To: "'Santosh Chokhani'" <[e-mail]>, "'Stefan Santesson'" <[e-mail]>, "'IETF-pkix'" <[e-mail]>
References: <01b001c9a696$211ec660$635c5320$@com> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: RE: Do we need rfc 3161bis?
Date: Mon, 16 Mar 2009 22:26:43 -0700
Message-ID: <015001c9a6c0$f5d49090$e17db1b0$@com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0151_01C9A686.4975B890"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Acmkrf0j+yb7f0QChUOhT/ms/PsBpAAKRABQAAxc04EAWKrEYAAKV4S0AABPAXAAAX+tawAHFfSwAAIvI0A=
Content-Language: en-us
Sender: [e-mail]
Precedence: 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 multipart message in MIME format.

------=_NextPart_000_0151_01C9A686.4975B890
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

The attack we are looking at is a certificate substitution attack with the
TSA certificate being changed to a different certificate.  This is not
question of trusting the TSA itself.  Unless of course it is the one trying
the attack for some reason.

 

 

From: Santosh Chokhani [mailto:[e-mail]] 
Sent: Monday, March 16, 2009 9:25 PM
To: Stefan Santesson; Jim Schaad; IETF-pkix
Subject: RE: Do we need rfc 3161bis?

 

I have not followed the thread well.  But, are we losing forest for the
trees here?

 

Do we not trust the TSA enough to not create collision attack?

 

  _____  

From: [e-mail] [mailto:[e-mail]] On
Behalf Of Stefan Santesson
Sent: Monday, March 16, 2009 9:01 PM
To: Jim Schaad; 'IETF-pkix'
Subject: Re: Do we need rfc 3161bis?

OK,

The prefix attack only works, as you say yourself, on the tbs bits to create
two certs with the same signature. This is ONLY possible if the signature
hash algorithm is broken. The hash in the essCertID is calculated on the
complete certificates (including signatures), not only the tbs bits.
Thus, the prefix attack is pretty useless if you have a large chunk of
random bits in the end that is bound to be different for each cert. And they
will be different IF the signature algorithm of the certificates is not
broken.

The second question, sorry for missing it, is broader than just RFC 3161bis.

I think we have many protocols, where collision resistance is not an issue,
where we don't provide algorithm agility for all uses of SHA-1. I do think
there is a use of SHA-1 in OCSP that is not part of the current update
proposal and there is currently a similar discussion in TLS where strong
arguments are raised against adding algorithm negotiation complexity when
collision resistance is not a security issue. This problem is more political
than technical. But if there is any reason to do this, it probably is for
political reasons, so your point is valid.

/Stefan

On 3/17/09 1:20 AM, "Jim Schaad" <[e-mail]> wrote:

Stefan,
 
First I don't know that I agree.  I think that the entirety of your
protection is actually given by the leading sequence/length bytes.  The
object is to prevent a prefix attack.  One can create a prefix attack
against the TBS bytes - leading to identical signatures for both versions of
the certificate.  However adding the leading sequence/length octets probably
means that you need to have two different prefix attacks - a much harder
condition, but maybe doable.
 
However I don't believe that you addressed my second point at all.  That is
people completely migrate away from SHA-1 because it is considered to be
broken.
 
jim
 

From: Stefan Santesson [mailto:[e-mail]] 
Sent: Monday, March 16, 2009 5:09 PM
To: Jim Schaad; 'IETF-pkix'
Subject: Re: Do we need rfc 3161bis?

Jim,

You ask,
The question becomes can I create two certificates that can have the same
hash, NOT will it happen by chance.

I totally agree. And I don't think you can.

Not if the two certificates are signed with a good signature algorithm. 
If these certificates are signed with a bad signature algorithm that allows
different certificates to share the same signature, then all bets are off
anyway.

If the signature algorithms are good, then the signatures of these
certificates will be composed of a substantial amount of vastly different
bits. As the signature algorithm is good, you can't control the bits of
these signatures in any meaningful way, leaving you basically with a trial
and error approach. That even if SHA-1 is broken.

/Stefan


On 3/16/09 8:17 PM, "Jim Schaad" <[e-mail]> wrote:
Stefan,
 
The property that is being used is not the randomness property, it is a
collision property.  (Or more specifically resistance to collisions.)   The
question becomes can I create two certificates that can have the same hash,
NOT will it happen by chance.   If I can do so then I have a successful
attack at this point.
 
However one needs to assume that if SHA-1 is significantly broken, people
will be removing it from the trusted algorithm list and would then need a
migration path of what to put in place of the current SHA-1 attribute.  This
is the main reason for doing the update.
 
jim
 

From: [e-mail] [mailto:[e-mail]] On
Behalf Of Stefan Santesson
Sent: Saturday, March 14, 2009 5:54 PM
To: Jim Schaad; 'IETF-pkix'
Subject: Re: Do we need rfc 3161bis?

Yes, a good question indeed.

Say that SHA-1 is completely broken in the sense that we can produce
collisions at will, of all sorts and forms.
Say also that we have a few valid TSA certificates issued for the same key
pair, signed using good hash algorithms (or else all bets are off anyway).

The randomness properties of SHA-1 will remain intact even if SHA-1 is
broken. This means that the risk/chance that two valid certificates, signed
with safe signature algorithms, will by chance produce collisions, is still
totally negligible.

Where am I thinking wrong here?

/Stefan



On 3/14/09 8:00 PM, "Jim Schaad" <[e-mail]> wrote:
Stefan,
 
The question you need to be asking is - Do you believe that SHA-1 will be
broken one day, and if it is broken do you want to have in place a solution
to deal with it.
 
Jim
 
 

From: [e-mail] [mailto:[e-mail]] On
Behalf Of Stefan Santesson
Sent: Saturday, March 14, 2009 7:06 AM
To: IETF-pkix
Subject: Do we need rfc 3161bis?

The more I look into this the more I get to doubt that we actually need
3161bis.

The only substantial technical change I know of is to allow the updated ESS
certIDv2 to be used to identify the signer's certificate IF the TSA for some
reason choose to hash its certificate with another hash then SHA-1.

The rationale for the certID identifier is given in section 5 of RFC 2634
and describes attacks where one valid certificate is substituted by another
valid certificate (exceopt for some DoS case that I don't think is relevant
here).
Now I have to ask myself. How likely is it that a legitimate TSA has 2  or
more legitimate certificates for the same public key with conflicting
information (or information different enough to actually have a security
impact) AND where the hash of these certificates produce a SHA-1 collision.

This is not the previously discussed certificate collision attack using weak
certificate signing hash, where I may prepare a certificate request in a way
where I can fool the CA to produce two valid certificates with the same
certificate signature. If I would use that technique I would have to find a
way to prepare the TSA certificate requests, the TSA certificate hash need
to be weak in addition to the certID hash AND In addition to that the
complete certificates (not only the to be signed part) need to create a hash
collision when computing the certID.

So, my first question is if this change addresses any real security threat?
Can someone provide a reasonable threat analysis?
And consequently, if there are no real threats to solve, does this update
motivate the potential interoperability issues that might be the result of
by allowing ESS CertIDv2 in time stamp tokens?


If we do come to the conclusion that it is worth it, then why not just
create an update RFC updating RFC 3161 instead of replacing it?

This update does not change any bits on the wire for implementations of the
current protocol. The only thing it does is to add an option to use ESS
certIDv2 IF SHA-1 is not used as hash to identify the TSA's certificate.
This seems like a perfect thing for an update RFC. Another argument is that
the old editors that rightfully should have the credit for RFC 3161 are not
part of this minor amendment but are completely erased from the update. That
may be reasonable if the changes are major but I'm not so sure in this case.


------=_NextPart_000_0151_01C9A686.4975B890
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)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<title>Re: Do we need rfc 3161bis?</title>
<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;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","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-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:1.0in 1.0in 1.0in 1.0in;}
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'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>The attack we are looking at is a certificate =
substitution attack
with the TSA certificate being changed to a different certificate.&nbsp; =
This is
not&nbsp; question of trusting the TSA itself.&nbsp; Unless of course it =
is the one
trying the attack for some reason.<o:p></o:p></span></p>

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

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

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

<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"'> Santosh =
Chokhani
[mailto:[e-mail]] <br>
<b>Sent:</b> Monday, March 16, 2009 9:25 PM<br>
<b>To:</b> Stefan Santesson; Jim Schaad; IETF-pkix<br>
<b>Subject:</b> RE: Do we need rfc 3161bis?<o:p></o:p></span></p>

</div>

</div>

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

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:blue'>I have not followed the thread well.&nbsp; But, are we =
losing
forest for the trees here?</span><o:p></o:p></p>

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

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:blue'>Do we not trust the TSA enough to not create collision =
attack?</span><o:p></o:p></p>

<blockquote style=3D'border:none;border-left:solid blue =
1.5pt;padding:0in 0in 0in 4.0pt;
margin-left:3.75pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'=
>

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

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'>

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

</div>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><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"'> [e-mail]
[mailto:[e-mail]] <b>On Behalf Of </b>Stefan =
Santesson<br>
<b>Sent:</b> Monday, March 16, 2009 9:01 PM<br>
<b>To:</b> Jim Schaad; 'IETF-pkix'<br>
<b>Subject:</b> Re: Do we need rfc 3161bis?</span><o:p></o:p></p>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><span =
style=3D'font-size:11.0pt;
font-family:"Calibri","sans-serif"'>OK,<br>
<br>
The prefix attack only works, as you say yourself, on the tbs bits to =
create
two certs with the same signature. This is ONLY possible if the =
signature hash
algorithm is broken. The hash in the essCertID is calculated on the =
complete
certificates (including signatures), not only the tbs bits.<br>
Thus, the prefix attack is pretty useless if you have a large chunk of =
random
bits in the end that is bound to be different for each cert. And they =
will be
different IF the signature algorithm of the certificates is not =
broken.<br>
<br>
The second question, sorry for missing it, is broader than just RFC =
3161bis.<br>
<br>
I think we have many protocols, where collision resistance is not an =
issue,
where we don&#8217;t provide algorithm agility for all uses of SHA-1. I =
do think
there is a use of SHA-1 in OCSP that is not part of the current update =
proposal
and there is currently a similar discussion in TLS where strong =
arguments are
raised against adding algorithm negotiation complexity when collision
resistance is not a security issue. This problem is more political than
technical. But if there is any reason to do this, it probably is for =
political
reasons, so your point is valid.<br>
<br>
/Stefan<br>
<br>
On 3/17/09 1:20 AM, &quot;Jim Schaad&quot; &lt;<a =
href=3D"[e-mail]">[e-mail]</a>&gt;
wrote:</span><o:p></o:p></p>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><span =
style=3D'font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'>Stefan,<br>
&nbsp;<br>
First I don&#8217;t know that I agree. &nbsp;I think that the entirety =
of your
protection is actually given by the leading sequence/length bytes. =
&nbsp;The
object is to prevent a prefix attack. &nbsp;One can create a prefix =
attack
against the TBS bytes &#8211; leading to identical signatures for both =
versions of
the certificate. &nbsp;However adding the leading sequence/length octets
probably means that you need to have two different prefix attacks =
&#8211; a much
harder condition, but maybe doable.<br>
&nbsp;<br>
However I don&#8217;t believe that you addressed my second point at all. =
&nbsp;That
is people completely migrate away from SHA-1 because it is considered to =
be
broken.<br>
&nbsp;<br>
jim<br>
&nbsp;<br>
</span><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'><br>
</span><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 [<a
href=3D"mailto:[e-mail]">mailto:[e-mail]</a>] <br>
<b>Sent:</b> Monday, March 16, 2009 5:09 PM<br>
<b>To:</b> Jim Schaad; 'IETF-pkix'<br>
<b>Subject:</b> Re: Do we need rfc 3161bis?<br>
</span><br>
<span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>Jim,<br>
<br>
You ask,<br>
<span style=3D'color:#1E487C'>The question becomes can I create two =
certificates
that can have the same hash, NOT will it happen by chance.<br>
</span><br>
I <b>totally</b> agree. And I don&#8217;t think you can.<br>
<br>
Not if the two certificates are signed with a good signature algorithm. =
<br>
If these certificates are signed with a bad signature algorithm that =
allows
different certificates to share the same signature, then all bets are =
off
anyway.<br>
<br>
If the signature algorithms are good, then the signatures of these =
certificates
will be composed of a substantial amount of vastly different bits. As =
the
signature algorithm is good, you can&#8217;t control the bits of these =
signatures in
any meaningful way, leaving you basically with a trial and error =
approach. That
even if SHA-1 is broken.<br>
<br>
/Stefan<br>
<br>
<br>
On 3/16/09 8:17 PM, &quot;Jim Schaad&quot; &lt;<a =
href=3D"[e-mail]">[e-mail]</a>&gt;
wrote:<br>
<span style=3D'color:#1F497D'>Stefan,<br>
&nbsp;<br>
The property that is being used is not the randomness property, it is a
collision property. &nbsp;(Or more specifically resistance to =
collisions.)
&nbsp;&nbsp;The question becomes can I create two certificates that can =
have
the same hash, NOT will it happen by chance. &nbsp;&nbsp;If I can do so =
then I
have a successful attack at this point.<br>
&nbsp;<br>
However one needs to assume that if SHA-1 is significantly broken, =
people will
be removing it from the trusted algorithm list and would then need a =
migration
path of what to put in place of the current SHA-1 attribute. &nbsp;This =
is the
main reason for doing the update.<br>
&nbsp;<br>
jim<br>
&nbsp;<br>
</span><br>
</span><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"'> <a
href=3D"[e-mail]">[e-mail]</a> =
[<a
href=3D"mailto:[e-mail]">mailto:owner-ietf-pkix@mail.=
imc.org</a>]
<b>On Behalf Of </b>Stefan Santesson<br>
<b>Sent:</b> Saturday, March 14, 2009 5:54 PM<br>
<b>To:</b> Jim Schaad; 'IETF-pkix'<br>
<b>Subject:</b> Re: Do we need rfc 3161bis?<br>
</span><br>
<span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>Yes, =
a good
question indeed.<br>
<br>
Say that SHA-1 is completely broken in the sense that we can produce =
collisions
at will, of all sorts and forms.<br>
Say also that we have a few valid TSA certificates issued for the same =
key
pair, signed using good hash algorithms (or else all bets are off =
anyway).<br>
<br>
The randomness properties of SHA-1 will remain intact even if SHA-1 is =
broken.
This means that the risk/chance that two valid certificates, signed with =
safe
signature algorithms, will by chance produce collisions, is still =
totally
negligible.<br>
<br>
Where am I thinking wrong here?<br>
<br>
/Stefan<br>
<br>
<br>
<br>
On 3/14/09 8:00 PM, &quot;Jim Schaad&quot; &lt;<a =
href=3D"[e-mail]">[e-mail]</a>&gt;
wrote:<br>
<span style=3D'color:#1F497D'>Stefan,<br>
&nbsp;<br>
The question you need to be asking is &#8211; Do you believe that SHA-1 =
will be
broken one day, and if it is broken do you want to have in place a =
solution to
deal with it.<br>
&nbsp;<br>
Jim<br>
&nbsp;<br>
&nbsp;<br>
</span><br>
</span><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"'> <a
href=3D"[e-mail]">[e-mail]</a> =
[<a
href=3D"mailto:[e-mail]">mailto:owner-ietf-pkix@mail.=
imc.org</a>]
<b>On Behalf Of </b>Stefan Santesson<br>
<b>Sent:</b> Saturday, March 14, 2009 7:06 AM<br>
<b>To:</b> IETF-pkix<br>
<b>Subject:</b> Do we need rfc 3161bis?<br>
</span><br>
<span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>The =
more I
look into this the more I get to doubt that we actually need =
3161bis.<br>
<br>
The only substantial technical change I know of is to allow the updated =
ESS
certIDv2 to be used to identify the signer&#8217;s certificate IF the =
TSA for some
reason choose to hash its certificate with another hash then SHA-1.<br>
<br>
The rationale for the certID identifier is given in section 5 of RFC =
2634 and
describes attacks where one valid certificate is substituted by another =
valid
certificate (exceopt for some DoS case that I don&#8217;t think is =
relevant here).<br>
Now I have to ask myself. How likely is it that a legitimate TSA has 2 =
&nbsp;or
more legitimate certificates for the same public key with conflicting
information (or information different enough to actually have a security
impact) AND where the hash of these certificates produce a SHA-1 =
collision.<br>
<br>
This is not the previously discussed certificate collision attack using =
weak
certificate signing hash, where I may prepare a certificate request in a =
way
where I can fool the CA to produce two valid certificates with the same
certificate signature. If I would use that technique I would have to =
find a way
to prepare the TSA certificate requests, the TSA certificate hash need =
to be
weak in addition to the certID hash AND In addition to that the complete
certificates (not only the to be signed part) need to create a hash =
collision
when computing the certID.<br>
<br>
So, my first question is if this change addresses any real security =
threat?<br>
Can someone provide a reasonable threat analysis?<br>
And consequently, if there are no real threats to solve, does this =
update
motivate the potential interoperability issues that might be the result =
of by
allowing ESS CertIDv2 in time stamp tokens?<br>
<br>
<br>
If we do come to the conclusion that it is worth it, then why not just =
create
an update RFC updating RFC 3161 instead of replacing it?<br>
<br>
This update does not change any bits on the wire for implementations of =
the
current protocol. The only thing it does is to add an option to use ESS
certIDv2 IF SHA-1 is not used as hash to identify the TSA&#8217;s =
certificate.<br>
This seems like a perfect thing for an update RFC. Another argument is =
that the
old editors that rightfully should have the credit for RFC 3161 are not =
part of
this minor amendment but are completely erased from the update. That may =
be
reasonable if the changes are major but I&#8217;m not so sure in this =
case.</span><o:p></o:p></p>

</blockquote>

</div>

</div>

</body>

</html>

------=_NextPart_000_0151_01C9A686.4975B890--



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 n2H4P5HN017504 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Mar 2009 21:25:05 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2H4P5CF017503; Mon, 16 Mar 2009 21:25:05 -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 n2H4OqAO017488 for <[e-mail]>; Mon, 16 Mar 2009 21:25:03 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 29296 invoked from network); 17 Mar 2009 04:24:10 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 17 Mar 2009 04:24:10 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9A6B8.50F52E87"
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: Do we need rfc 3161bis?
Date: Tue, 17 Mar 2009 00:24:50 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Do we need rfc 3161bis?
Thread-Index: Acmkrf0j+yb7f0QChUOhT/ms/PsBpAAKRABQAAxc04EAWKrEYAAKV4S0AABPAXAAAX+tawAHFfSw
References: <01b001c9a696$211ec660$635c5320$@com> <[e-mail]>
From: "Santosh Chokhani" <[e-mail]>
To: "Stefan Santesson" <[e-mail]>, "Jim Schaad" <[e-mail]>, "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_01C9A6B8.50F52E87
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I have not followed the thread well.  But, are we losing forest for the
trees here?
=20
Do we not trust the TSA enough to not create collision attack?


________________________________

	From: [e-mail]
[mailto:[e-mail]] On Behalf Of Stefan Santesson
	Sent: Monday, March 16, 2009 9:01 PM
	To: Jim Schaad; 'IETF-pkix'
	Subject: Re: Do we need rfc 3161bis?
=09
=09
	OK,
=09
	The prefix attack only works, as you say yourself, on the tbs
bits to create two certs with the same signature. This is ONLY possible
if the signature hash algorithm is broken. The hash in the essCertID is
calculated on the complete certificates (including signatures), not only
the tbs bits.
	Thus, the prefix attack is pretty useless if you have a large
chunk of random bits in the end that is bound to be different for each
cert. And they will be different IF the signature algorithm of the
certificates is not broken.
=09
	The second question, sorry for missing it, is broader than just
RFC 3161bis.
=09
	I think we have many protocols, where collision resistance is
not an issue, where we don't provide algorithm agility for all uses of
SHA-1. I do think there is a use of SHA-1 in OCSP that is not part of
the current update proposal and there is currently a similar discussion
in TLS where strong arguments are raised against adding algorithm
negotiation complexity when collision resistance is not a security
issue. This problem is more political than technical. But if there is
any reason to do this, it probably is for political reasons, so your
point is valid.
=09
	/Stefan
=09
	On 3/17/09 1:20 AM, "Jim Schaad" <[e-mail]> wrote:
=09
=09

		Stefan,
		=20
		First I don't know that I agree.  I think that the
entirety of your protection is actually given by the leading
sequence/length bytes.  The object is to prevent a prefix attack.  One
can create a prefix attack against the TBS bytes - leading to identical
signatures for both versions of the certificate.  However adding the
leading sequence/length octets probably means that you need to have two
different prefix attacks - a much harder condition, but maybe doable.
		=20
		However I don't believe that you addressed my second
point at all.  That is people completely migrate away from SHA-1 because
it is considered to be broken.
		=20
		jim
		=20
	=09
		From: Stefan Santesson [mailto:[e-mail]]=20
		Sent: Monday, March 16, 2009 5:09 PM
		To: Jim Schaad; 'IETF-pkix'
		Subject: Re: Do we need rfc 3161bis?
	=09
		Jim,
	=09
		You ask,
		The question becomes can I create two certificates that
can have the same hash, NOT will it happen by chance.
	=09
		I totally agree. And I don't think you can.
	=09
		Not if the two certificates are signed with a good
signature algorithm.=20
		If these certificates are signed with a bad signature
algorithm that allows different certificates to share the same
signature, then all bets are off anyway.
	=09
		If the signature algorithms are good, then the
signatures of these certificates will be composed of a substantial
amount of vastly different bits. As the signature algorithm is good, you
can't control the bits of these signatures in any meaningful way,
leaving you basically with a trial and error approach. That even if
SHA-1 is broken.
	=09
		/Stefan
	=09
	=09
		On 3/16/09 8:17 PM, "Jim Schaad"
<[e-mail]> wrote:
		Stefan,
		=20
		The property that is being used is not the randomness
property, it is a collision property.  (Or more specifically resistance
to collisions.)   The question becomes can I create two certificates
that can have the same hash, NOT will it happen by chance.   If I can do
so then I have a successful attack at this point.
		=20
		However one needs to assume that if SHA-1 is
significantly broken, people will be removing it from the trusted
algorithm list and would then need a migration path of what to put in
place of the current SHA-1 attribute.  This is the main reason for doing
the update.
		=20
		jim
		=20
	=09
		From: [e-mail]
[mailto:[e-mail]] On Behalf Of Stefan Santesson
		Sent: Saturday, March 14, 2009 5:54 PM
		To: Jim Schaad; 'IETF-pkix'
		Subject: Re: Do we need rfc 3161bis?
	=09
		Yes, a good question indeed.
	=09
		Say that SHA-1 is completely broken in the sense that we
can produce collisions at will, of all sorts and forms.
		Say also that we have a few valid TSA certificates
issued for the same key pair, signed using good hash algorithms (or else
all bets are off anyway).
	=09
		The randomness properties of SHA-1 will remain intact
even if SHA-1 is broken. This means that the risk/chance that two valid
certificates, signed with safe signature algorithms, will by chance
produce collisions, is still totally negligible.
	=09
		Where am I thinking wrong here?
	=09
		/Stefan
	=09
	=09
	=09
		On 3/14/09 8:00 PM, "Jim Schaad"
<[e-mail]> wrote:
		Stefan,
		=20
		The question you need to be asking is - Do you believe
that SHA-1 will be broken one day, and if it is broken do you want to
have in place a solution to deal with it.
		=20
		Jim
		=20
		=20
	=09
		From: [e-mail]
[mailto:[e-mail]] On Behalf Of Stefan Santesson
		Sent: Saturday, March 14, 2009 7:06 AM
		To: IETF-pkix
		Subject: Do we need rfc 3161bis?
	=09
		The more I look into this the more I get to doubt that
we actually need 3161bis.
	=09
		The only substantial technical change I know of is to
allow the updated ESS certIDv2 to be used to identify the signer's
certificate IF the TSA for some reason choose to hash its certificate
with another hash then SHA-1.
	=09
		The rationale for the certID identifier is given in
section 5 of RFC 2634 and describes attacks where one valid certificate
is substituted by another valid certificate (exceopt for some DoS case
that I don't think is relevant here).
		Now I have to ask myself. How likely is it that a
legitimate TSA has 2  or more legitimate certificates for the same
public key with conflicting information (or information different enough
to actually have a security impact) AND where the hash of these
certificates produce a SHA-1 collision.
	=09
		This is not the previously discussed certificate
collision attack using weak certificate signing hash, where I may
prepare a certificate request in a way where I can fool the CA to
produce two valid certificates with the same certificate signature. If I
would use that technique I would have to find a way to prepare the TSA
certificate requests, the TSA certificate hash need to be weak in
addition to the certID hash AND In addition to that the complete
certificates (not only the to be signed part) need to create a hash
collision when computing the certID.
	=09
		So, my first question is if this change addresses any
real security threat?
		Can someone provide a reasonable threat analysis?
		And consequently, if there are no real threats to solve,
does this update motivate the potential interoperability issues that
might be the result of by allowing ESS CertIDv2 in time stamp tokens?
	=09
	=09
		If we do come to the conclusion that it is worth it,
then why not just create an update RFC updating RFC 3161 instead of
replacing it?
	=09
		This update does not change any bits on the wire for
implementations of the current protocol. The only thing it does is to
add an option to use ESS certIDv2 IF SHA-1 is not used as hash to
identify the TSA's certificate.
		This seems like a perfect thing for an update RFC.
Another argument is that the old editors that rightfully should have the
credit for RFC 3161 are not part of this minor amendment but are
completely erased from the update. That may be reasonable if the changes
are major but I'm not so sure in this case.
	=09
	=09


------_=_NextPart_001_01C9A6B8.50F52E87
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Re: Do we need rfc 3161bis?</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.6000.16809" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D252232304-17032009><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>I have not followed the thread well.&nbsp; But, =
are we=20
losing forest for the trees here?</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D252232304-17032009><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D252232304-17032009><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Do we not trust the TSA enough to not create =
collision=20
attack?</FONT></SPAN></DIV><BR>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
  <HR tabIndex=3D-1>
  <FONT face=3DTahoma size=3D2><B>From:</B> [e-mail] =

  [mailto:[e-mail]] <B>On Behalf Of </B>Stefan=20
  Santesson<BR><B>Sent:</B> Monday, March 16, 2009 9:01 PM<BR><B>To:</B> =
Jim=20
  Schaad; 'IETF-pkix'<BR><B>Subject:</B> Re: Do we need rfc=20
  3161bis?<BR></FONT><BR></DIV>
  <DIV></DIV><FONT face=3D"Calibri, Verdana, Helvetica, Arial"><SPAN=20
  style=3D"FONT-SIZE: 11pt">OK,<BR><BR>The prefix attack only works, as =
you say=20
  yourself, on the tbs bits to create two certs with the same signature. =
This is=20
  ONLY possible if the signature hash algorithm is broken. The hash in =
the=20
  essCertID is calculated on the complete certificates (including =
signatures),=20
  not only the tbs bits.<BR>Thus, the prefix attack is pretty useless if =
you=20
  have a large chunk of random bits in the end that is bound to be =
different for=20
  each cert. And they will be different IF the signature algorithm of =
the=20
  certificates is not broken.<BR><BR>The second question, sorry for =
missing it,=20
  is broader than just RFC 3161bis.<BR><BR>I think we have many =
protocols, where=20
  collision resistance is not an issue, where we don&#8217;t provide =
algorithm agility=20
  for all uses of SHA-1. I do think there is a use of SHA-1 in OCSP that =
is not=20
  part of the current update proposal and there is currently a similar=20
  discussion in TLS where strong arguments are raised against adding =
algorithm=20
  negotiation complexity when collision resistance is not a security =
issue. This=20
  problem is more political than technical. But if there is any reason =
to do=20
  this, it probably is for political reasons, so your point is=20
  valid.<BR><BR>/Stefan<BR><BR>On 3/17/09 1:20 AM, "Jim Schaad" &lt;<A=20
  href=3D"[e-mail]">[e-mail]</A>&gt;=20
  wrote:<BR><BR></SPAN></FONT>
  <BLOCKQUOTE><FONT face=3D"Calibri, Verdana, Helvetica, Arial"><SPAN=20
    style=3D"FONT-SIZE: 11pt"><FONT =
color=3D#1f497d>Stefan,<BR>&nbsp;<BR>First I=20
    don&#8217;t know that I agree. &nbsp;I think that the entirety of =
your protection=20
    is actually given by the leading sequence/length bytes. &nbsp;The =
object is=20
    to prevent a prefix attack. &nbsp;One can create a prefix attack =
against the=20
    TBS bytes &#8211; leading to identical signatures for both versions =
of the=20
    certificate. &nbsp;However adding the leading sequence/length octets =

    probably means that you need to have two different prefix attacks =
&#8211; a much=20
    harder condition, but maybe doable.<BR>&nbsp;<BR>However I =
don&#8217;t believe=20
    that you addressed my second point at all. &nbsp;That is people =
completely=20
    migrate away from SHA-1 because it is considered to be=20
    broken.<BR>&nbsp;<BR>jim<BR>&nbsp;<BR></FONT><BR></SPAN></FONT><FONT =

    size=3D2><FONT face=3D"Tahoma, Verdana, Helvetica, Arial"><SPAN=20
    style=3D"FONT-SIZE: 10pt"><B>From:</B> Stefan Santesson [<A=20
    href=3D"mailto:[e-mail]">mailto:[e-mail]</A>]=20
    <BR><B>Sent:</B> Monday, March 16, 2009 5:09 PM<BR><B>To:</B> Jim =
Schaad;=20
    'IETF-pkix'<BR><B>Subject:</B> Re: Do we need rfc=20
    3161bis?<BR></SPAN></FONT></FONT><FONT face=3D"Times New =
Roman"><SPAN=20
    style=3D"FONT-SIZE: 12pt"><BR></SPAN></FONT><FONT=20
    face=3D"Calibri, Verdana, Helvetica, Arial"><SPAN=20
    style=3D"FONT-SIZE: 11pt">Jim,<BR><BR>You ask,<BR><FONT =
color=3D#1e487c>The=20
    question becomes can I create two certificates that can have the =
same hash,=20
    NOT will it happen by chance.<BR></FONT><BR>I <B>totally</B> agree. =
And I=20
    don&#8217;t think you can.<BR><BR>Not if the two certificates are =
signed with a=20
    good signature algorithm. <BR>If these certificates are signed with =
a bad=20
    signature algorithm that allows different certificates to share the =
same=20
    signature, then all bets are off anyway.<BR><BR>If the signature =
algorithms=20
    are good, then the signatures of these certificates will be composed =
of a=20
    substantial amount of vastly different bits. As the signature =
algorithm is=20
    good, you can&#8217;t control the bits of these signatures in any =
meaningful way,=20
    leaving you basically with a trial and error approach. That even if =
SHA-1 is=20
    broken.<BR><BR>/Stefan<BR><BR><BR>On 3/16/09 8:17 PM, "Jim Schaad" =
&lt;<A=20
    href=3D"[e-mail]">[e-mail]</A>&gt; =
wrote:<BR><FONT=20
    color=3D#1f497d>Stefan,<BR>&nbsp;<BR>The property that is being used =
is not=20
    the randomness property, it is a collision property. &nbsp;(Or more=20
    specifically resistance to collisions.) &nbsp;&nbsp;The question =
becomes can=20
    I create two certificates that can have the same hash, NOT will it =
happen by=20
    chance. &nbsp;&nbsp;If I can do so then I have a successful attack =
at this=20
    point.<BR>&nbsp;<BR>However one needs to assume that if SHA-1 is=20
    significantly broken, people will be removing it from the trusted =
algorithm=20
    list and would then need a migration path of what to put in place of =
the=20
    current SHA-1 attribute. &nbsp;This is the main reason for doing the =

    update.<BR>&nbsp;<BR>jim<BR>&nbsp;<BR></FONT><BR></SPAN></FONT><FONT =

    size=3D2><FONT face=3D"Tahoma, Verdana, Helvetica, Arial"><SPAN=20
    style=3D"FONT-SIZE: 10pt"><B>From:</B> <A=20
    =
href=3D"[e-mail]">[e-mail]</A> =
[<A=20
    =
href=3D"mailto:[e-mail]">mailto:owner-ietf-pkix@mail.=
imc.org</A>]=20
    <B>On Behalf Of </B>Stefan Santesson<BR><B>Sent:</B> Saturday, March =
14,=20
    2009 5:54 PM<BR><B>To:</B> Jim Schaad; =
'IETF-pkix'<BR><B>Subject:</B> Re: Do=20
    we need rfc 3161bis?<BR></SPAN></FONT></FONT><FONT=20
    face=3D"Times New Roman"><SPAN style=3D"FONT-SIZE: =
12pt"><BR></SPAN></FONT><FONT=20
    face=3D"Calibri, Verdana, Helvetica, Arial"><SPAN =
style=3D"FONT-SIZE: 11pt">Yes,=20
    a good question indeed.<BR><BR>Say that SHA-1 is completely broken =
in the=20
    sense that we can produce collisions at will, of all sorts and =
forms.<BR>Say=20
    also that we have a few valid TSA certificates issued for the same =
key pair,=20
    signed using good hash algorithms (or else all bets are off=20
    anyway).<BR><BR>The randomness properties of SHA-1 will remain =
intact even=20
    if SHA-1 is broken. This means that the risk/chance that two valid=20
    certificates, signed with safe signature algorithms, will by chance =
produce=20
    collisions, is still totally negligible.<BR><BR>Where am I thinking =
wrong=20
    here?<BR><BR>/Stefan<BR><BR><BR><BR>On 3/14/09 8:00 PM, "Jim Schaad" =
&lt;<A=20
    href=3D"[e-mail]">[e-mail]</A>&gt; =
wrote:<BR><FONT=20
    color=3D#1f497d>Stefan,<BR>&nbsp;<BR>The question you need to be =
asking is &#8211;=20
    Do you believe that SHA-1 will be broken one day, and if it is =
broken do you=20
    want to have in place a solution to deal with=20
    =
it.<BR>&nbsp;<BR>Jim<BR>&nbsp;<BR>&nbsp;<BR></FONT><BR></SPAN></FONT><FON=
T=20
    size=3D2><FONT face=3D"Tahoma, Verdana, Helvetica, Arial"><SPAN=20
    style=3D"FONT-SIZE: 10pt"><B>From:</B> <A=20
    =
href=3D"[e-mail]">[e-mail]</A> =
[<A=20
    =
href=3D"mailto:[e-mail]">mailto:owner-ietf-pkix@mail.=
imc.org</A>]=20
    <B>On Behalf Of </B>Stefan Santesson<BR><B>Sent:</B> Saturday, March =
14,=20
    2009 7:06 AM<BR><B>To:</B> IETF-pkix<BR><B>Subject:</B> Do we need =
rfc=20
    3161bis?<BR></SPAN></FONT></FONT><FONT face=3D"Times New =
Roman"><SPAN=20
    style=3D"FONT-SIZE: 12pt"><BR></SPAN></FONT><FONT=20
    face=3D"Calibri, Verdana, Helvetica, Arial"><SPAN =
style=3D"FONT-SIZE: 11pt">The=20
    more I look into this the more I get to doubt that we actually need=20
    3161bis.<BR><BR>The only substantial technical change I know of is =
to allow=20
    the updated ESS certIDv2 to be used to identify the signer&#8217;s =
certificate IF=20
    the TSA for some reason choose to hash its certificate with another =
hash=20
    then SHA-1.<BR><BR>The rationale for the certID identifier is given =
in=20
    section 5 of RFC 2634 and describes attacks where one valid =
certificate is=20
    substituted by another valid certificate (exceopt for some DoS case =
that I=20
    don&#8217;t think is relevant here).<BR>Now I have to ask myself. =
How likely is it=20
    that a legitimate TSA has 2 &nbsp;or more legitimate certificates =
for the=20
    same public key with conflicting information (or information =
different=20
    enough to actually have a security impact) AND where the hash of =
these=20
    certificates produce a SHA-1 collision.<BR><BR>This is not the =
previously=20
    discussed certificate collision attack using weak certificate =
signing hash,=20
    where I may prepare a certificate request in a way where I can fool =
the CA=20
    to produce two valid certificates with the same certificate =
signature. If I=20
    would use that technique I would have to find a way to prepare the =
TSA=20
    certificate requests, the TSA certificate hash need to be weak in =
addition=20
    to the certID hash AND In addition to that the complete certificates =
(not=20
    only the to be signed part) need to create a hash collision when =
computing=20
    the certID.<BR><BR>So, my first question is if this change addresses =
any=20
    real security threat?<BR>Can someone provide a reasonable threat=20
    analysis?<BR>And consequently, if there are no real threats to =
solve, does=20
    this update motivate the potential interoperability issues that =
might be the=20
    result of by allowing ESS CertIDv2 in time stamp =
tokens?<BR><BR><BR>If we do=20
    come to the conclusion that it is worth it, then why not just create =
an=20
    update RFC updating RFC 3161 instead of replacing it?<BR><BR>This =
update=20
    does not change any bits on the wire for implementations of the =
current=20
    protocol. The only thing it does is to add an option to use ESS =
certIDv2 IF=20
    SHA-1 is not used as hash to identify the TSA&#8217;s =
certificate.<BR>This seems=20
    like a perfect thing for an update RFC. Another argument is that the =
old=20
    editors that rightfully should have the credit for RFC 3161 are not =
part of=20
    this minor amendment but are completely erased from the update. That =
may be=20
    reasonable if the changes are major but I&#8217;m not so sure in =
this=20
    case.<BR><BR></SPAN></FONT></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C9A6B8.50F52E87--



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 n2H13UC8007888 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Mar 2009 18:03:30 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2H13UDV007887; Mon, 16 Mar 2009 18:03:30 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from s87.loopia.se (s87.loopia.se [194.9.95.112]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2H13Ret007878 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 16 Mar 2009 18:03:28 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 23618 invoked from network); 17 Mar 2009 01:03:36 -0000
Received: from s34.loopia.se (HELO s24.loopia.se) ([194.9.94.70]) (envelope-sender <[e-mail]>) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for <[e-mail]>; 17 Mar 2009 01:03:36 -0000
Received: (qmail 45702 invoked from network); 17 Mar 2009 01:03:25 -0000
Received: from 51.red-80-37-109.staticip.rima-tde.net (HELO [192.168.1.154]) ([e-mail]@[80.37.109.51]) (envelope-sender <[e-mail]>) by s24.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <[e-mail]>; 17 Mar 2009 01:03:25 -0000
User-Agent: Microsoft-Entourage/12.15.0.081119
Date: Tue, 17 Mar 2009 02:00:30 +0100
Subject: Re: Do we need rfc 3161bis?
From: Stefan Santesson <[e-mail]>
To: Jim Schaad <[e-mail]>, "'IETF-pkix'" <[e-mail]>
Message-ID: <[e-mail]>
Thread-Topic: Do we need rfc 3161bis?
Thread-Index: Acmkrf0j+yb7f0QChUOhT/ms/PsBpAAKRABQAAxc04EAWKrEYAAKV4S0AABPAXAAAX+taw==
In-Reply-To: <01b001c9a696$211ec660$635c5320$@com>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3320100205_9340425"
Sender: [e-mail]
Precedence: 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 message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3320100205_9340425
Content-type: text/plain;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

OK,

The prefix attack only works, as you say yourself, on the tbs bits to creat=
e
two certs with the same signature. This is ONLY possible if the signature
hash algorithm is broken. The hash in the essCertID is calculated on the
complete certificates (including signatures), not only the tbs bits.
Thus, the prefix attack is pretty useless if you have a large chunk of
random bits in the end that is bound to be different for each cert. And the=
y
will be different IF the signature algorithm of the certificates is not
broken.

The second question, sorry for missing it, is broader than just RFC 3161bis=
.

I think we have many protocols, where collision resistance is not an issue,
where we don=B9t provide algorithm agility for all uses of SHA-1. I do think
there is a use of SHA-1 in OCSP that is not part of the current update
proposal and there is currently a similar discussion in TLS where strong
arguments are raised against adding algorithm negotiation complexity when
collision resistance is not a security issue. This problem is more politica=
l
than technical. But if there is any reason to do this, it probably is for
political reasons, so your point is valid.

/Stefan

On 3/17/09 1:20 AM, "Jim Schaad" <[e-mail]> wrote:

> Stefan,
> =20
> First I don=B9t know that I agree.  I think that the entirety of your prote=
ction
> is actually given by the leading sequence/length bytes.  The object is to
> prevent a prefix attack.  One can create a prefix attack against the TBS =
bytes
> =AD leading to identical signatures for both versions of the certificate.
> However adding the leading sequence/length octets probably means that you=
 need
> to have two different prefix attacks =AD a much harder condition, but maybe
> doable.
> =20
> However I don=B9t believe that you addressed my second point at all.  That =
is
> people completely migrate away from SHA-1 because it is considered to be
> broken.
> =20
> jim
> =20
>=20
> From: Stefan Santesson [mailto:[e-mail]]
> Sent: Monday, March 16, 2009 5:09 PM
> To: Jim Schaad; 'IETF-pkix'
> Subject: Re: Do we need rfc 3161bis?
> =20
> Jim,
>=20
> You ask,
> The question becomes can I create two certificates that can have the same
> hash, NOT will it happen by chance.
>=20
> I totally agree. And I don=B9t think you can.
>=20
> Not if the two certificates are signed with a good signature algorithm.
> If these certificates are signed with a bad signature algorithm that allo=
ws
> different certificates to share the same signature, then all bets are off
> anyway.
>=20
> If the signature algorithms are good, then the signatures of these
> certificates will be composed of a substantial amount of vastly different
> bits. As the signature algorithm is good, you can=B9t control the bits of t=
hese
> signatures in any meaningful way, leaving you basically with a trial and =
error
> approach. That even if SHA-1 is broken.
>=20
> /Stefan
>=20
>=20
> On 3/16/09 8:17 PM, "Jim Schaad" <[e-mail]> wrote:
> Stefan,
> =20
> The property that is being used is not the randomness property, it is a
> collision property.  (Or more specifically resistance to collisions.)   T=
he
> question becomes can I create two certificates that can have the same has=
h,
> NOT will it happen by chance.   If I can do so then I have a successful a=
ttack
> at this point.
> =20
> However one needs to assume that if SHA-1 is significantly broken, people=
 will
> be removing it from the trusted algorithm list and would then need a migr=
ation
> path of what to put in place of the current SHA-1 attribute.  This is the=
 main
> reason for doing the update.
> =20
> jim
> =20
>=20
> From: [e-mail] [mailto:[e-mail]] =
On
> Behalf Of Stefan Santesson
> Sent: Saturday, March 14, 2009 5:54 PM
> To: Jim Schaad; 'IETF-pkix'
> Subject: Re: Do we need rfc 3161bis?
>=20
> Yes, a good question indeed.
>=20
> Say that SHA-1 is completely broken in the sense that we can produce
> collisions at will, of all sorts and forms.
> Say also that we have a few valid TSA certificates issued for the same ke=
y
> pair, signed using good hash algorithms (or else all bets are off anyway)=
.
>=20
> The randomness properties of SHA-1 will remain intact even if SHA-1 is br=
oken.
> This means that the risk/chance that two valid certificates, signed with =
safe
> signature algorithms, will by chance produce collisions, is still totally
> negligible.
>=20
> Where am I thinking wrong here?
>=20
> /Stefan
>=20
>=20
>=20
> On 3/14/09 8:00 PM, "Jim Schaad" <[e-mail]> wrote:
> Stefan,
> =20
> The question you need to be asking is =AD Do you believe that SHA-1 will be
> broken one day, and if it is broken do you want to have in place a soluti=
on to
> deal with it.
> =20
> Jim
> =20
> =20
>=20
> From: [e-mail] [mailto:[e-mail]] =
On
> Behalf Of Stefan Santesson
> Sent: Saturday, March 14, 2009 7:06 AM
> To: IETF-pkix
> Subject: Do we need rfc 3161bis?
>=20
> The more I look into this the more I get to doubt that we actually need
> 3161bis.
>=20
> The only substantial technical change I know of is to allow the updated E=
SS
> certIDv2 to be used to identify the signer=B9s certificate IF the TSA for s=
ome
> reason choose to hash its certificate with another hash then SHA-1.
>=20
> The rationale for the certID identifier is given in section 5 of RFC 2634=
 and
> describes attacks where one valid certificate is substituted by another v=
alid
> certificate (exceopt for some DoS case that I don=B9t think is relevant her=
e).
> Now I have to ask myself. How likely is it that a legitimate TSA has 2  o=
r
> more legitimate certificates for the same public key with conflicting
> information (or information different enough to actually have a security
> impact) AND where the hash of these certificates produce a SHA-1 collisio=
n.
>=20
> This is not the previously discussed certificate collision attack using w=
eak
> certificate signing hash, where I may prepare a certificate request in a =
way
> where I can fool the CA to produce two valid certificates with the same
> certificate signature. If I would use that technique I would have to find=
 a
> way to prepare the TSA certificate requests, the TSA certificate hash nee=
d to
> be weak in addition to the certID hash AND In addition to that the comple=
te
> certificates (not only the to be signed part) need to create a hash colli=
sion
> when computing the certID.
>=20
> So, my first question is if this change addresses any real security threa=
t?
> Can someone provide a reasonable threat analysis?
> And consequently, if there are no real threats to solve, does this update
> motivate the potential interoperability issues that might be the result o=
f by
> allowing ESS CertIDv2 in time stamp tokens?
>=20
>=20
> If we do come to the conclusion that it is worth it, then why not just cr=
eate
> an update RFC updating RFC 3161 instead of replacing it?
>=20
> This update does not change any bits on the wire for implementations of t=
he
> current protocol. The only thing it does is to add an option to use ESS
> certIDv2 IF SHA-1 is not used as hash to identify the TSA=B9s certificate.
> This seems like a perfect thing for an update RFC. Another argument is th=
at
> the old editors that rightfully should have the credit for RFC 3161 are n=
ot
> part of this minor amendment but are completely erased from the update. T=
hat
> may be reasonable if the changes are major but I=B9m not so sure in this ca=
se.
>=20


--B_3320100205_9340425
Content-type: text/html;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Re: Do we need rfc 3161bis?</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt=
'>OK,<BR>
<BR>
The prefix attack only works, as you say yourself, on the tbs bits to creat=
e two certs with the same signature. This is ONLY possible if the signature =
hash algorithm is broken. The hash in the essCertID is calculated on the com=
plete certificates (including signatures), not only the tbs bits.<BR>
Thus, the prefix attack is pretty useless if you have a large chunk of rand=
om bits in the end that is bound to be different for each cert. And they wil=
l be different IF the signature algorithm of the certificates is not broken.=
<BR>
<BR>
The second question, sorry for missing it, is broader than just RFC 3161bis=
.<BR>
<BR>
I think we have many protocols, where collision resistance is not an issue,=
 where we don&#8217;t provide algorithm agility for all uses of SHA-1. I do =
think there is a use of SHA-1 in OCSP that is not part of the current update=
 proposal and there is currently a similar discussion in TLS where strong ar=
guments are raised against adding algorithm negotiation complexity when coll=
ision resistance is not a security issue. This problem is more political tha=
n technical. But if there is any reason to do this, it probably is for polit=
ical reasons, so your point is valid.<BR>
<BR>
/Stefan<BR>
<BR>
On 3/17/09 1:20 AM, &quot;Jim Schaad&quot; &lt;<a href=3D"ietf@augustcellars.=
com">[e-mail]</a>&gt; wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><=
SPAN STYLE=3D'font-size:11pt'><FONT COLOR=3D"#1F497D">Stefan,<BR>
&nbsp;<BR>
First I don&#8217;t know that I agree. &nbsp;I think that the entirety of y=
our protection is actually given by the leading sequence/length bytes. &nbsp=
;The object is to prevent a prefix attack. &nbsp;One can create a prefix att=
ack against the TBS bytes &#8211; leading to identical signatures for both v=
ersions of the certificate. &nbsp;However adding the leading sequence/length=
 octets probably means that you need to have two different prefix attacks &#=
8211; a much harder condition, but maybe doable.<BR>
&nbsp;<BR>
However I don&#8217;t believe that you addressed my second point at all. &n=
bsp;That is people completely migrate away from SHA-1 because it is consider=
ed to be broken.<BR>
&nbsp;<BR>
jim<BR>
&nbsp;<BR>
</FONT><BR>
</SPAN></FONT><FONT SIZE=3D"2"><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:10pt'><B>From:</B> Stefan Santesson [<a href=3D"mailto=
:[e-mail]">mailto:[e-mail]</a>] <BR>
<B>Sent:</B> Monday, March 16, 2009 5:09 PM<BR>
<B>To:</B> Jim Schaad; 'IETF-pkix'<BR>
<B>Subject:</B> Re: Do we need rfc 3161bis?<BR>
</SPAN></FONT></FONT><FONT FACE=3D"Times New Roman"><SPAN STYLE=3D'font-size:12=
pt'> <BR>
</SPAN></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'=
font-size:11pt'>Jim,<BR>
<BR>
You ask,<BR>
<FONT COLOR=3D"#1E487C">The question becomes can I create two certificates th=
at can have the same hash, NOT will it happen by chance.<BR>
</FONT><BR>
I <B>totally</B> agree. And I don&#8217;t think you can.<BR>
<BR>
Not if the two certificates are signed with a good signature algorithm. <BR=
>
If these certificates are signed with a bad signature algorithm that allows=
 different certificates to share the same signature, then all bets are off a=
nyway.<BR>
<BR>
If the signature algorithms are good, then the signatures of these certific=
ates will be composed of a substantial amount of vastly different bits. As t=
he signature algorithm is good, you can&#8217;t control the bits of these si=
gnatures in any meaningful way, leaving you basically with a trial and error=
 approach. That even if SHA-1 is broken.<BR>
<BR>
/Stefan<BR>
<BR>
<BR>
On 3/16/09 8:17 PM, &quot;Jim Schaad&quot; &lt;<a href=3D"ietf@augustcellars.=
com">[e-mail]</a>&gt; wrote:<BR>
<FONT COLOR=3D"#1F497D">Stefan,<BR>
&nbsp;<BR>
The property that is being used is not the randomness property, it is a col=
lision property. &nbsp;(Or more specifically resistance to collisions.) &nbs=
p;&nbsp;The question becomes can I create two certificates that can have the=
 same hash, NOT will it happen by chance. &nbsp;&nbsp;If I can do so then I =
have a successful attack at this point.<BR>
&nbsp;<BR>
However one needs to assume that if SHA-1 is significantly broken, people w=
ill be removing it from the trusted algorithm list and would then need a mig=
ration path of what to put in place of the current SHA-1 attribute. &nbsp;Th=
is is the main reason for doing the update.<BR>
&nbsp;<BR>
jim<BR>
&nbsp;<BR>
</FONT><BR>
</SPAN></FONT><FONT SIZE=3D"2"><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:10pt'><B>From:</B> <a href=3D"[e-mail]=
.org">[e-mail]</a> [<a href=3D"mailto:owner-ietf-pkix@mail=
.imc.org">mailto:[e-mail]</a>] <B>On Behalf Of </B>Stefa=
n Santesson<BR>
<B>Sent:</B> Saturday, March 14, 2009 5:54 PM<BR>
<B>To:</B> Jim Schaad; 'IETF-pkix'<BR>
<B>Subject:</B> Re: Do we need rfc 3161bis?<BR>
</SPAN></FONT></FONT><FONT FACE=3D"Times New Roman"><SPAN STYLE=3D'font-size:12=
pt'><BR>
</SPAN></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'=
font-size:11pt'>Yes, a good question indeed.<BR>
<BR>
Say that SHA-1 is completely broken in the sense that we can produce collis=
ions at will, of all sorts and forms.<BR>
Say also that we have a few valid TSA certificates issued for the same key =
pair, signed using good hash algorithms (or else all bets are off anyway).<B=
R>
<BR>
The randomness properties of SHA-1 will remain intact even if SHA-1 is brok=
en. This means that the risk/chance that two valid certificates, signed with=
 safe signature algorithms, will by chance produce collisions, is still tota=
lly negligible.<BR>
<BR>
Where am I thinking wrong here?<BR>
<BR>
/Stefan<BR>
<BR>
<BR>
<BR>
On 3/14/09 8:00 PM, &quot;Jim Schaad&quot; &lt;<a href=3D"ietf@augustcellars.=
com">[e-mail]</a>&gt; wrote:<BR>
<FONT COLOR=3D"#1F497D">Stefan,<BR>
&nbsp;<BR>
The question you need to be asking is &#8211; Do you believe that SHA-1 wil=
l be broken one day, and if it is broken do you want to have in place a solu=
tion to deal with it.<BR>
&nbsp;<BR>
Jim<BR>
&nbsp;<BR>
&nbsp;<BR>
</FONT><BR>
</SPAN></FONT><FONT SIZE=3D"2"><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:10pt'><B>From:</B> <a href=3D"[e-mail]=
.org">[e-mail]</a> [<a href=3D"mailto:owner-ietf-pkix@mail=
.imc.org">mailto:[e-mail]</a>] <B>On Behalf Of </B>Stefa=
n Santesson<BR>
<B>Sent:</B> Saturday, March 14, 2009 7:06 AM<BR>
<B>To:</B> IETF-pkix<BR>
<B>Subject:</B> Do we need rfc 3161bis?<BR>
</SPAN></FONT></FONT><FONT FACE=3D"Times New Roman"><SPAN STYLE=3D'font-size:12=
pt'><BR>
</SPAN></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'=
font-size:11pt'>The more I look into this the more I get to doubt that we ac=
tually need 3161bis.<BR>
<BR>
The only substantial technical change I know of is to allow the updated ESS=
 certIDv2 to be used to identify the signer&#8217;s certificate IF the TSA f=
or some reason choose to hash its certificate with another hash then SHA-1.<=
BR>
<BR>
The rationale for the certID identifier is given in section 5 of RFC 2634 a=
nd describes attacks where one valid certificate is substituted by another v=
alid certificate (exceopt for some DoS case that I don&#8217;t think is rele=
vant here).<BR>
Now I have to ask myself. How likely is it that a legitimate TSA has 2 &nbs=
p;or more legitimate certificates for the same public key with conflicting i=
nformation (or information different enough to actually have a security impa=
ct) AND where the hash of these certificates produce a SHA-1 collision.<BR>
<BR>
This is not the previously discussed certificate collision attack using wea=
k certificate signing hash, where I may prepare a certificate request in a w=
ay where I can fool the CA to produce two valid certificates with the same c=
ertificate signature. If I would use that technique I would have to find a w=
ay to prepare the TSA certificate requests, the TSA certificate hash need to=
 be weak in addition to the certID hash AND In addition to that the complete=
 certificates (not only the to be signed part) need to create a hash collisi=
on when computing the certID.<BR>
<BR>
So, my first question is if this change addresses any real security threat?=
<BR>
Can someone provide a reasonable threat analysis?<BR>
And consequently, if there are no real threats to solve, does this update m=
otivate the potential interoperability issues that might be the result of by=
 allowing ESS CertIDv2 in time stamp tokens?<BR>
<BR>
<BR>
If we do come to the conclusion that it is worth it, then why not just crea=
te an update RFC updating RFC 3161 instead of replacing it?<BR>
<BR>
This update does not change any bits on the wire for implementations of the=
 current protocol. The only thing it does is to add an option to use ESS cer=
tIDv2 IF SHA-1 is not used as hash to identify the TSA&#8217;s certificate.<=
BR>
This seems like a perfect thing for an update RFC. Another argument is that=
 the old editors that rightfully should have the credit for RFC 3161 are not=
 part of this minor amendment but are completely erased from the update. Tha=
t may be reasonable if the changes are major but I&#8217;m not so sure in th=
is case.<BR>
<BR>
</SPAN></FONT></BLOCKQUOTE>
</BODY>
</HTML>


--B_3320100205_9340425--




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 n2H0Ka5Z005288 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Mar 2009 17:20:36 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2H0KaBp005287; Mon, 16 Mar 2009 17:20:36 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.174]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2H0KONe005274 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <[e-mail]>; Mon, 16 Mar 2009 17:20:35 -0700 (MST) (envelope-from [e-mail])
Received: from GALATIONS (unknown [207.202.179.27]) by smtp4.pacifier.net (Postfix) with ESMTP id E880A6A554; Mon, 16 Mar 2009 17:20:18 -0700 (PDT)
From: "Jim Schaad" <[e-mail]>
To: "'Stefan Santesson'" <[e-mail]>, "'IETF-pkix'" <[e-mail]>
References: <015c01c9a66b$d78048f0$8680dad0$@com> <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: RE: Do we need rfc 3161bis?
Date: Mon, 16 Mar 2009 17:20:06 -0700
Message-ID: <01b001c9a696$211ec660$635c5320$@com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_01B1_01C9A65B.74BFEE60"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Acmkrf0j+yb7f0QChUOhT/ms/PsBpAAKRABQAAxc04EAWKrEYAAKV4S0AABPAXA=
Content-Language: en-us
Sender: [e-mail]
Precedence: 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 multipart message in MIME format.

------=_NextPart_000_01B1_01C9A65B.74BFEE60
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Stefan,

 

First I don't know that I agree.  I think that the entirety of your
protection is actually given by the leading sequence/length bytes.  The
object is to prevent a prefix attack.  One can create a prefix attack
against the TBS bytes - leading to identical signatures for both versions of
the certificate.  However adding the leading sequence/length octets probably
means that you need to have two different prefix attacks - a much harder
condition, but maybe doable.

 

However I don't believe that you addressed my second point at all.  That is
people completely migrate away from SHA-1 because it is considered to be
broken.

 

jim

 

From: Stefan Santesson [mailto:[e-mail]] 
Sent: Monday, March 16, 2009 5:09 PM
To: Jim Schaad; 'IETF-pkix'
Subject: Re: Do we need rfc 3161bis?

 

Jim,

You ask,
The question becomes can I create two certificates that can have the same
hash, NOT will it happen by chance.

I totally agree. And I don't think you can.

Not if the two certificates are signed with a good signature algorithm. 
If these certificates are signed with a bad signature algorithm that allows
different certificates to share the same signature, then all bets are off
anyway.

If the signature algorithms are good, then the signatures of these
certificates will be composed of a substantial amount of vastly different
bits. As the signature algorithm is good, you can't control the bits of
these signatures in any meaningful way, leaving you basically with a trial
and error approach. That even if SHA-1 is broken.

/Stefan


On 3/16/09 8:17 PM, "Jim Schaad" <[e-mail]> wrote:

Stefan,
 
The property that is being used is not the randomness property, it is a
collision property.  (Or more specifically resistance to collisions.)   The
question becomes can I create two certificates that can have the same hash,
NOT will it happen by chance.   If I can do so then I have a successful
attack at this point.
 
However one needs to assume that if SHA-1 is significantly broken, people
will be removing it from the trusted algorithm list and would then need a
migration path of what to put in place of the current SHA-1 attribute.  This
is the main reason for doing the update.
 
jim
 

From: [e-mail] [mailto:[e-mail]] On
Behalf Of Stefan Santesson
Sent: Saturday, March 14, 2009 5:54 PM
To: Jim Schaad; 'IETF-pkix'
Subject: Re: Do we need rfc 3161bis?

Yes, a good question indeed.

Say that SHA-1 is completely broken in the sense that we can produce
collisions at will, of all sorts and forms.
Say also that we have a few valid TSA certificates issued for the same key
pair, signed using good hash algorithms (or else all bets are off anyway).

The randomness properties of SHA-1 will remain intact even if SHA-1 is
broken. This means that the risk/chance that two valid certificates, signed
with safe signature algorithms, will by chance produce collisions, is still
totally negligible.

Where am I thinking wrong here?

/Stefan



On 3/14/09 8:00 PM, "Jim Schaad" <[e-mail]> wrote:
Stefan,
 
The question you need to be asking is - Do you believe that SHA-1 will be
broken one day, and if it is broken do you want to have in place a solution
to deal with it.
 
Jim
 
 

From: [e-mail] [mailto:[e-mail]] On
Behalf Of Stefan Santesson
Sent: Saturday, March 14, 2009 7:06 AM
To: IETF-pkix
Subject: Do we need rfc 3161bis?

The more I look into this the more I get to doubt that we actually need
3161bis.

The only substantial technical change I know of is to allow the updated ESS
certIDv2 to be used to identify the signer's certificate IF the TSA for some
reason choose to hash its certificate with another hash then SHA-1.

The rationale for the certID identifier is given in section 5 of RFC 2634
and describes attacks where one valid certificate is substituted by another
valid certificate (exceopt for some DoS case that I don't think is relevant
here).
Now I have to ask myself. How likely is it that a legitimate TSA has 2  or
more legitimate certificates for the same public key with conflicting
information (or information different enough to actually have a security
impact) AND where the hash of these certificates produce a SHA-1 collision.

This is not the previously discussed certificate collision attack using weak
certificate signing hash, where I may prepare a certificate request in a way
where I can fool the CA to produce two valid certificates with the same
certificate signature. If I would use that technique I would have to find a
way to prepare the TSA certificate requests, the TSA certificate hash need
to be weak in addition to the certID hash AND In addition to that the
complete certificates (not only the to be signed part) need to create a hash
collision when computing the certID.

So, my first question is if this change addresses any real security threat?
Can someone provide a reasonable threat analysis?
And consequently, if there are no real threats to solve, does this update
motivate the potential interoperability issues that might be the result of
by allowing ESS CertIDv2 in time stamp tokens?


If we do come to the conclusion that it is worth it, then why not just
create an update RFC updating RFC 3161 instead of replacing it?

This update does not change any bits on the wire for implementations of the
current protocol. The only thing it does is to add an option to use ESS
certIDv2 IF SHA-1 is not used as hash to identify the TSA's certificate.
This seems like a perfect thing for an update RFC. Another argument is that
the old editors that rightfully should have the credit for RFC 3161 are not
part of this minor amendment but are completely erased from the update. That
may be reasonable if the changes are major but I'm not so sure in this case.


------=_NextPart_000_01B1_01C9A65B.74BFEE60
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)">
<title>Re: Do we need rfc 3161bis?</title>
<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;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","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-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:1.0in 1.0in 1.0in 1.0in;}
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'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Stefan,<o:p></o:p></span></p>

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

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>First I don&#8217;t know that I agree.&nbsp; I think that =
the entirety of
your protection is actually given by the leading sequence/length =
bytes.&nbsp; The
object is to prevent a prefix attack.&nbsp; One can create a prefix =
attack against
the TBS bytes &#8211; leading to identical signatures for both versions =
of the
certificate.&nbsp; However adding the leading sequence/length octets =
probably means
that you need to have two different prefix attacks &#8211; a much harder =
condition,
but maybe doable.<o:p></o:p></span></p>

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

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>However I don&#8217;t believe that you addressed my =
second point at
all.&nbsp; That is people completely migrate away from SHA-1 because it =
is
considered to be broken.<o:p></o:p></span></p>

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

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>jim<o:p></o:p></span></p>

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

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

<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> Monday, March 16, 2009 5:09 PM<br>
<b>To:</b> Jim Schaad; 'IETF-pkix'<br>
<b>Subject:</b> Re: Do we need rfc 3161bis?<o:p></o:p></span></p>

</div>

</div>

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

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><span =
style=3D'font-size:11.0pt;
font-family:"Calibri","sans-serif"'>Jim,<br>
<br>
You ask,<br>
<span style=3D'color:#1E487C'>The question becomes can I create two =
certificates
that can have the same hash, NOT will it happen by chance.<br>
</span><br>
I <b>totally</b> agree. And I don&#8217;t think you can.<br>
<br>
Not if the two certificates are signed with a good signature algorithm. =
<br>
If these certificates are signed with a bad signature algorithm that =
allows
different certificates to share the same signature, then all bets are =
off
anyway.<br>
<br>
If the signature algorithms are good, then the signatures of these =
certificates
will be composed of a substantial amount of vastly different bits. As =
the
signature algorithm is good, you can&#8217;t control the bits of these =
signatures in
any meaningful way, leaving you basically with a trial and error =
approach. That
even if SHA-1 is broken.<br>
<br>
/Stefan<br>
<br>
<br>
On 3/16/09 8:17 PM, &quot;Jim Schaad&quot; &lt;<a =
href=3D"[e-mail]">[e-mail]</a>&gt;
wrote:</span><o:p></o:p></p>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><span =
style=3D'font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'>Stefan,<br>
&nbsp;<br>
The property that is being used is not the randomness property, it is a
collision property. &nbsp;(Or more specifically resistance to =
collisions.)
&nbsp;&nbsp;The question becomes can I create two certificates that can =
have
the same hash, NOT will it happen by chance. &nbsp;&nbsp;If I can do so =
then I
have a successful attack at this point.<br>
&nbsp;<br>
However one needs to assume that if SHA-1 is significantly broken, =
people will
be removing it from the trusted algorithm list and would then need a =
migration
path of what to put in place of the current SHA-1 attribute. &nbsp;This =
is the
main reason for doing the update.<br>
&nbsp;<br>
jim<br>
&nbsp;<br>
</span><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'><br>
</span><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"'> <a
href=3D"[e-mail]">[e-mail]</a> =
[<a
href=3D"mailto:[e-mail]">mailto:owner-ietf-pkix@mail.=
imc.org</a>]
<b>On Behalf Of </b>Stefan Santesson<br>
<b>Sent:</b> Saturday, March 14, 2009 5:54 PM<br>
<b>To:</b> Jim Schaad; 'IETF-pkix'<br>
<b>Subject:</b> Re: Do we need rfc 3161bis?<br>
</span><br>
<span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>Yes, =
a good
question indeed.<br>
<br>
Say that SHA-1 is completely broken in the sense that we can produce =
collisions
at will, of all sorts and forms.<br>
Say also that we have a few valid TSA certificates issued for the same =
key
pair, signed using good hash algorithms (or else all bets are off =
anyway).<br>
<br>
The randomness properties of SHA-1 will remain intact even if SHA-1 is =
broken.
This means that the risk/chance that two valid certificates, signed with =
safe
signature algorithms, will by chance produce collisions, is still =
totally
negligible.<br>
<br>
Where am I thinking wrong here?<br>
<br>
/Stefan<br>
<br>
<br>
<br>
On 3/14/09 8:00 PM, &quot;Jim Schaad&quot; &lt;<a =
href=3D"[e-mail]">[e-mail]</a>&gt;
wrote:<br>
<span style=3D'color:#1F497D'>Stefan,<br>
&nbsp;<br>
The question you need to be asking is &#8211; Do you believe that SHA-1 =
will be
broken one day, and if it is broken do you want to have in place a =
solution to
deal with it.<br>
&nbsp;<br>
Jim<br>
&nbsp;<br>
&nbsp;<br>
</span><br>
</span><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"'> <a
href=3D"[e-mail]">[e-mail]</a> =
[<a
href=3D"mailto:[e-mail]">mailto:owner-ietf-pkix@mail.=
imc.org</a>]
<b>On Behalf Of </b>Stefan Santesson<br>
<b>Sent:</b> Saturday, March 14, 2009 7:06 AM<br>
<b>To:</b> IETF-pkix<br>
<b>Subject:</b> Do we need rfc 3161bis?<br>
</span><br>
<span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>The =
more I
look into this the more I get to doubt that we actually need =
3161bis.<br>
<br>
The only substantial technical change I know of is to allow the updated =
ESS
certIDv2 to be used to identify the signer&#8217;s certificate IF the =
TSA for some
reason choose to hash its certificate with another hash then SHA-1.<br>
<br>
The rationale for the certID identifier is given in section 5 of RFC =
2634 and
describes attacks where one valid certificate is substituted by another =
valid
certificate (exceopt for some DoS case that I don&#8217;t think is =
relevant here).<br>
Now I have to ask myself. How likely is it that a legitimate TSA has 2 =
&nbsp;or
more legitimate certificates for the same public key with conflicting
information (or information different enough to actually have a security
impact) AND where the hash of these certificates produce a SHA-1 =
collision.<br>
<br>
This is not the previously discussed certificate collision attack using =
weak
certificate signing hash, where I may prepare a certificate request in a =
way
where I can fool the CA to produce two valid certificates with the same
certificate signature. If I would use that technique I would have to =
find a way
to prepare the TSA certificate requests, the TSA certificate hash need =
to be
weak in addition to the certID hash AND In addition to that the complete
certificates (not only the to be signed part) need to create a hash =
collision
when computing the certID.<br>
<br>
So, my first question is if this change addresses any real security =
threat?<br>
Can someone provide a reasonable threat analysis?<br>
And consequently, if there are no real threats to solve, does this =
update
motivate the potential interoperability issues that might be the result =
of by
allowing ESS CertIDv2 in time stamp tokens?<br>
<br>
<br>
If we do come to the conclusion that it is worth it, then why not just =
create
an update RFC updating RFC 3161 instead of replacing it?<br>
<br>
This update does not change any bits on the wire for implementations of =
the
current protocol. The only thing it does is to add an option to use ESS
certIDv2 IF SHA-1 is not used as hash to identify the TSA&#8217;s =
certificate.<br>
This seems like a perfect thing for an update RFC. Another argument is =
that the
old editors that rightfully should have the credit for RFC 3161 are not =
part of
this minor amendment but are completely erased from the update. That may =
be
reasonable if the changes are major but I&#8217;m not so sure in this =
case.</span><o:p></o:p></p>

</div>

</div>

</body>

</html>

------=_NextPart_000_01B1_01C9A65B.74BFEE60--



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 n2H092Mo004595 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Mar 2009 17:09:02 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2H092fl004594; Mon, 16 Mar 2009 17:09:02 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from s87.loopia.se (s87.loopia.se [194.9.95.112]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2H08nSD004573 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 16 Mar 2009 17:09:01 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 3340 invoked from network); 17 Mar 2009 00:08:57 -0000
Received: from s34.loopia.se (HELO s57.loopia.se) ([194.9.94.70]) (envelope-sender <[e-mail]>) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for <[e-mail]>; 17 Mar 2009 00:08:57 -0000
Received: (qmail 11165 invoked from network); 17 Mar 2009 00:08:47 -0000
Received: from 51.red-80-37-109.staticip.rima-tde.net (HELO [192.168.1.154]) ([e-mail]@[80.37.109.51]) (envelope-sender <[e-mail]>) by s57.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <[e-mail]>; 17 Mar 2009 00:08:47 -0000
User-Agent: Microsoft-Entourage/12.15.0.081119
Date: Tue, 17 Mar 2009 01:08:45 +0100
Subject: Re: Do we need rfc 3161bis?
From: Stefan Santesson <[e-mail]>
To: Jim Schaad <[e-mail]>, "'IETF-pkix'" <[e-mail]>
Message-ID: <[e-mail]>
Thread-Topic: Do we need rfc 3161bis?
Thread-Index: Acmkrf0j+yb7f0QChUOhT/ms/PsBpAAKRABQAAxc04EAWKrEYAAKV4S0
In-Reply-To: <015c01c9a66b$d78048f0$8680dad0$@com>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3320096927_9156048"
Sender: [e-mail]
Precedence: 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 message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3320096927_9156048
Content-type: text/plain;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

Jim,

You ask,
The question becomes can I create two certificates that can have the same
hash, NOT will it happen by chance.

I totally agree. And I don=B9t think you can.

Not if the two certificates are signed with a good signature algorithm.
If these certificates are signed with a bad signature algorithm that allows
different certificates to share the same signature, then all bets are off
anyway.

If the signature algorithms are good, then the signatures of these
certificates will be composed of a substantial amount of vastly different
bits. As the signature algorithm is good, you can=B9t control the bits of
these signatures in any meaningful way, leaving you basically with a trial
and error approach. That even if SHA-1 is broken.

/Stefan


On 3/16/09 8:17 PM, "Jim Schaad" <[e-mail]> wrote:

> Stefan,
> =20
> The property that is being used is not the randomness property, it is a
> collision property.  (Or more specifically resistance to collisions.)   T=
he
> question becomes can I create two certificates that can have the same has=
h,
> NOT will it happen by chance.   If I can do so then I have a successful a=
ttack
> at this point.
> =20
> However one needs to assume that if SHA-1 is significantly broken, people=
 will
> be removing it from the trusted algorithm list and would then need a migr=
ation
> path of what to put in place of the current SHA-1 attribute.  This is the=
 main
> reason for doing the update.
> =20
> jim
> =20
>=20
> From: [e-mail] [mailto:[e-mail]] =
On
> Behalf Of Stefan Santesson
> Sent: Saturday, March 14, 2009 5:54 PM
> To: Jim Schaad; 'IETF-pkix'
> Subject: Re: Do we need rfc 3161bis?
> =20
> Yes, a good question indeed.
>=20
> Say that SHA-1 is completely broken in the sense that we can produce
> collisions at will, of all sorts and forms.
> Say also that we have a few valid TSA certificates issued for the same ke=
y
> pair, signed using good hash algorithms (or else all bets are off anyway)=
.
>=20
> The randomness properties of SHA-1 will remain intact even if SHA-1 is br=
oken.
> This means that the risk/chance that two valid certificates, signed with =
safe
> signature algorithms, will by chance produce collisions, is still totally
> negligible.
>=20
> Where am I thinking wrong here?
>=20
> /Stefan
>=20
>=20
>=20
> On 3/14/09 8:00 PM, "Jim Schaad" <[e-mail]> wrote:
> Stefan,
> =20
> The question you need to be asking is =AD Do you believe that SHA-1 will be
> broken one day, and if it is broken do you want to have in place a soluti=
on to
> deal with it.
> =20
> Jim
> =20
> =20
>=20
> From: [e-mail] [mailto:[e-mail]] =
On
> Behalf Of Stefan Santesson
> Sent: Saturday, March 14, 2009 7:06 AM
> To: IETF-pkix
> Subject: Do we need rfc 3161bis?
>=20
> The more I look into this the more I get to doubt that we actually need
> 3161bis.
>=20
> The only substantial technical change I know of is to allow the updated E=
SS
> certIDv2 to be used to identify the signer=B9s certificate IF the TSA for s=
ome
> reason choose to hash its certificate with another hash then SHA-1.
>=20
> The rationale for the certID identifier is given in section 5 of RFC 2634=
 and
> describes attacks where one valid certificate is substituted by another v=
alid
> certificate (exceopt for some DoS case that I don=B9t think is relevant her=
e).
> Now I have to ask myself. How likely is it that a legitimate TSA has 2  o=
r
> more legitimate certificates for the same public key with conflicting
> information (or information different enough to actually have a security
> impact) AND where the hash of these certificates produce a SHA-1 collisio=
n.
>=20
> This is not the previously discussed certificate collision attack using w=
eak
> certificate signing hash, where I may prepare a certificate request in a =
way
> where I can fool the CA to produce two valid certificates with the same
> certificate signature. If I would use that technique I would have to find=
 a
> way to prepare the TSA certificate requests, the TSA certificate hash nee=
d to
> be weak in addition to the certID hash AND In addition to that the comple=
te
> certificates (not only the to be signed part) need to create a hash colli=
sion
> when computing the certID.
>=20
> So, my first question is if this change addresses any real security threa=
t?
> Can someone provide a reasonable threat analysis?
> And consequently, if there are no real threats to solve, does this update
> motivate the potential interoperability issues that might be the result o=
f by
> allowing ESS CertIDv2 in time stamp tokens?
>=20
>=20
> If we do come to the conclusion that it is worth it, then why not just cr=
eate
> an update RFC updating RFC 3161 instead of replacing it?
>=20
> This update does not change any bits on the wire for implementations of t=
he
> current protocol. The only thing it does is to add an option to use ESS
> certIDv2 IF SHA-1 is not used as hash to identify the TSA=B9s certificate.
> This seems like a perfect thing for an update RFC. Another argument is th=
at
> the old editors that rightfully should have the credit for RFC 3161 are n=
ot
> part of this minor amendment but are completely erased from the update. T=
hat
> may be reasonable if the changes are major but I=B9m not so sure in this ca=
se.
>=20


--B_3320096927_9156048
Content-type: text/html;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Re: Do we need rfc 3161bis?</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt=
'>Jim,<BR>
<BR>
You ask,<BR>
<FONT COLOR=3D"#1E487C">The question becomes can I create two certificates th=
at can have the same hash, NOT will it happen by chance.<BR>
</FONT><BR>
I <B>totally</B> agree. And I don&#8217;t think you can.<BR>
<BR>
Not if the two certificates are signed with a good signature algorithm. <BR=
>
If these certificates are signed with a bad signature algorithm that allows=
 different certificates to share the same signature, then all bets are off a=
nyway.<BR>
<BR>
If the signature algorithms are good, then the signatures of these certific=
ates will be composed of a substantial amount of vastly different bits. As t=
he signature algorithm is good, you can&#8217;t control the bits of these si=
gnatures in any meaningful way, leaving you basically with a trial and error=
 approach. That even if SHA-1 is broken.<BR>
<BR>
/Stefan<BR>
<BR>
<BR>
On 3/16/09 8:17 PM, &quot;Jim Schaad&quot; &lt;<a href=3D"ietf@augustcellars.=
com">[e-mail]</a>&gt; wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><=
SPAN STYLE=3D'font-size:11pt'><FONT COLOR=3D"#1F497D">Stefan,<BR>
&nbsp;<BR>
The property that is being used is not the randomness property, it is a col=
lision property. &nbsp;(Or more specifically resistance to collisions.) &nbs=
p;&nbsp;The question becomes can I create two certificates that can have the=
 same hash, NOT will it happen by chance. &nbsp;&nbsp;If I can do so then I =
have a successful attack at this point.<BR>
&nbsp;<BR>
However one needs to assume that if SHA-1 is significantly broken, people w=
ill be removing it from the trusted algorithm list and would then need a mig=
ration path of what to put in place of the current SHA-1 attribute. &nbsp;Th=
is is the main reason for doing the update.<BR>
&nbsp;<BR>
jim<BR>
&nbsp;<BR>
</FONT><BR>
</SPAN></FONT><FONT SIZE=3D"2"><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:10pt'><B>From:</B> <a href=3D"[e-mail]=
.org">[e-mail]</a> [<a href=3D"mailto:owner-ietf-pkix@mail=
.imc.org">mailto:[e-mail]</a>] <B>On Behalf Of </B>Stefa=
n Santesson<BR>
<B>Sent:</B> Saturday, March 14, 2009 5:54 PM<BR>
<B>To:</B> Jim Schaad; 'IETF-pkix'<BR>
<B>Subject:</B> Re: Do we need rfc 3161bis?<BR>
</SPAN></FONT></FONT><FONT FACE=3D"Times New Roman"><SPAN STYLE=3D'font-size:12=
pt'> <BR>
</SPAN></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'=
font-size:11pt'>Yes, a good question indeed.<BR>
<BR>
Say that SHA-1 is completely broken in the sense that we can produce collis=
ions at will, of all sorts and forms.<BR>
Say also that we have a few valid TSA certificates issued for the same key =
pair, signed using good hash algorithms (or else all bets are off anyway).<B=
R>
<BR>
The randomness properties of SHA-1 will remain intact even if SHA-1 is brok=
en. This means that the risk/chance that two valid certificates, signed with=
 safe signature algorithms, will by chance produce collisions, is still tota=
lly negligible.<BR>
<BR>
Where am I thinking wrong here?<BR>
<BR>
/Stefan<BR>
<BR>
<BR>
<BR>
On 3/14/09 8:00 PM, &quot;Jim Schaad&quot; &lt;<a href=3D"ietf@augustcellars.=
com">[e-mail]</a>&gt; wrote:<BR>
<FONT COLOR=3D"#1F497D">Stefan,<BR>
&nbsp;<BR>
The question you need to be asking is &#8211; Do you believe that SHA-1 wil=
l be broken one day, and if it is broken do you want to have in place a solu=
tion to deal with it.<BR>
&nbsp;<BR>
Jim<BR>
&nbsp;<BR>
&nbsp;<BR>
</FONT><BR>
</SPAN></FONT><FONT SIZE=3D"2"><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:10pt'><B>From:</B> <a href=3D"[e-mail]=
.org">[e-mail]</a> [<a href=3D"mailto:owner-ietf-pkix@mail=
.imc.org">mailto:[e-mail]</a>] <B>On Behalf Of </B>Stefa=
n Santesson<BR>
<B>Sent:</B> Saturday, March 14, 2009 7:06 AM<BR>
<B>To:</B> IETF-pkix<BR>
<B>Subject:</B> Do we need rfc 3161bis?<BR>
</SPAN></FONT></FONT><FONT FACE=3D"Times New Roman"><SPAN STYLE=3D'font-size:12=
pt'><BR>
</SPAN></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'=
font-size:11pt'>The more I look into this the more I get to doubt that we ac=
tually need 3161bis.<BR>
<BR>
The only substantial technical change I know of is to allow the updated ESS=
 certIDv2 to be used to identify the signer&#8217;s certificate IF the TSA f=
or some reason choose to hash its certificate with another hash then SHA-1.<=
BR>
<BR>
The rationale for the certID identifier is given in section 5 of RFC 2634 a=
nd describes attacks where one valid certificate is substituted by another v=
alid certificate (exceopt for some DoS case that I don&#8217;t think is rele=
vant here).<BR>
Now I have to ask myself. How likely is it that a legitimate TSA has 2 &nbs=
p;or more legitimate certificates for the same public key with conflicting i=
nformation (or information different enough to actually have a security impa=
ct) AND where the hash of these certificates produce a SHA-1 collision.<BR>
<BR>
This is not the previously discussed certificate collision attack using wea=
k certificate signing hash, where I may prepare a certificate request in a w=
ay where I can fool the CA to produce two valid certificates with the same c=
ertificate signature. If I would use that technique I would have to find a w=
ay to prepare the TSA certificate requests, the TSA certificate hash need to=
 be weak in addition to the certID hash AND In addition to that the complete=
 certificates (not only the to be signed part) need to create a hash collisi=
on when computing the certID.<BR>
<BR>
So, my first question is if this change addresses any real security threat?=
<BR>
Can someone provide a reasonable threat analysis?<BR>
And consequently, if there are no real threats to solve, does this update m=
otivate the potential interoperability issues that might be the result of by=
 allowing ESS CertIDv2 in time stamp tokens?<BR>
<BR>
<BR>
If we do come to the conclusion that it is worth it, then why not just crea=
te an update RFC updating RFC 3161 instead of replacing it?<BR>
<BR>
This update does not change any bits on the wire for implementations of the=
 current protocol. The only thing it does is to add an option to use ESS cer=
tIDv2 IF SHA-1 is not used as hash to identify the TSA&#8217;s certificate.<=
BR>
This seems like a perfect thing for an update RFC. Another argument is that=
 the old editors that rightfully should have the credit for RFC 3161 are not=
 part of this minor amendment but are completely erased from the update. Tha=
t may be reasonable if the changes are major but I&#8217;m not so sure in th=
is case.<BR>
<BR>
</SPAN></FONT></BLOCKQUOTE>
</BODY>
</HTML>


--B_3320096927_9156048--




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 n2GJHnf8086118 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Mar 2009 12:17:49 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2GJHnvL086117; Mon, 16 Mar 2009 12:17:49 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2GJHcnK086105 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <[e-mail]>; Mon, 16 Mar 2009 12:17:48 -0700 (MST) (envelope-from [e-mail])
Received: from GALATIONS (unknown [207.202.179.27]) by smtp1.pacifier.net (Postfix) with ESMTP id 979366F00C; Mon, 16 Mar 2009 12:17:36 -0700 (PDT)
From: "Jim Schaad" <[e-mail]>
To: "'Stefan Santesson'" <[e-mail]>, "'IETF-pkix'" <[e-mail]>
References: <082801c9a4d7$2d24f350$876ed9f0$@com> <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: RE: Do we need rfc 3161bis?
Date: Mon, 16 Mar 2009 12:17:25 -0700
Message-ID: <015c01c9a66b$d78048f0$8680dad0$@com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_015D_01C9A631.2B2170F0"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Acmkrf0j+yb7f0QChUOhT/ms/PsBpAAKRABQAAxc04EAWKrEYA==
Content-Language: en-us
Sender: [e-mail]
Precedence: 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 multipart message in MIME format.

------=_NextPart_000_015D_01C9A631.2B2170F0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Stefan,

 

The property that is being used is not the randomness property, it is a
collision property.  (Or more specifically resistance to collisions.)   The
question becomes can I create two certificates that can have the same hash,
NOT will it happen by chance.   If I can do so then I have a successful
attack at this point.

 

However one needs to assume that if SHA-1 is significantly broken, people
will be removing it from the trusted algorithm list and would then need a
migration path of what to put in place of the current SHA-1 attribute.  This
is the main reason for doing the update.

 

jim

 

From: [e-mail] [mailto:[e-mail]] On
Behalf Of Stefan Santesson
Sent: Saturday, March 14, 2009 5:54 PM
To: Jim Schaad; 'IETF-pkix'
Subject: Re: Do we need rfc 3161bis?

 

Yes, a good question indeed.

Say that SHA-1 is completely broken in the sense that we can produce
collisions at will, of all sorts and forms.
Say also that we have a few valid TSA certificates issued for the same key
pair, signed using good hash algorithms (or else all bets are off anyway).

The randomness properties of SHA-1 will remain intact even if SHA-1 is
broken. This means that the risk/chance that two valid certificates, signed
with safe signature algorithms, will by chance produce collisions, is still
totally negligible.

Where am I thinking wrong here?

/Stefan



On 3/14/09 8:00 PM, "Jim Schaad" <[e-mail]> wrote:

Stefan,
 
The question you need to be asking is - Do you believe that SHA-1 will be
broken one day, and if it is broken do you want to have in place a solution
to deal with it.
 
Jim
 
 

From: [e-mail] [mailto:[e-mail]] On
Behalf Of Stefan Santesson
Sent: Saturday, March 14, 2009 7:06 AM
To: IETF-pkix
Subject: Do we need rfc 3161bis?

The more I look into this the more I get to doubt that we actually need
3161bis.

The only substantial technical change I know of is to allow the updated ESS
certIDv2 to be used to identify the signer's certificate IF the TSA for some
reason choose to hash its certificate with another hash then SHA-1.

The rationale for the certID identifier is given in section 5 of RFC 2634
and describes attacks where one valid certificate is substituted by another
valid certificate (exceopt for some DoS case that I don't think is relevant
here).
Now I have to ask myself. How likely is it that a legitimate TSA has 2  or
more legitimate certificates for the same public key with conflicting
information (or information different enough to actually have a security
impact) AND where the hash of these certificates produce a SHA-1 collision.

This is not the previously discussed certificate collision attack using weak
certificate signing hash, where I may prepare a certificate request in a way
where I can fool the CA to produce two valid certificates with the same
certificate signature. If I would use that technique I would have to find a
way to prepare the TSA certificate requests, the TSA certificate hash need
to be weak in addition to the certID hash AND In addition to that the
complete certificates (not only the to be signed part) need to create a hash
collision when computing the certID.

So, my first question is if this change addresses any real security threat?
Can someone provide a reasonable threat analysis?
And consequently, if there are no real threats to solve, does this update
motivate the potential interoperability issues that might be the result of
by allowing ESS CertIDv2 in time stamp tokens?


If we do come to the conclusion that it is worth it, then why not just
create an update RFC updating RFC 3161 instead of replacing it?

This update does not change any bits on the wire for implementations of the
current protocol. The only thing it does is to add an option to use ESS
certIDv2 IF SHA-1 is not used as hash to identify the TSA's certificate.
This seems like a perfect thing for an update RFC. Another argument is that
the old editors that rightfully should have the credit for RFC 3161 are not
part of this minor amendment but are completely erased from the update. That
may be reasonable if the changes are major but I'm not so sure in this case.


------=_NextPart_000_015D_01C9A631.2B2170F0
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=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<title>Re: Do we need rfc 3161bis?</title>
<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;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","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-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:1.0in 1.0in 1.0in 1.0in;}
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'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Stefan,<o:p></o:p></span></p>

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

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>The property that is being used is not the randomness =
property,
it is a collision property.&nbsp; (Or more specifically resistance to
collisions.)&nbsp;&nbsp; The question becomes can I create two =
certificates
that can have the same hash, NOT will it happen by chance. =
&nbsp;&nbsp;If I can
do so then I have a successful attack at this =
point.<o:p></o:p></span></p>

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

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>However one needs to assume that if SHA-1 is =
significantly
broken, people will be removing it from the trusted algorithm list and =
would
then need a migration path of what to put in place of the current SHA-1
attribute.&nbsp; This is the main reason for doing the =
update.<o:p></o:p></span></p>

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

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>jim<o:p></o:p></span></p>

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

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

<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"'> =
[e-mail]
[mailto:[e-mail]] <b>On Behalf Of </b>Stefan =
Santesson<br>
<b>Sent:</b> Saturday, March 14, 2009 5:54 PM<br>
<b>To:</b> Jim Schaad; 'IETF-pkix'<br>
<b>Subject:</b> Re: Do we need rfc 3161bis?<o:p></o:p></span></p>

</div>

</div>

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

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><span =
style=3D'font-size:11.0pt;
font-family:"Calibri","sans-serif"'>Yes, a good question indeed.<br>
<br>
Say that SHA-1 is completely broken in the sense that we can produce =
collisions
at will, of all sorts and forms.<br>
Say also that we have a few valid TSA certificates issued for the same =
key
pair, signed using good hash algorithms (or else all bets are off =
anyway).<br>
<br>
The randomness properties of SHA-1 will remain intact even if SHA-1 is =
broken.
This means that the risk/chance that two valid certificates, signed with =
safe
signature algorithms, will by chance produce collisions, is still =
totally
negligible.<br>
<br>
Where am I thinking wrong here?<br>
<br>
/Stefan<br>
<br>
<br>
<br>
On 3/14/09 8:00 PM, &quot;Jim Schaad&quot; &lt;<a =
href=3D"[e-mail]">[e-mail]</a>&gt;
wrote:</span><o:p></o:p></p>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><span =
style=3D'font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'>Stefan,<br>
&nbsp;<br>
The question you need to be asking is &#8211; Do you believe that SHA-1 =
will be
broken one day, and if it is broken do you want to have in place a =
solution to
deal with it.<br>
&nbsp;<br>
Jim<br>
&nbsp;<br>
&nbsp;<br>
</span><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'><br>
</span><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"'> <a
href=3D"[e-mail]">[e-mail]</a> =
[<a
href=3D"mailto:[e-mail]">mailto:owner-ietf-pkix@mail.=
imc.org</a>]
<b>On Behalf Of </b>Stefan Santesson<br>
<b>Sent:</b> Saturday, March 14, 2009 7:06 AM<br>
<b>To:</b> IETF-pkix<br>
<b>Subject:</b> Do we need rfc 3161bis?<br>
</span><br>
<span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>The =
more I
look into this the more I get to doubt that we actually need =
3161bis.<br>
<br>
The only substantial technical change I know of is to allow the updated =
ESS
certIDv2 to be used to identify the signer&#8217;s certificate IF the =
TSA for
some reason choose to hash its certificate with another hash then =
SHA-1.<br>
<br>
The rationale for the certID identifier is given in section 5 of RFC =
2634 and
describes attacks where one valid certificate is substituted by another =
valid
certificate (exceopt for some DoS case that I don&#8217;t think is =
relevant
here).<br>
Now I have to ask myself. How likely is it that a legitimate TSA has 2 =
&nbsp;or
more legitimate certificates for the same public key with conflicting
information (or information different enough to actually have a security
impact) AND where the hash of these certificates produce a SHA-1 =
collision.<br>
<br>
This is not the previously discussed certificate collision attack using =
weak
certificate signing hash, where I may prepare a certificate request in a =
way
where I can fool the CA to produce two valid certificates with the same
certificate signature. If I would use that technique I would have to =
find a way
to prepare the TSA certificate requests, the TSA certificate hash need =
to be
weak in addition to the certID hash AND In addition to that the complete
certificates (not only the to be signed part) need to create a hash =
collision
when computing the certID.<br>
<br>
So, my first question is if this change addresses any real security =
threat?<br>
Can someone provide a reasonable threat analysis?<br>
And consequently, if there are no real threats to solve, does this =
update
motivate the potential interoperability issues that might be the result =
of by
allowing ESS CertIDv2 in time stamp tokens?<br>
<br>
<br>
If we do come to the conclusion that it is worth it, then why not just =
create an
update RFC updating RFC 3161 instead of replacing it?<br>
<br>
This update does not change any bits on the wire for implementations of =
the
current protocol. The only thing it does is to add an option to use ESS
certIDv2 IF SHA-1 is not used as hash to identify the TSA&#8217;s =
certificate.<br>
This seems like a perfect thing for an update RFC. Another argument is =
that the
old editors that rightfully should have the credit for RFC 3161 are not =
part of
this minor amendment but are completely erased from the update. That may =
be
reasonable if the changes are major but I&#8217;m not so sure in this =
case.</span><o:p></o:p></p>

</div>

</div>

</body>

</html>

------=_NextPart_000_015D_01C9A631.2B2170F0--



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 n2GHASi3077915 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Mar 2009 10:10:28 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2GHASmG077914; Mon, 16 Mar 2009 10:10:28 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp109.biz.mail.re2.yahoo.com (smtp109.biz.mail.re2.yahoo.com [206.190.53.8]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n2GHAFoa077887 for <[e-mail]>; Mon, 16 Mar 2009 10:10:26 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 69070 invoked from network); 16 Mar 2009 17:10:15 -0000
Received: from unknown (HELO sean-turners-macbook.local) (turners@71.191.5.27 with plain) by smtp109.biz.mail.re2.yahoo.com with SMTP; 16 Mar 2009 17:10:15 -0000
X-Yahoo-SMTP: qPTWNAeswBAtDTSn9GKlmmL3C90ke7grn_5n9To-
X-YMail-OSG: KFAE1LQVM1l8mMcE5TWUSYRYZK.hG3p_VSck9w2ARL2QugODh.bLcSLjVmWW3fdYvpYLcZazu0OKh7qAwlsP1fLAVUhorL5MMz8e6RlLn4C9Ut1YjKuoCFjwUqbaEcW..5o1axpwFmsIo.1zlNh1pCWKcT98cJoZ9ocfHXzG2DAQ8ttu2pSCPyr4S0r1.GdkJuj_2IaaMcvhwTNb8Y7MU0RumE5fxfR5O8WNfK.zOp9.ZB3ock2lbq7ddyqsQXEfsA4BBXxSKE75aI9eWnd8EPWNryDPtgURdQ--
X-Yahoo-Newman-Property: ymail-3
Message-ID: <[e-mail]>
Date: Mon, 16 Mar 2009 13:10:26 -0400
From: Sean Turner <[e-mail]>
User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209)
MIME-Version: 1.0
To: RFC Errata System <[e-mail]>
CC: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: [Editorial Errata Reported] RFC5480 (1728)
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I approve (not sure this is the right term) this errata.

spt

RFC Errata System wrote:
> The following errata report has been submitted for RFC5480,
> "Elliptic Curve Cryptography Subject Public Key Information".
> 
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=5480&eid=1728
> 
> --------------------------------------
> Type: Editorial
> Reported by: Alfred Hoenes <[e-mail]>
> 
> Section: 2.1.1.1
> 
> Original Text
> -------------
>    The namedCurve field in ECParameters uses object identifiers to name
>    well-known curves.  This document publishes curve identifiers for the
>    fifteen NIST-recommended curves [FIPS186-3].  Other documents can
> |  publish other name curve identifiers.  The NIST-named curves are:
> 
> 
> Corrected Text
> --------------
>    The namedCurve field in ECParameters uses object identifiers to name
>    well-known curves.  This document publishes curve identifiers for the
>    fifteen NIST-recommended curves [FIPS186-3].  Other documents can
> |  publish other named curve identifiers.  The NIST named curves are:
>                      ^                             ^
> 
> Notes
> -----
> Location: first paragraph of 2.1.1.1
> Rationale:
> a) typo:  s/name curve/named curve/
> b) extraneous hyphen (inserted in final publication processing)
>    changes semantics in an unfortunate manner; "NIST-named curves"
>    could be misunderstood as indicating that NIST had named these
>    'Named Curves'; "NIST-recommended named curves" might have been a
>    valid alternative but would have incurred too much word repetition.
> 
> Instructions:
> -------------
> This errata is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party (IESG)
> can log in to change the status and edit the report, if necessary. 
> 
> --------------------------------------
> RFC5480 (draft-ietf-pkix-ecc-subpubkeyinfo-11)
> --------------------------------------
> Title               : Elliptic Curve Cryptography Subject Public Key Information
> Publication Date    : March 2009
> Author(s)           : S. Turner, D. Brown, K. Yiu, R. Housley, T. Polk
> Category            : PROPOSED STANDARD
> Source              : Public-Key Infrastructure (X.509)
> Area                : Security
> Stream              : IETF
> Verifying Party     : IESG
> 
> 



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 n2GGP8D6074488 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Mar 2009 09:25:08 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2GGP8gm074486; Mon, 16 Mar 2009 09:25:08 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from alfa.ritlabs.com (alfa.ritlabs.com [212.56.194.252]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2GGOuN5074454; Mon, 16 Mar 2009 09:25:07 -0700 (MST) (envelope-from [e-mail])
Received: from Maxim-PC1 (maxim.alfa.ritlabs.com [212.56.194.246]) by alfa.ritlabs.com (8.14.2/8.14.2) with ESMTP id n2GGOkju019416; Mon, 16 Mar 2009 18:24:47 +0200
CC: [e-mail], [e-mail]
Date: Mon, 16 Mar 2009 18:24:54 +0200
From: "Maxim Masiutin" <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Reply-To: "Maxim Masiutin" <[e-mail]>
Subject: Re[2]: A contradiction between RFC3852 and RFC3278
To: "Sean Turner" <[e-mail]>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on alfa.ritlabs.com
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hello Sean,

Thank you, your suggestion to add a paragraph is fine!

-- 
Best regards,
Maxim Masiutin                            mailto:[e-mail]



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 n2GGA8O3073455 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Mar 2009 09:10:08 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2GGA8qJ073453; Mon, 16 Mar 2009 09:10:08 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp108.biz.mail.re2.yahoo.com (smtp108.biz.mail.re2.yahoo.com [206.190.52.47]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n2GG9r4f073404 for <[e-mail]>; Mon, 16 Mar 2009 09:10:03 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 88129 invoked from network); 16 Mar 2009 16:09:53 -0000
Received: from unknown (HELO sean-turners-macbook.local) (turners@71.191.5.27 with plain) by smtp108.biz.mail.re2.yahoo.com with SMTP; 16 Mar 2009 16:09:52 -0000
X-Yahoo-SMTP: qPTWNAeswBAtDTSn9GKlmmL3C90ke7grn_5n9To-
X-YMail-OSG: .tA2C4AVM1khOuSnOXHA8QLZ0ZW.yFM6J5PJcAw_wnvyGvP6nG2FzruNwbgb1vJOol4f2LhDmJWtHqtdDRKpQ61gcbUihNQgut_XdpSywiSrBgqjZ9bJ0.CW9.6iqr04fH46FQf_RIaHyJfLacEXoXyf6S9PG50i7zC1tqife0vLT2pn1bMCFNKPpz4Y
X-Yahoo-Newman-Property: ymail-3
Message-ID: <[e-mail]>
Date: Mon, 16 Mar 2009 12:10:04 -0400
From: Sean Turner <[e-mail]>
User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209)
MIME-Version: 1.0
To: Maxim Masiutin <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: A contradiction between RFC3852 and RFC3278
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>

Maxim,

The paragraph now says:

signatureAlgorithm contains the signature algorithm identifier (see 
Section 7.1.3): ecdsa-with-SHA1, ecdsa-with-SHA224, ecdsa-with-SHA256, 
ecdsa-with-SHA384, or ecdsa-with-SHA512.

How about we add the following to the end of it:

The hash algorithm identified in the name of the signature algorithm 
MUST be the same as the digestAlgorithm (e.g., digestAlgorithm is 
id-sha256 therefore signatureAlgorithm is ecdsa-with-SHA256).

spt


Maxim Masiutin wrote:
> Hello Sean,
> 
> Maybe we should alter the description of signatureAlgorithm in section 2.1.1 of draft-smime-3278bis, to the following:
> 
>      - signatureAlgorithm contains the signature algorithm identifier 
>        (see Section 7.1.3) where the public key part of it
>        is ECDSA and the hash part MUST refer to the same algorithm as 
>        specified in the digestAlgorithm field. signatureAlgorithm MUST
>        be one of the following ecdsa-with-SHA1, 
>        ecdsa-with-SHA224, ecdsa-with-SHA256, 
>        ecdsa-with-SHA384, or ecdsa-with-SHA512. 
> 
> 



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 n2GFrb4T072065 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Mar 2009 08:53:37 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2GFrbqH072064; Mon, 16 Mar 2009 08:53:37 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2GFrZe0072054 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 16 Mar 2009 08:53:35 -0700 (MST) (envelope-from [e-mail])
Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n2GFqLBU025105 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 16 Mar 2009 08:52:22 -0700 (PDT)
Received: (from web-usrn@localhost) by boreas.isi.edu (8.13.8/8.13.8/Submit) id n2GFqL6E025094; Mon, 16 Mar 2009 08:52:21 -0700 (PDT)
Date: Mon, 16 Mar 2009 08:52:21 -0700 (PDT)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: [Editorial Errata Reported] RFC5480 (1728)
From: RFC Errata System <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail]
X-ISI-4-43-8-MailScanner: Found to be clean
X-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>

The following errata report has been submitted for RFC5480,
"Elliptic Curve Cryptography Subject Public Key Information".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5480&eid=1728

--------------------------------------
Type: Editorial
Reported by: Alfred Hoenes <[e-mail]>

Section: 2.1.1.1

Original Text
-------------
   The namedCurve field in ECParameters uses object identifiers to name
   well-known curves.  This document publishes curve identifiers for the
   fifteen NIST-recommended curves [FIPS186-3].  Other documents can
|  publish other name curve identifiers.  The NIST-named curves are:


Corrected Text
--------------
   The namedCurve field in ECParameters uses object identifiers to name
   well-known curves.  This document publishes curve identifiers for the
   fifteen NIST-recommended curves [FIPS186-3].  Other documents can
|  publish other named curve identifiers.  The NIST named curves are:
                     ^                             ^

Notes
-----
Location: first paragraph of 2.1.1.1
Rationale:
a) typo:  s/name curve/named curve/
b) extraneous hyphen (inserted in final publication processing)
   changes semantics in an unfortunate manner; "NIST-named curves"
   could be misunderstood as indicating that NIST had named these
   'Named Curves'; "NIST-recommended named curves" might have been a
   valid alternative but would have incurred too much word repetition.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC5480 (draft-ietf-pkix-ecc-subpubkeyinfo-11)
--------------------------------------
Title               : Elliptic Curve Cryptography Subject Public Key Information
Publication Date    : March 2009
Author(s)           : S. Turner, D. Brown, K. Yiu, R. Housley, T. Polk
Category            : PROPOSED STANDARD
Source              : Public-Key Infrastructure (X.509)
Area                : Security
Stream              : IETF
Verifying Party     : IESG



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 n2GFiHls071472 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Mar 2009 08:44:17 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2GFiHlh071471; Mon, 16 Mar 2009 08:44:17 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2GFi49R071451 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 16 Mar 2009 08:44:15 -0700 (MST) (envelope-from [e-mail])
Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n2GFggjY021390 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 16 Mar 2009 08:42:43 -0700 (PDT)
Received: (from web-usrn@localhost) by boreas.isi.edu (8.13.8/8.13.8/Submit) id n2GFgetl021383; Mon, 16 Mar 2009 08:42:40 -0700 (PDT)
Date: Mon, 16 Mar 2009 08:42:40 -0700 (PDT)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: [Editorial Errata Reported] RFC5480 (1727)
From: RFC Errata System <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail]
X-ISI-4-43-8-MailScanner: Found to be clean
X-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>

The following errata report has been submitted for RFC5480,
"Elliptic Curve Cryptography Subject Public Key Information".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5480&eid=1727

--------------------------------------
Type: Editorial
Reported by: Alfred Hoenes <[e-mail]>

Section: 2.1.1, pg.5

Original Text
-------------
|     o specifiedCurve, which is of type SpecifiedECDomain type (defined
        in [X9.62]), allows all of the elliptic curve domain parameters
        to be explicitly specified.  [...]

Corrected Text
--------------
|     o specifiedCurve, which is of type SpecifiedECDomain (defined
        in [X9.62]), allows all of the elliptic curve domain parameters
        to be explicitly specified.  [...]


Notes
-----
Location: last bullet in Section 2.1.1.
Rationale: inadvertant replication of "type"

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC5480 (draft-ietf-pkix-ecc-subpubkeyinfo-11)
--------------------------------------
Title               : Elliptic Curve Cryptography Subject Public Key Information
Publication Date    : March 2009
Author(s)           : S. Turner, D. Brown, K. Yiu, R. Housley, T. Polk
Category            : PROPOSED STANDARD
Source              : Public-Key Infrastructure (X.509)
Area                : Security
Stream              : IETF
Verifying Party     : IESG



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 n2GFX64G070956 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Mar 2009 08:33:06 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2GFX6oN070955; Mon, 16 Mar 2009 08:33:06 -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 n2GFWsej070922; Mon, 16 Mar 2009 08:33:05 -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 n2GFWrdN012305; Mon, 16 Mar 2009 11:32:54 -0400
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 n2GFWrfJ012285; Mon, 16 Mar 2009 11:32:53 -0400
Received: from IMCMBX2.MITRE.ORG ([129.83.29.205]) by imchub2.MITRE.ORG ([129.83.29.74]) with mapi; Mon, 16 Mar 2009 11:32:53 -0400
From: "Miller, Timothy J." <[e-mail]>
To: "'Jim Schaad'" <[e-mail]>, "'Maxim Masiutin'" <[e-mail]>, "[e-mail]" <[e-mail]>
CC: "[e-mail]" <[e-mail]>
Date: Mon, 16 Mar 2009 11:32:53 -0400
Subject: RE: RFC4134 email mismatch in examples 4.8 and 4.9
Thread-Topic: RFC4134 email mismatch in examples 4.8 and 4.9
Thread-Index: Acmk666Uws86s9IoQuiN4CXcD0QKRwAA4ndgAFbzbqA=
Message-ID: <[e-mail]>
References: <[e-mail]> <086a01c9a4ef$49782780$dc687680$@com>
In-Reply-To: <086a01c9a4ef$49782780$dc687680$@com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0006_01C9A622.900EFCD0"
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>

------=_NextPart_000_0006_01C9A622.900EFCD0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit

Not correct.  Mail address local parts are *case sensitive*.

RFC5322 Section 3.4.1:

"""
The local-part portion is a domain-dependent string.
"""

RFC5321:

"""
2.4.  General Syntax Principles and Transaction Model

   [...]
 
The
   local-part of a mailbox MUST BE treated as case sensitive.
   Therefore, SMTP implementations MUST take care to preserve the case
   of mailbox local-parts.  In particular, for some hosts, the user
   "smith" is different from the user "Smith".  However, exploiting the
   case sensitivity of mailbox local-parts impedes interoperability and
   is discouraged.  Mailbox domains follow normal DNS rules and are
   hence not case sensitive.
"""

Discouraged != (MUST NOT || SHOULD NOT)

We went through this argument (at my instigation) last year on the S/MIME
list:

http://osdir.com/ml/ietf.smime/2007-09/msg00004.html

-- Tim

>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]]
>On Behalf Of Jim Schaad
>Sent: Saturday, March 14, 2009 4:53 PM
>To: 'Maxim Masiutin'; [e-mail]
>Cc: [e-mail]
>Subject: RE: RFC4134 email mismatch in examples 4.8 and 4.9
>
>
>For the purposes of S/MIME all RFC822 addresses are considered to be
>case
>insensitive.
>
>Jim
>
>
>> -----Original Message-----
>> From: [e-mail] [mailto:owner-ietf-
>> [e-mail]] On Behalf Of Maxim Masiutin
>> Sent: Saturday, March 14, 2009 2:22 PM
>> To: [e-mail]
>> Cc: [e-mail]
>> Subject: RFC4134 email mismatch in examples 4.8 and 4.9
>>
>> Hello,
>>
>> I have a question about RFC4134, Examples 4.8 and 4.9.
>>
>> "From" line of the RFC-822 message is [e-mail], while the
>> certificate's SubjectAlternativeName contains Rfc822Name =
>> [e-mail]
>>
>> So the two emails are different in the host part.
>>
>> Is it OK for them to be different?
>>
>>
>> --
>> Best regards,
>> Maxim Masiutin
>> Ritlabs SRL
>> http://www.ritlabs.com/


------=_NextPart_000_0006_01C9A622.900EFCD0
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKuzCCA2Qw
ggJMoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwWjESMBAGA1UEChMJbWl0cmUub3JnMR4wHAYDVQQL
ExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJDAiBgNVBAMTG01JVFJFIENvcnBvcmF0aW9uIFJvb3Qg
Q0EtMTAeFw0wNjA2MDEwNDAwMDBaFw0xODA2MDEwNDAwMDBaMFoxEjAQBgNVBAoTCW1pdHJlLm9y
ZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MSQwIgYDVQQDExtNSVRSRSBDb3Jwb3Jh
dGlvbiBSb290IENBLTEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCva1qWPZiEJv5v
MtCbjt0cTu0Nbn15Q1cKqQBXKi8VSH9zZPmPxfWizJJ7JSqFJ5/sLUz3NsnUVjpLYBdFcxNXnOLj
XtmDPFOewm5T98NZc9wRRCiDzt4f8qsHFI19ShPiK3cN5UqtJf+i66QVLA1S6CNL6o2eGAsAl5Wn
xwOh2BfcWU5fNlHDVc9KKAlDDWpHjC2LLHAUbLP4ZzMIJKcLgLKFMtgM2AEfaSHzmi7WUdUHRCtC
blrF7qzPsy/jBLFrr8VcX+mb7saq95pEOilgcix0/naW7kJfM5ph7UBB+S1O/OhH+ZjQ4MjWnwE8
A/YDrQx1OVLAOi29Bsho/l8lAgMBAAGjNTAzMBIGA1UdEwEB/wQIMAYBAf8CAQMwHQYDVR0OBBYE
FMdwUQDYTf7kAdRolsU9n5qX/nQvMA0GCSqGSIb3DQEBBQUAA4IBAQAa+fVfCljimBlcfWwkfJXu
XNKWun9xloFKjnq6SPGgAIKi5LUDil60a0NaNGoGSO3I1xzYt7ncayh21qXulcVTDFqubSJdv51a
HTuJYcYUX72LN/gSq03UVLBCJzYm7ZLUlkb2YLo7xUeZ3coLFcT5AHR36kjG4cYHqXgH0liBl8jx
pN0gwgaci4sgPLUj1w4t8zoKH+zxGFwXwTP/P+etQqiJZ5T00fLLm5kz9mmnxxmmIvUGNdsCAhGh
dnF24pcrR43LNgyOBJ9DPUHBNq3kUQRO48WBKxBxflOtKzsICx/HEtIABcZn7deADHcY9spULZfB
nQYdEpyz5tgh7Y2qMIIDZzCCAk+gAwIBAgICHwUwDQYJKoZIhvcNAQEFBQAwXTESMBAGA1UEChMJ
bWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAlBgNVBAMTHk1JVFJF
IENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMTAeFw0wODA4MjExNTMxMjlaFw0xMDAyMTIxNTMxMjla
MFoxEjAQBgNVBAoTCW1pdHJlLm9yZzEPMA0GA1UECxMGcGVvcGxlMRcwFQYKCZImiZPyLGQBARMH
dG1pbGxlcjEaMBgGA1UEAxMRTWlsbGVyIFRpbW90aHkgSi4wgZ8wDQYJKoZIhvcNAQEBBQADgY0A
MIGJAoGBAJPEz7Pl8Mq+YEicZq2/QORXC47F3r1LYzaOGjxCQ6W1gkr/glSb24rRS1BmTIhsSOYK
mZcvDXuIwKADRKPC5R8nF0Xye1PKzyR7IyNF2UpLAWeSBmX20vujTrQsG1lBjMjlqOtb2Tc3vrwb
+TVtlLlRiIwYdTn5iCXgjBWGZC/fAgMBAAGjgbcwgbQwDgYDVR0PAQH/BAQDAgXgMB0GA1UdDgQW
BBRJcBGqaPkGXYvPtEuhQiS44eXQyTAfBgNVHSMEGDAWgBSHtA9IjWIzQsEtURpIHsKeuwqxrTBE
BgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vd3d3Lm1pdHJlLm9yZy90ZWNoL21paS9wa2kvY2ExX21p
dHJlX29yZy5jcmwwHAYDVR0RBBUwE4ERdG1pbGxlckBtaXRyZS5vcmcwDQYJKoZIhvcNAQEFBQAD
ggEBABsDU8f+F53+uvI7V/TJ9NEmcP+8vWsVN25S63+KsvsVJccbJu48fHJ1/IY+8niqP5PyGzVb
SNNrbNCdo9Hna2azeF5+XvoI1U/28mhWZoz2y8VfgNfp4mH/hIAjzW0C4EgryDGxZ3VVr8GeeHX/
CxktzzDaOSiNWqRPYAc9odLcMEpftABai9dVLFhCWowgfjO9I1JV+m+kh/QxYlZEE++B6tVJsmwD
h3PrOIq9cNbJJNX3PBK42OKQ2ov/+cgrCNuvdk59JQ7FK6FbnxqfYdrhN05G8bh0YkSwzPFulMH7
C3+zq0rqug41Xi6IO04ME1UAb5cah94xyxLRvuJd3EMwggPkMIICzKADAgECAgEFMA0GCSqGSIb3
DQEBBQUAMFoxEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9y
aXR5MSQwIgYDVQQDExtNSVRSRSBDb3Jwb3JhdGlvbiBSb290IENBLTEwHhcNMDYwNjAzMTcxMzIy
WhcNMTIwNjAzMTcxMzIyWjBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmlj
YXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xMIIB
IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyPB7Vl0QgqgQt0u8Q2duRs7eZUPnhlflKPFP
MXGG+iqGpImYs6nfbFPsn0q8FqklFsm/UEV2JJQ3c7Srwfrqe9CrCbVFh761OxZI7fnUWiUasNP2
ING19aAfrQ8IoJsAEtGzHeIacS+M5CN4C0yfUC6CpBZTc9ZldjLUatvJr407K1i+7WnrRsMVKhIC
fgmiO/XiVR9YeXyzeRqFrLy6YtJCJuJd0QRfwKtKRpek5oU67Izr7ClHDtPJs7UOTjMYBS2fTzzt
C+wwOTp6+A3ZbEymuQcAZRwmGkjVBe2R8MiX26R02Iigz+903ZAL/6bpvx0DnkrlR2UFr1KBGfBq
mQIDAQABo4GxMIGuMBIGA1UdEwEB/wQIMAYBAf8CAQIwDgYDVR0PAQH/BAQDAgGGMB0GA1UdDgQW
BBSHtA9IjWIzQsEtURpIHsKeuwqxrTAfBgNVHSMEGDAWgBTHcFEA2E3+5AHUaJbFPZ+al/50LzBI
BgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vd3d3Lm1pdHJlLm9yZy90ZWNoL21paS9wa2kvcm9vdGNh
MV9taXRyZV9vcmcuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQBNbm7rrins3SICPbteX9qSN1+RJClq
ix/pw3IAe7u60LK0V9jVZ9E2a+c0MZiSojdcwU5rXxI2OI2wwIf6wVBo76jIOc+IiQRlC+V8YatG
moibqP/8WDPzlud/WQAzkjrU2nuh8KdyJG+n1kH/6772Lbra2CIk8mu8FypeaB5P2uIJzdE+PGo8
2ZiyU680ukiJ9yF6UmEXuciB77tGQBRxMl6ePzIrArQnf48SmBhFD5XYLraueOiG7E+AzD99ig1M
6WHcxWXtp3DIrVqE/DZr146NJaCWqg9NoE14cmpEllnpWLtLnn5UBYJ+QCozmbe1SJXOOynZ0VxM
nGdh7NqgMYICvTCCArkCAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRp
ZmljYXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0x
AgIfBTAJBgUrDgMCGgUAoIIBsDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ
BTEPFw0wOTAzMTYxNTMyNTNaMCMGCSqGSIb3DQEJBDEWBBRlm5k99mp0eG0jHeOiIH4jdYiVuDBn
BgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIB
QDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTByBgkrBgEEAYI3
EAQxZTBjMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9y
aXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAh8FMHQGCyqGSIb3
DQEJEAILMWWgYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1
dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTANBgkq
hkiG9w0BAQEFAASBgAVEwY8sQ/FJ+8TigUBH/vPqTNWdoNTqz5pG6cmRxJDhFeN03bv01rSTMXuq
rmeacXgb84DJuVdlQLdaPvBo8+Eppt2EY0jIrS3ZIH2vJiTCunmIw4GLiB4lDKKiYZc1diAYbE5H
mO6M9PpS7XY+eVnrFimG3sUq4+0ZergkkBHGAAAAAAAA

------=_NextPart_000_0006_01C9A622.900EFCD0--



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 n2GEwmXg068594 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Mar 2009 07:58:48 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2GEwmNf068592; Mon, 16 Mar 2009 07:58:48 -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 n2GEwaGA068576 for <[e-mail]>; Mon, 16 Mar 2009 07:58:47 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 30) id 55D8028C18F; Mon, 16 Mar 2009 07:57:54 -0700 (PDT)
X-idtracker: yes
From: The IESG <[e-mail]>
To: IETF-Announce <[e-mail]>
Cc: Internet Architecture Board <[e-mail]>, RFC Editor <[e-mail]>, pkix mailing list <[e-mail]>, pkix chair <[e-mail]>
Subject: Protocol Action: 'Update for RSAES-OAEP Algorithm  Parameters' to Proposed Standard 
Message-Id: <[e-mail]>
Date: Mon, 16 Mar 2009 07:57:54 -0700 (PDT)
Sender: [e-mail]
Precedence: 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 approved the following document:

- 'Update for RSAES-OAEP Algorithm Parameters '
   <draft-ietf-pkix-rfc4055-update-02.txt> as a Proposed Standard

This document is the product of the Public-Key Infrastructure (X.509) 
Working Group. 

The IESG contact persons are Pasi Eronen and Tim Polk.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc4055-update-02.txt

Technical Summary

   The subjectPublicKeyInfo field of an X.509 certificate carries
   three data items: an algorithm identifier, optional parameters, and
   a bit string that represents the public key. The parameters are
   specific to the algorithm and this field usually contains simple
   values needed to characterize the public key algorithm, e.g., the
   generator and modulus for Diffie-Hellman. However, X.509 does not
   constrain the scope of this parameters field. The ANSI X9.62
   standards committee elected to use this field to express
   potentially complex limitations on how the public key in the
   certificate can be used, e.g., which key derivation functions can
   be applied to the bit string that results from a Diffie-Hellman key
   exchange.

   After considerable debate, the PKIX WG has decided to not express
   key usage constraints via this field. Instead, the WG decided that
   this sort of information should be expressed via use of distinct
   algorithm identifiers. (This decision is consistent with the
   observation that current products are not deigned to handle such
   key usage restrictions expressed in the subjectPublicKeyInfo
   field.)

   RFC 4055 such allowed restrictions to be placed in this field when
   used with RSA-OAEP.  This document changes RFC 4055 to say that
   restrictions MUST NOT be present in the certificate's
   subjectPublicKeyInfo field when used with RSA-OAEP. It also
   replaces incorrect references to the publicKeyAlgorithm field with
   references to the subjectPublicKeyInfo field. As a result, this
   revised version of RFC 4055 will be consistent with the PKIX WG
   conventions adopted for this field.

Working Group Summary

   This ID was discussed on the mailing list. A poll was taken on the
   PKIX list to determine whether the proposed change was the way
   forward and another poll was taken to determine whether the change
   would adversely affect implementations. The WG was in favor of the
   change and no implementer said it would adversely affect their
   products. Further, vendors that implement RFC 4055 support the
   change.

Document Quality

   This document is a short update of an existing draft and is
   comparable in quality to its predecessor.

Personnel

   Steve Kent is the document Shepherd.  Pasi Eronen is the 
   responsible security area director.



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 n2GEHXwH065433 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Mar 2009 07:17:33 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2GEHXgJ065432; Mon, 16 Mar 2009 07:17:33 -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 (rimp1.nist.gov [129.6.16.226]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2GEHLt4065407 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 16 Mar 2009 07:17:32 -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 n2GEHPcW001787; Mon, 16 Mar 2009 10:17:25 -0400
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 n2GEH2Wc032014; Mon, 16 Mar 2009 10:17:03 -0400
Message-ID: <[e-mail]>
Date: Mon, 16 Mar 2009 10:17:02 -0400
From: "David A. Cooper" <[e-mail]>
User-Agent: Thunderbird 2.0.0.19 (X11/20090114)
MIME-Version: 1.0
To: Jim Schaad <[e-mail]>
CC: pkix <[e-mail]>
Subject: Re: RFC4134 email mismatch in examples 4.8 and 4.9
References: <[e-mail]> <086a01c9a4ef$49782780$dc687680$@com>
In-Reply-To: <086a01c9a4ef$49782780$dc687680$@com>
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>

Jim Schaad wrote:
> For the purposes of S/MIME all RFC822 addresses are considered to be case
> insensitive.

Jim,

Could you provide a reference for this?

I know that the PKCS#9 emailAddress attribute is case insensitive, but 
everywhere else that I have seen indicates that the local-part of an 
email address is case sensitive (although the host may, and usually 
does, treat the local-part as case insensitive).  For example, RFC 5321 
states:

   The local-part of a mailbox MUST BE treated as case sensitive.
   Therefore, SMTP implementations MUST take care to preserve
   the case of mailbox local-parts.  In particular, for some hosts, the
   user "smith" is different from the user "Smith".  However, exploiting
   the case sensitivity of mailbox local-parts impedes interoperability
   and is discouraged.  Mailbox domains follow normal DNS rules
   and are hence not case sensitive.


When you say that RFC822 addresses are considered to be case 
insensitive, are you saying that this is according to the standard for 
S/MIME or just that it is common practice?

Thanks,

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 n2GBRhWJ051443 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Mar 2009 04:27:43 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2GBRhrH051442; Mon, 16 Mar 2009 04:27:43 -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 n2GBRUNu051427 for <[e-mail]>; Mon, 16 Mar 2009 04:27:42 -0700 (MST) (envelope-from [e-mail])
Received: from MSGA-001.frcl.bull.fr (msga-001.frcl.bull.fr [129.184.87.31]) by odin2.bull.net (Bull S.A.) with ESMTP id 93E3E7D13 for <[e-mail]>; Mon, 16 Mar 2009 12:26:40 +0100 (CET)
Received: from FRCLS4013 ([129.182.108.120]) by MSGA-001.frcl.bull.fr (Lotus Domino Release 5.0.11) with SMTP id 2009031612272935:676707 ; Mon, 16 Mar 2009 12:27:29 +0100 
Reply-To: [e-mail]
From: "Denis Pinkas"<[e-mail]>
To: "ietf-pkix"<[e-mail]>
Subject: Re: draft-ietf-pkix-rfc3161bis-01.txt
Date: Mon, 16 Mar 2009 12:27:29 +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 16/03/2009 12:27:29, Serialize by Router on MSGA-001/FR/BULL(Release 5.0.11  |July 24, 2002) at 16/03/2009 12:27:29, Serialize complete at 16/03/2009 12:27:29
Content-Type: multipart/alternative;  boundary="----=_NextPart_09031612271986357818122_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_09031612271986357818122_002
Content-Type: text/plain; 
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable


Sorry for the delay to respond.

Responses are in-line.

Denis
----- Message re=E7u -----=20
De : owner-ietf-pkix=20
=C0 : ietf-pkix=20
Date : 2009-03-04, 18:22:25
Sujet : draft-ietf-pkix-rfc3161bis-01.txt


I had the impression that thegoal of that texwt was an update
concerning hash algorithms.

One could expecte it would only contain an update to the ESScertid using
ESSCertidV2 etc.

The actual texts corresponds roughly to an expired draft some
years ago.

        - the document has been aligned with RFC 3628 to make the
          difference between a time-stamping unit (TSU) and a TSA.

Thus, the text is not a small update of 3161 but introduces several
new items, some of them seems questionable to me. Some problems
which had been mentioned with RFC 3161 in the past, have not been
addressed.

In 3161, a TSA is merely a technical service similar to what is
said in 3161bis for a TSU. A TSA in 3161bis does not really
have a defined technical role.

[Denis]  The key point is that the certificate belongs to one TSU, not to=
 one TSA.

A TSU certificate may be revoked. A TSA has no certificate and thus is no=
t revoked if one of its TSUs is compromised.
A TSA is the administrative entity responsible for managing one or more T=
SUs.

On the other hand the field tsa in a response refers to a TSA,
and to a certficate that validates it. But a TSA does no longer
have a certificate, only TSUs.

[Denis]  In the proposal, I kept the same names for the fields.=20
Maybe this is not the best choice, and "tsa" should be changed into "tsu"=
 to reflect better the difference.

As a consequence, the following paragraph cannot mention TSA
but at best a TSU.
Besides that it should also mentiion ESSCertIDv2.)

    The purpose of the tsa field is to give a hint in identifying the
    name of the TSA. If present, it MUST correspond to one of the
    subject names included in the certificate that is to be used to
    verify the token. However, the actual identification of the entity
    that signed the response will always occur through the use of the
    certificate identifier (ESSCertID Attribute) inside a
    SigningCertificate attribute which is part of the signerInfo
    (See Section 5 of [ESS]).


Chapter 3.3 does not use the 2119 terminology in the first phrase but
rather the ISO terminoilogy.=20

[Denis]  Do you mean "shall" should be changed into" SHALL" ?

3.3 is not relevant for the function of
a time stamp service. (Although it is likely that TSA actually
have filled all the REQUIRED 'shall) attributes in the DN)

The following text is extremely fuzzy:

    The name of the issuing TSU shall contain an appropriate subset of
    the following attributes (defined in ISO 9594-6 [ISO9594-6] and
    ITU-T Recommendation X.520 [X.520]):

        - countryName;
        - stateOrProvinceName;
        - organizationName;
        - commonName.

What means "appropriate subset". The text does not exclude
other attributs. So in fact, it says: The TSU MUST have a subjectDN?

It is not defined what name identifies a TSA? for example, everything exc=
ept
the common name?

[Denis]  The text is very explicit: "organizationName shall be present". =
Other fields are optional.

4.3 :

As it had been mentioned before the socket protocol as it is defined
has some problems: Since it was taken texto from CMP, there are some feat=
ures
that are may require some complexity in clients:
Only 00, 05, and 06 seem useful to me. If a TSA/U is not able to sign
a response within a few milliseconds with a TCP connection kept open,
I wouldn't call this a service.

[Denis]  I care for backwards compatibility first.=20
If some cases may not exist, then we can suppress them.=20
If they may exist, then we should keep them.=20

For HTTP, a server cannot return a poll indication as a comparison.

If a client does not send a pollReq, what will happen with a pending
response?

The protocol does not specify who terminates the connection. Is it the
server that closes after one exchange?

If multiple requests and responses can be exchanged over the same connect=
ion,
what is the dialogue model? request/response, pipelining, etc?

[Denis]  If you have a proposal , please post it to the list.

What is a TSU message? I think it should be TSP message. Old text was
TSA, which was also somewhat wrong.

[Denis]  A TSU Message is simply a message from a TSU.

Security section point 1 seems not quite correct:

Instead of :
it SHALL be set either to unspecified (0), affiliationChanged (3),
       superseded (4) or cessationOfOperation (5). In that case,

it should say

In the case when the reasonCode is set to either
       affiliationChanged (3),
       superseded (4) or cessationOfOperation (5)

Unspecified means that ther can be a key compromise IMO?

[Denis]. Good catch. Let us delete "unspecified (0)"

------=_NextPart_09031612271986357818122_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></DIV>
<DIV>&nbsp;</DIV>
<DIV>Sorry for the delay to respond.<BR></DIV>
<DIV>Responses are in-line.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Denis</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]">ietf-pkix</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> 2009-03-04, 18:22:25</DIV>
  <DIV=20
  style=3D"FONT-WEIGHT: normal; FONT-SIZE: 9pt; LINE-HEIGHT: normal; FONT=
-STYLE: normal; FONT-VARIANT: normal"><B>Sujet=20
  :</B> draft-ietf-pkix-rfc3161bis-01.txt</DIV>
  <DIV><BR></DIV>
  <DIV></DIV>
  <DIV></DIV>
  <DIV>
  <DIV>I had the impression that thegoal of that texwt was an=20
  update<BR>concerning hash algorithms.<BR><BR>One could expecte it would=
 only=20
  contain an update to the ESScertid using<BR>ESSCertidV2 etc.<BR><BR>The=
 actual=20
  texts corresponds roughly to an expired draft some<BR>years=20
  ago.<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;- the docum=
ent has=20
  been aligned with RFC 3628 to make=20
  the<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;diff=
erence=20
  between a time-stamping unit (TSU) and a TSA.<BR><BR>Thus, the text is =
not a=20
  small update of 3161 but introduces several<BR>new items, some of them =
seems=20
  questionable to me. Some problems<BR>which had been mentioned with RFC =
3161 in=20
  the past, have not been<BR>addressed.<BR><BR>In 3161, a TSA is merely a=
=20
  technical service similar to what is<BR>said in 3161bis for a TSU. A TS=
A in=20
  3161bis does not really<BR>have a defined technical role.</DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT color=3D#0000ff>[Denis]&nbsp; The key point is that the cert=
ificate=20
  belongs to one TSU, not to one TSA.</FONT></DIV>
  <DIV><FONT color=3D#0000ff></FONT>&nbsp;</DIV>
  <DIV><FONT color=3D#0000ff>A TSU certificate may be revoked. A TSA has =
no=20
  certificate and thus is not revoked if one of its TSUs is=20
  compromised.</FONT></DIV>
  <DIV><FONT color=3D#0000ff>A TSA&nbsp;is&nbsp;the administrative entity=
=20
  responsible for managing one or more TSUs.</FONT></DIV>
  <DIV><BR>On the other hand the field tsa in a response refers to a TSA,=
<BR>and=20
  to a certficate that validates it. But a TSA does no longer<BR>have a=20
  certificate, only TSUs.<BR></DIV>
  <DIV>
  <DIV><FONT color=3D#0000ff>[Denis]&nbsp; </FONT><FONT color=3D#0000ff>I=
n the=20
  proposal, I kept the same names for the fields. <BR>Maybe this is not t=
he best=20
  choice, and "tsa" should be changed into "tsu" to reflect better the=20
  difference.</FONT></DIV></DIV>
  <DIV><BR>As a consequence, the following paragraph cannot mention TSA<B=
R>but=20
  at best a TSU.<BR>Besides that it should also mentiion=20
  ESSCertIDv2.)<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;The purpose of the tsa fie=
ld is=20
  to give a hint in identifying the<BR>&nbsp;&nbsp;&nbsp;&nbsp;name of th=
e TSA.=20
  If present, it MUST correspond to one of=20
  the<BR>&nbsp;&nbsp;&nbsp;&nbsp;subject names included in the certificat=
e that=20
  is to be used to<BR>&nbsp;&nbsp;&nbsp;&nbsp;verify the token. However, =
the=20
  actual identification of the entity<BR>&nbsp;&nbsp;&nbsp;&nbsp;that sig=
ned the=20
  response will always occur through the use of=20
  the<BR>&nbsp;&nbsp;&nbsp;&nbsp;certificate identifier (ESSCertID Attrib=
ute)=20
  inside a<BR>&nbsp;&nbsp;&nbsp;&nbsp;SigningCertificate attribute which =
is part=20
  of the signerInfo<BR>&nbsp;&nbsp;&nbsp;&nbsp;(See Section 5 of=20
  [ESS]).<BR><BR><BR>Chapter 3.3 does not use the 2119 terminology in the=
 first=20
  phrase but<BR>rather the ISO terminoilogy. </DIV>
  <DIV>&nbsp;</DIV>
  <DIV>
  <DIV><FONT color=3D#0000ff>[Denis]&nbsp; Do you mean "shall" should be =
changed=20
  into" SHALL" ?</FONT></DIV></DIV>
  <DIV>&nbsp;</DIV>
  <DIV>3.3 is not relevant for the function of<BR>a time stamp service.=20
  (Although it is likely that TSA actually<BR>have filled all the REQUIRE=
D=20
  'shall) attributes in the DN)<BR><BR>The following text is extremely=20
  fuzzy:<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;The name of the issuing TSU shall=
=20
  contain an appropriate subset of<BR>&nbsp;&nbsp;&nbsp;&nbsp;the followi=
ng=20
  attributes (defined in ISO 9594-6 [ISO9594-6]=20
  and<BR>&nbsp;&nbsp;&nbsp;&nbsp;ITU-T Recommendation X.520=20
  [X.520]):<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;-=20
  countryName;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;-=20
  stateOrProvinceName;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;-=20
  organizationName;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;-=20
  commonName.<BR><BR>What means "appropriate subset". The text does not=20
  exclude<BR>other attributs. So in fact, it says: The TSU MUST have a=20
  subjectDN?<BR></DIV>
  <DIV>It is not defined what name identifies a TSA? for example, everyth=
ing=20
  except<BR>the common name?</DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT color=3D#0000ff>[Denis]&nbsp; The text is very explicit:=20
  "organizationName shall be present". Other fields are optional.</FONT><=
/DIV>
  <DIV><BR>4.3 :<BR><BR>As it had been mentioned before the socket protoc=
ol as=20
  it is defined<BR>has some problems: Since it was taken texto from CMP, =
there=20
  are some features<BR>that are may require some complexity in clients:<B=
R>Only=20
  00, 05, and 06 seem useful to me. If a TSA/U is not able to sign<BR>a r=
esponse=20
  within a few milliseconds with a TCP connection kept open,<BR>I wouldn'=
t call=20
  this a service.</DIV>
  <DIV>
  <DIV><FONT color=3D#0000ff></FONT>&nbsp;</DIV>
  <DIV><FONT color=3D#0000ff>[Denis]&nbsp; I care for backwards compatibi=
lity=20
  first. <BR>If some cases may not exist, then we can suppress them.=20
  </FONT></DIV>
  <DIV><FONT color=3D#0000ff>If they may exist, then we should keep them.=
=20
  </FONT></DIV></DIV>
  <DIV><BR>For HTTP, a server cannot return a poll indication as a=20
  comparison.<BR><BR>If a client does not send a pollReq, what will happe=
n with=20
  a pending<BR>response?<BR><BR>The protocol does not specify who termina=
tes the=20
  connection. Is it the<BR>server that closes after one exchange?<BR><BR>=
If=20
  multiple requests and responses can be exchanged over the same=20
  connection,<BR>what is the dialogue model? request/response, pipelining=
,=20
  etc?</DIV>
  <DIV><BR><FONT color=3D#0000ff>[Denis]&nbsp; If you have a proposal , p=
lease=20
  post it to the list.</FONT></DIV>
  <DIV><BR>What is a TSU message? I think it should be TSP message. Old t=
ext=20
  was<BR>TSA, which was also somewhat wrong.<BR></DIV>
  <DIV><FONT color=3D#0000ff>[Denis]&nbsp; A TSU Message is simply a mess=
age from=20
  a TSU.</FONT></DIV>
  <DIV><BR>Security section point 1 seems not quite correct:<BR><BR>Inste=
ad of=20
  :<BR>it SHALL be set either to unspecified (0), affiliationChanged=20
  (3),<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;superseded (4) or=20
  cessationOfOperation (5). In that case,<BR><BR>it should say<BR><BR>In =
the=20
  case when the reasonCode is set to=20
  either<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;affiliationChanged=20
  (3),<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;superseded (4) or=20
  cessationOfOperation (5)<BR><BR>Unspecified means that ther can be a ke=
y=20
  compromise IMO?<BR></DIV>
  <DIV><FONT color=3D#0000ff>[Denis]. Good catch. Let us delete "unspecif=
ied=20
  (0)"</FONT><BR></DIV>
  <DIV>&nbsp;</DIV></DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_09031612271986357818122_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 n2FDR66X084396 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 15 Mar 2009 06:27:06 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2FDR6bL084395; Sun, 15 Mar 2009 06:27:06 -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 n2FDQthf084380 for <[e-mail]>; Sun, 15 Mar 2009 06:27:05 -0700 (MST) (envelope-from [e-mail])
Received: from varuna.puteaux.on-x (varuna.puteaux.on-x [192.168.10.6]) by ganymede.on-x.com (Postfix) with ESMTP id 685176A; Sun, 15 Mar 2009 14:26:34 +0100 (CET)
Received: from smtps.on-x.com (mintaka.puteaux.on-x [192.168.14.11]) by varuna.puteaux.on-x (Postfix) with ESMTP id 0A43616FD3; Sun, 15 Mar 2009 14:26:34 +0100 (CET)
Received: from [192.168.0.19] (gut75-3-82-227-163-182.fbx.proxad.net [82.227.163.182]) by smtps.on-x.com (Postfix) with ESMTP id E25E277DC; Sun, 15 Mar 2009 14:26:33 +0100 (CET)
Message-ID: <[e-mail]>
Date: Sun, 15 Mar 2009 14:26:33 +0100
From: Peter Sylvester <[e-mail]>
User-Agent: Thunderbird 2.0.0.19 (X11/20090105)
MIME-Version: 1.0
To: Stefan Santesson <[e-mail]>
Cc: Jim Schaad <[e-mail]>, "'IETF-pkix'" <[e-mail]>
Subject: Re: Do we need rfc 3161bis?
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stefan Santesson wrote:
> Peter, 
>
> If we were designing the time stamp protocol from scratch today, I would
> probably argue that it is unnecessary to bind the signer's certificate to
> the time stamp token, or at least to make that optional.
>
> In most security services/protocols (such as OCSP) we do not bother to bind
> the signer's certificate to the signed data. In the general case the relying
> party is the one who reasonably relies on the signature and is therefore
> responsible for deciding if the certificate used to validate the signature
> is adequate for that trust decision.
>   
The "name of responder" is bound to the signature, as part
of the OCSP response similar to tsaName. Using essSigningCertficate
was overkill, but well, I am not asking to remove it.

If some update woul be necessary, I would rather remove the
MUST that requires a client to validate essSigningCert. IMO
tsaName match is sufficient.

At least one known public domain client
also verifies that the asserted date lies
in the validity period of the certificate. I am
not sure whether this is good.
> But since we already have 3161 out there, unless implementers and users have
> huge problems with it. I would not change anything.
>   
clarification and maybe simplifications that don't break interoperability
may be possible. The eesSigncert stuff is not in this category I think/

> In all other aspects I agree.
>
> /Stefan
>   
/P
>
> On 3/15/09 9:46 AM, "Peter Sylvester" <[e-mail]> wrote:
>
>   
>> What would be the impact, if a timestamp would not contain
>> a signingCertficate in the signed attributes?
>>
>> - A TSA could extend the lifetime of its TSA certificate by
>>   getting another with a different validity period?
>>
>> - The CA goes out of business, the CA cert gets revoked somehow;
>>   the TSA can get a replacement certificate with the same
>>   public key by another CA, so timestamps can still be
>>   verified,
>>
>> ... bad idea? Any security problem? I don't want to start
>> a discussion about long term verifiability (vs validity
>> of a timestamp).
>>
>> The 10 years old EU directive concerning  signatures do
>> require that the signatary is clearly identified. This is
>> sufficiently fulfilled by the 'tsa' field in the time stamp.
>>
>>
>> Another point:
>>
>> Most time stamp clients, if not all, verify that the timestamp
>> contains an essSigningCertficate. a v2 thus cannot simply
>> replace it without a risk that a client would not be able to
>> verify. The following piece of 3161bis may be problematic.
>>
>>    The time-stamp token MUST NOT contain any signatures other than the
>>    signature of the TSA.  The certificate identifier (either ESSCertID
>>    or ESSCertIDv2) of the TSU certificate MUST be included as a
>>    signerInfo attribute inside a SigningCertificate attribute.
>>
>>    Note: As mentioned in RFC 5035 [ESSV2], the SigningCertificateV2
>>          attribute MUST be used if any algorithm other than SHA-1
>>          is used and SHOULD NOT be used for SHA-1
>>
>> A TSA that starts using V2 after 3161bis publication would
>> be probably unable to produce verifiable time stamps for
>> many clients.
>>
>> In fact, it restricts the possibilities of a TSA, which today can
>> set both attributs.
>>
>> 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 n2FBVHGr079354 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 15 Mar 2009 04:31:17 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2FBVHjK079353; Sun, 15 Mar 2009 04:31:17 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from s87.loopia.se (s87.loopia.se [194.9.95.112]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2FBV4dw079344 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Sun, 15 Mar 2009 04:31:15 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 55348 invoked from network); 15 Mar 2009 11:31:07 -0000
Received: from s34.loopia.se (HELO s24.loopia.se) ([194.9.94.70]) (envelope-sender <[e-mail]>) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for <[e-mail]>; 15 Mar 2009 11:31:07 -0000
Received: (qmail 26185 invoked from network); 15 Mar 2009 11:31:03 -0000
Received: from 90-229-233-249-no153.tbcn.telia.com (HELO [192.168.0.17]) ([e-mail]@[90.229.233.249]) (envelope-sender <[e-mail]>) by s24.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <[e-mail]>; 15 Mar 2009 11:31:03 -0000
User-Agent: Microsoft-Entourage/12.15.0.081119
Date: Sun, 15 Mar 2009 12:31:02 +0100
Subject: Re: Do we need rfc 3161bis?
From: Stefan Santesson <[e-mail]>
To: Peter Sylvester <[e-mail]>
CC: Jim Schaad <[e-mail]>, "'IETF-pkix'" <[e-mail]>
Message-ID: <[e-mail]>
Thread-Topic: Do we need rfc 3161bis?
Thread-Index: AcmlYYUWP+CdxgExFU6SI43FIyBiIA==
In-Reply-To: <[e-mail]>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter, 

If we were designing the time stamp protocol from scratch today, I would
probably argue that it is unnecessary to bind the signer's certificate to
the time stamp token, or at least to make that optional.

In most security services/protocols (such as OCSP) we do not bother to bind
the signer's certificate to the signed data. In the general case the relying
party is the one who reasonably relies on the signature and is therefore
responsible for deciding if the certificate used to validate the signature
is adequate for that trust decision.

But since we already have 3161 out there, unless implementers and users have
huge problems with it. I would not change anything.

In all other aspects I agree.

/Stefan


On 3/15/09 9:46 AM, "Peter Sylvester" <[e-mail]> wrote:

> 
> What would be the impact, if a timestamp would not contain
> a signingCertficate in the signed attributes?
> 
> - A TSA could extend the lifetime of its TSA certificate by
>   getting another with a different validity period?
> 
> - The CA goes out of business, the CA cert gets revoked somehow;
>   the TSA can get a replacement certificate with the same
>   public key by another CA, so timestamps can still be
>   verified,
> 
> ... bad idea? Any security problem? I don't want to start
> a discussion about long term verifiability (vs validity
> of a timestamp).
> 
> The 10 years old EU directive concerning  signatures do
> require that the signatary is clearly identified. This is
> sufficiently fulfilled by the 'tsa' field in the time stamp.
> 
> 
> Another point:
> 
> Most time stamp clients, if not all, verify that the timestamp
> contains an essSigningCertficate. a v2 thus cannot simply
> replace it without a risk that a client would not be able to
> verify. The following piece of 3161bis may be problematic.
> 
>    The time-stamp token MUST NOT contain any signatures other than the
>    signature of the TSA.  The certificate identifier (either ESSCertID
>    or ESSCertIDv2) of the TSU certificate MUST be included as a
>    signerInfo attribute inside a SigningCertificate attribute.
> 
>    Note: As mentioned in RFC 5035 [ESSV2], the SigningCertificateV2
>          attribute MUST be used if any algorithm other than SHA-1
>          is used and SHOULD NOT be used for SHA-1
> 
> A TSA that starts using V2 after 3161bis publication would
> be probably unable to produce verifiable time stamps for
> many clients.
> 
> In fact, it restricts the possibilities of a TSA, which today can
> set both attributs.
> 
> 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 n2F9h5XO074122 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 15 Mar 2009 02:43:05 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2F9h5Sh074121; Sun, 15 Mar 2009 02:43:05 -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 n2F9h4XQ074115 for <[e-mail]>; Sun, 15 Mar 2009 02:43:04 -0700 (MST) (envelope-from [e-mail])
Received: from varuna.puteaux.on-x (varuna.puteaux.on-x [192.168.10.6]) by ganymede.on-x.com (Postfix) with ESMTP id D35E26A; Sun, 15 Mar 2009 10:42:43 +0100 (CET)
Received: from smtps.on-x.com (mintaka.puteaux.on-x [192.168.14.11]) by varuna.puteaux.on-x (Postfix) with ESMTP id A630E16FD3; Sun, 15 Mar 2009 10:42:43 +0100 (CET)
Received: from [192.168.0.19] (gut75-3-82-227-163-182.fbx.proxad.net [82.227.163.182]) by smtps.on-x.com (Postfix) with ESMTP id 4B34E77DC; Sun, 15 Mar 2009 10:42:43 +0100 (CET)
Message-ID: <[e-mail]>
Date: Sun, 15 Mar 2009 10:42:42 +0100
From: Peter Sylvester <[e-mail]>
User-Agent: Thunderbird 2.0.0.19 (X11/20090105)
MIME-Version: 1.0
To: [e-mail]
Cc: ietf-pkix <[e-mail]>
Subject: Re: draft-ietf-pkix-rfc3161bis-01.txt
References: <[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>

Denis Pinkas wrote:
> Stefan,
>  
> When you use the TSP (P = Protocol), you talk to a service (in this 
> case,  a Time Stamping Service).
>  
> You will get a response from one of the TSUs behind that service.
>  
> If the request is sucessful, the TST is signed by a TSU.
No, not in rfc 3161. The term used is TSA. The way how the
service is implemented, is out of scope NOIMO.

>  
> Every TSU is managed by a TSA.
Since I don't know your interpretation of "managed", it
is not clear whether you think about the TS Service Provider
the TS Service Operator, or some legal entity that assumes
the correct usage of a date and the protection of a key, or
else.

Nothing of that matters for the protocol.

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 n2F8kZbp072305 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 15 Mar 2009 01:46:35 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2F8kY2n072304; Sun, 15 Mar 2009 01:46: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 n2F8kNkO072295 for <[e-mail]>; Sun, 15 Mar 2009 01:46:34 -0700 (MST) (envelope-from [e-mail])
Received: from varuna.puteaux.on-x (varuna.puteaux.on-x [192.168.10.6]) by ganymede.on-x.com (Postfix) with ESMTP id 036166A; Sun, 15 Mar 2009 09:46:01 +0100 (CET)
Received: from smtps.on-x.com (mintaka.puteaux.on-x [192.168.14.11]) by varuna.puteaux.on-x (Postfix) with ESMTP id 8246216FD3; Sun, 15 Mar 2009 09:46:01 +0100 (CET)
Received: from [192.168.0.19] (gut75-3-82-227-163-182.fbx.proxad.net [82.227.163.182]) by smtps.on-x.com (Postfix) with ESMTP id 4E85C77DC; Sun, 15 Mar 2009 09:46:01 +0100 (CET)
Message-ID: <[e-mail]>
Date: Sun, 15 Mar 2009 09:46:01 +0100
From: Peter Sylvester <[e-mail]>
User-Agent: Thunderbird 2.0.0.19 (X11/20090105)
MIME-Version: 1.0
To: Stefan Santesson <[e-mail]>
Cc: Jim Schaad <[e-mail]>, "'IETF-pkix'" <[e-mail]>
Subject: Re: Do we need rfc 3161bis?
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

What would be the impact, if a timestamp would not contain
a signingCertficate in the signed attributes?

- A TSA could extend the lifetime of its TSA certificate by
  getting another with a different validity period?

- The CA goes out of business, the CA cert gets revoked somehow;
  the TSA can get a replacement certificate with the same
  public key by another CA, so timestamps can still be
  verified,

... bad idea? Any security problem? I don't want to start
a discussion about long term verifiability (vs validity
of a timestamp).

The 10 years old EU directive concerning  signatures do
require that the signatary is clearly identified. This is
sufficiently fulfilled by the 'tsa' field in the time stamp.


Another point:

Most time stamp clients, if not all, verify that the timestamp
contains an essSigningCertficate. a v2 thus cannot simply
replace it without a risk that a client would not be able to
verify. The following piece of 3161bis may be problematic.

   The time-stamp token MUST NOT contain any signatures other than the
   signature of the TSA.  The certificate identifier (either ESSCertID 
   or ESSCertIDv2) of the TSU certificate MUST be included as a 
   signerInfo attribute inside a SigningCertificate attribute.

   Note: As mentioned in RFC 5035 [ESSV2], the SigningCertificateV2 
         attribute MUST be used if any algorithm other than SHA-1 
         is used and SHOULD NOT be used for SHA-1

A TSA that starts using V2 after 3161bis publication would
be probably unable to produce verifiable time stamps for
many clients.

In fact, it restricts the possibilities of a TSA, which today can
set both attributs.

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 n2F0s5W2057316 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 14 Mar 2009 17:54:05 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2F0s5WO057315; Sat, 14 Mar 2009 17:54:05 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from s87.loopia.se (s87.loopia.se [194.9.95.112]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2F0rq6t057306 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Sat, 14 Mar 2009 17:54:04 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 92842 invoked from network); 15 Mar 2009 00:54:01 -0000
Received: from s34.loopia.se (HELO s42.loopia.se) ([194.9.94.70]) (envelope-sender <[e-mail]>) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for <[e-mail]>; 15 Mar 2009 00:54:01 -0000
Received: (qmail 75718 invoked from network); 15 Mar 2009 00:53:51 -0000
Received: from 90-229-233-249-no153.tbcn.telia.com (HELO [192.168.0.17]) ([e-mail]@[90.229.233.249]) (envelope-sender <[e-mail]>) by s42.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <[e-mail]>; 15 Mar 2009 00:53:51 -0000
User-Agent: Microsoft-Entourage/12.15.0.081119
Date: Sun, 15 Mar 2009 01:53:49 +0100
Subject: Re: Do we need rfc 3161bis?
From: Stefan Santesson <[e-mail]>
To: Jim Schaad <[e-mail]>, "'IETF-pkix'" <[e-mail]>
Message-ID: <[e-mail]>
Thread-Topic: Do we need rfc 3161bis?
Thread-Index: Acmkrf0j+yb7f0QChUOhT/ms/PsBpAAKRABQAAxc04E=
In-Reply-To: <082801c9a4d7$2d24f350$876ed9f0$@com>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3319926831_1682829"
Sender: [e-mail]
Precedence: 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 message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3319926831_1682829
Content-type: text/plain;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

Yes, a good question indeed.

Say that SHA-1 is completely broken in the sense that we can produce
collisions at will, of all sorts and forms.
Say also that we have a few valid TSA certificates issued for the same key
pair, signed using good hash algorithms (or else all bets are off anyway).

The randomness properties of SHA-1 will remain intact even if SHA-1 is
broken. This means that the risk/chance that two valid certificates, signed
with safe signature algorithms, will by chance produce collisions, is still
totally negligible.

Where am I thinking wrong here?

/Stefan



On 3/14/09 8:00 PM, "Jim Schaad" <[e-mail]> wrote:

> Stefan,
> =20
> The question you need to be asking is =AD Do you believe that SHA-1 will be
> broken one day, and if it is broken do you want to have in place a soluti=
on to
> deal with it.
> =20
> Jim
> =20
> =20
>=20
> From: [e-mail] [mailto:[e-mail]] =
On
> Behalf Of Stefan Santesson
> Sent: Saturday, March 14, 2009 7:06 AM
> To: IETF-pkix
> Subject: Do we need rfc 3161bis?
> =20
> The more I look into this the more I get to doubt that we actually need
> 3161bis.
>=20
> The only substantial technical change I know of is to allow the updated E=
SS
> certIDv2 to be used to identify the signer=B9s certificate IF the TSA for s=
ome
> reason choose to hash its certificate with another hash then SHA-1.
>=20
> The rationale for the certID identifier is given in section 5 of RFC 2634=
 and
> describes attacks where one valid certificate is substituted by another v=
alid
> certificate (exceopt for some DoS case that I don=B9t think is relevant her=
e).
> Now I have to ask myself. How likely is it that a legitimate TSA has 2  o=
r
> more legitimate certificates for the same public key with conflicting
> information (or information different enough to actually have a security
> impact) AND where the hash of these certificates produce a SHA-1 collisio=
n.
>=20
> This is not the previously discussed certificate collision attack using w=
eak
> certificate signing hash, where I may prepare a certificate request in a =
way
> where I can fool the CA to produce two valid certificates with the same
> certificate signature. If I would use that technique I would have to find=
 a
> way to prepare the TSA certificate requests, the TSA certificate hash nee=
d to
> be weak in addition to the certID hash AND In addition to that the comple=
te
> certificates (not only the to be signed part) need to create a hash colli=
sion
> when computing the certID.
>=20
> So, my first question is if this change addresses any real security threa=
t?
> Can someone provide a reasonable threat analysis?
> And consequently, if there are no real threats to solve, does this update
> motivate the potential interoperability issues that might be the result o=
f by
> allowing ESS CertIDv2 in time stamp tokens?
>=20
>=20
> If we do come to the conclusion that it is worth it, then why not just cr=
eate
> an update RFC updating RFC 3161 instead of replacing it?
>=20
> This update does not change any bits on the wire for implementations of t=
he
> current protocol. The only thing it does is to add an option to use ESS
> certIDv2 IF SHA-1 is not used as hash to identify the TSA=B9s certificate.
> This seems like a perfect thing for an update RFC. Another argument is th=
at
> the old editors that rightfully should have the credit for RFC 3161 are n=
ot
> part of this minor amendment but are completely erased from the update. T=
hat
> may be reasonable if the changes are major but I=B9m not so sure in this ca=
se.
>=20


--B_3319926831_1682829
Content-type: text/html;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Re: Do we need rfc 3161bis?</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt=
'>Yes, a good question indeed.<BR>
<BR>
Say that SHA-1 is completely broken in the sense that we can produce collis=
ions at will, of all sorts and forms.<BR>
Say also that we have a few valid TSA certificates issued for the same key =
pair, signed using good hash algorithms (or else all bets are off anyway).<B=
R>
<BR>
The randomness properties of SHA-1 will remain intact even if SHA-1 is brok=
en. This means that the risk/chance that two valid certificates, signed with=
 safe signature algorithms, will by chance produce collisions, is still tota=
lly negligible.<BR>
<BR>
Where am I thinking wrong here?<BR>
<BR>
/Stefan<BR>
<BR>
<BR>
<BR>
On 3/14/09 8:00 PM, &quot;Jim Schaad&quot; &lt;<a href=3D"ietf@augustcellars.=
com">[e-mail]</a>&gt; wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><=
SPAN STYLE=3D'font-size:11pt'><FONT COLOR=3D"#1F497D">Stefan,<BR>
&nbsp;<BR>
The question you need to be asking is &#8211; Do you believe that SHA-1 wil=
l be broken one day, and if it is broken do you want to have in place a solu=
tion to deal with it.<BR>
&nbsp;<BR>
Jim<BR>
&nbsp;<BR>
&nbsp;<BR>
</FONT><BR>
</SPAN></FONT><FONT SIZE=3D"2"><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:10pt'><B>From:</B> <a href=3D"[e-mail]=
.org">[e-mail]</a> [<a href=3D"mailto:owner-ietf-pkix@mail=
.imc.org">mailto:[e-mail]</a>] <B>On Behalf Of </B>Stefa=
n Santesson<BR>
<B>Sent:</B> Saturday, March 14, 2009 7:06 AM<BR>
<B>To:</B> IETF-pkix<BR>
<B>Subject:</B> Do we need rfc 3161bis?<BR>
</SPAN></FONT></FONT><FONT FACE=3D"Times New Roman"><SPAN STYLE=3D'font-size:12=
pt'> <BR>
</SPAN></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'=
font-size:11pt'>The more I look into this the more I get to doubt that we ac=
tually need 3161bis.<BR>
<BR>
The only substantial technical change I know of is to allow the updated ESS=
 certIDv2 to be used to identify the signer&#8217;s certificate IF the TSA f=
or some reason choose to hash its certificate with another hash then SHA-1.<=
BR>
<BR>
The rationale for the certID identifier is given in section 5 of RFC 2634 a=
nd describes attacks where one valid certificate is substituted by another v=
alid certificate (exceopt for some DoS case that I don&#8217;t think is rele=
vant here).<BR>
Now I have to ask myself. How likely is it that a legitimate TSA has 2 &nbs=
p;or more legitimate certificates for the same public key with conflicting i=
nformation (or information different enough to actually have a security impa=
ct) AND where the hash of these certificates produce a SHA-1 collision.<BR>
<BR>
This is not the previously discussed certificate collision attack using wea=
k certificate signing hash, where I may prepare a certificate request in a w=
ay where I can fool the CA to produce two valid certificates with the same c=
ertificate signature. If I would use that technique I would have to find a w=
ay to prepare the TSA certificate requests, the TSA certificate hash need to=
 be weak in addition to the certID hash AND In addition to that the complete=
 certificates (not only the to be signed part) need to create a hash collisi=
on when computing the certID.<BR>
<BR>
So, my first question is if this change addresses any real security threat?=
<BR>
Can someone provide a reasonable threat analysis?<BR>
And consequently, if there are no real threats to solve, does this update m=
otivate the potential interoperability issues that might be the result of by=
 allowing ESS CertIDv2 in time stamp tokens?<BR>
<BR>
<BR>
If we do come to the conclusion that it is worth it, then why not just crea=
te an update RFC updating RFC 3161 instead of replacing it?<BR>
<BR>
This update does not change any bits on the wire for implementations of the=
 current protocol. The only thing it does is to add an option to use ESS cer=
tIDv2 IF SHA-1 is not used as hash to identify the TSA&#8217;s certificate.<=
BR>
This seems like a perfect thing for an update RFC. Another argument is that=
 the old editors that rightfully should have the credit for RFC 3161 are not=
 part of this minor amendment but are completely erased from the update. Tha=
t may be reasonable if the changes are major but I&#8217;m not so sure in th=
is case.<BR>
<BR>
</SPAN></FONT></BLOCKQUOTE>
</BODY>
</HTML>


--B_3319926831_1682829--




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 n2EMUEIJ051960 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 14 Mar 2009 15:30:24 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2EMUEXO051959; Sat, 14 Mar 2009 15:30:14 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from argus.ritlabs.com (argus.ritlabs.com [91.198.236.2]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2EMUCjS051948; Sat, 14 Mar 2009 15:30:13 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (89-28-100-245.starnet.md [89.28.100.245]) (authenticated bits=0) by argus.ritlabs.com (8.14.2/8.14.2) with ESMTP id n2EMU9Fo027567 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 15 Mar 2009 00:30:09 +0200
CC: <[e-mail]>, <[e-mail]>
Date: Sun, 15 Mar 2009 00:29:45 +0200
From: "Maxim Masiutin" <[e-mail]>
In-Reply-To: <086a01c9a4ef$49782780$dc687680$@com>
MIME-Version: 1.0
Message-ID: <[e-mail]>
References: <[e-mail]> <086a01c9a4ef$49782780$dc687680$@com>
Reply-To: "Maxim Masiutin" <[e-mail]>
Subject: Re: RE: RFC4134 email mismatch in examples 4.8 and 4.9
To: "Jim Schaad" <[e-mail]>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on argus.ritlabs.com
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hello Jim,

Then you for replying. As I wrote in my first message, the two emails are different in the host part ("examples.com" vs "example.com"), where the character "s" after "example" before ".com" is the difference:

[e-mail]
[e-mail]



-- 
Best regards,
Maxim Masiutin                     
Ritlabs SRL
http://www.ritlabs.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 n2ELrg9h050588 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 14 Mar 2009 14:53:42 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2ELrfiR050587; Sat, 14 Mar 2009 14:53:41 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2ELrUs3050572 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 14 Mar 2009 14:53:41 -0700 (MST) (envelope-from [e-mail])
Received: from GALATIONS (unknown [207.202.179.27]) by smtp1.pacifier.net (Postfix) with ESMTP id 240D86EF59; Sat, 14 Mar 2009 14:53:30 -0700 (PDT)
From: "Jim Schaad" <[e-mail]>
To: "'Maxim Masiutin'" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: RE: RFC4134 email mismatch in examples 4.8 and 4.9
Date: Sat, 14 Mar 2009 14:53:18 -0700
Message-ID: <086a01c9a4ef$49782780$dc687680$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Acmk666Uws86s9IoQuiN4CXcD0QKRwAA4ndg
Content-Language: en-us
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

For the purposes of S/MIME all RFC822 addresses are considered to be case
insensitive.

Jim


> -----Original Message-----
> From: [e-mail] [mailto:owner-ietf-
> [e-mail]] On Behalf Of Maxim Masiutin
> Sent: Saturday, March 14, 2009 2:22 PM
> To: [e-mail]
> Cc: [e-mail]
> Subject: RFC4134 email mismatch in examples 4.8 and 4.9
> 
> Hello,
> 
> I have a question about RFC4134, Examples 4.8 and 4.9.
> 
> "From" line of the RFC-822 message is [e-mail], while the
> certificate's SubjectAlternativeName contains Rfc822Name =
> [e-mail]
> 
> So the two emails are different in the host part.
> 
> Is it OK for them to be different?
> 
> 
> --
> Best regards,
> Maxim Masiutin
> Ritlabs SRL
> http://www.ritlabs.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 n2ELhgDs049938 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 14 Mar 2009 14:43:42 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2ELhgET049936; Sat, 14 Mar 2009 14:43:42 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from argus.ritlabs.com (argus.ritlabs.com [91.198.236.2]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2ELheA3049921; Sat, 14 Mar 2009 14:43:41 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (89-28-100-245.starnet.md [89.28.100.245]) (authenticated bits=0) by argus.ritlabs.com (8.14.2/8.14.2) with ESMTP id n2ELha3f026105 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 14 Mar 2009 23:43:36 +0200
CC: [e-mail], [e-mail]
Date: Sat, 14 Mar 2009 23:43:18 +0200
From: "Maxim Masiutin" <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Reply-To: "Maxim Masiutin" <[e-mail]>
Subject: Re[2]: A contradiction between RFC3852 and RFC3278
To: "Sean Turner" <[e-mail]>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on argus.ritlabs.com
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hello Sean,

Maybe we should alter the description of signatureAlgorithm in section 2.1.1 of draft-smime-3278bis, to the following:

     - signatureAlgorithm contains the signature algorithm identifier 
       (see Section 7.1.3) where the public key part of it
       is ECDSA and the hash part MUST refer to the same algorithm as 
       specified in the digestAlgorithm field. signatureAlgorithm MUST
       be one of the following ecdsa-with-SHA1, 
       ecdsa-with-SHA224, ecdsa-with-SHA256, 
       ecdsa-with-SHA384, or ecdsa-with-SHA512. 


-- 
Best regards,
Maxim Masiutin                     
Ritlabs SRL
http://www.ritlabs.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 n2ELMo28048937 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 14 Mar 2009 14:22:50 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2ELMoNS048936; Sat, 14 Mar 2009 14:22:50 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from argus.ritlabs.com (argus.ritlabs.com [91.198.236.2]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2ELMbVV048913; Sat, 14 Mar 2009 14:22:48 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (89-28-100-245.starnet.md [89.28.100.245]) (authenticated bits=0) by argus.ritlabs.com (8.14.2/8.14.2) with ESMTP id n2ELMZQo025554 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 14 Mar 2009 23:22:36 +0200
CC: [e-mail]
Date: Sat, 14 Mar 2009 23:22:24 +0200
From: "Maxim Masiutin" <[e-mail]>
MIME-Version: 1.0
Message-ID: <[e-mail]>
Reply-To: "Maxim Masiutin" <[e-mail]>
Subject: RFC4134 email mismatch in examples 4.8 and 4.9
To: [e-mail]
Content-Type: text/plain; charset="Windows-1250"
Content-Transfer-Encoding: base64
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on argus.ritlabs.com
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

SGVsbG8sDQoNCkkgaGF2ZSBhIHF1ZXN0aW9uIGFib3V0IFJGQzQxMzQsIEV4YW1wbGVzIDQuOCBh
bmQgNC45Lg0KDQoiRnJvbSIgbGluZSBvZiB0aGUgUkZDLTgyMiBtZXNzYWdlIGlzIGFsaWNlRHNz
QGV4YW1wbGVzLmNvbSwgd2hpbGUgdGhlIGNlcnRpZmljYXRlknMgU3ViamVjdEFsdGVybmF0aXZl
TmFtZSBjb250YWlucyBSZmM4MjJOYW1lID0gQWxpY2VEU1NAZXhhbXBsZS5jb20NCg0KU28gdGhl
IHR3byBlbWFpbHMgYXJlIGRpZmZlcmVudCBpbiB0aGUgaG9zdCBwYXJ0Lg0KDQpJcyBpdCBPSyBm
b3IgdGhlbSB0byBiZSBkaWZmZXJlbnQ/DQoNCg0KLS0gDQpCZXN0IHJlZ2FyZHMsDQpNYXhpbSBN
YXNpdXRpbiAgICAgICAgICAgICAgICAgICAgICAgICANClJpdGxhYnMgU1JMDQpodHRwOi8vd3d3
LnJpdGxhYnMuY29tLw0K



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 n2EJ16Fv042046 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 14 Mar 2009 12:01:06 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2EJ16Xb042045; Sat, 14 Mar 2009 12:01:06 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.174]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2EJ0tDD042003 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <[e-mail]>; Sat, 14 Mar 2009 12:01:06 -0700 (MST) (envelope-from [e-mail])
Received: from GALATIONS (unknown [207.202.179.27]) by smtp4.pacifier.net (Postfix) with ESMTP id 174F86A50F; Sat, 14 Mar 2009 12:00:53 -0700 (PDT)
From: "Jim Schaad" <[e-mail]>
To: "'Stefan Santesson'" <[e-mail]>, "'IETF-pkix'" <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: RE: Do we need rfc 3161bis?
Date: Sat, 14 Mar 2009 12:00:43 -0700
Message-ID: <082801c9a4d7$2d24f350$876ed9f0$@com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0829_01C9A49C.80C61B50"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Acmkrf0j+yb7f0QChUOhT/ms/PsBpAAKRABQ
Content-Language: en-us
Sender: [e-mail]
Precedence: 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 multipart message in MIME format.

------=_NextPart_000_0829_01C9A49C.80C61B50
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Stefan,

 

The question you need to be asking is - Do you believe that SHA-1 will be
broken one day, and if it is broken do you want to have in place a solution
to deal with it.

 

Jim

 

 

From: [e-mail] [mailto:[e-mail]] On
Behalf Of Stefan Santesson
Sent: Saturday, March 14, 2009 7:06 AM
To: IETF-pkix
Subject: Do we need rfc 3161bis?

 

The more I look into this the more I get to doubt that we actually need
3161bis.

The only substantial technical change I know of is to allow the updated ESS
certIDv2 to be used to identify the signer's certificate IF the TSA for some
reason choose to hash its certificate with another hash then SHA-1.

The rationale for the certID identifier is given in section 5 of RFC 2634
and describes attacks where one valid certificate is substituted by another
valid certificate (exceopt for some DoS case that I don't think is relevant
here).
Now I have to ask myself. How likely is it that a legitimate TSA has 2  or
more legitimate certificates for the same public key with conflicting
information (or information different enough to actually have a security
impact) AND where the hash of these certificates produce a SHA-1 collision.

This is not the previously discussed certificate collision attack using weak
certificate signing hash, where I may prepare a certificate request in a way
where I can fool the CA to produce two valid certificates with the same
certificate signature. If I would use that technique I would have to find a
way to prepare the TSA certificate requests, the TSA certificate hash need
to be weak in addition to the certID hash AND In addition to that the
complete certificates (not only the to be signed part) need to create a hash
collision when computing the certID.

So, my first question is if this change addresses any real security threat?
Can someone provide a reasonable threat analysis?
And consequently, if there are no real threats to solve, does this update
motivate the potential interoperability issues that might be the result of
by allowing ESS CertIDv2 in time stamp tokens?


If we do come to the conclusion that it is worth it, then why not just
create an update RFC updating RFC 3161 instead of replacing it?

This update does not change any bits on the wire for implementations of the
current protocol. The only thing it does is to add an option to use ESS
certIDv2 IF SHA-1 is not used as hash to identify the TSA's certificate.
This seems like a perfect thing for an update RFC. Another argument is that
the old editors that rightfully should have the credit for RFC 3161 are not
part of this minor amendment but are completely erased from the update. That
may be reasonable if the changes are major but I'm not so sure in this case.


------=_NextPart_000_0829_01C9A49C.80C61B50
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)">
<title>Do we need rfc 3161bis?</title>
<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;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","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-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:1.0in 1.0in 1.0in 1.0in;}
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'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Stefan,<o:p></o:p></span></p>

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

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>The question you need to be asking is &#8211; Do you =
believe that
SHA-1 will be broken one day, and if it is broken do you want to have in =
place
a solution to deal with it.<o:p></o:p></span></p>

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

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Jim<o:p></o:p></span></p>

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

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

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

<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"'> =
[e-mail]
[mailto:[e-mail]] <b>On Behalf Of </b>Stefan =
Santesson<br>
<b>Sent:</b> Saturday, March 14, 2009 7:06 AM<br>
<b>To:</b> IETF-pkix<br>
<b>Subject:</b> Do we need rfc 3161bis?<o:p></o:p></span></p>

</div>

</div>

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

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><span =
style=3D'font-size:11.0pt;
font-family:"Calibri","sans-serif"'>The more I look into this the more I =
get to
doubt that we actually need 3161bis.<br>
<br>
The only substantial technical change I know of is to allow the updated =
ESS
certIDv2 to be used to identify the signer&#8217;s certificate IF the =
TSA for some
reason choose to hash its certificate with another hash then SHA-1.<br>
<br>
The rationale for the certID identifier is given in section 5 of RFC =
2634 and
describes attacks where one valid certificate is substituted by another =
valid
certificate (exceopt for some DoS case that I don&#8217;t think is =
relevant here).<br>
Now I have to ask myself. How likely is it that a legitimate TSA has 2 =
&nbsp;or
more legitimate certificates for the same public key with conflicting
information (or information different enough to actually have a security
impact) AND where the hash of these certificates produce a SHA-1 =
collision.<br>
<br>
This is not the previously discussed certificate collision attack using =
weak
certificate signing hash, where I may prepare a certificate request in a =
way
where I can fool the CA to produce two valid certificates with the same
certificate signature. If I would use that technique I would have to =
find a way
to prepare the TSA certificate requests, the TSA certificate hash need =
to be
weak in addition to the certID hash AND In addition to that the complete
certificates (not only the to be signed part) need to create a hash =
collision
when computing the certID.<br>
<br>
So, my first question is if this change addresses any real security =
threat?<br>
Can someone provide a reasonable threat analysis?<br>
And consequently, if there are no real threats to solve, does this =
update
motivate the potential interoperability issues that might be the result =
of by
allowing ESS CertIDv2 in time stamp tokens?<br>
<br>
<br>
If we do come to the conclusion that it is worth it, then why not just =
create
an update RFC updating RFC 3161 instead of replacing it?<br>
<br>
This update does not change any bits on the wire for implementations of =
the
current protocol. The only thing it does is to add an option to use ESS
certIDv2 IF SHA-1 is not used as hash to identify the TSA&#8217;s =
certificate.<br>
This seems like a perfect thing for an update RFC. Another argument is =
that the
old editors that rightfully should have the credit for RFC 3161 are not =
part of
this minor amendment but are completely erased from the update. That may =
be
reasonable if the changes are major but I&#8217;m not so sure in this =
case.</span><o:p></o:p></p>

</div>

</div>

</body>

</html>

------=_NextPart_000_0829_01C9A49C.80C61B50--



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 n2EE6BD5030298 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 14 Mar 2009 07:06:12 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2EE6BS7030296; Sat, 14 Mar 2009 07:06:11 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from s87.loopia.se (s87.loopia.se [194.9.95.112]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2EE5xIL030283 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Sat, 14 Mar 2009 07:06:10 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 3187 invoked from network); 14 Mar 2009 14:06:03 -0000
Received: from s34.loopia.se (HELO s128.loopia.se) ([194.9.94.70]) (envelope-sender <[e-mail]>) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for <[e-mail]>; 14 Mar 2009 14:06:03 -0000
Received: (qmail 5882 invoked from network); 14 Mar 2009 14:05:57 -0000
Received: from 90-229-233-249-no153.tbcn.telia.com (HELO [192.168.0.17]) ([e-mail]@[90.229.233.249]) (envelope-sender <[e-mail]>) by s128.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <[e-mail]>; 14 Mar 2009 14:05:57 -0000
User-Agent: Microsoft-Entourage/12.15.0.081119
Date: Sat, 14 Mar 2009 15:05:54 +0100
Subject: Do we need rfc 3161bis?
From: Stefan Santesson <[e-mail]>
To: IETF-pkix <[e-mail]>
Message-ID: <[e-mail]>
Thread-Topic: Do we need rfc 3161bis?
Thread-Index: Acmkrf0j+yb7f0QChUOhT/ms/PsBpA==
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3319887957_685341"
Sender: [e-mail]
Precedence: 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 message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3319887957_685341
Content-type: text/plain;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

The more I look into this the more I get to doubt that we actually need
3161bis.

The only substantial technical change I know of is to allow the updated ESS
certIDv2 to be used to identify the signer=B9s certificate IF the TSA for som=
e
reason choose to hash its certificate with another hash then SHA-1.

The rationale for the certID identifier is given in section 5 of RFC 2634
and describes attacks where one valid certificate is substituted by another
valid certificate (exceopt for some DoS case that I don=B9t think is relevant
here).
Now I have to ask myself. How likely is it that a legitimate TSA has 2  or
more legitimate certificates for the same public key with conflicting
information (or information different enough to actually have a security
impact) AND where the hash of these certificates produce a SHA-1 collision.

This is not the previously discussed certificate collision attack using wea=
k
certificate signing hash, where I may prepare a certificate request in a wa=
y
where I can fool the CA to produce two valid certificates with the same
certificate signature. If I would use that technique I would have to find a
way to prepare the TSA certificate requests, the TSA certificate hash need
to be weak in addition to the certID hash AND In addition to that the
complete certificates (not only the to be signed part) need to create a has=
h
collision when computing the certID.

So, my first question is if this change addresses any real security threat?
Can someone provide a reasonable threat analysis?
And consequently, if there are no real threats to solve, does this update
motivate the potential interoperability issues that might be the result of
by allowing ESS CertIDv2 in time stamp tokens?


If we do come to the conclusion that it is worth it, then why not just
create an update RFC updating RFC 3161 instead of replacing it?

This update does not change any bits on the wire for implementations of the
current protocol. The only thing it does is to add an option to use ESS
certIDv2 IF SHA-1 is not used as hash to identify the TSA=B9s certificate.
This seems like a perfect thing for an update RFC. Another argument is that
the old editors that rightfully should have the credit for RFC 3161 are not
part of this minor amendment but are completely erased from the update. Tha=
t
may be reasonable if the changes are major but I=B9m not so sure in this case=
.



--B_3319887957_685341
Content-type: text/html;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Do we need rfc 3161bis?</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt=
'>The more I look into this the more I get to doubt that we actually need 31=
61bis.<BR>
<BR>
The only substantial technical change I know of is to allow the updated ESS=
 certIDv2 to be used to identify the signer&#8217;s certificate IF the TSA f=
or some reason choose to hash its certificate with another hash then SHA-1.<=
BR>
<BR>
The rationale for the certID identifier is given in section 5 of RFC 2634 a=
nd describes attacks where one valid certificate is substituted by another v=
alid certificate (exceopt for some DoS case that I don&#8217;t think is rele=
vant here).<BR>
Now I have to ask myself. How likely is it that a legitimate TSA has 2 &nbs=
p;or more legitimate certificates for the same public key with conflicting i=
nformation (or information different enough to actually have a security impa=
ct) AND where the hash of these certificates produce a SHA-1 collision.<BR>
<BR>
This is not the previously discussed certificate collision attack using wea=
k certificate signing hash, where I may prepare a certificate request in a w=
ay where I can fool the CA to produce two valid certificates with the same c=
ertificate signature. If I would use that technique I would have to find a w=
ay to prepare the TSA certificate requests, the TSA certificate hash need to=
 be weak in addition to the certID hash AND In addition to that the complete=
 certificates (not only the to be signed part) need to create a hash collisi=
on when computing the certID.<BR>
<BR>
So, my first question is if this change addresses any real security threat?=
<BR>
Can someone provide a reasonable threat analysis?<BR>
And consequently, if there are no real threats to solve, does this update m=
otivate the potential interoperability issues that might be the result of by=
 allowing ESS CertIDv2 in time stamp tokens?<BR>
<BR>
<BR>
If we do come to the conclusion that it is worth it, then why not just crea=
te an update RFC updating RFC 3161 instead of replacing it?<BR>
<BR>
This update does not change any bits on the wire for implementations of the=
 current protocol. The only thing it does is to add an option to use ESS cer=
tIDv2 IF SHA-1 is not used as hash to identify the TSA&#8217;s certificate.<=
BR>
This seems like a perfect thing for an update RFC. Another argument is that=
 the old editors that rightfully should have the credit for RFC 3161 are not=
 part of this minor amendment but are completely erased from the update. Tha=
t may be reasonable if the changes are major but I&#8217;m not so sure in th=
is case.<BR>
<BR>
</SPAN></FONT>
</BODY>
</HTML>


--B_3319887957_685341--




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 n2DNuUW1092270 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Mar 2009 16:56:30 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2DNuUFo092268; Fri, 13 Mar 2009 16:56:30 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp101.biz.mail.re2.yahoo.com (smtp101.biz.mail.re2.yahoo.com [68.142.229.215]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n2DNuIjk092246 for <[e-mail]>; Fri, 13 Mar 2009 16:56:28 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 2666 invoked from network); 13 Mar 2009 23:56:17 -0000
Received: from unknown (HELO sean-turners-macbook.local) (turners@96.231.128.241 with plain) by smtp101.biz.mail.re2.yahoo.com with SMTP; 13 Mar 2009 23:56:17 -0000
X-Yahoo-SMTP: qPTWNAeswBAtDTSn9GKlmmL3C90ke7grn_5n9To-
X-YMail-OSG: heay3_sVM1ltRNlCCbsjc1cH1Pd02qxstxgbC7s7UFBwiNdl4sIi2TTGDz5p0dyazhVzOELEJGQBHpHcoe6sBYRTliw5TiuW4kyAazdTsblsZ.G7J6vtU.VXQXXYPLp62reHdjDUKyGa4sUWcKpAuoVInVuFosf07M7Yrk_qTPTnVG9FcMJpy4Pueyhp
X-Yahoo-Newman-Property: ymail-3
Message-ID: <[e-mail]>
Date: Fri, 13 Mar 2009 19:56:24 -0400
From: Sean Turner <[e-mail]>
User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209)
MIME-Version: 1.0
To: Maxim Masiutin <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: A contradiction between RFC3852 and RFC3278
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=windows-1250; format=flowed
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Maxim,

I don't have any objection to adding the note to draft-smime-3278bis.

spt

Maxim Masiutin wrote:
> Hello Sean,
> 
> In all CMS messages that I’ve seen, when RSA algorithm is used, SignatureAlgorithm in the SignerInfo is rsaEncryption, not md5WithRSAEncryption. That’s why it made confusion when I was implementing elliptic curves.
> Maybe, if an update of RFC3852 is planned, we will add a clarification for this?
> Also, while RFC3278-bis is in the draft status, what about adding a clarification that hash in SignatureAlgorithm and DigestAlgorithm must match?
> 
> 



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 n2DGK0gx069487 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Mar 2009 09:20:00 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2DGK0Is069486; Fri, 13 Mar 2009 09:20:00 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from alfa.ritlabs.com (alfa.ritlabs.com [212.56.194.252]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2DGJmcI069465 for <[e-mail]>; Fri, 13 Mar 2009 09:19:59 -0700 (MST) (envelope-from [e-mail])
Received: from Maxim-PC1 (maxim.alfa.ritlabs.com [212.56.194.246]) by alfa.ritlabs.com (8.14.2/8.14.2) with ESMTP id n2DGJflY015472; Fri, 13 Mar 2009 18:19:43 +0200
CC: [e-mail]
Date: Fri, 13 Mar 2009 18:19:42 +0200
From: "Maxim Masiutin" <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Reply-To: "Maxim Masiutin" <[e-mail]>
Subject: Re[2]: A contradiction between RFC3852 and RFC3278
To: "Sean Turner" <[e-mail]>
Content-Type: text/plain; charset="Windows-1250"
Content-Transfer-Encoding: base64
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on alfa.ritlabs.com
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

SGVsbG8gU2VhbiwNCg0KSW4gYWxsIENNUyBtZXNzYWdlcyB0aGF0IEmSdmUgc2Vlbiwgd2hlbiBS
U0EgYWxnb3JpdGhtIGlzIHVzZWQsIFNpZ25hdHVyZUFsZ29yaXRobSBpbiB0aGUgU2lnbmVySW5m
byBpcyByc2FFbmNyeXB0aW9uLCBub3QgbWQ1V2l0aFJTQUVuY3J5cHRpb24uIFRoYXSScyB3aHkg
aXQgbWFkZSBjb25mdXNpb24gd2hlbiBJIHdhcyBpbXBsZW1lbnRpbmcgZWxsaXB0aWMgY3VydmVz
Lg0KTWF5YmUsIGlmIGFuIHVwZGF0ZSBvZiBSRkMzODUyIGlzIHBsYW5uZWQsIHdlIHdpbGwgYWRk
IGEgY2xhcmlmaWNhdGlvbiBmb3IgdGhpcz8NCkFsc28sIHdoaWxlIFJGQzMyNzgtYmlzIGlzIGlu
IHRoZSBkcmFmdCBzdGF0dXMsIHdoYXQgYWJvdXQgYWRkaW5nIGEgY2xhcmlmaWNhdGlvbiB0aGF0
IGhhc2ggaW4gU2lnbmF0dXJlQWxnb3JpdGhtIGFuZCBEaWdlc3RBbGdvcml0aG0gbXVzdCBtYXRj
aD8NCg0KDQotLSANCkJlc3QgcmVnYXJkcywNCk1heGltIE1hc2l1dGluICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIG1haWx0bzptYXhAcml0bGFicy5jb20NCg==



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 n2DFwFaf067774 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Mar 2009 08:58:15 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2DFwFwA067773; Fri, 13 Mar 2009 08:58:15 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp110.biz.mail.re2.yahoo.com (smtp110.biz.mail.re2.yahoo.com [206.190.53.9]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n2DFw4dj067761 for <[e-mail]>; Fri, 13 Mar 2009 08:58:14 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 15528 invoked from network); 13 Mar 2009 15:58:04 -0000
Received: from unknown (HELO ?192.168.1.2?) (turners@71.191.0.18 with plain) by smtp110.biz.mail.re2.yahoo.com with SMTP; 13 Mar 2009 15:58:03 -0000
X-Yahoo-SMTP: qPTWNAeswBAtDTSn9GKlmmL3C90ke7grn_5n9To-
X-YMail-OSG: QJEzvZUVM1ng12_nPiLv8_5uvbycWuJ0_PIu9VlEJIzpk4.PDl80.LZA468U_FJ3xGu67twPJ94x3g_sl465SOiB6Hq5HVI3b7ewMhsXEQAhGZ8ne4cuj4hhj9FFvml6s87tiEa2.BOFc7ArLW1P2Wd.tv.mVfzE.bE8TJbk2nhyloyU9yNm6F7S6CUAznmgtCwClCE5HF.gxtGQ.w--
X-Yahoo-Newman-Property: ymail-3
Message-ID: <[e-mail]>
Date: Fri, 13 Mar 2009 11:58:16 -0400
From: Sean Turner <[e-mail]>
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: Maxim Masiutin <[e-mail]>
CC: [e-mail]
Subject: Re: A contradiction between RFC3852 and RFC3278
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=windows-1250; format=flowed
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Maxim,

I don't think that having the name of the hash algorithm in the 
signature ID assumes assumes that the algorithm takes as an input the 
whole message itself rather than the digest.  There are many examples 
where the object identifier's name for a signature algorithms includes 
the name of the hash that's used: md*WithRSAEncryption, 
sha*-WithRSAEncryption, and id-dsa-with-sha*. RFC 3278 and 
draft-ietf-smime-3278bis just follow the examples set by algorithms 
defined earlier.

I think it's pretty well implied that the digestAlgorithm hash (e.g., 
id-sha256) algorithm and the name of the hash in the signatureAlgorithm 
(e.g., ecdsda-with-SHA256) need to match.

spt

Maxim Masiutin wrote:
> Hello Ietf-Pkix,
> 
> I have found a contradiction between RFC3278 (and draft-ietf-smime-3278bis-05.txt work in progress) and RFC3852.
> 
> RFC3852 declares that the signatureAlgorithm in the SignerInfo should not be a compound algorithm of a public key algorithm and a hash function. Section 10.1.2 of RFC3852: ”The SignatureAlgorithmIdentifier type identifies a signature algorithm.  Examples include RSA, DSA, and ECDSA.  A signature algorithm supports signature generation and verification operations.  The signature generation operation uses the message digest and the signer’s private key to generate a signature value”. As specified in the RFC3852, the signature algorithm takes the message digest, i.e. the result of a hash function specified in the digestAlgorithm in the SignerInfo
> 
> 
> RFC3278 (and bis) declares that signatureAlgorithm contains the algorithm identifier ecdsa-with-SHA1 (bis also allows any other SHA hash), i.e. assumes that the algorithm takes as an input the whole message itself rather than the digest. It also tells that the digestAlgorithm in the SignerInfo should also be a SHA hash. Maybe it assumes that the SHA in digestAlgorithm should match SHA in signatureAlgorithm, but it is not explicitly clarified. Thus, a combination of ecdsa-with-SHA224 in signatureAlgorithm and id-sha-512 in digestAlgorithm is not prohibited.
> 
> 
> How can we resolve this contradiction of RFC3852 and RFC3278?
> 
>   
> 
> 



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 n2DCcNBV057163 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Mar 2009 05:38:23 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2DCcNFS057162; Fri, 13 Mar 2009 05:38:23 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from argus.ritlabs.com (argus.ritlabs.com [91.198.236.2]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2DCcBoa057149 for <[e-mail]>; Fri, 13 Mar 2009 05:38:22 -0700 (MST) (envelope-from [e-mail])
Received: from 127.0.0.1 (89-28-100-245.starnet.md [89.28.100.245]) (authenticated bits=0) by argus.ritlabs.com (8.14.2/8.14.2) with ESMTP id n2DCc9in002006 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <[e-mail]>; Fri, 13 Mar 2009 14:38:10 +0200
Date: Fri, 13 Mar 2009 14:38:03 +0200
From: "Maxim Masiutin" <[e-mail]>
MIME-Version: 1.0
Message-ID: <[e-mail]>
Reply-To: "Maxim Masiutin" <[e-mail]>
Subject: A contradiction between RFC3852 and RFC3278
To: [e-mail]
Content-Type: text/plain; charset="Windows-1250"
Content-Transfer-Encoding: base64
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on argus.ritlabs.com
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

SGVsbG8gSWV0Zi1Qa2l4LA0KDQpJIGhhdmUgZm91bmQgYSBjb250cmFkaWN0aW9uIGJldHdlZW4g
UkZDMzI3OCAoYW5kIGRyYWZ0LWlldGYtc21pbWUtMzI3OGJpcy0wNS50eHQgd29yayBpbiBwcm9n
cmVzcykgYW5kIFJGQzM4NTIuDQoNClJGQzM4NTIgZGVjbGFyZXMgdGhhdCB0aGUgc2lnbmF0dXJl
QWxnb3JpdGhtIGluIHRoZSBTaWduZXJJbmZvIHNob3VsZCBub3QgYmUgYSBjb21wb3VuZCBhbGdv
cml0aG0gb2YgYSBwdWJsaWMga2V5IGFsZ29yaXRobSBhbmQgYSBoYXNoIGZ1bmN0aW9uLiBTZWN0
aW9uIDEwLjEuMiBvZiBSRkMzODUyOiCUVGhlIFNpZ25hdHVyZUFsZ29yaXRobUlkZW50aWZpZXIg
dHlwZSBpZGVudGlmaWVzIGEgc2lnbmF0dXJlIGFsZ29yaXRobS4gIEV4YW1wbGVzIGluY2x1ZGUg
UlNBLCBEU0EsIGFuZCBFQ0RTQS4gIEEgc2lnbmF0dXJlIGFsZ29yaXRobSBzdXBwb3J0cyBzaWdu
YXR1cmUgZ2VuZXJhdGlvbiBhbmQgdmVyaWZpY2F0aW9uIG9wZXJhdGlvbnMuICBUaGUgc2lnbmF0
dXJlIGdlbmVyYXRpb24gb3BlcmF0aW9uIHVzZXMgdGhlIG1lc3NhZ2UgZGlnZXN0IGFuZCB0aGUg
c2lnbmVyknMgcHJpdmF0ZSBrZXkgdG8gZ2VuZXJhdGUgYSBzaWduYXR1cmUgdmFsdWWULiBBcyBz
cGVjaWZpZWQgaW4gdGhlIFJGQzM4NTIsIHRoZSBzaWduYXR1cmUgYWxnb3JpdGhtIHRha2VzIHRo
ZSBtZXNzYWdlIGRpZ2VzdCwgaS5lLiB0aGUgcmVzdWx0IG9mIGEgaGFzaCBmdW5jdGlvbiBzcGVj
aWZpZWQgaW4gdGhlIGRpZ2VzdEFsZ29yaXRobSBpbiB0aGUgU2lnbmVySW5mbw0KDQoNClJGQzMy
NzggKGFuZCBiaXMpIGRlY2xhcmVzIHRoYXQgc2lnbmF0dXJlQWxnb3JpdGhtIGNvbnRhaW5zIHRo
ZSBhbGdvcml0aG0gaWRlbnRpZmllciBlY2RzYS13aXRoLVNIQTEgKGJpcyBhbHNvIGFsbG93cyBh
bnkgb3RoZXIgU0hBIGhhc2gpLCBpLmUuIGFzc3VtZXMgdGhhdCB0aGUgYWxnb3JpdGhtIHRha2Vz
IGFzIGFuIGlucHV0IHRoZSB3aG9sZSBtZXNzYWdlIGl0c2VsZiByYXRoZXIgdGhhbiB0aGUgZGln
ZXN0LiBJdCBhbHNvIHRlbGxzIHRoYXQgdGhlIGRpZ2VzdEFsZ29yaXRobSBpbiB0aGUgU2lnbmVy
SW5mbyBzaG91bGQgYWxzbyBiZSBhIFNIQSBoYXNoLiBNYXliZSBpdCBhc3N1bWVzIHRoYXQgdGhl
IFNIQSBpbiBkaWdlc3RBbGdvcml0aG0gc2hvdWxkIG1hdGNoIFNIQSBpbiBzaWduYXR1cmVBbGdv
cml0aG0sIGJ1dCBpdCBpcyBub3QgZXhwbGljaXRseSBjbGFyaWZpZWQuIFRodXMsIGEgY29tYmlu
YXRpb24gb2YgZWNkc2Etd2l0aC1TSEEyMjQgaW4gc2lnbmF0dXJlQWxnb3JpdGhtIGFuZCBpZC1z
aGEtNTEyIGluIGRpZ2VzdEFsZ29yaXRobSBpcyBub3QgcHJvaGliaXRlZC4NCg0KDQpIb3cgY2Fu
IHdlIHJlc29sdmUgdGhpcyBjb250cmFkaWN0aW9uIG9mIFJGQzM4NTIgYW5kIFJGQzMyNzg/DQoN
CiAgDQoNCg0KLS0gDQpCZXN0IHJlZ2FyZHMsDQpNYXhpbSBNYXNpdXRpbiAgICAgICAgICAgICAg
ICAgICAgICAgICANClJpdGxhYnMgU1JMDQpodHRwOi8vd3d3LnJpdGxhYnMuY29tLw0K



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 n2D8ud8u043327 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Mar 2009 01:56:39 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2D8udKG043326; Fri, 13 Mar 2009 01:56:39 -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 n2D8uRu2043312 for <[e-mail]>; Fri, 13 Mar 2009 01:56:38 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (alg3 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 02D1520C0B0; Fri, 13 Mar 2009 09:56:26 +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 99D7820C0AF; Fri, 13 Mar 2009 09:56:25 +0100 (CET)
Received: from [10.208.1.240] ([10.208.1.240]) by mail-srv1.secumail.de with Microsoft SMTPSVC(6.0.3790.3959); Fri, 13 Mar 2009 09:56:25 +0100
Message-ID: <[e-mail]>
Date: Fri, 13 Mar 2009 09:56:24 +0100
From: Johannes Merkle <[e-mail]>
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: Alfredo Esposito <[e-mail]>
CC: Stefan Santesson <[e-mail]>, Peter Sylvester <[e-mail]>, [e-mail]
Subject: Re: draft-ietf-pkix-rfc3161bis-01.txt
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: 8bit
X-OriginalArrivalTime: 13 Mar 2009 08:56:25.0515 (UTC) FILETIME=[970B57B0:01C9A3B9]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

so, if a "time stamp Responder" uses several signature creation devices in order to increase performance, but the
corresponding certificates are issued for the same subject names, these signature creation devices represent the same
TSU? This seems counterintuitive to me.
And I am not sure whether this (quite typical) scenario is reflected by the new draft. At least the last sentence in
section 3.3 indicates a different scenario:
   A TSS MAY have distinct TSUs, e.g., to accommodate different
   policies, different algorithms, different private key sizes or to
   increase the performance.

Johannes


Alfredo Esposito schrieb am 12.03.2009 17:27:
> 
> I love joking with the words in my own language, but my English is not
> smart enough
> TSU is the subject of a X.509 public key certificate and the
> corresponding private key is used to sign time-stamp-token compliant
> with IETF RFC 3161
> Is it better?
> 
> 
> Stefan Santesson wrote:
>> Alfred,
>>
>>  
>>> The meaning of TSU seems to me pretty clear: it is the entity signing
>>> the time stamp token.
>>>     
>>
>> You see, already here you loose me.
>>
>> How can a "Unit" be an Entity? If so, how do you define entity?
>>
>> /Stefan
>>
>>
>>
>>
>>   
> 

-- 
Viele Grüße,
Johannes Merkle



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 n2D0GHYI022795 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Mar 2009 17:16:17 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2D0GHDs022794; Thu, 12 Mar 2009 17:16:17 -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 n2D0GGTs022785 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 12 Mar 2009 17:16:16 -0700 (MST) (envelope-from [e-mail])
Received: from dommiel.bbn.com ([192.1.122.15] helo=[172.28.172.219]) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from <[e-mail]>) id 1Lhv4F-0008IQ-AO; Thu, 12 Mar 2009 20:16:03 -0400
Mime-Version: 1.0
Message-Id: <p06240806c5df561cbb52@[172.28.172.219]>
In-Reply-To: <p06240860c5deebb4b2f6@[10.20.30.158]>
References: <[e-mail]> <p06240860c5deebb4b2f6@[10.20.30.158]>
Date: Thu, 12 Mar 2009 20:15:59 -0400
To: Paul Hoffman <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Call for agenda items
Cc: Stefan Santesson <[e-mail]>, IETF-pkix <[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 9:49 AM -0700 3/12/09, Paul Hoffman wrote:
>At 3:13 AM +0100 3/12/09, Stefan Santesson wrote:
>>I lack information about 3 active WG documents:
>>  - New ASN.1
>
>We have posted a new draft addressing the WGLC comments, but do not 
>need to spend face-to-face time telling people that fact. We will 
>send out a request for people to re-check the modules soon but, 
>again, don't need to take up meeting time doing that.
>
>--Paul Hoffman, Director
>--VPN Consortium

Paul,

Please post a message describing the changes made in response to WGLC comments.

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 n2CI6r9P005369 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Mar 2009 11:06:53 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2CI6rr1005368; Thu, 12 Mar 2009 11:06:53 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from s87.loopia.se (s87.loopia.se [194.9.95.112]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2CI6ocj005362 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 12 Mar 2009 11:06:51 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 23117 invoked from network); 12 Mar 2009 18:00:16 -0000
Received: from s34.loopia.se (HELO s19.loopia.se) ([194.9.94.70]) (envelope-sender <[e-mail]>) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for <[e-mail]>; 12 Mar 2009 18:00:16 -0000
Received: (qmail 62312 invoked from network); 12 Mar 2009 18:00:08 -0000
Received: from 90-229-233-249-no153.tbcn.telia.com (HELO [192.168.0.17]) ([e-mail]@[90.229.233.249]) (envelope-sender <[e-mail]>) by s19.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <[e-mail]>; 12 Mar 2009 18:00:08 -0000
User-Agent: Microsoft-Entourage/12.15.0.081119
Date: Thu, 12 Mar 2009 19:00:04 +0100
Subject: Re: draft-ietf-pkix-rfc3161bis-01.txt
From: Stefan Santesson <[e-mail]>
To: Alfredo Esposito <[e-mail]>
CC: <[e-mail]>
Message-ID: <[e-mail]>
Thread-Topic: draft-ietf-pkix-rfc3161bis-01.txt
Thread-Index: AcmjPF7DI2SnqlJe5EOS+uU5amRGkg==
In-Reply-To: <[e-mail]>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I can understand that it is a plus for a policy document, but not for the
protocol standard, especially not when we are "updating" an existing
standard.

I could argue the same for PKI. When describing a certificate issuing
service from a policy perspective I may want to distinguish between the
legal entity responsible for the service, the RA, the cryptographic modules
and the keys. But for the sake of defining the certificate standard, we only
have one entity (the certificate issuer a.k.a. The CA).

/Stefan


On 3/12/09 6:23 PM, "Alfredo Esposito" <[e-mail]> wrote:

> 
> Stefan
> Sure, for the mere description of the protocol we just need a
> "time-stamp" responder (may be the best term), unaware of the technical
> implementation and of any way the responder is organized.
> Nevertheless, IMHO, distinguishing among the physical responder and the
> organization ("the authority") liable for the service was a plus.
> 
> 
> 
> Stefan Santesson wrote:
>> Alfredo,
>> 
>> It may seem that I'm kidding around with words, but to me it is larger than
>> that.
>> 
>> No your definition does not help convince me why I need three separate terms
>> to describe one entity of a protocol, unless they are distinguished in the
>> protocol bits on the wire.
>> 
>> If the protocol could be defined for a TSA, and the bits on the wire are the
>> same today, except for the CertID, then why do I have to split the entity
>> into three separate terms. It's just confusing.
>> 
>> Where is the benefit?
>> 
>> /Stefan
>> 
>> 
>> 
>> On 3/12/09 5:27 PM, "Alfredo Esposito" <[e-mail]> wrote:
>> 
>>   
>>> I love joking with the words in my own language, but my English is not
>>> smart enough
>>> TSU is the subject of a X.509 public key certificate and the
>>> corresponding private key is used to sign time-stamp-token compliant
>>> with IETF RFC 3161
>>> Is it better?
>>> 
>>> 
>>> Stefan Santesson wrote:
>>>     
>>>> Alfred,
>>>> 
>>>>   
>>>>       
>>>>> The meaning of TSU seems to me pretty clear: it is the entity signing
>>>>> the time stamp token.
>>>>>     
>>>>>         
>>>> You see, already here you loose me.
>>>> 
>>>> How can a "Unit" be an Entity? If so, how do you define entity?
>>>> 
>>>> /Stefan
>>>> 
>>>> 
>>>> 
>>>> 
>>>>   
>>>>       
>> 
>> 
>> 
>>   
> 




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 n2CHRY6h003265 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Mar 2009 10:27:34 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2CHRYCM003264; Thu, 12 Mar 2009 10:27:34 -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 n2CHRM17003249 for <[e-mail]>; Thu, 12 Mar 2009 10:27:33 -0700 (MST) (envelope-from [e-mail])
Received: from MSGA-001.frcl.bull.fr (msga-001.frcl.bull.fr [129.184.87.31]) by odin2.bull.net (Bull S.A.) with ESMTP id 2AB45201E2 for <[e-mail]>; Thu, 12 Mar 2009 18:26:38 +0100 (CET)
Received: from FRCLS4013 ([129.182.108.120]) by MSGA-001.frcl.bull.fr (Lotus Domino Release 5.0.11) with SMTP id 2009031218272058:284816 ; Thu, 12 Mar 2009 18:27:20 +0100 
Reply-To: [e-mail]
From: "Denis Pinkas"<[e-mail]>
To: "ietf-pkix"<[e-mail]>
Subject: Re: draft-ietf-pkix-rfc3161bis-01.txt
Date: Thu, 12 Mar 2009 18:27:20 +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 12/03/2009 18:27:20, Serialize by Router on MSGA-001/FR/BULL(Release 5.0.11  |July 24, 2002) at 12/03/2009 18:27:22, Serialize complete at 12/03/2009 18:27:22
Content-Type: multipart/alternative;  boundary="----=_NextPart_09031218271969540460310_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_09031218271969540460310_002
Content-Type: text/plain; 
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

Stefan,

When you use the TSP (P =3D Protocol), you talk to a service (in this cas=
e,  a Time Stamping Service).

You will get a response from one of the TSUs behind that service.

If the request is sucessful, the TST is signed by a TSU.

Every TSU is managed by a TSA.

Denis

----- Message re=E7u -----=20
De : owner-ietf-pkix=20
=C0 : Alfredo Esposito=20
Date : 2009-03-12, 17:49:08
Sujet : Re: draft-ietf-pkix-rfc3161bis-01.txt


Alfredo,

It may seem that I'm kidding around with words, but to me it is larger th=
an
that.

No your definition does not help convince me why I need three separate te=
rms
to describe one entity of a protocol, unless they are distinguished in th=
e
protocol bits on the wire.

If the protocol could be defined for a TSA, and the bits on the wire are =
the
same today, except for the CertID, then why do I have to split the entity
into three separate terms. It's just confusing.

Where is the benefit?

/Stefan



On 3/12/09 5:27 PM, "Alfredo Esposito" <[e-mail]> wro=
te:

> I love joking with the words in my own language, but my English is not
> smart enough
> TSU is the subject of a X.509 public key certificate and the
> corresponding private key is used to sign time-stamp-token compliant
> with IETF RFC 3161
> Is it better?
>=20
>=20
> Stefan Santesson wrote:
>> Alfred,
>>=20
>>=20
>>> The meaning of TSU seems to me pretty clear: it is the entity signing
>>> the time stamp token.
>>>=20
>>=20
>> You see, already here you loose me.
>>=20
>> How can a "Unit" be an Entity? If so, how do you define entity?
>>=20
>> /Stefan
>>=20
>>=20
>>=20
>>=20
>>=20

------=_NextPart_09031218271969540460310_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>Stefan,</DIV>
<DIV>&nbsp;</DIV>
<DIV>When you use&nbsp;the TSP (P =3D Protocol), you talk to a service (i=
n this=20
case,&nbsp; a Time Stamping Service).</DIV>
<DIV>&nbsp;</DIV>
<DIV>You will get a response from one of the TSUs behind that service.</D=
IV>
<DIV>&nbsp;</DIV>
<DIV>If the request is sucessful, the TST is signed by a TSU.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Every TSU is managed by a TSA.</DIV>
<DIV>&nbsp;</DIV>
<DIV>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]">Alfredo Esposito=
</A>=20
  </DIV>
  <DIV=20
  style=3D"FONT-WEIGHT: normal; FONT-SIZE: 9pt; LINE-HEIGHT: normal; FONT=
-STYLE: normal; FONT-VARIANT: normal"><B>Date=20
  :</B> 2009-03-12, 17:49:08</DIV>
  <DIV=20
  style=3D"FONT-WEIGHT: normal; FONT-SIZE: 9pt; LINE-HEIGHT: normal; FONT=
-STYLE: normal; FONT-VARIANT: normal"><B>Sujet=20
  :</B> Re: draft-ietf-pkix-rfc3161bis-01.txt</DIV>
  <DIV><BR></DIV>
  <DIV></DIV>
  <DIV></DIV>
  <DIV>
  <DIV>Alfredo,<BR><BR>It may seem that I'm kidding around with words, bu=
t to me=20
  it is larger than<BR>that.<BR><BR>No your definition does not help conv=
ince me=20
  why I need three separate terms<BR>to describe one entity of a protocol=
,=20
  unless they are distinguished in the<BR>protocol bits on the wire.<BR><=
BR>If=20
  the protocol could be defined for a TSA, and the bits on the wire are=20
  the<BR>same today, except for the CertID, then why do I have to split t=
he=20
  entity<BR>into three separate terms. It's just confusing.<BR><BR>Where =
is the=20
  benefit?<BR><BR>/Stefan<BR><BR><BR><BR>On 3/12/09 5:27 PM, "Alfredo Esp=
osito"=20
  &lt;<A=20
  href=3D"mailto: [e-mail]">alfredo.esposito@infocert=
.it</A>&gt;=20
  wrote:<BR><BR>&gt; I love joking with the words in my own language, but=
 my=20
  English is not<BR>&gt; smart enough<BR>&gt; TSU is the subject of a X.5=
09=20
  public key certificate and the<BR>&gt; corresponding private key is use=
d to=20
  sign time-stamp-token compliant<BR>&gt; with IETF RFC 3161<BR>&gt; Is i=
t=20
  better?<BR>&gt; <BR>&gt; <BR>&gt; Stefan Santesson wrote:<BR>&gt;&gt;=20
  Alfred,<BR>&gt;&gt; <BR>&gt;&gt; <BR>&gt;&gt;&gt; The meaning of TSU se=
ems to=20
  me pretty clear: it is the entity signing<BR>&gt;&gt;&gt; the time stam=
p=20
  token.<BR>&gt;&gt;&gt; <BR>&gt;&gt; <BR>&gt;&gt; You see, already here =
you=20
  loose me.<BR>&gt;&gt; <BR>&gt;&gt; How can a "Unit" be an Entity? If so=
, how=20
  do you define entity?<BR>&gt;&gt; <BR>&gt;&gt; /Stefan<BR>&gt;&gt;=20
  <BR>&gt;&gt; <BR>&gt;&gt; <BR>&gt;&gt; <BR>&gt;&gt;=20
  <BR><BR><BR><BR></DIV></DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_09031218271969540460310_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 n2CHNghh003102 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Mar 2009 10:23:42 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2CHNguP003101; Thu, 12 Mar 2009 10:23:42 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from lxme02.infocamere.it (lxme02.infocamere.it [80.82.3.213]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2CHNeeM003095 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 12 Mar 2009 10:23:41 -0700 (MST) (envelope-from [e-mail])
Received: from lxm07.intra.infocamere.it (lxm07.intra.infocamere.it [1.5.72.7]) by lxme02.infocamere.it (8.13.6/8.13.6) with ESMTP id n2CHNcYs010537 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 12 Mar 2009 18:23:38 +0100
Received: from [1.71.4.82] ([1.71.4.82]) (authenticated bits=0) by lxm07.intra.infocamere.it (8.12.11/8.12.11) with ESMTP id n2CHNb15002977; Thu, 12 Mar 2009 18:23:37 +0100
Message-ID: <[e-mail]>
Date: Thu, 12 Mar 2009 18:23:37 +0100
From: Alfredo Esposito <[e-mail]>
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: Stefan Santesson <[e-mail]>
CC: [e-mail]
Subject: Re: draft-ietf-pkix-rfc3161bis-01.txt
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV 0.93.3/9101/Thu Mar 12 16:30:26 2009 on lxme02
X-Virus-Scanned: ClamAV 0.93/6996/Wed Apr 30 13:00:40 2008 on lxm07.intra.infocamere.it
X-Virus-Status: Clean
X-Brightmail-Tracker: AAAAAQAAAAI=
X-Brightmail-Tracker: AAAAAQAAAAI=
X-Whitelist: TRUE
X-Whitelist: TRUE
Sender: [e-mail]
Precedence: 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
Sure, for the mere description of the protocol we just need a 
"time-stamp" responder (may be the best term), unaware of the technical 
implementation and of any way the responder is organized.
Nevertheless, IMHO, distinguishing among the physical responder and the 
organization ("the authority") liable for the service was a plus.



Stefan Santesson wrote:
> Alfredo,
>
> It may seem that I'm kidding around with words, but to me it is larger than
> that.
>
> No your definition does not help convince me why I need three separate terms
> to describe one entity of a protocol, unless they are distinguished in the
> protocol bits on the wire.
>
> If the protocol could be defined for a TSA, and the bits on the wire are the
> same today, except for the CertID, then why do I have to split the entity
> into three separate terms. It's just confusing.
>
> Where is the benefit?
>
> /Stefan
>
>
>
> On 3/12/09 5:27 PM, "Alfredo Esposito" <[e-mail]> wrote:
>
>   
>> I love joking with the words in my own language, but my English is not
>> smart enough
>> TSU is the subject of a X.509 public key certificate and the
>> corresponding private key is used to sign time-stamp-token compliant
>> with IETF RFC 3161
>> Is it better?
>>
>>
>> Stefan Santesson wrote:
>>     
>>> Alfred,
>>>
>>>   
>>>       
>>>> The meaning of TSU seems to me pretty clear: it is the entity signing
>>>> the time stamp token.
>>>>     
>>>>         
>>> You see, already here you loose me.
>>>
>>> How can a "Unit" be an Entity? If so, how do you define entity?
>>>
>>> /Stefan
>>>
>>>
>>>
>>>
>>>   
>>>       
>
>
>
>   



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 n2CH5i88002043 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Mar 2009 10:05:44 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2CH5ios002042; Thu, 12 Mar 2009 10:05:44 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from s87.loopia.se (s87.loopia.se [194.9.95.112]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2CH5fmF002033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 12 Mar 2009 10:05:43 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 53381 invoked from network); 12 Mar 2009 16:49:15 -0000
Received: from s34.loopia.se (HELO s29.loopia.se) ([194.9.94.70]) (envelope-sender <[e-mail]>) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for <[e-mail]>; 12 Mar 2009 16:49:15 -0000
Received: (qmail 22246 invoked from network); 12 Mar 2009 16:49:09 -0000
Received: from 90-229-233-249-no153.tbcn.telia.com (HELO [192.168.0.17]) ([e-mail]@[90.229.233.249]) (envelope-sender <[e-mail]>) by s29.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <[e-mail]>; 12 Mar 2009 16:49:09 -0000
User-Agent: Microsoft-Entourage/12.15.0.081119
Date: Thu, 12 Mar 2009 17:49:08 +0100
Subject: Re: draft-ietf-pkix-rfc3161bis-01.txt
From: Stefan Santesson <[e-mail]>
To: Alfredo Esposito <[e-mail]>
CC: Peter Sylvester <[e-mail]>, <[e-mail]>
Message-ID: <[e-mail]>
Thread-Topic: draft-ietf-pkix-rfc3161bis-01.txt
Thread-Index: AcmjMnX9reM2BuqrAEGLW/QwM4TA6g==
In-Reply-To: <[e-mail]>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alfredo,

It may seem that I'm kidding around with words, but to me it is larger than
that.

No your definition does not help convince me why I need three separate terms
to describe one entity of a protocol, unless they are distinguished in the
protocol bits on the wire.

If the protocol could be defined for a TSA, and the bits on the wire are the
same today, except for the CertID, then why do I have to split the entity
into three separate terms. It's just confusing.

Where is the benefit?

/Stefan



On 3/12/09 5:27 PM, "Alfredo Esposito" <[e-mail]> wrote:

> I love joking with the words in my own language, but my English is not
> smart enough
> TSU is the subject of a X.509 public key certificate and the
> corresponding private key is used to sign time-stamp-token compliant
> with IETF RFC 3161
> Is it better?
> 
> 
> Stefan Santesson wrote:
>> Alfred,
>> 
>>   
>>> The meaning of TSU seems to me pretty clear: it is the entity signing
>>> the time stamp token.
>>>     
>> 
>> You see, already here you loose me.
>> 
>> How can a "Unit" be an Entity? If so, how do you define entity?
>> 
>> /Stefan
>> 
>> 
>> 
>> 
>>   




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 n2CGnFSk001022 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Mar 2009 09:49:15 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2CGnFli001021; Thu, 12 Mar 2009 09:49:15 -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.158] (dsl-63-249-108-169.static.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2CGnDa6001014 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Mar 2009 09:49:14 -0700 (MST) (envelope-from [e-mail])
Mime-Version: 1.0
Message-Id: <p06240860c5deebb4b2f6@[10.20.30.158]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Thu, 12 Mar 2009 09:49:12 -0700
To: Stefan Santesson <[e-mail]>, IETF-pkix <[e-mail]>
From: Paul Hoffman <[e-mail]>
Subject: Re: Call for agenda items
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 3:13 AM +0100 3/12/09, Stefan Santesson wrote:
>I lack information about 3 active WG documents:
> - New ASN.1

We have posted a new draft addressing the WGLC comments, but do not need to spend face-to-face time telling people that fact. We will send out a request for people to re-check the modules soon but, again, don't need to take up meeting time doing that.

--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 n2CGSa4J099092 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Mar 2009 09:28:36 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2CGSaWf099091; Thu, 12 Mar 2009 09:28:36 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from lxme02.infocamere.it (lxme02.infocamere.it [80.82.3.213]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2CGSNDR099060 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 12 Mar 2009 09:28:35 -0700 (MST) (envelope-from [e-mail])
Received: from lxm07.intra.infocamere.it (lxm07.intra.infocamere.it [1.5.72.7]) by lxme02.infocamere.it (8.13.6/8.13.6) with ESMTP id n2CGRweO003022 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 12 Mar 2009 17:27:58 +0100
Received: from [1.71.4.82] ([1.71.4.82]) (authenticated bits=0) by lxm07.intra.infocamere.it (8.12.11/8.12.11) with ESMTP id n2CGRqaF001913; Thu, 12 Mar 2009 17:27:57 +0100
Message-ID: <[e-mail]>
Date: Thu, 12 Mar 2009 17:27:53 +0100
From: Alfredo Esposito <[e-mail]>
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: Stefan Santesson <[e-mail]>
CC: Peter Sylvester <[e-mail]>, [e-mail]
Subject: Re: draft-ietf-pkix-rfc3161bis-01.txt
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV 0.93.3/9101/Thu Mar 12 16:30:26 2009 on lxme02
X-Virus-Scanned: ClamAV 0.93/6996/Wed Apr 30 13:00:40 2008 on lxm07.intra.infocamere.it
X-Virus-Status: Clean
X-Brightmail-Tracker: AAAAAQAAAAI=
X-Brightmail-Tracker: AAAAAQAAAAI=
X-Whitelist: TRUE
X-Whitelist: TRUE
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I love joking with the words in my own language, but my English is not 
smart enough
TSU is the subject of a X.509 public key certificate and the 
corresponding private key is used to sign time-stamp-token compliant 
with IETF RFC 3161
Is it better?


Stefan Santesson wrote:
> Alfred,
>
>   
>> The meaning of TSU seems to me pretty clear: it is the entity signing
>> the time stamp token.
>>     
>
> You see, already here you loose me.
>
> How can a "Unit" be an Entity? If so, how do you define entity?
>
> /Stefan
>
>
>
>
>   



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 n2CFxcMf096494 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Mar 2009 08:59:38 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2CFxcBR096492; Thu, 12 Mar 2009 08:59:38 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from s87.loopia.se (s87.loopia.se [194.9.95.112]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2CFxQc4096473 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 12 Mar 2009 08:59:37 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 25266 invoked from network); 12 Mar 2009 14:14:08 -0000
Received: from s34.loopia.se (HELO s60.loopia.se) ([194.9.94.70]) (envelope-sender <[e-mail]>) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for <[e-mail]>; 12 Mar 2009 14:14:08 -0000
Received: (qmail 48379 invoked from network); 12 Mar 2009 14:14:03 -0000
Received: from 90-229-233-249-no153.tbcn.telia.com (HELO [192.168.0.17]) ([e-mail]@[90.229.233.249]) (envelope-sender <[e-mail]>) by s60.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <[e-mail]>; 12 Mar 2009 14:14:03 -0000
User-Agent: Microsoft-Entourage/12.15.0.081119
Date: Thu, 12 Mar 2009 15:14:02 +0100
Subject: Re: draft-ietf-pkix-rfc3161bis-01.txt
From: Stefan Santesson <[e-mail]>
To: Alfredo Esposito <[e-mail]>
CC: Peter Sylvester <[e-mail]>, <[e-mail]>
Message-ID: <[e-mail]>
Thread-Topic: draft-ietf-pkix-rfc3161bis-01.txt
Thread-Index: AcmjHMsuyC/IFMxR/0Ok6zBm3kwCEg==
In-Reply-To: <[e-mail]>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alfred,

> The meaning of TSU seems to me pretty clear: it is the entity signing
> the time stamp token.

You see, already here you loose me.

How can a "Unit" be an Entity? If so, how do you define entity?

/Stefan





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 n2CEOAYn089275 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Mar 2009 07:24:11 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2CEOAVM089274; Thu, 12 Mar 2009 07:24:10 -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 n2CENwi3089258 for <[e-mail]>; Thu, 12 Mar 2009 07:24:10 -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 07A8757; Thu, 12 Mar 2009 15:23:57 +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 2009031215235617:387901 ; Thu, 12 Mar 2009 15:23:56 +0100 
Message-ID: <[e-mail]>
Date: Thu, 12 Mar 2009 15:23:56 +0100
From: Peter Sylvester <[e-mail]>
User-Agent: Thunderbird 1.5.0.9 (X11/20061206)
MIME-Version: 1.0
To: Alfredo Esposito <[e-mail]>
Cc: Stefan Santesson <[e-mail]>, [e-mail]
Subject: Re: draft-ietf-pkix-rfc3161bis-01.txt
References: <[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 03/12/2009 03:23:56 PM, Serialize by Router on vinea/ON-X(Release 5.0.11  |July 24, 2002) at 03/12/2009 03:23:56 PM, Serialize complete at 03/12/2009 03:23:56 PM
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=ISO-8859-1; 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>

Alfredo Esposito wrote:
> The meaning of TSU seems to me pretty clear: it is the entity signing 
> the time stamp token. For example, my company runs several Time stamp 
> services, each based on more than one different signing unit, for 
> performance and availability. An organization (i.e. an Authorithy) can 
> offer different time stamp services with different policies, so that TST 
> are signed with different keys. At the same time, defining different 
> roles does not forbid to collapse all in one. I don't see the problem.

A small paragraph allowing a reader to better distinguish the technical
term from some organisational usage may be sufficient. This is similar
as for the definition of an RA and CA. When used as technical terms,
a CA is simply a signing device, and a TSA is simply a 'signing device that
adds some time.'


... some text removed

> 
> Stefan Santesson wrote:

... some text removed

>> A more thorough discussion is needed here. My current view is that we
>> probably should revert completely back to the text of RFC 3161 and 
>> then just
>> do a minimum of technically well motivated changes. At this time I oppose
>> terminology alignment to RFC 3628.


I fully agree with this.


The text should be just have an update for the ESSSigningCertV2.

I mentioned also some unclear text concerning the socket protocol.


>>
>> /Stefan
>>
>>



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 n2CD4jbw083726 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Mar 2009 06:04:45 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2CD4jgK083725; Thu, 12 Mar 2009 06:04:45 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from lxme02.infocamere.it (lxme02.infocamere.it [80.82.3.213]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2CD4WFw083710 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 12 Mar 2009 06:04:44 -0700 (MST) (envelope-from [e-mail])
Received: from lxm07.intra.infocamere.it (lxm07.intra.infocamere.it [1.5.72.7]) by lxme02.infocamere.it (8.13.6/8.13.6) with ESMTP id n2CD3j70015078 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 12 Mar 2009 14:03:46 +0100
Received: from [1.71.4.82] ([1.71.4.82]) (authenticated bits=0) by lxm07.intra.infocamere.it (8.12.11/8.12.11) with ESMTP id n2CD3iJm006742; Thu, 12 Mar 2009 14:03:44 +0100
Message-ID: <[e-mail]>
Date: Thu, 12 Mar 2009 14:03:43 +0100
From: Alfredo Esposito <[e-mail]>
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: Stefan Santesson <[e-mail]>
CC: Peter Sylvester <[e-mail]>, [e-mail]
Subject: Re: draft-ietf-pkix-rfc3161bis-01.txt
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV 0.93.3/9100/Thu Mar 12 10:07:56 2009 on lxme02
X-Virus-Scanned: ClamAV 0.93/6996/Wed Apr 30 13:00:40 2008 on lxm07.intra.infocamere.it
X-Virus-Status: Clean
X-Brightmail-Tracker: AAAAAQAAAAI=
X-Brightmail-Tracker: AAAAAQAAAAI=
X-Whitelist: TRUE
X-Whitelist: TRUE
Sender: [e-mail]
Precedence: 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 meaning of TSU seems to me pretty clear: it is the entity signing 
the time stamp token. For example, my company runs several Time stamp 
services, each based on more than one different signing unit, for 
performance and availability. An organization (i.e. an Authorithy) can 
offer different time stamp services with different policies, so that TST 
are signed with different keys. At the same time, defining different 
roles does not forbid to collapse all in one. I don't see the problem.
Some suggestions for the draft
I would remove the first part of section 3.3 (identification of the TSU) 
related to the TSU name since it seems outside the scope of the document 
(named Time stamp PROTOCOL) and more suitable for a profile document 
(strictly speaking also the prescription of the EKU would be out of 
scope, but it was already there in the RFC 3161).
--Introduction
-replace
The TSA can  also be used to indicate the time of submission when a 
deadline is critical, or to indicate the time of transaction for entries 
in a  log.  An exhaustive list of possible uses of a TSU is beyond the 
scope of this document.
-with
A time-stamp can also be used to indicate the time of submission when a 
deadline is critical, or to indicate the time of transaction for entries 
in a  log.  An exhaustive list of possible uses of a time-stamps scope 
of this document.
--Definitions
-replace
time-stamping authority: authority which issues time-stamp tokens.
-with
time-stamping authority: authority responsible of issuing time-stamp tokens.

Stefan Santesson wrote:
> I would like to line up and express my concerns regarding the direction of
> this document.
>
> In principle I'm worried about the fundamental changes of concept and
> terminology made in the update of an existing IETF standard.
>
> While 3161 used TSA (Time Stamping Authority) as a collective term, 3161bis
> uses three different terms:
>
> TSA - TS Authority
> TSU - TS Unit
> TSS - TS Service
>
> This is extremely confusing to me and appears unnecessary distinctions for
> the sake of defining a protocol.
>
> The change is motivated by RFC 3628 which has been upgraded as Normative.
> But RFC 3628 is an Informational policy document and should never be
> normative over the protocol standard.
>
> I see several mixes of these new terms that appears confusing to me. For
> example TSU is mentioned as being responsible for things where I would
> suspect that any responsibility must reside with a TSA.
>
> In section 4.3 the body text talk about TSU Messages, but the protocol
> definitions define TSA Messages.
>
> And it goes on like that throughout the document.
>
> A more thorough discussion is needed here. My current view is that we
> probably should revert completely back to the text of RFC 3161 and then just
> do a minimum of technically well motivated changes. At this time I oppose
> terminology alignment to RFC 3628.
>
> /Stefan
>
>
>
> On 3/4/09 6:22 PM, "Peter Sylvester" <[e-mail]> wrote:
>
>   
>> I had the impression that thegoal of that texwt was an update
>> concerning hash algorithms.
>>
>>
>> One could expecte it would only contain an update to the ESScertid using
>> ESSCertidV2 etc.
>>
>> The actual texts corresponds roughly to an expired draft some
>> years ago.
>>
>>         - the document has been aligned with RFC 3628 to make the
>>           difference between a time-stamping unit (TSU) and a TSA.
>>
>> Thus, the text is not a small update of 3161 but introduces several
>> new items, some of them seems questionable to me. Some problems
>> which had been mentioned with RFC 3161 in the past, have not been
>> addressed.
>>
>> In 3161, a TSA is merely a technical service similar to what is
>> said in 3161bis for a TSU. A TSA in 3161bis does not really
>> have a defined technical role.
>>
>> On the other hand the field tsa in a response refers to a TSA,
>> and to a certficate that validates it. But a TSA does no longer
>> have a certificate, only TSUs.
>>
>> As a consequence, the following paragraph cannot mention TSA
>> but at best a TSU.
>> Besides that it should also mentiion ESSCertIDv2.)
>>
>>     The purpose of the tsa field is to give a hint in identifying the
>>     name of the TSA.  If present, it MUST correspond to one of the
>>     subject names included in the certificate that is to be used to
>>     verify the token.  However, the actual identification of the entity
>>     that signed the response will always occur through the use of the
>>     certificate identifier (ESSCertID Attribute) inside a
>>     SigningCertificate attribute which is part of the signerInfo
>>     (See Section 5 of [ESS]).
>>
>>
>> Chapter 3.3 does not use the 2119 terminology in the first phrase but
>> rather the ISO terminoilogy. 3.3 is not relevant for the function of
>> a time stamp service. (Although it is likely that TSA actually
>> have filled all the REQUIRED 'shall) attributes in the DN)
>>
>> The following text is extremely fuzzy:
>>
>>     The name of the issuing TSU shall contain an appropriate subset of
>>     the following attributes (defined in ISO 9594-6 [ISO9594-6] and
>>     ITU-T Recommendation X.520 [X.520]):
>>
>>         - countryName;
>>         - stateOrProvinceName;
>>         - organizationName;
>>         - commonName.
>>
>> What means "appropriate subset". The text does not exclude
>> other attributs. So in fact, it says: The TSU MUST have a subjectDN?
>>
>> It is not defined what name identifies a TSA? for example, everything except
>> the common name?
>>
>> 4.3 :
>>
>> As it had been mentioned before the socket protocol as it is defined
>> has some problems: Since it was taken texto from CMP, there are some features
>> that are may require some complexity in clients:
>> Only 00, 05, and 06 seem useful to me. If a TSA/U is not able to sign
>> a response within a few milliseconds with a TCP connection kept open,
>> I wouldn't call this a service.
>> For HTTP, a server cannot return a poll indication as a comparison.
>>
>> If a client does not send a pollReq, what will happen with a pending
>> response?
>>
>> The protocol does not specify who terminates the connection. Is it the
>> server that closes after one exchange?
>>
>> If multiple requests and responses can be exchanged over the same connection,
>> what is the dialogue model? request/response, pipelining, etc?
>>
>> What is a TSU message? I think it should be TSP message. Old text was
>> TSA, which was also somewhat wrong.
>>
>> Security section point 1 seems not quite correct:
>>
>> Instead of :
>> it SHALL be set either to unspecified (0), affiliationChanged (3),
>>        superseded (4) or cessationOfOperation (5).  In that case,
>>
>> it should say
>>
>> In the case when the reasonCode is set to either
>>        affiliationChanged (3),
>>        superseded (4) or cessationOfOperation (5)
>>
>> Unspecified means that ther can be a key compromise IMO?
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>     
>
>
>
>   



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 n2C2E1fK051461 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Mar 2009 19:14:01 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2C2E1a5051460; Wed, 11 Mar 2009 19:14:01 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from s87.loopia.se (s87.loopia.se [194.9.95.112]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2C2DmLf051450 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 11 Mar 2009 19:13:59 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 41020 invoked from network); 12 Mar 2009 02:13:57 -0000
Received: from s34.loopia.se (HELO s128.loopia.se) ([194.9.94.70]) (envelope-sender <[e-mail]>) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for <[e-mail]>; 12 Mar 2009 02:13:57 -0000
Received: (qmail 77539 invoked from network); 12 Mar 2009 02:13:46 -0000
Received: from 90-229-233-249-no153.tbcn.telia.com (HELO [192.168.0.17]) ([e-mail]@[90.229.233.249]) (envelope-sender <[e-mail]>) by s128.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <[e-mail]>; 12 Mar 2009 02:13:46 -0000
User-Agent: Microsoft-Entourage/12.15.0.081119
Date: Thu, 12 Mar 2009 03:13:45 +0100
Subject: Re: Call for agenda items
From: Stefan Santesson <[e-mail]>
To: IETF-pkix <[e-mail]>
Message-ID: <[e-mail]>
Thread-Topic: Call for agenda items
Thread-Index: Acmb80fBwJEE/S9xVk+d4pIiOftWRwGxOQXj
In-Reply-To: <[e-mail]>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3319672426_2560708"
Sender: [e-mail]
Precedence: 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 message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3319672426_2560708
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit

The preliminary agenda is posted.

http://www.ietf.org/proceedings/09mar/agenda/pkix.txt

I lack information about 3 active WG documents:
 - 3161bis (Time stamping),
 - New ASN.1
 - SHA2 for DSA and ECDSA

Please let me know if anyone is presenting anything bout these document
status.
Also, we are having the Monday Morning session. In order for me to be able
to prepare for the meeting, I would like the slides of all presenters before
1700 (5 pm) on Sunday March 22

Thank you.

Stefan Santesson
AAA-sec.com






On 3/3/09 12:29 PM, "Stefan Santesson" <[e-mail]> wrote:

> IETF in San Francisco is coming up.
> 
> PKIX has a 2.5 hour session directly on the Monday morning March 23 at 0900
> 
> Please let me know if you have anything you whish to present at the meeting.
> At least one representative of each active WG document MUST inform me if you
> need a time slot for that document or not.
>  
> I would like to have your request for timeslot by Wednesday March 11.
> After that we can always do late adjustments but I appreciate to have your
> request as early as possible.
> 
> Thank you.
> 
> /Stefan


--B_3319672426_2560708
Content-type: text/html;
	charset="US-ASCII"
Content-transfer-encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Re: Call for agenda items</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt=
'>The preliminary agenda is posted.<BR>
<BR>
<a href=3D"http://www.ietf.org/proceedings/09mar/agenda/pkix.txt">http://www.=
ietf.org/proceedings/09mar/agenda/pkix.txt</a><BR>
<BR>
I lack information about 3 active WG documents: <BR>
&nbsp;- 3161bis (Time stamping), <BR>
&nbsp;- New ASN.1<BR>
&nbsp;- SHA2 for DSA and ECDSA<BR>
<BR>
Please let me know if anyone is presenting anything bout these document sta=
tus.<BR>
Also, we are having the Monday Morning session. In order for me to be able =
to prepare for the meeting, I would like the slides of all presenters before=
 1700 (5 pm) on Sunday March 22 <BR>
<BR>
Thank you.<BR>
</SPAN></FONT><FONT COLOR=3D"#333333"><FONT SIZE=3D"2"><FONT FACE=3D"Tahoma, Verd=
ana, Helvetica, Arial"><SPAN STYLE=3D'font-size:10pt'><BR>
</SPAN></FONT></FONT></FONT><FONT SIZE=3D"2"><SPAN STYLE=3D'font-size:10pt'><FO=
NT COLOR=3D"#008080"><FONT FACE=3D"Cambria"><B>Stefan Santesson<BR>
</B></FONT></FONT><FONT FACE=3D"Cambria">AAA-sec.com<BR>
<BR>
<BR>
<BR>
</FONT></SPAN></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN =
STYLE=3D'font-size:11pt'><BR>
<BR>
<BR>
On 3/3/09 12:29 PM, &quot;Stefan Santesson&quot; &lt;<a href=3D"stefans@exmsf=
t.com">[e-mail]</a>&gt; wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><=
SPAN STYLE=3D'font-size:11pt'>IETF in San Francisco is coming up.<BR>
<BR>
PKIX has a 2.5 hour session directly on the Monday morning March 23 at 0900=
<BR>
<BR>
Please let me know if you have anything you whish to present at the meeting=
.<BR>
<B><U>At least one representative of each active WG document MUST inform me=
 if you need a time slot for that document or not.<BR>
</U></B> <BR>
I would like to have your request for timeslot by Wednesday March 11.<BR>
After that we can always do late adjustments but I appreciate to have your =
request as early as possible.<BR>
<BR>
Thank you.<BR>
<BR>
/Stefan<BR>
</SPAN></FONT></BLOCKQUOTE>
</BODY>
</HTML>


--B_3319672426_2560708--




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 n2BKuRGu038249 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Mar 2009 13:56:27 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2BKuRI9038248; Wed, 11 Mar 2009 13:56:27 -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 n2BKuQRx038242 for <[e-mail]>; Wed, 11 Mar 2009 13:56:26 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 8330 invoked from network); 11 Mar 2009 20:55:52 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 11 Mar 2009 20:55:52 -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: I-D Action:draft-ietf-pkix-tamp-01.txt 
Date: Wed, 11 Mar 2009 16:56:24 -0400
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-tamp-01.txt 
Thread-Index: AcmdugHbEEN+Q+v4TXiq2c4e4w6IhQExZ+MAAAMEhUA=
References: <[e-mail]> <[e-mail]> <[e-mail]>
From: "Santosh Chokhani" <[e-mail]>
To: "Carl Wallace" <[e-mail]>, "max pritikin" <[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>

Would it be more accurate to say that signer of TAMP messages must be a
management TA or the signer's certification path must terminate at a
management TA.=20

> -----Original Message-----
> From: [e-mail]=20
> [mailto:[e-mail]] On Behalf Of Carl Wallace
> Sent: Wednesday, March 11, 2009 3:48 PM
> To: max pritikin; [e-mail]
> Subject: RE: I-D Action:draft-ietf-pkix-tamp-01.txt=20
>=20
>=20
> <snip>
> > The latest [TAF] document appear to move away from specifically
> categorizing Apex, Management and Identity trust=20
> > anchors. I agree with this change. The [TAMP] draft still indicates
> these three types though and I no longer see how=20
> > they are distinguished. I do see that [TAMP, Section 1.3.2]=20
> indicates
> that:
> >   o  The trust anchor store MUST support the secure storage=20
> of exactly
> >     one apex trust anchor.  The trust anchor store SHOULD=20
> support the
> >     secure storage of at least one additional trust anchor.=20
> > but not how it is identified as the Apex. Or as a management trust
> anchor, or identity trust anchor. Is it expected that > this=20
> information would be encoded into the TAF extensions=20
> field[s]? For example TAMP would specify a specific extension=20
> > with these types indicated?
>=20
> The terms describe the function of a trust anchor, not=20
> necessarily its composition.
>=20
> A trust anchor is identified as the apex by placement,=20
> similar to a certificate that is recognized as a trust anchor=20
> by placing it in a trust anchor store.  The presence of a=20
> Apex trust anchor info certificate extension is a clue, but=20
> placement is what makes a trust anchor an apex.  This will be=20
> clarified in the next draft.
>=20
> An identity TA must be able to validate certification paths,=20
> so it must have name.  In an environment using the CCC spec=20
> for authorization, a management trust anchor would contain a=20
> CCC extension.  Other authorization mechanisms may have=20
> different hallmarks.
>=20
> <snip>
>=20
> > I like the idea of a TAF which can store information specific to
> particular applications, various management protocols=20
> > such as CMS, and other things moving forward. TAMP apparently then
> specifies specific authorizations and their meanings=20
> > but this doesn't limit or impact other uses? And=20
> importantly this type
> of construct results in a TAF which may be either=20
> > Apex, Management, or Identity or any combination thereof=20
> including new
> types in the future?
>=20
> Right.  TAs can be any combination of TA types (except that=20
> an apex is by definition a management TA) and could address=20
> various management protocols (like CMS) are defined.
>=20
> > This line of thought leads to some reflection on the [TAMP]=20
> discussion
> illustrated by Figure 4-1 might be even further >=20
> > refined. I appreciate the update from "Crypto Module" to=20
> "Trust Anchor
> Store" -- or maybe even a combination of the two=20
> > of them (this echoes my comment above about how the 802.1AR module
> sounds like a combination of both of these elements).=20
> > Perhaps my confusion is that in my mind a Trust Anchor Manager is
> communicating via TAMP with a TAMP service which is=20
> > then accessing the Trust Anchor Store. A picture is worth a thousand
> words:
>=20
>=20
> (my apologies if mail messes this up)
>       +---------+      +----------+
>       |         |      |          |
>       |         |      |          |
>       |         |      |          |
>       |         | TAMP |          |
>       | Trust   |<---->| TAMP     |
>       | Anchor  |      | Process  | OS & Application
>       | Manager |      |          | Service Interface
>       |         |      |          |      +----------+
>       |         |      |          |<---->|TAFs in a |
>       |         |      |          |      |Crypto    |
>       |         |      |          |      |Module    |
>       |         |      |          |      |& Store   |
>       +---------+      +----------+      +----------+
>=20
>=20
> > I haven't seen a discussion that the "OS & Application Service
> Interface" as being in scope. Drawing the diagram like >=20
> > this clarifies my impression that the TAF might be used by other
> applications and that those applications might benefit=20
> > from the TAF standardization. Given the recent changes to [TAF] I
> suspect things are moving in this direction?
>=20
> The diagram above is an accurate representation.  You are=20
> correct that the specs do not address the interface between=20
> the TA store and the applications.  Not shown in the diagram=20
> is how the TA is actually used (i.e., what an application=20
> does with a trust anchor once it retrieves it from the=20
> store).  There will be another short specification submitted=20
> soon that describes how to use TA-based constraints during=20
> certification path validation.
>=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 n2BJm2ZY034848 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Mar 2009 12:48:02 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2BJm2vb034847; Wed, 11 Mar 2009 12:48:02 -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 n2BJlpff034833 for <[e-mail]>; Wed, 11 Mar 2009 12:48:02 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 7010 invoked from network); 11 Mar 2009 19:47:17 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 11 Mar 2009 19:47:17 -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: I-D Action:draft-ietf-pkix-tamp-01.txt 
Date: Wed, 11 Mar 2009 15:47:50 -0400
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-tamp-01.txt 
Thread-Index: AcmdugHbEEN+Q+v4TXiq2c4e4w6IhQExZ+MA
References: <[e-mail]> <[e-mail]>
From: "Carl Wallace" <[e-mail]>
To: "max pritikin" <[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>

<snip>
> The latest [TAF] document appear to move away from specifically
categorizing Apex, Management and Identity trust=20
> anchors. I agree with this change. The [TAMP] draft still indicates
these three types though and I no longer see how=20
> they are distinguished. I do see that [TAMP, Section 1.3.2] indicates
that:
>   o  The trust anchor store MUST support the secure storage of exactly
>     one apex trust anchor.  The trust anchor store SHOULD support the
>     secure storage of at least one additional trust anchor.=20
> but not how it is identified as the Apex. Or as a management trust
anchor, or identity trust anchor. Is it expected that > this information
would be encoded into the TAF extensions field[s]? For example TAMP
would specify a specific extension > with these types indicated?

The terms describe the function of a trust anchor, not necessarily its
composition.

A trust anchor is identified as the apex by placement, similar to a
certificate that is recognized as a trust anchor by placing it in a
trust anchor store.  The presence of a Apex trust anchor info
certificate extension is a clue, but placement is what makes a trust
anchor an apex.  This will be clarified in the next draft.

An identity TA must be able to validate certification paths, so it must
have name.  In an environment using the CCC spec for authorization, a
management trust anchor would contain a CCC extension.  Other
authorization mechanisms may have different hallmarks.

<snip>

> I like the idea of a TAF which can store information specific to
particular applications, various management protocols=20
> such as CMS, and other things moving forward. TAMP apparently then
specifies specific authorizations and their meanings=20
> but this doesn't limit or impact other uses? And importantly this type
of construct results in a TAF which may be either=20
> Apex, Management, or Identity or any combination thereof including new
types in the future?

Right.  TAs can be any combination of TA types (except that an apex is
by definition a management TA) and could address various management
protocols (like CMS) are defined.

> This line of thought leads to some reflection on the [TAMP] discussion
illustrated by Figure 4-1 might be even further >=20
> refined. I appreciate the update from "Crypto Module" to "Trust Anchor
Store" -- or maybe even a combination of the two=20
> of them (this echoes my comment above about how the 802.1AR module
sounds like a combination of both of these elements).=20
> Perhaps my confusion is that in my mind a Trust Anchor Manager is
communicating via TAMP with a TAMP service which is=20
> then accessing the Trust Anchor Store. A picture is worth a thousand
words:


(my apologies if mail messes this up)
      +---------+      +----------+
      |         |      |          |
      |         |      |          |
      |         |      |          |
      |         | TAMP |          |
      | Trust   |<---->| TAMP     |
      | Anchor  |      | Process  | OS & Application
      | Manager |      |          | Service Interface
      |         |      |          |      +----------+
      |         |      |          |<---->|TAFs in a |
      |         |      |          |      |Crypto    |
      |         |      |          |      |Module    |
      |         |      |          |      |& Store   |
      +---------+      +----------+      +----------+


> I haven't seen a discussion that the "OS & Application Service
Interface" as being in scope. Drawing the diagram like >=20
> this clarifies my impression that the TAF might be used by other
applications and that those applications might benefit=20
> from the TAF standardization. Given the recent changes to [TAF] I
suspect things are moving in this direction?

The diagram above is an accurate representation.  You are correct that
the specs do not address the interface between the TA store and the
applications.  Not shown in the diagram is how the TA is actually used
(i.e., what an application does with a trust anchor once it retrieves it
from the store).  There will be another short specification submitted
soon that describes how to use TA-based constraints during certification
path validation.



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 n2BJcGka034365 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Mar 2009 12:38:16 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2BJcDhw034363; Wed, 11 Mar 2009 12:38:13 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mummy.ncsc.mil (mummy.ncsc.mil [144.51.88.129]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2BJcCQQ034356 for <[e-mail]>; Wed, 11 Mar 2009 12:38:12 -0700 (MST) (envelope-from [e-mail])
Received: from smtp.ncsc.mil (jazzhorn.ncsc.mil [144.51.5.9]) by mummy.ncsc.mil (8.12.10/8.12.10) with ESMTP id n2BJcBFt021847 for <[e-mail]>; Wed, 11 Mar 2009 19:38:12 GMT
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9A280.E9BFD97D"
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: Suite B Certificate & CRL Profile
Date: Wed, 11 Mar 2009 15:38:11 -0400
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Suite B Certificate & CRL Profile
Thread-Index: AcmigOnXYq6+PwquRwG6A7Vp0AOajg==
From: "Zieglar, Lydia L." <[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>

This is a multi-part message in MIME format.

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

We have recently submitted the next revision of the National Security
Agency's Suite B Certificate and CRL Profile to the IETF as an
Internet-Draft (individual submission).
=20
We encourage you to review the document and send comments to Lydia
Zieglar at [e-mail]
=20
You may find the document at:
=20
http://www.ietf.org/internet-drafts/draft-solinas-suiteb-cert-profile-01
.txt
=20
Thanks,
Lydia Zieglar
=20
Lydia Zieglar
301-688-1028
[e-mail]
=20

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.3492" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D464003319-11032009>We =
have recently=20
submitted the next revision of the National Security Agency's Suite B=20
Certificate and CRL Profile to the IETF as an Internet-Draft (individual =

submission).</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D464003319-11032009></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D464003319-11032009>We =
encourage you to=20
review the document and send comments to Lydia Zieglar at <A=20
href=3D"mailto:[e-mail]">[e-mail]</A></SPAN><=
/FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D464003319-11032009></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D464003319-11032009>You =
may find the=20
document at:</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D464003319-11032009></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><A=20
href=3D"http://www.ietf.org/internet-drafts/draft-solinas-suiteb-cert-pro=
file-01.txt">http://www.ietf.org/internet-drafts/draft-solinas-suiteb-cer=
t-profile-01.txt</A></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><SPAN class=3D464003319-11032009><FONT face=3DArial=20
size=3D2>Thanks,</FONT></SPAN></DIV>
<DIV><SPAN class=3D464003319-11032009><FONT face=3DArial size=3D2>Lydia=20
Zieglar</FONT></SPAN></DIV>
<DIV>&nbsp;</DIV>
<DIV align=3Dleft><FONT face=3DArial size=3D2>Lydia Zieglar</FONT></DIV>
<DIV align=3Dleft><FONT face=3DArial size=3D2>301-688-1028</FONT></DIV>
<DIV align=3Dleft><FONT face=3DArial =
size=3D2>[e-mail]</FONT></DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------_=_NextPart_001_01C9A280.E9BFD97D--



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 n2BJ8Ria032564 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Mar 2009 12:08:27 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2BJ8RYi032563; Wed, 11 Mar 2009 12:08:27 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from s87.loopia.se (s87.loopia.se [194.9.95.112]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2BJ8DGP032540 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 11 Mar 2009 12:08:24 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 58473 invoked from network); 11 Mar 2009 19:08:19 -0000
Received: from s34.loopia.se (HELO s42.loopia.se) ([194.9.94.70]) (envelope-sender <[e-mail]>) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for <[e-mail]>; 11 Mar 2009 19:08:19 -0000
Received: (qmail 41964 invoked from network); 11 Mar 2009 19:08:12 -0000
Received: from 90-229-233-249-no153.tbcn.telia.com (HELO [192.168.0.17]) ([e-mail]@[90.229.233.249]) (envelope-sender <[e-mail]>) by s42.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <[e-mail]>; 11 Mar 2009 19:08:12 -0000
User-Agent: Microsoft-Entourage/12.15.0.081119
Date: Wed, 11 Mar 2009 20:08:09 +0100
Subject: Re: I-D Action:draft-ietf-pkix-ta-format-01.txt
From: Stefan Santesson <[e-mail]>
To: Santosh Chokhani <[e-mail]>, ietf-pkix <[e-mail]>
Message-ID: <[e-mail]>
Thread-Topic: I-D Action:draft-ietf-pkix-ta-format-01.txt
Thread-Index: AcmeoByemoDoNLVHQcKDrDvG2F2HSgA41HygAL5SKao=
In-Reply-To: <[e-mail]>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On the name issue I don't think names need to be mandatory.

If we for a second set aside what is right and pure and standards compliant
and stick to what is needed from a pure cryptographic and security
viewpoint, then there is no need for exact name matching in X.509 path
validation.

Long before UTF-8, name mismatch of Issuer/subject names in path processing
was a real problem. Some for example used T.61 Teletex to tag a string
carrying Latin-1 characters.

What many implementers did, including Microsoft, in order to be "liberal in
what you accept" was to ignore name mismatch as long as keys of the path
matched (could be used to validate certificates in the path). There was no
security problem with it and it worked a lot better.

So basically, I'm also fine with an optional DN.

/Stefan


On 3/8/09 1:24 AM, "Santosh Chokhani" <[e-mail]> wrote:

> 
> If making name optional meets the requirements of multiple environment,
> then it is a better standard than making it mandatory.
> 
> As to memory challenged, I encourage you to speak with some real
> implementers as they move their hardware tokens from 1024 bits to 2048
> bits RSA.  They do need bigger and costlier cards.  So, memory in all
> form factors is not free.
> 
>> -----Original Message-----
>> From: [e-mail]
>> [mailto:[e-mail]] On Behalf Of Eric Norman
>> Sent: Friday, March 06, 2009 3:59 PM
>> To: ietf-pkix
>> Subject: Re: I-D Action:draft-ietf-pkix-ta-format-01.txt
>> 
>> 
>> 
>> On Mar 6, 2009, at 2:17 PM, Santosh Chokhani wrote:
>> 
>>> 
>>> There are environments where the device may be space
>> challenged and/or
>>> the communication environment may be bandwidth challenged.
>>> 
>>> Thus, having only the required information in trust anchors
>> and TAMP 
>>> will be helpful.
>> 
>> Really?  How many bytes can be stored on a ESB memory stick nowadays?
>> How many bits can be stored in one square millimeter
>> nowadays?  How much time does it take to transfer a few
>> thousand bytes with USB or Bluetooth nowadays?  Are you
>> seriously suggesting that we need to design for folks whose
>> environment includes carrier pigeons or tin cans and string
>> as their communication mechanism?
>> 
>> TAMP may indeed be useful, but not in the area of saving resources.
>> Where it can be useful is to make it clearer which
>> information is necessary and which information can be ignored
>> for something to be a trust anchor and under what circumstances.
>> 
>> 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 n2BCuX2m008119 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Mar 2009 05:56:33 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2BCuX3f008118; Wed, 11 Mar 2009 05:56:33 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from s87.loopia.se (s87.loopia.se [194.9.95.112]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2BCuKIq008102 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 11 Mar 2009 05:56:32 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 64404 invoked from network); 11 Mar 2009 12:56:24 -0000
Received: from s34.loopia.se (HELO s19.loopia.se) ([194.9.94.70]) (envelope-sender <[e-mail]>) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for <[e-mail]>; 11 Mar 2009 12:56:24 -0000
Received: (qmail 26626 invoked from network); 11 Mar 2009 12:56:19 -0000
Received: from 90-229-233-249-no153.tbcn.telia.com (HELO [192.168.0.17]) ([e-mail]@[90.229.233.249]) (envelope-sender <[e-mail]>) by s19.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <[e-mail]>; 11 Mar 2009 12:56:19 -0000
User-Agent: Microsoft-Entourage/12.15.0.081119
Date: Wed, 11 Mar 2009 13:56:14 +0100
Subject: Re: Call for agenda items & PRQP
From: Stefan Santesson <[e-mail]>
To: Massimiliano Pala <[e-mail]>, Stephen Kent <[e-mail]>, pkix <[e-mail]>
Message-ID: <[e-mail]>
Thread-Topic: Call for agenda items & PRQP
Thread-Index: AcmiSMJs+qUBggAD8kCICLmIM6BuIQ==
In-Reply-To: <[e-mail]>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Max,

What you say is very interesting. First of all sort out the IANA issue.
Secondly we should discuss a possible upgrade of this document to standards
track based on the deployment.

You have your time slot.

/Stefan


On 3/5/09 12:31 PM, "Massimiliano Pala" <[e-mail]>
wrote:

> Ciao Stefan, Steve, and pkix-wg,
> 
> I would need 10 mins for reporting on the activities about PRQP - we have been
> working both with the TERENA (TACAR) and Federal Bridge folks and they are
> going
> to deploy PRQP (at least as experimental). Some interest in the PRQP has also
> been expressed by some commercial vendors... so I think that the WG should be
> informed of these activities.
> 
> Also, from the collaboration with the DHC WG, we have changed the draft and it
> seems that we need IANA to assign identifiers for DHCP (both v4 and v6).
> 
> One concern that I have is that IANA would not be so keen in assigning DHCP
> service identifiers for an experimental-track protocol, but the deployment
> of PRQP is actually happening and I would like to have at least those
> identifiers
> standardized before this actually happens. I am not sure about what we shall
> do
> now. The PRQP will be included in the next release of OpenCA as well,
> therefore
> there will soon be a quite large installation base (besides the aforementioned
> communities).
> 
> Shall we move the status from experimental to standard track ? Is it too early
> ?
> I see that within the WG there is not much activity about PRQP, but in the
> real
> PKI world and Computing Grid communities the situation is different.
> 
> I would like to know the opinion of the chair(s) and the people in the WG...
> 
> Ciao,
> Max
> 
> 
> Stefan Santesson wrote:
>> IETF in San Francisco is coming up.
>> 
>> PKIX has a 2.5 hour session directly on the Monday morning March 23 at 0900
>> 
>> Please let me know if you have anything you whish to present at the meeting.
>> *_At least one representative of each active WG document MUST inform me
>> if you need a time slot for that document or not.
>> _*
>> I would like to have your request for timeslot by Wednesday March 11.
>> After that we can always do late adjustments but I appreciate to have
>> your request as early as possible.




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 n2B9O90n089266 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Mar 2009 02:24:09 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2B9O9NU089265; Wed, 11 Mar 2009 02:24:09 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from s87.loopia.se (s87.loopia.se [194.9.95.112]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2B9NuK5089239 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 11 Mar 2009 02:24:07 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 36157 invoked from network); 11 Mar 2009 09:23:57 -0000
Received: from s34.loopia.se (HELO s57.loopia.se) ([194.9.94.70]) (envelope-sender <[e-mail]>) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for <[e-mail]>; 11 Mar 2009 09:23:57 -0000
Received: (qmail 15276 invoked from network); 11 Mar 2009 09:23:54 -0000
Received: from 90-229-233-249-no153.tbcn.telia.com (HELO [192.168.0.17]) ([e-mail]@[90.229.233.249]) (envelope-sender <[e-mail]>) by s57.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <[e-mail]>; 11 Mar 2009 09:23:54 -0000
User-Agent: Microsoft-Entourage/12.15.0.081119
Date: Wed, 11 Mar 2009 10:23:54 +0100
Subject: Re: draft-ietf-pkix-rfc3161bis-01.txt
From: Stefan Santesson <[e-mail]>
To: Peter Sylvester <[e-mail]>, <[e-mail]>
Message-ID: <[e-mail]>
Thread-Topic: draft-ietf-pkix-rfc3161bis-01.txt
Thread-Index: AcmiKxjKurO3I1owz0KZN9z45nTfEw==
In-Reply-To: <[e-mail]>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I would like to line up and express my concerns regarding the direction of
this document.

In principle I'm worried about the fundamental changes of concept and
terminology made in the update of an existing IETF standard.

While 3161 used TSA (Time Stamping Authority) as a collective term, 3161bis
uses three different terms:

TSA - TS Authority
TSU - TS Unit
TSS - TS Service

This is extremely confusing to me and appears unnecessary distinctions for
the sake of defining a protocol.

The change is motivated by RFC 3628 which has been upgraded as Normative.
But RFC 3628 is an Informational policy document and should never be
normative over the protocol standard.

I see several mixes of these new terms that appears confusing to me. For
example TSU is mentioned as being responsible for things where I would
suspect that any responsibility must reside with a TSA.

In section 4.3 the body text talk about TSU Messages, but the protocol
definitions define TSA Messages.

And it goes on like that throughout the document.

A more thorough discussion is needed here. My current view is that we
probably should revert completely back to the text of RFC 3161 and then just
do a minimum of technically well motivated changes. At this time I oppose
terminology alignment to RFC 3628.

/Stefan



On 3/4/09 6:22 PM, "Peter Sylvester" <[e-mail]> wrote:

> 
> I had the impression that thegoal of that texwt was an update
> concerning hash algorithms.
> 
> 
> One could expecte it would only contain an update to the ESScertid using
> ESSCertidV2 etc.
> 
> The actual texts corresponds roughly to an expired draft some
> years ago.
> 
>         - the document has been aligned with RFC 3628 to make the
>           difference between a time-stamping unit (TSU) and a TSA.
> 
> Thus, the text is not a small update of 3161 but introduces several
> new items, some of them seems questionable to me. Some problems
> which had been mentioned with RFC 3161 in the past, have not been
> addressed.
> 
> In 3161, a TSA is merely a technical service similar to what is
> said in 3161bis for a TSU. A TSA in 3161bis does not really
> have a defined technical role.
> 
> On the other hand the field tsa in a response refers to a TSA,
> and to a certficate that validates it. But a TSA does no longer
> have a certificate, only TSUs.
> 
> As a consequence, the following paragraph cannot mention TSA
> but at best a TSU.
> Besides that it should also mentiion ESSCertIDv2.)
> 
>     The purpose of the tsa field is to give a hint in identifying the
>     name of the TSA.  If present, it MUST correspond to one of the
>     subject names included in the certificate that is to be used to
>     verify the token.  However, the actual identification of the entity
>     that signed the response will always occur through the use of the
>     certificate identifier (ESSCertID Attribute) inside a
>     SigningCertificate attribute which is part of the signerInfo
>     (See Section 5 of [ESS]).
> 
> 
> Chapter 3.3 does not use the 2119 terminology in the first phrase but
> rather the ISO terminoilogy. 3.3 is not relevant for the function of
> a time stamp service. (Although it is likely that TSA actually
> have filled all the REQUIRED 'shall) attributes in the DN)
> 
> The following text is extremely fuzzy:
> 
>     The name of the issuing TSU shall contain an appropriate subset of
>     the following attributes (defined in ISO 9594-6 [ISO9594-6] and
>     ITU-T Recommendation X.520 [X.520]):
> 
>         - countryName;
>         - stateOrProvinceName;
>         - organizationName;
>         - commonName.
> 
> What means "appropriate subset". The text does not exclude
> other attributs. So in fact, it says: The TSU MUST have a subjectDN?
> 
> It is not defined what name identifies a TSA? for example, everything except
> the common name?
> 
> 4.3 :
> 
> As it had been mentioned before the socket protocol as it is defined
> has some problems: Since it was taken texto from CMP, there are some features
> that are may require some complexity in clients:
> Only 00, 05, and 06 seem useful to me. If a TSA/U is not able to sign
> a response within a few milliseconds with a TCP connection kept open,
> I wouldn't call this a service.
> For HTTP, a server cannot return a poll indication as a comparison.
> 
> If a client does not send a pollReq, what will happen with a pending
> response?
> 
> The protocol does not specify who terminates the connection. Is it the
> server that closes after one exchange?
> 
> If multiple requests and responses can be exchanged over the same connection,
> what is the dialogue model? request/response, pipelining, etc?
> 
> What is a TSU message? I think it should be TSP message. Old text was
> TSA, which was also somewhat wrong.
> 
> Security section point 1 seems not quite correct:
> 
> Instead of :
> it SHALL be set either to unspecified (0), affiliationChanged (3),
>        superseded (4) or cessationOfOperation (5).  In that case,
> 
> it should say
> 
> In the case when the reasonCode is set to either
>        affiliationChanged (3),
>        superseded (4) or cessationOfOperation (5)
> 
> Unspecified means that ther can be a key compromise IMO?
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 




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 n2AIECat048089 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Mar 2009 11:14:12 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2AIECfJ048088; Tue, 10 Mar 2009 11:14:12 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2AIEBNP048082 for <[e-mail]>; Tue, 10 Mar 2009 11:14:12 -0700 (MST) (envelope-from [e-mail])
Received: by bosco.isi.edu (Postfix, from userid 70) id 11E8924B69C; Tue, 10 Mar 2009 11:12:19 -0700 (PDT)
To: [e-mail], [e-mail]
Subject: RFC 5480 on Elliptic Curve Cryptography Subject Public Key Information
From: [e-mail]
Cc: [e-mail], [e-mail]
Message-Id: <[e-mail]>
Date: Tue, 10 Mar 2009 11:12:19 -0700 (PDT)
Sender: [e-mail]
Precedence: 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 new Request for Comments is now available in online RFC libraries.

        
        RFC 5480

        Title:      Elliptic Curve Cryptography Subject Public 
                    Key Information 
        Author:     S. Turner, D. Brown,
                    K. Yiu, R. Housley,
                    T. Polk
        Status:     Standards Track
        Date:       March 2009
        Mailbox:    [e-mail], 
                    [e-mail], 
                    [e-mail],
                    [e-mail], 
                    [e-mail]
        Pages:      20
        Characters: 36209
        Updates:    RFC3279

        I-D Tag:    draft-ietf-pkix-ecc-subpubkeyinfo-11.txt

        URL:        http://www.rfc-editor.org/rfc/rfc5480.txt

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 and 5, and
the ASN.1 module of "Algorithms and Identifiers for the Internet X.509
Public Key Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 3279.  [STANDARDS TRACK]

This document is a product of the Public-Key Infrastructure (X.509) Working Group of the IETF.

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Internet
Official Protocol Standards (STD 1) for the standardization state and
status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
USC/Information Sciences Institute




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 n2AI7OKD047642 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Mar 2009 11:07:24 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2AI7OGc047641; Tue, 10 Mar 2009 11:07:24 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp105.biz.mail.re2.yahoo.com (smtp105.biz.mail.re2.yahoo.com [206.190.52.174]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n2AI7DjU047634 for <[e-mail]>; Tue, 10 Mar 2009 11:07:23 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 49938 invoked from network); 10 Mar 2009 18:07:13 -0000
Received: from unknown (HELO ?192.168.1.2?) (turners@96.241.9.68 with plain) by smtp105.biz.mail.re2.yahoo.com with SMTP; 10 Mar 2009 18:07:12 -0000
X-Yahoo-SMTP: qPTWNAeswBAtDTSn9GKlmmL3C90ke7grn_5n9To-
X-YMail-OSG: JG6FqZoVM1m759X_4FxOYesGhFURNjMMgUShpLwqAEWdQM7M8zbOwvEbWaYy31dIuFEQ9icCE2CgL95ibroGlDEo9YOkUziuZQDZqNZWfEEiN82Kv7BC_Q3q5EgwYFFv64iSwcYBXaH1f.wWLvyZtYbF9m69d_Z30PgtV03r1S3yZBQsB4B8wtejjgLweNog_lsUrLndU.PzG7NHqBemBHeFQD6O
X-Yahoo-Newman-Property: ymail-3
Message-ID: <[e-mail]>
Date: Tue, 10 Mar 2009 14:07:20 -0400
From: Sean Turner <[e-mail]>
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-rfc4055-update-02.txt
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This draft addresses three IESG DISCUSS comments and one from the SECDIR 
review:

#1 There's now introductory text to explain the who, what, where and why 
of the changes.  Without the background from the proto write up there 
was little context for the changes.

#2 The changes in section 3 now affect both the 2nd and 3rd paragraph.

#3 There were some changes to the abstract.

#4 The security considerations was expanded.

spt

[e-mail] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.
> 
> 	Title		: Update for RSAES-OAEP Algorithm Parameters
> 	Author(s)	: S. Turner, K. Yiu, D. Brown, R. Housley, W. Polk
> 	Filename	: draft-ietf-pkix-rfc4055-update-02.txt
> 	Pages		: 7
> 	Date		: 2009-3-9
> 	
> This document updates RFC 4055.  It updates the conventions for using 
>    the RSA Encryption Scheme - Optimal Asymmetric Encryption Padding 
>    (RSAES-OAEP) key transport algorithm in the Internet X.509 Public Key 
>    Infrastructure (PKI).  Specifically, it updates the conventions for 
>    algorithm parameters in an X.509 certificate's subjectPublicKeyInfo 
>    field.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc4055-update-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.



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 n29LjbOT083216 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Mar 2009 14:45:37 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n29Ljblb083215; Mon, 9 Mar 2009 14:45:37 -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 n29LjahT083209 for <[e-mail]>; Mon, 9 Mar 2009 14:45:37 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id B909C3A6C8A; Mon,  9 Mar 2009 14:45:01 -0700 (PDT)
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-rfc4055-update-02.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Mon,  9 Mar 2009 14:45:01 -0700 (PDT)
Sender: [e-mail]
Precedence: 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		: Update for RSAES-OAEP Algorithm Parameters
	Author(s)	: S. Turner, K. Yiu, D. Brown, R. Housley, W. Polk
	Filename	: draft-ietf-pkix-rfc4055-update-02.txt
	Pages		: 7
	Date		: 2009-3-9
	
This document updates RFC 4055.  It updates the conventions for using 
   the RSA Encryption Scheme - Optimal Asymmetric Encryption Padding 
   (RSAES-OAEP) key transport algorithm in the Internet X.509 Public Key 
   Infrastructure (PKI).  Specifically, it updates the conventions for 
   algorithm parameters in an X.509 certificate's subjectPublicKeyInfo 
   field.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc4055-update-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
Content-Type: Message/External-body;
	name="draft-ietf-pkix-rfc4055-update-02.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 n29LFcJw081712 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Mar 2009 14:15:38 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n29LFcdQ081711; Mon, 9 Mar 2009 14:15:38 -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 n29LFbuG081704 for <[e-mail]>; Mon, 9 Mar 2009 14:15:37 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id 9CC4F3A6BC2; Mon,  9 Mar 2009 14:15:02 -0700 (PDT)
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D Action:draft-ietf-pkix-new-asn1-03.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Mon,  9 Mar 2009 14:15:02 -0700 (PDT)
Sender: [e-mail]
Precedence: 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           : New ASN.1 Modules for PKIX
	Author(s)       : P. Hoffman, J. Schaad
	Filename        : draft-ietf-pkix-new-asn1-03.txt
	Pages           : 119
	Date            : 2009-03-09

The PKIX certificate format, and many associated formats, are
expressed using ASN.1.  The current ASN.1 modules conform to the 1988
version of ASN.1.  This document updates those ASN.1 modules to
conform to the 2002 version of ASN.1.  There are no bits-on-the-wire
changes to any of the formats; this is simply a change to the syntax.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-new-asn1-03.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-new-asn1-03.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 n280ODia071217 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 7 Mar 2009 17:24:13 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n280ODUU071216; Sat, 7 Mar 2009 17:24:13 -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 n280O2Nq071209 for <[e-mail]>; Sat, 7 Mar 2009 17:24:12 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 9253 invoked from network); 8 Mar 2009 00:23:33 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 8 Mar 2009 00:23:33 -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: I-D Action:draft-ietf-pkix-ta-format-01.txt
Date: Sat, 7 Mar 2009 19:24:00 -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-format-01.txt
Thread-Index: AcmeoByemoDoNLVHQcKDrDvG2F2HSgA41Hyg
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Santosh Chokhani" <[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>

If making name optional meets the requirements of multiple environment,
then it is a better standard than making it mandatory.

As to memory challenged, I encourage you to speak with some real
implementers as they move their hardware tokens from 1024 bits to 2048
bits RSA.  They do need bigger and costlier cards.  So, memory in all
form factors is not free.

> -----Original Message-----
> From: [e-mail]=20
> [mailto:[e-mail]] On Behalf Of Eric Norman
> Sent: Friday, March 06, 2009 3:59 PM
> To: ietf-pkix
> Subject: Re: I-D Action:draft-ietf-pkix-ta-format-01.txt
>=20
>=20
>=20
> On Mar 6, 2009, at 2:17 PM, Santosh Chokhani wrote:
>=20
> >
> > There are environments where the device may be space=20
> challenged and/or=20
> > the communication environment may be bandwidth challenged.
> >
> > Thus, having only the required information in trust anchors=20
> and TAMP=20
> > will be helpful.
>=20
> Really?  How many bytes can be stored on a ESB memory stick nowadays?
> How many bits can be stored in one square millimeter=20
> nowadays?  How much time does it take to transfer a few=20
> thousand bytes with USB or Bluetooth nowadays?  Are you=20
> seriously suggesting that we need to design for folks whose=20
> environment includes carrier pigeons or tin cans and string=20
> as their communication mechanism?
>=20
> TAMP may indeed be useful, but not in the area of saving resources.
> Where it can be useful is to make it clearer which=20
> information is necessary and which information can be ignored=20
> for something to be a trust anchor and under what circumstances.
>=20
> Eric Norman
>=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 n26KxGKJ005158 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Mar 2009 13:59:16 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n26KxGIe005157; Fri, 6 Mar 2009 13:59:16 -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 n26KxEZO005151 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL) for <[e-mail]>; Fri, 6 Mar 2009 13:59:15 -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-7.04 (built Sep 26 2008; 32bit)) id <[e-mail]> for [e-mail]; Fri, 06 Mar 2009 14:59:14 -0600 (CST)
Received: from [192.168.0.14] (97-92-189-144.dhcp.mdsn.wi.charter.com [97.92.189.144]) by smtpauth2.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <[e-mail]> for [e-mail]; Fri, 06 Mar 2009 14:59:09 -0600 (CST)
Date: Fri, 06 Mar 2009 14:59:10 -0600
From: Eric Norman <[e-mail]>
Subject: Re: I-D Action:draft-ietf-pkix-ta-format-01.txt
In-reply-to: <[e-mail]>
To: ietf-pkix <[e-mail]>
Message-id: <[e-mail]>
X-Mailer: Apple Mail (2.624)
X-Spam-Report: AuthenticatedSender=yes, SenderIP=192.168.0.14
X-Spam-PmxInfo: Server=avs-9, Version=5.5.1.360522, Antispam-Engine: 2.6.1.350677, Antispam-Data: 2009.3.6.204646, SenderIP=192.168.0.14
References: <[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>

On Mar 6, 2009, at 2:17 PM, Santosh Chokhani wrote:

>
> There are environments where the device may be space challenged and/or 
> the communication environment may be bandwidth challenged.
>
> Thus, having only the required information in trust anchors and TAMP 
> will be helpful.

Really?  How many bytes can be stored on a ESB memory stick nowadays?
How many bits can be stored in one square millimeter nowadays?  How
much time does it take to transfer a few thousand bytes with USB or
Bluetooth nowadays?  Are you seriously suggesting that we need to
design for folks whose environment includes carrier pigeons or tin
cans and string as their communication mechanism?

TAMP may indeed be useful, but not in the area of saving resources.
Where it can be useful is to make it clearer which information is
necessary and which information can be ignored for something to be
a trust anchor and under what circumstances.

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 n26KI3Jn003193 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Mar 2009 13:18:04 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n26KI36D003192; Fri, 6 Mar 2009 13:18:03 -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 n26KHqjh003181 for <[e-mail]>; Fri, 6 Mar 2009 13:18:02 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 19195 invoked from network); 6 Mar 2009 20:17:26 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 6 Mar 2009 20:17:26 -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: I-D Action:draft-ietf-pkix-ta-format-01.txt
Date: Fri, 6 Mar 2009 15:17:47 -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-format-01.txt
Thread-Index: AcmelbQVu7527amnSzmEtafDszsA2gAAreBw
References: <[e-mail]> <[e-mail]> <[e-mail]>
From: "Santosh Chokhani" <[e-mail]>
To: "Eric Norman" <[e-mail]>, "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>

There are environments where the device may be space challenged and/or =
the communication environment may be bandwidth challenged.

Thus, having only the required information in trust anchors and TAMP =
will be helpful.

> -----Original Message-----
> From: [e-mail]=20
> [mailto:[e-mail]] On Behalf Of Eric Norman
> Sent: Friday, March 06, 2009 2:45 PM
> To: ietf-pkix
> Subject: Re: I-D Action:draft-ietf-pkix-ta-format-01.txt
>=20
>=20
>=20
> On Mar 6, 2009, at 3:48 AM, Denis Pinkas wrote:
>=20
> > 1 - The draft states: "Though widely used, there is no=A0
> standard format=20
> > for representing trust anchor information".
> > This is untrue. Self-signed certificates are currently=20
> widely used to=20
> > represent TAs. It may simply be argued that other forms ("more=20
> > compact" as indicated) are also needed.
>=20
> Indeed, representation as self-signed certificates is almost=20
> universal.
> What I would like to point out, and what I think=20
> documentation should make clear, is that the "self-signed"=20
> part is not a requirement to be a trust anchor.  The ultimate=20
> decision about "trust" lies with the relying party, and I see=20
> no reason why a relying party should be denied the ability to=20
> use any public key they chose as a trust anchor, even if that=20
> public key is contained in a certificate that is not self-signed.
> This is not a syntactic thing.  In my mind it just a=20
> clarification of what often seems to be confusion between=20
> "must be represented" and "must be used".
>=20
> And on another topic.  Has the need for "more compact" been justified?
> Really?  If someone seriously thinks there is a need for more=20
> compactness nowadays, shouldn't they be talking to those XML folks?
>=20
> Eric Norman
>=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 n26JjCup001329 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Mar 2009 12:45:12 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n26JjC3H001328; Fri, 6 Mar 2009 12:45:12 -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 n26Jj1wJ001316 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL) for <[e-mail]>; Fri, 6 Mar 2009 12:45:12 -0700 (MST) (envelope-from [e-mail])
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Received: from avs-daemon.smtpauth2.wiscmail.wisc.edu by smtpauth2.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) id <[e-mail]> for [e-mail]; Fri, 06 Mar 2009 13:45:00 -0600 (CST)
Received: from [192.168.0.14] (97-92-189-144.dhcp.mdsn.wi.charter.com [97.92.189.144]) by smtpauth2.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <[e-mail]> for [e-mail]; Fri, 06 Mar 2009 13:44:54 -0600 (CST)
Date: Fri, 06 Mar 2009 13:44:55 -0600
From: Eric Norman <[e-mail]>
Subject: Re: I-D Action:draft-ietf-pkix-ta-format-01.txt
In-reply-to: <[e-mail]>
To: ietf-pkix <[e-mail]>
Message-id: <[e-mail]>
X-Mailer: Apple Mail (2.624)
Content-transfer-encoding: quoted-printable
X-Spam-Report: AuthenticatedSender=yes, SenderIP=192.168.0.14
X-Spam-PmxInfo: Server=avs-11, Version=5.5.1.360522, Antispam-Engine: 2.6.1.350677, Antispam-Data: 2009.3.6.193428, SenderIP=192.168.0.14
References: <[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 Mar 6, 2009, at 3:48 AM, Denis Pinkas wrote:

> 1 - The draft states: "Though widely used, there is no=A0standard =
format=20
> for representing trust anchor information".
> This is untrue. Self-signed certificates are currently widely used to=20=

> represent TAs. It may simply be argued that
> other forms ("more compact" as indicated) are also needed.

Indeed, representation as self-signed certificates is almost universal.
What I would like to point out, and what I think documentation should
make clear, is that the "self-signed" part is not a requirement to be
a trust anchor.  The ultimate decision about "trust" lies with the
relying party, and I see no reason why a relying party should be denied
the ability to use any public key they chose as a trust anchor, even
if that public key is contained in a certificate that is not=20
self-signed.
This is not a syntactic thing.  In my mind it just a clarification of
what often seems to be confusion between "must be represented" and "must
be used".

And on another topic.  Has the need for "more compact" been justified?
Really?  If someone seriously thinks there is a need for more=20
compactness
nowadays, shouldn't they be talking to those XML folks?

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 n26HNxJ7093799 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Mar 2009 10:23:59 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n26HNxbV093798; Fri, 6 Mar 2009 10:23:59 -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 n26HNmpT093788 for <[e-mail]>; Fri, 6 Mar 2009 10:23:58 -0700 (MST) (envelope-from [e-mail])
Received: from dommiel.bbn.com ([192.1.122.15] helo=[192.168.1.4]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from <[e-mail]>) id 1Lfdlz-0005vW-FP for [e-mail]; Fri, 06 Mar 2009 12:23:48 -0500
Mime-Version: 1.0
Message-Id: <p06240802c5d70c162122@[192.168.1.4]>
Date: Fri, 6 Mar 2009 12:23:45 -0500
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: another WGLC
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>

Stephen Farrell just posted draft-ietf-pkix-other-certs-02 and would 
like to initiate a WGLC.  I see that there has already been one 
comment, so it's good to see folks are paying attention :-).

Let's make this WGLC longer than the usual 2 weeks, because of the 
impending IETF meeting.  WGLC will close for this document on April 
10.

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 n26HHGEA093473 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Mar 2009 10:17:17 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n26HHGZ0093472; Fri, 6 Mar 2009 10:17:16 -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 n26HH4tA093457 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Fri, 6 Mar 2009 10:17:15 -0700 (MST) (envelope-from [e-mail])
Received: from dommiel.bbn.com ([192.1.122.15] helo=[192.168.1.4]) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from <[e-mail]>) id 1LfdfT-0007Eq-C2 for [e-mail]; Fri, 06 Mar 2009 12:17:04 -0500
Mime-Version: 1.0
Message-Id: <p06240801c5d70401734f@[192.168.1.4]>
Date: Fri, 6 Mar 2009 12:17:01 -0500
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: WGLC
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,

Sean and Santosh have updated

draft-ietf-pkix-authorityclearanceconstraints-01.txt

in response to feedback received during the WGLC process.

I'd like to initiate a quick (1 week) second-pass WGLC on this document now.

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 n26Go4wj092009 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Mar 2009 09:50:04 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n26Go4vK092008; Fri, 6 Mar 2009 09:50:04 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mallaury.nerim.net (smtp-105-friday.noc.nerim.net [62.4.17.105]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n26Gnr8l091983 for <[e-mail]>; Fri, 6 Mar 2009 09:50:03 -0700 (MST) (envelope-from [e-mail])
Received: from uranus.cry.pto (cryptolog2.pck.nerim.net [213.41.184.9]) by mallaury.nerim.net (Postfix) with ESMTP id 315B5A10E4; Fri,  6 Mar 2009 17:49:51 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by uranus.cry.pto (Postfix) with ESMTP id 20EC9440F5; Fri,  6 Mar 2009 17:49:52 +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 QUIE7Q-lto+h; Fri,  6 Mar 2009 17:49:47 +0100 (CET)
Received: from [10.0.1.30] (leda.cry.pto [10.0.1.30]) by uranus.cry.pto (Postfix) with ESMTP id 53706440ED; Fri,  6 Mar 2009 17:49:47 +0100 (CET)
Message-ID: <[e-mail]>
Date: Fri, 06 Mar 2009 17:49:47 +0100
From: Julien Stern <[e-mail]>
User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103)
MIME-Version: 1.0
To: Carl Wallace <[e-mail]>
Cc: [e-mail]
Subject: Re: I-D Action:draft-ietf-pkix-ta-format-01.txt
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>

Carl Wallace wrote:
>>> The booleans align with the inputs to the path validation algorithm.
>>> Ideally, those would have been integers too.
>> Hmm... That a tricky point I think. I agree that the 
>> validation algorithm has currently described takes booleans.
>>
>> However,
>> 1) It is allowed to augment the algorithm (and that would be 
>> a worthwhile augmentation)
>> 2) What are some existing algorithm doing?Iif the indicator 
>> is set to true, some will look at the extension in the trust 
>> anchor to initialize a value which will be an integer, and 
>> not a boolean anymore.
>>
>> So, if we leave them as boolean in the trust anchor, we will 
>> prevent trust anchor from defining these values, especially 
>> considering that the RFC explicitly states that the 
>> extensions which contains these elements should be ignored.
> 
> Even if the algorithm were augmented, we'd need to describe how to use
> the existing inputs.  Two possible options are:
> 
> 	- Require the values to be 0.  This would have the effect of
> setting the corresponding validation input flag to true.  Processing
> would fail if the extension is present and the value is not zero.  
> 	- Turn on the corresponding validation input flag given any
> SkipCerts value (i.e., presence of a field or extension corresponding to
> a validation input flag causes the flag to be set to true and absence
> causes the flag to be set to false).
> 
> The first option would also disallow using arbitrary CA certificates as
> a trust anchor if the certificate contains a SkipCerts > 0.  Though it
> could be used if the certificate were wrapped in a TrustAnchorInfo or
> just the TBSCertificate structure were used.  I prefer the second
> option.

Carl,

I agree. And indeed 5280 defines these flags as OPTIONAL, when taken 
from the certificate extension.

id-ce-policyConstraints OBJECT IDENTIFIER ::=  { id-ce 36 }

PolicyConstraints ::= SEQUENCE {
    requireExplicitPolicy           [0] SkipCerts OPTIONAL,
    inhibitPolicyMapping            [1] SkipCerts OPTIONAL }

So, if we were to replace the booleans by integers, it would indeed be 
needed to make them OPTIONAL, and to set the value of the input flag to 
false if they are absent and true otherwise.

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 n26GicOZ091818 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Mar 2009 09:44:39 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n26Gicmr091817; Fri, 6 Mar 2009 09:44:38 -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.158] (dsl-63-249-108-169.static.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n26GiYaF091807 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Mar 2009 09:44:35 -0700 (MST) (envelope-from [e-mail])
Mime-Version: 1.0
Message-Id: <p0624084ac5d702f27727@[10.20.30.158]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Date: Fri, 6 Mar 2009 08:44:34 -0800
To: [e-mail], "ietf-pkix"<[e-mail]>
From: Paul Hoffman <[e-mail]>
Subject: Re: I-D Action:draft-ietf-pkix-ta-format-01.txt
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:48 AM +0100 3/6/09, Denis Pinkas wrote:
>1 - The draft states: "Though widely used, there is no standard format for representing trust anchor information".
>This is untrue. Self-signed certificates are currently widely used to represent TAs. It may simply be argued that
>other forms ("more compact" as indicated) are also needed.

Self-signed certs are widely used for representing the trust anchor keys, but not the rest of the information, such as what chains those keys can be used for. The latter is much more interesting than the former.


--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 n26G0YHc089342 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Mar 2009 09:00:34 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n26G0Y8Z089341; Fri, 6 Mar 2009 09:00:34 -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 n26G0XEN089335 for <[e-mail]>; Fri, 6 Mar 2009 09:00:33 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id C9DFD28C27C; Fri,  6 Mar 2009 08:00:01 -0800 (PST)
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D Action:draft-ietf-pkix-sha2-dsa-ecdsa-06.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Fri,  6 Mar 2009 08: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           : Internet X.509 Public Key Infrastructure: Additional Algorithms and Identifiers for DSA and ECDSA
	Author(s)       : Q. Dang
	Filename        : draft-ietf-pkix-sha2-dsa-ecdsa-06.txt
	Pages           : 15
	Date            : 2009-03-06

This document supplements RFC 3279. It specifies 

 algorithm identifiers and ASN.1 encoding rules for 

 the Digital Signature Algorithm (DSA) and Elliptic 

 Curve Digital Signature Algorithm (ECDSA) digital 

 signatures when using SHA-224, SHA-256, SHA-384 or 

 SHA-512 as hashing algorithm. This specification 

 applies to the Internet X.509 Public Key  

 Infrastructure (PKI) when digital signatures are 

 used to sign certificates and certificate 

 revocation lists (CRLs).  

  

 The key words "MUST", "MUST NOT", "REQUIRED", 

 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", 

 "RECOMMENDED", "MAY", and "OPTIONAL" in this 

 document are to be interpreted as described in 

 [RFC 2119].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-sha2-dsa-ecdsa-06.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-sha2-dsa-ecdsa-06.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 n26FcQYE088369 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Mar 2009 08:38:26 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n26FcQTI088368; Fri, 6 Mar 2009 08:38:26 -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 n26FcFEk088358 for <[e-mail]>; Fri, 6 Mar 2009 08:38:25 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 14045 invoked from network); 6 Mar 2009 15:37:48 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 6 Mar 2009 15:37:48 -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: I-D Action:draft-ietf-pkix-ta-format-01.txt
Date: Fri, 6 Mar 2009 10:38:13 -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-format-01.txt
Thread-Index: AcmdlO054K481wIbRmeBUlUTWB1SzgA2ooHQ
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Carl Wallace" <[e-mail]>
To: "Julien Stern" <[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>

> > The booleans align with the inputs to the path validation algorithm.
> > Ideally, those would have been integers too.
>=20
> Hmm... That a tricky point I think. I agree that the=20
> validation algorithm has currently described takes booleans.
>=20
> However,
> 1) It is allowed to augment the algorithm (and that would be=20
> a worthwhile augmentation)
> 2) What are some existing algorithm doing?Iif the indicator=20
> is set to true, some will look at the extension in the trust=20
> anchor to initialize a value which will be an integer, and=20
> not a boolean anymore.
>=20
> So, if we leave them as boolean in the trust anchor, we will=20
> prevent trust anchor from defining these values, especially=20
> considering that the RFC explicitly states that the=20
> extensions which contains these elements should be ignored.

Even if the algorithm were augmented, we'd need to describe how to use
the existing inputs.  Two possible options are:

	- Require the values to be 0.  This would have the effect of
setting the corresponding validation input flag to true.  Processing
would fail if the extension is present and the value is not zero. =20
	- Turn on the corresponding validation input flag given any
SkipCerts value (i.e., presence of a field or extension corresponding to
a validation input flag causes the flag to be set to true and absence
causes the flag to be set to false).

The first option would also disallow using arbitrary CA certificates as
a trust anchor if the certificate contains a SkipCerts > 0.  Though it
could be used if the certificate were wrapped in a TrustAnchorInfo or
just the TBSCertificate structure were used.  I prefer the second
option. =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 n26F1Ynp086829 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Mar 2009 08:01:34 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n26F1YmD086828; Fri, 6 Mar 2009 08:01:34 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from WA4EHSOBE003.bigfish.com (wa4ehsobe003.messaging.microsoft.com [216.32.181.13]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n26F1MJP086818 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL) for <[e-mail]>; Fri, 6 Mar 2009 08:01:33 -0700 (MST) (envelope-from [e-mail])
Received: from mail187-wa4-R.bigfish.com (10.8.14.254) by WA4EHSOBE003.bigfish.com (10.8.40.23) with Microsoft SMTP Server id 8.1.340.0; Fri, 6 Mar 2009 15:01:22 +0000
Received: from mail187-wa4 (localhost.localdomain [127.0.0.1])	by mail187-wa4-R.bigfish.com (Postfix) with ESMTP id 0347F10805C;	Fri,  6 Mar 2009 15:01:22 +0000 (UTC)
X-BigFish: VPS-13(zz1432R98dR148cM1805Mfb6Kzzzzz2dh6bh87il62h)
X-Spam-TCS-SCL: 1:0
X-FB-SS: 5,
X-FB-DOMAIN-IP-MATCH: fail
Received: by mail187-wa4 (MessageSwitch) id 1236351680244533_2648; Fri,  6 Mar 2009 15:01:20 +0000 (UCT)
Received: from imx1.tcd.ie (imx1.tcd.ie [134.226.17.160])	by mail187-wa4.bigfish.com (Postfix) with ESMTP id E2D6B131005E;	Fri,  6 Mar 2009 15:01:19 +0000 (UTC)
Received: from Vams.imx1 (imx1.tcd.ie [134.226.17.160])	by imx1.tcd.ie (Postfix) with SMTP	id 4F6394929; Fri,  6 Mar 2009 15:01:19 +0000 (GMT)
Received: from imx1.tcd.ie ([134.226.17.160])	by imx1 ([127.0.0.1])	with SMTP (gateway) id A04A6D4B561; Fri, 06 Mar 2009 15:01:19 +0000
Received: from [134.226.36.180] (sfarrell.dsg.cs.tcd.ie [134.226.36.180])	by imx1.tcd.ie (Postfix) with ESMTP	id 3A1CC4929; Fri,  6 Mar 2009 15:01:19 +0000 (GMT)
Message-ID: <[e-mail]>
Date: Fri, 6 Mar 2009 15:01:34 +0000
From: Stephen Farrell <[e-mail]>
User-Agent: Thunderbird 2.0.0.16 (X11/20080707)
MIME-Version: 1.0
To: "Manger, James H" <[e-mail]>
CC: "[e-mail]" <[e-mail]>
Subject: Re: I-D Action:draft-ietf-pkix-other-certs-02.txt
References: <[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
X-AntiVirus-Status: MessageID = A14A6D4B561
X-AntiVirus-Status: Host: imx1.tcd.ie
X-AntiVirus-Status: Action Taken: 
X-AntiVirus-Status: NONE
X-AntiVirus-Status: Checked by TCD Vexira. (version=1.60.2 VDF=10.101.35)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Manger, James H wrote:
> draft-ietf-pkix-other-certs-02.txt allows a cert to reference any number of other certs.
> 
> The cert and the other certs will often be issued by the same CA. It would be nice if the CA's DN didn't have to be repeated for every other cert. For instance, refer to each other cert by: cert hash, cert serial number, and an optional issuer DN. When the issuer DN is absent from a reference use the issuer DN from the certificate (or the previous reference).
> 
> The issuer DN in a reference is held in a SEQUENCE OF GeneralName. It would be tempting to treat an empty sequence as meaning use the cert DN. The hassle is than the sequence (GeneralNames) is defined with a SIZE (1..MAX) constraint.

Nice idea, thanks for pointing it out.

I guess if the optimisation was considered worthwhile we could
say that there should be 1 GeneralName that's a DN that's empty,
in which case the issuer of the containing cert is indicated.

> 
> Issuer DNs are often a few hundred bytes (10%-20% of cert), but perhaps avoiding duplication isn't worth adding any complexity for.

Right. At this point, I don't think that the change is worthwhile
mainly because it'd (I guess) mean that anyone wanting to implement
this would have to tweak their code for handling SCVPCertID for the
special case above. Again, I'm guessing, but I suspect that existing
code for that structure might barf on an empty DN.

However, if folks want that, I'd have no problem adding a scheme
like the above, but for now I think its best left out.

In any case, I'll add a note along the lines below (and an ack
to you) so that if this ever comes back onto the standards track,
that whoever's doing the work then can think about it.

Sound ok?

Stephen.

The SCVPCertID structure used here contains the issuer name for
the CA of the linked certificate. It may happen that that issuer
is also the issuer of the certificate containing the other-certificates
extension. If a new certificate were linked back to a number of old
certificates from that same CA, then there would be considerable
redundancy since there would be many copies of the same issuer name.

One suggestion raised was to have a convention where if the X.500 Name
in the SCVPCertID is an "empty" DN (see RFC5280) that that would
indicate that the same CA issued both the current and the linked
certificates.




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 n26E99GC084001 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Mar 2009 07:09:09 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n26E99rx084000; Fri, 6 Mar 2009 07:09: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-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 n26E8voF083982 for <[e-mail]>; Fri, 6 Mar 2009 07:09:08 -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 n26E8uM2007556 for <[e-mail]>; Fri, 6 Mar 2009 09:08:56 -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 n26E8tsG007468; Fri, 6 Mar 2009 09:08:55 -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; Fri, 6 Mar 2009 09:08:54 -0500
Message-ID: <[e-mail]>
Date: Fri, 6 Mar 2009 08:08:52 -0600
From: "Timothy J. Miller" <[e-mail]>
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: "David A. Cooper" <[e-mail]>
CC: pkix <[e-mail]>
Subject: Re: Need help finding implementations of certain RFC 5280 features
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050705050508090107050100"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

David A. Cooper wrote:

> 2) From Section 4.2.2.1 (Authority Information Access):
> 
>    HTTP server implementations accessed via the URI SHOULD specify the
>    media type application/pkix-cert [RFC2585] in the content-type header
>    field of the response for a single DER encoded certificate....
> 
> I have found several certificates that include an AIA extension with an 
> id-ad-caIssuers access method with an HTTP URI that points to a single 
> certificate, but none of the HTTP servers specify the media type as 
> application/pkix-cert.  Most specify the media type as 
> application/x-x509-ca-cert and a few specify the media type as text/plain.

Newer DoD certs contain an AIA caIssuers HTTP URI of the form:

http://crl.disa.mil/getsign?<URL encoded CA name>

e.g.:

http://crl.disa.mil/getsign?DOD%20CA-18

Which returns a MIME type of application/pkix-cert.  Also, crl.disa.mil 
is sometimes crl.gds.disa.mil, just because we like to change names a 
lot.  :)

Please be nice to the website; the DISA network providing CRLs is almost 
completely saturated.  If you do fetch a DoD CRL by way of example, 
stick to the one above; it has one of the smallest CRLs.

-- Tim


--------------ms050705050508090107050100
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
Fw0wOTAzMDYxNDA4NTJaMCMGCSqGSIb3DQEJBDEWBBTOY6BnwYScrZvu33m7EfkD5UFaTTBS
BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D
AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNV
BAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQD
Ex5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAh8FMHQGCyqGSIb3DQEJEAILMWWg
YzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0
eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTANBgkqhkiG
9w0BAQEFAASBgCu9XaaM+WIfGN11vEZKtW7sF0KJ5MKNnqimgAE5ZM+DeBueiWt9sTYbgi4W
ucTlNanyriFBTHy+0+7aqemK3VtlRqs3T+fajXdaVLFyGIbwrdjapTzSEeJETMZES17jQwBS
jI6oO+2tdei8FIiAfVEW8Ox7mipCnMvk2+J/pCshAAAAAAAA
--------------ms050705050508090107050100--



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 n269mItp068981 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Mar 2009 02:48:19 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n269mISs068980; Fri, 6 Mar 2009 02:48:18 -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 n269m6Nt068965 for <[e-mail]>; Fri, 6 Mar 2009 02:48:18 -0700 (MST) (envelope-from [e-mail])
Received: from MSGA-001.frcl.bull.fr (msga-001.frcl.bull.fr [129.184.87.31]) by odin2.bull.net (Bull S.A.) with ESMTP id B5E777BEA for <[e-mail]>; Fri,  6 Mar 2009 10:39:39 +0100 (CET)
Received: from FRCLS4013 ([129.182.108.120]) by MSGA-001.frcl.bull.fr (Lotus Domino Release 5.0.11) with SMTP id 2009030610480439:308103 ; Fri, 6 Mar 2009 10:48:04 +0100 
Reply-To: [e-mail]
From: "Denis Pinkas"<[e-mail]>
To: "ietf-pkix"<[e-mail]>
Subject: Re: I-D Action:draft-ietf-pkix-ta-format-01.txt
Date: Fri, 6 Mar 2009 10:48:04 +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/03/2009 10:48:04, Serialize by Router on MSGA-001/FR/BULL(Release 5.0.11  |July 24, 2002) at 06/03/2009 10:48:05, Serialize complete at 06/03/2009 10:48:05
Content-Type: multipart/alternative;  boundary="----=_NextPart_09030610480419520008280_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_09030610480419520008280_002
Content-Type: text/plain; 
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

Yesterday, I have seen an avalanche of e-mails on this draft.

The main issue is that this document has two different goals which should=
 be clearly advertised in the abstract:

It provides the controls needed to :

a) initialize an X.509 certification path validation algorithm implementa=
tion, and to=20
b) verify digital signatures in contexts where X.509 certificates are NOT=
 used.

The draft makes circumvolutions to address both cases. Quoted text:
"If the certificate is present, the subject name in the certificate MUST =
exactly match the X.500 distinguished name provided in the taName field, =
the public key MUST exactly match the public key in the pubKey field and =
the subjectKeyIdentifier extension, if present, MUST exactly match the ke=
y identifier in the keyId field".=20
It would be simpler and clearer to separate both cases and to have a CHOI=
CE between two simple structures from the very beginning.

Basically, I support Julien's view, saying that the name of the taTitle s=
hould be mandatory. However, it is only needed for case b).
When deciding to place a TA in a store, a human being may need to make a =
decision.
Currenty the keyId is only an octet string. This does not allow a human b=
eing to know to who the key belongs to.
On the contrary, taTitle is an UTF8String that can be easily displayed.

Besides these points, I would like to mention some other concerns on this=
 draft.

1 - The draft states: "Though widely used, there is no standard format fo=
r representing trust anchor information".
This is untrue. Self-signed certificates are currently widely used to rep=
resent TAs. It may simply be argued that=20
other forms ("more compact" as indicated) are also needed.

2 - For case a), a structure containing the hash of a self-signed certifi=
cate should also be considered.=20
This would diminish the size of the foot-print.

3 - For case b, the validity period of the TA is a fundamental informatio=
n.=20
The current structure does not allow to support it. It should.=20

Denis
 =20
----- Message re=E7u -----=20
De : owner-ietf-pkix=20
=C0 : i-d-announce=20
Date : 2009-03-04, 17:15:02
Sujet : I-D Action:draft-ietf-pkix-ta-format-01.txt


Pi=E8ce(s) Jointe(s) au message original :
  (1). draft-ietf-pkix-ta-format-01.txt


  Title : Trust Anchor Format
  Author(s) : R. Housley, et al.
  Filename : draft-ietf-pkix-ta-format-01.txt
  Pages : 17
  Date : 2009-03-04

This document describes a structure for representing trust anchor
information. A trust anchor is an authoritative entity represented
by 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 or actions for which the trust
anchor is authoritative. The structures defined in this document are
intended to satisfy the format-related requirements defined in Trust
Anchor Management Requirements.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-ta-format-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_09030610480419520008280_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>Yesterday, I have seen an avalanche of e-mails on this draft.</DIV>
<DIV>&nbsp;</DIV>
<DIV>The main issue is that this document has two different goals which s=
hould=20
be&nbsp;clearly advertised in the abstract:</DIV>
<DIV>&nbsp;</DIV>
<DIV>It provides the controls needed to :</DIV>
<DIV>&nbsp;</DIV>
<DIV>a) initialize an X.509 certification path validation algorithm=20
implementation, and to </DIV>
<DIV>b) verify digital signatures in contexts where X.509 certificates=20
are&nbsp;NOT used.</DIV>
<DIV>&nbsp;</DIV>
<DIV>The draft makes circumvolutions to address both cases.&nbsp;Quoted=20
text:</DIV>
<DIV><PRE>"If the certificate is present, the<SPAN style=3D"mso-spacerun:=
 yes"> </SPAN>subject name in the certificate MUST exactly match <BR>the =
X.500 distinguished name provided in the taName field, the public key MUS=
T <BR>exactly match the public key in the pubKey field and the subjectKey=
Identifier extension, <BR>if present, MUST exactly match the <SPAN style=3D=
"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-font-family=
: 'Times New Roman'; mso-ansi-language: FR; mso-fareast-language: FR; mso=
-bidi-language: AR-SA">key identifier in the keyId field". </SPAN></PRE><=
/DIV>
<DIV>It would be simpler and clearer to separate both cases and to have a=
 CHOICE=20
between two simple structures from the very beginning.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Basically, I support Julien's view, saying that the name of the taTi=
tle=20
should be mandatory. However, it is only needed for case b).</DIV>
<DIV>When deciding to place a TA in a store, a human being may need to ma=
ke a=20
decision.</DIV>
<DIV>Currenty the keyId is only an octet string. This&nbsp;does not allow=
 a=20
human being to know to who the key belongs to.</DIV>
<DIV>On the contrary, taTitle is an UTF8String that can be easily=20
displayed.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Besides these points, I would like to mention&nbsp;some other&nbsp;c=
oncerns=20
on this draft.</DIV>
<DIV>&nbsp;</DIV>
<DIV>1 - The draft states: "Though widely used, there is no&nbsp;<SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-fon=
t-family: 'Times New Roman'; mso-ansi-language: FR; mso-fareast-language:=
 FR; mso-bidi-language: AR-SA">standard=20
format for representing trust anchor information".</SPAN></DIV>
<DIV><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-fon=
t-family: 'Times New Roman'; mso-ansi-language: FR; mso-fareast-language:=
 FR; mso-bidi-language: AR-SA">This=20
is untrue. Self-signed certificates are currently widely used to represen=
t TAs.=20
It may simply be argued that <BR>other forms ("more compact" as indicated=
) are=20
also needed</SPAN><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-fon=
t-family: 'Times New Roman'; mso-ansi-language: FR; mso-fareast-language:=
 FR; mso-bidi-language: AR-SA">.</SPAN></DIV>
<DIV><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-fon=
t-family: 'Times New Roman'; mso-ansi-language: FR; mso-fareast-language:=
 FR; mso-bidi-language: AR-SA"></SPAN>&nbsp;</DIV>
<DIV><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-fon=
t-family: 'Times New Roman'; mso-ansi-language: FR; mso-fareast-language:=
 FR; mso-bidi-language: AR-SA">2&nbsp;-=20
For case a), a structure containing the hash of&nbsp;a self-signed certif=
icate=20
should also be considered. </SPAN></DIV>
<DIV><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-fon=
t-family: 'Times New Roman'; mso-ansi-language: FR; mso-fareast-language:=
 FR; mso-bidi-language: AR-SA">This=20
would d<SPAN lang=3DEN-GB=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-fon=
t-family: 'Times New Roman'; mso-ansi-language: EN-GB; mso-fareast-langua=
ge: FR; mso-bidi-language: AR-SA">iminish</SPAN>=20
the size of the foot-print.</SPAN></DIV>
<DIV><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-fon=
t-family: 'Times New Roman'; mso-ansi-language: FR; mso-fareast-language:=
 FR; mso-bidi-language: AR-SA"></SPAN><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-fon=
t-family: 'Times New Roman'; mso-ansi-language: FR; mso-fareast-language:=
 FR; mso-bidi-language: AR-SA"></SPAN>&nbsp;</DIV>
<DIV><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-fon=
t-family: 'Times New Roman'; mso-ansi-language: FR; mso-fareast-language:=
 FR; mso-bidi-language: AR-SA">3&nbsp;-=20
For case b, the&nbsp;validity period of the TA is a fundamental informati=
on.=20
<BR>The current structure does not allow to support it. </SPAN><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-fon=
t-family: 'Times New Roman'; mso-ansi-language: FR; mso-fareast-language:=
 FR; mso-bidi-language: AR-SA">It=20
should. </SPAN></DIV>
<DIV><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-fon=
t-family: 'Times New Roman'; mso-ansi-language: FR; mso-fareast-language:=
 FR; mso-bidi-language: AR-SA"></SPAN><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-fon=
t-family: 'Times New Roman'; mso-ansi-language: FR; mso-fareast-language:=
 FR; mso-bidi-language: AR-SA"></SPAN><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-fon=
t-family: 'Times New Roman'; mso-ansi-language: FR; mso-fareast-language:=
 FR; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-fon=
t-family: 'Times New Roman'; mso-ansi-language: FR; mso-fareast-language:=
 FR; mso-bidi-language: AR-SA"></SPAN></SPAN>&nbsp;</DIV>
<DIV><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-fon=
t-family: 'Times New Roman'; mso-ansi-language: FR; mso-fareast-language:=
 FR; mso-bidi-language: AR-SA">Denis</SPAN></DIV>
<DIV><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-fon=
t-family: 'Times New Roman'; mso-ansi-language: FR; mso-fareast-language:=
 FR; mso-bidi-language: AR-SA">&nbsp;&nbsp;</SPAN></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> 2009-03-04, 17:15:02</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-format-01.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-format-01.txt</DIV><BR></=
DIV>
  <DIV>
  <DIV>&nbsp;&nbsp;Title : Trust Anchor Format<BR>&nbsp;&nbsp;Author(s) :=
 R.=20
  Housley, et al.<BR>&nbsp;&nbsp;Filename :=20
  draft-ietf-pkix-ta-format-01.txt<BR>&nbsp;&nbsp;Pages : 17<BR>&nbsp;&nb=
sp;Date=20
  : 2009-03-04<BR><BR>This document describes a structure for representin=
g trust=20
  anchor<BR>information. A trust anchor is an authoritative entity=20
  represented<BR>by a public key and associated data. The public key is u=
sed=20
  to<BR>verify digital signatures and the associated data is used=20
  to<BR>constrain the types of information or actions for which the=20
  trust<BR>anchor is authoritative. The structures defined in this docume=
nt=20
  are<BR>intended to satisfy the format-related requirements defined in=20
  Trust<BR>Anchor Management Requirements.<BR><BR>A URL for this Internet=
-Draft=20
  is:<BR><A=20
  href=3D"http://www.ietf.org/internet-drafts/draft-ietf-pkix-ta-format-0=
1.txt">http://www.ietf.org/internet-drafts/draft-ietf-pkix-ta-format-01.t=
xt</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_09030610480419520008280_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 n260bPdF047439 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Mar 2009 17:37:25 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n260bP6x047438; Thu, 5 Mar 2009 17:37:25 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mailipbo.ntcif.telstra.com.au (mailipbo.ntcif.telstra.com.au [202.12.233.29]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n260bDBP047421 for <[e-mail]>; Thu, 5 Mar 2009 17:37:24 -0700 (MST) (envelope-from [e-mail])
Received: from unknown (HELO mailbi.ntcif.telstra.com.au) ([202.12.162.19]) by mailipbi.ntcif.telstra.com.au with ESMTP; 06 Mar 2009 11:37:12 +1100
Received: from mail.cdn.telstra.com.au (localhost [127.0.0.1]) by mailbi.ntcif.telstra.com.au (Postfix) with ESMTP id 69C69FFBA for <[e-mail]>; Fri,  6 Mar 2009 11:37:11 +1100 (EST)
Received: from WSMSG3701.srv.dir.telstra.com (wsmsg3701.srv.dir.telstra.com [172.49.40.169]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id LAA29012 for <[e-mail]>; Fri, 6 Mar 2009 11:37:10 +1100 (EST)
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3701.srv.dir.telstra.com ([172.49.40.169]) with mapi; Fri, 6 Mar 2009 11:37:10 +1100
From: "Manger, James H" <[e-mail]>
To: "[e-mail]" <[e-mail]>
Date: Fri, 6 Mar 2009 11:37:09 +1100
Subject: RE: I-D Action:draft-ietf-pkix-other-certs-02.txt
Thread-Topic: I-D Action:draft-ietf-pkix-other-certs-02.txt
Thread-Index: AcmdsUjNkKfUIEA9R6mKhdfOjLJr/QAOh+sg
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
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>

ZHJhZnQtaWV0Zi1wa2l4LW90aGVyLWNlcnRzLTAyLnR4dCBhbGxvd3MgYSBjZXJ0IHRvIHJlZmVy
ZW5jZSBhbnkgbnVtYmVyIG9mIG90aGVyIGNlcnRzLg0KDQpUaGUgY2VydCBhbmQgdGhlIG90aGVy
IGNlcnRzIHdpbGwgb2Z0ZW4gYmUgaXNzdWVkIGJ5IHRoZSBzYW1lIENBLiBJdCB3b3VsZCBiZSBu
aWNlIGlmIHRoZSBDQSdzIEROIGRpZG4ndCBoYXZlIHRvIGJlIHJlcGVhdGVkIGZvciBldmVyeSBv
dGhlciBjZXJ0LiBGb3IgaW5zdGFuY2UsIHJlZmVyIHRvIGVhY2ggb3RoZXIgY2VydCBieTogY2Vy
dCBoYXNoLCBjZXJ0IHNlcmlhbCBudW1iZXIsIGFuZCBhbiBvcHRpb25hbCBpc3N1ZXIgRE4uIFdo
ZW4gdGhlIGlzc3VlciBETiBpcyBhYnNlbnQgZnJvbSBhIHJlZmVyZW5jZSB1c2UgdGhlIGlzc3Vl
ciBETiBmcm9tIHRoZSBjZXJ0aWZpY2F0ZSAob3IgdGhlIHByZXZpb3VzIHJlZmVyZW5jZSkuDQoN
ClRoZSBpc3N1ZXIgRE4gaW4gYSByZWZlcmVuY2UgaXMgaGVsZCBpbiBhIFNFUVVFTkNFIE9GIEdl
bmVyYWxOYW1lLiBJdCB3b3VsZCBiZSB0ZW1wdGluZyB0byB0cmVhdCBhbiBlbXB0eSBzZXF1ZW5j
ZSBhcyBtZWFuaW5nIHVzZSB0aGUgY2VydCBETi4gVGhlIGhhc3NsZSBpcyB0aGFuIHRoZSBzZXF1
ZW5jZSAoR2VuZXJhbE5hbWVzKSBpcyBkZWZpbmVkIHdpdGggYSBTSVpFICgxLi5NQVgpIGNvbnN0
cmFpbnQuDQoNCklzc3VlciBETnMgYXJlIG9mdGVuIGEgZmV3IGh1bmRyZWQgYnl0ZXMgKDEwJS0y
MCUgb2YgY2VydCksIGJ1dCBwZXJoYXBzIGF2b2lkaW5nIGR1cGxpY2F0aW9uIGlzbid0IHdvcnRo
IGFkZGluZyBhbnkgY29tcGxleGl0eSBmb3IuDQoNCg0KSmFtZXMgTWFuZ2VyDQoNCg0KLS0tLS0t
LS0tLQ0KRnJvbTogb3duZXItaWV0Zi1wa2l4QG1haWwuaW1jLm9yZyBbbWFpbHRvOm93bmVyLWll
dGYtcGtpeEBtYWlsLmltYy5vcmddIE9uIEJlaGFsZiBPZiBTdGVwaGVuIEZhcnJlbGwNClNlbnQ6
IEZyaWRheSwgNiBNYXJjaCAyMDA5IDI6NDggQU0NClRvOiBpZXRmLXBraXhAaW1jLm9yZw0KU3Vi
amVjdDogUmU6IEktRCBBY3Rpb246ZHJhZnQtaWV0Zi1wa2l4LW90aGVyLWNlcnRzLTAyLnR4dA0K
DQo+IAlUaXRsZSAgICAgICAgICAgOiBPdGhlciBDZXJ0aWZpY2F0ZXMgRXh0ZW5zaW9uDQo+IAlB
dXRob3IocykgICAgICAgOiBTLiBGYXJyZWxsDQo+IAlGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1p
ZXRmLXBraXgtb3RoZXItY2VydHMtMDIudHh0DQo+IAlQYWdlcyAgICAgICAgICAgOiA4DQo+IAlE
YXRlICAgICAgICAgICAgOiAyMDA5LTAzLTA1DQo+IA0KPiBodHRwOi8vd3d3LmlldGYub3JnL2lu
dGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLXBraXgtb3RoZXItY2VydHMtMDIudHh0DQo=



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 n25MtjVU043739 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Mar 2009 15:55:45 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n25MtjuP043738; Thu, 5 Mar 2009 15:55:45 -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 n25MtYnu043729 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 5 Mar 2009 15:55: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 n25MtTKq027252 for <[e-mail]>; Thu, 5 Mar 2009 17:55:30 -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 n25MtIBH000885 for <[e-mail]>; Thu, 5 Mar 2009 17:55:19 -0500
Message-ID: <[e-mail]>
Date: Thu, 05 Mar 2009 17:55:18 -0500
From: "David A. Cooper" <[e-mail]>
User-Agent: Thunderbird 2.0.0.19 (X11/20090114)
MIME-Version: 1.0
To: pkix <[e-mail]>
Subject: Need help finding implementations of certain RFC 5280 features
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>

All,

I have been asked to work on finding two independent implementations of 
every feature in RFC 5280 in order to support the process of advancing 
RFC 5280 to Draft Standard.  I have been fairly successful so far, but 
there are a lot of features in RFC 5280 that need to be covered.  So, 
this will likely be the first of many emails requesting help in finding 
implementations of certain features.

So, please let me know if you are aware of any certificates that satisfy 
either of the following requirements:

1) From Section 4.2.1.4 (Certificate Policies):

      An explicitText field includes the textual statement directly in
      the certificate.  The explicitText field is a string with a
      maximum size of 200 characters.  Conforming CAs SHOULD use the
      UTF8String encoding for explicitText, but MAY use IA5String.
      Conforming CAs MUST NOT encode explicitText as VisibleString or
      BMPString.  The explicitText string SHOULD NOT include any control
      characters (e.g., U+0000 to U+001F and U+007F to U+009F).  When
      the UTF8String encoding is used, all character sequences SHOULD be
      normalized according to Unicode normalization form C (NFC) [NFC].

I have found several certificates that include a userNotice policy 
qualifier with explicitText, but every one of them encodes the 
explicitText as VisibleString.

2) From Section 4.2.2.1 (Authority Information Access):

   HTTP server implementations accessed via the URI SHOULD specify the
   media type application/pkix-cert [RFC2585] in the content-type header
   field of the response for a single DER encoded certificate....

I have found several certificates that include an AIA extension with an 
id-ad-caIssuers access method with an HTTP URI that points to a single 
certificate, but none of the HTTP servers specify the media type as 
application/pkix-cert.  Most specify the media type as 
application/x-x509-ca-cert and a few specify the media type as text/plain.


Thanks in advance for any help you can give me locating certificates 
(and HTTP servers) that can be used to demonstrate the existence of 
implementations of these features.

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 n25HUwCo028088 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Mar 2009 10:30:58 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n25HUwPx028087; Thu, 5 Mar 2009 10:30:58 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n25HUlEl028070 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for <[e-mail]>; Thu, 5 Mar 2009 10:30:57 -0700 (MST) (envelope-from [e-mail])
X-IronPort-AV: E=Sophos;i="4.38,308,1233532800";  d="scan'208,217";a="66101184"
Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 05 Mar 2009 17:30:47 +0000
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n25HUlXg007902; Thu, 5 Mar 2009 09:30:47 -0800
Received: from [10.0.1.195] (stealth-10-32-244-66.cisco.com [10.32.244.66]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n25HUkop022894; Thu, 5 Mar 2009 17:30:46 GMT
Cc: [e-mail], [e-mail]
Message-Id: <[e-mail]>
From: max pritikin <[e-mail]>
To: [e-mail]
In-Reply-To: <[e-mail]>
Content-Type: multipart/alternative; boundary=Apple-Mail-32-269006191
Mime-Version: 1.0 (Apple Message framework v930.3)
Subject: Re: I-D Action:draft-ietf-pkix-tamp-01.txt 
Date: Thu, 5 Mar 2009 11:30:43 -0600
References: <[e-mail]>
X-Mailer: Apple Mail (2.930.3)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=16993; t=1236274247; x=1237138247; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20max=20pritikin=20<[e-mail]> |Subject:=20Re=3A=20I-D=20Action=3Adraft-ietf-pkix-tamp-01. txt=20 |Sender:=20; bh=F7Yg0k6ANS9nXeCZK6E5VqlVG3Om3nSofyaiERFiy4g=; b=Z8DAFk1sQfh9tgrelkvqAZx5mgZTLa4t8P4kSlwWKp4Z6TANmg9r71IUZg Pqn8U6TSmwB7BgPzhj7/4DRY+c2U9vbfJR/QtZMFnX+YiEpfAGIDJkKeinmu ua0BrviTUuXBokOS7yGUYF/b56MP/2uo4oTXOvpJcKLlhb+fYeX7E=;
Authentication-Results: sj-dkim-1; header.From=[e-mail]; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); 
Sender: [e-mail]
Precedence: 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-32-269006191
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: 7bit

The following questions concern the [TAMP], [TAF] and [TAMR] drafts  
(versions indicated below). I've been reading these documents to see  
how they line-up or conflict with the IEEE 802.1AR (Device Identity)  
draft that I am the editor for. This perspective colors my comments.

Broadly IEEE 802.1AR concerns itself with the shipping of a device  
complete with an X.509 certificate issued by the manufacturer. This  
may be accompanied by the manufacturer's certificate chain. Storage  
and use of associated private key material are within the module.  
802.1AR defines mechanisms for insertion and management of additional  
identity certificates issued by a local CA.

In this context I think the 802.1AR module is loosely analogous to a  
'trust anchor store' as described in [TAMR, Section 1] combined with  
the Cryptographic Module discussed in [TAMP, Section 1.3.1]. The 'TA  
manager' would use the 802.1AR defined service interface to interact  
with the module; and of course no 802.1AR limitations are made that  
prohibit additional service interface functionalities specific to TAMP  
(or any other management application) are defined.

The use of local CA issued certificates within 802.1AR appears  
consistent with the 'identity trust anchors'. The manufacturer  
installed certificate and certificate chain on the other hand could be  
described as some combination of the 'apex', 'management' and even  
'identity' trust anchors depending on future use. This is where my  
questions about these drafts arise. I'm like to know more about how  
you envision pre-installed credentials being catagorized.

On the subject of categorization reading these document has raised the  
following questions for me:

The latest [TAF] document appear to move away from specifically  
categorizing Apex, Management and Identity trust anchors. I agree with  
this change. The [TAMP] draft still indicates these three types though  
and I no longer see how they are distinguished. I do see that [TAMP,  
Section 1.3.2] indicates that:
    o  The trust anchor store MUST support the secure storage of exactly
       one apex trust anchor.  The trust anchor store SHOULD support the
       secure storage of at least one additional trust anchor.
but not how it is identified as the Apex. Or as a management trust  
anchor, or identity trust anchor. Is it expected that this information  
would be encoded into the TAF extensions field[s]? For example TAMP  
would specify a specific extension with these types indicated?

(I continue to be unsure how to relate this to the 802.1AR concepts of  
an 'initial device identity' installed during manufacturing vs a  
'local device identity' installed later.  But if these types are TAMP  
specific vs TAF specific perhaps that is less of a concern.)

I like the idea of a TAF which can store information specific to  
particular applications, various management protocols such as CMS, and  
other things moving forward. TAMP apparently then specifies specific  
authorizations and their meanings but this doesn't limit or impact  
other uses? And importantly this type of construct results in a TAF  
which may be either Apex, Management, or Identity or any combination  
thereof including new types in the future?

This line of thought leads to some reflection on the [TAMP] discussion  
illustrated by Figure 4-1 might be even further refined. I appreciate  
the update from "Crypto Module" to "Trust Anchor Store" -- or maybe  
even a combination of the two of them (this echoes my comment above  
about how the 802.1AR module sounds like a combination of both of  
these elements). Perhaps my confusion is that in my mind a Trust  
Anchor Manager is communicating via TAMP with a TAMP service which is  
then accessing the Trust Anchor Store. A picture is worth a thousand  
words:

(my apologies if mail messes this up)
       +---------+      +----------+
       |         |      |          |
       |         |      |          |
       |         |      |          |
       |         | TAMP |          |
       | Trust   |<---->| TAMP     |
       | Anchor  |      | Process  | OS & Application
       | Manager |      |          | Service Interface
       |         |      |          |      +----------+
       |         |      |          |<---->|TAFs in a |
       |         |      |          |      |Crypto    |
       |         |      |          |      |Module    |
       |         |      |          |      |& Store   |
       +---------+      +----------+      +----------+

I haven't seen a discussion that the "OS & Application Service  
Interface" as being in scope. Drawing the diagram like this clarifies  
my impression that the TAF might be used by other applications and  
that those applications might benefit from the TAF standardization.  
Given the recent changes to [TAF] I suspect things are moving in this  
direction?

Thanks for any clarifications,

- Max Pritikin

referenced documents:
[TAF] draft-ietf-pkix-ta-format-01
[TAMP] draft-ietf-pkix-tamp-01
[TAMR] draft-ietf-pkix-ta-mgmt-reqs-02



On Mar 4, 2009, at 10:15 AM, [e-mail] wrote:

> A New Internet-Draft is available from the on-line Internet-Drafts  
> directories.
> This draft is a work item of the Public-Key Infrastructure (X.509)  
> Working Group of the IETF.
>
>
> 	Title           : Trust Anchor Management Protocol (TAMP)
> 	Author(s)       : R. Housley, et al.
> 	Filename        : draft-ietf-pkix-tamp-01.txt
> 	Pages           : 84
> 	Date            : 2009-03-04
>
> This document describes a transport independent protocol for the
> management of trust anchors and community identifiers stored in a
> trust anchor store.  The protocol makes use of the Cryptographic
> Message Syntax (CMS), and a digital signature is used to provide
> integrity protection and data origin authentication.  The protocol
> can be used to manage trust anchor stores containing trust anchors
> represented as Certificate, TBSCertificate or TrustAnchorInfo
> objects.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-tamp-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.
> <mime-attachment>


--Apple-Mail-32-269006191
Content-Type: text/html;
	charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

<html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; "><div>The following questions =
concern the [TAMP], [TAF] and [TAMR] drafts (versions indicated below). =
I've been reading these documents to see how they line-up or conflict =
with the IEEE 802.1AR (Device Identity) draft that I am the editor for. =
This perspective colors my =
comments.&nbsp;</div><div><br></div><div>Broadly IEEE 802.1AR concerns =
itself with the shipping of a device complete with an X.509 certificate =
issued by the manufacturer. This may be accompanied by the =
manufacturer's certificate chain. Storage and use of associated private =
key material are within the module. 802.1AR defines mechanisms for =
insertion and management of additional identity certificates issued by a =
local CA.&nbsp;</div><div><br></div><div>In this context I think the =
802.1AR module is loosely analogous to a 'trust anchor store' as =
described in [TAMR, Section 1] combined with the Cryptographic Module =
discussed in [TAMP, Section 1.3.1]. The 'TA manager' would use the =
802.1AR defined service interface to interact with the module; and of =
course no 802.1AR limitations are made that prohibit additional service =
interface functionalities specific to TAMP (or any other management =
application) are defined.&nbsp;</div><div><br></div><div>The use of =
local CA issued certificates within 802.1AR appears consistent with the =
'identity trust anchors'. The manufacturer installed certificate and =
certificate chain on the other hand could be described as some =
combination of the 'apex', 'management' and even 'identity' trust =
anchors depending on future use. This is where my questions about these =
drafts arise. I'm like to know more about how you envision pre-installed =
credentials being catagorized.</div><div><br></div><div>On the subject =
of&nbsp;categorization&nbsp;reading these document has raised the =
following questions for me:</div><div><br></div><div>The latest [TAF] =
document appear to move away from specifically categorizing Apex, =
Management and Identity trust anchors. I agree with this change. The =
[TAMP] draft still indicates these three types though and I no longer =
see how they are distinguished. I do see that [TAMP, Section 1.3.2] =
indicates that:</div><div>&nbsp;&nbsp; o &nbsp;The trust anchor store =
MUST support the secure storage of exactly</div><div>&nbsp;&nbsp; &nbsp; =
&nbsp;one apex trust anchor. &nbsp;The trust anchor store SHOULD support =
the</div><div>&nbsp;&nbsp; &nbsp; &nbsp;secure storage of at least one =
additional trust anchor.&nbsp;</div><div>but not how it is identified as =
the Apex. Or as a management trust anchor, or identity trust anchor. Is =
it expected that this information would be encoded into the TAF =
extensions field[s]? For example TAMP would specify a specific extension =
with these types indicated?</div><div><br></div><div>(I continue to be =
unsure how to relate this to the 802.1AR concepts of an 'initial device =
identity' installed during manufacturing vs a 'local device identity' =
installed later. &nbsp;But if these types are TAMP specific vs TAF =
specific perhaps that is less of a concern.)</div><div><br></div><div>I =
like the idea of a TAF which can store information specific to =
particular applications, various management protocols such as CMS, and =
other things moving forward. TAMP apparently then specifies specific =
authorizations and their meanings but this doesn't limit or impact other =
uses? And importantly this type of construct results in a TAF which may =
be either Apex, Management, or Identity or any combination thereof =
including new types in the future?</div><div><br></div><div>This line of =
thought leads to some reflection on the [TAMP] discussion illustrated by =
Figure 4-1 might be even further refined. I appreciate the update from =
"Crypto Module" to "Trust Anchor Store" -- or maybe even a combination =
of the two of them (this echoes my comment above about how the 802.1AR =
module sounds like a combination of both of these elements). Perhaps my =
confusion is that in my mind a Trust Anchor Manager is communicating via =
TAMP with a TAMP service which is then accessing the Trust Anchor Store. =
A picture is worth a thousand words:</div><div><br></div><div>(my =
apologies if mail messes this up)</div><div><font =
class=3D"Apple-style-span" face=3D"Courier">&nbsp;&nbsp; &nbsp; =
&nbsp;+---------+ &nbsp; &nbsp; =
&nbsp;+----------+</font></div><div><font class=3D"Apple-style-span" =
face=3D"Courier">&nbsp;&nbsp; &nbsp; &nbsp;| &nbsp; &nbsp; &nbsp; &nbsp; =
| &nbsp; &nbsp; &nbsp;| &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp;|</font></div><div><font class=3D"Apple-style-span" =
face=3D"Courier">&nbsp;&nbsp; &nbsp; &nbsp;| &nbsp; &nbsp; &nbsp; &nbsp; =
| &nbsp; &nbsp; &nbsp;| &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp;|</font></div><div><font class=3D"Apple-style-span" =
face=3D"Courier">&nbsp;&nbsp; &nbsp; &nbsp;| &nbsp; &nbsp; &nbsp; &nbsp; =
| &nbsp; &nbsp; &nbsp;| &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp;|</font></div><div><font class=3D"Apple-style-span" =
face=3D"Courier">&nbsp;&nbsp; &nbsp; &nbsp;| &nbsp; &nbsp; &nbsp; &nbsp; =
| TAMP | &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;|</font></div><div><font =
class=3D"Apple-style-span" face=3D"Courier">&nbsp;&nbsp; &nbsp; &nbsp;| =
Trust &nbsp; |&lt;---->| TAMP &nbsp; &nbsp; |</font></div><div><font =
class=3D"Apple-style-span" face=3D"Courier">&nbsp;&nbsp; &nbsp; &nbsp;| =
Anchor &nbsp;| &nbsp; &nbsp; &nbsp;| Process &nbsp;| OS &amp; =
Application</font></div><div><font class=3D"Apple-style-span" =
face=3D"Courier">&nbsp;&nbsp; &nbsp; &nbsp;| Manager | &nbsp; &nbsp; =
&nbsp;| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;| Service =
Interface</font></div><div><font class=3D"Apple-style-span" =
face=3D"Courier">&nbsp;&nbsp; &nbsp; &nbsp;| &nbsp; &nbsp; &nbsp; &nbsp; =
| &nbsp; &nbsp; &nbsp;| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;| &nbsp; =
&nbsp; &nbsp;+----------+</font></div><div><font =
class=3D"Apple-style-span" face=3D"Courier">&nbsp;&nbsp; &nbsp; &nbsp;| =
&nbsp; &nbsp; &nbsp; &nbsp; | &nbsp; &nbsp; &nbsp;| &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp;|&lt;---->|TAFs in a |</font></div><div><font =
class=3D"Apple-style-span" face=3D"Courier">&nbsp;&nbsp; &nbsp; &nbsp;| =
&nbsp; &nbsp; &nbsp; &nbsp; | &nbsp; &nbsp; &nbsp;| &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp;| &nbsp; &nbsp; &nbsp;|Crypto &nbsp; =
&nbsp;|</font></div><div><font class=3D"Apple-style-span" =
face=3D"Courier">&nbsp;&nbsp; &nbsp; &nbsp;| &nbsp; &nbsp; &nbsp; &nbsp; =
| &nbsp; &nbsp; &nbsp;| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;| &nbsp; =
&nbsp; &nbsp;|Module &nbsp; &nbsp;|</font></div><div><font =
class=3D"Apple-style-span" face=3D"Courier">&nbsp;&nbsp; &nbsp; &nbsp;| =
&nbsp; &nbsp; &nbsp; &nbsp; | &nbsp; &nbsp; &nbsp;| &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp;| &nbsp; &nbsp; &nbsp;|&amp; Store &nbsp; =
|</font></div><div><font class=3D"Apple-style-span" =
face=3D"Courier">&nbsp;&nbsp; &nbsp; &nbsp;+---------+ &nbsp; &nbsp; =
&nbsp;+----------+ &nbsp; &nbsp; =
&nbsp;+----------+</font></div><div><br></div><div>I haven't seen a =
discussion that the "OS &amp; Application Service Interface" as being in =
scope. Drawing the diagram like this clarifies my impression that the =
TAF might be used by other applications and that those applications =
might benefit from the TAF standardization. Given the recent changes to =
[TAF] I suspect things are moving in this =
direction?</div><div><br></div><div>Thanks for any =
clarifications,</div><div><br></div><div>- Max =
Pritikin</div><div><br></div><div>referenced documents:</div><div>[TAF] =
draft-ietf-pkix-ta-format-01</div><div>[TAMP] =
draft-ietf-pkix-tamp-01</div><div>[TAMR] =
draft-ietf-pkix-ta-mgmt-reqs-02</div><div><br></div><br><div><div><br></di=
v><div>On Mar 4, 2009, at 10:15 AM, <a =
href=3D"mailto:[e-mail]">[e-mail]</a> =
wrote:</div><br><blockquote type=3D"cite"><div>A New Internet-Draft is =
available from the on-line Internet-Drafts directories.<br>This draft is =
a work item of the Public-Key Infrastructure (X.509) Working Group of =
the IETF.<br><br><br><span class=3D"Apple-tab-span" =
style=3D"white-space:pre">	</span>Title =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;: Trust =
Anchor Management Protocol (TAMP)<br><span class=3D"Apple-tab-span" =
style=3D"white-space:pre">	</span>Author(s) =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;: R. Housley, et al.<br><span =
class=3D"Apple-tab-span" style=3D"white-space:pre">	</span>Filename =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;: =
draft-ietf-pkix-tamp-01.txt<br><span class=3D"Apple-tab-span" =
style=3D"white-space:pre">	</span>Pages =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;: =
84<br><span class=3D"Apple-tab-span" style=3D"white-space:pre">	=
</span>Date =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;: =
2009-03-04<br><br>This document describes a transport independent =
protocol for the<br>management of trust anchors and community =
identifiers stored in a<br>trust anchor store. &nbsp;The protocol makes =
use of the Cryptographic<br>Message Syntax (CMS), and a digital =
signature is used to provide<br>integrity protection and data origin =
authentication. &nbsp;The protocol<br>can be used to manage trust anchor =
stores containing trust anchors<br>represented as Certificate, =
TBSCertificate or TrustAnchorInfo<br>objects.<br><br>A URL for this =
Internet-Draft is:<br><a =
href=3D"http://www.ietf.org/internet-drafts/draft-ietf-pkix-tamp-01.txt">h=
ttp://www.ietf.org/internet-drafts/draft-ietf-pkix-tamp-01.txt</a><br><br>=
Internet-Drafts are also available by anonymous FTP =
at:<br>ftp://ftp.ietf.org/internet-drafts/<br><br>Below is the data =
which will enable a MIME compliant mail reader<br>implementation to =
automatically retrieve the ASCII version of =
the<br>Internet-Draft.<br><span =
id=3D"cid:[e-mail]">&lt;mime-attachm=
ent></span></div></blockquote></div><br></body></html>=

--Apple-Mail-32-269006191--



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 n25H6CFD026334 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Mar 2009 10:06:12 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n25H6CN2026333; Thu, 5 Mar 2009 10:06:12 -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 n25H61Rt026321 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL) for <[e-mail]>; Thu, 5 Mar 2009 10:06:11 -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-7.04 (built Sep 26 2008; 32bit)) id <[e-mail]> for [e-mail]; Thu, 05 Mar 2009 11:05:52 -0600 (CST)
Received: from [192.168.0.14] (97-92-189-144.dhcp.mdsn.wi.charter.com [97.92.189.144]) by smtpauth2.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <[e-mail]> for [e-mail]; Thu, 05 Mar 2009 11:05:45 -0600 (CST)
Date: Thu, 05 Mar 2009 11:05:44 -0600
From: Eric Norman <[e-mail]>
Subject: Re: I-D Action:draft-ietf-pkix-ta-format-01.txt
In-reply-to: <[e-mail]>
To: [e-mail]
Message-id: <[e-mail]>
X-Mailer: Apple Mail (2.624)
X-Spam-Report: AuthenticatedSender=yes, SenderIP=192.168.0.14
X-Spam-PmxInfo: Server=avs-9, Version=5.5.1.360522, Antispam-Engine: 2.6.1.350677, Antispam-Data: 2009.3.5.164921, SenderIP=192.168.0.14
References: <[e-mail]> <[e-mail]> <[e-mail]> <[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>

On Mar 5, 2009, at 9:46 AM, Carl Wallace wrote:

> Trust in the key is established by external means, i.e., manual check 
> or
> TAMP message verification.  DNs are generally not small.  The taName is
> optional to allow omission in situations where they are not used.  Why
> should a name be required since not all uses require a name?

Why not make a clear distinction between usage and inclusion?  If
information like a DN MUST be included in some structure, I don't
see why that implies that it MUST be used.  The part of the standard
that specifies usage can say that such information MUST or MAY be
ignored.

It seems to me that failing to make a clear distinction is getting
dangerously close to creating a situation where a creator of a
trust anchor will be required to prepare different structures
depending on usage.  I.e. there will be more structures flying
around.  Is this really a situation that y'all want?  Won't this
just lead to more confusion and more interoperability problems?

Personally, I don't see why trust anchors can't be specified with
the same format as X.509 certificates along with the proviso that
some components (like issuer, serial number, etc) may be ignored
in the validation algorithm.

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 n25H5eOO026310 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Mar 2009 10:05:40 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n25H5e9R026309; Thu, 5 Mar 2009 10:05:40 -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 n25H5dNH026303 for <[e-mail]>; Thu, 5 Mar 2009 10:05:39 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 22747 invoked from network); 5 Mar 2009 17:05:14 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 5 Mar 2009 17:05:14 -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: I-D Action:draft-ietf-pkix-ta-format-01.txt
Date: Thu, 5 Mar 2009 12:05:38 -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-format-01.txt
Thread-Index: AcmdtArscviU1YTbSLO/59n7srQuEAAAHPNQ
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Carl Wallace" <[e-mail]>
To: "Julien Stern" <[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>

> > There are two means of implementing this with the current=20
> spec.  The=20
> > taTitle field can identify the TA using a string value.
>=20
> True. But if I do want to put a DN in there, I will bump into=20
> all the infamous Printable/BMP/UTF-8/etc encoding issues :)
>=20
>  > A subjectAltName extension could be included with any form=20
> of GeneralName.
> > Neither of these would enable path validation.
>=20
> Also true, but no-one else will understand this extension as=20
> no standard=20
> extension are defined in the draft. It will likely be mostly=20
> a "private"=20
> extension.

This can be clarified in the draft.=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 n25H1ZVw026024 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Mar 2009 10:01:35 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n25H1Zri026023; Thu, 5 Mar 2009 10:01:35 -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-104-thursday.nerim.net [62.4.16.104]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n25H1YUk026016 for <[e-mail]>; Thu, 5 Mar 2009 10:01:35 -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 5BE67CFBAC; Thu,  5 Mar 2009 18:01:33 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by uranus.cry.pto (Postfix) with ESMTP id 6B35B440F5; Thu,  5 Mar 2009 18:01:33 +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 KB7yxXVTl3ml; Thu,  5 Mar 2009 18:01:30 +0100 (CET)
Received: from [10.0.1.30] (leda.cry.pto [10.0.1.30]) by uranus.cry.pto (Postfix) with ESMTP id E7736440AF; Thu,  5 Mar 2009 18:01:29 +0100 (CET)
Message-ID: <[e-mail]>
Date: Thu, 05 Mar 2009 18:01:29 +0100
From: Julien Stern <[e-mail]>
User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103)
MIME-Version: 1.0
To: Carl Wallace <[e-mail]>
Cc: Tom Gindin <[e-mail]>, [e-mail]
Subject: Re: I-D Action:draft-ietf-pkix-ta-format-01.txt
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[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>

Carl Wallace wrote:
> <snip>
>> To sum things up:
>>
>> 1) It still believe that mandating the inclusion of the 
>> identity of the 
>> private key owner in one way or an other (possibly not a DN) 
>> would be nice.
>> 2) If everyone thinks that this identity can be omitted if 
>> implicit from 
>> the context, well, fine. A short paragraph explaining that 
>> could be nice.
> 
> Adding a paragraph to clarify this seems reasonable to me.
> 
>> 3) Providing a way to provide this identity (possibly under various 
>> forms: string, DN, etc) _without_ necessarily linking the presence of 
>> the DN to the fact that this TA can be used for X.509 
>> validation would 
>> certainly also be nice.

> There are two means of implementing this with the current spec.  The
> taTitle field can identify the TA using a string value.

True. But if I do want to put a DN in there, I will bump into all the 
infamous Printable/BMP/UTF-8/etc encoding issues :)

 > A subjectAltName extension could be included with any form of 
GeneralName.
> Neither of these would enable path validation.

Also true, but no-one else will understand this extension as no standard 
extension are defined in the draft. It will likely be mostly a "private" 
extension.



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 n25GlXnV025196 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Mar 2009 09:47:33 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n25GlXOD025195; Thu, 5 Mar 2009 09:47:33 -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 n25GlMp9025180 for <[e-mail]>; Thu, 5 Mar 2009 09:47:32 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 22462 invoked from network); 5 Mar 2009 16:46:57 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 5 Mar 2009 16:46:57 -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: I-D Action:draft-ietf-pkix-ta-format-01.txt
Date: Thu, 5 Mar 2009 11:47:21 -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-format-01.txt
Thread-Index: Acmdr++IDSjJ6KxsSkaAQIhRZJu4BAAAU5Ag
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Carl Wallace" <[e-mail]>
To: "Julien Stern" <[e-mail]>
Cc: "Tom Gindin" <[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>

<snip>
> To sum things up:
>=20
> 1) It still believe that mandating the inclusion of the=20
> identity of the=20
> private key owner in one way or an other (possibly not a DN)=20
> would be nice.
> 2) If everyone thinks that this identity can be omitted if=20
> implicit from=20
> the context, well, fine. A short paragraph explaining that=20
> could be nice.

Adding a paragraph to clarify this seems reasonable to me.

> 3) Providing a way to provide this identity (possibly under various=20
> forms: string, DN, etc) _without_ necessarily linking the presence of=20
> the DN to the fact that this TA can be used for X.509=20
> validation would=20
> certainly also be nice.

There are two means of implementing this with the current spec.  The
taTitle field can identify the TA using a string value.  A
subjectAltName extension could be included with any form of GeneralName.
Neither of these would enable path validation.



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 n25GjEYP025047 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Mar 2009 09:45:14 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n25GjEUW025046; Thu, 5 Mar 2009 09:45:14 -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-118-thursday.nerim.net [62.4.16.118]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n25Gj37u025025 for <[e-mail]>; Thu, 5 Mar 2009 09:45:14 -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 3CCD0B9738; Thu,  5 Mar 2009 17:45:02 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by uranus.cry.pto (Postfix) with ESMTP id 2EA09440F5; Thu,  5 Mar 2009 17:45:02 +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 GGBkhTBlLFnJ; Thu,  5 Mar 2009 17:44:54 +0100 (CET)
Received: from [10.0.1.30] (leda.cry.pto [10.0.1.30]) by uranus.cry.pto (Postfix) with ESMTP id 2974B440AF; Thu,  5 Mar 2009 17:44:54 +0100 (CET)
Message-ID: <[e-mail]>
Date: Thu, 05 Mar 2009 17:44:54 +0100
From: Julien Stern <[e-mail]>
User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103)
MIME-Version: 1.0
To: Russ Housley <[e-mail]>
Cc: [e-mail]
Subject: Re: I-D Action:draft-ietf-pkix-ta-format-01.txt
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>

Russ Housley wrote:
> 
> Julien:
> 
>> I fully share your view that the "other policy information" should 
>> only be an optional part of the trust anchor. However, I feel that the 
>> name is a fundamental part of the trust anchor. A trust anchor without 
>> a name, in my opinion, would be like a certificate without a name.
> 
> I have no objection to the taName becoming a mandatory element of the 
> structure.  It is certainly needed for certification path construction 
> and validation.  However, in the TAMP context, there are messages that 
> are signed directly by the trust anchor.  In this case, a key identifier 
> without a name is sufficient.  This element is optional to allow for a 
> trust anchor that is able to sign such messages but not allowed to sign 
> certificates.  So, if the taName becomes non-optional, another mechanism 
> is needed to indicate whether the trust anchor can sign certificates.

Russ,

As explained into more details in my reply to Carl, my understanding 
from the draft was;

1) the identity of the private key owner is optional
2) the taName can optionally be used to identity him in a X.500 context

I am in disagreement with 1). I still think that a TA without a name 
(whichever its form, DN or not) would be like a certificate without a 
name. However, I seem to be the only one, so I'll stop.

Now, from what you say, I understand that if I put a DN, it will _also_ 
mean that this TA can be used for X.509 validation.

Isn't it a limitation to combine the identification of the owner with a 
DN and the authorization to perform X.509 validation with this TA?

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 n25GXnkJ024305 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Mar 2009 09:33:49 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n25GXndd024304; Thu, 5 Mar 2009 09:33:49 -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 n25GXbqx024291 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 5 Mar 2009 09:33:48 -0700 (MST) (envelope-from [e-mail])
Received: from dhcp89-089-198.bbn.com ([128.89.89.198] helo=[10.71.0.129]) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from <[e-mail]>) id 1LfGVs-00054E-Be; Thu, 05 Mar 2009 11:33:36 -0500
Mime-Version: 1.0
Message-Id: <p06240809c5d59ee584f0@[10.71.0.129]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Date: Thu, 5 Mar 2009 11:31:15 -0500
To: Julien Stern <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: I-D Action:draft-ietf-pkix-ta-format-01.txt
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 7:43 PM +0100 3/4/09, Julien Stern wrote:
>[e-mail] wrote:
>>A New Internet-Draft is available from the on-line Internet-Drafts 
>>directories.
>>This draft is a work item of the Public-Key Infrastructure (X.509) 
>>Working Group of the IETF.
>>
>>
>>	Title           : Trust Anchor Format
>>	Author(s)       : R. Housley, et al.
>>	Filename        : draft-ietf-pkix-ta-format-01.txt
>>	Pages           : 17
>>	Date            : 2009-03-04
>>
>
>Hi again,
>
>separating from the previous email due to the nature of the comment: 
>this one is more "philosophical" :)
>
>This draft defines a trust anchor as a public key with additional data.
>
>I believe that the most common usage of the word "trust anchor" 
>denotes the _binding_ of a public key _and_ a name. A certificate 
>binds a name and a public key (along with other information) thanks 
>to a signature. A trust anchor binds them through direct trust.

A PKC, especially a v3 PKC, contains a number of attributes, of which 
name is often viewed as the most important. But not all PKIs view the 
subject name as the most important attribute, e.g., in the RPKI 
developed in the SIDR WG, the RFC 3779 extension are arguably the 
most important attributes. We have adopted this TA format for that 
work. So I think the current wording is appropriate.

In large part, motivation for not requiring a (subject) DN arises 
because of the intent to use this TA representation in the context of 
device management, where a key (but not a self-signed cert) makes 
sense.

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 n25GWKRT024191 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Mar 2009 09: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 n25GWKip024190; Thu, 5 Mar 2009 09: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 kraid.nerim.net (smtp-104-thursday.nerim.net [62.4.16.104]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n25GW8lq024172 for <[e-mail]>; Thu, 5 Mar 2009 09:32:19 -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 7FA6DCFB7B; Thu,  5 Mar 2009 17:32:07 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by uranus.cry.pto (Postfix) with ESMTP id 56F9F440AF; Thu,  5 Mar 2009 17:32:07 +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 MvyiU2flsKje; Thu,  5 Mar 2009 17:32:02 +0100 (CET)
Received: from [10.0.1.30] (leda.cry.pto [10.0.1.30]) by uranus.cry.pto (Postfix) with ESMTP id 0E396440F5; Thu,  5 Mar 2009 17:32:02 +0100 (CET)
Message-ID: <[e-mail]>
Date: Thu, 05 Mar 2009 17:32:01 +0100
From: Julien Stern <[e-mail]>
User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103)
MIME-Version: 1.0
To: Carl Wallace <[e-mail]>
Cc: Tom Gindin <[e-mail]>, [e-mail]
Subject: Re: I-D Action:draft-ietf-pkix-ta-format-01.txt
References: <[e-mail]> <[e-mail]> <[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>

Inline...

Carl Wallace wrote:
> Inline... 
> 
>> -----Original Message-----
>> From: Julien Stern [mailto:[e-mail]] 
>> Sent: Thursday, March 05, 2009 10:10 AM
>> To: Carl Wallace
>> Cc: Tom Gindin; [e-mail]
>> Subject: Re: I-D Action:draft-ietf-pkix-ta-format-01.txt
>>
>> Carl,
>>
>> Thanks for your reply.
>> I'm starting to see some of the rationale better.
>>
>> What still slightly bothers me is the following:
>>
>> I keep on thinking it would bring major confusion to say that 
>> a trust anchor can be reduced to a public key. A trust anchor 
>> has to be an _identified_ public key, else it's just... 
>> well... a public key.
> 
> A TA is a public key and some constraints on its usage.  As referenced
> in this thread, a DN is just one form of constraint.

Carl,

While I do agree with a lot of what you say, I just cannot agree with 
this :) A TA is not just a public key possibly with constraints of 
usage. A public key can be "promoted" to a TA if you KNOWN and TRUST the 
entity controlling the corresponding public key. Now this "promotion" 
can be explicit (you click on something) or implicit (you receive some 
hardware device with the manufacturer key embedded). But whether 
implicit or explicit, the fact you known the identity of the private key 
owner (and that you trust it) is what differentiates a public key from a TA.

If you do not believe that the identity of the private key owner is a 
fundamental part of a TA, then we have a strong disagreement.

Otherwise, we probably only have a very minor disagreement.
- You say that this identity can be omitted from the TA information and 
can be inferred by external means
- I felt that this identity was such a fundamental aspect that it needed 
to be an integral part of the TA information

No big deal, in fact :)

And well, I agree that it you receive a hardware device with an embedded 
public key, the identity of the private key owner (the hardware 
manufacturer most likely) can be implicitly inferred... On the other 
hand, it does not cost so much to embed it.

At any rate, if there is a consensus that this identity can be omitted 
and implicit, let us stop the thread on this aspect.


Now, as regards the DN:
I originally understood it was _the_ way to identity the private key 
owner and that it was optional. Apparently, it serves a dual-purpose:
1) to identify the private key owner
2) to indicate the public key can be used for X.509 validation

One may view this as a limitation: I cannot state the identity of the 
key owner using a DN unless I want to use the public key for X.509 
validation.


To sum things up:

1) It still believe that mandating the inclusion of the identity of the 
private key owner in one way or an other (possibly not a DN) would be nice.
2) If everyone thinks that this identity can be omitted if implicit from 
the context, well, fine. A short paragraph explaining that could be nice.
3) Providing a way to provide this identity (possibly under various 
forms: string, DN, etc) _without_ necessarily linking the presence of 
the DN to the fact that this TA can be used for X.509 validation would 
certainly also be nice.

Regards,

--
Julien

>> Now, I feel I'm starting to understand why the keyIdentifier 
>> is always mandatory. Maybe you meant to be using this key 
>> identifier as a generic "name" for the key? In which case, we 
>> do have a difference between a public key and a trust anchor, 
>> e.g. the key is "identified". However, this keyIdentifier is 
>> usually directly inferred from the public key, so this 
>> "identification" is a weak one at best.
>>
>> The very beginning of the TA draft says: "A trust anchor is 
>> an authoritative entity represented by a public key and 
>> associated data."
>> The bare minimum currently allowed is the key and the keyIdentifier.
>>
>> I fail to see how the authoritative entity comes into play 
>> here. 
> 
> The authoritative entity associated with the TA comes into play by using
> the private key.  
> 
>> In all the examples you gave below, we may possibly go 
>> through a keyIdentifier instead of a DN to find the public 
>> key used to signing, but it does not make sense to use this 
>> key if it is an "anonymous" key.
> 
> Why?  That some signature schemes use a key identifier instead of a DN
> to locate the public key isn't a problem.  Even 5280 uses key identifier
> more than DN to find a key (where one CA has multiple certs).  The
> important thing is that the TA was obtained in a secure manner.  
> 
>> Maybe, an other way to highlight the difference in our views 
>> is that you assume the "identification" of the key can be 
>> performed by external means? In which case, a trust anchor 
>> could be a public key whose owner happens to be known by 
>> external means or be implicit from the context? 
>> And that I believe the identity of the "authoritative entity" 
>> should be explicitly stated in the TA?
> 
> Trust in the key is established by external means, i.e., manual check or
> TAMP message verification.  DNs are generally not small.  The taName is
> optional to allow omission in situations where they are not used.  Why
> should a name be required since not all uses require a name?   
>> Regards,
>>
>> --
>> Julien
>>
>>
>> Carl Wallace wrote:
>>> Inline...
>>>
>>>> -----Original Message-----
>>>> From: Julien Stern [mailto:[e-mail]]
>>>> Sent: Thursday, March 05, 2009 8:09 AM
>>>> To: Carl Wallace
>>>> Cc: Tom Gindin; [e-mail]
>>>> Subject: Re: I-D Action:draft-ietf-pkix-ta-format-01.txt
>>>>
>>>> Carl,
>>>>
>>>> well, there may be strong "philosophical" disagreements 
>> from yourself 
>>>> and/or Tom of what a trust anchor is (which is fine
>>>> :) ), but could you give an example of an actual use of a trust 
>>>> anchor that do not require an identity?
>>> CMS does not use a DN to identify a signer.  Timestamps, firmware 
>>> packages and key packages are all examples of objects 
>> signed using CMS 
>>> that could be verified using a TA that is not named using a DN but 
>>> identified with a key identifier.  OCSP responses aren't 
>> signed using 
>>> CMS but can also identify a signer using a key identifier 
>> and may be 
>>> validated by a TA.
>>>  
>>>> Again, my humble personal view is that a PKI in general is 
>> before all 
>>>> used to link cryptographic key to identities. This can be done by 
>>>> direct trust (e.g. a trust anchor) or vouched by an other entity 
>>>> (e.g. a certificate). This is why I believe the identity is a 
>>>> fundamental part of a trust anchor.
>>>> Now the fact that this identity should be a DN is not as 
>> fundamental 
>>>> (it could be a string), but considering the global 
>> context, a DN is 
>>>> really what makes senses.
>>> You could choose to use a DN and/or a TA title in all TAs 
>> used in your 
>>> environment.
>>>  
>>>> I read the fact that omission of the taName precludes path 
>> validation 
>>>> (and I naturally concur), but I actually think that 
>> omission of that 
>>>> name precludes _any_ usage of the corresponding public 
>> key, and that 
>>>> therefore the DN should be made mandatory in all cases.
>>> The DN is required by 5280 for name chaining.  A DN is not 
>> required in 
>>> all cases where a TA could be used (see above) so making it 
>> mandatory 
>>> is not desirable.
>>>  
>>>> --
>>>> Julien
>>>>
>>>> Carl Wallace wrote:
>>>>> The draft notes that omission of the taName field precludes path 
>>>>> validation.  Given that TAs serve other purposes that don't
>>>> require DNs,
>>>>> making the field optional makes sense.  All three formats
>>>> in the draft
>>>>> support including a DN.  This allows the 5280 requirement to be
>>>>> satisfied with each structure.   
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: [e-mail] 
>>>>>> [mailto:[e-mail]] On Behalf Of Tom Gindin
>>>>>> Sent: Wednesday, March 04, 2009 8:41 PM
>>>>>> To: Julien Stern
>>>>>> Cc: [e-mail]
>>>>>> Subject: Re: I-D Action:draft-ietf-pkix-ta-format-01.txt
>>>>>>
>>>>>>
>>>>>>         Julian:
>>>>>>
>>>>>>         I think you're wrong in believing that the name 
>> is central 
>>>>>> to the definition of a trust anchor.  I can have (and my browser 
>>>>>> may be shipped
>>>>>> with) several trust anchors issued by the same organization, and 
>>>>>> the names which distinguish them are (to me as the 
>> manager of the 
>>>>>> trust store) quite arbitrary.  A typical example is that 
>> there are 
>>>>>> two separate CA certificates from Entrust with CN="Entrust.net 
>>>>>> Secure Server Certification Authority".  Their OU's are slightly 
>>>>>> different, and one of them has a Country attribute.
>>>>>>         While philosophically I completely disagree with 
>> you, RFC 
>>>>>> 5280 section 6.1.1 point d-1 requires that the trust 
>> anchor have an 
>>>>>> issuer name, as does the same section in 3280.
>>>>>>  Thus, no trust anchor definition which does not include 
>> an issuer 
>>>>>> name can be used by our own existing algorithms.  I 
>> think that's a 
>>>>>> pretty good reason for PKIX to require the presence of a 
>> DN in this 
>>>>>> definition.
>>>>>>
>>>>>>                 Tom Gindin
>>>>>>
>>>>>> P.S. - These views are mine personally, and not 
>> necessarily those 
>>>>>> of my employer
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Julien Stern <[e-mail]> Sent by: 
>>>>>> [e-mail]
>>>>>> 03/04/2009 01:43 PM
>>>>>>
>>>>>> To
>>>>>>
>>>>>> cc
>>>>>> [e-mail]
>>>>>> Subject
>>>>>> Re: I-D Action:draft-ietf-pkix-ta-format-01.txt
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> [e-mail] wrote:
>>>>>>> A New Internet-Draft is available from the on-line
>>>> Internet-Drafts
>>>>>> directories.
>>>>>>> This draft is a work item of the Public-Key
>>>> Infrastructure (X.509)
>>>>>> Working Group of the IETF.
>>>>>>>                Title           : Trust Anchor Format
>>>>>>>                Author(s)       : R. Housley, et al.
>>>>>>>                Filename        : 
>> draft-ietf-pkix-ta-format-01.txt
>>>>>>>                Pages           : 17
>>>>>>>                Date            : 2009-03-04
>>>>>>>
>>>>>> Hi again,
>>>>>>
>>>>>> separating from the previous email due to the nature of
>>>> the comment: 
>>>>>> this one is more "philosophical" :)
>>>>>>
>>>>>> This draft defines a trust anchor as a public key with 
>> additional 
>>>>>> data.
>>>>>>
>>>>>> I believe that the most common usage of the word "trust anchor" 
>>>>>> denotes the _binding_ of a public key _and_ a name. A 
>> certificate 
>>>>>> binds a name and a public key (along with other 
>> information) thanks 
>>>>>> to a signature. A trust anchor binds them through direct trust.
>>>>>>
>>>>>> And indeed, the definition in X.509 is:
>>>>>>
>>>>>> trust anchor: A trust anchor is a set of the following
>>>> information in
>>>>>> addition to the public key: algorithm identifier, public key 
>>>>>> parameters (if applicable), distinguished name of the 
>> holder of the
>>>> associated
>>>>>> private key (i.e., the subject CA) and optionally a validity 
>>>>>> period. The trust anchor may be provided in the form of a 
>>>>>> self-signed
>>>> certificate.
>>>>>> A trust anchor is trusted by a certificate using system
>>>> and used for
>>>>>> validating certificates in certification paths.
>>>>>>
>>>>>>
>>>>>> I assume that you did not choose to make the DN optional without 
>>>>>> reason.
>>>>>> But is that really something that we would like to have? 
>> Are there 
>>>>>> really cases where we want to use a public key without 
>> explicitly 
>>>>>> knowing whom it belongs to? Isn't there a risk to spread
>>>> confusion on
>>>>>> what a "trust anchor" is?
>>>>>>
>>>>>> Granted, this RFC could define a Trust Anchor in a more
>>>> global scope,
>>>>>> without a need to bind it to a DN, but I'm (very
>>>> personally) not sure
>>>>>> this is a great idea and I believe that mandating the 
>> presence of a 
>>>>>> DN would not bring a strong limitation.
>>>>>>
>>>>>> Have you considered moving the taName from the 
>> CertPathControls to 
>>>>>> the main structure (TrustAnchorInfo) and keeping the 
>>>>>> CertPathControls structure for fine tuning of the X.509 input 
>>>>>> algorithm?
>>>>>>
>>>>>> (And along the same lines, why is the KeyIdentifier
>>>> mandatory and not
>>>>>> optional?)
>>>>>>
>>>>>> 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 n25GTosa023979 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Mar 2009 09:29:50 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n25GTogb023978; Thu, 5 Mar 2009 09:29:50 -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.158] (dsl-63-249-108-169.static.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n25GThgE023964 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Mar 2009 09:29:43 -0700 (MST) (envelope-from [e-mail])
Mime-Version: 1.0
Message-Id: <p06240830c5d5ad04ec32@[10.20.30.158]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Thu, 5 Mar 2009 08:29:42 -0800
To: Julien Stern <[e-mail]>, Carl Wallace <[e-mail]>
From: Paul Hoffman <[e-mail]>
Subject: Re: I-D Action:draft-ietf-pkix-ta-format-01.txt
Cc: Tom Gindin <[e-mail]>, [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:09 PM +0100 3/5/09, Julien Stern wrote:
>I keep on thinking it would bring major confusion to say that a trust anchor can be reduced to a public key. A trust anchor has to be an _identified_ public key, else it's just... well... a public key.

A trust anchor is a public key and some policy information related to the key, namely what the relying party can use the trust anchor to validate. That policy information is not the same for all applications, so specifying a single structure for it would be meaningless: it would be an octet hole that is filled in application by application.

I support the current structure in the draft: it allows each application to specify its policy in a way that is appropriate for the application, yet gives an interoperable format for trust anchors that work well beyond typical PKIX uses.

--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 n25FmKl4020536 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Mar 2009 08:48:20 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n25FmK79020535; Thu, 5 Mar 2009 08:48:20 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.newbay.com (87-198-172-198.ptr.magnet.ie [87.198.172.198]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n25Fm8c8020512 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 5 Mar 2009 08:48:19 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.newbay.com (Postfix) with ESMTP id 34CF1100406C7 for <[e-mail]>; Thu,  5 Mar 2009 15:48:07 +0000 (GMT)
X-Virus-Scanned: amavisd-new at newbay.com
Received: from mail.newbay.com ([127.0.0.1]) by localhost (mail.newbay.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gjhn+9owqhXa for <[e-mail]>; Thu,  5 Mar 2009 15:48:06 +0000 (GMT)
Received: from [192.168.3.55] (unknown [192.168.3.55]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.newbay.com (Postfix) with ESMTP id 3CA141003F4B9 for <[e-mail]>; Thu,  5 Mar 2009 15:48:06 +0000 (GMT)
Message-ID: <[e-mail]>
Date: Thu, 05 Mar 2009 15:48:20 +0000
From: Stephen Farrell <[e-mail]>
User-Agent: Thunderbird 2.0.0.16 (X11/20080707)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: I-D Action:draft-ietf-pkix-other-certs-02.txt
References: <[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>

Just to save you time, this is basically the same as before
but with the editorial comments removed and I've asked the
chairs to start a WGLC for it at the appropriate time.

S.

[e-mail] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.
> 
> 
> 	Title           : Other Certificates Extension
> 	Author(s)       : S. Farrell
> 	Filename        : draft-ietf-pkix-other-certs-02.txt
> 	Pages           : 8
> 	Date            : 2009-03-05
> 
> Some applications that associate state information with public key
> certificates can benefit from a way to link together a set of
> certificates belonging to the same end entity that can safely be
> considered to be equivalent for the purposes of referencing that
> application state information.  This memo defines a certificate
> extension that allows applications to establish the required linkage
> without introducing a new application protocol data unit.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-other-certs-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.



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 n25FkCMY020381 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Mar 2009 08:46:12 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n25FkCQt020379; Thu, 5 Mar 2009 08:46: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 n25FkBxA020373 for <[e-mail]>; Thu, 5 Mar 2009 08:46:12 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 21100 invoked from network); 5 Mar 2009 15:45:47 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 5 Mar 2009 15:45:46 -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: I-D Action:draft-ietf-pkix-ta-format-01.txt
Date: Thu, 5 Mar 2009 10:46:10 -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-format-01.txt
Thread-Index: AcmdpQ9hq6hS9g5OTjG9rrruy8wqPgAAaHiA
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Carl Wallace" <[e-mail]>
To: "Julien Stern" <[e-mail]>
Cc: "Tom Gindin" <[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>

Inline...=20

> -----Original Message-----
> From: Julien Stern [mailto:[e-mail]]=20
> Sent: Thursday, March 05, 2009 10:10 AM
> To: Carl Wallace
> Cc: Tom Gindin; [e-mail]
> Subject: Re: I-D Action:draft-ietf-pkix-ta-format-01.txt
>=20
> Carl,
>=20
> Thanks for your reply.
> I'm starting to see some of the rationale better.
>=20
> What still slightly bothers me is the following:
>=20
> I keep on thinking it would bring major confusion to say that=20
> a trust anchor can be reduced to a public key. A trust anchor=20
> has to be an _identified_ public key, else it's just...=20
> well... a public key.

A TA is a public key and some constraints on its usage.  As referenced
in this thread, a DN is just one form of constraint.
=20
> Now, I feel I'm starting to understand why the keyIdentifier=20
> is always mandatory. Maybe you meant to be using this key=20
> identifier as a generic "name" for the key? In which case, we=20
> do have a difference between a public key and a trust anchor,=20
> e.g. the key is "identified". However, this keyIdentifier is=20
> usually directly inferred from the public key, so this=20
> "identification" is a weak one at best.
>
> The very beginning of the TA draft says: "A trust anchor is=20
> an authoritative entity represented by a public key and=20
> associated data."
> The bare minimum currently allowed is the key and the keyIdentifier.
>=20
> I fail to see how the authoritative entity comes into play=20
> here.=20

The authoritative entity associated with the TA comes into play by using
the private key. =20

> In all the examples you gave below, we may possibly go=20
> through a keyIdentifier instead of a DN to find the public=20
> key used to signing, but it does not make sense to use this=20
> key if it is an "anonymous" key.

Why?  That some signature schemes use a key identifier instead of a DN
to locate the public key isn't a problem.  Even 5280 uses key identifier
more than DN to find a key (where one CA has multiple certs).  The
important thing is that the TA was obtained in a secure manner. =20

> Maybe, an other way to highlight the difference in our views=20
> is that you assume the "identification" of the key can be=20
> performed by external means? In which case, a trust anchor=20
> could be a public key whose owner happens to be known by=20
> external means or be implicit from the context?=20
> And that I believe the identity of the "authoritative entity"=20
> should be explicitly stated in the TA?

Trust in the key is established by external means, i.e., manual check or
TAMP message verification.  DNs are generally not small.  The taName is
optional to allow omission in situations where they are not used.  Why
should a name be required since not all uses require a name?  =20
=20
> Regards,
>=20
> --
> Julien
>=20
>=20
> Carl Wallace wrote:
> > Inline...
> >=20
> >> -----Original Message-----
> >> From: Julien Stern [mailto:[e-mail]]
> >> Sent: Thursday, March 05, 2009 8:09 AM
> >> To: Carl Wallace
> >> Cc: Tom Gindin; [e-mail]
> >> Subject: Re: I-D Action:draft-ietf-pkix-ta-format-01.txt
> >>
> >> Carl,
> >>
> >> well, there may be strong "philosophical" disagreements=20
> from yourself=20
> >> and/or Tom of what a trust anchor is (which is fine
> >> :) ), but could you give an example of an actual use of a trust=20
> >> anchor that do not require an identity?
> >=20
> > CMS does not use a DN to identify a signer.  Timestamps, firmware=20
> > packages and key packages are all examples of objects=20
> signed using CMS=20
> > that could be verified using a TA that is not named using a DN but=20
> > identified with a key identifier.  OCSP responses aren't=20
> signed using=20
> > CMS but can also identify a signer using a key identifier=20
> and may be=20
> > validated by a TA.
> > =20
> >> Again, my humble personal view is that a PKI in general is=20
> before all=20
> >> used to link cryptographic key to identities. This can be done by=20
> >> direct trust (e.g. a trust anchor) or vouched by an other entity=20
> >> (e.g. a certificate). This is why I believe the identity is a=20
> >> fundamental part of a trust anchor.
> >> Now the fact that this identity should be a DN is not as=20
> fundamental=20
> >> (it could be a string), but considering the global=20
> context, a DN is=20
> >> really what makes senses.
> >=20
> > You could choose to use a DN and/or a TA title in all TAs=20
> used in your=20
> > environment.
> > =20
> >> I read the fact that omission of the taName precludes path=20
> validation=20
> >> (and I naturally concur), but I actually think that=20
> omission of that=20
> >> name precludes _any_ usage of the corresponding public=20
> key, and that=20
> >> therefore the DN should be made mandatory in all cases.
> >=20
> > The DN is required by 5280 for name chaining.  A DN is not=20
> required in=20
> > all cases where a TA could be used (see above) so making it=20
> mandatory=20
> > is not desirable.
> > =20
> >> --
> >> Julien
> >>
> >> Carl Wallace wrote:
> >>> The draft notes that omission of the taName field precludes path=20
> >>> validation.  Given that TAs serve other purposes that don't
> >> require DNs,
> >>> making the field optional makes sense.  All three formats
> >> in the draft
> >>> support including a DN.  This allows the 5280 requirement to be
> >>> satisfied with each structure.  =20
> >>>
> >>>> -----Original Message-----
> >>>> From: [e-mail]=20
> >>>> [mailto:[e-mail]] On Behalf Of Tom Gindin
> >>>> Sent: Wednesday, March 04, 2009 8:41 PM
> >>>> To: Julien Stern
> >>>> Cc: [e-mail]
> >>>> Subject: Re: I-D Action:draft-ietf-pkix-ta-format-01.txt
> >>>>
> >>>>
> >>>>         Julian:
> >>>>
> >>>>         I think you're wrong in believing that the name=20
> is central=20
> >>>> to the definition of a trust anchor.  I can have (and my browser=20
> >>>> may be shipped
> >>>> with) several trust anchors issued by the same organization, and=20
> >>>> the names which distinguish them are (to me as the=20
> manager of the=20
> >>>> trust store) quite arbitrary.  A typical example is that=20
> there are=20
> >>>> two separate CA certificates from Entrust with CN=3D"Entrust.net=20
> >>>> Secure Server Certification Authority".  Their OU's are slightly=20
> >>>> different, and one of them has a Country attribute.
> >>>>         While philosophically I completely disagree with=20
> you, RFC=20
> >>>> 5280 section 6.1.1 point d-1 requires that the trust=20
> anchor have an=20
> >>>> issuer name, as does the same section in 3280.
> >>>>  Thus, no trust anchor definition which does not include=20
> an issuer=20
> >>>> name can be used by our own existing algorithms.  I=20
> think that's a=20
> >>>> pretty good reason for PKIX to require the presence of a=20
> DN in this=20
> >>>> definition.
> >>>>
> >>>>                 Tom Gindin
> >>>>
> >>>> P.S. - These views are mine personally, and not=20
> necessarily those=20
> >>>> of my employer
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> Julien Stern <[e-mail]> Sent by:=20
> >>>> [e-mail]
> >>>> 03/04/2009 01:43 PM
> >>>>
> >>>> To
> >>>>
> >>>> cc
> >>>> [e-mail]
> >>>> Subject
> >>>> Re: I-D Action:draft-ietf-pkix-ta-format-01.txt
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> [e-mail] wrote:
> >>>>> A New Internet-Draft is available from the on-line
> >> Internet-Drafts
> >>>> directories.
> >>>>> This draft is a work item of the Public-Key
> >> Infrastructure (X.509)
> >>>> Working Group of the IETF.
> >>>>>                Title           : Trust Anchor Format
> >>>>>                Author(s)       : R. Housley, et al.
> >>>>>                Filename        :=20
> draft-ietf-pkix-ta-format-01.txt
> >>>>>                Pages           : 17
> >>>>>                Date            : 2009-03-04
> >>>>>
> >>>> Hi again,
> >>>>
> >>>> separating from the previous email due to the nature of
> >> the comment:=20
> >>>> this one is more "philosophical" :)
> >>>>
> >>>> This draft defines a trust anchor as a public key with=20
> additional=20
> >>>> data.
> >>>>
> >>>> I believe that the most common usage of the word "trust anchor"=20
> >>>> denotes the _binding_ of a public key _and_ a name. A=20
> certificate=20
> >>>> binds a name and a public key (along with other=20
> information) thanks=20
> >>>> to a signature. A trust anchor binds them through direct trust.
> >>>>
> >>>> And indeed, the definition in X.509 is:
> >>>>
> >>>> trust anchor: A trust anchor is a set of the following
> >> information in
> >>>> addition to the public key: algorithm identifier, public key=20
> >>>> parameters (if applicable), distinguished name of the=20
> holder of the
> >> associated
> >>>> private key (i.e., the subject CA) and optionally a validity=20
> >>>> period. The trust anchor may be provided in the form of a=20
> >>>> self-signed
> >> certificate.
> >>>> A trust anchor is trusted by a certificate using system
> >> and used for
> >>>> validating certificates in certification paths.
> >>>>
> >>>>
> >>>> I assume that you did not choose to make the DN optional without=20
> >>>> reason.
> >>>> But is that really something that we would like to have?=20
> Are there=20
> >>>> really cases where we want to use a public key without=20
> explicitly=20
> >>>> knowing whom it belongs to? Isn't there a risk to spread
> >> confusion on
> >>>> what a "trust anchor" is?
> >>>>
> >>>> Granted, this RFC could define a Trust Anchor in a more
> >> global scope,
> >>>> without a need to bind it to a DN, but I'm (very
> >> personally) not sure
> >>>> this is a great idea and I believe that mandating the=20
> presence of a=20
> >>>> DN would not bring a strong limitation.
> >>>>
> >>>> Have you considered moving the taName from the=20
> CertPathControls to=20
> >>>> the main structure (TrustAnchorInfo) and keeping the=20
> >>>> CertPathControls structure for fine tuning of the X.509 input=20
> >>>> algorithm?
> >>>>
> >>>> (And along the same lines, why is the KeyIdentifier
> >> mandatory and not
> >>>> optional?)
> >>>>
> >>>> Regards,
> >>>>
> >>>> --
> >>>> Julien
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>
> >=20
> >=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 n25FJg73018557 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Mar 2009 08:19:42 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n25FJgNg018556; Thu, 5 Mar 2009 08:19:42 -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 n25FJVCr018534 for <[e-mail]>; Thu, 5 Mar 2009 08:19:41 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Received: (qmail 24811 invoked by uid 0); 5 Mar 2009 15:19:27 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (96.255.144.212) by woodstock.binhost.com with SMTP; 5 Mar 2009 15:19:27 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Thu, 05 Mar 2009 09:00:46 -0500
To: Julien Stern <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: I-D Action:draft-ietf-pkix-ta-format-01.txt
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>

Julien:

>I fully share your view that the "other policy information" should 
>only be an optional part of the trust anchor. However, I feel that 
>the name is a fundamental part of the trust anchor. A trust anchor 
>without a name, in my opinion, would be like a certificate without a name.

I have no objection to the taName becoming a mandatory element of the 
structure.  It is certainly needed for certification path 
construction and validation.  However, in the TAMP context, there are 
messages that are signed directly by the trust anchor.  In this case, 
a key identifier without a name is sufficient.  This element is 
optional to allow for a trust anchor that is able to sign such 
messages but not allowed to sign certificates.  So, if the taName 
becomes non-optional, another mechanism is needed to indicate whether 
the trust anchor can sign certificates.

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 n25F9jMv017933 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Mar 2009 08:09:45 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n25F9jeE017932; Thu, 5 Mar 2009 08:09:45 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mallaury.nerim.net (smtp-104-thursday.noc.nerim.net [62.4.17.104]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n25F9hss017926 for <[e-mail]>; Thu, 5 Mar 2009 08:09:43 -0700 (MST) (envelope-from [e-mail])
Received: from uranus.cry.pto (cryptolog2.pck.nerim.net [213.41.184.9]) by mallaury.nerim.net (Postfix) with ESMTP id 5FA67A1087; Thu,  5 Mar 2009 16:09:39 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by uranus.cry.pto (Postfix) with ESMTP id 17921440F5; Thu,  5 Mar 2009 16:09:40 +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 6qd2HwZHpfZ4; Thu,  5 Mar 2009 16:09:35 +0100 (CET)
Received: from [10.0.1.30] (leda.cry.pto [10.0.1.30]) by uranus.cry.pto (Postfix) with ESMTP id 382A3440AF; Thu,  5 Mar 2009 16:09:35 +0100 (CET)
Message-ID: <[e-mail]>
Date: Thu, 05 Mar 2009 16:09:35 +0100
From: Julien Stern <[e-mail]>
User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103)
MIME-Version: 1.0
To: Carl Wallace <[e-mail]>
Cc: Tom Gindin <[e-mail]>, [e-mail]
Subject: Re: I-D Action:draft-ietf-pkix-ta-format-01.txt
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>

Carl,

Thanks for your reply.
I'm starting to see some of the rationale better.

What still slightly bothers me is the following:

I keep on thinking it would bring major confusion to say that a trust 
anchor can be reduced to a public key. A trust anchor has to be an 
_identified_ public key, else it's just... well... a public key.

Now, I feel I'm starting to understand why the keyIdentifier is always 
mandatory. Maybe you meant to be using this key identifier as a generic 
"name" for the key? In which case, we do have a difference between a 
public key and a trust anchor, e.g. the key is "identified". However, 
this keyIdentifier is usually directly inferred from the public key, so 
this "identification" is a weak one at best.

The very beginning of the TA draft says: "A trust anchor is an 
authoritative entity represented by a public key and associated data."
The bare minimum currently allowed is the key and the keyIdentifier.

I fail to see how the authoritative entity comes into play here. In all 
the examples you gave below, we may possibly go through a keyIdentifier 
instead of a DN to find the public key used to signing, but it does not 
make sense to use this key if it is an "anonymous" key.

Maybe, an other way to highlight the difference in our views is that you 
assume the "identification" of the key can be performed by external 
means? In which case, a trust anchor could be a public key whose owner 
happens to be known by external means or be implicit from the context? 
And that I believe the identity of the "authoritative entity" should be 
explicitly stated in the TA?

Regards,

--
Julien


Carl Wallace wrote:
> Inline...
> 
>> -----Original Message-----
>> From: Julien Stern [mailto:[e-mail]] 
>> Sent: Thursday, March 05, 2009 8:09 AM
>> To: Carl Wallace
>> Cc: Tom Gindin; [e-mail]
>> Subject: Re: I-D Action:draft-ietf-pkix-ta-format-01.txt
>>
>> Carl,
>>
>> well, there may be strong "philosophical" disagreements from 
>> yourself and/or Tom of what a trust anchor is (which is fine 
>> :) ), but could you give an example of an actual use of a 
>> trust anchor that do not require an identity?
> 
> CMS does not use a DN to identify a signer.  Timestamps, firmware
> packages and key packages are all examples of objects signed using CMS
> that could be verified using a TA that is not named using a DN but
> identified with a key identifier.  OCSP responses aren't signed using
> CMS but can also identify a signer using a key identifier and may be
> validated by a TA. 
>  
>> Again, my humble personal view is that a PKI in general is 
>> before all used to link cryptographic key to identities. This 
>> can be done by direct trust (e.g. a trust anchor) or vouched 
>> by an other entity (e.g. a certificate). This is why I 
>> believe the identity is a fundamental part of a trust anchor. 
>> Now the fact that this identity should be a DN is not as 
>> fundamental (it could be a string), but considering the 
>> global context, a DN is really what makes senses.
> 
> You could choose to use a DN and/or a TA title in all TAs used in your
> environment.
>  
>> I read the fact that omission of the taName precludes path 
>> validation (and I naturally concur), but I actually think 
>> that omission of that name precludes _any_ usage of the 
>> corresponding public key, and that therefore the DN should be 
>> made mandatory in all cases.
> 
> The DN is required by 5280 for name chaining.  A DN is not required in
> all cases where a TA could be used (see above) so making it mandatory is
> not desirable.
>  
>> --
>> Julien
>>
>> Carl Wallace wrote:
>>> The draft notes that omission of the taName field precludes path
>>> validation.  Given that TAs serve other purposes that don't 
>> require DNs,
>>> making the field optional makes sense.  All three formats 
>> in the draft
>>> support including a DN.  This allows the 5280 requirement to be
>>> satisfied with each structure.   
>>>
>>>> -----Original Message-----
>>>> From: [e-mail] 
>>>> [mailto:[e-mail]] On Behalf Of Tom Gindin
>>>> Sent: Wednesday, March 04, 2009 8:41 PM
>>>> To: Julien Stern
>>>> Cc: [e-mail]
>>>> Subject: Re: I-D Action:draft-ietf-pkix-ta-format-01.txt
>>>>
>>>>
>>>>         Julian:
>>>>
>>>>         I think you're wrong in believing that the name is 
>>>> central to the definition of a trust anchor.  I can have (and 
>>>> my browser may be shipped
>>>> with) several trust anchors issued by the same organization, 
>>>> and the names which distinguish them are (to me as the  
>>>> manager of the trust store) quite arbitrary.  A typical 
>>>> example is that there are two separate CA certificates from 
>>>> Entrust with CN="Entrust.net Secure Server Certification 
>>>> Authority".  Their OU's are slightly different, and one of 
>>>> them has a Country attribute.
>>>>         While philosophically I completely disagree with you, 
>>>> RFC 5280 section 6.1.1 point d-1 requires that the trust 
>>>> anchor have an issuer name, as does the same section in 3280. 
>>>>  Thus, no trust anchor definition which does not include an 
>>>> issuer name can be used by our own existing algorithms.  I 
>>>> think that's a pretty good reason for PKIX to require the 
>>>> presence of a DN in this definition.
>>>>
>>>>                 Tom Gindin
>>>>
>>>> P.S. - These views are mine personally, and not necessarily 
>>>> those of my employer
>>>>
>>>>
>>>>
>>>>
>>>> Julien Stern <[e-mail]> 
>>>> Sent by: [e-mail]
>>>> 03/04/2009 01:43 PM
>>>>
>>>> To
>>>>
>>>> cc
>>>> [e-mail]
>>>> Subject
>>>> Re: I-D Action:draft-ietf-pkix-ta-format-01.txt
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> [e-mail] wrote:
>>>>> A New Internet-Draft is available from the on-line 
>> Internet-Drafts 
>>>> directories.
>>>>> This draft is a work item of the Public-Key 
>> Infrastructure (X.509) 
>>>> Working Group of the IETF.
>>>>>                Title           : Trust Anchor Format
>>>>>                Author(s)       : R. Housley, et al.
>>>>>                Filename        : draft-ietf-pkix-ta-format-01.txt
>>>>>                Pages           : 17
>>>>>                Date            : 2009-03-04
>>>>>
>>>> Hi again,
>>>>
>>>> separating from the previous email due to the nature of 
>> the comment: 
>>>> this one is more "philosophical" :)
>>>>
>>>> This draft defines a trust anchor as a public key with 
>>>> additional data.
>>>>
>>>> I believe that the most common usage of the word "trust 
>>>> anchor" denotes 
>>>> the _binding_ of a public key _and_ a name. A certificate 
>>>> binds a name 
>>>> and a public key (along with other information) thanks to a 
>>>> signature. A 
>>>> trust anchor binds them through direct trust.
>>>>
>>>> And indeed, the definition in X.509 is:
>>>>
>>>> trust anchor: A trust anchor is a set of the following 
>> information in 
>>>> addition to the public key: algorithm identifier, public key 
>>>> parameters 
>>>> (if applicable), distinguished name of the holder of the 
>> associated 
>>>> private key (i.e., the subject CA) and optionally a validity 
>>>> period. The 
>>>> trust anchor may be provided in the form of a self-signed 
>> certificate.
>>>> A trust anchor is trusted by a certificate using system 
>> and used for 
>>>> validating certificates in certification paths.
>>>>
>>>>
>>>> I assume that you did not choose to make the DN optional 
>>>> without reason. 
>>>> But is that really something that we would like to have? Are there 
>>>> really cases where we want to use a public key without explicitly 
>>>> knowing whom it belongs to? Isn't there a risk to spread 
>> confusion on 
>>>> what a "trust anchor" is?
>>>>
>>>> Granted, this RFC could define a Trust Anchor in a more 
>> global scope, 
>>>> without a need to bind it to a DN, but I'm (very 
>> personally) not sure 
>>>> this is a great idea and I believe that mandating the 
>>>> presence of a DN 
>>>> would not bring a strong limitation.
>>>>
>>>> Have you considered moving the taName from the 
>>>> CertPathControls to the 
>>>> main structure (TrustAnchorInfo) and keeping the CertPathControls 
>>>> structure for fine tuning of the X.509 input algorithm?
>>>>
>>>> (And along the same lines, why is the KeyIdentifier 
>> mandatory and not 
>>>> optional?)
>>>>
>>>> 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 n25E0VB7013415 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Mar 2009 07:00:31 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n25E0VhF013414; Thu, 5 Mar 2009 07:00:31 -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 n25E0VWx013408 for <[e-mail]>; Thu, 5 Mar 2009 07:00:31 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id 3A4903A6B33; Thu,  5 Mar 2009 06:00:00 -0800 (PST)
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D Action:draft-ietf-pkix-other-certs-02.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Thu,  5 Mar 2009 06: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           : Other Certificates Extension
	Author(s)       : S. Farrell
	Filename        : draft-ietf-pkix-other-certs-02.txt
	Pages           : 8
	Date            : 2009-03-05

Some applications that associate state information with public key
certificates can benefit from a way to link together a set of
certificates belonging to the same end entity that can safely be
considered to be equivalent for the purposes of referencing that
application state information.  This memo defines a certificate
extension that allows applications to establish the required linkage
without introducing a new application protocol data unit.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-other-certs-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
Content-Type: Message/External-body;
	name="draft-ietf-pkix-other-certs-02.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 n25DYuvb012142 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Mar 2009 06:34:56 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n25DYugL012141; Thu, 5 Mar 2009 06:34:56 -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 n25DYiwm012128 for <[e-mail]>; Thu, 5 Mar 2009 06:34:55 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 18425 invoked from network); 5 Mar 2009 13:34:19 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 5 Mar 2009 13:34: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: I-D Action:draft-ietf-pkix-ta-format-01.txt
Date: Thu, 5 Mar 2009 08:34:42 -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-format-01.txt
Thread-Index: Acmdk59BHTFx1oR2QI+uyhxTFx8xjQAAGJOg
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Carl Wallace" <[e-mail]>
To: "Julien Stern" <[e-mail]>
Cc: "Tom Gindin" <[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>

Inline...

> -----Original Message-----
> From: Julien Stern [mailto:[e-mail]]=20
> Sent: Thursday, March 05, 2009 8:09 AM
> To: Carl Wallace
> Cc: Tom Gindin; [e-mail]
> Subject: Re: I-D Action:draft-ietf-pkix-ta-format-01.txt
>=20
> Carl,
>=20
> well, there may be strong "philosophical" disagreements from=20
> yourself and/or Tom of what a trust anchor is (which is fine=20
> :) ), but could you give an example of an actual use of a=20
> trust anchor that do not require an identity?

CMS does not use a DN to identify a signer.  Timestamps, firmware
packages and key packages are all examples of objects signed using CMS
that could be verified using a TA that is not named using a DN but
identified with a key identifier.  OCSP responses aren't signed using
CMS but can also identify a signer using a key identifier and may be
validated by a TA.=20
=20
> Again, my humble personal view is that a PKI in general is=20
> before all used to link cryptographic key to identities. This=20
> can be done by direct trust (e.g. a trust anchor) or vouched=20
> by an other entity (e.g. a certificate). This is why I=20
> believe the identity is a fundamental part of a trust anchor.=20
> Now the fact that this identity should be a DN is not as=20
> fundamental (it could be a string), but considering the=20
> global context, a DN is really what makes senses.

You could choose to use a DN and/or a TA title in all TAs used in your
environment.
=20
> I read the fact that omission of the taName precludes path=20
> validation (and I naturally concur), but I actually think=20
> that omission of that name precludes _any_ usage of the=20
> corresponding public key, and that therefore the DN should be=20
> made mandatory in all cases.

The DN is required by 5280 for name chaining.  A DN is not required in
all cases where a TA could be used (see above) so making it mandatory is
not desirable.
=20
> --
> Julien
>=20
> Carl Wallace wrote:
> > The draft notes that omission of the taName field precludes path
> > validation.  Given that TAs serve other purposes that don't=20
> require DNs,
> > making the field optional makes sense.  All three formats=20
> in the draft
> > support including a DN.  This allows the 5280 requirement to be
> > satisfied with each structure.  =20
> >=20
> >> -----Original Message-----
> >> From: [e-mail]=20
> >> [mailto:[e-mail]] On Behalf Of Tom Gindin
> >> Sent: Wednesday, March 04, 2009 8:41 PM
> >> To: Julien Stern
> >> Cc: [e-mail]
> >> Subject: Re: I-D Action:draft-ietf-pkix-ta-format-01.txt
> >>
> >>
> >>         Julian:
> >>
> >>         I think you're wrong in believing that the name is=20
> >> central to the definition of a trust anchor.  I can have (and=20
> >> my browser may be shipped
> >> with) several trust anchors issued by the same organization,=20
> >> and the names which distinguish them are (to me as the =20
> >> manager of the trust store) quite arbitrary.  A typical=20
> >> example is that there are two separate CA certificates from=20
> >> Entrust with CN=3D"Entrust.net Secure Server Certification=20
> >> Authority".  Their OU's are slightly different, and one of=20
> >> them has a Country attribute.
> >>         While philosophically I completely disagree with you,=20
> >> RFC 5280 section 6.1.1 point d-1 requires that the trust=20
> >> anchor have an issuer name, as does the same section in 3280.=20
> >>  Thus, no trust anchor definition which does not include an=20
> >> issuer name can be used by our own existing algorithms.  I=20
> >> think that's a pretty good reason for PKIX to require the=20
> >> presence of a DN in this definition.
> >>
> >>                 Tom Gindin
> >>
> >> P.S. - These views are mine personally, and not necessarily=20
> >> those of my employer
> >>
> >>
> >>
> >>
> >> Julien Stern <[e-mail]>=20
> >> Sent by: [e-mail]
> >> 03/04/2009 01:43 PM
> >>
> >> To
> >>
> >> cc
> >> [e-mail]
> >> Subject
> >> Re: I-D Action:draft-ietf-pkix-ta-format-01.txt
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> [e-mail] wrote:
> >>> A New Internet-Draft is available from the on-line=20
> Internet-Drafts=20
> >> directories.
> >>> This draft is a work item of the Public-Key=20
> Infrastructure (X.509)=20
> >> Working Group of the IETF.
> >>>
> >>>                Title           : Trust Anchor Format
> >>>                Author(s)       : R. Housley, et al.
> >>>                Filename        : draft-ietf-pkix-ta-format-01.txt
> >>>                Pages           : 17
> >>>                Date            : 2009-03-04
> >>>
> >> Hi again,
> >>
> >> separating from the previous email due to the nature of=20
> the comment:=20
> >> this one is more "philosophical" :)
> >>
> >> This draft defines a trust anchor as a public key with=20
> >> additional data.
> >>
> >> I believe that the most common usage of the word "trust=20
> >> anchor" denotes=20
> >> the _binding_ of a public key _and_ a name. A certificate=20
> >> binds a name=20
> >> and a public key (along with other information) thanks to a=20
> >> signature. A=20
> >> trust anchor binds them through direct trust.
> >>
> >> And indeed, the definition in X.509 is:
> >>
> >> trust anchor: A trust anchor is a set of the following=20
> information in=20
> >> addition to the public key: algorithm identifier, public key=20
> >> parameters=20
> >> (if applicable), distinguished name of the holder of the=20
> associated=20
> >> private key (i.e., the subject CA) and optionally a validity=20
> >> period. The=20
> >> trust anchor may be provided in the form of a self-signed=20
> certificate.
> >> A trust anchor is trusted by a certificate using system=20
> and used for=20
> >> validating certificates in certification paths.
> >>
> >>
> >> I assume that you did not choose to make the DN optional=20
> >> without reason.=20
> >> But is that really something that we would like to have? Are there=20
> >> really cases where we want to use a public key without explicitly=20
> >> knowing whom it belongs to? Isn't there a risk to spread=20
> confusion on=20
> >> what a "trust anchor" is?
> >>
> >> Granted, this RFC could define a Trust Anchor in a more=20
> global scope,=20
> >> without a need to bind it to a DN, but I'm (very=20
> personally) not sure=20
> >> this is a great idea and I believe that mandating the=20
> >> presence of a DN=20
> >> would not bring a strong limitation.
> >>
> >> Have you considered moving the taName from the=20
> >> CertPathControls to the=20
> >> main structure (TrustAnchorInfo) and keeping the CertPathControls=20
> >> structure for fine tuning of the X.509 input algorithm?
> >>
> >> (And along the same lines, why is the KeyIdentifier=20
> mandatory and not=20
> >> optional?)
> >>
> >> Regards,
> >>
> >> --
> >> Julien
> >>
> >>
> >>
> >>
> >=20
> >=20
>=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 n25DIpFS011402 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Mar 2009 06:18:51 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n25DIpnW011401; Thu, 5 Mar 2009 06:18:51 -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-118-thursday.nerim.net [62.4.16.118]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n25DIofC011395 for <[e-mail]>; Thu, 5 Mar 2009 06:18:50 -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 66650B9862; Thu,  5 Mar 2009 14:18:49 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by uranus.cry.pto (Postfix) with ESMTP id 2F44B440F5; Thu,  5 Mar 2009 14:18:49 +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 K+EDN78JBRHs; Thu,  5 Mar 2009 14:18:44 +0100 (CET)
Received: from [10.0.1.30] (leda.cry.pto [10.0.1.30]) by uranus.cry.pto (Postfix) with ESMTP id 9CF40440AF; Thu,  5 Mar 2009 14:18:44 +0100 (CET)
Message-ID: <[e-mail]>
Date: Thu, 05 Mar 2009 14:18:44 +0100
From: Julien Stern <[e-mail]>
User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103)
MIME-Version: 1.0
To: Carl Wallace <[e-mail]>
Cc: [e-mail]
Subject: Re: I-D Action:draft-ietf-pkix-ta-format-01.txt
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>

Carl Wallace wrote:
> <snip>
>> One first comment regarding the CertPolicyFlags:
>>
>> They are defined as:
>>
>> CertPolicyFlags ::= BIT STRING {
>>        inhibitPolicyMapping   (0),
>>        requireExplicitPolicy  (1),
>>        inhibitAnyPolicy       (2) }
>>
>> But in 5280, they are integer, not booleans, for example:
>>
>> PolicyConstraints ::= SEQUENCE {
>>       requireExplicitPolicy   [0]     SkipCerts OPTIONAL,
>>       inhibitPolicyMapping    [1]     SkipCerts OPTIONAL }
>>
>> SkipCerts ::= INTEGER (0..MAX)
>>
>> I believe that we should keep them integers to keep the full 
>> generality (unless I missed a point).
> 
> The booleans align with the inputs to the path validation algorithm.
> Ideally, those would have been integers too.

Hmm... That a tricky point I think. I agree that the validation 
algorithm has currently described takes booleans.

However,
1) It is allowed to augment the algorithm (and that would be a 
worthwhile augmentation)
2) What are some existing algorithm doing?Iif the indicator is set to 
true, some will look at the extension in the trust anchor to initialize 
a value which will be an integer, and not a boolean anymore.

So, if we leave them as boolean in the trust anchor, we will prevent 
trust anchor from defining these values, especially considering that the 
RFC explicitly states that the extensions which contains these elements 
should be ignored.

--
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 n25D9fdi010480 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Mar 2009 06:09:41 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n25D9ffJ010479; Thu, 5 Mar 2009 06:09:41 -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-104-thursday.nerim.net [62.4.16.104]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n25D9TNf010462 for <[e-mail]>; Thu, 5 Mar 2009 06:09:40 -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 2D02DCF176; Thu,  5 Mar 2009 14:09:28 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by uranus.cry.pto (Postfix) with ESMTP id 30FA1440F5; Thu,  5 Mar 2009 14:09:28 +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 YceC0YZk-leN; Thu,  5 Mar 2009 14:09:20 +0100 (CET)
Received: from [10.0.1.30] (leda.cry.pto [10.0.1.30]) by uranus.cry.pto (Postfix) with ESMTP id 653A4440AF; Thu,  5 Mar 2009 14:09:20 +0100 (CET)
Message-ID: <[e-mail]>
Date: Thu, 05 Mar 2009 14:09:20 +0100
From: Julien Stern <[e-mail]>
User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103)
MIME-Version: 1.0
To: Carl Wallace <[e-mail]>
Cc: Tom Gindin <[e-mail]>, [e-mail]
Subject: Re: I-D Action:draft-ietf-pkix-ta-format-01.txt
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>

Carl,

well, there may be strong "philosophical" disagreements from yourself 
and/or Tom of what a trust anchor is (which is fine :) ), but could you 
give an example of an actual use of a trust anchor that do not require 
an identity?

Again, my humble personal view is that a PKI in general is before all 
used to link cryptographic key to identities. This can be done by direct 
trust (e.g. a trust anchor) or vouched by an other entity (e.g. a 
certificate). This is why I believe the identity is a fundamental part 
of a trust anchor. Now the fact that this identity should be a DN is not 
as fundamental (it could be a string), but considering the global 
context, a DN is really what makes senses.

I read the fact that omission of the taName precludes path validation 
(and I naturally concur), but I actually think that omission of that 
name precludes _any_ usage of the corresponding public key, and that 
therefore the DN should be made mandatory in all cases.

--
Julien

Carl Wallace wrote:
> The draft notes that omission of the taName field precludes path
> validation.  Given that TAs serve other purposes that don't require DNs,
> making the field optional makes sense.  All three formats in the draft
> support including a DN.  This allows the 5280 requirement to be
> satisfied with each structure.   
> 
>> -----Original Message-----
>> From: [e-mail] 
>> [mailto:[e-mail]] On Behalf Of Tom Gindin
>> Sent: Wednesday, March 04, 2009 8:41 PM
>> To: Julien Stern
>> Cc: [e-mail]
>> Subject: Re: I-D Action:draft-ietf-pkix-ta-format-01.txt
>>
>>
>>         Julian:
>>
>>         I think you're wrong in believing that the name is 
>> central to the definition of a trust anchor.  I can have (and 
>> my browser may be shipped
>> with) several trust anchors issued by the same organization, 
>> and the names which distinguish them are (to me as the  
>> manager of the trust store) quite arbitrary.  A typical 
>> example is that there are two separate CA certificates from 
>> Entrust with CN="Entrust.net Secure Server Certification 
>> Authority".  Their OU's are slightly different, and one of 
>> them has a Country attribute.
>>         While philosophically I completely disagree with you, 
>> RFC 5280 section 6.1.1 point d-1 requires that the trust 
>> anchor have an issuer name, as does the same section in 3280. 
>>  Thus, no trust anchor definition which does not include an 
>> issuer name can be used by our own existing algorithms.  I 
>> think that's a pretty good reason for PKIX to require the 
>> presence of a DN in this definition.
>>
>>                 Tom Gindin
>>
>> P.S. - These views are mine personally, and not necessarily 
>> those of my employer
>>
>>
>>
>>
>> Julien Stern <[e-mail]> 
>> Sent by: [e-mail]
>> 03/04/2009 01:43 PM
>>
>> To
>>
>> cc
>> [e-mail]
>> Subject
>> Re: I-D Action:draft-ietf-pkix-ta-format-01.txt
>>
>>
>>
>>
>>
>>
>>
>> [e-mail] wrote:
>>> A New Internet-Draft is available from the on-line Internet-Drafts 
>> directories.
>>> This draft is a work item of the Public-Key Infrastructure (X.509) 
>> Working Group of the IETF.
>>>
>>>                Title           : Trust Anchor Format
>>>                Author(s)       : R. Housley, et al.
>>>                Filename        : draft-ietf-pkix-ta-format-01.txt
>>>                Pages           : 17
>>>                Date            : 2009-03-04
>>>
>> Hi again,
>>
>> separating from the previous email due to the nature of the comment: 
>> this one is more "philosophical" :)
>>
>> This draft defines a trust anchor as a public key with 
>> additional data.
>>
>> I believe that the most common usage of the word "trust 
>> anchor" denotes 
>> the _binding_ of a public key _and_ a name. A certificate 
>> binds a name 
>> and a public key (along with other information) thanks to a 
>> signature. A 
>> trust anchor binds them through direct trust.
>>
>> And indeed, the definition in X.509 is:
>>
>> trust anchor: A trust anchor is a set of the following information in 
>> addition to the public key: algorithm identifier, public key 
>> parameters 
>> (if applicable), distinguished name of the holder of the associated 
>> private key (i.e., the subject CA) and optionally a validity 
>> period. The 
>> trust anchor may be provided in the form of a self-signed certificate.
>> A trust anchor is trusted by a certificate using system and used for 
>> validating certificates in certification paths.
>>
>>
>> I assume that you did not choose to make the DN optional 
>> without reason. 
>> But is that really something that we would like to have? Are there 
>> really cases where we want to use a public key without explicitly 
>> knowing whom it belongs to? Isn't there a risk to spread confusion on 
>> what a "trust anchor" is?
>>
>> Granted, this RFC could define a Trust Anchor in a more global scope, 
>> without a need to bind it to a DN, but I'm (very personally) not sure 
>> this is a great idea and I believe that mandating the 
>> presence of a DN 
>> would not bring a strong limitation.
>>
>> Have you considered moving the taName from the 
>> CertPathControls to the 
>> main structure (TrustAnchorInfo) and keeping the CertPathControls 
>> structure for fine tuning of the X.509 input algorithm?
>>
>> (And along the same lines, why is the KeyIdentifier mandatory and not 
>> optional?)
>>
>> 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 n25D02Ve009882 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Mar 2009 06:00:02 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n25D01Rt009881; Thu, 5 Mar 2009 06:00:01 -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-118-thursday.nerim.net [62.4.16.118]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n25CxogG009807 for <[e-mail]>; Thu, 5 Mar 2009 06:00:01 -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 910B0B92B3; Thu,  5 Mar 2009 13:59:43 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by uranus.cry.pto (Postfix) with ESMTP id 4A4ED440F5; Thu,  5 Mar 2009 13:59:43 +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 dijtJC7skWGB; Thu,  5 Mar 2009 13:59:38 +0100 (CET)
Received: from [10.0.1.30] (leda.cry.pto [10.0.1.30]) by uranus.cry.pto (Postfix) with ESMTP id 6FDC1440AF; Thu,  5 Mar 2009 13:59:38 +0100 (CET)
Message-ID: <[e-mail]>
Date: Thu, 05 Mar 2009 13:59:38 +0100
From: Julien Stern <[e-mail]>
User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103)
MIME-Version: 1.0
To: Tom Gindin <[e-mail]>
Cc: [e-mail]
Subject: Re: I-D Action:draft-ietf-pkix-ta-format-01.txt
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tom,

you are having me slightly confused here. You say that a name is not 
central to the definition of a trust anchor, but you quote examples of 
trust anchors that includes names. Also, I fail to see any examples of 
trust anchors without names.

I think just as you do that PKIX should require the presence of a DN and 
I was wondering why this DN was not simply always mandatory. What is the 
use of a key not linked to an identity?

Regards,

--
Julien

Tom Gindin wrote:
>         Julian:
> 
>         I think you're wrong in believing that the name is central to the 
> definition of a trust anchor.  I can have (and my browser may be shipped 
> with) several trust anchors issued by the same organization, and the names 
> which distinguish them are (to me as the  manager of the trust store) 
> quite arbitrary.  A typical example is that there are two separate CA 
> certificates from Entrust with CN="Entrust.net Secure Server Certification 
> Authority".  Their OU's are slightly different, and one of them has a 
> Country attribute.
>         While philosophically I completely disagree with you, RFC 5280 
> section 6.1.1 point d-1 requires that the trust anchor have an issuer 
> name, as does the same section in 3280.  Thus, no trust anchor definition 
> which does not include an issuer name can be used by our own existing 
> algorithms.  I think that's a pretty good reason for PKIX to require the 
> presence of a DN in this definition.
> 
>                 Tom Gindin
> 
> P.S. - These views are mine personally, and not necessarily those of my 
> employer
> 
> 
> 
> 
> Julien Stern <[e-mail]> 
> Sent by: [e-mail]
> 03/04/2009 01:43 PM
> 
> To
> 
> cc
> [e-mail]
> Subject
> Re: I-D Action:draft-ietf-pkix-ta-format-01.txt
> 
> 
> 
> 
> 
> 
> 
> [e-mail] wrote:
>> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
>> This draft is a work item of the Public-Key Infrastructure (X.509) 
> Working Group of the IETF.
>>
>>                Title           : Trust Anchor Format
>>                Author(s)       : R. Housley, et al.
>>                Filename        : draft-ietf-pkix-ta-format-01.txt
>>                Pages           : 17
>>                Date            : 2009-03-04
>>
> 
> Hi again,
> 
> separating from the previous email due to the nature of the comment: 
> this one is more "philosophical" :)
> 
> This draft defines a trust anchor as a public key with additional data.
> 
> I believe that the most common usage of the word "trust anchor" denotes 
> the _binding_ of a public key _and_ a name. A certificate binds a name 
> and a public key (along with other information) thanks to a signature. A 
> trust anchor binds them through direct trust.
> 
> And indeed, the definition in X.509 is:
> 
> trust anchor: A trust anchor is a set of the following information in 
> addition to the public key: algorithm identifier, public key parameters 
> (if applicable), distinguished name of the holder of the associated 
> private key (i.e., the subject CA) and optionally a validity period. The 
> trust anchor may be provided in the form of a self-signed certificate.
> A trust anchor is trusted by a certificate using system and used for 
> validating certificates in certification paths.
> 
> 
> I assume that you did not choose to make the DN optional without reason. 
> But is that really something that we would like to have? Are there 
> really cases where we want to use a public key without explicitly 
> knowing whom it belongs to? Isn't there a risk to spread confusion on 
> what a "trust anchor" is?
> 
> Granted, this RFC could define a Trust Anchor in a more global scope, 
> without a need to bind it to a DN, but I'm (very personally) not sure 
> this is a great idea and I believe that mandating the presence of a DN 
> would not bring a strong limitation.
> 
> Have you considered moving the taName from the CertPathControls to the 
> main structure (TrustAnchorInfo) and keeping the CertPathControls 
> structure for fine tuning of the X.509 input algorithm?
> 
> (And along the same lines, why is the KeyIdentifier mandatory and not 
> optional?)
> 
> 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 n25CtVC7009686 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Mar 2009 05:55:31 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n25CtV2h009685; Thu, 5 Mar 2009 05:55:31 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mallaury.nerim.net (smtp-104-thursday.noc.nerim.net [62.4.17.104]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n25CtJ5A009670 for <[e-mail]>; Thu, 5 Mar 2009 05:55:30 -0700 (MST) (envelope-from [e-mail])
Received: from uranus.cry.pto (cryptolog2.pck.nerim.net [213.41.184.9]) by mallaury.nerim.net (Postfix) with ESMTP id C7EE8A1092; Thu,  5 Mar 2009 13:55:15 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by uranus.cry.pto (Postfix) with ESMTP id 534AD440F5; Thu,  5 Mar 2009 13:55:16 +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 IygiL7LrdxEF; Thu,  5 Mar 2009 13:55:11 +0100 (CET)
Received: from [10.0.1.30] (leda.cry.pto [10.0.1.30]) by uranus.cry.pto (Postfix) with ESMTP id 8809D440AF; Thu,  5 Mar 2009 13:55:11 +0100 (CET)
Message-ID: <[e-mail]>
Date: Thu, 05 Mar 2009 13:55:11 +0100
From: Julien Stern <[e-mail]>
User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103)
MIME-Version: 1.0
To: Russ Housley <[e-mail]>
Cc: [e-mail]
Subject: Re: I-D Action:draft-ietf-pkix-ta-format-01.txt
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>

Russ,

Comments in line.

Regards,

--
Julien

Russ Housley wrote:
> 
> Julien:
> 
> X.509 did not originally include a definition of trust anchor.  RFC 2459 
> follow this example, and it caused problems when describing 
> certification path validation.  Since RFC 3280 added a lot of material 
> on this topic, a definition was needed.  RFC 3280 includes:
> 
>    In section 6.1, the text describes basic path validation.  Valid
>    paths begin with certificates issued by a trust anchor.  The
>    algorithm requires the public key of the CA, the CA's name, and any
>    constraints upon the set of paths which may be validated using this
>    key.
> 
> I consider these constraints to be additional data.  The RFC 3280 
> definition is saying what is needed in a trust anchor for the path 
> validation algorithm.  Constraints are implemented through settings in 
> the path validation algorithm.  However, I do not see anything in this 
> text that says other policy information cannot be part of a trust 
> anchor.  The text you quote includes validity period, and I consider 
> this to be an example of such policy information.

I fully share your view that the "other policy information" should only 
be an optional part of the trust anchor. However, I feel that the name 
is a fundamental part of the trust anchor. A trust anchor without a 
name, in my opinion, would be like a certificate without a name.

> RFC 2459, RFC 3280, and RFC 5280 have all required CA certificates to 
> include a Distinguished Name.  This is important for constructing a 
> certification path and for identifying a particular certificate in a CRL.
> 
> The taName is needed for certification path construction and 
> validation.  I do not really care if it is placed in a separate OPTIONAL 
> element of TrustAnchorInfo.  How would this change help you?

Well, again, I was wondering about moving the taName up one level, but 
to keep it mandatory not OPTIONAL. I mean, in which use cases would you 
need a key which is not linked to an identity?

> TAMP requires a key identifier.  This format was originally embedded in 
> TAMP.  I guess this linkage remains.  I do point out that a key 
> identifier could be computed from the public key using the technique 
> described in RFC 5280, so this is not an onerous requirement.

OK. Fair enough. Thanks for the clarification.

> Russ
> 
> 
> At 01:43 PM 3/4/2009, Julien Stern wrote:
> 
>> [e-mail] wrote:
>>> A New Internet-Draft is available from the on-line Internet-Drafts 
>>> directories.
>>> This draft is a work item of the Public-Key Infrastructure (X.509) 
>>> Working Group of the IETF.
>>>
>>>         Title           : Trust Anchor Format
>>>         Author(s)       : R. Housley, et al.
>>>         Filename        : draft-ietf-pkix-ta-format-01.txt
>>>         Pages           : 17
>>>         Date            : 2009-03-04
>>
>> Hi again,
>>
>> separating from the previous email due to the nature of the comment: 
>> this one is more "philosophical" :)
>>
>> This draft defines a trust anchor as a public key with additional data.
>>
>> I believe that the most common usage of the word "trust anchor" 
>> denotes the _binding_ of a public key _and_ a name. A certificate 
>> binds a name and a public key (along with other information) thanks to 
>> a signature. A trust anchor binds them through direct trust.
>>
>> And indeed, the definition in X.509 is:
>>
>> trust anchor: A trust anchor is a set of the following information in 
>> addition to the public key: algorithm identifier, public key 
>> parameters (if applicable), distinguished name of the holder of the 
>> associated private key (i.e., the subject CA) and optionally a 
>> validity period. The trust anchor may be provided in the form of a 
>> self-signed certificate.
>> A trust anchor is trusted by a certificate using system and used for 
>> validating certificates in certification paths.
>>
>>
>> I assume that you did not choose to make the DN optional without 
>> reason. But is that really something that we would like to have? Are 
>> there really cases where we want to use a public key without 
>> explicitly knowing whom it belongs to? Isn't there a risk to spread 
>> confusion on what a "trust anchor" is?
>>
>> Granted, this RFC could define a Trust Anchor in a more global scope, 
>> without a need to bind it to a DN, but I'm (very personally) not sure 
>> this is a great idea and I believe that mandating the presence of a DN 
>> would not bring a strong limitation.
>>
>> Have you considered moving the taName from the CertPathControls to the 
>> main structure (TrustAnchorInfo) and keeping the CertPathControls 
>> structure for fine tuning of the X.509 input algorithm?
>>
>> (And along the same lines, why is the KeyIdentifier mandatory and not 
>> optional?)
>>
>> 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 n25BgKYY005613 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Mar 2009 04:42:20 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n25BgKTO005612; Thu, 5 Mar 2009 04:42:20 -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 n25Bg7Zs005598 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 5 Mar 2009 04:42:18 -0700 (MST) (envelope-from [e-mail])
Received: from dommiel.bbn.com ([192.1.122.15] helo=[10.71.0.129]) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from <[e-mail]>) id 1LfBxk-0000Q9-Cf for [e-mail]; Thu, 05 Mar 2009 06:42:07 -0500
Mime-Version: 1.0
Message-Id: <p06240801c5d56adcb384@[128.33.244.176]>
Date: Thu, 5 Mar 2009 06:42:03 -0500
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: message from SangHwan Park, forwarded to the list
Content-Type: multipart/alternative; boundary="============_-975869171==_ma============"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

>Dear David A. Cooper and Kemp, David,
>
>First, I'd like to thank you for the comments.
>
>I've included my responses in blue in-line below for each item.
>
>Thank you.
>
>---------------------
>Section 3 (Requirements):
>
>- This section begins by stating that the "document describes a
>   new separation-of-authority model".  How does the model in this
>   document differ from the one in [13], "An Architecture for
>   Pseudonymous e-Commerce"?  What properties does the protocol
>   in this document have that the protocol in [13] does not?
>In the architecture for Pseudonymous e-Commerce, a CA can link the 
>pseudonym in the subject field to the real identity unilaterally, 
>which can lead to a potential 'big brother problem'. In order to 
>address this issue, this document proposes the separation of 
>authority concepts (two CAs to issue TAC, which tries to prevent one 
>CA from linking pseudonym to real identity unilaterally).
>
>This is incorrect.  In "An Architecture for Pseudonymous 
>e-Commerce", the subscriber requests a certificate from CA A (i.e., 
>the BI).  The subscriber authenticates to CA A using his/her real 
>identity.  CA A issues certificate A to the subscriber with a 
>pseudonymous subject name.  The subscriber then requests a 
>certificate from CA B (i.e., the AI).  The subscriber authenticates 
>to CA B using certificate A.  CA B issues certificate B to the 
>subscriber with a pseudonymous subject name (a name that cannot be 
>connected to the subject name in certificate A).  The subscriber 
>then uses certificate B to authenticate him/herself during normal 
>transactions.  Thus, the subscribers' real identity cannot be tied 
>to the subject name in certificate B without the cooperation of both 
>CA A and CA B.
>
>Note that the subscriber could even use certificate B to obtain yet 
>another pseudonymous certificate from CA C so that it would require 
>the collusion of three CAs to tie the pseudonymous identity that 
>he/she uses to his/her real identity.
>
>Park) In "An architecture of Pseudonymous e-Commerce", the CA A you 
>mentioned above knows of the links between user's real identity and 
>pseudonymous subject name of certificate. It means that CA A can 
>trace user's real identity with the certificate with pseudonymous 
>certificate that is used. The main differences from the "An 
>architecture of Pseudonymous e-Commerce" is that TAC can secure the 
>anonymity not only in the issuance processes but also in the usages 
>of certificate, separating AI and BI's duties with the help of  both 
>threshold and blind signature scheme. The paper you inquired just 
>focuses on the usage of certificate, not on the anonymity in the 
>issuing processes.
>
>Section 5 (Issuing a TAC):
>
>- The protocol involves a complicated scheme involving split
>   signatures and blind signatures.  The use of split signatures
>   complicates the issuance of both certificates and CRLs, yet
>   the need for this scheme is not clear.  It was previously
>   argued that the split signature scheme prevents the CA from
>   issuing a certificate to a user by itself, which could
>   result in a non-traceable certificate.  However, the CA
>   could still create a non-traceable certificate by simply
>   not maintaining the link between the TAC and the Token.
>   An untrustworthy CA could even use a Token issued by the BI
>   to one user as the basis for issuing a certificate to a
>   different user.  Similarly, a BI could issue a Token to a
>   user without first identifying that user.  Since both the AI
>   and BI need to cooperate to identify the user associated with
>   a TAC, there is no benefit in trying to prevent the AI from
>   issuing a non-traceable certificate, as there is no way to
>   force the AI (or BI) from cooperating in the tracing of a
>   certificate if the AI (or BI) simply chooses not the store
>the information required to perform the trace.
>
>It's fair to say that use of the mechanisms mandated by the protocol 
>is not a technical guarantee of the split between the RA and CA 
>functions, e.g., for the reasons you note. However, use of these 
>mechanisms probably makes it easier to conduct an audit that 
>verifies the desired separation of duties. One could define a TAC 
>system that did not specify these mechanistic details. However, 
>verifying that such a system provides the desired separation would 
>be more difficult, on a case-by-case basis. Since you work at NIST, 
>I think a reasonable analogy here is with some of the specs used for 
>FIPS 140-n compliance. For example, there is a spec for a PRNG 
>because it makes it easy for a lab to evaluate a product claiming 
>compliance with 140, not because that PRNG is the only good way to 
>generate random values for use in crypto algorithms.
>
>Can you please explain how the use of threshold signatures (combined 
>with blinded signatures) makes it easier to conduct an audit that 
>verifies that the AI and BI are performing their duties properly?
>Park) With the technology of threshold and blind signature scheme, 
>we can separate the duties of which each AI or BI takes. In other 
>words, AI and BI have its shares of the private keys beforehand; 
>subscribers authenticates to BI using his/her real identity and 
>requests TAC to AI with the Token issued by BI. AI and BI 
>bilaterally digital-signs TAC with the threshold signature scheme. 
>The blind signature is used to let BI be blind to the contents of 
>TAC in order to prevent BI from linking the real identity to subject 
>pseudonymous name.
>
>- Section 5 says that "Blinding is also defined for signature
>   algorithms like DSA, but the explanation is more complex, since
>   DSA does not natively encrypt data."  Can a reference be
>   provided?  I can only find references to papers that propose
>   blinding schemes for variants of DSA.
>You can refer to the blind DSA signature based on MacKenzie and 
>Reiter, 
><http://www.ece.cmu.edu/~reiter/papers/2001/CRYPTO.pdf>http://www.ece.cmu.edu/~reiter/papers/2001/CRYPTO.pdf.
>
>This paper seems to describe a threshold signature scheme (in 
>particular two-party generation of DSA signatures), not a blind 
>signature scheme.
>Park) You can refer to the blind signing protocol of Chapter 4.2 in 
>the attached pdf above.
>It might be difficult to understand how DSA blind signing protocols work.
>
>- Section 5.1, Step 1 states "The signature on a Token is
>   generated by the BI using a private key employed only for
>   this purpose."  Step 2 states "The signature (SignatureValue
>   of SignerInfo) is generated using the BI's private signature
>   key, corresponding to the public key present in the BI's
>   certificate. (Note that this certificate is just a certificate
>   suitable for use with TLS, and is NOT the split-key certificate
>   used to verify a TAC.)"  May the BI use the same private key
>   and certificate to sign Tokens and for TLS authentication?  If
>   not (as stated in Step 1), then why is it necessary for the
>   certificate corresponding to the Token signing key to be
>   "suitable for use with TLS"?  Many other places in the document
>   state that certificates used to verify signatures on CMS
>   messages should be "suitable for use with TLS".
>
>There are several questions here:
>
>- We recommend use of different keys for TLS authentication and for 
>Token signing, as you noted above. Our advice is conservative, 
>following the principle that one should use distinct keys for 
>distinct purposes. Key generation is not so expensive as to warrant 
>reuse of keys for these two purposes.
>
>-  we use the phrase "suitable for use with TLS" to distinguish the 
>certificates used for CMS message verification as distinct from the 
>split-key certificates, as a shorthand. If you have a preferred 
>wording for EE certificates being used in these cases, I think we 
>would be happy to use that wording instead.
>
>Why not say "(Note that this certificate is just a certificate 
>suitable for use with CMS, and is NOT the split-key certificate used 
>to verify a TAC.)"?
>
>Park) We'll reword the phrases as you suggested.
>
>- Section 5.1, Step 6 states:
>      Note that the user should be prepared to accommodate delays
>      in the certificate issuance process. For example, a
>      connection between the user and the AI might fail sometime
>      after the user submits a certificate request at the end of
>      Step 3 and before the AI returns the certificate at the end
>      of Step 6. If this happens, the user should resubmit the
>      request. The AI and BI retain sufficient state to be able to
>      match the resubmitted request to the original request, and
>      respond accordingly.
>
>   This seem appropriate, but it is contradicted by the following
>   text in Section 5.1, Step 4:
>      Next, the AI compares the received Token against a cache of
>      recent (i.e., not "timed out"), validated Tokens. If a
>      duplicate is detected, the certificate request is rejected as
>      a replay.
>
>The comments in step 4 are design guidance; they don't impose 
>specific constraints on how long an AI holds onto a Token.  We can 
>revise the step 6 text to note that although the AI and BI maintain 
>state, they do not do so forever.
>
>The problem isn't that Step 6 implies that the AI and BI have to 
>maintain state forever (although that is a good point as well).  The 
>problem is that Step 4 says that "If a duplicate is detected, the 
>certificate request is rejected as a replay".  Step 6 implies that a 
>AI should (when possible) respond to a resubmitted request by 
>resending the previous generated response, whereas Step 4 implies 
>that the AI must respond to a resubmitted request by rejected it 
>(i.e., by not responding to the request).
>Park) We'll revise the Step 4 accordingly to the Step 6.
>
>- Section 5.2, Step A states that "we propose creating a second
>   CA, under the TAC CA and have it be the CRL issuer for the EE
>   certificates issued by the TAC CA."  However, the actual
>   proposal is to create a second (CRL signing only) key for the
>   CA, not to create a second CA.
>
>Sorry if this is not clear enough. The other CRL is issued using a 
>private key known to the AI unilaterally. Since the key is distinct, 
>but we want the CRL Issuer name to be the same, we elected to have a 
>new CA, represented by a new CA certificate issued under the jointly 
>managed CA certificate.
>
>A CA is identified by its name, not by its key. So, in the scenario 
>you are describing, you are not creating a new CA that issues CRLs 
>under the same name as the AI.  You have a single CA with two keys, 
>one for signing certificates and one for signing CRLs.
>Park) Right.
>
>- Section 5.2, Step A states that "If the AI uses OCSP [14] or
>   SCVP [15] to convey the revocation status of TACs, an equivalent
>   procedure is employed."  SCVP cannot be used by a CA to convey
>   status information in the same way that CRLs and OCSP can, and
>   so it should not be mentioned here.
>
>SCVP responses are more  encompassing than OCSP and CRLs, but they 
>can still provide an RP with an indication of whether a given 
>certificate has been revoked, or not. So, I'm not sure why you feel 
>that SCVP ought not be mentioned here.
>
>OCSP can (generally) be used in one of two ways: (1) it can be 
>operated on behalf of a CA to provide all relying parties with 
>status information for the certificates issued by that CA; or (2) it 
>can be operated on behalf a relying party to provide status 
>information for all certificates that the relying party wishes to 
>validate.  Section 5.2, Step A is describing (1), which is 
>appropriate for OCSP but not SCVP.  Trust model (2) would work for 
>either OCSP or SCVP, but the use of SCVP here would relate to the 
>way in which the relying party obtains status information, not the 
>way in which the AI makes status information available.
>Park) We'll revise the text to cite only OCSP, not SCVP.
>
>
>- Section 5.3.1, Attributes: "This attribute contains
>   X509v3 Certificate Extensions."  Which attribute?  Not the
>   id-kisa-tac attribute mentioned in the previous sentence?  Is
>   inclusion of extension in the PKCS10 optional or are there
>   certain extensions that must be included?
>Whether extensions are required, optional, or permitted is a 
>function of the CP for the TAC CA. However, We can add a note that, 
>in general, it is a bad idea to allow users to include extensions in 
>a cert request because that probably will allow the BI to match the 
>issued cert to the user.
>
>The biggest problem is simply that the text says "this attribute" 
>and I cannot what tell which attribute it means by "this".  Perhaps 
>the text could be reworded as (if my proposed rewording is 
>technically correct):
>
>        Attributes
>         PKCS10[3] defines the attributes field as key-value pairs 
>    where the key is an OID and the value's structure depends on the 
>    key.  The Attributes field MUST include the id-kisa-tac attribute,
>    which holds the Token and is defined below.  The Attributes field
>    MAY also contain X509v3 Certificate Extensions that the subscriber
>    would like to have included in the certificate.   The profile for
>    extensions in certificate requests is specified in the RFC5280[2].
>
>Park) We'll revise the text, as you and Kemp, David suggested.
>
>- Section 5.3.1 says:
>      This profile applies the following additional constraints 
>to      fields that MAY appear in a CertificationRequest Object:
>
>         signatureAlgorithm
>             This field specifies the signature algorithm.
>
>   What does this mean?  The signatureAlgorithm is mandatory and
>   this text does not impose any constraints on the field.
>
>We'll fix the text to reflect the fact that this is a mandatory field.
>
>Why not simply delete this?  Based on the second sentence of Section 
>5.3.1, the document should not even bother to mention a field unless 
>it is to specify an "additional constraint".
>Park) We'll revise the text.
>
>- Section 5.3.2, Extensions: Is inclusion of extension optional
>   or are there certain extensions that must be included?
>See the reply above for 5.3.1.
>
>As above, the text about Extensions should simply be deleted unless 
>the document will impose "additional constraints".
>Park) We'll revise the text.
>General:
>
>We'll review the document and fix the citation errors.
>
>- The protocol messages defined in this document all use the
>   same basic format: a CMS signed data object.  For all of these
>messages, the eContentType is specified as id-data and
>   (presumably) the MIME type is application/pkcs7-mime, perhaps
>   with the parameter smime-type=signed-data.  Each of the
>   protocol messages should have its own MIME type and/or
>   eContentType.  Otherwise, there is no way for the recipient to
>   know how to process the data.
>
>We adopted use of CMS to move the data between the AI and BI via our 
>TLS-protected channel because Jim Schaad noted that we needed to 
>have some way to carry the data that is already known and accepted 
>by the application ADs, and CMS satisfies this criteria. Presumably 
>we can use a new content type, w/o encryption and still keep them 
>happy, even though this is NOT a content type that is generally 
>supported.
>
>If using a contentType other than id-data is problematic (although I 
>can't see why since no standard library can meaningfully process 
>something tagged as id-data), at least specify a different MIME type 
>for each message.
>
>Park) We will specify a distinct contentType (OID) for each message 
>as an easy approach to distinguishing message types
>- Referring to the certificates issued using this protocol as
>   anonymous rather than pseudonymous is confusing.  The editors
>   note in the Introduction that pseudonymous is the correct term,
>   but still choose to use the misleading term "anonymous".  I do
>   not agree that the terms are commonly used interchangeably, and
>   believe that the use of the correct term, pseudonymous, would
>   make the privacy properties of the certificates more clear.
>   People already understand the idea of using different names
>   (pseudonyms) in different contexts in order to increase privacy.
>   Anonymity is achieved by not identifying (authenticating)
>   oneself at all, not by identifying oneself using a pseudonym.
>
>It is true that the terms are not equivalent, even though many folks 
>do use them interchangeably. However, the term pseudonymous isn't 
>ideal here as it suggests that only RPs don't know the true identity 
>of the Subject. TACs do provide a form of conditional anonymity, 
>hence the name.
>
>I have never heard this definition of pseudonymous.  Anonymous 
>implies that no name is used, whereas pseudonymous implies that a 
>fictitious name is used. There is no implication that anyone (other 
>than the person using the pseudonym) knows the true identity of the 
>person using the pseudonym.
>Park) We've adopted the term 'Anonymous' to imply the meaning of 
>privacy protection in PKI to RP, beyond the general meaning of the 
>name which is not real whose definition of the term 'pseudonymous' 
>in the subject field.
>
>- The protocol should allow for the possibility of rekey.  In many
>   cases, users will want to use the same pseudonym for an
>   extended period of time.  For example, many people use a
>   pseudonym when posting to message boards or when selling items
>   on-line (e.g., on eBay).  People who earn good reputations as
>   sellers would not want to have to periodically change
>   pseudonyms.  A TAC for these users would allow them perform
>   strong authentication to prevent others from accessing their
>   accounts.  The TAC would allow the sellers to keep their true
>   identities a secret while at the same time reassuring buyers
>   that sellers' true identities could be determined in case a
>   seller committed fraud.  While this type of scenario may not
>   have been the original motivation for TAC, is there any reason
>   that it should not be supported?
>I agree that the ability to retain the same pseudonym would have 
>advantages in the contexts you cite above, but we dropped support 
>for rekey as it added complexity (as noted by Jim) that we didn't 
>want to address at this stage.
>
>If the requirement to use a threshold signature scheme were removed, 
>then the AI could accept and process standard certificate management 
>request messages (including rekey requests) and so support for rekey 
>would not add any additional complexity.  It is only the use of the 
>threshold signature scheme that makes support for standard 
>certificate management operations complex, and as noted above, I 
>still do not see how the threshold signature scheme requirement 
>provides any real benefit.
>Park) The threshold scheme(combined with blind signature) is the 
>principal technology for implementing TAC. Even though its adoption 
>makes the protocols and operations complex, this document proposes 
>the experimental mechanisms to achieve the anonymity not only for 
>issuance process but also usage transactions of certificate.
>
>
>-------------------
>SangHwan Park
>Senior Researcher / CISA / CISSP / ITIL
>Korea Information Security Agency(KISA)
>[phone], <mailto:[e-mail]>[e-mail]
>
--============_-975869171==_ma============
Content-Type: text/html; charset="us-ascii"

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></style><title>message from SangHwan Park, forwarded to the
list</title></head><body>
<blockquote type="cite" cite><font size="-1">Dear David A. Cooper and
Kemp, David,</font></blockquote>
<blockquote type="cite" cite><font
size="-1">&nbsp;</font></blockquote>
<blockquote type="cite" cite><font size="-1">First, I</font><font
face="Times New Roman">'</font>d like to thank you for the
comments.</blockquote>
<blockquote type="cite" cite><font
size="-1">&nbsp;</font></blockquote>
<blockquote type="cite" cite><font size="-1">I've included my
responses in blue in-line below for each item.</font></blockquote>
<blockquote type="cite" cite><font
size="-1">&nbsp;</font></blockquote>
<blockquote type="cite" cite><font size="-1">Thank
you.</font></blockquote>
<blockquote type="cite" cite><font
size="-1">&nbsp;</font></blockquote>
<blockquote type="cite" cite><font
size="-1">---------------------</font></blockquote>
<blockquote type="cite" cite><font size="-1">Section 3
(Requirements):</font></blockquote>
<blockquote type="cite" cite><font size="-1"><br></font></blockquote>
<blockquote type="cite" cite><font size="-1">- This section begins by
stating that the &quot;document describes a</font></blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> new separation-of-authority
model&quot;.<font face="Times New Roman">&nbsp;</font> How does the
model in this</blockquote>
<blockquote type="cite" cite><font face="Times New Roman"
size="-1">&nbsp;</font> document differ from the one in [13], &quot;An
Architecture for</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> Pseudonymous
e-Commerce&quot;?<font face="Times New Roman">&nbsp;</font> What
properties does the protocol</blockquote>
<blockquote type="cite" cite><font face="Times New Roman"
size="-1">&nbsp;</font> in this document have that the protocol in
[13] does not?</blockquote>
<blockquote type="cite" cite><font size="-1"><b>In the architecture
for Pseudonymous e-Commerce, a CA can link the pseudonym in the
subject field to the real identity unilaterally, which can lead to a
potential 'big brother problem'. In order to address this issue, this
document proposes the separation of authority concepts (two CAs to
issue TAC, which tries to prevent one CA from linking pseudonym to
real identity unilaterally).</b></font></blockquote>
<blockquote type="cite" cite><font size="-1"><br></font></blockquote>
<blockquote type="cite" cite><font size="-1">This is
incorrect.</font><font face="Times New Roman">&nbsp;</font> In
&quot;An Architecture for Pseudonymous e-Commerce&quot;, the
subscriber requests a certificate from CA A (i.e., the BI).<font
face="Times New Roman">&nbsp;</font> The subscriber authenticates to
CA A using his/her real identity.<font
face="Times New Roman">&nbsp;</font> CA A issues certificate A to the
subscriber with a pseudonymous subject name.<font
face="Times New Roman">&nbsp;</font> The subscriber then requests a
certificate from CA B (i.e., the AI).<font
face="Times New Roman">&nbsp;</font> The subscriber authenticates to
CA B using certificate A.<font face="Times New Roman">&nbsp;</font> CA
B issues certificate B to the subscriber with a pseudonymous subject
name (a name that cannot be connected to the subject name in
certificate A).<font face="Times New Roman">&nbsp;</font> The
subscriber then uses certificate B to authenticate him/herself during
normal transactions.<font face="Times New Roman">&nbsp;</font> Thus,
the subscribers' real identity cannot be tied to the subject name in
certificate B without the cooperation of both CA A and CA
B.</blockquote>
<blockquote type="cite" cite><br></blockquote>
<blockquote type="cite" cite>Note that the subscriber could even use
certificate B to obtain yet another pseudonymous certificate from CA C
so that it would require the collusion of three CAs to tie the
pseudonymous identity that he/she uses to his/her real
identity.</blockquote>
<blockquote type="cite" cite><font size="-1"
color="#000080">&nbsp;</font></blockquote>
<blockquote type="cite" cite><font size="-1" color="#000080"><b>Park)
In</b></font><font face="Times New Roman" color="#000080"><b>
"</b></font><font color="#000080"><b>An architecture of Pseudonymous
e-Commerce<font face="Times New Roman">"</font>, the CA A you
mentioned above knows of the links between user<font
face="Times New Roman">'</font>s real identity and pseudonymous
subject name of certificate. It means that CA A can trace user<font
face="Arial">'</font>s real identity with the certificate with
pseudonymous certificate that is used. The main differences from
the<font face="Arial"> "</font>An architecture of Pseudonymous
e-Commerce<font face="Times New Roman">"</font> is that TAC can
secure the anonymity not only in the issuance processes but also in
the usages of certificate, separating AI and BI<font
face="Times New Roman">'</font>s duties with the help of<font
face="Times New Roman"> &nbsp;</font>both threshold and blind
signature scheme. The paper you inquired just focuses on the usage of
certificate, not on the anonymity in the issuing
processes.</b></font></blockquote>
<blockquote type="cite" cite><font size="-1"
color="#000080">&nbsp;</font></blockquote>
<blockquote type="cite" cite><font size="-1">Section 5 (Issuing a
TAC):</font></blockquote>
<blockquote type="cite" cite><font size="-1"><br></font></blockquote>
<blockquote type="cite" cite><font size="-1">- The protocol involves a
complicated scheme involving split</font></blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> signatures and blind
signatures.<font face="Times New Roman">&nbsp;</font> The use of split
signatures</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> complicates the issuance of both
certificates and CRLs, yet</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> the need for this scheme is not
clear.<font face="Times New Roman">&nbsp;</font> It was
previously</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> argued that the split signature
scheme prevents the CA from</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> issuing a certificate to a user
by itself, which could</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> result in a non-traceable
certificate.<font face="Times New Roman">&nbsp;</font> However, the
CA</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> could still create a
non-traceable certificate by simply</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> not maintaining the link between
the TAC and the Token.</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> An untrustworthy CA could even
use a Token issued by the BI</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> to one user as the basis for
issuing a certificate to a</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> different user.<font
face="Times New Roman">&nbsp;</font> Similarly, a BI could issue a
Token to a</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> user without first identifying
that user.<font face="Times New Roman">&nbsp;</font> Since both the
AI</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> and BI need to cooperate to
identify the user associated with</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> a TAC, there is no benefit in
trying to prevent the AI from</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> issuing a non-traceable
certificate, as there is no way to</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> force the AI (or BI) from
cooperating in the tracing of a</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> certificate if the AI (or BI)
simply chooses not the store</blockquote>
<blockquote type="cite" cite>the information required to perform the
trace.</blockquote>
<blockquote type="cite" cite><br></blockquote>
<blockquote type="cite" cite><b>It's fair to say that use of the
mechanisms mandated by the protocol is not a technical guarantee of
the split between the RA and CA functions, e.g., for the reasons you
note. However, use of these mechanisms probably makes it easier to
conduct an audit that verifies the desired separation of duties. One
could define a TAC system that did not specify these mechanistic
details. However, verifying that such a system provides the desired
separation would be more difficult, on a case-by-case basis. Since you
work at NIST, I think a reasonable analogy here is with some of the
specs used for FIPS 140-n compliance. For example, there is a spec for
a PRNG because it makes it easy for a lab to evaluate a product
claiming compliance with 140, not because that PRNG is the only good
way to generate random values for use in crypto
algorithms.</b></blockquote>
<blockquote type="cite" cite><font size="-1"><br></font></blockquote>
<blockquote type="cite" cite><font size="-1">Can you please explain
how the use of threshold signatures (combined with blinded signatures)
makes it easier to conduct an audit that verifies that the AI and BI
are performing their duties properly?</font></blockquote>
<blockquote type="cite" cite><font size="-1" color="#000080"><b>Park)
With the technology of threshold and blind signature scheme, we can
separate the duties of which each AI or BI takes. In other words, AI
and BI have its shares of the private keys beforehand; subscribers
authenticates to BI using his/her real identity and requests TAC to AI
with the Token issued by BI. AI and BI bilaterally digital-signs TAC
with the threshold signature scheme. The blind signature is used to
let BI be blind to the contents of TAC in order to prevent BI from
linking the real identity to subject pseudonymous
name.</b></font></blockquote>
<blockquote type="cite" cite><font size="-1"
color="#000000">&nbsp;</font></blockquote>
<blockquote type="cite" cite><font size="-1">- Section 5 says that
&quot;Blinding is also defined for signature</font></blockquote>
<blockquote type="cite" cite><font face="Times New Roman"
size="-1">&nbsp;</font> algorithms like DSA, but the explanation is
more complex, since</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> DSA does not natively encrypt
data.&quot;<font face="Times New Roman">&nbsp;</font> Can a reference
be</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> provided?<font
face="Times New Roman">&nbsp;</font> I can only find references to
papers that propose</blockquote>
<blockquote type="cite" cite><font face="Times New Roman"
size="-1">&nbsp;</font> blinding schemes for variants of
DSA.</blockquote>
<blockquote type="cite" cite><font size="-1"><b>You can refer to the
blind DSA signature based on MacKenzie and Reiter,</b></font> <a
href="http://www.ece.cmu.edu/~reiter/papers/2001/CRYPTO.pdf"><font
size="-1"
color="#0000FF"><u><b
>http://www.ece.cmu.edu/~reiter/papers/2001/CRYPTO.pdf</b></u></font></a
><font size="-1"><b>.</b></font></blockquote>
<blockquote type="cite" cite><font size="-1"><br></font></blockquote>
<blockquote type="cite" cite><font size="-1">This paper seems to
describe a threshold signature scheme (in particular two-party
generation of DSA signatures), not a blind signature
scheme.</font></blockquote>
<blockquote type="cite" cite><font size="-1" color="#000080"><b>Park)
You can refer to the blind signing protocol of Chapter 4.2 in the
attached pdf above.</b></font></blockquote>
<blockquote type="cite" cite><font size="-1" color="#000080"><b>It
might be difficult to understand how DSA blind signing protocols
work.</b></font></blockquote>
<blockquote type="cite" cite><font face="Times New Roman"
color="#000000">&nbsp;</font></blockquote>
<blockquote type="cite" cite><font size="-1">- Section 5.1, Step 1
states &quot;The signature on a Token is</font></blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> generated by the BI using a
private key employed only for</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> this purpose.&quot;<font
face="Times New Roman">&nbsp;</font> Step 2 states &quot;The signature
(SignatureValue</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> of SignerInfo) is generated using
the BI's private signature</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> key, corresponding to the public
key present in the BI's</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> certificate. (Note that this
certificate is just a certificate</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> suitable for use with TLS, and is
NOT the split-key certificate</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> used to verify a
TAC.)&quot;<font face="Times New Roman">&nbsp;</font> May the BI use
the same private key</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> and certificate to sign Tokens
and for TLS authentication?<font face="Times New Roman">&nbsp;</font>
If</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> not (as stated in Step 1), then
why is it necessary for the</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> certificate corresponding to the
Token signing key to be</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> &quot;suitable for use with
TLS&quot;?<font face="Times New Roman">&nbsp;</font> Many other places
in the document</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> state that certificates used to
verify signatures on CMS</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> messages should be &quot;suitable
for use with TLS&quot;.</blockquote>
<blockquote type="cite" cite><br></blockquote>
<blockquote type="cite" cite><b>There are several questions
here:</b></blockquote>
<blockquote type="cite" cite><font
size="-1"><b><br></b></font></blockquote>
<blockquote type="cite" cite><font size="-1"><b>- We recommend use of
different keys for TLS authentication and for Token signing, as you
noted above. Our advice is conservative, following the principle that
one should use distinct keys for distinct purposes. Key generation is
not so expensive as to warrant reuse of keys for these two
purposes.</b></font></blockquote>
<blockquote type="cite" cite><font
size="-1"><b><br></b></font></blockquote>
<blockquote type="cite" cite><font size="-1"><b>-</b></font><font
face="Times New Roman"><b>&nbsp;</b></font><b> we use the phrase
&quot;suitable for use with TLS&quot; to distinguish the certificates
used for CMS message verification as distinct from the split-key
certificates, as a shorthand. If you have a preferred wording for EE
certificates being used in these cases, I think we would be happy to
use that wording instead.</b></blockquote>
<blockquote type="cite" cite><font size="-1"><br></font></blockquote>
<blockquote type="cite" cite><font size="-1">Why not say</font><font
face="Times New Roman"> "</font>(Note that this certificate is just
a certificate suitable for use with CMS, and is NOT the split-key
certificate used to verify a TAC.)<font
face="Times New Roman">"</font>?</blockquote>
<blockquote type="cite" cite><br></blockquote>
<blockquote type="cite" cite><font color="#000080"><b>Park) We<font
face="Times New Roman">'</font>ll reword the phrases as you
suggested.</b></font></blockquote>
<blockquote type="cite" cite><font size="-1"
color="#000080">&nbsp;</font></blockquote>
<blockquote type="cite" cite><font size="-1">- Section 5.1, Step 6
states:</font></blockquote>
<blockquote type="cite" cite><font face="Times New Roman"
size="-1">&nbsp;&nbsp;&nbsp;&nbsp;</font> Note that the user should be
prepared to accommodate delays</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;&nbsp;&nbsp;&nbsp;</font> in the
certificate issuance process. For example, a</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;&nbsp;&nbsp;&nbsp;</font> connection
between the user and the AI might fail sometime</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;&nbsp;&nbsp;&nbsp;</font> after the user
submits a certificate request at the end of</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;&nbsp;&nbsp;&nbsp;</font> Step 3 and
before the AI returns the certificate at the end</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;&nbsp;&nbsp;&nbsp;</font> of Step 6. If
this happens, the user should resubmit the</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;&nbsp;&nbsp;&nbsp;</font> request. The AI
and BI retain sufficient state to be able to</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;&nbsp;&nbsp;&nbsp;</font> match the
resubmitted request to the original request, and</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;&nbsp;&nbsp;&nbsp;</font> respond
accordingly.</blockquote>
<blockquote type="cite" cite><br></blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> This seem appropriate, but it is
contradicted by the following</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> text in Section 5.1, Step
4:</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;&nbsp;&nbsp;&nbsp;</font> Next, the AI
compares the received Token against a cache of</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;&nbsp;&nbsp;&nbsp;</font> recent (i.e.,
not &quot;timed out&quot;), validated Tokens. If a</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;&nbsp;&nbsp;&nbsp;</font> duplicate is
detected, the certificate request is rejected as</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;&nbsp;&nbsp;&nbsp;</font> a
replay.</blockquote>
<blockquote type="cite" cite><br></blockquote>
<blockquote type="cite" cite><b>The comments in step 4 are design
guidance; they don't impose specific constraints on how long an AI
holds onto a Token.<font face="Times New Roman">&nbsp;</font> We can
revise the step 6 text to note that although the AI and BI maintain
state, they do not do so forever.</b></blockquote>
<blockquote type="cite" cite><font size="-1"><br></font></blockquote>
<blockquote type="cite" cite><font size="-1">The problem isn't that
Step 6 implies that the AI and BI have to maintain state forever
(although that is a good point as well).</font><font
face="Times New Roman">&nbsp;</font> The problem is that Step 4 says
that &quot;If a duplicate is detected, the certificate request is
rejected as a replay&quot;.<font face="Times New Roman">&nbsp;</font>
Step 6 implies that a AI should (when possible) respond to a
resubmitted request by resending the previous generated response,
whereas Step 4 implies that the AI must respond to a resubmitted
request by rejected it (i.e., by not responding to the
request).</blockquote>
<blockquote type="cite" cite><font size="-1" color="#000080"><b>Park)
We</b></font><font face="Times New Roman"
color="#000080"><b>'</b></font><font color="#000080"><b>ll revise the
Step 4 accordingly to the Step 6.</b></font></blockquote>
<blockquote type="cite" cite><font face="Times New Roman"
color="#000000">&nbsp;</font></blockquote>
<blockquote type="cite" cite><font size="-1">- Section 5.2, Step A
states that &quot;we propose creating a second</font></blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> CA, under the TAC CA and have it
be the CRL issuer for the EE</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> certificates issued by the TAC
CA.&quot;<font face="Times New Roman">&nbsp;</font> However, the
actual</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> proposal is to create a second
(CRL signing only) key for the</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> CA, not to create a second
CA.</blockquote>
<blockquote type="cite" cite><br></blockquote>
<blockquote type="cite" cite><b>Sorry if this is not clear enough. The
other CRL is issued using a private key known to the AI unilaterally.
Since the key is distinct, but we want the CRL Issuer name to be the
same, we elected to have a new CA, represented by a new CA certificate
issued under the jointly managed CA certificate.</b></blockquote>
<blockquote type="cite" cite><font size="-1"><br></font></blockquote>
<blockquote type="cite" cite><font size="-1">A CA is identified by its
name, not by its key. So, in the scenario you are describing, you are
not creating a new CA that issues CRLs under the same name as the
AI.</font><font face="Times New Roman">&nbsp;</font> You have a single
CA with two keys, one for signing certificates and one for signing
CRLs.</blockquote>
<blockquote type="cite" cite><font size="-1" color="#000080"><b>Park)
Right.</b></font></blockquote>
<blockquote type="cite" cite><font face="Times New Roman"
color="#000000">&nbsp;</font></blockquote>
<blockquote type="cite" cite><font size="-1">- Section 5.2, Step A
states that &quot;If the AI uses OCSP [14] or</font></blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> SCVP [15] to convey the
revocation status of TACs, an equivalent</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> procedure is
employed.&quot;<font face="Times New Roman">&nbsp;</font> SCVP cannot
be used by a CA to convey</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> status information in the same
way that CRLs and OCSP can, and</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> so it should not be mentioned
here.</blockquote>
<blockquote type="cite" cite><br></blockquote>
<blockquote type="cite" cite><b>SCVP responses are more<font
face="Times New Roman">&nbsp;</font> encompassing than OCSP and CRLs,
but they can still provide an RP with an indication of whether a given
certificate has been revoked, or not. So, I'm not sure why you feel
that SCVP ought not be mentioned here.</b></blockquote>
<blockquote type="cite" cite><font size="-1"><br></font></blockquote>
<blockquote type="cite" cite><font size="-1">OCSP can (generally) be
used in one of two ways: (1) it can be operated on behalf of a CA to
provide all relying parties with status information for the
certificates issued by that CA; or (2) it can be operated on behalf a
relying party to provide status information for all certificates that
the relying party wishes to validate.</font><font
face="Times New Roman">&nbsp;</font> Section 5.2, Step A is describing
(1), which is appropriate for OCSP but not SCVP.<font
face="Times New Roman">&nbsp;</font> Trust model (2) would work for
either OCSP or SCVP, but the use of SCVP here would relate to the way
in which the relying party obtains status information, not the way in
which the AI makes status information available.</blockquote>
<blockquote type="cite" cite><font size="-1" color="#000080"><b>Park)
We</b></font><font face="Times New Roman"
color="#000080"><b>'</b></font><font color="#000080"><b>ll revise the
text to cite only OCSP, not SCVP.</b></font></blockquote>
<blockquote type="cite" cite><font size="-1"
color="#000080">&nbsp;</font></blockquote>
<blockquote type="cite" cite><font face="Times New Roman"
color="#000000">&nbsp;</font></blockquote>
<blockquote type="cite" cite><font size="-1">- Section 5.3.1,
Attributes: &quot;This attribute contains</font></blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> X509v3 Certificate
Extensions.&quot;<font face="Times New Roman">&nbsp;</font> Which
attribute?<font face="Times New Roman">&nbsp;</font> Not
the</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> id-kisa-tac attribute mentioned
in the previous sentence?<font face="Times New Roman">&nbsp;</font>
Is</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> inclusion of extension in the
PKCS10 optional or are there</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> certain extensions that must be
included?</blockquote>
<blockquote type="cite" cite><font size="-1"><b>Whether extensions are
required, optional, or permitted is a function of the CP for the TAC
CA. However, We can add a note that, in general, it is a bad idea to
allow users to include extensions in a cert request because that
probably will allow the BI to match the issued cert to the
user.</b></font></blockquote>
<blockquote type="cite" cite><font size="-1"><br></font></blockquote>
<blockquote type="cite" cite><font size="-1">The biggest problem is
simply that the text says &quot;this attribute&quot; and I cannot what
tell which attribute it means by &quot;this&quot;.</font><font
face="Times New Roman">&nbsp;</font> Perhaps the text could be
reworded as (if my proposed rewording is technically
correct):</blockquote>
<blockquote type="cite" cite><br></blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</font>
Attributes</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</font
> PKCS10[3] defines the attributes field as key-value pairs<font
face="Times New Roman">&nbsp;</font></blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;&nbsp;</font> where the key is an OID and
the value's structure depends on the<font
face="Times New Roman">&nbsp;</font></blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;&nbsp;</font> key.<font
face="Times New Roman">&nbsp;</font> The Attributes field MUST include
the id-kisa-tac attribute,</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;&nbsp;</font> which holds the Token and
is defined below.<font face="Times New Roman">&nbsp;</font> The
Attributes field</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;&nbsp;</font> MAY also contain X509v3
Certificate Extensions that the subscriber</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;&nbsp;</font> would like to have included
in the certificate.<font face="Times New Roman">&nbsp;&nbsp;</font>
The profile for</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;&nbsp;</font> extensions in certificate
requests is specified in the RFC5280[2].</blockquote>
<blockquote type="cite" cite><font size="-1"><br></font></blockquote>
<blockquote type="cite" cite><font size="-1" color="#000080"><b>Park)
We</b></font><font face="Times New Roman"
color="#000080"><b>'</b></font><font color="#000080"><b>ll revise the
text, as you and Kemp, David suggested.</b></font></blockquote>
<blockquote type="cite" cite><font size="-1"
color="#000080">&nbsp;</font></blockquote>
<blockquote type="cite" cite><font size="-1">- Section 5.3.1
says:</font></blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;&nbsp;&nbsp;&nbsp;</font> This profile
applies the following additional constraints to<font
face="Times New Roman">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</font> fields
that MAY appear in a CertificationRequest Object:</blockquote>
<blockquote type="cite" cite><br></blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</font
> signatureAlgorithm</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman"
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</font
> This field specifies the signature algorithm.</blockquote>
<blockquote type="cite" cite><br></blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> What does this mean?<font
face="Times New Roman">&nbsp;</font> The signatureAlgorithm is
mandatory and</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> this text does not impose any
constraints on the field.</blockquote>
<blockquote type="cite" cite><br></blockquote>
<blockquote type="cite" cite><b>We'll fix the text to reflect the fact
that this is a mandatory field.</b></blockquote>
<blockquote type="cite" cite><font size="-1"><br></font></blockquote>
<blockquote type="cite" cite><font size="-1">Why not simply delete
this?</font><font face="Times New Roman">&nbsp;</font> Based on the
second sentence of Section 5.3.1, the document should not even bother
to mention a field unless it is to specify an &quot;additional
constraint&quot;.</blockquote>
<blockquote type="cite" cite><font color="#000080"><b>Park) We<font
face="Times New Roman">'</font>ll revise the
text.</b></font></blockquote>
<blockquote type="cite" cite><font size="-1"
color="#000000">&nbsp;</font></blockquote>
<blockquote type="cite" cite><font size="-1">- Section 5.3.2,
Extensions: Is inclusion of extension optional</font></blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> or are there certain extensions
that must be included?</blockquote>
<blockquote type="cite" cite><font size="-1"><b>See the reply above
for 5.3.1.</b></font></blockquote>
<blockquote type="cite" cite><font size="-1"><br></font></blockquote>
<blockquote type="cite" cite><font size="-1">As above, the text about
Extensions should simply be deleted unless the document will impose
&quot;additional constraints&quot;.</font></blockquote>
<blockquote type="cite" cite><font size="-1" color="#000080"><b>Park)
We</b></font><font face="Times New Roman"
color="#000080"><b>'</b></font><font color="#000080"><b>ll revise the
text.</b></font></blockquote>
<blockquote type="cite" cite><font
size="-1">General:</font></blockquote>
<blockquote type="cite" cite><font size="-1"><br></font></blockquote>
<blockquote type="cite" cite><font size="-1"><b>We'll review the
document and fix the citation errors.</b></font></blockquote>
<blockquote type="cite" cite><font
size="-1"><b><br></b></font></blockquote>
<blockquote type="cite" cite><font size="-1">- The protocol messages
defined in this document all use the</font></blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> same basic format: a CMS signed
data object.<font face="Times New Roman">&nbsp;</font> For all of
these</blockquote>
<blockquote type="cite" cite>messages, the eContentType is specified
as id-data and</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> (presumably) the MIME type is
application/pkcs7-mime, perhaps</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> with the parameter
smime-type=signed-data.<font face="Times New Roman">&nbsp;</font> Each
of the</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> protocol messages should have its
own MIME type and/or</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> eContentType.<font
face="Times New Roman">&nbsp;</font> Otherwise, there is no way for
the recipient to</blockquote>
<blockquote type="cite" cite><font face="Times New Roman"
size="-1">&nbsp;</font> know how to process the data.</blockquote>
<blockquote type="cite" cite><font
size="-1">&nbsp;</font></blockquote>
<blockquote type="cite" cite><font size="-1"><b>We adopted use of CMS
to move the data between the AI and BI via our TLS-protected channel
because Jim Schaad noted that we needed to have some way to carry the
data that is already known and accepted by the application ADs, and
CMS satisfies this criteria. Presumably we can use a new content type,
w/o encryption and still keep them happy, even though this is NOT a
content type that is generally supported.</b></font></blockquote>
<blockquote type="cite" cite><font size="-1"><br></font></blockquote>
<blockquote type="cite" cite><font size="-1">If using a contentType
other than id-data is problematic (although I can't see why since no
standard library can meaningfully process something tagged as
id-data), at least specify a different MIME type for each
message.</font></blockquote>
<blockquote type="cite" cite><font size="-1"><br></font></blockquote>
<blockquote type="cite" cite><font size="-1" color="#000080"><b>Park)
We will specify a distinct contentType (OID) for each message as an
easy approach to distinguishing message types</b></font></blockquote>
<blockquote type="cite" cite><font size="-1">- Referring to the
certificates issued using this protocol as</font></blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> anonymous rather than
pseudonymous is confusing.<font face="Times New Roman">&nbsp;</font>
The editors</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> note in the Introduction that
pseudonymous is the correct term,</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> but still choose to use the
misleading term &quot;anonymous&quot;.<font
face="Times New Roman">&nbsp;</font> I do</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> not agree that the terms are
commonly used interchangeably, and</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> believe that the use of the
correct term, pseudonymous, would</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> make the privacy properties of
the certificates more clear.</blockquote>
<blockquote type="cite" cite><font face="Times New Roman"
size="-1">&nbsp;</font> People already understand the idea of using
different names</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> (pseudonyms) in different
contexts in order to increase privacy.</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> Anonymity is achieved by not
identifying (authenticating)</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> oneself at all, not by
identifying oneself using a pseudonym.</blockquote>
<blockquote type="cite" cite><br></blockquote>
<blockquote type="cite" cite><b>It is true that the terms are not
equivalent, even though many folks do use them interchangeably.
However, the term pseudonymous isn't ideal here as it suggests that
only RPs don't know the true identity of the Subject. TACs do provide
a form of conditional anonymity, hence the name.</b></blockquote>
<blockquote type="cite" cite><font size="-1"><br></font></blockquote>
<blockquote type="cite" cite><font size="-1">I have never heard this
definition of pseudonymous.</font><font
face="Times New Roman">&nbsp;</font> Anonymous implies that no name is
used, whereas pseudonymous implies that a fictitious name is used.
There is no implication that anyone (other than the person using the
pseudonym) knows the true identity of the person using the
pseudonym.</blockquote>
<blockquote type="cite" cite><font size="-1" color="#000080"><b>Park)
We</b></font><font face="Times New Roman"
color="#000080"><b>'</b></font><font color="#000080"><b>ve adopted the
term<font face="Times New Roman"> '</font>Anonymous<font
face="Times New Roman">'</font> to imply the meaning of privacy
protection in PKI to RP, beyond the general meaning of the name which
is not real whose definition of the term<font face="Times New Roman">
'</font>pseudonymous<font face="Times New Roman">'</font> in the
subject field.</b></font></blockquote>
<blockquote type="cite" cite><font face="Times New Roman"
color="#000000">&nbsp;</font></blockquote>
<blockquote type="cite" cite><font size="-1">- The protocol should
allow for the possibility of rekey.</font><font
face="Times New Roman">&nbsp;</font> In many</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> cases, users will want to use the
same pseudonym for an</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> extended period of time.<font
face="Times New Roman">&nbsp;</font> For example, many people use
a</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> pseudonym when posting to message
boards or when selling items</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> on-line (e.g., on eBay).<font
face="Times New Roman">&nbsp;</font> People who earn good reputations
as</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> sellers would not want to have to
periodically change</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> pseudonyms.<font
face="Times New Roman">&nbsp;</font> A TAC for these users would allow
them perform</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> strong authentication to prevent
others from accessing their</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> accounts.<font
face="Times New Roman">&nbsp;</font> The TAC would allow the sellers
to keep their true</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> identities a secret while at the
same time reassuring buyers</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> that sellers' true identities
could be determined in case a</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> seller committed fraud.<font
face="Times New Roman">&nbsp;</font> While this type of scenario may
not</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> have been the original motivation
for TAC, is there any reason</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> that it should not be
supported?</blockquote>
<blockquote type="cite" cite><font size="-1"><b>I agree that the
ability to retain the same pseudonym would have advantages in the
contexts you cite above, but we dropped support for rekey as it added
complexity (as noted by Jim) that we didn't want to address at this
stage.</b></font></blockquote>
<blockquote type="cite" cite><font
size="-1"><b><br></b></font></blockquote>
<blockquote type="cite" cite>If the requirement to use a threshold
signature scheme were removed, then the AI could accept and process
standard certificate management request messages (including rekey
requests) and so support for rekey would not add any additional
complexity.<font face="Times New Roman">&nbsp;</font> It is only the
use of the threshold signature scheme that makes support for standard
certificate management operations complex, and as noted above, I still
do not see how the threshold signature scheme requirement provides any
real benefit.</blockquote>
<blockquote type="cite" cite><font size="-1" color="#000080"><b>Park)
The threshold scheme(combined with blind signature) is the principal
technology for implementing TAC. Even though its adoption makes the
protocols and operations complex, this document proposes the
experimental mechanisms to achieve the anonymity not only for issuance
process but also usage transactions of
certificate.</b></font></blockquote>
<blockquote type="cite" cite><font
size="-1">&nbsp;</font></blockquote>
<blockquote type="cite" cite><font face="Times New Roman"
size="-1">&nbsp;</font></blockquote>
<blockquote type="cite" cite><font
size="-1">-------------------</font></blockquote>
<blockquote type="cite" cite><font size="-1">SangHwan</font>
Park</blockquote>
<blockquote type="cite" cite><font size="-1">Senior Researcher / CISA
/ CISSP / ITIL</font></blockquote>
<blockquote type="cite" cite><font size="-1">Korea Information
Security Agency(KISA)</font></blockquote>
<blockquote type="cite" cite><font size="-1">[phone],</font> <a
href="mailto:[e-mail]"><font
size="-1">[e-mail]</font></a></blockquote>
<blockquote type="cite" cite><font
size="-1">&nbsp;</font></blockquote>
</body>
</html>
--============_-975869171==_ma============--



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 n25BYrW3005319 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Mar 2009 04:34:53 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n25BYrBC005318; Thu, 5 Mar 2009 04:34:53 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mailhub1.dartmouth.edu (mailhub1.dartmouth.edu [129.170.16.122]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n25BYf1q005298 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 5 Mar 2009 04:34:52 -0700 (MST) (envelope-from [e-mail])
Received: from newblitzen.Dartmouth.EDU (newblitzen-shared.dartmouth.edu [129.170.20.37]) by mailhub1.dartmouth.edu (8.13.5/DND2.0/8.13.5) with ESMTP id n255FsL7032075 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Mar 2009 06:31:22 -0500
X-Disclaimer: This message was received from outside Dartmouth's BlitzMail system.
Received: from wifi365.ogf25.garr.it [90.147.29.111] by newblitzen.Dartmouth.EDU (Mac) via SMTP  for  id <143331912>; 05 Mar 2009 06:31:21 -0500
Message-ID: <[e-mail]>
Date: Thu, 05 Mar 2009 06:31:01 -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: Stefan Santesson <[e-mail]>, Stephen Kent <[e-mail]>, pkix <[e-mail]>
Subject: Re: Call for agenda items & PRQP
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030202080706010903050505"
X-MailScanner: Found to be clean by mailhub.Dartmouth.EDU
X-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>

This is a cryptographically signed message in MIME format.

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

Ciao Stefan, Steve, and pkix-wg,

I would need 10 mins for reporting on the activities about PRQP - we have been
working both with the TERENA (TACAR) and Federal Bridge folks and they are going
to deploy PRQP (at least as experimental). Some interest in the PRQP has also
been expressed by some commercial vendors... so I think that the WG should be
informed of these activities.

Also, from the collaboration with the DHC WG, we have changed the draft and it
seems that we need IANA to assign identifiers for DHCP (both v4 and v6).

One concern that I have is that IANA would not be so keen in assigning DHCP
service identifiers for an experimental-track protocol, but the deployment
of PRQP is actually happening and I would like to have at least those identifiers
standardized before this actually happens. I am not sure about what we shall do
now. The PRQP will be included in the next release of OpenCA as well, therefore
there will soon be a quite large installation base (besides the aforementioned
communities).

Shall we move the status from experimental to standard track ? Is it too early ?
I see that within the WG there is not much activity about PRQP, but in the real
PKI world and Computing Grid communities the situation is different.

I would like to know the opinion of the chair(s) and the people in the WG...

Ciao,
Max


Stefan Santesson wrote:
> IETF in San Francisco is coming up.
> 
> PKIX has a 2.5 hour session directly on the Monday morning March 23 at 0900
> 
> Please let me know if you have anything you whish to present at the meeting.
> *_At least one representative of each active WG document MUST inform me 
> if you need a time slot for that document or not.
> _*
> I would like to have your request for timeslot by Wednesday March 11.
> After that we can always do late adjustments but I appreciate to have 
> your request as early as possible.

-- 

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

--------------ms030202080706010903050505
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
AKCCAdEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwMzA1
MTEzMTAxWjAjBgkqhkiG9w0BCQQxFgQUvBNtgQpDtr5tXShDXH4gXtN3i00wUgYJKoZIhvcN
AQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYF
Kw4DAgcwDQYIKoZIhvcNAwICASgwgYwGCSsGAQQBgjcQBDF/MH0wdzETMBEGCgmSJomT8ixk
ARkWA2VkdTEZMBcGCgmSJomT8ixkARkWCWRhcnRtb3V0aDELMAkGA1UEBhMCVVMxGjAYBgNV
BAoTEURhcnRtb3V0aCBDb2xsZWdlMRwwGgYDVQQDExNEYXJ0bW91dGggQ2VydEF1dGgxAgIa
UzCBjgYLKoZIhvcNAQkQAgsxf6B9MHcxEzARBgoJkiaJk/IsZAEZFgNlZHUxGTAXBgoJkiaJ
k/IsZAEZFglkYXJ0bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91dGggQ29s
bGVnZTEcMBoGA1UEAxMTRGFydG1vdXRoIENlcnRBdXRoMQICGlMwDQYJKoZIhvcNAQEBBQAE
gYBVSpImD8aIR7jngXYyPlWLNXkjUBFb/kQlVzxtFRYCgmuIsqw4TjEZX1BVYCMutL/kdYA3
7nPjLfTnk/DfLG/5oNsDjqKuS98+Q5r51I0XPz3mUtwUbl0hiXmvB4tRwVp5wPoZaZseBwL9
n6jG0pSk7oxoHhFhPvYlQDLs0jZB2gAAAAAAAA==
--------------ms030202080706010903050505--



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 n252mBH4081517 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Mar 2009 19:48:11 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n252mBVp081516; Wed, 4 Mar 2009 19:48: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 n252mAaX081509 for <[e-mail]>; Wed, 4 Mar 2009 19:48:10 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 3022 invoked from network); 5 Mar 2009 02:47:46 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 5 Mar 2009 02:47:46 -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: I-D Action:draft-ietf-pkix-ta-format-01.txt
Date: Wed, 4 Mar 2009 21:48:08 -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-format-01.txt
Thread-Index: AcmdNYea/8MGwAZWRYG2c/fp2DCxfQABiDaA
References: <[e-mail]> <[e-mail]>
From: "Carl Wallace" <[e-mail]>
To: "Tom Gindin" <[e-mail]>, "Julien Stern" <[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>

The draft notes that omission of the taName field precludes path
validation.  Given that TAs serve other purposes that don't require DNs,
making the field optional makes sense.  All three formats in the draft
support including a DN.  This allows the 5280 requirement to be
satisfied with each structure.  =20

> -----Original Message-----
> From: [e-mail]=20
> [mailto:[e-mail]] On Behalf Of Tom Gindin
> Sent: Wednesday, March 04, 2009 8:41 PM
> To: Julien Stern
> Cc: [e-mail]
> Subject: Re: I-D Action:draft-ietf-pkix-ta-format-01.txt
>=20
>=20
>         Julian:
>=20
>         I think you're wrong in believing that the name is=20
> central to the definition of a trust anchor.  I can have (and=20
> my browser may be shipped
> with) several trust anchors issued by the same organization,=20
> and the names which distinguish them are (to me as the =20
> manager of the trust store) quite arbitrary.  A typical=20
> example is that there are two separate CA certificates from=20
> Entrust with CN=3D"Entrust.net Secure Server Certification=20
> Authority".  Their OU's are slightly different, and one of=20
> them has a Country attribute.
>         While philosophically I completely disagree with you,=20
> RFC 5280 section 6.1.1 point d-1 requires that the trust=20
> anchor have an issuer name, as does the same section in 3280.=20
>  Thus, no trust anchor definition which does not include an=20
> issuer name can be used by our own existing algorithms.  I=20
> think that's a pretty good reason for PKIX to require the=20
> presence of a DN in this definition.
>=20
>                 Tom Gindin
>=20
> P.S. - These views are mine personally, and not necessarily=20
> those of my employer
>=20
>=20
>=20
>=20
> Julien Stern <[e-mail]>=20
> Sent by: [e-mail]
> 03/04/2009 01:43 PM
>=20
> To
>=20
> cc
> [e-mail]
> Subject
> Re: I-D Action:draft-ietf-pkix-ta-format-01.txt
>=20
>=20
>=20
>=20
>=20
>=20
>=20
> [e-mail] wrote:
> > A New Internet-Draft is available from the on-line Internet-Drafts=20
> directories.
> > This draft is a work item of the Public-Key Infrastructure (X.509)=20
> Working Group of the IETF.
> >=20
> >=20
> >                Title           : Trust Anchor Format
> >                Author(s)       : R. Housley, et al.
> >                Filename        : draft-ietf-pkix-ta-format-01.txt
> >                Pages           : 17
> >                Date            : 2009-03-04
> >=20
>=20
> Hi again,
>=20
> separating from the previous email due to the nature of the comment:=20
> this one is more "philosophical" :)
>=20
> This draft defines a trust anchor as a public key with=20
> additional data.
>=20
> I believe that the most common usage of the word "trust=20
> anchor" denotes=20
> the _binding_ of a public key _and_ a name. A certificate=20
> binds a name=20
> and a public key (along with other information) thanks to a=20
> signature. A=20
> trust anchor binds them through direct trust.
>=20
> And indeed, the definition in X.509 is:
>=20
> trust anchor: A trust anchor is a set of the following information in=20
> addition to the public key: algorithm identifier, public key=20
> parameters=20
> (if applicable), distinguished name of the holder of the associated=20
> private key (i.e., the subject CA) and optionally a validity=20
> period. The=20
> trust anchor may be provided in the form of a self-signed certificate.
> A trust anchor is trusted by a certificate using system and used for=20
> validating certificates in certification paths.
>=20
>=20
> I assume that you did not choose to make the DN optional=20
> without reason.=20
> But is that really something that we would like to have? Are there=20
> really cases where we want to use a public key without explicitly=20
> knowing whom it belongs to? Isn't there a risk to spread confusion on=20
> what a "trust anchor" is?
>=20
> Granted, this RFC could define a Trust Anchor in a more global scope,=20
> without a need to bind it to a DN, but I'm (very personally) not sure=20
> this is a great idea and I believe that mandating the=20
> presence of a DN=20
> would not bring a strong limitation.
>=20
> Have you considered moving the taName from the=20
> CertPathControls to the=20
> main structure (TrustAnchorInfo) and keeping the CertPathControls=20
> structure for fine tuning of the X.509 input algorithm?
>=20
> (And along the same lines, why is the KeyIdentifier mandatory and not=20
> optional?)
>=20
> Regards,
>=20
> --
> Julien
>=20
>=20
>=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 n252GcUA080327 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Mar 2009 19:16:38 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n252GcUv080326; Wed, 4 Mar 2009 19:16:38 -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 n252GQ3a080315 for <[e-mail]>; Wed, 4 Mar 2009 19:16:37 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 2587 invoked from network); 5 Mar 2009 02:16:02 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 5 Mar 2009 02:16: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: I-D Action:draft-ietf-pkix-ta-format-01.txt
Date: Wed, 4 Mar 2009 21:16: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-format-01.txt
Thread-Index: AcmdNYea/8MGwAZWRYG2c/fp2DCxfQAAsMMA
References: <[e-mail]> <[e-mail]>
From: "Santosh Chokhani" <[e-mail]>
To: "Tom Gindin" <[e-mail]>, "Julien Stern" <[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>

May be two wrongs can make a right since if a name should be required in
a TA, it is the subject and not issuer name.=20

> -----Original Message-----
> From: [e-mail]=20
> [mailto:[e-mail]] On Behalf Of Tom Gindin
> Sent: Wednesday, March 04, 2009 8:41 PM
> To: Julien Stern
> Cc: [e-mail]
> Subject: Re: I-D Action:draft-ietf-pkix-ta-format-01.txt
>=20
>=20
>         Julian:
>=20
>         I think you're wrong in believing that the name is=20
> central to the definition of a trust anchor.  I can have (and=20
> my browser may be shipped
> with) several trust anchors issued by the same organization,=20
> and the names which distinguish them are (to me as the =20
> manager of the trust store) quite arbitrary.  A typical=20
> example is that there are two separate CA certificates from=20
> Entrust with CN=3D"Entrust.net Secure Server Certification=20
> Authority".  Their OU's are slightly different, and one of=20
> them has a Country attribute.
>         While philosophically I completely disagree with you,=20
> RFC 5280 section 6.1.1 point d-1 requires that the trust=20
> anchor have an issuer name, as does the same section in 3280.=20
>  Thus, no trust anchor definition which does not include an=20
> issuer name can be used by our own existing algorithms.  I=20
> think that's a pretty good reason for PKIX to require the=20
> presence of a DN in this definition.
>=20
>                 Tom Gindin
>=20
> P.S. - These views are mine personally, and not necessarily=20
> those of my employer
>=20
>=20
>=20
>=20
> Julien Stern <[e-mail]>=20
> Sent by: [e-mail]
> 03/04/2009 01:43 PM
>=20
> To
>=20
> cc
> [e-mail]
> Subject
> Re: I-D Action:draft-ietf-pkix-ta-format-01.txt
>=20
>=20
>=20
>=20
>=20
>=20
>=20
> [e-mail] wrote:
> > A New Internet-Draft is available from the on-line Internet-Drafts=20
> directories.
> > This draft is a work item of the Public-Key Infrastructure (X.509)=20
> Working Group of the IETF.
> >=20
> >=20
> >                Title           : Trust Anchor Format
> >                Author(s)       : R. Housley, et al.
> >                Filename        : draft-ietf-pkix-ta-format-01.txt
> >                Pages           : 17
> >                Date            : 2009-03-04
> >=20
>=20
> Hi again,
>=20
> separating from the previous email due to the nature of the comment:=20
> this one is more "philosophical" :)
>=20
> This draft defines a trust anchor as a public key with=20
> additional data.
>=20
> I believe that the most common usage of the word "trust=20
> anchor" denotes=20
> the _binding_ of a public key _and_ a name. A certificate=20
> binds a name=20
> and a public key (along with other information) thanks to a=20
> signature. A=20
> trust anchor binds them through direct trust.
>=20
> And indeed, the definition in X.509 is:
>=20
> trust anchor: A trust anchor is a set of the following information in=20
> addition to the public key: algorithm identifier, public key=20
> parameters=20
> (if applicable), distinguished name of the holder of the associated=20
> private key (i.e., the subject CA) and optionally a validity=20
> period. The=20
> trust anchor may be provided in the form of a self-signed certificate.
> A trust anchor is trusted by a certificate using system and used for=20
> validating certificates in certification paths.
>=20
>=20
> I assume that you did not choose to make the DN optional=20
> without reason.=20
> But is that really something that we would like to have? Are there=20
> really cases where we want to use a public key without explicitly=20
> knowing whom it belongs to? Isn't there a risk to spread confusion on=20
> what a "trust anchor" is?
>=20
> Granted, this RFC could define a Trust Anchor in a more global scope,=20
> without a need to bind it to a DN, but I'm (very personally) not sure=20
> this is a great idea and I believe that mandating the=20
> presence of a DN=20
> would not bring a strong limitation.
>=20
> Have you considered moving the taName from the=20
> CertPathControls to the=20
> main structure (TrustAnchorInfo) and keeping the CertPathControls=20
> structure for fine tuning of the X.509 input algorithm?
>=20
> (And along the same lines, why is the KeyIdentifier mandatory and not=20
> optional?)
>=20
> Regards,
>=20
> --
> Julien
>=20
>=20
>=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 n251fXPr078777 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Mar 2009 18:41:33 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n251fX3L078776; Wed, 4 Mar 2009 18:41:33 -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 n251fLYV078768 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Wed, 4 Mar 2009 18:41:32 -0700 (MST) (envelope-from [e-mail])
Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e4.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id n251cnXL006935 for <[e-mail]>; Wed, 4 Mar 2009 20:38:49 -0500
Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n251fKQA191338 for <[e-mail]>; Wed, 4 Mar 2009 20:41:20 -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 n251fKsV013486 for <[e-mail]>; Wed, 4 Mar 2009 20:41:20 -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 n251fKk7013477; Wed, 4 Mar 2009 20:41:20 -0500
In-Reply-To: <[e-mail]>
To: Julien Stern <[e-mail]>
Cc: [e-mail]
MIME-Version: 1.0
Subject: Re: I-D Action:draft-ietf-pkix-ta-format-01.txt
X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006
From: Tom Gindin <[e-mail]>
Message-ID: <[e-mail]>
Date: Wed, 4 Mar 2009 20:41:19 -0500
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 8.0.1 HF8|December 19, 2008) at 03/04/2009 20:41:20, Serialize complete at 03/04/2009 20:41:20
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>

        Julian:

        I think you're wrong in believing that the name is central to the 
definition of a trust anchor.  I can have (and my browser may be shipped 
with) several trust anchors issued by the same organization, and the names 
which distinguish them are (to me as the  manager of the trust store) 
quite arbitrary.  A typical example is that there are two separate CA 
certificates from Entrust with CN="Entrust.net Secure Server Certification 
Authority".  Their OU's are slightly different, and one of them has a 
Country attribute.
        While philosophically I completely disagree with you, RFC 5280 
section 6.1.1 point d-1 requires that the trust anchor have an issuer 
name, as does the same section in 3280.  Thus, no trust anchor definition 
which does not include an issuer name can be used by our own existing 
algorithms.  I think that's a pretty good reason for PKIX to require the 
presence of a DN in this definition.

                Tom Gindin

P.S. - These views are mine personally, and not necessarily those of my 
employer




Julien Stern <[e-mail]> 
Sent by: [e-mail]
03/04/2009 01:43 PM

To

cc
[e-mail]
Subject
Re: I-D Action:draft-ietf-pkix-ta-format-01.txt







[e-mail] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
> This draft is a work item of the Public-Key Infrastructure (X.509) 
Working Group of the IETF.
> 
> 
>                Title           : Trust Anchor Format
>                Author(s)       : R. Housley, et al.
>                Filename        : draft-ietf-pkix-ta-format-01.txt
>                Pages           : 17
>                Date            : 2009-03-04
> 

Hi again,

separating from the previous email due to the nature of the comment: 
this one is more "philosophical" :)

This draft defines a trust anchor as a public key with additional data.

I believe that the most common usage of the word "trust anchor" denotes 
the _binding_ of a public key _and_ a name. A certificate binds a name 
and a public key (along with other information) thanks to a signature. A 
trust anchor binds them through direct trust.

And indeed, the definition in X.509 is:

trust anchor: A trust anchor is a set of the following information in 
addition to the public key: algorithm identifier, public key parameters 
(if applicable), distinguished name of the holder of the associated 
private key (i.e., the subject CA) and optionally a validity period. The 
trust anchor may be provided in the form of a self-signed certificate.
A trust anchor is trusted by a certificate using system and used for 
validating certificates in certification paths.


I assume that you did not choose to make the DN optional without reason. 
But is that really something that we would like to have? Are there 
really cases where we want to use a public key without explicitly 
knowing whom it belongs to? Isn't there a risk to spread confusion on 
what a "trust anchor" is?

Granted, this RFC could define a Trust Anchor in a more global scope, 
without a need to bind it to a DN, but I'm (very personally) not sure 
this is a great idea and I believe that mandating the presence of a DN 
would not bring a strong limitation.

Have you considered moving the taName from the CertPathControls to the 
main structure (TrustAnchorInfo) and keeping the CertPathControls 
structure for fine tuning of the X.509 input algorithm?

(And along the same lines, why is the KeyIdentifier mandatory and not 
optional?)

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 n250UVnE075243 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Mar 2009 17:30:31 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n250UVDH075242; Wed, 4 Mar 2009 17:30:31 -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 n250UVJj075235 for <[e-mail]>; Wed, 4 Mar 2009 17:30:31 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id C377D3A684D; Wed,  4 Mar 2009 16:30:01 -0800 (PST)
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-authorityclearanceconstraints-01.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Wed,  4 Mar 2009 16:30: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-01.txt
	Pages		: 19
	Date		: 2009-3-4
	
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-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-authorityclearanceconstraints-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 n24NdhBD072795 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Mar 2009 16:39:43 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n24NdhT6072794; Wed, 4 Mar 2009 16:39:43 -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 n24NdWcQ072782 for <[e-mail]>; Wed, 4 Mar 2009 16:39:42 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Received: (qmail 31889 invoked by uid 0); 4 Mar 2009 23:39:24 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (96.255.144.212) by woodstock.binhost.com with SMTP; 4 Mar 2009 23:39:24 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Wed, 04 Mar 2009 17:58:53 -0500
To: Julien Stern <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: I-D Action:draft-ietf-pkix-ta-format-01.txt
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Julien:

X.509 did not originally include a definition of trust anchor.  RFC 
2459 follow this example, and it caused problems when describing 
certification path validation.  Since RFC 3280 added a lot of 
material on this topic, a definition was needed.  RFC 3280 includes:

    In section 6.1, the text describes basic path validation.  Valid
    paths begin with certificates issued by a trust anchor.  The
    algorithm requires the public key of the CA, the CA's name, and any
    constraints upon the set of paths which may be validated using this
    key.

I consider these constraints to be additional data.  The RFC 3280 
definition is saying what is needed in a trust anchor for the path 
validation algorithm.  Constraints are implemented through settings 
in the path validation algorithm.  However, I do not see anything in 
this text that says other policy information cannot be part of a 
trust anchor.  The text you quote includes validity period, and I 
consider this to be an example of such policy information.

RFC 2459, RFC 3280, and RFC 5280 have all required CA certificates to 
include a Distinguished Name.  This is important for constructing a 
certification path and for identifying a particular certificate in a CRL.

The taName is needed for certification path construction and 
validation.  I do not really care if it is placed in a separate 
OPTIONAL element of TrustAnchorInfo.  How would this change help you?

TAMP requires a key identifier.  This format was originally embedded 
in TAMP.  I guess this linkage remains.  I do point out that a key 
identifier could be computed from the public key using the technique 
described in RFC 5280, so this is not an onerous requirement.

Russ


At 01:43 PM 3/4/2009, Julien Stern wrote:

>[e-mail] wrote:
>>A New Internet-Draft is available from the on-line Internet-Drafts 
>>directories.
>>This draft is a work item of the Public-Key Infrastructure (X.509) 
>>Working Group of the IETF.
>>
>>         Title           : Trust Anchor Format
>>         Author(s)       : R. Housley, et al.
>>         Filename        : draft-ietf-pkix-ta-format-01.txt
>>         Pages           : 17
>>         Date            : 2009-03-04
>
>Hi again,
>
>separating from the previous email due to the nature of the comment: 
>this one is more "philosophical" :)
>
>This draft defines a trust anchor as a public key with additional data.
>
>I believe that the most common usage of the word "trust anchor" 
>denotes the _binding_ of a public key _and_ a name. A certificate 
>binds a name and a public key (along with other information) thanks 
>to a signature. A trust anchor binds them through direct trust.
>
>And indeed, the definition in X.509 is:
>
>trust anchor: A trust anchor is a set of the following information 
>in addition to the public key: algorithm identifier, public key 
>parameters (if applicable), distinguished name of the holder of the 
>associated private key (i.e., the subject CA) and optionally a 
>validity period. The trust anchor may be provided in the form of a 
>self-signed certificate.
>A trust anchor is trusted by a certificate using system and used for 
>validating certificates in certification paths.
>
>
>I assume that you did not choose to make the DN optional without 
>reason. But is that really something that we would like to have? Are 
>there really cases where we want to use a public key without 
>explicitly knowing whom it belongs to? Isn't there a risk to spread 
>confusion on what a "trust anchor" is?
>
>Granted, this RFC could define a Trust Anchor in a more global 
>scope, without a need to bind it to a DN, but I'm (very personally) 
>not sure this is a great idea and I believe that mandating the 
>presence of a DN would not bring a strong limitation.
>
>Have you considered moving the taName from the CertPathControls to 
>the main structure (TrustAnchorInfo) and keeping the 
>CertPathControls structure for fine tuning of the X.509 input algorithm?
>
>(And along the same lines, why is the KeyIdentifier mandatory and 
>not optional?)
>
>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 n24MUWFX069728 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Mar 2009 15:30:32 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n24MUW4a069727; Wed, 4 Mar 2009 15:30:32 -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 n24MUVwT069721 for <[e-mail]>; Wed, 4 Mar 2009 15:30:31 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id 12AFF3A6BD4; Wed,  4 Mar 2009 14:30:01 -0800 (PST)
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D Action:draft-ietf-pkix-ocspagility-00.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Wed,  4 Mar 2009 14:30:02 -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           : OCSP Algorithm Agility
	Author(s)       : P. Hallam-Baker
	Filename        : draft-ietf-pkix-ocspagility-00.txt
	Pages           : 7
	Date            : 2009-03-04

The OSCP specification defined in RFC 2560 requires server responses
to be signed but does not specify a mechanism for selecting the
signature algorithm to be used leading to possible interoperability
failures in contexts where multiple signature algorithms are in use.
This document specifies an algorithm for server signature algorithm
selection and an extension that allows a client to advise a server
that specific signature algorithms are supported.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-ocspagility-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-ocspagility-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 n24KNj4k062795 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Mar 2009 13:23:45 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n24KNjSl062794; Wed, 4 Mar 2009 13:23:45 -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 n24KNYk0062772 for <[e-mail]>; Wed, 4 Mar 2009 13:23:44 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 29918 invoked from network); 4 Mar 2009 20:23:10 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 4 Mar 2009 20:23: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: I-D Action:draft-ietf-pkix-ta-format-01.txt
Date: Wed, 4 Mar 2009 15:23:33 -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-format-01.txt
Thread-Index: AcmdAKVz3rIMfELxQeKEzbFkmXkY/AABX2mw
References: <[e-mail]> <[e-mail]>
From: "Carl Wallace" <[e-mail]>
To: "Julien Stern" <[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>

<snip>
> One first comment regarding the CertPolicyFlags:
>=20
> They are defined as:
>=20
> CertPolicyFlags ::=3D BIT STRING {
>        inhibitPolicyMapping   (0),
>        requireExplicitPolicy  (1),
>        inhibitAnyPolicy       (2) }
>=20
> But in 5280, they are integer, not booleans, for example:
>=20
> PolicyConstraints ::=3D SEQUENCE {
>       requireExplicitPolicy   [0]     SkipCerts OPTIONAL,
>       inhibitPolicyMapping    [1]     SkipCerts OPTIONAL }
>=20
> SkipCerts ::=3D INTEGER (0..MAX)
>=20
> I believe that we should keep them integers to keep the full=20
> generality (unless I missed a point).

The booleans align with the inputs to the path validation algorithm.
Ideally, those would have been integers too.
=20
> On a more global note, I noticed some time ago that a=20
> document from ETSI (namely ETSI 102 272) defined a fairly=20
> similar (albeit simpler) structure. It dates from 2003, but=20
> could provide some interesting bits.
> For those interested, here is the link:=20
> http://webapp.etsi.org/workprogram/Report_WorkItem.asp?WKI_ID=3D19571
>=20
>=20
> For those interested, but lazy, here are the relevant "raw=20
> ASN.1" bits:
>=20
> CertificateTrustPoint ::=3D SEQUENCE {
>      trustpoint              Certificate,
>      pathLenConstraint   [0] PathLenConstraint   OPTIONAL,
>      acceptablePolicySet [1] AcceptablePolicySet OPTIONAL, --=20
> If not present "any policy"
>      nameConstraints     [2] NameConstraints     OPTIONAL,
>      policyConstraints   [3] PolicyConstraints   OPTIONAL }
>=20
> PathLenConstraint ::=3D INTEGER (0..MAX)
> AcceptablePolicySet ::=3D SEQUENCE OF CertPolicyId CertPolicyId=20
> ::=3D OBJECT IDENTIFIER
>=20
> NameConstraints ::=3D SEQUENCE {
>            permittedSubtrees       [0]     GeneralSubtrees OPTIONAL,
>            excludedSubtrees        [1]     GeneralSubtrees OPTIONAL }
> GeneralSubtrees ::=3D SEQUENCE SIZE (1..MAX) OF GeneralSubtree=20
> GeneralSubtree ::=3D SEQUENCE {
>            base                    GeneralName,
>            minimum         [0]     BaseDistance DEFAULT 0,
>            maximum         [1]     BaseDistance OPTIONAL }
> BaseDistance ::=3D INTEGER (0..MAX)
>=20
> PolicyConstraints ::=3D SEQUENCE {
>          requireExplicitPolicy    [0] SkipCerts OPTIONAL,
>          inhibitPolicyMapping     [1] SkipCerts OPTIONAL }
> SkipCerts ::=3D INTEGER (0..MAX)
>=20
>=20
>=20
> I like the fact that the certificate is optional in the TA=20
> draft, and that it can be defined as a pure DN/Public Key=20
> pair. I've always thought the direct inclusion of a=20
> self-signed certificate led to possible unclarities as=20
> regards treatment of extensions. But anyway, always=20
> interesting to compare with what exists ...

Thanks for the reference.   =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 n24Iht06056453 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Mar 2009 11:43:55 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n24IhtAM056452; Wed, 4 Mar 2009 11:43:55 -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-117-wednesday.nerim.net [62.4.16.117]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n24Ihs2i056446 for <[e-mail]>; Wed, 4 Mar 2009 11:43:55 -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 6F278B8B5F for <[e-mail]>; Wed,  4 Mar 2009 19:43:51 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by uranus.cry.pto (Postfix) with ESMTP id 6DEFB440F5 for <[e-mail]>; Wed,  4 Mar 2009 19:43:51 +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 S0Owp-OWxiLQ for <[e-mail]>; Wed,  4 Mar 2009 19:43:47 +0100 (CET)
Received: from [10.0.1.30] (leda.cry.pto [10.0.1.30]) by uranus.cry.pto (Postfix) with ESMTP id 136CA440ED for <[e-mail]>; Wed,  4 Mar 2009 19:43:47 +0100 (CET)
Message-ID: <[e-mail]>
Date: Wed, 04 Mar 2009 19:43:46 +0100
From: Julien Stern <[e-mail]>
User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103)
MIME-Version: 1.0
Cc: [e-mail]
Subject: Re: I-D Action:draft-ietf-pkix-ta-format-01.txt
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

[e-mail] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.
> 
> 
> 	Title           : Trust Anchor Format
> 	Author(s)       : R. Housley, et al.
> 	Filename        : draft-ietf-pkix-ta-format-01.txt
> 	Pages           : 17
> 	Date            : 2009-03-04
> 

Hi again,

separating from the previous email due to the nature of the comment: 
this one is more "philosophical" :)

This draft defines a trust anchor as a public key with additional data.

I believe that the most common usage of the word "trust anchor" denotes 
the _binding_ of a public key _and_ a name. A certificate binds a name 
and a public key (along with other information) thanks to a signature. A 
trust anchor binds them through direct trust.

And indeed, the definition in X.509 is:

trust anchor: A trust anchor is a set of the following information in 
addition to the public key: algorithm identifier, public key parameters 
(if applicable), distinguished name of the holder of the associated 
private key (i.e., the subject CA) and optionally a validity period. The 
trust anchor may be provided in the form of a self-signed certificate.
A trust anchor is trusted by a certificate using system and used for 
validating certificates in certification paths.


I assume that you did not choose to make the DN optional without reason. 
But is that really something that we would like to have? Are there 
really cases where we want to use a public key without explicitly 
knowing whom it belongs to? Isn't there a risk to spread confusion on 
what a "trust anchor" is?

Granted, this RFC could define a Trust Anchor in a more global scope, 
without a need to bind it to a DN, but I'm (very personally) not sure 
this is a great idea and I believe that mandating the presence of a DN 
would not bring a strong limitation.

Have you considered moving the taName from the CertPathControls to the 
main structure (TrustAnchorInfo) and keeping the CertPathControls 
structure for fine tuning of the X.509 input algorithm?

(And along the same lines, why is the KeyIdentifier mandatory and not 
optional?)

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 n24IJm46054457 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Mar 2009 11:19:48 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n24IJmgF054456; Wed, 4 Mar 2009 11:19:48 -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-103-wednesday.nerim.net [62.4.16.103]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n24IJaqV054444 for <[e-mail]>; Wed, 4 Mar 2009 11:19:47 -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 4473ECFCA6 for <[e-mail]>; Wed,  4 Mar 2009 19:19:35 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by uranus.cry.pto (Postfix) with ESMTP id 6969D440F5 for <[e-mail]>; Wed,  4 Mar 2009 19:19:35 +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 ILf1RMPgsnop for <[e-mail]>; Wed,  4 Mar 2009 19:19:31 +0100 (CET)
Received: from [10.0.1.30] (leda.cry.pto [10.0.1.30]) by uranus.cry.pto (Postfix) with ESMTP id 58956440ED for <[e-mail]>; Wed,  4 Mar 2009 19:19:31 +0100 (CET)
Message-ID: <[e-mail]>
Date: Wed, 04 Mar 2009 19:19:31 +0100
From: Julien Stern <[e-mail]>
User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103)
MIME-Version: 1.0
Cc: [e-mail]
Subject: Re: I-D Action:draft-ietf-pkix-ta-format-01.txt
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

[e-mail] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.
> 
> 
> 	Title           : Trust Anchor Format
> 	Author(s)       : R. Housley, et al.
> 	Filename        : draft-ietf-pkix-ta-format-01.txt
> 	Pages           : 17
> 	Date            : 2009-03-04
> 

Hi,

Nice work. Thanks.

One first comment regarding the CertPolicyFlags:

They are defined as:

CertPolicyFlags ::= BIT STRING {
       inhibitPolicyMapping   (0),
       requireExplicitPolicy  (1),
       inhibitAnyPolicy       (2) }

But in 5280, they are integer, not booleans, for example:

PolicyConstraints ::= SEQUENCE {
      requireExplicitPolicy   [0]     SkipCerts OPTIONAL,
      inhibitPolicyMapping    [1]     SkipCerts OPTIONAL }

SkipCerts ::= INTEGER (0..MAX)

I believe that we should keep them integers to keep the full generality 
(unless I missed a point).

On a more global note, I noticed some time ago that a document from ETSI 
(namely ETSI 102 272) defined a fairly similar (albeit simpler) 
structure. It dates from 2003, but could provide some interesting bits.
For those interested, here is the link: 
http://webapp.etsi.org/workprogram/Report_WorkItem.asp?WKI_ID=19571


For those interested, but lazy, here are the relevant "raw ASN.1" bits:

CertificateTrustPoint ::= SEQUENCE {
     trustpoint              Certificate,
     pathLenConstraint   [0] PathLenConstraint   OPTIONAL,
     acceptablePolicySet [1] AcceptablePolicySet OPTIONAL, -- If not 
present "any policy"
     nameConstraints     [2] NameConstraints     OPTIONAL,
     policyConstraints   [3] PolicyConstraints   OPTIONAL }

PathLenConstraint ::= INTEGER (0..MAX)
AcceptablePolicySet ::= SEQUENCE OF CertPolicyId
CertPolicyId ::= OBJECT IDENTIFIER

NameConstraints ::= SEQUENCE {
           permittedSubtrees       [0]     GeneralSubtrees OPTIONAL,
           excludedSubtrees        [1]     GeneralSubtrees OPTIONAL }
GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree
GeneralSubtree ::= SEQUENCE {
           base                    GeneralName,
           minimum         [0]     BaseDistance DEFAULT 0,
           maximum         [1]     BaseDistance OPTIONAL }
BaseDistance ::= INTEGER (0..MAX)

PolicyConstraints ::= SEQUENCE {
         requireExplicitPolicy    [0] SkipCerts OPTIONAL,
         inhibitPolicyMapping     [1] SkipCerts OPTIONAL }
SkipCerts ::= INTEGER (0..MAX)



I like the fact that the certificate is optional in the TA draft, and 
that it can be defined as a pure DN/Public Key pair. I've always thought 
the direct inclusion of a self-signed certificate led to possible 
unclarities as regards treatment of extensions. But anyway, always 
interesting to compare with what exists ...

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 n24HMcxH051002 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Mar 2009 10:22:38 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n24HMcSG051001; Wed, 4 Mar 2009 10:22:38 -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 n24HMRG4050983 for <[e-mail]>; Wed, 4 Mar 2009 10:22:38 -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 31C026A for <[e-mail]>; Wed,  4 Mar 2009 18:22:26 +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 2009030418222499:375904 ; Wed, 4 Mar 2009 18:22:24 +0100 
Message-ID: <[e-mail]>
Date: Wed, 04 Mar 2009 18:22:25 +0100
From: Peter Sylvester <[e-mail]>
User-Agent: Thunderbird 1.5.0.9 (X11/20061206)
MIME-Version: 1.0
To: [e-mail]
Subject: draft-ietf-pkix-rfc3161bis-01.txt
X-MIMETrack: Itemize by SMTP Server on vinea/ON-X(Release 5.0.11  |July 24, 2002) at 03/04/2009 06:22:25 PM, Serialize by Router on vinea/ON-X(Release 5.0.11  |July 24, 2002) at 03/04/2009 06:22:25 PM, Serialize complete at 03/04/2009 06:22:25 PM
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I had the impression that thegoal of that texwt was an update
concerning hash algorithms.


One could expecte it would only contain an update to the ESScertid using
ESSCertidV2 etc.

The actual texts corresponds roughly to an expired draft some
years ago.

        - the document has been aligned with RFC 3628 to make the
          difference between a time-stamping unit (TSU) and a TSA.

Thus, the text is not a small update of 3161 but introduces several
new items, some of them seems questionable to me. Some problems
which had been mentioned with RFC 3161 in the past, have not been
addressed.

In 3161, a TSA is merely a technical service similar to what is
said in 3161bis for a TSU. A TSA in 3161bis does not really
have a defined technical role.

On the other hand the field tsa in a response refers to a TSA,
and to a certficate that validates it. But a TSA does no longer
have a certificate, only TSUs.

As a consequence, the following paragraph cannot mention TSA
but at best a TSU.
Besides that it should also mentiion ESSCertIDv2.)

    The purpose of the tsa field is to give a hint in identifying the
    name of the TSA.  If present, it MUST correspond to one of the
    subject names included in the certificate that is to be used to
    verify the token.  However, the actual identification of the entity
    that signed the response will always occur through the use of the
    certificate identifier (ESSCertID Attribute) inside a
    SigningCertificate attribute which is part of the signerInfo
    (See Section 5 of [ESS]).


Chapter 3.3 does not use the 2119 terminology in the first phrase but
rather the ISO terminoilogy. 3.3 is not relevant for the function of
a time stamp service. (Although it is likely that TSA actually
have filled all the REQUIRED 'shall) attributes in the DN)

The following text is extremely fuzzy:

    The name of the issuing TSU shall contain an appropriate subset of
    the following attributes (defined in ISO 9594-6 [ISO9594-6] and
    ITU-T Recommendation X.520 [X.520]):

        - countryName;
        - stateOrProvinceName;
        - organizationName;
        - commonName.

What means "appropriate subset". The text does not exclude
other attributs. So in fact, it says: The TSU MUST have a subjectDN?

It is not defined what name identifies a TSA? for example, everything except
the common name?

4.3 :

As it had been mentioned before the socket protocol as it is defined
has some problems: Since it was taken texto from CMP, there are some features
that are may require some complexity in clients:
Only 00, 05, and 06 seem useful to me. If a TSA/U is not able to sign
a response within a few milliseconds with a TCP connection kept open,
I wouldn't call this a service.
For HTTP, a server cannot return a poll indication as a comparison.

If a client does not send a pollReq, what will happen with a pending
response?

The protocol does not specify who terminates the connection. Is it the
server that closes after one exchange?

If multiple requests and responses can be exchanged over the same connection,
what is the dialogue model? request/response, pipelining, etc?

What is a TSU message? I think it should be TSP message. Old text was
TSA, which was also somewhat wrong.

Security section point 1 seems not quite correct:

Instead of :
it SHALL be set either to unspecified (0), affiliationChanged (3),
       superseded (4) or cessationOfOperation (5).  In that case,

it should say

In the case when the reasonCode is set to either
       affiliationChanged (3),
       superseded (4) or cessationOfOperation (5)

Unspecified means that ther can be a key compromise IMO?



















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 n24GFYVg047099 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Mar 2009 09:15:34 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n24GFYcp047098; Wed, 4 Mar 2009 09:15:34 -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 n24GFVYb047072 for <[e-mail]>; Wed, 4 Mar 2009 09:15:31 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id 7EA3828C123; Wed,  4 Mar 2009 08:15:02 -0800 (PST)
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D Action:draft-ietf-pkix-ta-format-01.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Wed,  4 Mar 2009 08:15:02 -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           : Trust Anchor Format
	Author(s)       : R. Housley, et al.
	Filename        : draft-ietf-pkix-ta-format-01.txt
	Pages           : 17
	Date            : 2009-03-04

This document describes a structure for representing trust anchor
information.  A trust anchor is an authoritative entity represented
by 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 or actions for which the trust
anchor is authoritative.  The structures defined in this document are
intended to satisfy the format-related requirements defined in Trust
Anchor Management Requirements.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-ta-format-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-ta-format-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 n24GFW4G047093 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Mar 2009 09:15:32 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n24GFWF4047092; Wed, 4 Mar 2009 09:15:32 -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 n24GFVqv047073 for <[e-mail]>; Wed, 4 Mar 2009 09:15:31 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id 8A5613A6C85; Wed,  4 Mar 2009 08:15:02 -0800 (PST)
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D Action:draft-ietf-pkix-ta-mgmt-reqs-03.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Wed,  4 Mar 2009 08:15:02 -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           : Trust Anchor Management Requirements
	Author(s)       : R. Reddy, C. Wallace
	Filename        : draft-ietf-pkix-ta-mgmt-reqs-03.txt
	Pages           : 19
	Date            : 2009-03-04

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
push-based 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-03.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-ta-mgmt-reqs-03.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 n24GFWj0047094 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Mar 2009 09:15:32 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n24GFWYD047091; Wed, 4 Mar 2009 09:15:32 -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 n24GFVQU047074 for <[e-mail]>; Wed, 4 Mar 2009 09:15:31 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id 90A2328C1A4; Wed,  4 Mar 2009 08:15:02 -0800 (PST)
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D Action:draft-ietf-pkix-tamp-01.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Wed,  4 Mar 2009 08:15:02 -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           : Trust Anchor Management Protocol (TAMP)
	Author(s)       : R. Housley, et al.
	Filename        : draft-ietf-pkix-tamp-01.txt
	Pages           : 84
	Date            : 2009-03-04

This document describes a transport independent protocol for the
management of trust anchors and community identifiers stored in a
trust anchor store.  The protocol makes use of the Cryptographic
Message Syntax (CMS), and a digital signature is used to provide
integrity protection and data origin authentication.  The protocol
can be used to manage trust anchor stores containing trust anchors
represented as Certificate, TBSCertificate or TrustAnchorInfo
objects.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-tamp-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-tamp-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 n23Dw2Z8045973 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Mar 2009 06:58:02 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n23Dw2Ro045972; Tue, 3 Mar 2009 06:58:02 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail67.messagelabs.com (mail67.messagelabs.com [193.109.254.83]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n23DvoFv045961 for <[e-mail]>; Tue, 3 Mar 2009 06:58:01 -0700 (MST) (envelope-from [e-mail])
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-10.tower-67.messagelabs.com!1236088669!33330122!1
X-StarScan-Version: 6.0.0; banners=.,-,-
X-Originating-IP: [195.92.40.48]
Received: (qmail 1803 invoked from network); 3 Mar 2009 13:57:49 -0000
Received: from gateway-201.energis.gsi.gov.uk (HELO mx.hosting-e.gsi.gov.uk) (195.92.40.48) by server-10.tower-67.messagelabs.com with SMTP; 3 Mar 2009 13:57:49 -0000
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-3.tower-89.messagelabs.com!1236081287!36689781!1
X-StarScan-Version: 6.0.0; banners=-,-,gchq.gsi.gov.uk
X-Originating-IP: [192.245.12.227]
X-SpamReason: No, hits=1.1 required=7.0 tests=HTML_20_30,HTML_MESSAGE, MIME_QP_LONG_LINE
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
User-Agent: Microsoft-Entourage/12.15.0.081119
Date: Tue, 03 Mar 2009 12:29:14 +0100
Subject: Call for agenda items
From: Stefan Santesson <[e-mail]>
To: IETF-pkix <[e-mail]>
Message-ID: <[e-mail]>
Thread-Topic: Call for agenda items
Thread-Index: Acmb80fBwJEE/S9xVk+d4pIiOftWRw==
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3318928155_3051272"
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: 03 Mar 2009 11:58:30.0738 (UTC) FILETIME=[5EDA9320:01C99BF7]
Sender: [e-mail]
Precedence: 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 message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3318928155_3051272
Content-type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: 7bit
Content-Transfer-Encoding: quoted-printable

IETF=20in=20San=20Francisco=20is=20coming=20up.

PKIX=20has=20a=202.5=20hour=20session=20directly=20on=20the=20Monday=20mor=
ning=20March=2023=20at=200900

Please=20let=20me=20know=20if=20you=20have=20anything=20you=20whish=20to=20=
present=20at=20the=20meeting.
At=20least=20one=20representative=20of=20each=20active=20WG=20document=20M=
UST=20inform=20me=20if=20you
need=20a=20time=20slot=20for=20that=20document=20or=20not.
=20
I=20would=20like=20to=20have=20your=20request=20for=20timeslot=20by=20Wedn=
esday=20March=2011.
After=20that=20we=20can=20always=20do=20late=20adjustments=20but=20I=20app=
reciate=20to=20have=20your
request=20as=20early=20as=20possible.

Thank=20you.

/Stefan


This=20email=20was=20received=20from=20the=20INTERNET=20and=20scanned=20by=
=20the=20Government=20Secure=20Intranet=20anti-virus=20service=20supplied=20=
by=20Cable&Wireless=20in=20partnership=20with=20MessageLabs.=20(CCTM=20Cer=
tificate=20Number=202007/11/0032.)=20In=20case=20of=20problems,=20please=20=
call=20your=20organisation=92s=20IT=20Helpdesk.=20
Communications=20via=20the=20GSi=20may=20be=20automatically=20logged,=20mo=
nitored=20and/or=20recorded=20for=20legal=20purposes.

**************************************************************************=
**
Communications=20with=20GCHQ=20may=20be=20monitored=20and/or=20recorded=20=

for=20system=20efficiency=20and=20other=20lawful=20purposes.=20Any=20views=
=20or=20
opinions=20expressed=20in=20this=20e-mail=20do=20not=20necessarily=20refle=
ct=20GCHQ=20
policy.=20=20This=20email,=20and=20any=20attachments,=20is=20intended=20fo=
r=20the=20
attention=20of=20the=20addressee(s)=20only.=20Its=20unauthorised=20use,=20=

disclosure,=20storage=20or=20copying=20is=20not=20permitted.=20=20If=20you=
=20are=20not=20the
intended=20recipient,=20please=20notify=[e-mail].=20=20=


This=20information=20is=20exempt=20from=20disclosure=20under=20the=20Freed=
om=20of=20
Information=20Act=202000=20and=20may=20be=20subject=20to=20exemption=20und=
er
other=20UK=20information=20legislation.=20Refer=20disclosure=20requests=20=
to=20
GCHQ=20on=2001242=20221491=20ext=2030306=20(non-secure)=20or=20email
[e-mail]

**************************************************************************=
**


______________________________________________________________________
This=20email=20has=20been=20scanned=20by=20the=20MessageLabs=20Email=20Sec=
urity=20System.
For=20more=20information=20please=20visit=20http://www.messagelabs.com/ema=
il=20
______________________________________________________________________
--B_3318928155_3051272
Content-type: text/html; charset="US-ASCII"
Content-transfer-encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Call=20for=20agenda=20items</TITLE>
</HEAD>
<BODY>
<FONT=20FACE=3D"Calibri,=20Verdana,=20Helvetica,=20Arial"><SPAN=20STYLE=3D=
'font-size:11pt'>IETF=20in=20San=20Francisco=20is=20coming=20up.<BR>
<BR>
PKIX=20has=20a=202.5=20hour=20session=20directly=20on=20the=20Monday=20mor=
ning=20March=2023=20at=200900<BR>
<BR>
Please=20let=20me=20know=20if=20you=20have=20anything=20you=20whish=20to=20=
present=20at=20the=20meeting.<BR>
<B><U>At=20least=20one=20representative=20of=20each=20active=20WG=20docume=
nt=20MUST=20inform=20me=20if=20you=20need=20a=20time=20slot=20for=20that=20=
document=20or=20not.<BR>
</U></B>=20<BR>
I=20would=20like=20to=20have=20your=20request=20for=20timeslot=20by=20Wedn=
esday=20March=2011.<BR>
After=20that=20we=20can=20always=20do=20late=20adjustments=20but=20I=20app=
reciate=20to=20have=20your=20request=20as=20early=20as=20possible.<BR>
<BR>
Thank=20you.<BR>
<BR>
/Stefan</SPAN></FONT>

<BR>
This=20email=20was=20received=20from=20the=20INTERNET=20and=20scanned=20by=
=20the=20Government=20Secure=20Intranet=20anti-virus=20service=20supplied=20=
by=20Cable&Wireless=20in=20partnership=20with=20MessageLabs.=20(CCTM=20Cer=
tificate=20Number=202007/11/0032.)=20In=20case=20of=20problems,=20please=20=
call=20your=20organisation=92s=20IT=20Helpdesk.=20<BR>
Communications=20via=20the=20GSi=20may=20be=20automatically=20logged,=20mo=
nitored=20and/or=20recorded=20for=20legal=20purposes.<BR>
<CODE><FONT=20SIZE=3D3><BR>
<BR>
**************************************************************************=
**<BR>
Communications=20with=20GCHQ=20may=20be=20monitored=20and/or=20recorded=20=
<BR>
for=20system=20efficiency=20and=20other=20lawful=20purposes.=20Any=20views=
=20or=20<BR>
opinions=20expressed=20in=20this=20e-mail=20do=20not=20necessarily=20refle=
ct=20GCHQ=20<BR>
policy.=20=20This=20email,=20and=20any=20attachments,=20is=20intended=20fo=
r=20the=20<BR>
attention=20of=20the=20addressee(s)=20only.=20Its=20unauthorised=20use,=20=
<BR>
disclosure,=20storage=20or=20copying=20is=20not=20permitted.=20=20If=20you=
=20are=20not=20the<BR>
intended=20recipient,=20please=20notify=[e-mail].=20=20=
<BR>
<BR>
This=20information=20is=20exempt=20from=20disclosure=20under=20the=20Freed=
om=20of=20<BR>
Information=20Act=202000=20and=20may=20be=20subject=20to=20exemption=20und=
er<BR>
other=20UK=20information=20legislation.=20Refer=20disclosure=20requests=20=
to=20<BR>
GCHQ=20on=2001242=20221491=20ext=2030306=20(non-secure)=20or=20email<BR>
[e-mail]<BR>
<BR>
**************************************************************************=
**<BR>
</FONT></CODE>

<BR>
______________________________________________________________________<BR>=

This=20email=20has=20been=20scanned=20by=20the=20MessageLabs=20Email=20Sec=
urity=20System.<BR>
For=20more=20information=20please=20visit=20http://www.messagelabs.com/ema=
il=20<BR>
______________________________________________________________________<BR>=

</BODY>
</HTML>


--B_3318928155_3051272--




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 n23BTTGp033924 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Mar 2009 04:29:29 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n23BTTMa033923; Tue, 3 Mar 2009 04:29:29 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from s87.loopia.se (s87.loopia.se [194.9.95.112]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n23BTG5p033903 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 3 Mar 2009 04:29:28 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 55069 invoked from network); 3 Mar 2009 11:29:19 -0000
Received: from s34.loopia.se (HELO s42.loopia.se) ([194.9.94.70]) (envelope-sender <[e-mail]>) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for <[e-mail]>; 3 Mar 2009 11:29:19 -0000
Received: (qmail 48086 invoked from network); 3 Mar 2009 11:29:15 -0000
Received: from 90-229-233-249-no153.tbcn.telia.com (HELO [192.168.0.17]) ([e-mail]@[90.229.233.249]) (envelope-sender <[e-mail]>) by s42.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <[e-mail]>; 3 Mar 2009 11:29:15 -0000
User-Agent: Microsoft-Entourage/12.15.0.081119
Date: Tue, 03 Mar 2009 12:29:14 +0100
Subject: Call for agenda items
From: Stefan Santesson <[e-mail]>
To: IETF-pkix <[e-mail]>
Message-ID: <[e-mail]>
Thread-Topic: Call for agenda items
Thread-Index: Acmb80fBwJEE/S9xVk+d4pIiOftWRw==
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3318928155_3051272"
Sender: [e-mail]
Precedence: 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 message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3318928155_3051272
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit

IETF in San Francisco is coming up.

PKIX has a 2.5 hour session directly on the Monday morning March 23 at 0900

Please let me know if you have anything you whish to present at the meeting.
At least one representative of each active WG document MUST inform me if you
need a time slot for that document or not.
 
I would like to have your request for timeslot by Wednesday March 11.
After that we can always do late adjustments but I appreciate to have your
request as early as possible.

Thank you.

/Stefan

--B_3318928155_3051272
Content-type: text/html;
	charset="US-ASCII"
Content-transfer-encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Call for agenda items</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt=
'>IETF in San Francisco is coming up.<BR>
<BR>
PKIX has a 2.5 hour session directly on the Monday morning March 23 at 0900=
<BR>
<BR>
Please let me know if you have anything you whish to present at the meeting=
.<BR>
<B><U>At least one representative of each active WG document MUST inform me=
 if you need a time slot for that document or not.<BR>
</U></B> <BR>
I would like to have your request for timeslot by Wednesday March 11.<BR>
After that we can always do late adjustments but I appreciate to have your =
request as early as possible.<BR>
<BR>
Thank you.<BR>
<BR>
/Stefan</SPAN></FONT>
</BODY>
</HTML>


--B_3318928155_3051272--