Re: Embedded certificate image

[Tom Gindin <[e-mail]>]

        Stefan:

        While it is unreasonable to dictate what a CA can accept, I think 
that the Security Considerations section should say something like: "the 
information about the certificate subject contained in the image SHOULD 
NOT include any graphic supplied by the applicant".  The "tumor" construct 
which we saw in MD5 collisions could be placed into such a graphic.  Thus 
if a CA were to construct a graphic by inserting a customer-provided 
graphic into a template provided by the CA, it would be subject to the 
same attacks as MD5 certificates have been, but it would not be evident 
from the certificate syntax.

                Tom Gindin




Stefan Santesson <[e-mail]> 
Sent by: [e-mail]
07/31/2009 02:19 PM

To
"Timothy J. Miller" <[e-mail]>, Santosh Chokhani 
<[e-mail]>
cc
ietf-pkix <[e-mail]>
Subject
Re: Embedded certificate image







Tim,

It is not reasonable for this standard to dictate what a CA accepts as
input.

/Stefan

On 09-07-31 6:57 PM, "Timothy J. Miller" <[e-mail]> wrote:

> Santosh Chokhani wrote:
> 
>> RFC says "The relationship between the subject organization and the
>> subject
>>    organization logotype, and the relationship between the issuer and
>>    either the issuer organization logotype or the community logotype,
>>    are relationships asserted by the issuer."
>> 
>> It tends to imply that the logotype is predefined data and not in the
>> certificate request payload.
> 
> I'd feel better if it were explicit that the subject logotype is
> provided by the issuer.
> 
> As it is, I think it can be read either way.  The issuer asserts
> everything in the cert, after all, but it didn't create it all; much was
> provided by the applicant.
> 
> -- Tim





Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7107O7p019254 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 31 Jul 2009 17: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 n7107N77019253; Fri, 31 Jul 2009 17:07:23 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from e7.ny.us.ibm.com (e7.ny.us.ibm.com [32.97.182.137]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7107BHM019237 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Fri, 31 Jul 2009 17:07:22 -0700 (MST) (envelope-from [e-mail])
Received: from d01relay06.pok.ibm.com (d01relay06.pok.ibm.com [9.56.227.116]) by e7.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id n7106lpc015592 for <[e-mail]>; Fri, 31 Jul 2009 20:06:47 -0400
Received: from d01av05.pok.ibm.com (d01av05.pok.ibm.com [9.56.224.195]) by d01relay06.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n7107A4V2412692 for <[e-mail]>; Fri, 31 Jul 2009 20:07:10 -0400
Received: from d01av05.pok.ibm.com (loopback [127.0.0.1]) by d01av05.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id n71079OK012506 for <[e-mail]>; Fri, 31 Jul 2009 20:07:10 -0400
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.56.228.115]) by d01av05.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id n710794U012503; Fri, 31 Jul 2009 20:07:09 -0400
In-Reply-To: <[e-mail]>
To: Stefan Santesson <[e-mail]>
Cc: ietf-pkix <[e-mail]>, Santosh Chokhani <[e-mail]>, "Timothy J. Miller" <[e-mail]>
MIME-Version: 1.0
Subject: Re: Embedded certificate image
X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006
From: Tom Gindin <[e-mail]>
Message-ID: <[e-mail]>
Date: Fri, 31 Jul 2009 20:07:08 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 8.0.2FP1 ZOS802FP1HF3|June 25, 2009) at 07/31/2009 20:07:08, Serialize complete at 07/31/2009 20:07:08
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>

        Stefan:

        While it is unreasonable to dictate what a CA can accept, I think 
that the Security Considerations section should say something like: "the 
information about the certificate subject contained in the image SHOULD 
NOT include any graphic supplied by the applicant".  The "tumor" construct 
which we saw in MD5 collisions could be placed into such a graphic.  Thus 
if a CA were to construct a graphic by inserting a customer-provided 
graphic into a template provided by the CA, it would be subject to the 
same attacks as MD5 certificates have been, but it would not be evident 
from the certificate syntax.

                Tom Gindin




Stefan Santesson <[e-mail]> 
Sent by: [e-mail]
07/31/2009 02:19 PM

To
"Timothy J. Miller" <[e-mail]>, Santosh Chokhani 
<[e-mail]>
cc
ietf-pkix <[e-mail]>
Subject
Re: Embedded certificate image







Tim,

It is not reasonable for this standard to dictate what a CA accepts as
input.

/Stefan

On 09-07-31 6:57 PM, "Timothy J. Miller" <[e-mail]> wrote:

> Santosh Chokhani wrote:
> 
>> RFC says "The relationship between the subject organization and the
>> subject
>>    organization logotype, and the relationship between the issuer and
>>    either the issuer organization logotype or the community logotype,
>>    are relationships asserted by the issuer."
>> 
>> It tends to imply that the logotype is predefined data and not in the
>> certificate request payload.
> 
> I'd feel better if it were explicit that the subject logotype is
> provided by the issuer.
> 
> As it is, I think it can be read either way.  The issuer asserts
> everything in the cert, after all, but it didn't create it all; much was
> provided by the applicant.
> 
> -- Tim






Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6VIYZV4000709 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 31 Jul 2009 11:34:36 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6VIYZcn000707; Fri, 31 Jul 2009 11:34:35 -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.113]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6VIYXuE000695 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Fri, 31 Jul 2009 11:34:34 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 58885 invoked from network); 31 Jul 2009 18:34:39 -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]>; 31 Jul 2009 18:34:39 -0000
Received: (qmail 22555 invoked from network); 31 Jul 2009 18:34:32 -0000
Received: from 213-64-142-97-no153.business.telia.com (HELO [192.168.1.5]) ([e-mail]@[213.64.142.97]) (envelope-sender <[e-mail]>) by s29.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <[e-mail]>; 31 Jul 2009 18:34:32 -0000
User-Agent: Microsoft-Entourage/12.20.0.090605
Date: Fri, 31 Jul 2009 20:34:25 +0200
Subject: Re: Embedded certificate image
From: Stefan Santesson <[e-mail]>
To: Tom Gindin <[e-mail]>
CC: ietf-pkix <[e-mail]>, Santosh Chokhani <[e-mail]>, "Timothy J. Miller" <[e-mail]>
Message-ID: <[e-mail]>
Thread-Topic: Embedded certificate image
Thread-Index: AcoSDYd1ThkGZ+noYUudFmso/t+rNQ==
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>

The draft we are discussing is the certificate image draft, not the use of
subject logotype with RFC 3709.

A certificate image is composed by the CA even if there may be part of the
image that has been imported, such as a subject logo appearing somewhere
inside the certificate image. The fact that the certificate image is
composed by the CA creates the situation described by Tom. I.e. the imported
image appears somewhere inside the certificate image, therefore it will be
preceded and mixed with data provided by the CA.

/Stefan


On 09-07-31 4:03 PM, "Tom Gindin" <[e-mail]> wrote:

> 
>         But isn't the subject organization's logotype precisely the entity
> which could be manipulated to produce a collision?  What other
> unpredictable data is in the image?  The certificate (as distinct from its
> image) is always assembled and created by the CA, but that didn't stop the
> collision attacks at New Year's.  I tend to agree with Timothy about this
> one.
>         The simplest way to make this safe against collisions IMHO is to
> add an optional OCTET STRING as the first item (not the last) in the
> logotype extension and have the CA set it to a random value the same size
> as the digest output whenever it puts in an image.  That should break up
> the prefix attack.  Unfortunatly, there is no corresponding field in the
> base definition.
>         I have seen Santosh's citation from 3709, but is the subject
> organization's logotype more a "relationship asserted by the issuer" than
> an OU value?
> 
>                 Tom Gindin
> 
> 
> 
> 
> Stefan Santesson <[e-mail]>
> Sent by: [e-mail]
> 07/30/2009 03:52 PM
> 
> To
> Santosh Chokhani <[e-mail]>, "Timothy J. Miller"
> <[e-mail]>
> cc
> ietf-pkix <[e-mail]>
> Subject
> Re: Embedded certificate image
> 
> 
> 
> 
> 
> 
> 
> This is data generated by the CA.
> 
> Some included elements, like logotype of the subject organization may be
> provided by the applicant but the certificate image is assembled and
> created
> by the CA.
> 
> /Stefan
> 
> 
> On 09-07-30 8:55 PM, "Santosh Chokhani" <[e-mail]> wrote:
> 
>> 
>> I do not mean to intrude, but is this data being provided by the
>> applicant or is this something structured created by the CA or gotten by
>> the CA from a source that applicant does not control.
>> 
>> I ask because depending on the answer, this may become pre-image attack
>> and hence impractical.
>> 
>>> -----Original Message-----
>>> From: [e-mail]
>>> [mailto:[e-mail]] On Behalf Of Stefan Santesson
>>> Sent: Thursday, July 30, 2009 2:32 PM
>>> To: Timothy J. Miller
>>> Cc: ietf-pkix
>>> Subject: Re: Embedded certificate image
>>> 
>>> 
>>> So, with all things taken into account, what is your opinion
>>> on what we should do?
>>> 
>>> Do you argue that we should ignore the feature because it may
>>> enhance hash attacks?
>>> 
>>> /Stefan
>>> 
>>> On 09-07-30 5:32 PM, "Timothy J. Miller" <[e-mail]> wrote:
>>> 
>>>> Stefan Santesson wrote:
>>>> 
>>>>> However, I can't escape that it feels a bit warped if we abandon
>>>>> useful features because we must design protocols to resist weak
>>>>> hashes instead of making sure that we can and do use
>>> adequate hash algorithms.
>>>> 
>>>> It's a risk-management decision, in the end.  The question
>>> is, whose 
>>>> risk is it?  The protocol designer's, or the end user's?
>>>> 
>>>>> On the second point, the data in both SVG and PDF/A are
>>> highly structured.
>>>>> SVG is for example an XML based vector graphic language.
>>>> 
>>>> I can bury arbitrary amounts of unstructured data in both
>>> SVG and PDF/A.
>>>>   SVG allows the same RFC2397 data URLs that you were discussing
>>>> previously, and you can embed fonts in both PDF/A (it's actually
>>>> required) and SVG.  :)
>>>> 
>>>> -- Tim
>>>> 
>>> 
>>> 
>>> 
>> 
> 
> 
> 
> 




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6VIJRFC099311 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 31 Jul 2009 11:19:27 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6VIJR4E099310; Fri, 31 Jul 2009 11:19: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.113]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6VIJLj2099296 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Fri, 31 Jul 2009 11:19:26 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 13723 invoked from network); 31 Jul 2009 18:19:26 -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]>; 31 Jul 2009 18:19:26 -0000
Received: (qmail 76569 invoked from network); 31 Jul 2009 18:19:17 -0000
Received: from 213-64-142-97-no153.business.telia.com (HELO [192.168.1.5]) ([e-mail]@[213.64.142.97]) (envelope-sender <[e-mail]>) by s19.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <[e-mail]>; 31 Jul 2009 18:19:17 -0000
User-Agent: Microsoft-Entourage/12.20.0.090605
Date: Fri, 31 Jul 2009 20:19:15 +0200
Subject: Re: Embedded certificate image
From: Stefan Santesson <[e-mail]>
To: "Timothy J. Miller" <[e-mail]>, Santosh Chokhani <[e-mail]>
CC: ietf-pkix <[e-mail]>
Message-ID: <[e-mail]>
Thread-Topic: Embedded certificate image
Thread-Index: AcoSC2kOpD1TXwIPLUuq89vKgQlIDQ==
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>

Tim,

It is not reasonable for this standard to dictate what a CA accepts as
input.

/Stefan

On 09-07-31 6:57 PM, "Timothy J. Miller" <[e-mail]> wrote:

> Santosh Chokhani wrote:
> 
>> RFC says "The relationship between the subject organization and the
>> subject
>>    organization logotype, and the relationship between the issuer and
>>    either the issuer organization logotype or the community logotype,
>>    are relationships asserted by the issuer."
>> 
>> It tends to imply that the logotype is predefined data and not in the
>> certificate request payload.
> 
> I'd feel better if it were explicit that the subject logotype is
> provided by the issuer.
> 
> As it is, I think it can be read either way.  The issuer asserts
> everything in the cert, after all, but it didn't create it all; much was
> provided by the applicant.
> 
> -- Tim




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6VGvRsP093471 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 31 Jul 2009 09:57:27 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6VGvRbq093470; Fri, 31 Jul 2009 09:57:27 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-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 n6VGvFup093457 for <[e-mail]>; Fri, 31 Jul 2009 09:57:25 -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 n6VGvEmH018308 for <[e-mail]>; Fri, 31 Jul 2009 12:57:15 -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 n6VGvE9s018305; Fri, 31 Jul 2009 12:57:14 -0400
Received: from [172.31.17.57] (172.31.17.57) by imchub2.MITRE.ORG (129.83.29.74) with Microsoft SMTP Server (TLS) id 8.1.375.2; Fri, 31 Jul 2009 12:57:14 -0400
Message-ID: <[e-mail]>
Date: Fri, 31 Jul 2009 11:57:11 -0500
From: "Timothy J. Miller" <[e-mail]>
User-Agent: Thunderbird 2.0.0.22 (Windows/20090605)
MIME-Version: 1.0
To: Santosh Chokhani <[e-mail]>
CC: Stefan Santesson <[e-mail]>, ietf-pkix <[e-mail]>
Subject: Re: Embedded certificate image
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030407070107010104000405"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

Santosh Chokhani wrote:

> RFC says "The relationship between the subject organization and the
> subject
>    organization logotype, and the relationship between the issuer and
>    either the issuer organization logotype or the community logotype,
>    are relationships asserted by the issuer."
> 
> It tends to imply that the logotype is predefined data and not in the
> certificate request payload.

I'd feel better if it were explicit that the subject logotype is 
provided by the issuer.

As it is, I think it can be read either way.  The issuer asserts 
everything in the cert, after all, but it didn't create it all; much was 
provided by the applicant.

-- Tim

--------------ms030407070107010104000405
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
Fw0wOTA3MzExNjU3MTFaMCMGCSqGSIb3DQEJBDEWBBRdAj7b01oOTeEWsk6bRrzbBYPs/DBS
BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D
AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNV
BAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQD
Ex5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAh8FMHQGCyqGSIb3DQEJEAILMWWg
YzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0
eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTANBgkqhkiG
9w0BAQEFAASBgEAkmkAG9HB0sdbSzspSUEtdHeJwwe6yQ4+WSpMqqwW3ZXCMYtrUXi/RXGz3
YgY5T5mT8WHW6r2HNvePIBLHWMF0dUVBZDtOgHfQM8FFgxT0JMRxNdmqpu0PRQOghABZA3GX
pgvNhqPtv47HA9OSPGBfD4MIyFSDxOUDu2dFXFM4AAAAAAAA
--------------ms030407070107010104000405--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6VE3ZnJ081710 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 31 Jul 2009 07:03:35 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6VE3ZNF081709; Fri, 31 Jul 2009 07:03:35 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.145]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6VE3WEu081701 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Fri, 31 Jul 2009 07:03:33 -0700 (MST) (envelope-from [e-mail])
Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e5.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id n6VDu3bF004524 for <[e-mail]>; Fri, 31 Jul 2009 09:56:03 -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 v10.0) with ESMTP id n6VE3Vc1220346 for <[e-mail]>; Fri, 31 Jul 2009 10:03:31 -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 n6VE3VAc027196 for <[e-mail]>; Fri, 31 Jul 2009 10:03:31 -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 n6VE3VqD027167; Fri, 31 Jul 2009 10:03:31 -0400
In-Reply-To: <[e-mail]>
To: Stefan Santesson <[e-mail]>
Cc: ietf-pkix <[e-mail]>, Santosh Chokhani <[e-mail]>, "Timothy J. Miller" <[e-mail]>
MIME-Version: 1.0
Subject: Re: Embedded certificate image
X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006
From: Tom Gindin <[e-mail]>
Message-ID: <[e-mail]>
Date: Fri, 31 Jul 2009 10:03:29 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 8.0.2FP1 ZOS802FP1HF3|June 25, 2009) at 07/31/2009 10:03:30, Serialize complete at 07/31/2009 10:03:30
Content-Type: text/plain; charset="US-ASCII"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

        But isn't the subject organization's logotype precisely the entity 
which could be manipulated to produce a collision?  What other 
unpredictable data is in the image?  The certificate (as distinct from its 
image) is always assembled and created by the CA, but that didn't stop the 
collision attacks at New Year's.  I tend to agree with Timothy about this 
one.
        The simplest way to make this safe against collisions IMHO is to 
add an optional OCTET STRING as the first item (not the last) in the 
logotype extension and have the CA set it to a random value the same size 
as the digest output whenever it puts in an image.  That should break up 
the prefix attack.  Unfortunatly, there is no corresponding field in the 
base definition.
        I have seen Santosh's citation from 3709, but is the subject 
organization's logotype more a "relationship asserted by the issuer" than 
an OU value?

                Tom Gindin




Stefan Santesson <[e-mail]> 
Sent by: [e-mail]
07/30/2009 03:52 PM

To
Santosh Chokhani <[e-mail]>, "Timothy J. Miller" 
<[e-mail]>
cc
ietf-pkix <[e-mail]>
Subject
Re: Embedded certificate image







This is data generated by the CA.

Some included elements, like logotype of the subject organization may be
provided by the applicant but the certificate image is assembled and 
created
by the CA.

/Stefan


On 09-07-30 8:55 PM, "Santosh Chokhani" <[e-mail]> wrote:

> 
> I do not mean to intrude, but is this data being provided by the
> applicant or is this something structured created by the CA or gotten by
> the CA from a source that applicant does not control.
> 
> I ask because depending on the answer, this may become pre-image attack
> and hence impractical.
> 
>> -----Original Message-----
>> From: [e-mail]
>> [mailto:[e-mail]] On Behalf Of Stefan Santesson
>> Sent: Thursday, July 30, 2009 2:32 PM
>> To: Timothy J. Miller
>> Cc: ietf-pkix
>> Subject: Re: Embedded certificate image
>> 
>> 
>> So, with all things taken into account, what is your opinion
>> on what we should do?
>> 
>> Do you argue that we should ignore the feature because it may
>> enhance hash attacks?
>> 
>> /Stefan
>> 
>> On 09-07-30 5:32 PM, "Timothy J. Miller" <[e-mail]> wrote:
>> 
>>> Stefan Santesson wrote:
>>> 
>>>> However, I can't escape that it feels a bit warped if we abandon
>>>> useful features because we must design protocols to resist weak
>>>> hashes instead of making sure that we can and do use
>> adequate hash algorithms.
>>> 
>>> It's a risk-management decision, in the end.  The question
>> is, whose 
>>> risk is it?  The protocol designer's, or the end user's?
>>> 
>>>> On the second point, the data in both SVG and PDF/A are
>> highly structured.
>>>> SVG is for example an XML based vector graphic language.
>>> 
>>> I can bury arbitrary amounts of unstructured data in both
>> SVG and PDF/A.
>>>   SVG allows the same RFC2397 data URLs that you were discussing
>>> previously, and you can embed fonts in both PDF/A (it's actually
>>> required) and SVG.  :)
>>> 
>>> -- Tim
>>> 
>> 
>> 
>> 
> 






Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6VBobpJ068563 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 31 Jul 2009 04:50:37 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6VBobpB068562; Fri, 31 Jul 2009 04:50: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 n6VBoapZ068553 for <[e-mail]>; Fri, 31 Jul 2009 04:50:36 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 30) id 377353A6DD9; Fri, 31 Jul 2009 04:50:33 -0700 (PDT)
X-idtracker: yes
To: IETF-Announce <[e-mail]>
From: The IESG <[e-mail]>
Reply-to: [e-mail]
CC: <[e-mail]>
Subject: Last Call: draft-ietf-pkix-authorityclearanceconstraints (Clearance Attribute and Authority Clearance Constraints Certificate Extension) to Proposed Standard
Message-Id: <[e-mail]>
Date: Fri, 31 Jul 2009 04:50:34 -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:

- 'Clearance Attribute and Authority Clearance Constraints Certificate 
   Extension '
   <draft-ietf-pkix-authorityclearanceconstraints-02.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
[e-mail] mailing lists by 2009-08-14. 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-authorityclearanceconstraints-02.txt


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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6V804rD049109 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 31 Jul 2009 01:00:04 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6V804F9049108; Fri, 31 Jul 2009 01:00:04 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6V804Kh049102 for <[e-mail]>; Fri, 31 Jul 2009 01:00:04 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id BA72B3A6B39; Fri, 31 Jul 2009 01:00:01 -0700 (PDT)
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D Action:draft-ietf-pkix-ocspagility-01.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Fri, 31 Jul 2009 01:00: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           : OCSP Algorithm Agility
	Author(s)       : P. Hallam-Baker, S. Santesson
	Filename        : draft-ietf-pkix-ocspagility-01.txt
	Pages           : 8
	Date            : 2009-07-31

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-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-ocspagility-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 n6ULbwdG012910 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Jul 2009 14:37:58 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6ULbwv9012909; Thu, 30 Jul 2009 14:37:58 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from p03c11o142.symantecmail.net (p03c11o142.symantecmail.net [208.65.144.85]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6ULbuge012902 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 30 Jul 2009 14:37:57 -0700 (MST) (envelope-from [e-mail])
Received: from unknown [65.242.48.5] (EHLO scygexch1.cygnacom.com) by p03c11o142.symantecmail.net (mxl_mta-5.7.0-7) with ESMTP id 5b2127a4.2808093616.420218.00-026.p03c11o142.symantecmail.net (envelope-from <[e-mail]>); Thu, 30 Jul 2009 15:37:57 -0600 (MDT)
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: Embedded certificate image
Date: Thu, 30 Jul 2009 17:37:55 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Embedded certificate image
thread-index: AcoRWRmub0BhqRwcSaycRD64DrJ4MQAAJ6xA
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Santosh Chokhani" <[e-mail]>
To: "Timothy J. Miller" <[e-mail]>
Cc: "Stefan Santesson" <[e-mail]>, "ietf-pkix" <[e-mail]>
X-Spam: [F=0.2000000000; S=0.200(2009071501)]
X-MAIL-FROM: <[e-mail]>
X-SOURCE-IP: [65.242.48.5]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tim,

RFC says "The relationship between the subject organization and the
subject
   organization logotype, and the relationship between the issuer and
   either the issuer organization logotype or the community logotype,
   are relationships asserted by the issuer."

It tends to imply that the logotype is predefined data and not in the
certificate request payload.

> -----Original Message-----
> From: Timothy J. Miller [mailto:[e-mail]]=20
> Sent: Thursday, July 30, 2009 5:03 PM
> To: Santosh Chokhani
> Cc: Stefan Santesson; ietf-pkix
> Subject: Re: Embedded certificate image
>=20
> Santosh Chokhani wrote:
>=20
> > Stefan is saying that the data is not applicant chosen.=20
>=20
> The subject org logotype in 3709 is applicant chosen and has=20
> the same problem.
>=20
> I think the countermeasure of re-ordering extensions is=20
> sufficient, and is probably worth a security consideration in=20
> both specs.
>=20
> -- Tim
>=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 n6UL2pYN011069 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Jul 2009 14:02:51 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6UL2pi5011068; Thu, 30 Jul 2009 14:02:51 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from 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 n6UL2oLM011062 for <[e-mail]>; Thu, 30 Jul 2009 14:02:50 -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 n6UL2nSM008885 for <[e-mail]>; Thu, 30 Jul 2009 17:02:50 -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 n6UL2nsw008882; Thu, 30 Jul 2009 17:02:49 -0400
Received: from [172.31.16.249] (172.31.16.249) by imchub2.MITRE.ORG (129.83.29.74) with Microsoft SMTP Server (TLS) id 8.1.375.2; Thu, 30 Jul 2009 17:02:49 -0400
Message-ID: <[e-mail]>
Date: Thu, 30 Jul 2009 16:02:46 -0500
From: "Timothy J. Miller" <[e-mail]>
User-Agent: Thunderbird 2.0.0.22 (Windows/20090605)
MIME-Version: 1.0
To: Santosh Chokhani <[e-mail]>
CC: Stefan Santesson <[e-mail]>, ietf-pkix <[e-mail]>
Subject: Re: Embedded certificate image
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090207090701000607030201"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

Santosh Chokhani wrote:

> Stefan is saying that the data is not applicant chosen. 

The subject org logotype in 3709 is applicant chosen and has the same 
problem.

I think the countermeasure of re-ordering extensions is sufficient, and 
is probably worth a security consideration in both specs.

-- Tim

--------------ms090207090701000607030201
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
Fw0wOTA3MzAyMTAyNDZaMCMGCSqGSIb3DQEJBDEWBBQdrQYw0JGt0scuBeqw/bDQ6WFv0DBS
BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D
AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNV
BAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQD
Ex5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAh8FMHQGCyqGSIb3DQEJEAILMWWg
YzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0
eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTANBgkqhkiG
9w0BAQEFAASBgDnwTVn79sGEnsTc88YH2Qfk2Jo5a6lNMNcbFAYzvbxuaMj55+pvT6HIDU3l
he/33y4B3Q6NgLHTtTcWqJpPCpgkm6wWmVo5s1J020X6X8RbiTBJ1hXDMNVH2VQAfdRHYAyW
j5vz1tyLTpN6B10H4LOhCCu1A3od7kYFkMMo8+f1AAAAAAAA
--------------ms090207090701000607030201--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6UKj4pY010075 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Jul 2009 13:45:04 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6UKj4h3010074; Thu, 30 Jul 2009 13:45:04 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6UKj3VY010068 for <[e-mail]>; Thu, 30 Jul 2009 13:45:03 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id 4446A3A68E8; Thu, 30 Jul 2009 13:45:00 -0700 (PDT)
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D Action:draft-ietf-pkix-cmp-transport-protocols-06.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Thu, 30 Jul 2009 13: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           : Internet X.509 Public Key Infrastructure -- Transport Protocols for CMP
	Author(s)       : A. Kapoor, et al.
	Filename        : draft-ietf-pkix-cmp-transport-protocols-06.txt
	Pages           : 24
	Date            : 2009-07-30

This document describes how to layer Certificate Management Protocols
over various transport protocols.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-cmp-transport-protocols-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-cmp-transport-protocols-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 n6UKgXix009892 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Jul 2009 13:42:33 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6UKgXVl009891; Thu, 30 Jul 2009 13:42:33 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from p03c11o142.symantecmail.net (p03c11o142.symantecmail.net [208.65.144.85]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6UKgVbB009885 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 30 Jul 2009 13:42:32 -0700 (MST) (envelope-from [e-mail])
Received: from unknown [65.242.48.5] (EHLO scygexch1.cygnacom.com) by p03c11o142.symantecmail.net (mxl_mta-5.7.0-7) with ESMTP id 8b5027a4.2262621104.409675.00-016.p03c11o142.symantecmail.net (envelope-from <[e-mail]>); Thu, 30 Jul 2009 14:42:32 -0600 (MDT)
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: Embedded certificate image
Date: Thu, 30 Jul 2009 16:42:30 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Embedded certificate image
thread-index: AcoRVQq7pyhA+IpSQKy2BDmsPCublgAASxyw
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Santosh Chokhani" <[e-mail]>
To: "Timothy J. Miller" <[e-mail]>
Cc: "Stefan Santesson" <[e-mail]>, "ietf-pkix" <[e-mail]>
X-Spam: [F=0.2000000000; S=0.200(2009071501)]
X-MAIL-FROM: <[e-mail]>
X-SOURCE-IP: [65.242.48.5]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tim,

Stefan is saying that the data is not applicant chosen.=20

> -----Original Message-----
> From: Timothy J. Miller [mailto:[e-mail]]=20
> Sent: Thursday, July 30, 2009 4:34 PM
> To: Santosh Chokhani
> Cc: Stefan Santesson; ietf-pkix
> Subject: Re: Embedded certificate image
>=20
> Santosh Chokhani wrote:
> > I do not mean to intrude, but is this data being provided by the=20
> > applicant or is this something structured created by the CA=20
> or gotten=20
> > by the CA from a source that applicant does not control.
> >=20
> > I ask because depending on the answer, this may become pre-image=20
> > attack and hence impractical.
>=20
> I went and refreshed myself on Stevens et.al.'s paper (and=20
> Lenstra's site on colliding X.509) and while I continue to=20
> struggle to understand it I think the following is true:
>=20
> The presence of a large applicant-controlled data block like=20
> an image in the extensions would allow a chosen prefix attack=20
> using the extension to house the colliding suffixes (S and=20
> S') and the tail construction (T).=20
> This eliminates the restriction that S||T and S'||T must form=20
> a valid RSA modulus, and opens the possibility that the=20
> attacker can use more near-collision blocks (if the image is=20
> larger than the key).  This would make the attack easier, but=20
> I have no earthly idea by how much.
>=20
> On the other hand, the larger prefixes P and P' (as they now=20
> include the whole cert up to the extensions) makes it easier=20
> for the CA to confound the chosen-prefix attack.  The CA=20
> would only need to place an unpredictable extension *before*=20
> the id-pe-logotype prior to signing; that's a simple enough=20
> reordering step.
>=20
> It's worth noting that I think this concern applies to RFC3709 too.
>=20
> So what would I do?  To be safe, you could do one or more of=20
> the following:
>=20
> - Require the CA to reorder the extensions prior to signing,=20
> and never place id-pe-logotype first.
>=20
> - Specify that the image data is entirely CA controlled, or=20
> contains only minimal data that is applicant controlled (and=20
> that applicant-controlled data in total is less than the key length).=20
> Ideally, take the applicant data from other fields in the=20
> request, rather than having the applicant submit his own image data.
>=20
> - Place an upper limit on refStructURI length.  A length less=20
> than the key would probably be sufficient.  Whether this=20
> would be sufficient to house a data URL is an open question;=20
> I don't know.
>=20
> - Finally, prohibiting data URLs entirely is always an option.
>=20
> The reason I say limit applicant data to less than the key=20
> length is because that would restrict the number of collision=20
> blocks the cert image can hold to less than those that can be=20
> held in the modulus. This increases complexity and time for=20
> the attacker if he uses this extension for his collision.  He=20
> can always use the key unless the CA takes other steps to=20
> prevent chosen prefix attacks on its own--which, naturally,=20
> prevents chosen prefix attacks in the extension as well, but=20
> requiring certain CA behavior for *all* certificates is=20
> beyond the scope of this document.  Might be worth a=20
> paragraph in the security considerations, though.
>=20
> All of this presumes that a chosen-prefix attack against SHA=20
> is someday possible, of course.  But it's always good to be=20
> proactive if it's not too difficult.
>=20
> -- Tim
>=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 n6UKXm39009477 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Jul 2009 13:33:48 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6UKXmhA009476; Thu, 30 Jul 2009 13:33:48 -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 n6UKXk2j009470 for <[e-mail]>; Thu, 30 Jul 2009 13:33:47 -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 n6UKXjDH023317 for <[e-mail]>; Thu, 30 Jul 2009 16:33:46 -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 n6UKXjeZ023314; Thu, 30 Jul 2009 16:33:45 -0400
Received: from [172.31.16.249] (172.31.16.249) by imchub2.MITRE.ORG (129.83.29.74) with Microsoft SMTP Server (TLS) id 8.1.375.2; Thu, 30 Jul 2009 16:33:45 -0400
Message-ID: <[e-mail]>
Date: Thu, 30 Jul 2009 15:33:42 -0500
From: "Timothy J. Miller" <[e-mail]>
User-Agent: Thunderbird 2.0.0.22 (Windows/20090605)
MIME-Version: 1.0
To: Santosh Chokhani <[e-mail]>
CC: Stefan Santesson <[e-mail]>, ietf-pkix <[e-mail]>
Subject: Re: Embedded certificate image
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000709090401040607000609"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

Santosh Chokhani wrote:
> I do not mean to intrude, but is this data being provided by the
> applicant or is this something structured created by the CA or gotten by
> the CA from a source that applicant does not control.
> 
> I ask because depending on the answer, this may become pre-image attack
> and hence impractical. 

I went and refreshed myself on Stevens et.al.'s paper (and Lenstra's 
site on colliding X.509) and while I continue to struggle to understand 
it I think the following is true:

The presence of a large applicant-controlled data block like an image in 
the extensions would allow a chosen prefix attack using the extension to 
house the colliding suffixes (S and S') and the tail construction (T). 
This eliminates the restriction that S||T and S'||T must form a valid 
RSA modulus, and opens the possibility that the attacker can use more 
near-collision blocks (if the image is larger than the key).  This would 
make the attack easier, but I have no earthly idea by how much.

On the other hand, the larger prefixes P and P' (as they now include the 
whole cert up to the extensions) makes it easier for the CA to confound 
the chosen-prefix attack.  The CA would only need to place an 
unpredictable extension *before* the id-pe-logotype prior to signing; 
that's a simple enough reordering step.

It's worth noting that I think this concern applies to RFC3709 too.

So what would I do?  To be safe, you could do one or more of the following:

- Require the CA to reorder the extensions prior to signing, and never 
place id-pe-logotype first.

- Specify that the image data is entirely CA controlled, or contains 
only minimal data that is applicant controlled (and that 
applicant-controlled data in total is less than the key length). 
Ideally, take the applicant data from other fields in the request, 
rather than having the applicant submit his own image data.

- Place an upper limit on refStructURI length.  A length less than the 
key would probably be sufficient.  Whether this would be sufficient to 
house a data URL is an open question; I don't know.

- Finally, prohibiting data URLs entirely is always an option.

The reason I say limit applicant data to less than the key length is 
because that would restrict the number of collision blocks the cert 
image can hold to less than those that can be held in the modulus. This 
increases complexity and time for the attacker if he uses this extension 
for his collision.  He can always use the key unless the CA takes other 
steps to prevent chosen prefix attacks on its own--which, naturally, 
prevents chosen prefix attacks in the extension as well, but requiring 
certain CA behavior for *all* certificates is beyond the scope of this 
document.  Might be worth a paragraph in the security considerations, 
though.

All of this presumes that a chosen-prefix attack against SHA is someday 
possible, of course.  But it's always good to be proactive if it's not 
too difficult.

-- Tim

--------------ms000709090401040607000609
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
Fw0wOTA3MzAyMDMzNDJaMCMGCSqGSIb3DQEJBDEWBBRx/ZpakMHNuQts9lc6iOD4Hb0FyDBS
BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D
AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNV
BAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQD
Ex5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAh8FMHQGCyqGSIb3DQEJEAILMWWg
YzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0
eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTANBgkqhkiG
9w0BAQEFAASBgG9BwJQc1AmX8Ohkhd4tmswAdzRYkbcSrkR0Xf11hl6q9wZzsVOCypZoHogt
dEy3hkfAIirMxCd0csAbpdrojoLOLx3CM9ImBB7WT3lc3N3m2FZgLoN4uIU1AsLnI05HXOfy
e1I/9ccyk2Nb35Xn2sZPJbYPetq0ZXcgxNRVDKk4AAAAAAAA
--------------ms000709090401040607000609--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6UKLuhQ008677 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Jul 2009 13:21:56 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6UKLu2L008676; Thu, 30 Jul 2009 13:21: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.ssc.lt (mail.ssc.lt [195.43.64.5]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6UKLstn008670 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 30 Jul 2009 13:21:56 -0700 (MST) (envelope-from [e-mail])
Received: from lan-84-240-23-130.vln.skynet.lt ([84.240.23.130] helo=[127.0.0.1]) by mail.ssc.lt with esmtpsa (SSL 3.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1MWc8H-0002he-1E; Thu, 30 Jul 2009 23:21:45 +0300
Message-ID: <[e-mail]>
Date: Thu, 30 Jul 2009 23:21:36 +0300
From: "Moudrick M. Dadashov" <[e-mail]>
User-Agent: Thunderbird 2.0.0.22 (Windows/20090605)
MIME-Version: 1.0
To: Stefan Santesson <[e-mail]>
CC: Santosh Chokhani <[e-mail]>, "Timothy J. Miller" <[e-mail]>, ietf-pkix <[e-mail]>
Subject: Re: Embedded certificate image
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>

Sorry, I didn't get the idea. Do you mean the CA will create those 
logotypes or the logotypes will be presented to CA as any other Subject 
related data to be included in the certificate?

M.D.

Stefan Santesson wrote:
> This is data generated by the CA.
>
> Some included elements, like logotype of the subject organization may be
> provided by the applicant but the certificate image is assembled and created
> by the CA.
>
> /Stefan
>
>
> On 09-07-30 8:55 PM, "Santosh Chokhani" <[e-mail]> wrote:
>
>   
>> I do not mean to intrude, but is this data being provided by the
>> applicant or is this something structured created by the CA or gotten by
>> the CA from a source that applicant does not control.
>>
>> I ask because depending on the answer, this may become pre-image attack
>> and hence impractical.
>>
>>     
>>> -----Original Message-----
>>> From: [e-mail]
>>> [mailto:[e-mail]] On Behalf Of Stefan Santesson
>>> Sent: Thursday, July 30, 2009 2:32 PM
>>> To: Timothy J. Miller
>>> Cc: ietf-pkix
>>> Subject: Re: Embedded certificate image
>>>
>>>
>>> So, with all things taken into account, what is your opinion
>>> on what we should do?
>>>
>>> Do you argue that we should ignore the feature because it may
>>> enhance hash attacks?
>>>
>>> /Stefan
>>>
>>> On 09-07-30 5:32 PM, "Timothy J. Miller" <[e-mail]> wrote:
>>>
>>>       
>>>> Stefan Santesson wrote:
>>>>
>>>>         
>>>>> However, I can't escape that it feels a bit warped if we abandon
>>>>> useful features because we must design protocols to resist weak
>>>>> hashes instead of making sure that we can and do use
>>>>>           
>>> adequate hash algorithms.
>>>       
>>>> It's a risk-management decision, in the end.  The question
>>>>         
>>> is, whose 
>>>       
>>>> risk is it?  The protocol designer's, or the end user's?
>>>>
>>>>         
>>>>> On the second point, the data in both SVG and PDF/A are
>>>>>           
>>> highly structured.
>>>       
>>>>> SVG is for example an XML based vector graphic language.
>>>>>           
>>>> I can bury arbitrary amounts of unstructured data in both
>>>>         
>>> SVG and PDF/A.
>>>       
>>>>   SVG allows the same RFC2397 data URLs that you were discussing
>>>> previously, and you can embed fonts in both PDF/A (it's actually
>>>> required) and SVG.  :)
>>>>
>>>> -- Tim
>>>>
>>>>         
>>>
>>>       
>
>
>   



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6UJtT9o006929 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Jul 2009 12:55:29 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6UJtTDx006928; Thu, 30 Jul 2009 12:55:29 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from p03c11o142.symantecmail.net (p03c11o142.symantecmail.net [208.65.144.85]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6UJt60O006907 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 30 Jul 2009 12:55:16 -0700 (MST) (envelope-from [e-mail])
Received: from unknown [65.242.48.5] (EHLO scygexch1.cygnacom.com) by p03c11o142.symantecmail.net (mxl_mta-5.7.0-7) with ESMTP id 4aaf17a4.2619276208.399888.00-001.p03c11o142.symantecmail.net (envelope-from <[e-mail]>); Thu, 30 Jul 2009 13:55:16 -0600 (MDT)
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: Embedded certificate image
Date: Thu, 30 Jul 2009 15:55:05 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Embedded certificate image
thread-index: AcoRRATVJ9elVxril0+14j0wFrBD8wAAyVcgAAIILMoAAA2qQA==
References: <[e-mail]> <[e-mail]>
From: "Santosh Chokhani" <[e-mail]>
To: "Stefan Santesson" <[e-mail]>, "Timothy J. Miller" <[e-mail]>
Cc: "ietf-pkix" <[e-mail]>
X-Spam: [F=0.2000000000; S=0.200(2009071501)]
X-MAIL-FROM: <[e-mail]>
X-SOURCE-IP: [65.242.48.5]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Then, a security considerations section describing how this field does
not aid in collision attack should be sufficient.=20

> -----Original Message-----
> From: Stefan Santesson [mailto:[e-mail]]=20
> Sent: Thursday, July 30, 2009 3:53 PM
> To: Santosh Chokhani; Timothy J. Miller
> Cc: ietf-pkix
> Subject: Re: Embedded certificate image
>=20
> This is data generated by the CA.
>=20
> Some included elements, like logotype of the subject=20
> organization may be provided by the applicant but the=20
> certificate image is assembled and created by the CA.
>=20
> /Stefan
>=20
>=20
> On 09-07-30 8:55 PM, "Santosh Chokhani"=20
> <[e-mail]> wrote:
>=20
> >=20
> > I do not mean to intrude, but is this data being provided by the=20
> > applicant or is this something structured created by the CA=20
> or gotten=20
> > by the CA from a source that applicant does not control.
> >=20
> > I ask because depending on the answer, this may become pre-image=20
> > attack and hence impractical.
> >=20
> >> -----Original Message-----
> >> From: [e-mail]
> >> [mailto:[e-mail]] On Behalf Of Stefan Santesson
> >> Sent: Thursday, July 30, 2009 2:32 PM
> >> To: Timothy J. Miller
> >> Cc: ietf-pkix
> >> Subject: Re: Embedded certificate image
> >>=20
> >>=20
> >> So, with all things taken into account, what is your=20
> opinion on what=20
> >> we should do?
> >>=20
> >> Do you argue that we should ignore the feature because it=20
> may enhance=20
> >> hash attacks?
> >>=20
> >> /Stefan
> >>=20
> >> On 09-07-30 5:32 PM, "Timothy J. Miller" <[e-mail]> wrote:
> >>=20
> >>> Stefan Santesson wrote:
> >>>=20
> >>>> However, I can't escape that it feels a bit warped if we abandon=20
> >>>> useful features because we must design protocols to resist weak=20
> >>>> hashes instead of making sure that we can and do use
> >> adequate hash algorithms.
> >>>=20
> >>> It's a risk-management decision, in the end.  The question
> >> is, whose
> >>> risk is it?  The protocol designer's, or the end user's?
> >>>=20
> >>>> On the second point, the data in both SVG and PDF/A are
> >> highly structured.
> >>>> SVG is for example an XML based vector graphic language.
> >>>=20
> >>> I can bury arbitrary amounts of unstructured data in both
> >> SVG and PDF/A.
> >>>   SVG allows the same RFC2397 data URLs that you were discussing=20
> >>> previously, and you can embed fonts in both PDF/A (it's actually
> >>> required) and SVG.  :)
> >>>=20
> >>> -- Tim
> >>>=20
> >>=20
> >>=20
> >>=20
> >=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 n6UJqjGb006758 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Jul 2009 12:52:45 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6UJqjV7006757; Thu, 30 Jul 2009 12:52:45 -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.113]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6UJqgiN006750 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 30 Jul 2009 12:52:44 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 91700 invoked from network); 30 Jul 2009 19:52:49 -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]>; 30 Jul 2009 19:52:48 -0000
Received: (qmail 66349 invoked from network); 30 Jul 2009 19:52:40 -0000
Received: from static-88.131.106.162.addr.tdcsong.se (HELO [10.133.3.238]) ([e-mail]@[88.131.106.162]) (envelope-sender <[e-mail]>) by s42.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <[e-mail]>; 30 Jul 2009 19:52:40 -0000
User-Agent: Microsoft-Entourage/12.20.0.090605
Date: Thu, 30 Jul 2009 21:52:39 +0200
Subject: Re: Embedded certificate image
From: Stefan Santesson <[e-mail]>
To: Santosh Chokhani <[e-mail]>, "Timothy J. Miller" <[e-mail]>
CC: ietf-pkix <[e-mail]>
Message-ID: <[e-mail]>
Thread-Topic: Embedded certificate image
Thread-Index: AcoRRATVJ9elVxril0+14j0wFrBD8wAAyVcgAAIILMo=
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>

This is data generated by the CA.

Some included elements, like logotype of the subject organization may be
provided by the applicant but the certificate image is assembled and created
by the CA.

/Stefan


On 09-07-30 8:55 PM, "Santosh Chokhani" <[e-mail]> wrote:

> 
> I do not mean to intrude, but is this data being provided by the
> applicant or is this something structured created by the CA or gotten by
> the CA from a source that applicant does not control.
> 
> I ask because depending on the answer, this may become pre-image attack
> and hence impractical.
> 
>> -----Original Message-----
>> From: [e-mail]
>> [mailto:[e-mail]] On Behalf Of Stefan Santesson
>> Sent: Thursday, July 30, 2009 2:32 PM
>> To: Timothy J. Miller
>> Cc: ietf-pkix
>> Subject: Re: Embedded certificate image
>> 
>> 
>> So, with all things taken into account, what is your opinion
>> on what we should do?
>> 
>> Do you argue that we should ignore the feature because it may
>> enhance hash attacks?
>> 
>> /Stefan
>> 
>> On 09-07-30 5:32 PM, "Timothy J. Miller" <[e-mail]> wrote:
>> 
>>> Stefan Santesson wrote:
>>> 
>>>> However, I can't escape that it feels a bit warped if we abandon
>>>> useful features because we must design protocols to resist weak
>>>> hashes instead of making sure that we can and do use
>> adequate hash algorithms.
>>> 
>>> It's a risk-management decision, in the end.  The question
>> is, whose 
>>> risk is it?  The protocol designer's, or the end user's?
>>> 
>>>> On the second point, the data in both SVG and PDF/A are
>> highly structured.
>>>> SVG is for example an XML based vector graphic language.
>>> 
>>> I can bury arbitrary amounts of unstructured data in both
>> SVG and PDF/A.
>>>   SVG allows the same RFC2397 data URLs that you were discussing
>>> previously, and you can embed fonts in both PDF/A (it's actually
>>> required) and SVG.  :)
>>> 
>>> -- Tim
>>> 
>> 
>> 
>> 
> 




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6UIu7WR003112 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Jul 2009 11:56:07 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6UIu7Xh003111; Thu, 30 Jul 2009 11:56:07 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from p03c11o143.symantecmail.net (p03c11o143.symantecmail.net [208.65.144.86]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6UItuTN003099 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 30 Jul 2009 11:56:06 -0700 (MST) (envelope-from [e-mail])
Received: from unknown [65.242.48.5] (EHLO scygexch1.cygnacom.com) by p03c11o143.symantecmail.net (mxl_mta-5.7.0-7) with ESMTP id 7cce17a4.3077122992.387399.00-004.p03c11o143.symantecmail.net (envelope-from <[e-mail]>); Thu, 30 Jul 2009 12:56:07 -0600 (MDT)
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: Embedded certificate image
Date: Thu, 30 Jul 2009 14:55:55 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Embedded certificate image
thread-index: AcoRRATVJ9elVxril0+14j0wFrBD8wAAyVcg
References: <[e-mail]> <[e-mail]>
From: "Santosh Chokhani" <[e-mail]>
To: "Stefan Santesson" <[e-mail]>, "Timothy J. Miller" <[e-mail]>
Cc: "ietf-pkix" <[e-mail]>
X-Spam: [F=0.2000000000; S=0.200(2009071501)]
X-MAIL-FROM: <[e-mail]>
X-SOURCE-IP: [65.242.48.5]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I do not mean to intrude, but is this data being provided by the
applicant or is this something structured created by the CA or gotten by
the CA from a source that applicant does not control.

I ask because depending on the answer, this may become pre-image attack
and hence impractical.=20

> -----Original Message-----
> From: [e-mail]=20
> [mailto:[e-mail]] On Behalf Of Stefan Santesson
> Sent: Thursday, July 30, 2009 2:32 PM
> To: Timothy J. Miller
> Cc: ietf-pkix
> Subject: Re: Embedded certificate image
>=20
>=20
> So, with all things taken into account, what is your opinion=20
> on what we should do?
>=20
> Do you argue that we should ignore the feature because it may=20
> enhance hash attacks?
>=20
> /Stefan
>=20
> On 09-07-30 5:32 PM, "Timothy J. Miller" <[e-mail]> wrote:
>=20
> > Stefan Santesson wrote:
> >=20
> >> However, I can't escape that it feels a bit warped if we abandon=20
> >> useful features because we must design protocols to resist weak=20
> >> hashes instead of making sure that we can and do use=20
> adequate hash algorithms.
> >=20
> > It's a risk-management decision, in the end.  The question=20
> is, whose=20
> > risk is it?  The protocol designer's, or the end user's?
> >=20
> >> On the second point, the data in both SVG and PDF/A are=20
> highly structured.
> >> SVG is for example an XML based vector graphic language.
> >=20
> > I can bury arbitrary amounts of unstructured data in both=20
> SVG and PDF/A.
> >   SVG allows the same RFC2397 data URLs that you were discussing=20
> > previously, and you can embed fonts in both PDF/A (it's actually
> > required) and SVG.  :)
> >=20
> > -- Tim
> >=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 n6UIWBQm001776 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Jul 2009 11:32:11 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6UIWBx4001775; Thu, 30 Jul 2009 11:32: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.113]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6UIW2xL001758 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 30 Jul 2009 11:32:09 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 48148 invoked from network); 30 Jul 2009 18:32:07 -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]>; 30 Jul 2009 18:32:07 -0000
Received: (qmail 16422 invoked from network); 30 Jul 2009 18:31:59 -0000
Received: from static-88.131.106.162.addr.tdcsong.se (HELO [10.133.3.238]) ([e-mail]@[88.131.106.162]) (envelope-sender <[e-mail]>) by s42.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <[e-mail]>; 30 Jul 2009 18:31:59 -0000
User-Agent: Microsoft-Entourage/12.20.0.090605
Date: Thu, 30 Jul 2009 20:31:57 +0200
Subject: Re: Embedded certificate image
From: Stefan Santesson <[e-mail]>
To: "Timothy J. Miller" <[e-mail]>
CC: ietf-pkix <[e-mail]>
Message-ID: <[e-mail]>
Thread-Topic: Embedded certificate image
Thread-Index: AcoRRATVJ9elVxril0+14j0wFrBD8w==
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>

So, with all things taken into account, what is your opinion on what we
should do?

Do you argue that we should ignore the feature because it may enhance hash
attacks?

/Stefan

On 09-07-30 5:32 PM, "Timothy J. Miller" <[e-mail]> wrote:

> Stefan Santesson wrote:
> 
>> However, I can't escape that it feels a bit warped if we abandon useful
>> features because we must design protocols to resist weak hashes instead of
>> making sure that we can and do use adequate hash algorithms.
> 
> It's a risk-management decision, in the end.  The question is, whose
> risk is it?  The protocol designer's, or the end user's?
> 
>> On the second point, the data in both SVG and PDF/A are highly structured.
>> SVG is for example an XML based vector graphic language.
> 
> I can bury arbitrary amounts of unstructured data in both SVG and PDF/A.
>   SVG allows the same RFC2397 data URLs that you were discussing
> previously, and you can embed fonts in both PDF/A (it's actually
> required) and SVG.  :)
> 
> -- Tim
> 




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6UFX54V087493 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Jul 2009 08:33:05 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6UFX5eX087492; Thu, 30 Jul 2009 08:33:05 -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 n6UFX40t087481 for <[e-mail]>; Thu, 30 Jul 2009 08:33:04 -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 n6UFX39L011005 for <[e-mail]>; Thu, 30 Jul 2009 11:33:03 -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 n6UFX3pn010999; Thu, 30 Jul 2009 11:33:03 -0400
Received: from [172.31.16.249] (172.31.16.249) by imchub2.MITRE.ORG (129.83.29.74) with Microsoft SMTP Server (TLS) id 8.1.375.2; Thu, 30 Jul 2009 11:33:03 -0400
Message-ID: <[e-mail]>
Date: Thu, 30 Jul 2009 10:32:59 -0500
From: "Timothy J. Miller" <[e-mail]>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Stefan Santesson <[e-mail]>
CC: ietf-pkix <[e-mail]>
Subject: Re: Embedded certificate image
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090407000603090905050804"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

Stefan Santesson wrote:

> However, I can't escape that it feels a bit warped if we abandon useful
> features because we must design protocols to resist weak hashes instead of
> making sure that we can and do use adequate hash algorithms.

It's a risk-management decision, in the end.  The question is, whose 
risk is it?  The protocol designer's, or the end user's?

> On the second point, the data in both SVG and PDF/A are highly structured.
> SVG is for example an XML based vector graphic language.

I can bury arbitrary amounts of unstructured data in both SVG and PDF/A. 
  SVG allows the same RFC2397 data URLs that you were discussing 
previously, and you can embed fonts in both PDF/A (it's actually 
required) and SVG.  :)

-- Tim


--------------ms090407000603090905050804
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
Fw0wOTA3MzAxNTMyNTlaMCMGCSqGSIb3DQEJBDEWBBTXZmTcjK+rPC5o97Coctj+hT943jBS
BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D
AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNV
BAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQD
Ex5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAh8FMHQGCyqGSIb3DQEJEAILMWWg
YzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0
eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTANBgkqhkiG
9w0BAQEFAASBgAUZQDG5OiEP1F5tdgNxDhnrRaluKNZVvqvxFvM7cTpjJIX0gHxGYIcrKUpm
vp82wJVqrnpgrfSQIdJtQSAOBwtljh3UCe3PoK/QoZXA8Gu13NmwJPBP2zm0GP30UjXu8/9n
dFY/UIQlNJVLN7RdkBqDyQG/i91Q6EgwDGl482wZAAAAAAAA
--------------ms090407000603090905050804--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6UEhnP0083392 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Jul 2009 07:43:49 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6UEhnct083391; Thu, 30 Jul 2009 07:43:49 -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.113]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6UEhdxZ083380 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 30 Jul 2009 07:43:48 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 88643 invoked from network); 30 Jul 2009 14:43:42 -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]>; 30 Jul 2009 14:43:42 -0000
Received: (qmail 44315 invoked from network); 30 Jul 2009 14:43:37 -0000
Received: from static-88.131.106.162.addr.tdcsong.se (HELO [10.133.3.238]) ([e-mail]@[88.131.106.162]) (envelope-sender <[e-mail]>) by s29.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <[e-mail]>; 30 Jul 2009 14:43:37 -0000
User-Agent: Microsoft-Entourage/12.20.0.090605
Date: Thu, 30 Jul 2009 16:43:36 +0200
Subject: Re: Embedded certificate image
From: Stefan Santesson <[e-mail]>
To: "Miller, Timothy J." <[e-mail]>, ietf-pkix <[e-mail]>
Message-ID: <[e-mail]>
Thread-Topic: Embedded certificate image
Thread-Index: AcoJ6a+BhbDwMA2b20+h06qSltpcaAAXuBOMAZOvk3QAIg+JwAABJIqR
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>

Understood,

However, I can't escape that it feels a bit warped if we abandon useful
features because we must design protocols to resist weak hashes instead of
making sure that we can and do use adequate hash algorithms.

On the second point, the data in both SVG and PDF/A are highly structured.
SVG is for example an XML based vector graphic language.

/Stefan


On 09-07-30 4:16 PM, "Miller, Timothy J." <[e-mail]> wrote:

>> Russ came up with a concern that all hash attacks loves big chunks of
>> random data that can be used to create collisions. Counter arguments is
>> that this is only a concern is a week hash is used and also that the
>> data has some structure as it is base64 encoded.
> 
> Since no-one knows what the next weakness in any hash will be, this isn't a
> valid counter-argument to Russ's point, IMHO.  SHA1 could be completely
> broken tomorrow.
> 
> Sotirov, Stevens, Lenstra, et.al. would have had an easier time, I should
> think, if there was a big chunk of data in each cert *other* than they key.
> Also, the actual image data is largely unstructrured past the image header;
> but any structure in this data is largely immaterial to a collision
> construction attack.
> 
> -- Tim
> 




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6UEGwDI081165 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Jul 2009 07:16:58 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6UEGw84081164; Thu, 30 Jul 2009 07:16:58 -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 n6UEGjZd081136 for <[e-mail]>; Thu, 30 Jul 2009 07:16:56 -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 n6UEGi6b032177 for <[e-mail]>; Thu, 30 Jul 2009 10:16:45 -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 n6UEGiZd032174; Thu, 30 Jul 2009 10:16:44 -0400
Received: from IMCMBX2.MITRE.ORG ([129.83.29.205]) by imchub2.MITRE.ORG ([129.83.29.74]) with mapi; Thu, 30 Jul 2009 10:16:44 -0400
From: "Miller, Timothy J." <[e-mail]>
To: "'Stefan Santesson'" <[e-mail]>, ietf-pkix <[e-mail]>
Date: Thu, 30 Jul 2009 10:16:43 -0400
Subject: RE: Embedded certificate image
Thread-Topic: Embedded certificate image
Thread-Index: AcoJ6a+BhbDwMA2b20+h06qSltpcaAAXuBOMAZOvk3QAIg+JwA==
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0000_01CA10F6.73FB78E0"
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_0000_01CA10F6.73FB78E0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

>Russ came up with a concern that all hash attacks loves big chunks of
>random data that can be used to create collisions. Counter arguments is
>that this is only a concern is a week hash is used and also that the
>data has some structure as it is base64 encoded.

Since no-one knows what the next weakness in any hash will be, this isn't a
valid counter-argument to Russ's point, IMHO.  SHA1 could be completely
broken tomorrow.

Sotirov, Stevens, Lenstra, et.al. would have had an easier time, I should
think, if there was a big chunk of data in each cert *other* than they key.
Also, the actual image data is largely unstructrured past the image header;
but any structure in this data is largely immaterial to a collision
construction attack.

-- Tim


------=_NextPart_000_0000_01CA10F6.73FB78E0
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
BTEPFw0wOTA3MzAxNDE2NDJaMCMGCSqGSIb3DQEJBDEWBBR1K5YXwToPwo4SCVEFtVued9zFIjBn
BgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIB
QDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTByBgkrBgEEAYI3
EAQxZTBjMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9y
aXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAh8FMHQGCyqGSIb3
DQEJEAILMWWgYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1
dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTANBgkq
hkiG9w0BAQEFAASBgEo2edZ7KUJ+pC6BczIo4/nP92jNaMPEd47IAmHBaxpGq4BkgKXnZiqMEDSZ
rDTqAka8M6LiERud5g9eqc7+wxng7L9MlSOGmClnL0UamvIEO1wPuGpIyZICJ+dg/5MkY9h86dCX
nr0boYjfSZ0tGlCi1raZw3w7oVXpyjDPgSIuAAAAAAAA

------=_NextPart_000_0000_01CA10F6.73FB78E0--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6UAv10E051799 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Jul 2009 03:57:01 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6UAv1lQ051798; Thu, 30 Jul 2009 03:57:01 -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 n6UAuoqi051775 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <[e-mail]>; Thu, 30 Jul 2009 03:57:00 -0700 (MST) (envelope-from [e-mail])
Received: from GALATIONS (dhcp-11ba.meeting.ietf.org [130.129.17.186]) by smtp4.pacifier.net (Postfix) with ESMTP id 9B1F86A9B5; Thu, 30 Jul 2009 03:56:48 -0700 (PDT)
From: "Jim Schaad" <[e-mail]>
To: "'Stefan Santesson'" <[e-mail]>, "'Peter Gutmann'" <[e-mail]>, <[e-mail]>, <[e-mail]>
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: RE: Embedded certificate image
Date: Thu, 30 Jul 2009 12:56:10 +0200
Message-ID: <0a1501ca1104$5a4652e0$0ed2f8a0$@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: AcoQ7ch2V67FGYF9T0GYcAu4PWihYwAFmkqw
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>

RFC 2397  The data URL scheme.  Limitations on the length of the URL are
application dependent.

> -----Original Message-----
> From: [e-mail] [mailto:owner-ietf-
> [e-mail]] On Behalf Of Stefan Santesson
> Sent: Thursday, July 30, 2009 10:15 AM
> To: Peter Gutmann; [e-mail]; [e-mail]
> Subject: Re: Embedded certificate image
> 
> 
> Peter,
> 
> In-line;
> 
> On 09-07-30 10:01 AM, "Peter Gutmann" <[e-mail]>
> wrote:
> 
> >
> > Stefan Santesson <[e-mail]> writes:
> >
> >> This is the case for RFC 3709, which is the standard we would use to
> bind a
> >> cert image to the certificate. RFC 3709 does only offer a URL as
> means of
> >> referring to the actual image, it does not offer any other means of
> local
> >> storage.
> >
> > Why not use one of the type-and-value options, OtherLogoTypeInfo or
> something?
> > This just seems like a horrible kludge, like pounding a nail with a
> scredriver
> > because that's what was lying around.
> 
> We have concluded that the RFC 3709 syntax does not allow any such
> option or
> extensibility. It's either in the URL or nothing at all.
> 
> >
> > How do you distinguish real URLs from not-a-real-URLs?
> >
> > Peter.
> >
> 
> That is my question to Jim. Apparently there is an RFC that would tell.
> 
> In any case, this is just an interesting idea that we should
> investigate. I
> have scary feelings too about this but I would like to turn the stone
> and
> look at it before throwing this option away.
> 
> /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 n6U8EiGv038651 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Jul 2009 01:14:45 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6U8EiTD038650; Thu, 30 Jul 2009 01:14: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.113]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6U8EfVv038635 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 30 Jul 2009 01:14:43 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 21000 invoked from network); 30 Jul 2009 08:14:42 -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]>; 30 Jul 2009 08:14:42 -0000
Received: (qmail 72376 invoked from network); 30 Jul 2009 08:14:40 -0000
Received: from static-88.131.106.162.addr.tdcsong.se (HELO [10.133.3.238]) ([e-mail]@[88.131.106.162]) (envelope-sender <[e-mail]>) by s60.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <[e-mail]>; 30 Jul 2009 08:14:40 -0000
User-Agent: Microsoft-Entourage/12.20.0.090605
Date: Thu, 30 Jul 2009 10:14:39 +0200
Subject: Re: Embedded certificate image
From: Stefan Santesson <[e-mail]>
To: Peter Gutmann <[e-mail]>, <[e-mail]>, <[e-mail]>
Message-ID: <[e-mail]>
Thread-Topic: Embedded certificate image
Thread-Index: AcoQ7ch2V67FGYF9T0GYcAu4PWihYw==
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,

In-line;

On 09-07-30 10:01 AM, "Peter Gutmann" <[e-mail]> wrote:

> 
> Stefan Santesson <[e-mail]> writes:
> 
>> This is the case for RFC 3709, which is the standard we would use to bind a
>> cert image to the certificate. RFC 3709 does only offer a URL as means of
>> referring to the actual image, it does not offer any other means of local
>> storage.
> 
> Why not use one of the type-and-value options, OtherLogoTypeInfo or something?
> This just seems like a horrible kludge, like pounding a nail with a scredriver
> because that's what was lying around.

We have concluded that the RFC 3709 syntax does not allow any such option or
extensibility. It's either in the URL or nothing at all.

> 
> How do you distinguish real URLs from not-a-real-URLs?
> 
> Peter.
> 

That is my question to Jim. Apparently there is an RFC that would tell.

In any case, this is just an interesting idea that we should investigate. I
have scary feelings too about this but I would like to turn the stone and
look at it before throwing this option away.

/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 n6U81a9x037397 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Jul 2009 01:01:46 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6U81aU0037396; Thu, 30 Jul 2009 01:01:36 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mailhost.auckland.ac.nz (moe.its.auckland.ac.nz [130.216.12.35]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6U81P1g037372 for <[e-mail]>; Thu, 30 Jul 2009 01:01:35 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id A5A11171A58; Thu, 30 Jul 2009 20:01:24 +1200 (NZST)
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (moe.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oe4xIej3LX4y; Thu, 30 Jul 2009 20:01:24 +1200 (NZST)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 52306171381; Thu, 30 Jul 2009 20:01:24 +1200 (NZST)
Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 65B341A662F8; Thu, 30 Jul 2009 20:01:23 +1200 (NZST)
Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from <[e-mail]>) id 1MWQZn-0003tn-92; Thu, 30 Jul 2009 20:01:23 +1200
From: Peter Gutmann <[e-mail]>
To: [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: Embedded certificate image
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
Date: Thu, 30 Jul 2009 20:01:23 +1200
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stefan Santesson <[e-mail]> writes:

>This is the case for RFC 3709, which is the standard we would use to bind a
>cert image to the certificate. RFC 3709 does only offer a URL as means of
>referring to the actual image, it does not offer any other means of local
>storage.

Why not use one of the type-and-value options, OtherLogoTypeInfo or something? 
This just seems like a horrible kludge, like pounding a nail with a scredriver 
because that's what was lying around.

How do you distinguish real URLs from not-a-real-URLs?

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 n6U7iauw036115 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Jul 2009 00:44:36 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6U7iaQx036114; Thu, 30 Jul 2009 00:44: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.113]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6U7iXYI036103 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 30 Jul 2009 00:44:35 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 24732 invoked from network); 30 Jul 2009 07:44:34 -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]>; 30 Jul 2009 07:44:34 -0000
Received: (qmail 57861 invoked from network); 30 Jul 2009 07:44:31 -0000
Received: from static-88.131.106.162.addr.tdcsong.se (HELO [10.133.3.238]) ([e-mail]@[88.131.106.162]) (envelope-sender <[e-mail]>) by s60.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <[e-mail]>; 30 Jul 2009 07:44:31 -0000
User-Agent: Microsoft-Entourage/12.20.0.090605
Date: Thu, 30 Jul 2009 09:44:30 +0200
Subject: Re: Embedded certificate image
From: Stefan Santesson <[e-mail]>
To: Peter Gutmann <[e-mail]>, <[e-mail]>, <[e-mail]>
Message-ID: <[e-mail]>
Thread-Topic: Embedded certificate image
Thread-Index: AcoQ6ZI3cP7DeB3yD0a6BwVTdwKfhw==
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>

Good question.

The reason would be to allow data to be stored locally when the original
specification only offers the option to specify a URL to the location of the
data.

This is the case for RFC 3709, which is the standard we would use to bind a
cert image to the certificate. RFC 3709 does only offer a URL as means of
referring to the actual image, it does not offer any other means of local
storage.

By providing the image in the URL, we could offer a way to embed the image
and still stay within the syntax of the original spec.

/Stefan


On 09-07-30 9:36 AM, "Peter Gutmann" <[e-mail]> wrote:

> Yoav Nir <[e-mail]> writes:
> 
>> I guess that if the image is embedded in the URL, you don't really need to
>> follow it, just process it locally.
> 
> In that case why encode it as a URL in the first place?
> 
> 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 n6U7amJJ035625 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Jul 2009 00:36:48 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6U7amTm035624; Thu, 30 Jul 2009 00:36:48 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.33]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6U7aa4v035605 for <[e-mail]>; Thu, 30 Jul 2009 00:36:47 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 51CFF9C3F2; Thu, 30 Jul 2009 19:36:36 +1200 (NZST)
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yUClU7XuUUUm; Thu, 30 Jul 2009 19:36:36 +1200 (NZST)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 972C366922F; Thu, 30 Jul 2009 19:36:33 +1200 (NZST)
Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 76B7119F4001; Thu, 30 Jul 2009 19:36:30 +1200 (NZST)
Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from <[e-mail]>) id 1MWQBi-0002jI-Ae; Thu, 30 Jul 2009 19:36:30 +1200
From: Peter Gutmann <[e-mail]>
To: [e-mail], [e-mail], [e-mail], [e-mail]
Subject: RE: Embedded certificate image
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
Date: Thu, 30 Jul 2009 19:36:30 +1200
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Yoav Nir <[e-mail]> writes:

>I guess that if the image is embedded in the URL, you don't really need to 
>follow it, just process it locally.

In that case why encode it as a URL in the first place?

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 n6U6R8ok030824 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Jul 2009 23:27:08 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6U6R83U030822; Wed, 29 Jul 2009 23:27:08 -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.113]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6U6Qsv6030801 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 29 Jul 2009 23:27:06 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 853 invoked from network); 30 Jul 2009 06:26:55 -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]>; 30 Jul 2009 06:26:55 -0000
Received: (qmail 71957 invoked from network); 30 Jul 2009 06:26:53 -0000
Received: from static-88.131.106.162.addr.tdcsong.se (HELO [10.133.3.238]) ([e-mail]@[88.131.106.162]) (envelope-sender <[e-mail]>) by s42.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <[e-mail]>; 30 Jul 2009 06:26:53 -0000
User-Agent: Microsoft-Entourage/12.20.0.090605
Date: Thu, 30 Jul 2009 08:26:52 +0200
Subject: Re: Embedded certificate image
From: Stefan Santesson <[e-mail]>
To: Yoav Nir <[e-mail]>, "'Peter Gutmann'" <[e-mail]>, "[e-mail]" <[e-mail]>
Message-ID: <[e-mail]>
Thread-Topic: Embedded certificate image
Thread-Index: AcoQzZGvN8aL9aguS4C+fXwW7SsvSwAAFqlAAAQzYCo=
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>

Exactly


On 09-07-30 6:26 AM, "Yoav Nir" <[e-mail]> wrote:

> 
> I guess that if the image is embedded in the URL, you don't really need to
> follow it, just process it locally.
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Peter Gutmann
> Sent: Thursday, July 30, 2009 7:10 AM
> To: [e-mail]; [e-mail]
> Subject: Re: Embedded certificate image
> 
> 
> Stefan Santesson <[e-mail]> writes:
> 
>> It seems that there are ways to store base64 encoded data in a URL. Since all
>> images are located through a URL, this opens interesting possibilities if the
>> URL actually contains the image data itself.
> 
> How big are these things going to get?  Anything beyond about 1024 characters
> and you start running into problems with things that reject over-long URLs.
> 
> Peter.
> 
> 
> Email secured by Check Point
> 




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6U4RDYb022681 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Jul 2009 21:27:13 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6U4RDDE022680; Wed, 29 Jul 2009 21:27:13 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6U4R1aI022660 for <[e-mail]>; Wed, 29 Jul 2009 21:27:12 -0700 (MST) (envelope-from [e-mail])
Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 8AE2F29C005; Thu, 30 Jul 2009 07:27:13 +0300 (IDT)
Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 43C3E29C002; Thu, 30 Jul 2009 07:27:13 +0300 (IDT)
X-CheckPoint: {4A711FA6-0-14201DC2-1FFFF}
Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n6U4Qs3d027091; Thu, 30 Jul 2009 07:26:55 +0300 (IDT)
Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Thu, 30 Jul 2009 07:26:54 +0300
From: Yoav Nir <[e-mail]>
To: "'Peter Gutmann'" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Date: Thu, 30 Jul 2009 07:26:53 +0300
Subject: RE: Embedded certificate image
Thread-Topic: Embedded certificate image
Thread-Index: AcoQzZGvN8aL9aguS4C+fXwW7SsvSwAAFqlA
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I guess that if the image is embedded in the URL, you don't really need to =
follow it, just process it locally.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On=
 Behalf Of Peter Gutmann
Sent: Thursday, July 30, 2009 7:10 AM
To: [e-mail]; [e-mail]
Subject: Re: Embedded certificate image


Stefan Santesson <[e-mail]> writes:

>It seems that there are ways to store base64 encoded data in a URL. Since =
all
>images are located through a URL, this opens interesting possibilities if =
the
>URL actually contains the image data itself.

How big are these things going to get?  Anything beyond about 1024 characte=
rs
and you start running into problems with things that reject over-long URLs.

Peter.


Email secured by Check Point



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6U4Al6V021510 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Jul 2009 21:10:47 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6U4AlW3021509; Wed, 29 Jul 2009 21:10:47 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.33]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6U4AYVY021487 for <[e-mail]>; Wed, 29 Jul 2009 21:10:45 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 5F3C06683E5; Thu, 30 Jul 2009 16:10:30 +1200 (NZST)
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q3k2fnXJTX87; Thu, 30 Jul 2009 16:10:30 +1200 (NZST)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id DF1286683D4; Thu, 30 Jul 2009 16:10:23 +1200 (NZST)
Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 72AB219EC0BC; Thu, 30 Jul 2009 16:10:22 +1200 (NZST)
Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from <[e-mail]>) id 1MWMyE-0000cm-B5; Thu, 30 Jul 2009 16:10:22 +1200
From: Peter Gutmann <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Embedded certificate image
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
Date: Thu, 30 Jul 2009 16:10:22 +1200
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stefan Santesson <[e-mail]> writes:

>It seems that there are ways to store base64 encoded data in a URL. Since all
>images are located through a URL, this opens interesting possibilities if the
>URL actually contains the image data itself.

How big are these things going to get?  Anything beyond about 1024 characters
and you start running into problems with things that reject over-long URLs.

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 n6TLtwKs000940 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Jul 2009 14:55:58 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6TLtw3E000939; Wed, 29 Jul 2009 14:55:58 -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.113]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6TLtjoQ000926 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 29 Jul 2009 14:55:57 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 31357 invoked from network); 29 Jul 2009 21:55: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]>; 29 Jul 2009 21:55:52 -0000
Received: (qmail 28513 invoked from network); 29 Jul 2009 21:55:43 -0000
Received: from static-88.131.106.162.addr.tdcsong.se (HELO [10.133.3.238]) ([e-mail]@[88.131.106.162]) (envelope-sender <[e-mail]>) by s19.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <[e-mail]>; 29 Jul 2009 21:55:43 -0000
User-Agent: Microsoft-Entourage/12.20.0.090605
Date: Wed, 29 Jul 2009 23:55:37 +0200
Subject: Re: Embedded certificate image
From: Stefan Santesson <[e-mail]>
To: ietf-pkix <[e-mail]>
Message-ID: <[e-mail]>
Thread-Topic: Embedded certificate image
Thread-Index: AcoJ6a+BhbDwMA2b20+h06qSltpcaAAXuBOMAZOvk3Q=
In-Reply-To: <[e-mail]>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3331756543_10385817"
Sender: [e-mail]
Precedence: 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_3331756543_10385817
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit

Jim Schaad provided a very interesting idea to this issue at PKIX today

It seems that there are ways to store base64 encoded data in a URL. Since
all images are located through a URL, this opens interesting possibilities
if the URL actually contains the image data itself.

I think it could make sense in many situations and environments to provide
the image inside the certificate in this form.

Russ came up with a concern that all hash attacks loves big chunks of random
data that can be used to create collisions. Counter arguments is that this
is only a concern is a week hash is used and also that the data has some
structure as it is base64 encoded.

Jim, could you provide more specific information about the underlying
specification that would enable this?

/Stefan 

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

<HTML>
<HEAD>
<TITLE>Re: Embedded certificate image</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt=
'>Jim Schaad provided a very interesting idea to this issue at PKIX today<BR=
>
<BR>
It seems that there are ways to store base64 encoded data in a URL. Since a=
ll images are located through a URL, this opens interesting possibilities if=
 the URL actually contains the image data itself.<BR>
<BR>
I think it could make sense in many situations and environments to provide =
the image inside the certificate in this form.<BR>
<BR>
Russ came up with a concern that all hash attacks loves big chunks of rando=
m data that can be used to create collisions. Counter arguments is that this=
 is only a concern is a week hash is used and also that the data has some st=
ructure as it is base64 encoded.<BR>
<BR>
Jim, could you provide more specific information about the underlying speci=
fication that would enable this?<BR>
<BR>
/Stefan </SPAN></FONT>
</BODY>
</HTML>


--B_3331756543_10385817--




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6T92vWI037091 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Jul 2009 02:02:58 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6T92vRk037090; Wed, 29 Jul 2009 02:02: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.113]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6T92imm037071 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 29 Jul 2009 02:02:56 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 31101 invoked from network); 29 Jul 2009 09:02:46 -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]>; 29 Jul 2009 09:02:46 -0000
Received: (qmail 19813 invoked from network); 29 Jul 2009 09:02:43 -0000
Received: from static-88.131.106.162.addr.tdcsong.se (HELO [10.133.3.238]) ([e-mail]@[88.131.106.162]) (envelope-sender <[e-mail]>) by s42.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <[e-mail]>; 29 Jul 2009 09:02:43 -0000
User-Agent: Microsoft-Entourage/12.20.0.090605
Date: Wed, 29 Jul 2009 11:02:42 +0200
Subject: Re: WGLC on draft-ietf-pkix-new-asn1-05.txt
From: Stefan Santesson <[e-mail]>
To: "[e-mail]" <[e-mail]>
Message-ID: <[e-mail]>
Thread-Topic: WGLC on draft-ietf-pkix-new-asn1-05.txt
Thread-Index: AcoAMYSCTdtsO7y6eEuE+5lrugQPGgP+c/x2
In-Reply-To: <[e-mail]>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3331710163_8436001"
Sender: [e-mail]
Precedence: 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_3331710163_8436001
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit

It is my interpretation of the last call discussion that all comments have
been dealt with and that we are ready to hand this document over to the
IESG.

/Stefan


On 09-07-09 3:06 AM, "Stefan Santesson" <[e-mail]> wrote:

> 
> Initiating WG last call on draft-ietf-pkix-new-asn1-05.txt
> Last call ends on Friday July 24.
> 
> /Stefan


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

<HTML>
<HEAD>
<TITLE>Re: WGLC on draft-ietf-pkix-new-asn1-05.txt</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt=
'>It is my interpretation of the last call discussion that all comments have=
 been dealt with and that we are ready to hand this document over to the IES=
G.<BR>
<BR>
/Stefan<BR>
<BR>
<BR>
On 09-07-09 3:06 AM, &quot;Stefan Santesson&quot; &lt;<a href=3D"stefan@aaa-s=
ec.com">[e-mail]</a>&gt; wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><=
SPAN STYLE=3D'font-size:11pt'><BR>
Initiating WG last call on </SPAN></FONT><FONT SIZE=3D"1"><FONT FACE=3D"Geneva,=
 Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:9pt'>draft-ietf-pkix-new-=
asn1-05.txt<BR>
Last call ends on Friday July 24.<BR>
<BR>
/Stefan</SPAN></FONT></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:11pt'><BR>
</SPAN></FONT></BLOCKQUOTE>
</BODY>
</HTML>


--B_3331710163_8436001--




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6SFB5gF063057 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Jul 2009 08:11:05 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6SFB5ff063056; Tue, 28 Jul 2009 08:11:05 -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 n6SFB4Ke063050 for <[e-mail]>; Tue, 28 Jul 2009 08:11:04 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 30) id EE3F73A703D; Tue, 28 Jul 2009 08:10:59 -0700 (PDT)
X-idtracker: yes
To: IETF-Announce <[e-mail]>
From: The IESG <[e-mail]>
Reply-to: [e-mail]
CC: <[e-mail]>
Subject: Last Call: draft-ietf-pkix-other-certs (Other Certificates Extension) to Experimental RFC
Message-Id: <[e-mail]>
Date: Tue, 28 Jul 2009 08:10:59 -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:

- 'Other Certificates Extension '
   <draft-ietf-pkix-other-certs-04.txt> as an Experimental RFC

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-08-11. 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-other-certs-04.txt


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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6SEJVe4057386 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Jul 2009 07:19:31 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6SEJVl4057385; Tue, 28 Jul 2009 07:19:31 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from p03c11o142.symantecmail.net (p03c11o142.symantecmail.net [208.65.144.85]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6SEJJm6057370 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 28 Jul 2009 07:19:30 -0700 (MST) (envelope-from [e-mail])
Received: from unknown [65.242.48.5] (EHLO scygexch1.cygnacom.com) by p03c11o142.symantecmail.net (mxl_mta-5.7.0-7) with ESMTP id 2f80f6a4.2032507824.311477.00-001.p03c11o142.symantecmail.net (envelope-from <[e-mail]>); Tue, 28 Jul 2009 08:19:30 -0600 (MDT)
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: Comments on Draft-ietf-pkix-asn1-translation
Date: Tue, 28 Jul 2009 10:19:16 -0400
Message-ID: <[e-mail]>
In-Reply-To: <056d01ca0f81$e3beca90$ab3c5fb0$@com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Comments on Draft-ietf-pkix-asn1-translation
thread-index: AcoPgdh9H1Kwf082S+So/Hp6q0HXOwACnsMg
References: <056d01ca0f81$e3beca90$ab3c5fb0$@com>
From: "Carl Wallace" <[e-mail]>
To: "Jim Schaad" <[e-mail]>
Cc: "Charles W. Gardiner" <[e-mail]>, <[e-mail]>
X-Spam: [F=0.2000000000; S=0.200(2009071501)]
X-MAIL-FROM: <[e-mail]>
X-SOURCE-IP: [65.242.48.5]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Thanks, Jim.  I accepted all of your suggested text and will address ANY
and the integer option of ANY DEFINED BY.  There were three comments I
didn't quite follow.

Section 2.1.2 - The SubjectPublicKeyInfo one is a strained example.  It
assumes that one actually understands the structures from RFC5280.  i.e.
no similar comment to the extnValue case and the adjacent OCTET STRING
cannot been seen.

[CRW] I don't understand your point.  Would you prefer a DSA signature
value as an example or maybe an ASN.1 dump?

Section 2.1.2 - The example might be more interesting if you actually
dumped the Extension object - thus seeing the OCTET STRING wrapping.

[CRW] The example is a dump of the extension, including the OCTET
STRING.  Would you prefer it be scoped just to the OCTET STRING?

Section 2.2.3 -
   The example of the BIT STRING does not have a constraint on it.  You
could refer the the example just above.
  =20
[CRW] The lack of a constraint is noted in the text describing the
example, which is demonstrating usage of prose as a means of
constraining the value.  The purpose of the example is to show that a
constraint cannot be specified relative to a field within the
AlgorithmIdentifier structure.

> -----Original Message-----
> From: Jim Schaad [mailto:[e-mail]]
> Sent: Tuesday, July 28, 2009 2:50 PM
> To: Carl Wallace
> Cc: 'Charles W. Gardiner'; [e-mail]
> Subject: Comments on Draft-ietf-pkix-asn1-translation
>=20
> Sorry I did not get to this sooner, I completely missed the
publication
> announcement and did not realize that it had been put out.
>=20
> New Paragraph for section #1.
>=20
> Transforming a new ASN.1 module to an older ASN.1 module can be
> performed in
> a fairly mechanical manner, much of the transformation consists of
> deleting
> new constructs.  Transforming an older ASN.1 module to a newer ASN.1
> module
> can be done fairly mechanically, if one does not wish to move many of
> the
> constraints that are contained in the prose into the ASN.1 module.  If
> the
> constraints are to be added, then the conversion can be a complex
> process.
>=20
> Section 1.1 - Delete paragraph #1 - I think that the only place where
> you
> have these keywords is in the examples, an as such it does not make
> sense to
> have the compliance terms defined.
>=20
> Section 2.1.1 - ANY DEFINED BY can use either an OBJECT IDENTIFIER or
> an
> INTEGER as the identification field.  (See ExtensionAttribute in
> RFC5280.)
>=20
> Section 2.1.1 - Need to talk about a plain ANY - see RFC5280
> AttributeValue
>=20
> Section 2.1.1 - s/does not provide a means/does not provide a formal
> means/
> 	New sentence:  Any associations are done in the comments of the
> module and/or the text of the associated document.
>=20
> Section 2.1.2 - The SubjectPublicKeyInfo one is a strained example.
It
> assumes that one actually understands the structures from RFC5280.
> i.e. no
> similar comment to the extnValue case and the adjacent OCTET STRING
> cannot
> been seen.
>=20
> Section 2.1.2 - The example might be more interesting if you actually
> dumped
> the Extension object - thus seeing the OCTET STRING wrapping.
>=20
> Section 2.1.3 - I want to change the intro here a bit.
>=20
> Information object classes are defined in [].  Object classes allow
> protocol
> designers to associated pieces of data that are in some way
associated.
> In
> the most generic of terms, an Information Object class can be thought
> of as
> a database schema, with Information Object Sets being instances of the
> databases.
>=20
> Unlike type definitions, object classes with the same structure are
not
> equivalent.  Thus if you have:
>=20
>     FOO ::=3D TYPE-IDENTIFIER
>     BAR ::=3D TYPE-IDENTIFIER
>=20
> FOO and BAR are not interchangeable.
>=20
> TYPE-IDENTIFIER is one of the predefined information object classes in
> Annex
> A of [].  This provides for a simple mapping from an OBJECT IDENTIFIER
> to a
> data type.  The tag UNIQUE on &id means that this value may appear
only
> once
> in an Information Object Set, however multiple objects can be defined
> with
> the same &id value.
>=20
> Section 2.2.2 -
>=20
>    Component relation constraints are often used to bind the type
field
>    of an open type to the identifier field.  Using the binding in this
> ways
> allows for
>    a compiler to immediately decode the associated type when the
> containing
> structure is defined.  The following example from
>    [RFC2560] as updated [I-D.ietf-pkix-new-asn1] demonstrates this
>    usage.
>=20
> Section 2.2.2 -
>=20
> In this example, the responseType has a simple constraint applied to
it
> while the response field is constrained to contain a type
>    identified by the responseType field.  The controlling field is
> identified
>=20
>=20
> Section 2.2.2
>=20
> For example, the following example includes invalid
>    atNotation in the defintion of the signature field within the
SIGNED
> paramterized type.
>=20
>  Section 2.2.2
>=20
>    In the above example, the outermost SEQUENCE, SET or CHOICE
relative
>    to the parameters field is the structure named ToBeSigned.
>=20
> 		- the structure is NOT named ToBeSigned.  The type is
not
> actually named, but would probably be best referred to as the SIGNED
> type
> (or SIGNED parameterized type).
>=20
> Section 2.2.3 -
>    The example of the BIT STRING does not have a constraint on it.
You
> could refer the the example just above.
>=20
>=20
> Section 4.1 and Section 4.2
>   We need to have some level of checklists at this point which allows
> people
> to know what they needed to be doing.
>=20
> 4.1
> 1) Remove all Information Set Class, Information Set Object and
> Information
> Set Object Set definitions and imports from the file.
>=20
> 2) Replace all fixed Type Information Set Class element references
with
> the
> fixed type.
>=20
> 3) Delete all simple constraints
>=20
> 4) Delete all CONTAINING statements
>=20
> 5) Convert the remaining Content Constraints into either ANY or ANY
> DEFINED
> BY statements.
>=20
> 6) Remove version and extension markers
>=20
> 7) Hand instantiate all instances of parameterized types.
>=20
>=20
> 4.2  Simple
>=20
> 1) Use TYPE-IDENTIFIER.&Type for "ANY"
>=20
> 2) Use TYPE-IDENTIFIER.&Type for "ANY DEFINED BY ..."
>=20
> 4.2  Complex
>=20
> 1)  Identify each unique class that should be defined based on what
> types of
> things exist.
>=20
> 2)  Define an Information Object Class for each of the classes above
> with
> the appropriate elements.
>=20
> 3)  Define the all of appropriate Information Object Sets based on the
> classes defined in step 2 along with the different places that they
> should
> be used.
>=20
> 4)  Replace ANY by the appropriate class and variable type element.
>=20
> 5)  Replace ANY DEFINED BY with the appropriate variable type element
> and
> the components constraint.
>=20
> 6)  Add any simple constraints as appropriate.
>=20
> 7)  Define any objects and fill in elements for object sets as
> appropriate.
>=20
>=20
> There is probably more -- but this is a good first cut.
>=20
> Jim
>=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 n6RElSPs057839 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Jul 2009 07:47:28 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6RElS7p057838; Mon, 27 Jul 2009 07:47:28 -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 n6RElRZf057829 for <[e-mail]>; Mon, 27 Jul 2009 07:47:27 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 30) id 4B2313A6B22; Mon, 27 Jul 2009 07:47:25 -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: 'An Internet Attribute Certificate Profile for Authorization' to Proposed Standard
Message-Id: <[e-mail]>
Date: Mon, 27 Jul 2009 07:47:25 -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:

- 'An Internet Attribute Certificate Profile for Authorization '
   <draft-ietf-pkix-3281update-05.txt> as a Proposed Standard


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

The IESG contact persons are Tim Polk and Pasi Eronen.

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

Technical Summary

This specification defines a profile for the use of X.509 Attribute
Certificates in Internet Protocols.  Attribute certificates may be used in
a wide range of applications and environments covering a broad spectrum of
interoperability goals and a broader spectrum of operational and assurance
requirements.  The goal of this document is to establish a common baseline
for generic applications requiring broad interoperability as well as
limited special purpose requirements.  The profile places emphasis on
attribute certificate support for Internet electronic mail, IPsec, and WWW
security applications.  This document obsoletes RFC 3281.

Working Group Summary

This ID was discussed on the mailing list and at multiple meetings. It is
a simple update to address known errata posted to the RFC editor and to
address an issue identified as a result of developing the
draft-ietf-pkix-authorityclearanceconstraints ID.  The clearance attribute
object identifier didn't match the attribute's X.509 object identifier.

Document Quality

This document is an update of an existing draft and is comparable
in quality to its predecessor.  Note that most of the changes listed in
Appendix C of the document are a result of the long lag time between
updates (e.g., reference updates).

Personnel

Steve Kent is the document Shepherd.  Tim Polk is the responsible
Security Area AD.

RFC Editor Note

License Note:
This document is being forwarded for publication assuming that the
proposed update to the TLP will be completed by the IETF Trust prior
to completion of the RFC publication process.  If that process does not
terminate successfully, please make the following substitution in
Appendix B, replacing RFC XXXX with the number assigned to this RFC:

OLD

   DEFINITIONS IMPLICIT TAGS ::=

NEW

   DEFINITIONS IMPLICIT TAGS ::=

--   Copyright (c) 2009 IETF Trust and the persons identified as
--   authors of the code.  All rights reserved.
--
--   Redistribution and use in source and binary forms, with or without
--   modification, are permitted provided that the following conditions
--   are met:
--
--   - Redistributions of source code must retain the above copyright
--     notice, this list of conditions and the following disclaimer.
--
--   - Redistributions in binary form must reproduce the above copyright
--     notice, this list of conditions and the following disclaimer in
--     the documentation and/or other materials provided with the
--     distribution.
--
--   - Neither the name of Internet Society, IETF or IETF Trust, nor the
--     names of specific contributors, may be used to endorse or promote
--     products derived from this software without specific prior
--     written permission.
--
--
--
--   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
--   'AS IS' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
--   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
--   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
--   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
--   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
--   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
--   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
--   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
--   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
--   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
--
--   This code is part of RFC XXXX; see the RFC itself for full legal
notices.
-- 
--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6R36aJd003052 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 26 Jul 2009 20: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 n6R36aHI003051; Sun, 26 Jul 2009 20: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 szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6R36NaN003032 for <[e-mail]>; Sun, 26 Jul 2009 20:06:34 -0700 (MST) (envelope-from [e-mail])
Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <[e-mail]> for [e-mail]; Mon, 27 Jul 2009 11:06:00 +0800 (CST)
Received: from huawei.com ([172.24.1.33]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <[e-mail]> for [e-mail]; Mon, 27 Jul 2009 11:06:00 +0800 (CST)
Received: from z54906b ([10.168.86.61]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <[e-mail]> for [e-mail]; Mon, 27 Jul 2009 11:06:00 +0800 (CST)
Date: Mon, 27 Jul 2009 11:05:59 +0800
From: Zhipeng Zhou <[e-mail]>
Subject: RE: Welcome your kind comments on "draft-zhipeng-pkix-drm-proxy-architecture".
In-reply-to: <[e-mail]>
To: "'Tom Gindin'" <[e-mail]>
Cc: "'PKIX'" <[e-mail]>
Message-id: <000501ca0e67$2b582de0$[e-mail]>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset=gb2312
Content-transfer-encoding: quoted-printable
Thread-index: AcoNdK/IhnTUIssKTVGZ4vt2qUXovAA72brQ
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

That sentence means after parsing the authorization document the Service
Server would exactly know what service rights can be issued to Device A
through the delegate of Device B.
Take an example in the routine life, A asks B to borrow 50 dollars from =
the
bank, then the bank will just lends 50 dollars (not 100) to A through =
the
hands of B.=20
Sure, the wording will be reshaped.
If your second paragraph is about the update of authorization, I feel a =
new
section is needed to explain that part.

Thank you.
Zhipeng
=20

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] =
On
Behalf Of Tom Gindin
Sent: Sunday, July 26, 2009 5:40 AM
To: Zhipeng Zhou
Cc: 'PKIX'
Subject: RE: Welcome your kind comments on
"draft-zhipeng-pkix-drm-proxy-architecture".

        The last sentence of the first sentence on page 6 goes, "Once =
all
these verifications are correct, the Service Server will also catch the
rights that are authorized to Proxy Device B by Request Device A via =
parsing
the elements in the Authorization document."  I am not sure what that =
means,
precisely.  If you mean "will also cache the rights authorized on behalf =
of
Request Device A (via parsing ...) for use through Proxy Device B", then =
B
has no independent set of rights.  That could also be worded "will cache =
the
rights delegated by Request Device A (via parsing
...) to Proxy Device B".
        I assume that A is trying to delegate those rights specified in =
the
ServiceRights field.  What rights does B now have?  It could be the
intersection of A's configured rights with ServiceRights, or the
intersection of B's configured rights with ServiceRights, or the union =
of
B's pre-existing configured rights with the intersection of A's =
configured
rights and ServiceRights.

                Tom Gindin





Zhipeng Zhou <[e-mail]>
07/24/2009 09:44 PM

To
Tom Gindin/Watson/IBM@IBMUS
cc
"'PKIX'" <[e-mail]>
Subject
RE: Welcome your kind comments on
"draft-zhipeng-pkix-drm-proxy-architecture".







Thanks for comments.=20
In DRM specification, the Request message will contain the signature of=20
the
Request entity.=20
I think better to give a concise introduction of this point.
Here I am not quite clear of your said " If device B's rights are to be
added to device A's authorization", can you pls give me a use case to =
help
me understand it.
Thank you.
Zhipeng


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

On
Behalf Of Tom Gindin
Sent: Friday, July 24, 2009 9:46 PM
To: Zhipeng Zhou
Cc: 'Perez, Aram'; 'PKIX'
Subject: RE: Welcome your kind comments on
"draft-zhipeng-pkix-drm-proxy-architecture".

        I don't see any signature applied by Proxy Device B, so what is=20
the
point of its certificate in this protocol?  I am not questioning the
function of the proxy itself, just of its certificate.  If device B's=20
rights
are to be added to device A's authorization, should it not authenticate
itself at some point, perhaps through a countersignature?

                Tom Gindin




Zhipeng Zhou <[e-mail]>
Sent by: [e-mail]
07/22/2009 08:57 PM

To
"'Perez, Aram'" <[e-mail]>
cc
"'PKIX'" <[e-mail]>
Subject
RE: Welcome your kind comments on
"draft-zhipeng-pkix-drm-proxy-architecture".






Hi Aram,
Nice to hear you.
Are you going to Sweden ?
If you can help me gathering more comments in the meeting, that will be=20
exactly wonderful for me.
Thank you.
Zhipeng

From: [e-mail] [mailto:[e-mail]] =

On Behalf Of Perez, Aram
Sent: Thursday, July 23, 2009 3:50 AM
To: PKIX
Subject: Re: Welcome your kind comments on=20
"draft-zhipeng-pkix-drm-proxy-architecture".

Hi Zhipeng,

Interesting draft RFC. Here are a few minor comments:

=A1=B0Trusty=A1=B1 is not a word. I believe what you want to say is =
=A1=B0trusted=20
relationship=A1=B1.=20
In section 5.1 you are using the binary format description language we=20
defined in OMA DRM but you have not explained how it is used.

Take care,
Aram


On 7/21/09 8:12 PM, Zhipeng Zhou  wrote:

Stefan and all,
I'd ask if the PKIX guys in the Sweden meeting could feeback me your =
kind=20
comments or suggesions on my draft-zhipeng-pkix-drm-proxy-architecture=20
<blocked::
http://tools.ietf.org/id/draft-zhipeng-pkix-drm-proxy-architecture-00.txt=
>=20

 .
Since some reasons, I could not be in the meeting. Welcome your emails=20
anytime.
Thanks very much.
Zhipeng
=20
-----------------------------------------------------

Huawei Software Technologies Co.,Ltd.

Floor 2, Building A, NO.48=A3=ACNing Nan AV.,Nanjing, P.R.of China
Zipcode:210012
E-Mail: [e-mail] <mailto:[e-mail]>=20
Phone:[phone]
Fax:[phone]

Mobile:[phone]
-----------------------------------------------------

=20

*************************************************************************=
***
***********************************
=A1=A1=A1=A1=B1=BE=D3=CA=BC=FE=BC=B0=C6=E4=B8=BD=BC=FE=BA=AC=D3=D0=BB=AA=CE=
=AA=B9=AB=CB=BE=B5=C4=B1=A3=C3=DC=D0=C5=CF=A2=A3=AC=BD=F6=CF=DE=D3=DA=B7=A2=
=CB=CD=B8=F8=C9=CF=C3=E6=B5=D8=D6=B7=D6=D0=C1=D0=B3=F6=B5=C4=B8=F6=C8=CB
=BB=F2=C8=BA=D7=E9=A1=A3=BD=FB=D6=B9=C8=CE=BA=CE=C6=E4=CB=FB=C8=CB=D2=D4=C8=
=CE=BA=CE=D0=CE=CA=BD=CA=B9=D3=C3

=A3=A8=B0=FC=C0=A8=B5=AB=B2=BB=CF=DE=D3=DA=C8=AB=B2=BF=BB=F2=B2=BF=B7=D6=B5=
=D8=D0=B9=C2=B6=A1=A2=B8=B4=D6=C6=A1=A2=BB=F2=C9=A2=B7=A2=A3=A9=B1=BE=D3=CA=
=BC=FE=D6=D0=B5=C4=D0=C5=CF=A2=A1=A3

    =
=C8=E7=B9=FB=C4=FA=B4=ED=CA=D5=C1=CB=B1=BE=D3=CA=BC=FE=A3=AC=C7=EB=C4=FA=C1=
=A2=BC=B4=B5=E7=BB=B0=BB=F2=D3=CA=BC=FE=CD=A8=D6=AA=B7=A2=BC=FE=C8=CB=B2=A2=
=C9=BE=B3=FD=B1=BE=D3=CA=BC=FE=A3=A1
*************************************************************************=
***
***********************************


*************************************************************************=
***
***********************************
    This e-mail and its attachments contain confidential information =
from=20
HUAWEI, which is intended only for the

person or entity whose address is listed above. Any use of the =
information=20

contained herein in any way(including,

but not limited to, total or partial disclosure, reproduction, or=20
dissemination) by persons other than the intended

recipient(s) is prohibited.=20

    If you receive this e-mail in error, please notify the sender by =
phone=20

or email immediately and delete it!
*************************************************************************=
***
***********************************


=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 n6PLeM4E011925 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 25 Jul 2009 14:40:22 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6PLeMID011924; Sat, 25 Jul 2009 14:40:22 -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 n6PLeAe7011914 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Sat, 25 Jul 2009 14:40:21 -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.14.3/8.13.1) with ESMTP id n6PHdxVM017573 for <[e-mail]>; Sat, 25 Jul 2009 13:39:59 -0400
Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n6PLe9Ww219144 for <[e-mail]>; Sat, 25 Jul 2009 17:40:09 -0400
Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n6PLbTg5006269 for <[e-mail]>; Sat, 25 Jul 2009 17:37:30 -0400
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.56.228.115]) by d01av02.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n6PLbTx4006260; Sat, 25 Jul 2009 17:37:29 -0400
In-Reply-To: <009a01ca0cc9$653b37e0$[e-mail]>
To: Zhipeng Zhou <[e-mail]>
Cc: "'PKIX'" <[e-mail]>
MIME-Version: 1.0
Subject: RE: Welcome your kind comments on "draft-zhipeng-pkix-drm-proxy-architecture".
X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006
From: Tom Gindin <[e-mail]>
Message-ID: <[e-mail]>
Date: Sat, 25 Jul 2009 17:40:07 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 8.0.2FP1 ZOS802FP1HF3|June 25, 2009) at 07/25/2009 17:40:07, Serialize complete at 07/25/2009 17:40:07
Content-Type: text/plain; charset="GB2312"
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>

ICAgICAgICBUaGUgbGFzdCBzZW50ZW5jZSBvZiB0aGUgZmlyc3Qgc2VudGVuY2Ugb24gcGFnZSA2
IGdvZXMsICJPbmNlIGFsbCANCnRoZXNlIHZlcmlmaWNhdGlvbnMgYXJlIGNvcnJlY3QsIHRoZSBT
ZXJ2aWNlIFNlcnZlciB3aWxsIGFsc28gY2F0Y2ggdGhlIA0KcmlnaHRzIHRoYXQgYXJlIGF1dGhv
cml6ZWQgdG8gUHJveHkgRGV2aWNlIEIgYnkgUmVxdWVzdCBEZXZpY2UgQSB2aWEgDQpwYXJzaW5n
IHRoZSBlbGVtZW50cyBpbiB0aGUgQXV0aG9yaXphdGlvbiBkb2N1bWVudC4iICBJIGFtIG5vdCBz
dXJlIHdoYXQgDQp0aGF0IG1lYW5zLCBwcmVjaXNlbHkuICBJZiB5b3UgbWVhbiAid2lsbCBhbHNv
IGNhY2hlIHRoZSByaWdodHMgYXV0aG9yaXplZCANCm9uIGJlaGFsZiBvZiBSZXF1ZXN0IERldmlj
ZSBBICh2aWEgcGFyc2luZyAuLi4pIGZvciB1c2UgdGhyb3VnaCBQcm94eSANCkRldmljZSBCIiwg
dGhlbiBCIGhhcyBubyBpbmRlcGVuZGVudCBzZXQgb2YgcmlnaHRzLiAgVGhhdCBjb3VsZCBhbHNv
IGJlIA0Kd29yZGVkICJ3aWxsIGNhY2hlIHRoZSByaWdodHMgZGVsZWdhdGVkIGJ5IFJlcXVlc3Qg
RGV2aWNlIEEgKHZpYSBwYXJzaW5nIA0KLi4uKSB0byBQcm94eSBEZXZpY2UgQiIuDQogICAgICAg
IEkgYXNzdW1lIHRoYXQgQSBpcyB0cnlpbmcgdG8gZGVsZWdhdGUgdGhvc2UgcmlnaHRzIHNwZWNp
ZmllZCBpbiANCnRoZSBTZXJ2aWNlUmlnaHRzIGZpZWxkLiAgV2hhdCByaWdodHMgZG9lcyBCIG5v
dyBoYXZlPyAgSXQgY291bGQgYmUgdGhlIA0KaW50ZXJzZWN0aW9uIG9mIEEncyBjb25maWd1cmVk
IHJpZ2h0cyB3aXRoIFNlcnZpY2VSaWdodHMsIG9yIHRoZSANCmludGVyc2VjdGlvbiBvZiBCJ3Mg
Y29uZmlndXJlZCByaWdodHMgd2l0aCBTZXJ2aWNlUmlnaHRzLCBvciB0aGUgdW5pb24gb2YgDQpC
J3MgcHJlLWV4aXN0aW5nIGNvbmZpZ3VyZWQgcmlnaHRzIHdpdGggdGhlIGludGVyc2VjdGlvbiBv
ZiBBJ3MgY29uZmlndXJlZCANCnJpZ2h0cyBhbmQgU2VydmljZVJpZ2h0cy4NCg0KICAgICAgICAg
ICAgICAgIFRvbSBHaW5kaW4NCg0KDQoNCg0KDQpaaGlwZW5nIFpob3UgPHpob3V6cEBodWF3ZWku
Y29tPiANCjA3LzI0LzIwMDkgMDk6NDQgUE0NCg0KVG8NClRvbSBHaW5kaW4vV2F0c29uL0lCTUBJ
Qk1VUw0KY2MNCiInUEtJWCciIDxpZXRmLXBraXhAaW1jLm9yZz4NClN1YmplY3QNClJFOiBXZWxj
b21lIHlvdXIga2luZCBjb21tZW50cyBvbiANCiJkcmFmdC16aGlwZW5nLXBraXgtZHJtLXByb3h5
LWFyY2hpdGVjdHVyZSIuDQoNCg0KDQoNCg0KDQoNClRoYW5rcyBmb3IgY29tbWVudHMuIA0KSW4g
RFJNIHNwZWNpZmljYXRpb24sIHRoZSBSZXF1ZXN0IG1lc3NhZ2Ugd2lsbCBjb250YWluIHRoZSBz
aWduYXR1cmUgb2YgDQp0aGUNClJlcXVlc3QgZW50aXR5LiANCkkgdGhpbmsgYmV0dGVyIHRvIGdp
dmUgYSBjb25jaXNlIGludHJvZHVjdGlvbiBvZiB0aGlzIHBvaW50Lg0KSGVyZSBJIGFtIG5vdCBx
dWl0ZSBjbGVhciBvZiB5b3VyIHNhaWQgIiBJZiBkZXZpY2UgQidzIHJpZ2h0cyBhcmUgdG8gYmUN
CmFkZGVkIHRvIGRldmljZSBBJ3MgYXV0aG9yaXphdGlvbiIsIGNhbiB5b3UgcGxzIGdpdmUgbWUg
YSB1c2UgY2FzZSB0byBoZWxwDQptZSB1bmRlcnN0YW5kIGl0Lg0KVGhhbmsgeW91Lg0KWmhpcGVu
Zw0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBvd25lci1pZXRmLXBraXhA
bWFpbC5pbWMub3JnIFttYWlsdG86b3duZXItaWV0Zi1wa2l4QG1haWwuaW1jLm9yZ10gDQpPbg0K
QmVoYWxmIE9mIFRvbSBHaW5kaW4NClNlbnQ6IEZyaWRheSwgSnVseSAyNCwgMjAwOSA5OjQ2IFBN
DQpUbzogWmhpcGVuZyBaaG91DQpDYzogJ1BlcmV6LCBBcmFtJzsgJ1BLSVgnDQpTdWJqZWN0OiBS
RTogV2VsY29tZSB5b3VyIGtpbmQgY29tbWVudHMgb24NCiJkcmFmdC16aGlwZW5nLXBraXgtZHJt
LXByb3h5LWFyY2hpdGVjdHVyZSIuDQoNCiAgICAgICAgSSBkb24ndCBzZWUgYW55IHNpZ25hdHVy
ZSBhcHBsaWVkIGJ5IFByb3h5IERldmljZSBCLCBzbyB3aGF0IGlzIA0KdGhlDQpwb2ludCBvZiBp
dHMgY2VydGlmaWNhdGUgaW4gdGhpcyBwcm90b2NvbD8gIEkgYW0gbm90IHF1ZXN0aW9uaW5nIHRo
ZQ0KZnVuY3Rpb24gb2YgdGhlIHByb3h5IGl0c2VsZiwganVzdCBvZiBpdHMgY2VydGlmaWNhdGUu
ICBJZiBkZXZpY2UgQidzIA0KcmlnaHRzDQphcmUgdG8gYmUgYWRkZWQgdG8gZGV2aWNlIEEncyBh
dXRob3JpemF0aW9uLCBzaG91bGQgaXQgbm90IGF1dGhlbnRpY2F0ZQ0KaXRzZWxmIGF0IHNvbWUg
cG9pbnQsIHBlcmhhcHMgdGhyb3VnaCBhIGNvdW50ZXJzaWduYXR1cmU/DQoNCiAgICAgICAgICAg
ICAgICBUb20gR2luZGluDQoNCg0KDQoNClpoaXBlbmcgWmhvdSA8emhvdXpwQGh1YXdlaS5jb20+
DQpTZW50IGJ5OiBvd25lci1pZXRmLXBraXhAbWFpbC5pbWMub3JnDQowNy8yMi8yMDA5IDA4OjU3
IFBNDQoNClRvDQoiJ1BlcmV6LCBBcmFtJyIgPGFyYW1wQHF1YWxjb21tLmNvbT4NCmNjDQoiJ1BL
SVgnIiA8aWV0Zi1wa2l4QGltYy5vcmc+DQpTdWJqZWN0DQpSRTogV2VsY29tZSB5b3VyIGtpbmQg
Y29tbWVudHMgb24NCiJkcmFmdC16aGlwZW5nLXBraXgtZHJtLXByb3h5LWFyY2hpdGVjdHVyZSIu
DQoNCg0KDQoNCg0KDQpIaSBBcmFtLA0KTmljZSB0byBoZWFyIHlvdS4NCkFyZSB5b3UgZ29pbmcg
dG8gU3dlZGVuID8NCklmIHlvdSBjYW4gaGVscCBtZSBnYXRoZXJpbmcgbW9yZSBjb21tZW50cyBp
biB0aGUgbWVldGluZywgdGhhdCB3aWxsIGJlIA0KZXhhY3RseSB3b25kZXJmdWwgZm9yIG1lLg0K
VGhhbmsgeW91Lg0KWmhpcGVuZw0KDQpGcm9tOiBvd25lci1pZXRmLXBraXhAbWFpbC5pbWMub3Jn
IFttYWlsdG86b3duZXItaWV0Zi1wa2l4QG1haWwuaW1jLm9yZ10gDQpPbiBCZWhhbGYgT2YgUGVy
ZXosIEFyYW0NClNlbnQ6IFRodXJzZGF5LCBKdWx5IDIzLCAyMDA5IDM6NTAgQU0NClRvOiBQS0lY
DQpTdWJqZWN0OiBSZTogV2VsY29tZSB5b3VyIGtpbmQgY29tbWVudHMgb24gDQoiZHJhZnQtemhp
cGVuZy1wa2l4LWRybS1wcm94eS1hcmNoaXRlY3R1cmUiLg0KDQpIaSBaaGlwZW5nLA0KDQpJbnRl
cmVzdGluZyBkcmFmdCBSRkMuIEhlcmUgYXJlIGEgZmV3IG1pbm9yIGNvbW1lbnRzOg0KDQqhsFRy
dXN0eaGxIGlzIG5vdCBhIHdvcmQuIEkgYmVsaWV2ZSB3aGF0IHlvdSB3YW50IHRvIHNheSBpcyCh
sHRydXN0ZWQgDQpyZWxhdGlvbnNoaXChsS4gDQpJbiBzZWN0aW9uIDUuMSB5b3UgYXJlIHVzaW5n
IHRoZSBiaW5hcnkgZm9ybWF0IGRlc2NyaXB0aW9uIGxhbmd1YWdlIHdlIA0KZGVmaW5lZCBpbiBP
TUEgRFJNIGJ1dCB5b3UgaGF2ZSBub3QgZXhwbGFpbmVkIGhvdyBpdCBpcyB1c2VkLg0KDQpUYWtl
IGNhcmUsDQpBcmFtDQoNCg0KT24gNy8yMS8wOSA4OjEyIFBNLCBaaGlwZW5nIFpob3UgIHdyb3Rl
Og0KDQpTdGVmYW4gYW5kIGFsbCwNCkknZCBhc2sgaWYgdGhlIFBLSVggZ3V5cyBpbiB0aGUgU3dl
ZGVuIG1lZXRpbmcgY291bGQgZmVlYmFjayBtZSB5b3VyIGtpbmQgDQpjb21tZW50cyBvciBzdWdn
ZXNpb25zIG9uIG15IGRyYWZ0LXpoaXBlbmctcGtpeC1kcm0tcHJveHktYXJjaGl0ZWN0dXJlIA0K
PGJsb2NrZWQ6Og0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LXpoaXBlbmctcGtpeC1k
cm0tcHJveHktYXJjaGl0ZWN0dXJlLTAwLnR4dD4gDQoNCiAuDQpTaW5jZSBzb21lIHJlYXNvbnMs
IEkgY291bGQgbm90IGJlIGluIHRoZSBtZWV0aW5nLiBXZWxjb21lIHlvdXIgZW1haWxzIA0KYW55
dGltZS4NClRoYW5rcyB2ZXJ5IG11Y2guDQpaaGlwZW5nDQogDQotLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpIdWF3ZWkgU29mdHdhcmUgVGVj
aG5vbG9naWVzIENvLixMdGQuDQoNCkZsb29yIDIsIEJ1aWxkaW5nIEEsIE5PLjQ4o6xOaW5nIE5h
biBBVi4sTmFuamluZywgUC5SLm9mIENoaW5hDQpaaXBjb2RlOjIxMDAxMg0KRS1NYWlsOiB6aG91
enBAaHVhd2VpLmNvbSA8bWFpbHRvOnpob3V6cEBodWF3ZWkuY29tPiANClBob25lOigrODYpIDI1
LTgyMjc2NzcxDQpGYXg6KCs4NikgMjUtODIyNzY3NjANCg0KTW9iaWxlOigrODYpIDEzNDA0MTYy
ODQ5DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LQ0KDQogDQoNCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqDQqhoaGhsb7Tyrz+vLDG5Li9vP66rNPQu6rOqrmry761xLGjw9zQxc+io6y99s/e
09q3osvNuPjJz8PmtdjWt9bQwdCz9rXEuPbIyw0Ku/LIutfpoaO9+9a5yM66zsbky/vIy9LUyM66
ztDOyr3KudPDDQoNCqOosPzAqLWrsrvP3tPayKuyv7vysr+31rXY0LnCtqGiuLTWxqGiu/LJorei
o6mxvtPKvP7W0LXE0MXPoqGjDQoNCiAgICDI57n7xPq07crVwcuxvtPKvP6jrMfrxPrBory0tee7
sLvy08q8/s2o1qq3orz+yMuyosm+s/2xvtPKvP6joQ0KKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCg0KDQoqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
DQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KICAgIFRoaXMgZS1tYWlsIGFu
ZCBpdHMgYXR0YWNobWVudHMgY29udGFpbiBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24gZnJvbSAN
CkhVQVdFSSwgd2hpY2ggaXMgaW50ZW5kZWQgb25seSBmb3IgdGhlDQoNCnBlcnNvbiBvciBlbnRp
dHkgd2hvc2UgYWRkcmVzcyBpcyBsaXN0ZWQgYWJvdmUuIEFueSB1c2Ugb2YgdGhlIGluZm9ybWF0
aW9uIA0KDQpjb250YWluZWQgaGVyZWluIGluIGFueSB3YXkoaW5jbHVkaW5nLA0KDQpidXQgbm90
IGxpbWl0ZWQgdG8sIHRvdGFsIG9yIHBhcnRpYWwgZGlzY2xvc3VyZSwgcmVwcm9kdWN0aW9uLCBv
ciANCmRpc3NlbWluYXRpb24pIGJ5IHBlcnNvbnMgb3RoZXIgdGhhbiB0aGUgaW50ZW5kZWQNCg0K
cmVjaXBpZW50KHMpIGlzIHByb2hpYml0ZWQuIA0KDQogICAgSWYgeW91IHJlY2VpdmUgdGhpcyBl
LW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBieSBwaG9uZSANCg0Kb3Ig
ZW1haWwgaW1tZWRpYXRlbHkgYW5kIGRlbGV0ZSBpdCENCioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQoNCg0KIA0KDQoNCg0KDQoNCg==



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6P1iQ83042491 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Jul 2009 18:44:26 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6P1iQWt042490; Fri, 24 Jul 2009 18:44:26 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6P1iFIj042477 for <[e-mail]>; Fri, 24 Jul 2009 18:44:25 -0700 (MST) (envelope-from [e-mail])
Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <[e-mail]> for [e-mail]; Sat, 25 Jul 2009 09:44:09 +0800 (CST)
Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <[e-mail]> for [e-mail]; Sat, 25 Jul 2009 09:44:09 +0800 (CST)
Received: from z54906b ([10.168.86.61]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <[e-mail]> for [e-mail]; Sat, 25 Jul 2009 09:44:08 +0800 (CST)
Date: Sat, 25 Jul 2009 09:44:05 +0800
From: Zhipeng Zhou <[e-mail]>
Subject: RE: Welcome your kind comments on "draft-zhipeng-pkix-drm-proxy-architecture".
In-reply-to: <[e-mail]>
To: "'Tom Gindin'" <[e-mail]>
Cc: "'PKIX'" <[e-mail]>
Message-id: <009a01ca0cc9$653b37e0$[e-mail]>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset=gb2312
Content-transfer-encoding: quoted-printable
Thread-index: AcoMae2Mdn6zKi1YQtev3sAAiUkCOAAXQJ4A
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Thanks for comments.=20
In DRM specification, the Request message will contain the signature of =
the
Request entity.=20
I think better to give a concise introduction of this point.
Here I am not quite clear of your said " If device B's rights are to be
added to device A's authorization", can you pls give me a use case to =
help
me understand it.
Thank you.
Zhipeng


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] =
On
Behalf Of Tom Gindin
Sent: Friday, July 24, 2009 9:46 PM
To: Zhipeng Zhou
Cc: 'Perez, Aram'; 'PKIX'
Subject: RE: Welcome your kind comments on
"draft-zhipeng-pkix-drm-proxy-architecture".

        I don't see any signature applied by Proxy Device B, so what is =
the
point of its certificate in this protocol?  I am not questioning the
function of the proxy itself, just of its certificate.  If device B's =
rights
are to be added to device A's authorization, should it not authenticate
itself at some point, perhaps through a countersignature?

                Tom Gindin




Zhipeng Zhou <[e-mail]>
Sent by: [e-mail]
07/22/2009 08:57 PM

To
"'Perez, Aram'" <[e-mail]>
cc
"'PKIX'" <[e-mail]>
Subject
RE: Welcome your kind comments on
"draft-zhipeng-pkix-drm-proxy-architecture".






Hi Aram,
Nice to hear you.
Are you going to Sweden ?
If you can help me gathering more comments in the meeting, that will be=20
exactly wonderful for me.
Thank you.
Zhipeng

From: [e-mail] [mailto:[e-mail]] =

On Behalf Of Perez, Aram
Sent: Thursday, July 23, 2009 3:50 AM
To: PKIX
Subject: Re: Welcome your kind comments on=20
"draft-zhipeng-pkix-drm-proxy-architecture".

Hi Zhipeng,

Interesting draft RFC. Here are a few minor comments:

=A1=B0Trusty=A1=B1 is not a word. I believe what you want to say is =
=A1=B0trusted=20
relationship=A1=B1.=20
In section 5.1 you are using the binary format description language we=20
defined in OMA DRM but you have not explained how it is used.

Take care,
Aram


On 7/21/09 8:12 PM, Zhipeng Zhou  wrote:

Stefan and all,
I'd ask if the PKIX guys in the Sweden meeting could feeback me your =
kind=20
comments or suggesions on my draft-zhipeng-pkix-drm-proxy-architecture=20
<blocked::
http://tools.ietf.org/id/draft-zhipeng-pkix-drm-proxy-architecture-00.txt=
>=20
 .
Since some reasons, I could not be in the meeting. Welcome your emails=20
anytime.
Thanks very much.
Zhipeng
=20
-----------------------------------------------------

Huawei Software Technologies Co.,Ltd.

Floor 2, Building A, NO.48=A3=ACNing Nan AV.,Nanjing, P.R.of China
Zipcode:210012
E-Mail: [e-mail] <mailto:[e-mail]>=20
Phone:[phone]
Fax:[phone]

Mobile:[phone]
-----------------------------------------------------

=20

*************************************************************************=
***
***********************************
=A1=A1=A1=A1=B1=BE=D3=CA=BC=FE=BC=B0=C6=E4=B8=BD=BC=FE=BA=AC=D3=D0=BB=AA=CE=
=AA=B9=AB=CB=BE=B5=C4=B1=A3=C3=DC=D0=C5=CF=A2=A3=AC=BD=F6=CF=DE=D3=DA=B7=A2=
=CB=CD=B8=F8=C9=CF=C3=E6=B5=D8=D6=B7=D6=D0=C1=D0=B3=F6=B5=C4=B8=F6=C8=CB
=BB=F2=C8=BA=D7=E9=A1=A3=BD=FB=D6=B9=C8=CE=BA=CE=C6=E4=CB=FB=C8=CB=D2=D4=C8=
=CE=BA=CE=D0=CE=CA=BD=CA=B9=D3=C3

=A3=A8=B0=FC=C0=A8=B5=AB=B2=BB=CF=DE=D3=DA=C8=AB=B2=BF=BB=F2=B2=BF=B7=D6=B5=
=D8=D0=B9=C2=B6=A1=A2=B8=B4=D6=C6=A1=A2=BB=F2=C9=A2=B7=A2=A3=A9=B1=BE=D3=CA=
=BC=FE=D6=D0=B5=C4=D0=C5=CF=A2=A1=A3

    =
=C8=E7=B9=FB=C4=FA=B4=ED=CA=D5=C1=CB=B1=BE=D3=CA=BC=FE=A3=AC=C7=EB=C4=FA=C1=
=A2=BC=B4=B5=E7=BB=B0=BB=F2=D3=CA=BC=FE=CD=A8=D6=AA=B7=A2=BC=FE=C8=CB=B2=A2=
=C9=BE=B3=FD=B1=BE=D3=CA=BC=FE=A3=A1
*************************************************************************=
***
***********************************


*************************************************************************=
***
***********************************
    This e-mail and its attachments contain confidential information =
from=20
HUAWEI, which is intended only for the

person or entity whose address is listed above. Any use of the =
information=20
contained herein in any way(including,

but not limited to, total or partial disclosure, reproduction, or=20
dissemination) by persons other than the intended

recipient(s) is prohibited.=20

    If you receive this e-mail in error, please notify the sender by =
phone=20
or email immediately and delete it!
*************************************************************************=
***
***********************************


=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 n6ODkJNd097527 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Jul 2009 06:46:19 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6ODkJgr097526; Fri, 24 Jul 2009 06:46:19 -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 n6ODk74G097510 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Fri, 24 Jul 2009 06:46:18 -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 n6ODk2Tr023417 for <[e-mail]>; Fri, 24 Jul 2009 09:46:02 -0400
Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n6ODk3TJ214688 for <[e-mail]>; Fri, 24 Jul 2009 09:46:07 -0400
Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n6ODhOE5013656 for <[e-mail]>; Fri, 24 Jul 2009 09:43:24 -0400
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.56.228.115]) by d01av02.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n6ODhOw8013651; Fri, 24 Jul 2009 09:43:24 -0400
In-Reply-To: <006f01ca0b30$80090150$[e-mail]>
To: Zhipeng Zhou <[e-mail]>
Cc: "'Perez, Aram'" <[e-mail]>, "'PKIX'" <[e-mail]>
MIME-Version: 1.0
Subject: RE: Welcome your kind comments on "draft-zhipeng-pkix-drm-proxy-architecture".
X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006
From: Tom Gindin <[e-mail]>
Message-ID: <[e-mail]>
Date: Fri, 24 Jul 2009 09:46:02 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 8.0.1 HF8|December 19, 2008) at 07/24/2009 09:46:02, Serialize complete at 07/24/2009 09:46:02
Content-Type: text/plain; charset="GB2312"
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>

ICAgICAgICBJIGRvbid0IHNlZSBhbnkgc2lnbmF0dXJlIGFwcGxpZWQgYnkgUHJveHkgRGV2aWNl
IEIsIHNvIHdoYXQgaXMgDQp0aGUgcG9pbnQgb2YgaXRzIGNlcnRpZmljYXRlIGluIHRoaXMgcHJv
dG9jb2w/ICBJIGFtIG5vdCBxdWVzdGlvbmluZyB0aGUgDQpmdW5jdGlvbiBvZiB0aGUgcHJveHkg
aXRzZWxmLCBqdXN0IG9mIGl0cyBjZXJ0aWZpY2F0ZS4gIElmIGRldmljZSBCJ3MgDQpyaWdodHMg
YXJlIHRvIGJlIGFkZGVkIHRvIGRldmljZSBBJ3MgYXV0aG9yaXphdGlvbiwgc2hvdWxkIGl0IG5v
dCANCmF1dGhlbnRpY2F0ZSBpdHNlbGYgYXQgc29tZSBwb2ludCwgcGVyaGFwcyB0aHJvdWdoIGEg
Y291bnRlcnNpZ25hdHVyZT8NCg0KICAgICAgICAgICAgICAgIFRvbSBHaW5kaW4NCg0KDQoNCg0K
WmhpcGVuZyBaaG91IDx6aG91enBAaHVhd2VpLmNvbT4gDQpTZW50IGJ5OiBvd25lci1pZXRmLXBr
aXhAbWFpbC5pbWMub3JnDQowNy8yMi8yMDA5IDA4OjU3IFBNDQoNClRvDQoiJ1BlcmV6LCBBcmFt
JyIgPGFyYW1wQHF1YWxjb21tLmNvbT4NCmNjDQoiJ1BLSVgnIiA8aWV0Zi1wa2l4QGltYy5vcmc+
DQpTdWJqZWN0DQpSRTogV2VsY29tZSB5b3VyIGtpbmQgY29tbWVudHMgb24gDQoiZHJhZnQtemhp
cGVuZy1wa2l4LWRybS1wcm94eS1hcmNoaXRlY3R1cmUiLg0KDQoNCg0KDQoNCg0KSGkgQXJhbSwN
Ck5pY2UgdG8gaGVhciB5b3UuDQpBcmUgeW91IGdvaW5nIHRvIFN3ZWRlbiA/DQpJZiB5b3UgY2Fu
IGhlbHAgbWUgZ2F0aGVyaW5nIG1vcmUgY29tbWVudHMgaW4gdGhlIG1lZXRpbmcsIHRoYXQgd2ls
bCBiZSANCmV4YWN0bHkgd29uZGVyZnVsIGZvciBtZS4NClRoYW5rIHlvdS4NClpoaXBlbmcNCg0K
RnJvbTogb3duZXItaWV0Zi1wa2l4QG1haWwuaW1jLm9yZyBbbWFpbHRvOm93bmVyLWlldGYtcGtp
eEBtYWlsLmltYy5vcmddIA0KT24gQmVoYWxmIE9mIFBlcmV6LCBBcmFtDQpTZW50OiBUaHVyc2Rh
eSwgSnVseSAyMywgMjAwOSAzOjUwIEFNDQpUbzogUEtJWA0KU3ViamVjdDogUmU6IFdlbGNvbWUg
eW91ciBraW5kIGNvbW1lbnRzIG9uIA0KImRyYWZ0LXpoaXBlbmctcGtpeC1kcm0tcHJveHktYXJj
aGl0ZWN0dXJlIi4NCg0KSGkgWmhpcGVuZywNCg0KSW50ZXJlc3RpbmcgZHJhZnQgUkZDLiBIZXJl
IGFyZSBhIGZldyBtaW5vciBjb21tZW50czoNCg0KobBUcnVzdHmhsSBpcyBub3QgYSB3b3JkLiBJ
IGJlbGlldmUgd2hhdCB5b3Ugd2FudCB0byBzYXkgaXMgobB0cnVzdGVkIA0KcmVsYXRpb25zaGlw
obEuIA0KSW4gc2VjdGlvbiA1LjEgeW91IGFyZSB1c2luZyB0aGUgYmluYXJ5IGZvcm1hdCBkZXNj
cmlwdGlvbiBsYW5ndWFnZSB3ZSANCmRlZmluZWQgaW4gT01BIERSTSBidXQgeW91IGhhdmUgbm90
IGV4cGxhaW5lZCBob3cgaXQgaXMgdXNlZC4NCg0KVGFrZSBjYXJlLA0KQXJhbQ0KDQoNCk9uIDcv
MjEvMDkgODoxMiBQTSwgWmhpcGVuZyBaaG91ICB3cm90ZToNCg0KU3RlZmFuIGFuZCBhbGwsDQpJ
J2QgYXNrIGlmIHRoZSBQS0lYIGd1eXMgaW4gdGhlIFN3ZWRlbiBtZWV0aW5nIGNvdWxkIGZlZWJh
Y2sgbWUgeW91ciBraW5kIA0KY29tbWVudHMgb3Igc3VnZ2VzaW9ucyBvbiBteSBkcmFmdC16aGlw
ZW5nLXBraXgtZHJtLXByb3h5LWFyY2hpdGVjdHVyZSANCjxibG9ja2VkOjoNCmh0dHA6Ly90b29s
cy5pZXRmLm9yZy9pZC9kcmFmdC16aGlwZW5nLXBraXgtZHJtLXByb3h5LWFyY2hpdGVjdHVyZS0w
MC50eHQ+IA0KIC4NClNpbmNlIHNvbWUgcmVhc29ucywgSSBjb3VsZCBub3QgYmUgaW4gdGhlIG1l
ZXRpbmcuIFdlbGNvbWUgeW91ciBlbWFpbHMgDQphbnl0aW1lLg0KVGhhbmtzIHZlcnkgbXVjaC4N
ClpoaXBlbmcNCiANCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tDQoNCkh1YXdlaSBTb2Z0d2FyZSBUZWNobm9sb2dpZXMgQ28uLEx0ZC4NCg0KRmxv
b3IgMiwgQnVpbGRpbmcgQSwgTk8uNDijrE5pbmcgTmFuIEFWLixOYW5qaW5nLCBQLlIub2YgQ2hp
bmENClppcGNvZGU6MjEwMDEyDQpFLU1haWw6IHpob3V6cEBodWF3ZWkuY29tIDxtYWlsdG86emhv
dXpwQGh1YXdlaS5jb20+IA0KUGhvbmU6KCs4NikgMjUtODIyNzY3NzENCkZheDooKzg2KSAyNS04
MjI3Njc2MA0KDQpNb2JpbGU6KCs4NikgMTM0MDQxNjI4NDkNCi0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCiANCg0KKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQqhoaGhsb7Tyrz+vLDG5Li9
vP66rNPQu6rOqrmry761xLGjw9zQxc+io6y99s/e09q3osvNuPjJz8PmtdjWt9bQwdCz9rXEuPbI
yw0Ku/LIutfpoaO9+9a5yM66zsbky/vIy9LUyM66ztDOyr3KudPDDQoNCqOosPzAqLWrsrvP3tPa
yKuyv7vysr+31rXY0LnCtqGiuLTWxqGiu/LJoreio6mxvtPKvP7W0LXE0MXPoqGjDQoNCiAgICDI
57n7xPq07crVwcuxvtPKvP6jrMfrxPrBory0tee7sLvy08q8/s2o1qq3orz+yMuyosm+s/2xvtPK
vP6joQ0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqDQoNCg0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqDQogICAgVGhpcyBlLW1haWwgYW5kIGl0cyBhdHRhY2htZW50cyBjb250YWluIGNvbmZp
ZGVudGlhbCBpbmZvcm1hdGlvbiBmcm9tIA0KSFVBV0VJLCB3aGljaCBpcyBpbnRlbmRlZCBvbmx5
IGZvciB0aGUNCg0KcGVyc29uIG9yIGVudGl0eSB3aG9zZSBhZGRyZXNzIGlzIGxpc3RlZCBhYm92
ZS4gQW55IHVzZSBvZiB0aGUgaW5mb3JtYXRpb24gDQpjb250YWluZWQgaGVyZWluIGluIGFueSB3
YXkoaW5jbHVkaW5nLA0KDQpidXQgbm90IGxpbWl0ZWQgdG8sIHRvdGFsIG9yIHBhcnRpYWwgZGlz
Y2xvc3VyZSwgcmVwcm9kdWN0aW9uLCBvciANCmRpc3NlbWluYXRpb24pIGJ5IHBlcnNvbnMgb3Ro
ZXIgdGhhbiB0aGUgaW50ZW5kZWQNCg0KcmVjaXBpZW50KHMpIGlzIHByb2hpYml0ZWQuIA0KDQog
ICAgSWYgeW91IHJlY2VpdmUgdGhpcyBlLW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhl
IHNlbmRlciBieSBwaG9uZSANCm9yIGVtYWlsIGltbWVkaWF0ZWx5IGFuZCBkZWxldGUgaXQhDQoq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCg0K
DQogDQoNCg0K



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6N0vI4j081804 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Jul 2009 17:57:18 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6N0vI8r081803; Wed, 22 Jul 2009 17:57:18 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [119.145.14.65]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6N0v68G081795 for <[e-mail]>; Wed, 22 Jul 2009 17:57:17 -0700 (MST) (envelope-from [e-mail])
Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <[e-mail]> for [e-mail]; Thu, 23 Jul 2009 08:57:05 +0800 (CST)
Received: from huawei.com ([172.24.1.33]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <[e-mail]> for [e-mail]; Thu, 23 Jul 2009 08:57:05 +0800 (CST)
Received: from z54906b ([10.168.86.61]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <[e-mail]> for [e-mail]; Thu, 23 Jul 2009 08:57:05 +0800 (CST)
Date: Thu, 23 Jul 2009 08:57:06 +0800
From: Zhipeng Zhou <[e-mail]>
Subject: RE: Welcome your kind comments on "draft-zhipeng-pkix-drm-proxy-architecture".
In-reply-to: <[e-mail]>
To: "'Perez, Aram'" <[e-mail]>
Cc: "'PKIX'" <[e-mail]>
Message-id: <006f01ca0b30$80090150$[e-mail]>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Mailer: Microsoft Office Outlook 11
Content-type: multipart/alternative; boundary="Boundary_(ID_lcf8bGtOSs255QhN1Ir/DQ)"
Thread-index: AcoKek1rw3zwBU08RGmKO1MxlcSqOAAi1RX9AApdljA=
Sender: [e-mail]
Precedence: 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.

--Boundary_(ID_lcf8bGtOSs255QhN1Ir/DQ)
Content-type: text/plain; charset=gb2312
Content-transfer-encoding: quoted-printable

Hi Aram,
Nice to hear you.
Are you going to Sweden ?
If you can help me gathering more comments in the meeting, that will be
exactly wonderful for me.
Thank you.
Zhipeng

  _____ =20

From: [e-mail] [mailto:[e-mail]] =
On
Behalf Of Perez, Aram
Sent: Thursday, July 23, 2009 3:50 AM
To: PKIX
Subject: Re: Welcome your kind comments on
"draft-zhipeng-pkix-drm-proxy-architecture".


Hi Zhipeng,

Interesting draft RFC. Here are a few minor comments:



*	=A1=B0Trusty=A1=B1 is not a word. I believe what you want to say is
=A1=B0trusted relationship=A1=B1.=20

*	In section 5.1 you are using the binary format description language
we defined in OMA DRM but you have not explained how it is used.



Take care,
Aram


On 7/21/09 8:12 PM, Zhipeng Zhou  wrote:



Stefan and all,
I'd ask if the PKIX guys in the Sweden meeting could feeback me your =
kind
comments or suggesions on my draft-zhipeng-pkix-drm-proxy-architecture
<blocked::http://tools.ietf.org/id/draft-zhipeng-pkix-drm-proxy-architect=
ure
-00.txt>  .
Since some reasons, I could not be in the meeting. Welcome your emails
anytime.
Thanks very much.
Zhipeng
=20
-----------------------------------------------------

Huawei Software Technologies Co.,Ltd.

Floor 2, Building A, NO.48=A3=ACNing Nan AV.,Nanjing, P.R.of China
Zipcode:210012
E-Mail: [e-mail] <mailto:[e-mail]>=20
Phone:[phone]
Fax:[phone]

Mobile:[phone]
-----------------------------------------------------

=20

*************************************************************************=
***
***********************************
=A1=A1=A1=A1=B1=BE=D3=CA=BC=FE=BC=B0=C6=E4=B8=BD=BC=FE=BA=AC=D3=D0=BB=AA=CE=
=AA=B9=AB=CB=BE=B5=C4=B1=A3=C3=DC=D0=C5=CF=A2=A3=AC=BD=F6=CF=DE=D3=DA=B7=A2=
=CB=CD=B8=F8=C9=CF=C3=E6=B5=D8=D6=B7=D6=D0=C1=D0=B3=F6=B5=C4=B8=F6=C8=CB=BB=
=F2
=C8=BA=D7=E9=A1=A3=BD=FB=D6=B9=C8=CE=BA=CE=C6=E4=CB=FB=C8=CB=D2=D4=C8=CE=BA=
=CE=D0=CE=CA=BD=CA=B9=D3=C3

=A3=A8=B0=FC=C0=A8=B5=AB=B2=BB=CF=DE=D3=DA=C8=AB=B2=BF=BB=F2=B2=BF=B7=D6=B5=
=D8=D0=B9=C2=B6=A1=A2=B8=B4=D6=C6=A1=A2=BB=F2=C9=A2=B7=A2=A3=A9=B1=BE=D3=CA=
=BC=FE=D6=D0=B5=C4=D0=C5=CF=A2=A1=A3

    =
=C8=E7=B9=FB=C4=FA=B4=ED=CA=D5=C1=CB=B1=BE=D3=CA=BC=FE=A3=AC=C7=EB=C4=FA=C1=
=A2=BC=B4=B5=E7=BB=B0=BB=F2=D3=CA=BC=FE=CD=A8=D6=AA=B7=A2=BC=FE=C8=CB=B2=A2=
=C9=BE=B3=FD=B1=BE=D3=CA=BC=FE=A3=A1
*************************************************************************=
***
***********************************


*************************************************************************=
***
***********************************
    This e-mail and its attachments contain confidential information =
from
HUAWEI, which is intended only for the

person or entity whose address is listed above. Any use of the =
information
contained herein in any way(including,

but not limited to, total or partial disclosure, reproduction, or
dissemination) by persons other than the intended

recipient(s) is prohibited.=20

    If you receive this e-mail in error, please notify the sender by =
phone
or email immediately and delete it!
*************************************************************************=
***
***********************************

=20




--Boundary_(ID_lcf8bGtOSs255QhN1Ir/DQ)
Content-type: text/html; charset=gb2312
Content-transfer-encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Re: Welcome your kind comments on =
"draft-zhipeng-pkix-drm-proxy-architecture".</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dgb2312">
<META content=3D"MSHTML 6.00.2900.3562" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D962024700-23072009><FONT =
color=3D#0000ff>Hi=20
Aram,</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D962024700-23072009><FONT =
color=3D#0000ff>Nice=20
to hear you.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D962024700-23072009><FONT =
color=3D#0000ff>Are=20
you going to Sweden ?</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D962024700-23072009><FONT =
color=3D#0000ff>If=20
you can help me gathering more comments in the meeting, that will be=20
exactly&nbsp;wonderful for me.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D962024700-23072009><FONT =
color=3D#0000ff>Thank=20
you.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D962024700-23072009><FONT=20
color=3D#0000ff>Zhipeng</FONT></SPAN></DIV><BR>
<DIV class=3DOutlookMessageHeader lang=3Dzh-cn dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> [e-mail]=20
[mailto:[e-mail]] <B>On Behalf Of </B>Perez,=20
Aram<BR><B>Sent:</B> Thursday, July 23, 2009 3:50 AM<BR><B>To:</B>=20
PKIX<BR><B>Subject:</B> Re: Welcome your kind comments on=20
"draft-zhipeng-pkix-drm-proxy-architecture".<BR></FONT><BR></DIV>
<DIV></DIV><FONT face=3DArial><SPAN style=3D"FONT-SIZE: 11pt">Hi=20
Zhipeng,<BR><BR>Interesting draft RFC. Here are a few minor=20
comments:<BR><BR></SPAN></FONT>
<UL>
  <LI><FONT face=3DArial><SPAN style=3D"FONT-SIZE: =
11pt">=A1=B0Trusty=A1=B1 is not a word. I=20
  believe what you want to say is =A1=B0trusted relationship=A1=B1. =
</SPAN></FONT>
  <LI><FONT face=3DArial><SPAN style=3D"FONT-SIZE: 11pt">In section 5.1 =
you are=20
  using the binary format description language we defined in OMA DRM but =
you=20
  have not explained how it is used.<BR></SPAN></FONT></LI></UL><FONT=20
face=3DArial><SPAN style=3D"FONT-SIZE: 11pt"><BR>Take =
care,<BR>Aram<BR><BR><BR>On=20
7/21/09 8:12 PM, Zhipeng Zhou &nbsp;wrote:<BR><BR></SPAN></FONT>
<BLOCKQUOTE><FONT face=3DArial><SPAN style=3D"FONT-SIZE: 11pt">Stefan =
and=20
  all,<BR>I'd ask if the PKIX guys in the Sweden meeting could feeback =
me your=20
  kind comments or suggesions on my =
draft-zhipeng-pkix-drm-proxy-architecture=20
  &lt;blocked::<A=20
  =
href=3D"http://tools.ietf.org/id/draft-zhipeng-pkix-drm-proxy-architectur=
e-00.txt">http://tools.ietf.org/id/draft-zhipeng-pkix-drm-proxy-architect=
ure-00.txt</A>&gt;=20
  &nbsp;.<BR>Since some reasons, I could not be in the meeting. Welcome =
your=20
  emails anytime.<BR>Thanks very =
much.<BR>Zhipeng<BR>&nbsp;<BR></SPAN><SPAN=20
  style=3D"FONT-SIZE: =
12pt">-----------------------------------------------------<BR><BR>Huawei=
=20
  Software Technologies Co.,Ltd.<BR><BR>Floor 2, Building A, =
NO.48=A3=ACNing Nan=20
  AV.,Nanjing, P.R.of China<BR>Zipcode:210012<BR>E-Mail: </SPAN><FONT=20
  color=3D#808080><FONT size=3D2><SPAN style=3D"FONT-SIZE: 10pt"><A=20
  =
href=3D"[e-mail]">[e-mail]</A></SPAN></FONT></FONT><SPA=
N=20
  style=3D"FONT-SIZE: 12pt"> &lt;<A=20
  href=3D"mailto:[e-mail]">mailto:[e-mail]</A>&gt;=20
  <BR>Phone:[phone]<BR>Fax:(+86) =
25-82276760<BR><BR>Mobile:(+86)=20
  =
13404162849<BR>-----------------------------------------------------<BR><=
BR>&nbsp;<BR><BR>********************************************************=
*******************************************************<BR>=A1=A1=A1=A1=B1=
=BE=D3=CA=BC=FE=BC=B0=C6=E4=B8=BD=BC=FE=BA=AC=D3=D0=BB=AA=CE=AA=B9=AB=CB=BE=
=B5=C4=B1=A3=C3=DC=D0=C5=CF=A2=A3=AC=BD=F6=CF=DE=D3=DA=B7=A2=CB=CD=B8=F8=C9=
=CF=C3=E6=B5=D8=D6=B7=D6=D0=C1=D0=B3=F6=B5=C4=B8=F6=C8=CB=BB=F2=C8=BA=D7=E9=
=A1=A3=BD=FB=D6=B9=C8=CE=BA=CE=C6=E4=CB=FB=C8=CB=D2=D4=C8=CE=BA=CE=D0=CE=CA=
=BD=CA=B9=D3=C3<BR><BR>=A3=A8=B0=FC=C0=A8=B5=AB=B2=BB=CF=DE=D3=DA=C8=AB=B2=
=BF=BB=F2=B2=BF=B7=D6=B5=D8=D0=B9=C2=B6=A1=A2=B8=B4=D6=C6=A1=A2=BB=F2=C9=A2=
=B7=A2=A3=A9=B1=BE=D3=CA=BC=FE=D6=D0=B5=C4=D0=C5=CF=A2=A1=A3<BR><BR>&nbsp=
;&nbsp;&nbsp;&nbsp;=C8=E7=B9=FB=C4=FA=B4=ED=CA=D5=C1=CB=B1=BE=D3=CA=BC=FE=
=A3=AC=C7=EB=C4=FA=C1=A2=BC=B4=B5=E7=BB=B0=BB=F2=D3=CA=BC=FE=CD=A8=D6=AA=B7=
=A2=BC=FE=C8=CB=B2=A2=C9=BE=B3=FD=B1=BE=D3=CA=BC=FE=A3=A1<BR>************=
*************************************************************************=
**************************<BR><BR><BR>***********************************=
*************************************************************************=
***<BR>&nbsp;&nbsp;&nbsp;&nbsp;This=20
  e-mail and its attachments contain confidential information from =
HUAWEI, which=20
  is intended only for the<BR><BR>person or entity whose address is =
listed=20
  above. Any use of the information contained herein in any=20
  way(including,<BR><BR>but not limited to, total or partial disclosure, =

  reproduction, or dissemination) by persons other than the=20
  intended<BR><BR>recipient(s) is prohibited. =
<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;If=20
  you receive this e-mail in error, please notify the sender by phone or =
email=20
  immediately and delete=20
  =
it!<BR>******************************************************************=
*********************************************<BR></SPAN><SPAN=20
  style=3D"FONT-SIZE: =
11pt"><BR>&nbsp;<BR><BR></SPAN></FONT></BLOCKQUOTE></BODY></HTML>

--Boundary_(ID_lcf8bGtOSs255QhN1Ir/DQ)--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6MJoUeg063124 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Jul 2009 12:50:30 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6MJoU8v063123; Wed, 22 Jul 2009 12:50:30 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6MJoJ2I063111 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Wed, 22 Jul 2009 12:50:29 -0700 (MST) (envelope-from [e-mail])
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=[e-mail]; q=dns/txt; s=qcdkim; t=1248292229; x=1279828229; h=from:to:date:subject:thread-topic:thread-index: message-id:in-reply-to:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:acceptlanguage: content-type:mime-version:x-ironport-av; z=From:=20"Perez,=20Aram"=20<[e-mail]>|To:=20PKI X=20<[e-mail]>|Date:=20Wed,=2022=20Jul=202009=20 12:50:15=20-0700|Subject:=20Re:=20Welcome=20your=20kind =20comments=20on=0D=0A=20"draft-zhipeng-pkix-drm-proxy-ar chitecture".|Thread-Topic:=20Welcome=20your=20kind=20comm ents=20on=0D=0A=20"draft-zhipeng-pkix-drm-proxy-architect ure".|Thread-Index:=20AcoKek1rw3zwBU08RGmKO1MxlcSqOAAi1RX 9|Message-ID:=20<[e-mail]> |In-Reply-To:=20<007801ca0a7a$4dd19870$[e-mail] wei.com>|Accept-Language:=20en-US|Content-Language:=20en |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20multipart/alternative=3B=0D=0A =09boundary=3D"_000_C68CBB872221Aarampqualcommcom_" |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5684"=3B=20a=3D"21079228"; bh=ry8Vh9GTtf4+bHCjbOAvO3E1UE07nPUJuh6dUOXlJpo=; b=QSINkAxVtbqYN47t4cbPyqXrgYVmkXKe1SOCVYObiBSDdBlpxxY/nZZf lbCnuEM+d34RspOuDeCIqkx3Mp6Xlgr3+T+rE7fHMgvLGhp+bW2IOUY+X vkUDbyYDUOBKZ+CmnVKmJvB5443FgAxU4AGUh2bfMdgbdz0FyKycOnhHs Q=;
X-IronPort-AV: E=McAfee;i="5300,2777,5684"; a="21079228"
Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 22 Jul 2009 12:50:18 -0700
Received: from msgtransport03.qualcomm.com (msgtransport03.qualcomm.com [129.46.61.154]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n6MJoI9i019588 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Wed, 22 Jul 2009 12:50:18 -0700
Received: from nasanexhub06.na.qualcomm.com (nasanexhub06.na.qualcomm.com [129.46.134.254]) by msgtransport03.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n6MJoI7g023291 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for <[e-mail]>; Wed, 22 Jul 2009 12:50:18 -0700
Received: from NASANEXMB05.na.qualcomm.com ([129.46.52.178]) by nasanexhub06.na.qualcomm.com ([129.46.134.254]) with mapi; Wed, 22 Jul 2009 12:50:18 -0700
From: "Perez, Aram" <[e-mail]>
To: PKIX <[e-mail]>
Date: Wed, 22 Jul 2009 12:50:15 -0700
Subject: Re: Welcome your kind comments on "draft-zhipeng-pkix-drm-proxy-architecture".
Thread-Topic: Welcome your kind comments on "draft-zhipeng-pkix-drm-proxy-architecture".
Thread-Index: AcoKek1rw3zwBU08RGmKO1MxlcSqOAAi1RX9
Message-ID: <[e-mail]>
In-Reply-To: <007801ca0a7a$4dd19870$[e-mail]>
Accept-Language: en-US
Content-Language: en
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_C68CBB872221Aarampqualcommcom_"
MIME-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--_000_C68CBB872221Aarampqualcommcom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGkgWmhpcGVuZywNCg0KSW50ZXJlc3RpbmcgZHJhZnQgUkZDLiBIZXJlIGFyZSBhIGZldyBtaW5v
ciBjb21tZW50czoNCg0KDQogKiAgIOKAnFRydXN0eeKAnSBpcyBub3QgYSB3b3JkLiBJIGJlbGll
dmUgd2hhdCB5b3Ugd2FudCB0byBzYXkgaXMg4oCcdHJ1c3RlZCByZWxhdGlvbnNoaXDigJ0uDQog
KiAgIEluIHNlY3Rpb24gNS4xIHlvdSBhcmUgdXNpbmcgdGhlIGJpbmFyeSBmb3JtYXQgZGVzY3Jp
cHRpb24gbGFuZ3VhZ2Ugd2UgZGVmaW5lZCBpbiBPTUEgRFJNIGJ1dCB5b3UgaGF2ZSBub3QgZXhw
bGFpbmVkIGhvdyBpdCBpcyB1c2VkLg0KDQpUYWtlIGNhcmUsDQpBcmFtDQoNCg0KT24gNy8yMS8w
OSA4OjEyIFBNLCBaaGlwZW5nIFpob3UgIHdyb3RlOg0KDQpTdGVmYW4gYW5kIGFsbCwNCkknZCBh
c2sgaWYgdGhlIFBLSVggZ3V5cyBpbiB0aGUgU3dlZGVuIG1lZXRpbmcgY291bGQgZmVlYmFjayBt
ZSB5b3VyIGtpbmQgY29tbWVudHMgb3Igc3VnZ2VzaW9ucyBvbiBteSBkcmFmdC16aGlwZW5nLXBr
aXgtZHJtLXByb3h5LWFyY2hpdGVjdHVyZSA8YmxvY2tlZDo6aHR0cDovL3Rvb2xzLmlldGYub3Jn
L2lkL2RyYWZ0LXpoaXBlbmctcGtpeC1kcm0tcHJveHktYXJjaGl0ZWN0dXJlLTAwLnR4dD4gIC4N
ClNpbmNlIHNvbWUgcmVhc29ucywgSSBjb3VsZCBub3QgYmUgaW4gdGhlIG1lZXRpbmcuIFdlbGNv
bWUgeW91ciBlbWFpbHMgYW55dGltZS4NClRoYW5rcyB2ZXJ5IG11Y2guDQpaaGlwZW5nDQoNCi0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCkh1
YXdlaSBTb2Z0d2FyZSBUZWNobm9sb2dpZXMgQ28uLEx0ZC4NCg0KRmxvb3IgMiwgQnVpbGRpbmcg
QSwgTk8uNDjvvIxOaW5nIE5hbiBBVi4sTmFuamluZywgUC5SLm9mIENoaW5hDQpaaXBjb2RlOjIx
MDAxMg0KRS1NYWlsOiB6aG91enBAaHVhd2VpLmNvbSA8bWFpbHRvOnpob3V6cEBodWF3ZWkuY29t
Pg0KUGhvbmU6KCs4NikgMjUtODIyNzY3NzENCkZheDooKzg2KSAyNS04MjI3Njc2MA0KDQpNb2Jp
bGU6KCs4NikgMTM0MDQxNjI4NDkNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tDQoNCg0KDQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioNCuOAgOOAgOacrOmCruS7tuWPiuWFtumZhOS7tuWQq+ac
ieWNjuS4uuWFrOWPuOeahOS/neWvhuS/oeaBr++8jOS7hemZkOS6juWPkemAgee7meS4iumdouWc
sOWdgOS4reWIl+WHuueahOS4quS6uuaIlue+pOe7hOOAguemgeatouS7u+S9leWFtuS7luS6uuS7
peS7u+S9leW9ouW8j+S9v+eUqA0KDQrvvIjljIXmi6zkvYbkuI3pmZDkuo7lhajpg6jmiJbpg6jl
iIblnLDms4TpnLLjgIHlpI3liLbjgIHmiJbmlaPlj5HvvInmnKzpgq7ku7bkuK3nmoTkv6Hmga/j
gIINCg0KICAgIOWmguaenOaCqOmUmeaUtuS6huacrOmCruS7tu+8jOivt+aCqOeri+WNs+eUteiv
neaIlumCruS7tumAmuefpeWPkeS7tuS6uuW5tuWIoOmZpOacrOmCruS7tu+8gQ0KKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQoNCg0KKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQogICAgVGhp
cyBlLW1haWwgYW5kIGl0cyBhdHRhY2htZW50cyBjb250YWluIGNvbmZpZGVudGlhbCBpbmZvcm1h
dGlvbiBmcm9tIEhVQVdFSSwgd2hpY2ggaXMgaW50ZW5kZWQgb25seSBmb3IgdGhlDQoNCnBlcnNv
biBvciBlbnRpdHkgd2hvc2UgYWRkcmVzcyBpcyBsaXN0ZWQgYWJvdmUuIEFueSB1c2Ugb2YgdGhl
IGluZm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJlaW4gaW4gYW55IHdheShpbmNsdWRpbmcsDQoNCmJ1
dCBub3QgbGltaXRlZCB0bywgdG90YWwgb3IgcGFydGlhbCBkaXNjbG9zdXJlLCByZXByb2R1Y3Rp
b24sIG9yIGRpc3NlbWluYXRpb24pIGJ5IHBlcnNvbnMgb3RoZXIgdGhhbiB0aGUgaW50ZW5kZWQN
Cg0KcmVjaXBpZW50KHMpIGlzIHByb2hpYml0ZWQuDQoNCiAgICBJZiB5b3UgcmVjZWl2ZSB0aGlz
IGUtbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGJ5IHBob25lIG9yIGVt
YWlsIGltbWVkaWF0ZWx5IGFuZCBkZWxldGUgaXQhDQoqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCg0KDQoNCg==

--_000_C68CBB872221Aarampqualcommcom_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PEhUTUw+DQo8SEVBRD4NCjxUSVRMRT5SZTogV2VsY29tZSB5b3VyIGtpbmQgY29tbWVudHMgb24g
JnF1b3Q7ZHJhZnQtemhpcGVuZy1wa2l4LWRybS1wcm94eS1hcmNoaXRlY3R1cmUmcXVvdDsuPC9U
SVRMRT4NCjwvSEVBRD4NCjxCT0RZPg0KPEZPTlQgRkFDRT0iQXJpYWwiPjxTUEFOIFNUWUxFPSdm
b250LXNpemU6MTFwdCc+SGkgWmhpcGVuZyw8QlI+DQo8QlI+DQpJbnRlcmVzdGluZyBkcmFmdCBS
RkMuIEhlcmUgYXJlIGEgZmV3IG1pbm9yIGNvbW1lbnRzOjxCUj4NCjxCUj4NCjwvU1BBTj48L0ZP
TlQ+PFVMPjxMST48Rk9OVCBGQUNFPSJBcmlhbCI+PFNQQU4gU1RZTEU9J2ZvbnQtc2l6ZToxMXB0
Jz4mIzgyMjA7VHJ1c3R5JiM4MjIxOyBpcyBub3QgYSB3b3JkLiBJIGJlbGlldmUgd2hhdCB5b3Ug
d2FudCB0byBzYXkgaXMgJiM4MjIwO3RydXN0ZWQgcmVsYXRpb25zaGlwJiM4MjIxOy4NCjwvU1BB
Tj48L0ZPTlQ+PExJPjxGT05UIEZBQ0U9IkFyaWFsIj48U1BBTiBTVFlMRT0nZm9udC1zaXplOjEx
cHQnPkluIHNlY3Rpb24gNS4xIHlvdSBhcmUgdXNpbmcgdGhlIGJpbmFyeSBmb3JtYXQgZGVzY3Jp
cHRpb24gbGFuZ3VhZ2Ugd2UgZGVmaW5lZCBpbiBPTUEgRFJNIGJ1dCB5b3UgaGF2ZSBub3QgZXhw
bGFpbmVkIGhvdyBpdCBpcyB1c2VkLjxCUj4NCjwvU1BBTj48L0ZPTlQ+PC9VTD48Rk9OVCBGQUNF
PSJBcmlhbCI+PFNQQU4gU1RZTEU9J2ZvbnQtc2l6ZToxMXB0Jz48QlI+DQpUYWtlIGNhcmUsPEJS
Pg0KQXJhbTxCUj4NCjxCUj4NCjxCUj4NCk9uIDcvMjEvMDkgODoxMiBQTSwgWmhpcGVuZyBaaG91
ICZuYnNwO3dyb3RlOjxCUj4NCjxCUj4NCjwvU1BBTj48L0ZPTlQ+PEJMT0NLUVVPVEU+PEZPTlQg
RkFDRT0iQXJpYWwiPjxTUEFOIFNUWUxFPSdmb250LXNpemU6MTFwdCc+U3RlZmFuIGFuZCBhbGws
PEJSPg0KSSdkIGFzayBpZiB0aGUgUEtJWCBndXlzIGluIHRoZSBTd2VkZW4gbWVldGluZyBjb3Vs
ZCBmZWViYWNrIG1lIHlvdXIga2luZCBjb21tZW50cyBvciBzdWdnZXNpb25zIG9uIG15IGRyYWZ0
LXpoaXBlbmctcGtpeC1kcm0tcHJveHktYXJjaGl0ZWN0dXJlICZsdDtibG9ja2VkOjo8YSBocmVm
PSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtemhpcGVuZy1wa2l4LWRybS1wcm94eS1h
cmNoaXRlY3R1cmUtMDAudHh0Ij5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtemhpcGVu
Zy1wa2l4LWRybS1wcm94eS1hcmNoaXRlY3R1cmUtMDAudHh0PC9hPiZndDsgJm5ic3A7LjxCUj4N
ClNpbmNlIHNvbWUgcmVhc29ucywgSSBjb3VsZCBub3QgYmUgaW4gdGhlIG1lZXRpbmcuIFdlbGNv
bWUgeW91ciBlbWFpbHMgYW55dGltZS48QlI+DQpUaGFua3MgdmVyeSBtdWNoLjxCUj4NClpoaXBl
bmc8QlI+DQombmJzcDs8QlI+DQo8L1NQQU4+PFNQQU4gU1RZTEU9J2ZvbnQtc2l6ZToxMnB0Jz4t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxCUj4N
CjxCUj4NCkh1YXdlaSBTb2Z0d2FyZSBUZWNobm9sb2dpZXMgQ28uLEx0ZC48QlI+DQo8QlI+DQpG
bG9vciAyLCBCdWlsZGluZyBBLCBOTy40OO+8jE5pbmcgTmFuIEFWLixOYW5qaW5nLCBQLlIub2Yg
Q2hpbmE8QlI+DQpaaXBjb2RlOjIxMDAxMjxCUj4NCkUtTWFpbDogPC9TUEFOPjxGT05UIENPTE9S
PSIjODA4MDgwIj48Rk9OVCBTSVpFPSIyIj48U1BBTiBTVFlMRT0nZm9udC1zaXplOjEwcHQnPjxh
IGhyZWY9Inpob3V6cEBodWF3ZWkuY29tIj56aG91enBAaHVhd2VpLmNvbTwvYT48L1NQQU4+PC9G
T05UPjwvRk9OVD48U1BBTiBTVFlMRT0nZm9udC1zaXplOjEycHQnPiAmbHQ7PGEgaHJlZj0ibWFp
bHRvOnpob3V6cEBodWF3ZWkuY29tIj5tYWlsdG86emhvdXpwQGh1YXdlaS5jb208L2E+Jmd0OyA8
QlI+DQpQaG9uZTooKzg2KSAyNS04MjI3Njc3MTxCUj4NCkZheDooKzg2KSAyNS04MjI3Njc2MDxC
Uj4NCjxCUj4NCk1vYmlsZTooKzg2KSAxMzQwNDE2Mjg0OTxCUj4NCi0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPEJSPg0KPEJSPg0KJm5ic3A7PEJS
Pg0KPEJSPg0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqPEJSPg0K44CA44CA5pys6YKu5Lu25Y+K5YW26ZmE5Lu25ZCr5pyJ5Y2O5Li65YWs5Y+4
55qE5L+d5a+G5L+h5oGv77yM5LuF6ZmQ5LqO5Y+R6YCB57uZ5LiK6Z2i5Zyw5Z2A5Lit5YiX5Ye6
55qE5Liq5Lq65oiW576k57uE44CC56aB5q2i5Lu75L2V5YW25LuW5Lq65Lul5Lu75L2V5b2i5byP
5L2/55SoPEJSPg0KPEJSPg0K77yI5YyF5ous5L2G5LiN6ZmQ5LqO5YWo6YOo5oiW6YOo5YiG5Zyw
5rOE6Zyy44CB5aSN5Yi244CB5oiW5pWj5Y+R77yJ5pys6YKu5Lu25Lit55qE5L+h5oGv44CCPEJS
Pg0KPEJSPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A75aaC5p6c5oKo6ZSZ5pS25LqG5pys6YKu
5Lu277yM6K+35oKo56uL5Y2z55S16K+d5oiW6YKu5Lu26YCa55+l5Y+R5Lu25Lq65bm25Yig6Zmk
5pys6YKu5Lu277yBPEJSPg0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqPEJSPg0KPEJSPg0KPEJSPg0KKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqPEJSPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7VGhpcyBlLW1haWwgYW5kIGl0cyBhdHRhY2htZW50cyBjb250YWluIGNvbmZpZGVudGlhbCBp
bmZvcm1hdGlvbiBmcm9tIEhVQVdFSSwgd2hpY2ggaXMgaW50ZW5kZWQgb25seSBmb3IgdGhlPEJS
Pg0KPEJSPg0KcGVyc29uIG9yIGVudGl0eSB3aG9zZSBhZGRyZXNzIGlzIGxpc3RlZCBhYm92ZS4g
QW55IHVzZSBvZiB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGhlcmVpbiBpbiBhbnkgd2F5KGlu
Y2x1ZGluZyw8QlI+DQo8QlI+DQpidXQgbm90IGxpbWl0ZWQgdG8sIHRvdGFsIG9yIHBhcnRpYWwg
ZGlzY2xvc3VyZSwgcmVwcm9kdWN0aW9uLCBvciBkaXNzZW1pbmF0aW9uKSBieSBwZXJzb25zIG90
aGVyIHRoYW4gdGhlIGludGVuZGVkPEJSPg0KPEJSPg0KcmVjaXBpZW50KHMpIGlzIHByb2hpYml0
ZWQuIDxCUj4NCjxCUj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO0lmIHlvdSByZWNlaXZlIHRo
aXMgZS1tYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYnkgcGhvbmUgb3Ig
ZW1haWwgaW1tZWRpYXRlbHkgYW5kIGRlbGV0ZSBpdCE8QlI+DQoqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKio8QlI+DQo8L1NQQU4+PFNQQU4gU1RZ
TEU9J2ZvbnQtc2l6ZToxMXB0Jz48QlI+DQombmJzcDs8QlI+DQo8QlI+DQo8L1NQQU4+PC9GT05U
PjwvQkxPQ0tRVU9URT4NCjwvQk9EWT4NCjwvSFRNTD4NCg0K

--_000_C68CBB872221Aarampqualcommcom_--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6MGwOuv050662 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Jul 2009 09:58:24 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6MGwORJ050661; Wed, 22 Jul 2009 09:58:24 -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 n6MGwCrH050627 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <[e-mail]>; Wed, 22 Jul 2009 09:58:22 -0700 (MST) (envelope-from [e-mail])
Received: from GALATIONS (unknown [207.202.179.27]) by smtp1.pacifier.net (Postfix) with ESMTP id 27E9F6F64C; Wed, 22 Jul 2009 09:58:11 -0700 (PDT)
From: "Jim Schaad" <[e-mail]>
To: "'Charles W. Gardiner'" <[e-mail]>
Cc: "'Stefan Santesson'" <[e-mail]>, <[e-mail]>
References: <[e-mail]> <6.2.1.2.2.20090710104636.02899208@127.0.0.1> <13da01ca02ac$1520ebf0$3f62c3d0$@com> <6.2.1.2.2.20090722101142.02802f98@127.0.0.1>
In-Reply-To: <6.2.1.2.2.20090722101142.02802f98@127.0.0.1>
Subject: RE: WGLC on draft-ietf-pkix-new-asn1-05.txt
Date: Wed, 22 Jul 2009 09:57:32 -0700
Message-ID: <00b601ca0aed$824c0ef0$86e42cd0$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Content-language: en-us
Thread-Index: AcoK27CSyzrPAHmTTF6geUou/jL1bgAEGs8g
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

See embedded comments

> -----Original Message-----
> From: Charles W. Gardiner [mailto:[e-mail]]
> Sent: Wednesday, July 22, 2009 7:49 AM
> To: Jim Schaad
> Cc: Stefan Santesson; [e-mail]
> Subject: RE: WGLC on draft-ietf-pkix-new-asn1-05.txt
> 
> At 12:49 AM 7/12/2009, Jim Schaad wrote:
> 
> >Please see the comments embedded in the message.
> 
> <snip>
> 
> 
> >We have not introduced any new looping in the PKIX 5280 ASN.1 modules.
> >These modules have long had such loops in them.  If you go to a larger
> set
> >of modules to compile you will find even worse looping may occur.  Any
> ASN.1
> >compiler must be able to deal with this looping when doing emissions
> to .h
> >files.
> 
>      Alas, I see that X68* does not prohibit looping,so I'll go along.
> 
> 
> > >
> > > 2. The ParamOptions described in AlgorithmInformation is not much
> use
> > > to a
> > > computer.  Translating the shades of necessity to numbers does not
> help
> > > either, particularly as the numbers are not in order of necessity.
> > > (What
> > > percentage of messages having parameters should be rejected if the
> > > preferredAbsent option is specified?)  Most of the options offered,
> > > namely
> > > required, absent and optional, can be achieved by choosing an
> > > appropriate
> > > form of the PARAM statement: for required, just give the TYPE; for
> > > absent,
> > > omit the PARAM statement completely; and for optional, use ARE
> OPTIONAL
> > > in
> > > the PARAM statement.  Perhaps inheritable could be dealt with by a
> > > variant
> > > of the ARE statement, or maybe that condition is implied by OPTION
> >
> >We could order the values of ParamOptions if desired, however I do not
> >actually see any benefit to doing so.  No message should be rejected
> on
> >decoding when preferredAbsent is the value (the parameters should be
> decoded
> >and used), however when messages are encoded then the parameters
> should be
> >omitted.  The presence if this value in the object definition is to
> deal
> >with the text which says "the parameters for an algorithm have the
> type
> >NULL, the parameters SHOULD be omitted, but you MUST accept the
> parameters
> >if they are present."  This is, unfortunately a very common
> construction and
> >we need to represent this so that code can be written by the user (not
> the
> >compiler) that can correctly deal with it.  Having it emitted from the
> ASN.1
> >module rather than hand extracted from the text makes this more
> consistent.
> 
>      The suggestion of accepting one thing when decoding and creating
> another when encoding sounds a little like a distinguished encoding
> rule,
> but it is not in X690.  Won't it create problems in validating
> signatures
> if one decodes a certificate and then encodes the ToBeSigned part
> (perhaps
> changing the parameters) to make a hash?  It sounds like something that
> might be a source of trouble as well as something that requires special
> treatment beyond what X68* specifies.
> 
>      While on that part of the files, I think the CERT KEY USAGE syntax
> is
> somewhat baffling, because there is no way AFAIK to express in ASN.1
> how to
> get from, say, SubjectPublicKeyInfo to the Extension for KeyUsage.  It
> looks like another case where a person might figure it out but a
> computer
> can't without some special code for just that situation.

Both of these constitute META-DATA.  As such it does not directly change how
the encoding, decoding or compiler generated validation is done.  The data
is provided in the module, in a usable form for user code, so that the code
writer does not need to search through the text of the document to find the
same data. 


In terms of how it would be used, consider how one should encode the SHA-1
hash algorithm identifier.  Depending on the document one is reading, it
says either omit the parameter or encode NULL as the parameter.  Having the
information available as part of the meta-data generated by the compiler
allows for code to determine which usage is to be done for a specific
encoding of the SHA-1 hash algorithm.  Having this data generated makes it
easier to be consistent and more correct on such usage.


> 
> 
> > >
> > > 3. The disambiguation of SignatureAlgs and PublicKeys by the use of
> the
> > > file names, e.g PKIXAlgs-2008.SignatureAlgs, seems like a
> significant
> > > extension of the language.  Other cases use the name of a
> construct, as
> > > in
> > > the definition of SingleAttribute where it says ATTRIBUTE.&Type,
> but
> > > file
> > > names only appear in IMPORT statements.  Is this use of the
> language
> > > allowed in those difficult X68* documents? It might be simpler to
> > > change
> > > the names of the ambiguous terms in one case, e.g.
> SignatureAlgsOAEP
> > > (assuming that PKIXAlgs-2008 came first).  Or maybe both should be
> > > changed.
> >
> >We looked at doing this both ways, that is using a single common name
> and
> >requiring the prefix of a module, and using distinguished names for
> each
> >module.  I finally decided that the use of a single common name makes
> it
> >clearer what the Object Set is used for and that clarity was worth
> requiring
> >that the module name (as defined in the import statement) be prefixed
> on the
> >single common name.
> >
> >Please note that the reference to a variable as module.name was
> defined as
> >an acceptable part of the language in the 1988 ASN.1 syntax, while it
> was
> >not frequently used, it has always been in the language definition.
> 
>      OK, I see it is allowed.
> 
> 
> > >
> > > 4. PKIXExplicit88 has the statement "AttributeType ::=
> ATTRIBUTE.&id".
> > > Why
> > > not simply say AttributeType ::= OBJECT IDENTIFIER"?  This is a
> minor
> > > point, but it seems to me that the present wording requires extra
> work
> > > by a
> > > computer or by a person trying to understand what is meant.  The
> > > simpler
> > > description is used in many other places, so why not this one?
> >
> >I might be willing to think about this type of change for the benefit
> of a
> >person, but not for the compiler.
> 
>      Wouldn't it help the compiler, too?

It makes absolute no difference to my compiler which way it is encoded for
some things, but for some other things it might make a difference.  The
folding of types is done differently for basic types and for types in
restrictions.  I would need to go back and do some careful reading to make
sure that it would all be kosher.   However given that this is the "normal"
way to represent the type information I would lean to leaving it as it is.

Jim


> 
> >Taking your logic one step farther it
> >would make sense to eliminate the use of AttributeType and just use
> OBJECT
> >IDENTIFIER wherever AttributeType is used.  This would make it even
> easier
> >for the person reading the module.  This is one change that could be
> made,
> >however I don't know that I see a real benefit to making the change
> 
>      Making it even easier sounds useful.
> 
> Charlie Gardiner
> 




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6MEmroX039933 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Jul 2009 07:48:53 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6MEmrQ4039932; Wed, 22 Jul 2009 07:48:53 -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 n6MEmeGQ039919 for <[e-mail]>; Wed, 22 Jul 2009 07:48:50 -0700 (MST) (envelope-from [e-mail])
Received: from dhcp89-089-178.bbn.com ([128.89.89.178] helo=gardiner-xp.bbn.com) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from <[e-mail]>) id 1MTcBS-0007KR-Du; Wed, 22 Jul 2009 09:48:38 -0400
Message-Id: <6.2.1.2.2.20090722101142.02802f98@127.0.0.1>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2
Date: Wed, 22 Jul 2009 10:48:38 -0400
To: "Jim Schaad" <[e-mail]>
From: "Charles W. Gardiner" <[e-mail]>
Subject: RE: WGLC on draft-ietf-pkix-new-asn1-05.txt
Cc: Stefan Santesson <[e-mail]>, <[e-mail]>
In-Reply-To: <13da01ca02ac$1520ebf0$3f62c3d0$@com>
References: <[e-mail]> <6.2.1.2.2.20090710104636.02899208@127.0.0.1> <13da01ca02ac$1520ebf0$3f62c3d0$@com>
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>

At 12:49 AM 7/12/2009, Jim Schaad wrote:

>Please see the comments embedded in the message.

<snip>


>We have not introduced any new looping in the PKIX 5280 ASN.1 modules.
>These modules have long had such loops in them.  If you go to a larger set
>of modules to compile you will find even worse looping may occur.  Any ASN.1
>compiler must be able to deal with this looping when doing emissions to .h
>files.

     Alas, I see that X68* does not prohibit looping,so I'll go along.


> >
> > 2. The ParamOptions described in AlgorithmInformation is not much use
> > to a
> > computer.  Translating the shades of necessity to numbers does not help
> > either, particularly as the numbers are not in order of necessity.
> > (What
> > percentage of messages having parameters should be rejected if the
> > preferredAbsent option is specified?)  Most of the options offered,
> > namely
> > required, absent and optional, can be achieved by choosing an
> > appropriate
> > form of the PARAM statement: for required, just give the TYPE; for
> > absent,
> > omit the PARAM statement completely; and for optional, use ARE OPTIONAL
> > in
> > the PARAM statement.  Perhaps inheritable could be dealt with by a
> > variant
> > of the ARE statement, or maybe that condition is implied by OPTION
>
>We could order the values of ParamOptions if desired, however I do not
>actually see any benefit to doing so.  No message should be rejected on
>decoding when preferredAbsent is the value (the parameters should be decoded
>and used), however when messages are encoded then the parameters should be
>omitted.  The presence if this value in the object definition is to deal
>with the text which says "the parameters for an algorithm have the type
>NULL, the parameters SHOULD be omitted, but you MUST accept the parameters
>if they are present."  This is, unfortunately a very common construction and
>we need to represent this so that code can be written by the user (not the
>compiler) that can correctly deal with it.  Having it emitted from the ASN.1
>module rather than hand extracted from the text makes this more consistent.

     The suggestion of accepting one thing when decoding and creating 
another when encoding sounds a little like a distinguished encoding rule, 
but it is not in X690.  Won't it create problems in validating signatures 
if one decodes a certificate and then encodes the ToBeSigned part (perhaps 
changing the parameters) to make a hash?  It sounds like something that 
might be a source of trouble as well as something that requires special 
treatment beyond what X68* specifies.

     While on that part of the files, I think the CERT KEY USAGE syntax is 
somewhat baffling, because there is no way AFAIK to express in ASN.1 how to 
get from, say, SubjectPublicKeyInfo to the Extension for KeyUsage.  It 
looks like another case where a person might figure it out but a computer 
can't without some special code for just that situation.


> >
> > 3. The disambiguation of SignatureAlgs and PublicKeys by the use of the
> > file names, e.g PKIXAlgs-2008.SignatureAlgs, seems like a significant
> > extension of the language.  Other cases use the name of a construct, as
> > in
> > the definition of SingleAttribute where it says ATTRIBUTE.&Type, but
> > file
> > names only appear in IMPORT statements.  Is this use of the language
> > allowed in those difficult X68* documents? It might be simpler to
> > change
> > the names of the ambiguous terms in one case, e.g. SignatureAlgsOAEP
> > (assuming that PKIXAlgs-2008 came first).  Or maybe both should be
> > changed.
>
>We looked at doing this both ways, that is using a single common name and
>requiring the prefix of a module, and using distinguished names for each
>module.  I finally decided that the use of a single common name makes it
>clearer what the Object Set is used for and that clarity was worth requiring
>that the module name (as defined in the import statement) be prefixed on the
>single common name.
>
>Please note that the reference to a variable as module.name was defined as
>an acceptable part of the language in the 1988 ASN.1 syntax, while it was
>not frequently used, it has always been in the language definition.

     OK, I see it is allowed.


> >
> > 4. PKIXExplicit88 has the statement "AttributeType ::= ATTRIBUTE.&id".
> > Why
> > not simply say AttributeType ::= OBJECT IDENTIFIER"?  This is a minor
> > point, but it seems to me that the present wording requires extra work
> > by a
> > computer or by a person trying to understand what is meant.  The
> > simpler
> > description is used in many other places, so why not this one?
>
>I might be willing to think about this type of change for the benefit of a
>person, but not for the compiler.

     Wouldn't it help the compiler, too?

>Taking your logic one step farther it
>would make sense to eliminate the use of AttributeType and just use OBJECT
>IDENTIFIER wherever AttributeType is used.  This would make it even easier
>for the person reading the module.  This is one change that could be made,
>however I don't know that I see a real benefit to making the change

     Making it even easier sounds useful.

Charlie Gardiner




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6M3D8r7090931 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Jul 2009 20:13:08 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6M3D80X090930; Tue, 21 Jul 2009 20:13:08 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6M3CtH1090872 for <[e-mail]>; Tue, 21 Jul 2009 20:13:06 -0700 (MST) (envelope-from [e-mail])
Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <[e-mail]> for [e-mail]; Wed, 22 Jul 2009 11:12:54 +0800 (CST)
Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <[e-mail]> for [e-mail]; Wed, 22 Jul 2009 11:12:54 +0800 (CST)
Received: from z54906b ([10.168.86.61]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <[e-mail]> for [e-mail]; Wed, 22 Jul 2009 11:12:54 +0800 (CST)
Date: Wed, 22 Jul 2009 11:12:53 +0800
From: Zhipeng Zhou <[e-mail]>
Subject: Welcome your kind comments on "draft-zhipeng-pkix-drm-proxy-architecture".
To: [e-mail]
Cc: [e-mail]
Message-id: <007801ca0a7a$4dd19870$[e-mail]>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Mailer: Microsoft Office Outlook 11
Content-type: multipart/alternative; boundary="Boundary_(ID_Y+qK7eWpt701WL1uKWqtFQ)"
Thread-index: AcoKek1rw3zwBU08RGmKO1MxlcSqOA==
Sender: [e-mail]
Precedence: 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.

--Boundary_(ID_Y+qK7eWpt701WL1uKWqtFQ)
Content-type: text/plain; charset=gb2312
Content-transfer-encoding: quoted-printable

Stefan and all,
I'd ask if the PKIX guys in the Sweden meeting could feeback me your =
kind
comments or suggesions on my draft-zhipeng-pkix-drm-proxy-architecture
<blocked::http://tools.ietf.org/id/draft-zhipeng-pkix-drm-proxy-architect=
ure
-00.txt>  .
Since some reasons, I could not be in the meeting. Welcome your emails
anytime.
Thanks very much.
Zhipeng
=20

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

Huawei Software Technologies Co.,Ltd.

Floor 2, Building A, NO.48=A3=ACNing Nan AV.,Nanjing, P.R.of China
Zipcode:210012
E-Mail:  <mailto:[e-mail]> [e-mail]
Phone:[phone]
Fax:[phone]

Mobile:[phone]
-----------------------------------------------------

=20

*************************************************************************=
***
***********************************
=A1=A1=A1=A1=B1=BE=D3=CA=BC=FE=BC=B0=C6=E4=B8=BD=BC=FE=BA=AC=D3=D0=BB=AA=CE=
=AA=B9=AB=CB=BE=B5=C4=B1=A3=C3=DC=D0=C5=CF=A2=A3=AC=BD=F6=CF=DE=D3=DA=B7=A2=
=CB=CD=B8=F8=C9=CF=C3=E6=B5=D8=D6=B7=D6=D0=C1=D0=B3=F6=B5=C4=B8=F6=C8=CB=BB=
=F2
=C8=BA=D7=E9=A1=A3=BD=FB=D6=B9=C8=CE=BA=CE=C6=E4=CB=FB=C8=CB=D2=D4=C8=CE=BA=
=CE=D0=CE=CA=BD=CA=B9=D3=C3

=A3=A8=B0=FC=C0=A8=B5=AB=B2=BB=CF=DE=D3=DA=C8=AB=B2=BF=BB=F2=B2=BF=B7=D6=B5=
=D8=D0=B9=C2=B6=A1=A2=B8=B4=D6=C6=A1=A2=BB=F2=C9=A2=B7=A2=A3=A9=B1=BE=D3=CA=
=BC=FE=D6=D0=B5=C4=D0=C5=CF=A2=A1=A3

    =
=C8=E7=B9=FB=C4=FA=B4=ED=CA=D5=C1=CB=B1=BE=D3=CA=BC=FE=A3=AC=C7=EB=C4=FA=C1=
=A2=BC=B4=B5=E7=BB=B0=BB=F2=D3=CA=BC=FE=CD=A8=D6=AA=B7=A2=BC=FE=C8=CB=B2=A2=
=C9=BE=B3=FD=B1=BE=D3=CA=BC=FE=A3=A1
*************************************************************************=
***
***********************************


*************************************************************************=
***
***********************************
    This e-mail and its attachments contain confidential information =
from
HUAWEI, which is intended only for the

person or entity whose address is listed above. Any use of the =
information
contained herein in any way(including,

but not limited to, total or partial disclosure, reproduction, or
dissemination) by persons other than the intended

recipient(s) is prohibited.=20

    If you receive this e-mail in error, please notify the sender by =
phone
or email immediately and delete it!
*************************************************************************=
***
***********************************

=20

--Boundary_(ID_Y+qK7eWpt701WL1uKWqtFQ)
Content-type: text/html; charset=gb2312
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=3Dgb2312">
<META content=3D"MSHTML 6.00.2900.3562" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D242480603-22072009><FONT face=3DArial>Stefan and=20
all,</FONT></SPAN></DIV>
<DIV><SPAN class=3D242480603-22072009><FONT face=3DArial>I'd =
ask&nbsp;if&nbsp;the=20
PKIX&nbsp;guys in the Sweden meeting could feeback me your kind comments =
or=20
suggesions on my <A=20
title=3D"blocked::http://tools.ietf.org/id/draft-zhipeng-pkix-drm-proxy-a=
rchitecture-00.txt&#10;http://tools.ietf.org/id/draft-zhipeng-pkix-drm-pr=
oxy-architecture-00.txt"=20
href=3D"blocked::http://tools.ietf.org/id/draft-zhipeng-pkix-drm-proxy-ar=
chitecture-00.txt">draft-zhipeng-pkix-drm-proxy-architecture</A><FONT=20
color=3D#000000> .</FONT></FONT></SPAN></DIV>
<DIV><SPAN class=3D242480603-22072009><FONT face=3DArial>Since some =
reasons, I could=20
not be in the meeting. Welcome your emails anytime.</FONT></SPAN></DIV>
<DIV><SPAN class=3D242480603-22072009><FONT face=3DArial>Thanks very=20
much.</FONT></SPAN></DIV>
<DIV><SPAN class=3D242480603-22072009><FONT =
face=3DArial>Zhipeng</FONT></SPAN></DIV>
<DIV>&nbsp;</DIV><?xml:namespace prefix =3D o ns =3D=20
"urn:schemas-microsoft-com:office:office" /><o:SmartTagType =
name=3D"City"=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagT=
ype><o:SmartTagType=20
name=3D"country-region"=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagT=
ype><o:SmartTagType=20
name=3D"place"=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagT=
ype>
<OBJECT id=3Dieooui =
classid=3Dclsid:38481807-CA0E-42D2-BF39-B33AF135CC4D></OBJECT>
<STYLE>
st1\:*{behavior:url(#ieooui) }
</STYLE>

<STYLE>
<!--
 /* Font Definitions */
 @font-face
	{font-family:=CB=CE=CC=E5;
	panose-1:2 1 6 0 3 1 1 1 1 1;
	mso-font-alt:SimSun;
	mso-font-charset:134;
	mso-generic-font-family:auto;
	mso-font-pitch:variable;
	mso-font-signature:3 135135232 16 0 262145 0;}
@font-face
	{font-family:"\@=CB=CE=CC=E5";
	panose-1:2 1 6 0 3 1 1 1 1 1;
	mso-font-charset:134;
	mso-generic-font-family:auto;
	mso-font-pitch:variable;
	mso-font-signature:3 135135232 16 0 262145 0;}
@font-face
	{font-family:Albertus;
	mso-font-alt:"Times New Roman";
	mso-font-charset:0;
	mso-generic-font-family:auto;
	mso-font-pitch:auto;
	mso-font-signature:0 0 0 0 0 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0cm;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:=CB=CE=CC=E5;
	mso-bidi-font-family:=CB=CE=CC=E5;}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
p.section1, li.section1, div.section1
	{mso-style-name:section1;
	mso-margin-top-alt:auto;
	margin-right:0cm;
	mso-margin-bottom-alt:auto;
	margin-left:0cm;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:=CB=CE=CC=E5;
	mso-bidi-font-family:=CB=CE=CC=E5;}
span.SpellE
	{mso-style-name:"";
	mso-spl-e:yes;}
span.GramE
	{mso-style-name:"";
	mso-gram-e:yes;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;
	mso-header-margin:42.55pt;
	mso-footer-margin:49.6pt;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
-->
</STYLE>

<DIV class=3DSection1>
<P class=3Dsection1 style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-no-proof: yes"></SPAN><SPAN=20
lang=3DEN-US>-----------------------------------------------------</SPAN>=
<SPAN=20
lang=3DEN-US=20
style=3D"FONT-SIZE: 10.5pt; COLOR: gray; FONT-FAMILY: Albertus; =
mso-bidi-font-family: Arial"><o:p></o:p></SPAN></P>
<P class=3Dsection1 style=3D"MARGIN: 0cm 0cm 0pt; LAYOUT-GRID-MODE: =
char"><SPAN=20
lang=3DEN-US>Huawei Software Technologies Co.<SPAN=20
class=3DGramE>,Ltd</SPAN>.<o:p></o:p></SPAN></P>
<P class=3Dsection1 style=3D"MARGIN: 0cm 0cm 0pt; LAYOUT-GRID-MODE: =
char"><SPAN=20
lang=3DEN-US>Floor 2, Building A, NO.48</SPAN>=A3=AC<SPAN =
class=3DSpellE><SPAN=20
lang=3DEN-US>Ning</SPAN></SPAN><SPAN lang=3DEN-US> Nan <SPAN =
class=3DSpellE>AV.<SPAN=20
class=3DGramE>,<?xml:namespace prefix =3D st1 ns =3D=20
"urn:schemas-microsoft-com:office:smarttags" /><st1:City=20
w:st=3D"on">Nanjing</st1:City>, </SPAN>P.R.of</SPAN> <st1:country-region =

w:st=3D"on"><st1:place=20
w:st=3D"on">China</st1:place></st1:country-region><BR>Zipcode:210012<BR>E=
-Mail: <A=20
title=3Dmailto:[e-mail] =
href=3D"mailto:[e-mail]"><SPAN=20
style=3D"FONT-SIZE: 10.5pt; COLOR: gray; FONT-FAMILY: Albertus; =
mso-bidi-font-family: Arial">[e-mail]</SPAN></A><BR>Phone:(+86) =

25-82276771<BR>Fax:[phone]</SPAN><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 10.5pt; COLOR: gray; FONT-FAMILY: =
Albertus"><o:p></o:p></SPAN></P>
<P class=3Dsection1 style=3D"MARGIN: 0cm 0cm 0pt; LAYOUT-GRID-MODE: =
char"><SPAN=20
class=3DGramE><SPAN lang=3DEN-US>Mobile:</SPAN></SPAN><SPAN =
lang=3DEN-US>(+86)=20
13404162849<BR>-----------------------------------------------------</SPA=
N><SPAN=20
lang=3DEN-US=20
style=3D"FONT-SIZE: 10.5pt; COLOR: gray; FONT-FAMILY: =
Albertus"><o:p></o:p></SPAN></P>
<P class=3Dsection1 style=3D"MARGIN: 0cm 0cm 0pt"><SPAN=20
lang=3DEN-US><o:p>&nbsp;</o:p></SPAN></P>
<P class=3Dsection1 style=3D"MARGIN: 0cm 0cm 0pt"><SPAN=20
lang=3DEN-US>************************************************************=
***************************************************<BR></SPAN>=A1=A1=A1=A1=
=B1=BE=D3=CA=BC=FE=BC=B0=C6=E4=B8=BD=BC=FE=BA=AC=D3=D0=BB=AA=CE=AA=B9=AB=CB=
=BE=B5=C4=B1=A3=C3=DC=D0=C5=CF=A2=A3=AC=BD=F6=CF=DE=D3=DA=B7=A2=CB=CD=B8=F8=
=C9=CF=C3=E6=B5=D8=D6=B7=D6=D0=C1=D0=B3=F6=B5=C4=B8=F6=C8=CB=BB=F2=C8=BA=D7=
=E9=A1=A3=BD=FB=D6=B9=C8=CE=BA=CE=C6=E4=CB=FB=C8=CB=D2=D4=C8=CE=BA=CE=D0=CE=
=CA=BD=CA=B9=D3=C3<SPAN=20
lang=3DEN-US style=3D"FONT-SIZE: 10pt"><o:p></o:p></SPAN></P>
<P class=3Dsection1=20
style=3D"MARGIN: 0cm 0cm =
0pt">=A3=A8=B0=FC=C0=A8=B5=AB=B2=BB=CF=DE=D3=DA=C8=AB=B2=BF=BB=F2=B2=BF=B7=
=D6=B5=D8=D0=B9=C2=B6=A1=A2=B8=B4=D6=C6=A1=A2=BB=F2=C9=A2=B7=A2=A3=A9=B1=BE=
=D3=CA=BC=FE=D6=D0=B5=C4=D0=C5=CF=A2=A1=A3<SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 10pt"><o:p></o:p></SPAN></P>
<P class=3Dsection1 style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-US><SPAN=20
style=3D"mso-tab-count: 1">&nbsp;&nbsp;&nbsp;=20
</SPAN></SPAN>=C8=E7=B9=FB=C4=FA=B4=ED=CA=D5=C1=CB=B1=BE=D3=CA=BC=FE=A3=AC=
=C7=EB=C4=FA=C1=A2=BC=B4=B5=E7=BB=B0=BB=F2=D3=CA=BC=FE=CD=A8=D6=AA=B7=A2=BC=
=FE=C8=CB=B2=A2=C9=BE=B3=FD=B1=BE=D3=CA=BC=FE=A3=A1<SPAN=20
lang=3DEN-US><BR>********************************************************=
*******************************************************</SPAN></P>
<P class=3Dsection1 style=3D"MARGIN: 0cm 0cm 0pt"><SPAN=20
lang=3DEN-US><BR>********************************************************=
*******************************************************<BR><SPAN=20
style=3D"mso-tab-count: 1">&nbsp;&nbsp;&nbsp; </SPAN>This e-mail and its =

attachments contain confidential information from HUAWEI, which is =
intended only=20
for the</SPAN><SPAN lang=3DEN-US style=3D"FONT-SIZE: =
10pt"><o:p></o:p></SPAN></P>
<P class=3Dsection1 style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-US>person or entity=20
whose address is listed above. Any use of the information contained =
herein in=20
any way(including,</SPAN><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 10pt"><o:p></o:p></SPAN></P>
<P class=3Dsection1 style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US>but =
not limited=20
to, total or partial disclosure, reproduction, or dissemination) by =
persons=20
other than the intended</SPAN><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 10pt"><o:p></o:p></SPAN></P>
<P class=3Dsection1 style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-US>recipient(s) is=20
prohibited. </SPAN><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 10pt"><o:p></o:p></SPAN></P>
<P class=3Dsection1 style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-US><SPAN=20
style=3D"mso-tab-count: 1">&nbsp;&nbsp;&nbsp; </SPAN>If you receive this =
e-mail in=20
error, please notify the sender by phone or email immediately and delete =

it!<BR>******************************************************************=
*********************************************</SPAN></P></DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

--Boundary_(ID_Y+qK7eWpt701WL1uKWqtFQ)--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6LLc3Ju070617 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Jul 2009 14:38:03 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6LLc34a070616; Tue, 21 Jul 2009 14:38:03 -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 n6LLc0So070603 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 21 Jul 2009 14:38:01 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 39792 invoked from network); 21 Jul 2009 21:38:07 -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]>; 21 Jul 2009 21:38:07 -0000
Received: (qmail 17908 invoked from network); 21 Jul 2009 21:37:59 -0000
Received: from 213-64-142-97-no153.business.telia.com (HELO [192.168.1.5]) ([e-mail]@[213.64.142.97]) (envelope-sender <[e-mail]>) by s29.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <[e-mail]>; 21 Jul 2009 21:37:59 -0000
User-Agent: Microsoft-Entourage/12.20.0.090605
Date: Tue, 21 Jul 2009 23:37:58 +0200
Subject: Re: Embedded certificate image
From: Stefan Santesson <[e-mail]>
To: Thomas Hardjono <[e-mail]>, "'ietf-pkix'" <[e-mail]>
Message-ID: <[e-mail]>
Thread-Topic: Embedded certificate image
Thread-Index: AcoJYnIl4eQPCg2qAEyVQipx4ozd7AAF+ohgAAItt8EALh6AwAAD/Z3C
In-Reply-To: <003c01ca0a3f$bd8d6c60$38a84520$@net>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3331064279_2138730"
Sender: [e-mail]
Precedence: 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_3331064279_2138730
Content-type: text/plain;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

Thomas,

We do indeed see a wave of identity federation in many areas. In many
aspects this is very healthy. We have seen huge success in the academic
world. We can further see that the European Union is betting heavily on
identity federation to solve cross border identity recognition. However, in
other aspects we are getting extremely close to truth #6 of networking (RFC
1925). It is is easier to move a problem around than it is to solve it.
(Thanks Peter Gutman for reminding me of this truth).

One aspect that is almost forgotten currently in the hype is that we need
solutions for electronic signatures and encryption and identification of
services to users, not just single sign on. Identity federation will not
solve all these cases and we may end up with parallel solutions for
different use cases. We might want to hide the technology for the users, bu=
t
we have also hidden the important result of the technology... To display th=
e
certified identity of the identified opponent.

I do agree on your conclusion, but I have more seen the cert image as a goo=
d
candidate image for an information card, but never the need to store an
information card in a certificate.

/Stefan


On 09-07-21 10:13 PM, "Thomas Hardjono" <[e-mail]> wrote:

> Hi Stefan,
> =20
> In my (limited) view of looking at where the world of identity & ID feder=
ation
> is heading, it seems that X509 certs could have a major role (depending o=
n how
> it is architected). The problem is that the complexity of X509 (perceived=
 and
> real) have really put-off people in the identity space from considering i=
t for
> direct use as an identity structure.
> =20
> So for X509 to play a role in the new identity =B3layer=B2 on the Internet, i=
t
> really should remain technology-under-the-hood that the average users sho=
uld
> never see.  In fact, I think the PKIX community should right now be think=
ing
> about (a) how X509 can complement (not replace or supplant) other emergin=
g
> identity structures, and (b) how a PKI-infrastructure could support the
> identity metasystem infrastructure that organizations are rolling-out.
> =20
> To the end of making an X.509 more human-friendly and more =B3identity
> friendly=B2, embedding an image inside a cert could be a very attractive wa=
y to
> bridge the two worlds. Given the large amounts of traffic being exchanged
> among identity metasystem infrastructure entities (think SAML stuff, and =
WS-S
> stuff over SOAP), I don=B9t the size of an X509+image cert matters any more=
 at
> the identity layer.
> =20
> /thomas/
> =20
> =20
> =20
>=20
> From: Stefan Santesson [mailto:[e-mail]]
> Sent: Monday, July 20, 2009 5:43 PM
> To: Thomas Hardjono; 'ietf-pkix'
> Subject: Re: Embedded certificate image
> =20
> Hi Thomas,
>=20
> When discussing the particular issue at hand, it has just been considered=
 in
> relation to certificate images.
> However I agree that if we would create such extension, that we should ma=
ke it
> generic.
>=20
> I think that is yet another good argument that such extension should be
> separated from the certimage work.
>=20
> What is your assessment on the actual need to store objects like an
> information card inside a certificate?
>=20
> /Stefan
>=20
>=20
> On 09-07-20 10:44 PM, "Thomas Hardjono" <[e-mail]> wrote:
> Stefan,
> =20
> Has there been any thought about making such an extension =B3generic=B2 enoug=
h
> that it could reference other human-friendly objects (e.g. InfoCard, Open=
ID
> identity, etc. etc).
> =20
> /thomas/
> =20
> =20
> =20
>=20
> From: [e-mail] [mailto:[e-mail]] =
On
> Behalf Of Stefan Santesson
> Sent: Monday, July 20, 2009 1:50 PM
> To: ietf-pkix
> Subject: Embedded certificate image
>=20
> This is the first of two unresolved issues listed in the Certimage draft.
>=20
> Is there any reason to provide any means to embed certificate images in a
> certificate.
>=20
> The reason why this might be a valid option is because we often use
> certificates in environments that have sufficient bandwidth and memory
> capacity to allow certificate images to be stored in the certificate itse=
lf.
> By storing the image in the certificate, we could save a network retrieva=
l.
>=20
> The main counter argument is that it would be a serious disadvantage if a
> certificate occasionally needs to be used in a constrained environment an=
d the
> fact that the base standard that we are updating (RFC 3709) simply does n=
ot
> allow embedded images.
>=20
> One way to do this could be to store images in a separate extension and t=
hen
> define  a way to reference that image from the logotype extension through=
 an
> internal reference.
>=20
> My proposed resolution is to exclude local storage from the current draft=
.
> Defining local embedding is adding unnecessary complexity to the draft.
>=20
> If a strong reason emerges to allow local storage, then this can be defin=
ed in
> a separate draft.
>=20
> /Stefan=20
>=20


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

<HTML>
<HEAD>
<TITLE>Re: Embedded certificate image</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt=
'>Thomas,<BR>
<BR>
We do indeed see a wave of identity federation in many areas. In many aspec=
ts this is very healthy. We have seen huge success in the academic world. We=
 can further see that the European Union is betting heavily on identity fede=
ration to solve cross border identity recognition. However, in other aspects=
 we are getting extremely close to truth #6 of networking (RFC 1925). It is =
is easier to move a problem around than it is to solve it. (Thanks Peter Gut=
man for reminding me of this truth).<BR>
<BR>
One aspect that is almost forgotten currently in the hype is that we need s=
olutions for electronic signatures and encryption and identification of serv=
ices to users, not just single sign on. Identity federation will not solve a=
ll these cases and we may end up with parallel solutions for different use c=
ases. We might want to hide the technology for the users, but we have also h=
idden the important result of the technology... To display the certified ide=
ntity of the identified opponent.<BR>
<BR>
I do agree on your conclusion, but I have more seen the cert image as a goo=
d candidate image for an information card, but never the need to store an in=
formation card in a certificate. <BR>
<BR>
/Stefan<BR>
<BR>
<BR>
On 09-07-21 10:13 PM, &quot;Thomas Hardjono&quot; &lt;<a href=3D"ietf@hardjon=
o.net">[e-mail]</a>&gt; wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><SPAN STYLE=3D'font-size:11pt'><FONT COLOR=3D"#1F497D=
"><FONT FACE=3D"Courier New">Hi Stefan,<BR>
&nbsp;<BR>
In my (limited) view of looking at where the world of identity &amp; ID fed=
eration is heading, it seems that X509 certs could have a major role (depend=
ing on how it is architected). The problem is that the complexity of X509 (p=
erceived and real) have really put-off people in the identity space from con=
sidering it for direct use as an identity structure.<BR>
&nbsp;<BR>
So for X509 to play a role in the new identity &#8220;layer&#8221; on the I=
nternet, it really should remain technology-under-the-hood that the average =
users should never see. &nbsp;In fact, I think the PKIX community should rig=
ht now be thinking about (a) how X509 can complement (not replace or supplan=
t) other emerging identity structures, and (b) how a PKI-infrastructure coul=
d support the identity metasystem infrastructure that organizations are roll=
ing-out.<BR>
&nbsp;<BR>
To the end of making an X.509 more human-friendly and more &#8220;identity =
friendly&#8221;, embedding an image inside a cert could be a very attractive=
 way to bridge the two worlds. Given the large amounts of traffic being exch=
anged among identity metasystem infrastructure entities (think SAML stuff, a=
nd WS-S stuff over SOAP), I don&#8217;t the size of an X509+image cert matte=
rs any more at the identity layer.<BR>
&nbsp;<BR>
/thomas/<BR>
&nbsp;<BR>
&nbsp;<BR>
&nbsp;<BR>
</FONT></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><BR>
</FONT></SPAN><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, July 20, 2009 5:43 PM<BR>
<B>To:</B> Thomas Hardjono; 'ietf-pkix'<BR>
<B>Subject:</B> Re: Embedded certificate image<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'>Hi Thomas,<BR>
<BR>
When discussing the particular issue at hand, it has just been considered i=
n relation to certificate images.<BR>
However I agree that if we would create such extension, that we should make=
 it generic.<BR>
<BR>
I think that is yet another good argument that such extension should be sep=
arated from the certimage work.<BR>
<BR>
What is your assessment on the actual need to store objects like an informa=
tion card inside a certificate?<BR>
<BR>
/Stefan<BR>
<BR>
<BR>
On 09-07-20 10:44 PM, &quot;Thomas Hardjono&quot; &lt;<a href=3D"ietf@hardjon=
o.net">[e-mail]</a>&gt; wrote:<BR>
</SPAN></FONT><SPAN STYLE=3D'font-size:11pt'><FONT COLOR=3D"#1F497D"><FONT FACE=
=3D"Courier New">Stefan,<BR>
&nbsp;<BR>
Has there been any thought about making such an extension &#8220;generic&#8=
221; enough that it could reference other human-friendly objects (e.g. InfoC=
ard, OpenID identity, etc. etc).<BR>
&nbsp;<BR>
/thomas/<BR>
&nbsp;<BR>
&nbsp;<BR>
&nbsp;<BR>
</FONT></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><BR>
</FONT></SPAN><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, July 20, 2009 1:50 PM<BR>
<B>To:</B> ietf-pkix<BR>
<B>Subject:</B> Embedded certificate image<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'>This is the first of two unresolved issues listed in the Cer=
timage draft.<BR>
<BR>
Is there any reason to provide any means to embed certificate images in a c=
ertificate.<BR>
<BR>
The reason why this might be a valid option is because we often use certifi=
cates in environments that have sufficient bandwidth and memory capacity to =
allow certificate images to be stored in the certificate itself. By storing =
the image in the certificate, we could save a network retrieval.<BR>
<BR>
The main counter argument is that it would be a serious disadvantage if a c=
ertificate occasionally needs to be used in a constrained environment and th=
e fact that the base standard that we are updating (RFC 3709) simply does no=
t allow embedded images.<BR>
<BR>
One way to do this could be to store images in a separate extension and the=
n define &nbsp;a way to reference that image from the logotype extension thr=
ough an internal reference.<BR>
<BR>
My proposed resolution is to exclude local storage from the current draft.<=
BR>
Defining local embedding is adding unnecessary complexity to the draft.<BR>
<BR>
If a strong reason emerges to allow local storage, then this can be defined=
 in a separate draft.<BR>
<BR>
/Stefan <BR>
<BR>
</SPAN></FONT></BLOCKQUOTE>
</BODY>
</HTML>


--B_3331064279_2138730--




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6LLNhUF069932 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Jul 2009 14:23:43 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6LLNhIl069931; Tue, 21 Jul 2009 14:23:43 -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 n6LLNWNa069919 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <[e-mail]>; Tue, 21 Jul 2009 14:23:43 -0700 (MST) (envelope-from [e-mail])
Received: from GALATIONS (unknown [207.202.179.27]) by smtp4.pacifier.net (Postfix) with ESMTP id 026B76AB5A; Tue, 21 Jul 2009 14:23:31 -0700 (PDT)
From: "Jim Schaad" <[e-mail]>
To: "'Sean Turner'" <[e-mail]>, <[e-mail]>
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: RE: WGLC on draft-ietf-pkix-new-asn1-05.txt
Date: Tue, 21 Jul 2009 14:22:56 -0700
Message-ID: <083701ca0a49$6a7abf00$3f703d00$@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: AcoEiS3dObOFYod5Tvq6VxiMNxc1wQFv1HdA
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>

The advantage of using the second option is that certificates which use the,
for PKIX, deprecated options would still decode correctly.

The disadvantage of using the second option is that a small piece of ASN.1
in the CMS world would need to be modified for some obsolete text where a
NULL was permitted in an AlgorithmParameter to say that the same EC
parameters were being used (rather than being in some way implicit).

My personal preference is the second option merely because it is the least
restrictive, but I would be willing to accept either one.

Jim



> -----Original Message-----
> From: [e-mail] [mailto:owner-ietf-
> [e-mail]] On Behalf Of Sean Turner
> Sent: Tuesday, July 14, 2009 6:38 AM
> To: [e-mail]
> Subject: Re: WGLC on draft-ietf-pkix-new-asn1-05.txt
> 
> 
> We need to align ECParameters with RFC 5480.  PKIX agreed to comment
> out
>   the specifiedCurve and namedCurve choices.  I leave the choice to you
> as to which way you'd like to fix it (though I tend to lean towards the
> 1st):
> 
> ECParameters ::= CHOICE {
>   namedCurve      CURVE.&id({NamedCurve})
>   -- implicitCurve   NULL
>   -- specifiedCurve  SpecifiedECDomain
>   -- implicitCurve and specifiedCurve MUST NOT be used in PKIX.
>   -- Details for specifiedCurve can be found in [X9.62].
>   -- Any future additions to this CHOICE should be coordinated
>   -- with ANSI X.9.
> }
> 
> or
> 
> ECParameters ::= CHOICE {
>   namedCurve      CURVE.&id({NamedCurve}),
>   implicitCurve   NULL,
>   specifiedCurve  SpecifiedECDomain
>   -- specifiedCurve MUST NOT be used in PKIX.
>   -- Details for SpecifiedECDomain can be found in [X9.62].
>   -- Any future additions to this CHOICE should be coordinated
>   -- with ANSI X.9.
> }
> WITH COMPONENTS {namedCurve PRESENT}
> 
> spt




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6LLH7HC069642 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Jul 2009 14:17:07 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6LLH7p9069641; Tue, 21 Jul 2009 14:17:07 -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 n6LLGr6L069628 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 21 Jul 2009 14:17:05 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 44835 invoked from network); 21 Jul 2009 21:17:00 -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]>; 21 Jul 2009 21:17:00 -0000
Received: (qmail 7514 invoked from network); 21 Jul 2009 21:16:51 -0000
Received: from 213-64-142-97-no153.business.telia.com (HELO [192.168.1.5]) ([e-mail]@[213.64.142.97]) (envelope-sender <[e-mail]>) by s57.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <[e-mail]>; 21 Jul 2009 21:16:51 -0000
User-Agent: Microsoft-Entourage/12.20.0.090605
Date: Tue, 21 Jul 2009 23:16:50 +0200
Subject: Re: Embedded certificate image
From: Stefan Santesson <[e-mail]>
To: Stefan Santesson <[e-mail]>, Anders Rundgren <[e-mail]>
CC: ietf-pkix <[e-mail]>
Message-ID: <[e-mail]>
Thread-Topic: Embedded certificate image
Thread-Index: AcoJ6a+BhbDwMA2b20+h06qSltpcaAAXuBOM
In-Reply-To: <[e-mail]>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3331063011_2072136"
Sender: [e-mail]
Precedence: 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_3331063011_2072136
Content-type: text/plain;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

Anders,

Thanks for the clarifications provided off-line.
I just wanted to recap here on the list.

As we have concluded there are some variants for storing a locally selected
image with the certificate for local use. That is, in a way that does
benefit the certificate holder but not the relying party.
Information Card is one such technology and the system you are working on i=
s
another.

As I think we concluded, these represent other use cases than the one the
certimage draft is addressing and IMO they are more complementary than
competing in the sense that if the issuer has provided an image, then it
will be a good candidate image for local use.

Nothing in this suggest that the certimage draft should provide a solution
for local storage of the image data.

/Stefan


On 09-07-21 11:57 AM, "Stefan Santesson" <[e-mail]> wrote:

> I=B9m sorry Anders, but totally fail to see how this has anything to do wit=
h the
> discussed issue.
>=20
> I don=B9t see any =B3competing proposal=B2
> Is there any chance you could give me a distinct short explanation in one
> sentence or two that would help me understand.
>=20
> /Stefan
>=20
>=20
>=20
> On 09-07-21 11:10 AM, "Anders Rundgren" <[e-mail]> wrote=
:
>=20
>> Stefan,
>>=20
>>> >I'm not sure what you mean by "competing" proposal
>>=20
>> If you look back a few months on my comments to the cert-image I-D
>> you'll find pointers to an entirely different proposal which is built
>> on top of a new provisioning protocol which in turn builds on a
>> revised TPM-based key storage scheme:
>> http://webpki.org/papers/keygen2/secure-key-store.pdf
>>=20
>> The "humble" goal is unifying Information Cards, PKI, and OTP because
>> they are all useful but support quite distinct use-cases.
>>=20
>> Isn't this incredibly difficult to succeed with?  Probably, but there is
>> no competition at least, since most people appear awfully busy solving
>> yesterdays' problems (like PKI middleware), ignoring higher-level aspect=
s
>> of tokens such as utility in the real world where you need to deal with
>> multiple identities and technologies.
>>=20
>> In addition, "iPhone & friends" have shown that the Mobile Internet
>> finally is here while interoperable and generally available authenticati=
on
>> solutions are not.   The described solution is also designed to fill thi=
s
>> vacuum.
>>=20
>> Anders
>>=20
>> Stefan Santesson wrote:
>>> =20
>>> Anders,
>>>=20
>>> I'm not sure what you mean by "competing" proposal, but a reasonable
>>> behavior by the client is to cache the certificate image once it has
>>> obtained it, creating the situation where the image is locally stored b=
ut
>>> not embedded.
>>>=20
>>> But you won't get away from that first retrieval.
>>>=20
>>> /Stefan
>>>=20
>>>=20
>>> On 09-07-21 8:33 AM, "Anders Rundgren" <[e-mail]>
>>> <mailto:[e-mail]>  wrote:
>>>=20
>>>  =20
>>> =20
>>>> =20
>>>> In the "competing" proposal, certificate images are locally stored
>>>> but not embedded in certificates.  This is a viable solution when
>>>> images are only to be consumed by the end-user.  For external
>>>> consumption (which I consider an entirely different use-case),
>>>> the existing I-D seems quite sufficient.
>>>>=20
>>>> Anders
>>>>=20
>>>> Stefan Santesson wrote:
>>>>    =20
>>>> =20
>>>>> =20
>>>>> This is the first of two unresolved issues listed in the Certimage dr=
aft.
>>>>>=20
>>>>> Is there any reason to provide any means to embed certificate images
>>>>> in a certificate.
>>>>>=20
>>>>> The reason why this might be a valid option is because we often use
>>>>> certificates in environments that have sufficient bandwidth and memor=
y
>>>>> capacity to allow certificate images to be stored in the certificate
>>>>> itself. By storing the image in the certificate, we could save a
>>>>> network retrieval.
>>>>>=20
>>>>> The main counter argument is that it would be a serious disadvantage
>>>>> if a certificate occasionally needs to be used in a constrained
>>>>> environment and the fact that the base standard that we are updating
>>>>> (RFC 3709) simply does not allow embedded images.
>>>>>=20
>>>>> One way to do this could be to store images in a separate extension
>>>>> and then define  a way to reference that image from the logotype
>>>>> extension through an internal reference.
>>>>>=20
>>>>> My proposed resolution is to exclude local storage from the current d=
raft.
>>>>> Defining local embedding is adding unnecessary complexity to the draf=
t.
>>>>>=20
>>>>> If a strong reason emerges to allow local storage, then this can be
>>>>> defined in a separate draft.
>>>>>=20
>>>>> /Stefan=20
>>>>>      =20
>>>>> =20
>>>> =20
>>> =20
>>>=20
>>>=20
>>>=20
>>>  =20
>>=20
>>=20
>=20


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

<HTML>
<HEAD>
<TITLE>Re: Embedded certificate image</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt=
'>Anders,<BR>
<BR>
Thanks for the clarifications provided off-line.<BR>
I just wanted to recap here on the list.<BR>
<BR>
As we have concluded there are some variants for storing a locally selected=
 image with the certificate for local use. That is, in a way that does benef=
it the certificate holder but not the relying party.<BR>
Information Card is one such technology and the system you are working on i=
s another.<BR>
<BR>
As I think we concluded, these represent other use cases than the one the c=
ertimage draft is addressing and IMO they are more complementary than compet=
ing in the sense that if the issuer has provided an image, then it will be a=
 good candidate image for local use.<BR>
<BR>
Nothing in this suggest that the certimage draft should provide a solution =
for local storage of the image data.<BR>
<BR>
/Stefan<BR>
<BR>
<BR>
On 09-07-21 11:57 AM, &quot;Stefan Santesson&quot; &lt;<a href=3D"stefan@aaa-=
sec.com">[e-mail]</a>&gt; wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><=
SPAN STYLE=3D'font-size:11pt'>I&#8217;m sorry Anders, but totally fail to see =
how this has anything to do with the discussed issue.<BR>
<BR>
I don&#8217;t see any &#8220;competing proposal&#8221;<BR>
Is there any chance you could give me a distinct short explanation in one s=
entence or two that would help me understand.<BR>
<BR>
/Stefan<BR>
<BR>
<BR>
<BR>
On 09-07-21 11:10 AM, &quot;Anders Rundgren&quot; &lt;<a href=3D"anders.rundg=
[e-mail]">[e-mail]</a>&gt; wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><=
SPAN STYLE=3D'font-size:11pt'>Stefan,<BR>
<BR>
&gt;I'm not sure what you mean by &quot;competing&quot; proposal<BR>
<BR>
If you look back a few months on my comments to the cert-image I-D<BR>
you'll find pointers to an entirely different proposal which is built<BR>
on top of a new provisioning protocol which in turn builds on a<BR>
revised TPM-based key storage scheme:<BR>
<a href=3D"http://webpki.org/papers/keygen2/secure-key-store.pdf">http://webp=
ki.org/papers/keygen2/secure-key-store.pdf</a><BR>
<BR>
The &quot;humble&quot; goal is unifying Information Cards, PKI, and OTP bec=
ause<BR>
they are all useful but support quite distinct use-cases.<BR>
<BR>
Isn't this incredibly difficult to succeed with? &nbsp;Probably, but there =
is<BR>
no competition at least, since most people appear awfully busy solving<BR>
yesterdays' problems (like PKI middleware), ignoring higher-level aspects<B=
R>
of tokens such as utility in the real world where you need to deal with<BR>
multiple identities and technologies.<BR>
<BR>
In addition, &quot;iPhone &amp; friends&quot; have shown that the Mobile In=
ternet<BR>
finally is here while interoperable and generally available authentication<=
BR>
solutions are not. &nbsp;&nbsp;The described solution is also designed to f=
ill this vacuum.<BR>
<BR>
Anders<BR>
<BR>
Stefan Santesson wrote: <BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><=
SPAN STYLE=3D'font-size:11pt'> <BR>
Anders,<BR>
<BR>
I'm not sure what you mean by &quot;competing&quot; proposal, but a reasona=
ble<BR>
behavior by the client is to cache the certificate image once it has<BR>
obtained it, creating the situation where the image is locally stored but<B=
R>
not embedded.<BR>
<BR>
But you won't get away from that first retrieval.<BR>
<BR>
/Stefan<BR>
<BR>
<BR>
On 09-07-21 8:33 AM, &quot;Anders Rundgren&quot; &lt;<a href=3D"anders.rundgr=
[e-mail]">[e-mail]</a>&gt; &lt;<a href=3D"mailto:anders.r=
[e-mail]">mailto:[e-mail]</a>&gt; &nbsp;wrote:<BR>
<BR>
&nbsp;&nbsp;<BR>
&nbsp;<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><=
SPAN STYLE=3D'font-size:11pt'> <BR>
In the &quot;competing&quot; proposal, certificate images are locally store=
d<BR>
but not embedded in certificates. &nbsp;This is a viable solution when<BR>
images are only to be consumed by the end-user. &nbsp;For external<BR>
consumption (which I consider an entirely different use-case),<BR>
the existing I-D seems quite sufficient.<BR>
<BR>
Anders<BR>
<BR>
Stefan Santesson wrote:<BR>
&nbsp;&nbsp;&nbsp;&nbsp;<BR>
&nbsp;<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><=
SPAN STYLE=3D'font-size:11pt'> <BR>
This is the first of two unresolved issues listed in the Certimage draft.<B=
R>
<BR>
Is there any reason to provide any means to embed certificate images<BR>
in a certificate.<BR>
<BR>
The reason why this might be a valid option is because we often use<BR>
certificates in environments that have sufficient bandwidth and memory<BR>
capacity to allow certificate images to be stored in the certificate<BR>
itself. By storing the image in the certificate, we could save a<BR>
network retrieval.<BR>
<BR>
The main counter argument is that it would be a serious disadvantage<BR>
if a certificate occasionally needs to be used in a constrained<BR>
environment and the fact that the base standard that we are updating<BR>
(RFC 3709) simply does not allow embedded images.<BR>
<BR>
One way to do this could be to store images in a separate extension<BR>
and then define &nbsp;a way to reference that image from the logotype<BR>
extension through an internal reference.<BR>
<BR>
My proposed resolution is to exclude local storage from the current draft.<=
BR>
Defining local embedding is adding unnecessary complexity to the draft.<BR>
<BR>
If a strong reason emerges to allow local storage, then this can be<BR>
defined in a separate draft.<BR>
<BR>
/Stefan <BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
&nbsp;<BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial">=
<SPAN STYLE=3D'font-size:11pt'> <BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial">=
<SPAN STYLE=3D'font-size:11pt'> <BR>
<BR>
<BR>
<BR>
&nbsp;&nbsp;<BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial">=
<SPAN STYLE=3D'font-size:11pt'><BR>
<BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial">=
<SPAN STYLE=3D'font-size:11pt'><BR>
</SPAN></FONT></BLOCKQUOTE>
</BODY>
</HTML>


--B_3331063011_2072136--




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6LKGJxi066652 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Jul 2009 13:16:19 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6LKGJh7066651; Tue, 21 Jul 2009 13:16:19 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from outbound-mail-26.bluehost.com (outbound-mail-26.bluehost.com [69.89.17.191]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n6LKG7Nk066613 for <[e-mail]>; Tue, 21 Jul 2009 13:16:17 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 4282 invoked by uid 0); 21 Jul 2009 20:16:06 -0000
Received: from unknown (HELO box251.bluehost.com) (69.89.31.51) by outboundproxy2.bluehost.com with SMTP; 21 Jul 2009 20:16:06 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=hardjono.net; h=Received:From:To:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=MWMXjtPXY8voVaVm8S6x54AUivDAKgNu4o9XB57bdooiGjZnHMYzvExpTKRnitQMvcfmI4RgPjVnCgWZBle3VNCd59YAje7opyGRtIU2c8NW6ZbeMP3twAY5S2BJY470;
Received: from dhcp-18-111-47-199.dyn.mit.edu ([18.111.47.199] helo=thomasvnf1ekrv) by box251.bluehost.com with esmtpa (Exim 4.69) (envelope-from <[e-mail]>) id 1MTLks-0004f3-4v; Tue, 21 Jul 2009 14:16:06 -0600
From: "Thomas Hardjono" <[e-mail]>
To: "'Stefan Santesson'" <[e-mail]>, "'ietf-pkix'" <[e-mail]>
References: <007501ca097a$d72162f0$856428d0$@net> <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: RE: Embedded certificate image
Date: Tue, 21 Jul 2009 16:13:33 -0400
Message-ID: <003c01ca0a3f$bd8d6c60$38a84520$@net>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_003D_01CA0A1E.367BCC60"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcoJYnIl4eQPCg2qAEyVQipx4ozd7AAF+ohgAAItt8EALh6AwA==
Content-Language: en-us
X-Identified-User: {727:box251.bluehost.com:hardjono:hardjono.net} {sentby:smtp auth 18.111.47.199 authed with ietf+hardjono.net}
Sender: [e-mail]
Precedence: 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_003D_01CA0A1E.367BCC60
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi Stefan,
 
In my (limited) view of looking at where the world of identity & ID
federation is heading, it seems that X509 certs could have a major role
(depending on how it is architected). The problem is that the complexity of
X509 (perceived and real) have really put-off people in the identity space
from considering it for direct use as an identity structure.
 
So for X509 to play a role in the new identity "layer" on the Internet, it
really should remain technology-under-the-hood that the average users should
never see.  In fact, I think the PKIX community should right now be thinking
about (a) how X509 can complement (not replace or supplant) other emerging
identity structures, and (b) how a PKI-infrastructure could support the
identity metasystem infrastructure that organizations are rolling-out.
 
To the end of making an X.509 more human-friendly and more "identity
friendly", embedding an image inside a cert could be a very attractive way
to bridge the two worlds. Given the large amounts of traffic being exchanged
among identity metasystem infrastructure entities (think SAML stuff, and
WS-S stuff over SOAP), I don't the size of an X509+image cert matters any
more at the identity layer.
 
/thomas/
 
 
 
From: Stefan Santesson [mailto:[e-mail]] 
Sent: Monday, July 20, 2009 5:43 PM
To: Thomas Hardjono; 'ietf-pkix'
Subject: Re: Embedded certificate image
 
Hi Thomas,

When discussing the particular issue at hand, it has just been considered in
relation to certificate images.
However I agree that if we would create such extension, that we should make
it generic.

I think that is yet another good argument that such extension should be
separated from the certimage work.

What is your assessment on the actual need to store objects like an
information card inside a certificate?

/Stefan


On 09-07-20 10:44 PM, "Thomas Hardjono" <[e-mail]> wrote:
Stefan,
 
Has there been any thought about making such an extension "generic" enough
that it could reference other human-friendly objects (e.g. InfoCard, OpenID
identity, etc. etc).
 
/thomas/
 
 
 

From: [e-mail] [mailto:[e-mail]] On
Behalf Of Stefan Santesson
Sent: Monday, July 20, 2009 1:50 PM
To: ietf-pkix
Subject: Embedded certificate image

This is the first of two unresolved issues listed in the Certimage draft.

Is there any reason to provide any means to embed certificate images in a
certificate.

The reason why this might be a valid option is because we often use
certificates in environments that have sufficient bandwidth and memory
capacity to allow certificate images to be stored in the certificate itself.
By storing the image in the certificate, we could save a network retrieval.

The main counter argument is that it would be a serious disadvantage if a
certificate occasionally needs to be used in a constrained environment and
the fact that the base standard that we are updating (RFC 3709) simply does
not allow embedded images.

One way to do this could be to store images in a separate extension and then
define  a way to reference that image from the logotype extension through an
internal reference.

My proposed resolution is to exclude local storage from the current draft.
Defining local embedding is adding unnecessary complexity to the draft.

If a strong reason emerges to allow local storage, then this can be defined
in a separate draft.

/Stefan 

------=_NextPart_000_003D_01CA0A1E.367BCC60
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=3DProgId content=3DWord.Document>
<meta name=3DGenerator content=3D"Microsoft Word 12">
<meta name=3DOriginator content=3D"Microsoft Word 12">
<link rel=3DFile-List href=3D"cid:filelist.xml@01CA0A1E.314E1D60">
<title>Re: Embedded certificate image</title>
<!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:AllowPNG/>
  <o:DoNotRelyOnCSS/>
  <o:TargetScreenSize>1024x768</o:TargetScreenSize>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:SpellingState>Clean</w:SpellingState>
  <w:TrackMoves/>
  <w:TrackFormatting/>
  <w:EnvelopeVis/>
  <w:ValidateAgainstSchemas/>
  <w:SaveIfXMLInvalid>false</w:SaveIfXMLInvalid>
  <w:IgnoreMixedContent>false</w:IgnoreMixedContent>
  <w:AlwaysShowPlaceholderText>false</w:AlwaysShowPlaceholderText>
  <w:DoNotPromoteQF/>
  <w:LidThemeOther>EN-US</w:LidThemeOther>
  <w:LidThemeAsian>X-NONE</w:LidThemeAsian>
  <w:LidThemeComplexScript>X-NONE</w:LidThemeComplexScript>
  <w:Compatibility>
   <w:DoNotExpandShiftReturn/>
   <w:BreakWrappedTables/>
   <w:SplitPgBreakAndParaMark/>
   <w:DontVertAlignCellWithSp/>
   <w:DontBreakConstrainedForcedTables/>
   <w:DontVertAlignInTxbx/>
   <w:Word11KerningPairs/>
   <w:CachedColBalance/>
  </w:Compatibility>
  <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
  <m:mathPr>
   <m:mathFont m:val=3D"Cambria Math"/>
   <m:brkBin m:val=3D"before"/>
   <m:brkBinSub m:val=3D"--"/>
   <m:smallFrac m:val=3D"off"/>
   <m:dispDef/>
   <m:lMargin m:val=3D"0"/>
   <m:rMargin m:val=3D"0"/>
   <m:defJc m:val=3D"centerGroup"/>
   <m:wrapIndent m:val=3D"1440"/>
   <m:intLim m:val=3D"subSup"/>
   <m:naryLim m:val=3D"undOvr"/>
  </m:mathPr></w:WordDocument>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:LatentStyles DefLockedState=3D"false" DefUnhideWhenUsed=3D"true"=20
  DefSemiHidden=3D"true" DefQFormat=3D"false" DefPriority=3D"99"=20
  LatentStyleCount=3D"267">
  <w:LsdException Locked=3D"false" Priority=3D"0" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Normal"/>
  <w:LsdException Locked=3D"false" Priority=3D"9" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"heading 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"9" QFormat=3D"true" =
Name=3D"heading 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"9" QFormat=3D"true" =
Name=3D"heading 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"9" QFormat=3D"true" =
Name=3D"heading 4"/>
  <w:LsdException Locked=3D"false" Priority=3D"9" QFormat=3D"true" =
Name=3D"heading 5"/>
  <w:LsdException Locked=3D"false" Priority=3D"9" QFormat=3D"true" =
Name=3D"heading 6"/>
  <w:LsdException Locked=3D"false" Priority=3D"9" QFormat=3D"true" =
Name=3D"heading 7"/>
  <w:LsdException Locked=3D"false" Priority=3D"9" QFormat=3D"true" =
Name=3D"heading 8"/>
  <w:LsdException Locked=3D"false" Priority=3D"9" QFormat=3D"true" =
Name=3D"heading 9"/>
  <w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 4"/>
  <w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 5"/>
  <w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 6"/>
  <w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 7"/>
  <w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 8"/>
  <w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 9"/>
  <w:LsdException Locked=3D"false" Priority=3D"35" QFormat=3D"true" =
Name=3D"caption"/>
  <w:LsdException Locked=3D"false" Priority=3D"10" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Title"/>
  <w:LsdException Locked=3D"false" Priority=3D"1" Name=3D"Default =
Paragraph Font"/>
  <w:LsdException Locked=3D"false" Priority=3D"11" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Subtitle"/>
  <w:LsdException Locked=3D"false" Priority=3D"22" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Strong"/>
  <w:LsdException Locked=3D"false" Priority=3D"20" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Emphasis"/>
  <w:LsdException Locked=3D"false" Priority=3D"59" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Table Grid"/>
  <w:LsdException Locked=3D"false" UnhideWhenUsed=3D"false" =
Name=3D"Placeholder Text"/>
  <w:LsdException Locked=3D"false" Priority=3D"1" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"No Spacing"/>
  <w:LsdException Locked=3D"false" Priority=3D"60" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Light Shading"/>
  <w:LsdException Locked=3D"false" Priority=3D"61" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Light List"/>
  <w:LsdException Locked=3D"false" Priority=3D"62" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Light Grid"/>
  <w:LsdException Locked=3D"false" Priority=3D"63" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Shading 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"64" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Shading 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"65" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium List 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"66" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium List 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"67" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"68" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"69" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"70" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Dark List"/>
  <w:LsdException Locked=3D"false" Priority=3D"71" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Colorful Shading"/>
  <w:LsdException Locked=3D"false" Priority=3D"72" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Colorful List"/>
  <w:LsdException Locked=3D"false" Priority=3D"73" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Colorful Grid"/>
  <w:LsdException Locked=3D"false" Priority=3D"60" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Light Shading Accent 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"61" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Light List Accent 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"62" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Light Grid Accent 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"63" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Shading 1 Accent 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"64" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Shading 2 Accent 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"65" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium List 1 Accent 1"/>
  <w:LsdException Locked=3D"false" UnhideWhenUsed=3D"false" =
Name=3D"Revision"/>
  <w:LsdException Locked=3D"false" Priority=3D"34" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"List Paragraph"/>
  <w:LsdException Locked=3D"false" Priority=3D"29" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Quote"/>
  <w:LsdException Locked=3D"false" Priority=3D"30" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Intense Quote"/>
  <w:LsdException Locked=3D"false" Priority=3D"66" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium List 2 Accent 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"67" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 1 Accent 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"68" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 2 Accent 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"69" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 3 Accent 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"70" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Dark List Accent 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"71" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Colorful Shading Accent 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"72" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Colorful List Accent 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"73" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Colorful Grid Accent 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"60" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Light Shading Accent 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"61" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Light List Accent 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"62" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Light Grid Accent 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"63" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Shading 1 Accent 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"64" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Shading 2 Accent 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"65" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium List 1 Accent 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"66" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium List 2 Accent 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"67" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 1 Accent 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"68" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 2 Accent 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"69" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 3 Accent 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"70" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Dark List Accent 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"71" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Colorful Shading Accent 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"72" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Colorful List Accent 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"73" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Colorful Grid Accent 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"60" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Light Shading Accent 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"61" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Light List Accent 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"62" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Light Grid Accent 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"63" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Shading 1 Accent 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"64" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Shading 2 Accent 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"65" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium List 1 Accent 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"66" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium List 2 Accent 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"67" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 1 Accent 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"68" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 2 Accent 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"69" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 3 Accent 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"70" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Dark List Accent 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"71" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Colorful Shading Accent 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"72" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Colorful List Accent 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"73" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Colorful Grid Accent 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"60" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Light Shading Accent 4"/>
  <w:LsdException Locked=3D"false" Priority=3D"61" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Light List Accent 4"/>
  <w:LsdException Locked=3D"false" Priority=3D"62" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Light Grid Accent 4"/>
  <w:LsdException Locked=3D"false" Priority=3D"63" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Shading 1 Accent 4"/>
  <w:LsdException Locked=3D"false" Priority=3D"64" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Shading 2 Accent 4"/>
  <w:LsdException Locked=3D"false" Priority=3D"65" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium List 1 Accent 4"/>
  <w:LsdException Locked=3D"false" Priority=3D"66" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium List 2 Accent 4"/>
  <w:LsdException Locked=3D"false" Priority=3D"67" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 1 Accent 4"/>
  <w:LsdException Locked=3D"false" Priority=3D"68" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 2 Accent 4"/>
  <w:LsdException Locked=3D"false" Priority=3D"69" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 3 Accent 4"/>
  <w:LsdException Locked=3D"false" Priority=3D"70" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Dark List Accent 4"/>
  <w:LsdException Locked=3D"false" Priority=3D"71" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Colorful Shading Accent 4"/>
  <w:LsdException Locked=3D"false" Priority=3D"72" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Colorful List Accent 4"/>
  <w:LsdException Locked=3D"false" Priority=3D"73" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Colorful Grid Accent 4"/>
  <w:LsdException Locked=3D"false" Priority=3D"60" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Light Shading Accent 5"/>
  <w:LsdException Locked=3D"false" Priority=3D"61" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Light List Accent 5"/>
  <w:LsdException Locked=3D"false" Priority=3D"62" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Light Grid Accent 5"/>
  <w:LsdException Locked=3D"false" Priority=3D"63" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Shading 1 Accent 5"/>
  <w:LsdException Locked=3D"false" Priority=3D"64" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Shading 2 Accent 5"/>
  <w:LsdException Locked=3D"false" Priority=3D"65" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium List 1 Accent 5"/>
  <w:LsdException Locked=3D"false" Priority=3D"66" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium List 2 Accent 5"/>
  <w:LsdException Locked=3D"false" Priority=3D"67" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 1 Accent 5"/>
  <w:LsdException Locked=3D"false" Priority=3D"68" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 2 Accent 5"/>
  <w:LsdException Locked=3D"false" Priority=3D"69" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 3 Accent 5"/>
  <w:LsdException Locked=3D"false" Priority=3D"70" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Dark List Accent 5"/>
  <w:LsdException Locked=3D"false" Priority=3D"71" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Colorful Shading Accent 5"/>
  <w:LsdException Locked=3D"false" Priority=3D"72" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Colorful List Accent 5"/>
  <w:LsdException Locked=3D"false" Priority=3D"73" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Colorful Grid Accent 5"/>
  <w:LsdException Locked=3D"false" Priority=3D"60" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Light Shading Accent 6"/>
  <w:LsdException Locked=3D"false" Priority=3D"61" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Light List Accent 6"/>
  <w:LsdException Locked=3D"false" Priority=3D"62" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Light Grid Accent 6"/>
  <w:LsdException Locked=3D"false" Priority=3D"63" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Shading 1 Accent 6"/>
  <w:LsdException Locked=3D"false" Priority=3D"64" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Shading 2 Accent 6"/>
  <w:LsdException Locked=3D"false" Priority=3D"65" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium List 1 Accent 6"/>
  <w:LsdException Locked=3D"false" Priority=3D"66" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium List 2 Accent 6"/>
  <w:LsdException Locked=3D"false" Priority=3D"67" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 1 Accent 6"/>
  <w:LsdException Locked=3D"false" Priority=3D"68" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 2 Accent 6"/>
  <w:LsdException Locked=3D"false" Priority=3D"69" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 3 Accent 6"/>
  <w:LsdException Locked=3D"false" Priority=3D"70" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Dark List Accent 6"/>
  <w:LsdException Locked=3D"false" Priority=3D"71" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Colorful Shading Accent 6"/>
  <w:LsdException Locked=3D"false" Priority=3D"72" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Colorful List Accent 6"/>
  <w:LsdException Locked=3D"false" Priority=3D"73" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Colorful Grid Accent 6"/>
  <w:LsdException Locked=3D"false" Priority=3D"19" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Subtle Emphasis"/>
  <w:LsdException Locked=3D"false" Priority=3D"21" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Intense Emphasis"/>
  <w:LsdException Locked=3D"false" Priority=3D"31" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Subtle Reference"/>
  <w:LsdException Locked=3D"false" Priority=3D"32" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Intense =
Reference"/>
  <w:LsdException Locked=3D"false" Priority=3D"33" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Book Title"/>
  <w:LsdException Locked=3D"false" Priority=3D"37" =
Name=3D"Bibliography"/>
  <w:LsdException Locked=3D"false" Priority=3D"39" QFormat=3D"true" =
Name=3D"TOC Heading"/>
 </w:LatentStyles>
</xml><![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;
	mso-font-charset:0;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:-1610611985 1073750139 0 0 159 0;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;
	mso-font-charset:0;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:1627400839 -2147483648 8 0 66047 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-unhide:no;
	mso-style-qformat:yes;
	mso-style-parent:"";
	margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";
	mso-fareast-font-family:Calibri;}
a:link, span.MsoHyperlink
	{mso-style-noshow:yes;
	mso-style-priority:99;
	color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-noshow:yes;
	mso-style-priority:99;
	color:purple;
	text-decoration:underline;
	text-underline:single;}
span.EmailStyle17
	{mso-style-type:personal-reply;
	mso-style-noshow:yes;
	mso-style-unhide:no;
	mso-ansi-font-size:11.0pt;
	mso-bidi-font-size:11.0pt;
	font-family:"Courier New";
	mso-ascii-font-family:"Courier New";
	mso-hansi-font-family:"Courier New";
	mso-bidi-font-family:"Times New Roman";
	color:#1F497D;}
span.SpellE
	{mso-style-name:"";
	mso-spl-e:yes;}
.MsoChpDefault
	{mso-style-type:export-only;
	mso-default-props:yes;
	font-size:10.0pt;
	mso-ansi-font-size:10.0pt;
	mso-bidi-font-size:10.0pt;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;
	mso-header-margin:.5in;
	mso-footer-margin:.5in;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 10]>
<style>
 /* Style Definitions */=20
 table.MsoNormalTable
	{mso-style-name:"Table Normal";
	mso-tstyle-rowband-size:0;
	mso-tstyle-colband-size:0;
	mso-style-noshow:yes;
	mso-style-priority:99;
	mso-style-qformat:yes;
	mso-style-parent:"";
	mso-padding-alt:0in 5.4pt 0in 5.4pt;
	mso-para-margin:0in;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Times New Roman","serif";}
</style>
<![endif]--><!--[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 =
style=3D'tab-interval:.5in'>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3D"Courier =
New"><span
style=3D'font-size:11.0pt;font-family:"Courier =
New";mso-bidi-font-family:"Times New Roman";
color:#1F497D'>Hi Stefan,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3D"Courier =
New"><span
style=3D'font-size:11.0pt;font-family:"Courier =
New";mso-bidi-font-family:"Times New Roman";
color:#1F497D'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3D"Courier =
New"><span
style=3D'font-size:11.0pt;font-family:"Courier =
New";mso-bidi-font-family:"Times New Roman";
color:#1F497D'>In my (limited) view of looking at where the world of =
identity
&amp; ID federation is heading, it seems that X509 <span =
class=3DSpellE>certs</span>
could have a major role (depending on how it is architected). The =
problem is
that the complexity of X509 (perceived and real) have really put-off =
people in
the identity space from considering it for direct use as an identity =
structure.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3D"Courier =
New"><span
style=3D'font-size:11.0pt;font-family:"Courier =
New";mso-bidi-font-family:"Times New Roman";
color:#1F497D'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3D"Courier =
New"><span
style=3D'font-size:11.0pt;font-family:"Courier =
New";mso-bidi-font-family:"Times New Roman";
color:#1F497D'>So for X509 to play a role in the new identity =
&#8220;layer&#8221;
on the Internet, it really should remain technology-under-the-hood that =
the
average users should never see.<span style=3D'mso-spacerun:yes'>&nbsp; =
</span>In
fact, I think the PKIX community should right now be thinking about (a) =
how
X509 can complement (not replace or supplant) other emerging identity =
structures,
and (b) how a PKI-infrastructure could support the identity <span =
class=3DSpellE>metasystem</span>
infrastructure that organizations are =
rolling-out.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3D"Courier =
New"><span
style=3D'font-size:11.0pt;font-family:"Courier =
New";mso-bidi-font-family:"Times New Roman";
color:#1F497D'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3D"Courier =
New"><span
style=3D'font-size:11.0pt;font-family:"Courier =
New";mso-bidi-font-family:"Times New Roman";
color:#1F497D'>To the end of making an X.509 more human-friendly and =
more &#8220;identity
friendly&#8221;, embedding an image inside a cert could be a very =
attractive
way to bridge the two worlds. Given the large amounts of traffic being
exchanged among identity <span class=3DSpellE>metasystem</span> =
infrastructure entities
(think SAML stuff, and WS-S stuff over SOAP), I don&#8217;t the size of =
an X509+image
cert matters any more at the identity =
layer.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3D"Courier =
New"><span
style=3D'font-size:11.0pt;font-family:"Courier =
New";mso-bidi-font-family:"Times New Roman";
color:#1F497D'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3D"Courier =
New"><span
style=3D'font-size:11.0pt;font-family:"Courier =
New";mso-bidi-font-family:"Times New Roman";
color:#1F497D'>/thomas/<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3D"Courier =
New"><span
style=3D'font-size:11.0pt;font-family:"Courier =
New";mso-bidi-font-family:"Times New Roman";
color:#1F497D'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3D"Courier =
New"><span
style=3D'font-size:11.0pt;font-family:"Courier =
New";mso-bidi-font-family:"Times New Roman";
color:#1F497D'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3D"Courier =
New"><span
style=3D'font-size:11.0pt;font-family:"Courier =
New";mso-bidi-font-family:"Times New Roman";
color:#1F497D'><o:p>&nbsp;</o:p></span></font></p>

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

<div>

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

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:"Tahoma","sans-serif";mso-fareast-font-family:"Times New =
Roman";
font-weight:bold'>From:</span></font></b><font size=3D2 =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif";mso-fareast-f=
ont-family:
"Times New Roman"'> Stefan Santesson [mailto:[e-mail]] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Monday, July 20, =
2009 5:43
PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Thomas Hardjono; =
'ietf-pkix'<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> Re: Embedded =
certificate
image<o:p></o:p></span></font></p>

</div>

</div>

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

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><font size=3D2 =
face=3DCalibri><span
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";mso-fareast-=
font-family:
"Times New Roman"'>Hi Thomas,<br>
<br>
When discussing the particular issue at hand, it has just been =
considered in
relation to certificate images.<br>
However I agree that if we would create such extension, that we should =
make it
generic.<br>
<br>
I think that is yet another good argument that such extension should be
separated from the certimage work.<br>
<br>
What is your assessment on the actual need to store objects like an =
information
card inside a certificate?<br>
<br>
/Stefan<br>
<br>
<br>
On 09-07-20 10:44 PM, &quot;Thomas Hardjono&quot; &lt;<a
href=3D"[e-mail]">[e-mail]</a>&gt; =
wrote:</span></font><span
style=3D'mso-fareast-font-family:"Times New =
Roman"'><o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><font size=3D2 =
color=3D"#1f497d"
face=3D"Courier New"><span =
style=3D'font-size:11.0pt;font-family:"Courier New";
mso-fareast-font-family:"Times New Roman";color:#1F497D'>Stefan,<br>
&nbsp;<br>
Has there been any thought about making such an extension =
&#8220;generic&#8221;
enough that it could reference other human-friendly objects (e.g. =
InfoCard,
OpenID identity, etc. etc).<br>
&nbsp;<br>
/thomas/<br>
&nbsp;<br>
&nbsp;<br>
&nbsp;<br>
</span></font><font size=3D2 face=3DCalibri><span =
style=3D'font-size:11.0pt;
font-family:"Calibri","sans-serif";mso-fareast-font-family:"Times New =
Roman"'><br>
</span></font><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:"Tahoma","sans-serif";mso-fareast-font-family:"Times New =
Roman";
font-weight:bold'>From:</span></font></b><font size=3D2 =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif";mso-fareast-f=
ont-family:
"Times New Roman"'> <a =
href=3D"[e-mail]">[e-mail]</a>
[<a =
href=3D"mailto:[e-mail]">mailto:owner-ietf-pkix@mail.=
imc.org</a>]
<b><span style=3D'font-weight:bold'>On Behalf Of </span></b>Stefan =
Santesson<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Monday, July 20, =
2009 1:50
PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> ietf-pkix<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> Embedded =
certificate
image<br>
</span></font><span style=3D'mso-fareast-font-family:"Times New =
Roman"'><br>
</span><font size=3D2 face=3DCalibri><span =
style=3D'font-size:11.0pt;font-family:
"Calibri","sans-serif";mso-fareast-font-family:"Times New Roman"'>This =
is the
first of two unresolved issues listed in the Certimage draft.<br>
<br>
Is there any reason to provide any means to embed certificate images in =
a
certificate.<br>
<br>
The reason why this might be a valid option is because we often use =
certificates
in environments that have sufficient bandwidth and memory capacity to =
allow
certificate images to be stored in the certificate itself. By storing =
the image
in the certificate, we could save a network retrieval.<br>
<br>
The main counter argument is that it would be a serious disadvantage if =
a
certificate occasionally needs to be used in a constrained environment =
and the
fact that the base standard that we are updating (RFC 3709) simply does =
not
allow embedded images.<br>
<br>
One way to do this could be to store images in a separate extension and =
then
define &nbsp;a way to reference that image from the logotype extension =
through
an internal reference.<br>
<br>
My proposed resolution is to exclude local storage from the current =
draft.<br>
Defining local embedding is adding unnecessary complexity to the =
draft.<br>
<br>
If a strong reason emerges to allow local storage, then this can be =
defined in
a separate draft.<br>
<br>
/Stefan </span></font><span style=3D'mso-fareast-font-family:"Times New =
Roman"'><o:p></o:p></span></p>

</div>

</div>

</body>

</html>

------=_NextPart_000_003D_01CA0A1E.367BCC60--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6L9w1mg017621 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Jul 2009 02:58:01 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6L9w1Sg017620; Tue, 21 Jul 2009 02:58: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 n6L9vmmm017604 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 21 Jul 2009 02:57:59 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 17253 invoked from network); 21 Jul 2009 09:57:49 -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]>; 21 Jul 2009 09:57:49 -0000
Received: (qmail 51344 invoked from network); 21 Jul 2009 09:57:46 -0000
Received: from 213-64-142-97-no153.business.telia.com (HELO [192.168.1.5]) ([e-mail]@[213.64.142.97]) (envelope-sender <[e-mail]>) by s42.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <[e-mail]>; 21 Jul 2009 09:57:46 -0000
User-Agent: Microsoft-Entourage/12.19.0.090515
Date: Tue, 21 Jul 2009 11:57:41 +0200
Subject: Re: Embedded certificate image
From: Stefan Santesson <[e-mail]>
To: Anders Rundgren <[e-mail]>
CC: ietf-pkix <[e-mail]>
Message-ID: <[e-mail]>
Thread-Topic: Embedded certificate image
Thread-Index: AcoJ6a+BhbDwMA2b20+h06qSltpcaA==
In-Reply-To: <[e-mail]>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3331022266_5038418"
Sender: [e-mail]
Precedence: 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_3331022266_5038418
Content-type: text/plain;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

I=B9m sorry Anders, but totally fail to see how this has anything to do with
the discussed issue.

I don=B9t see any =B3competing proposal=B2
Is there any chance you could give me a distinct short explanation in one
sentence or two that would help me understand.

/Stefan



On 09-07-21 11:10 AM, "Anders Rundgren" <[e-mail]> wrote:

> Stefan,
>=20
>> >I'm not sure what you mean by "competing" proposal
>=20
> If you look back a few months on my comments to the cert-image I-D
> you'll find pointers to an entirely different proposal which is built
> on top of a new provisioning protocol which in turn builds on a
> revised TPM-based key storage scheme:
> http://webpki.org/papers/keygen2/secure-key-store.pdf
>=20
> The "humble" goal is unifying Information Cards, PKI, and OTP because
> they are all useful but support quite distinct use-cases.
>=20
> Isn't this incredibly difficult to succeed with?  Probably, but there is
> no competition at least, since most people appear awfully busy solving
> yesterdays' problems (like PKI middleware), ignoring higher-level aspects
> of tokens such as utility in the real world where you need to deal with
> multiple identities and technologies.
>=20
> In addition, "iPhone & friends" have shown that the Mobile Internet
> finally is here while interoperable and generally available authenticatio=
n
> solutions are not.   The described solution is also designed to fill this
> vacuum.
>=20
> Anders
>=20
> Stefan Santesson wrote:
>> =20
>> Anders,
>>=20
>> I'm not sure what you mean by "competing" proposal, but a reasonable
>> behavior by the client is to cache the certificate image once it has
>> obtained it, creating the situation where the image is locally stored bu=
t
>> not embedded.
>>=20
>> But you won't get away from that first retrieval.
>>=20
>> /Stefan
>>=20
>>=20
>> On 09-07-21 8:33 AM, "Anders Rundgren" <[e-mail]>
>> <mailto:[e-mail]>  wrote:
>>=20
>>  =20
>> =20
>>> =20
>>> In the "competing" proposal, certificate images are locally stored
>>> but not embedded in certificates.  This is a viable solution when
>>> images are only to be consumed by the end-user.  For external
>>> consumption (which I consider an entirely different use-case),
>>> the existing I-D seems quite sufficient.
>>>=20
>>> Anders
>>>=20
>>> Stefan Santesson wrote:
>>>    =20
>>> =20
>>>> =20
>>>> This is the first of two unresolved issues listed in the Certimage dra=
ft.
>>>>=20
>>>> Is there any reason to provide any means to embed certificate images
>>>> in a certificate.
>>>>=20
>>>> The reason why this might be a valid option is because we often use
>>>> certificates in environments that have sufficient bandwidth and memory
>>>> capacity to allow certificate images to be stored in the certificate
>>>> itself. By storing the image in the certificate, we could save a
>>>> network retrieval.
>>>>=20
>>>> The main counter argument is that it would be a serious disadvantage
>>>> if a certificate occasionally needs to be used in a constrained
>>>> environment and the fact that the base standard that we are updating
>>>> (RFC 3709) simply does not allow embedded images.
>>>>=20
>>>> One way to do this could be to store images in a separate extension
>>>> and then define  a way to reference that image from the logotype
>>>> extension through an internal reference.
>>>>=20
>>>> My proposed resolution is to exclude local storage from the current dr=
aft.
>>>> Defining local embedding is adding unnecessary complexity to the draft=
.
>>>>=20
>>>> If a strong reason emerges to allow local storage, then this can be
>>>> defined in a separate draft.
>>>>=20
>>>> /Stefan=20
>>>>      =20
>>>> =20
>>> =20
>> =20
>>=20
>>=20
>>=20
>>  =20
>=20
>=20


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

<HTML>
<HEAD>
<TITLE>Re: Embedded certificate image</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt=
'>I&#8217;m sorry Anders, but totally fail to see how this has anything to d=
o with the discussed issue.<BR>
<BR>
I don&#8217;t see any &#8220;competing proposal&#8221;<BR>
Is there any chance you could give me a distinct short explanation in one s=
entence or two that would help me understand.<BR>
<BR>
/Stefan<BR>
<BR>
<BR>
<BR>
On 09-07-21 11:10 AM, &quot;Anders Rundgren&quot; &lt;<a href=3D"anders.rundg=
[e-mail]">[e-mail]</a>&gt; wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><=
SPAN STYLE=3D'font-size:11pt'>Stefan,<BR>
<BR>
&gt;I'm not sure what you mean by &quot;competing&quot; proposal<BR>
<BR>
If you look back a few months on my comments to the cert-image I-D<BR>
you'll find pointers to an entirely different proposal which is built<BR>
on top of a new provisioning protocol which in turn builds on a<BR>
revised TPM-based key storage scheme:<BR>
<a href=3D"http://webpki.org/papers/keygen2/secure-key-store.pdf">http://webp=
ki.org/papers/keygen2/secure-key-store.pdf</a><BR>
<BR>
The &quot;humble&quot; goal is unifying Information Cards, PKI, and OTP bec=
ause<BR>
they are all useful but support quite distinct use-cases.<BR>
<BR>
Isn't this incredibly difficult to succeed with? &nbsp;Probably, but there =
is<BR>
no competition at least, since most people appear awfully busy solving<BR>
yesterdays' problems (like PKI middleware), ignoring higher-level aspects<B=
R>
of tokens such as utility in the real world where you need to deal with<BR>
multiple identities and technologies.<BR>
<BR>
In addition, &quot;iPhone &amp; friends&quot; have shown that the Mobile In=
ternet<BR>
finally is here while interoperable and generally available authentication<=
BR>
solutions are not. &nbsp;&nbsp;The described solution is also designed to f=
ill this vacuum.<BR>
<BR>
Anders<BR>
<BR>
Stefan Santesson wrote: <BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><=
SPAN STYLE=3D'font-size:11pt'> <BR>
Anders,<BR>
<BR>
I'm not sure what you mean by &quot;competing&quot; proposal, but a reasona=
ble<BR>
behavior by the client is to cache the certificate image once it has<BR>
obtained it, creating the situation where the image is locally stored but<B=
R>
not embedded.<BR>
<BR>
But you won't get away from that first retrieval.<BR>
<BR>
/Stefan<BR>
<BR>
<BR>
On 09-07-21 8:33 AM, &quot;Anders Rundgren&quot; &lt;<a href=3D"anders.rundgr=
[e-mail]">[e-mail]</a>&gt; &lt;<a href=3D"mailto:anders.r=
[e-mail]">mailto:[e-mail]</a>&gt; &nbsp;wrote:<BR>
<BR>
&nbsp;&nbsp;<BR>
&nbsp;<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><=
SPAN STYLE=3D'font-size:11pt'> <BR>
In the &quot;competing&quot; proposal, certificate images are locally store=
d<BR>
but not embedded in certificates. &nbsp;This is a viable solution when<BR>
images are only to be consumed by the end-user. &nbsp;For external<BR>
consumption (which I consider an entirely different use-case),<BR>
the existing I-D seems quite sufficient.<BR>
<BR>
Anders<BR>
<BR>
Stefan Santesson wrote:<BR>
&nbsp;&nbsp;&nbsp;&nbsp;<BR>
&nbsp;<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><=
SPAN STYLE=3D'font-size:11pt'> <BR>
This is the first of two unresolved issues listed in the Certimage draft.<B=
R>
<BR>
Is there any reason to provide any means to embed certificate images<BR>
in a certificate.<BR>
<BR>
The reason why this might be a valid option is because we often use<BR>
certificates in environments that have sufficient bandwidth and memory<BR>
capacity to allow certificate images to be stored in the certificate<BR>
itself. By storing the image in the certificate, we could save a<BR>
network retrieval.<BR>
<BR>
The main counter argument is that it would be a serious disadvantage<BR>
if a certificate occasionally needs to be used in a constrained<BR>
environment and the fact that the base standard that we are updating<BR>
(RFC 3709) simply does not allow embedded images.<BR>
<BR>
One way to do this could be to store images in a separate extension<BR>
and then define &nbsp;a way to reference that image from the logotype<BR>
extension through an internal reference.<BR>
<BR>
My proposed resolution is to exclude local storage from the current draft.<=
BR>
Defining local embedding is adding unnecessary complexity to the draft.<BR>
<BR>
If a strong reason emerges to allow local storage, then this can be<BR>
defined in a separate draft.<BR>
<BR>
/Stefan <BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
&nbsp;<BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial">=
<SPAN STYLE=3D'font-size:11pt'> <BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial">=
<SPAN STYLE=3D'font-size:11pt'> <BR>
<BR>
<BR>
<BR>
&nbsp;&nbsp;<BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial">=
<SPAN STYLE=3D'font-size:11pt'><BR>
<BR>
</SPAN></FONT></BLOCKQUOTE>
</BODY>
</HTML>


--B_3331022266_5038418--




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6L9AnrT013775 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Jul 2009 02:10:49 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6L9AnZ8013774; Tue, 21 Jul 2009 02:10:49 -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 n6L9AkDt013768 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 21 Jul 2009 02:10:48 -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 3E43D1001B; Tue, 21 Jul 2009 11:10:45 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Tue, 21 Jul 2009 11:10:44 +0200
From: Anders Rundgren <[e-mail]>
User-Agent: Thunderbird 2.0.0.21 (X11/20090318)
MIME-Version: 1.0
To: Stefan Santesson <[e-mail]>
CC: ietf-pkix <[e-mail]>
Subject: Re: Embedded certificate image
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/alternative; boundary="------------030507010909040806050708"
Sender: [e-mail]
Precedence: 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.
--------------030507010909040806050708
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Stefan,

 >I'm not sure what you mean by "competing" proposal

If you look back a few months on my comments to the cert-image I-D
you'll find pointers to an entirely different proposal which is built
on top of a new provisioning protocol which in turn builds on a
revised TPM-based key storage scheme:
http://webpki.org/papers/keygen2/secure-key-store.pdf

The "humble" goal is unifying Information Cards, PKI, and OTP because
they are all useful but support quite distinct use-cases.

Isn't this incredibly difficult to succeed with?  Probably, but there is
no competition at least, since most people appear awfully busy solving
yesterdays' problems (like PKI middleware), ignoring higher-level aspects
of tokens such as utility in the real world where you need to deal with
multiple identities and technologies.

In addition, "iPhone & friends" have shown that the Mobile Internet
finally is here while interoperable and generally available authentication
solutions are not.   The described solution is also designed to fill 
this vacuum.

Anders

Stefan Santesson wrote:
> Anders,
>
> I'm not sure what you mean by "competing" proposal, but a reasonable
> behavior by the client is to cache the certificate image once it has
> obtained it, creating the situation where the image is locally stored but
> not embedded.
>
> But you won't get away from that first retrieval.
>
> /Stefan
>
>
> On 09-07-21 8:33 AM, "Anders Rundgren" <[e-mail]> wrote:
>
>   
>> In the "competing" proposal, certificate images are locally stored
>> but not embedded in certificates.  This is a viable solution when
>> images are only to be consumed by the end-user.  For external
>> consumption (which I consider an entirely different use-case),
>> the existing I-D seems quite sufficient.
>>
>> Anders
>>
>> Stefan Santesson wrote:
>>     
>>> This is the first of two unresolved issues listed in the Certimage draft.
>>>
>>> Is there any reason to provide any means to embed certificate images
>>> in a certificate.
>>>
>>> The reason why this might be a valid option is because we often use
>>> certificates in environments that have sufficient bandwidth and memory
>>> capacity to allow certificate images to be stored in the certificate
>>> itself. By storing the image in the certificate, we could save a
>>> network retrieval.
>>>
>>> The main counter argument is that it would be a serious disadvantage
>>> if a certificate occasionally needs to be used in a constrained
>>> environment and the fact that the base standard that we are updating
>>> (RFC 3709) simply does not allow embedded images.
>>>
>>> One way to do this could be to store images in a separate extension
>>> and then define  a way to reference that image from the logotype
>>> extension through an internal reference.
>>>
>>> My proposed resolution is to exclude local storage from the current draft.
>>> Defining local embedding is adding unnecessary complexity to the draft.
>>>
>>> If a strong reason emerges to allow local storage, then this can be
>>> defined in a separate draft.
>>>
>>> /Stefan 
>>>       
>
>
>
>   


--------------030507010909040806050708
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Stefan,<br>
<br>
&gt;I'm not sure what you mean by "competing" proposal<br>
<br>
If you look back a few months on my comments to the cert-image I-D<br>
you'll find pointers to an entirely different proposal which is built<br>
on top of a new provisioning protocol which in turn builds on a<br>
revised TPM-based key storage scheme:<br>
<a class="moz-txt-link-freetext"
 href="http://webpki.org/papers/keygen2/secure-key-store.pdf">http://webpki.org/papers/keygen2/secure-key-store.pdf</a><br>
<br>
The "humble" goal is unifying Information Cards, PKI, and OTP because<br>
they are all useful but support quite distinct use-cases.<br>
<br>
Isn't this incredibly difficult to succeed with?&nbsp; Probably, but there is<br>
no competition at least, since most people appear awfully busy solving<br>
yesterdays' problems (like PKI middleware), ignoring higher-level
aspects<br>
of tokens such as utility in the real world where you need to deal with<br>
multiple identities and technologies.<br>
<br>
In addition, "iPhone &amp; friends" have shown that the Mobile Internet<br>
finally is here while interoperable and generally available
authentication<br>
solutions are not. &nbsp; The described solution is also designed to fill
this vacuum.<br>
<br>
Anders<br>
<br>
Stefan Santesson wrote:
<blockquote cite="mid:[e-mail]" type="cite">
  <pre wrap="">Anders,

I'm not sure what you mean by "competing" proposal, but a reasonable
behavior by the client is to cache the certificate image once it has
obtained it, creating the situation where the image is locally stored but
not embedded.

But you won't get away from that first retrieval.

/Stefan


On 09-07-21 8:33 AM, "Anders Rundgren" <a class="moz-txt-link-rfc2396E"
 href="mailto:[e-mail]">&lt;[e-mail]&gt;</a> wrote:

  </pre>
  <blockquote type="cite">
    <pre wrap="">In the "competing" proposal, certificate images are locally stored
but not embedded in certificates.  This is a viable solution when
images are only to be consumed by the end-user.  For external
consumption (which I consider an entirely different use-case),
the existing I-D seems quite sufficient.

Anders

Stefan Santesson wrote:
    </pre>
    <blockquote type="cite">
      <pre wrap="">This is the first of two unresolved issues listed in the Certimage draft.

Is there any reason to provide any means to embed certificate images
in a certificate.

The reason why this might be a valid option is because we often use
certificates in environments that have sufficient bandwidth and memory
capacity to allow certificate images to be stored in the certificate
itself. By storing the image in the certificate, we could save a
network retrieval.

The main counter argument is that it would be a serious disadvantage
if a certificate occasionally needs to be used in a constrained
environment and the fact that the base standard that we are updating
(RFC 3709) simply does not allow embedded images.

One way to do this could be to store images in a separate extension
and then define  a way to reference that image from the logotype
extension through an internal reference.

My proposed resolution is to exclude local storage from the current draft.
Defining local embedding is adding unnecessary complexity to the draft.

If a strong reason emerges to allow local storage, then this can be
defined in a separate draft.

/Stefan 
      </pre>
    </blockquote>
  </blockquote>
  <pre wrap=""><!---->


  </pre>
</blockquote>
<br>
</body>
</html>

--------------030507010909040806050708--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6L6sKp5004293 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Jul 2009 23:54:20 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6L6sKqP004292; Mon, 20 Jul 2009 23:54: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 n6L6s7Iv004280 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 20 Jul 2009 23:54:19 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 31429 invoked from network); 21 Jul 2009 06:54:08 -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]>; 21 Jul 2009 06:54:08 -0000
Received: (qmail 2797 invoked from network); 21 Jul 2009 06:54:06 -0000
Received: from 213-64-142-97-no153.business.telia.com (HELO [192.168.1.5]) ([e-mail]@[213.64.142.97]) (envelope-sender <[e-mail]>) by s29.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <[e-mail]>; 21 Jul 2009 06:54:06 -0000
User-Agent: Microsoft-Entourage/12.19.0.090515
Date: Tue, 21 Jul 2009 08:54:05 +0200
Subject: Re: Embedded certificate image
From: Stefan Santesson <[e-mail]>
To: Anders Rundgren <[e-mail]>
CC: ietf-pkix <[e-mail]>
Message-ID: <[e-mail]>
Thread-Topic: Embedded certificate image
Thread-Index: AcoJ0Al1x9/V2BhNO0im7GUBT1nkMw==
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>

Anders,

I'm not sure what you mean by "competing" proposal, but a reasonable
behavior by the client is to cache the certificate image once it has
obtained it, creating the situation where the image is locally stored but
not embedded.

But you won't get away from that first retrieval.

/Stefan


On 09-07-21 8:33 AM, "Anders Rundgren" <[e-mail]> wrote:

> In the "competing" proposal, certificate images are locally stored
> but not embedded in certificates.  This is a viable solution when
> images are only to be consumed by the end-user.  For external
> consumption (which I consider an entirely different use-case),
> the existing I-D seems quite sufficient.
> 
> Anders
> 
> Stefan Santesson wrote:
>> This is the first of two unresolved issues listed in the Certimage draft.
>> 
>> Is there any reason to provide any means to embed certificate images
>> in a certificate.
>> 
>> The reason why this might be a valid option is because we often use
>> certificates in environments that have sufficient bandwidth and memory
>> capacity to allow certificate images to be stored in the certificate
>> itself. By storing the image in the certificate, we could save a
>> network retrieval.
>> 
>> The main counter argument is that it would be a serious disadvantage
>> if a certificate occasionally needs to be used in a constrained
>> environment and the fact that the base standard that we are updating
>> (RFC 3709) simply does not allow embedded images.
>> 
>> One way to do this could be to store images in a separate extension
>> and then define  a way to reference that image from the logotype
>> extension through an internal reference.
>> 
>> My proposed resolution is to exclude local storage from the current draft.
>> Defining local embedding is adding unnecessary complexity to the draft.
>> 
>> If a strong reason emerges to allow local storage, then this can be
>> defined in a separate draft.
>> 
>> /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 n6L6XiHi003328 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Jul 2009 23:33:44 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6L6Xi8I003327; Mon, 20 Jul 2009 23:33:44 -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 n6L6XVKZ003283 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 20 Jul 2009 23:33:43 -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 0A83BC3DE1; Tue, 21 Jul 2009 08:33:30 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Tue, 21 Jul 2009 08:33:29 +0200
From: Anders Rundgren <[e-mail]>
User-Agent: Thunderbird 2.0.0.21 (X11/20090318)
MIME-Version: 1.0
To: Stefan Santesson <[e-mail]>
CC: ietf-pkix <[e-mail]>
Subject: Re: Embedded certificate image
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>

In the "competing" proposal, certificate images are locally stored
but not embedded in certificates.  This is a viable solution when
images are only to be consumed by the end-user.  For external
consumption (which I consider an entirely different use-case),
the existing I-D seems quite sufficient.

Anders

Stefan Santesson wrote:
> This is the first of two unresolved issues listed in the Certimage draft.
>
> Is there any reason to provide any means to embed certificate images 
> in a certificate.
>
> The reason why this might be a valid option is because we often use 
> certificates in environments that have sufficient bandwidth and memory 
> capacity to allow certificate images to be stored in the certificate 
> itself. By storing the image in the certificate, we could save a 
> network retrieval.
>
> The main counter argument is that it would be a serious disadvantage 
> if a certificate occasionally needs to be used in a constrained 
> environment and the fact that the base standard that we are updating 
> (RFC 3709) simply does not allow embedded images.
>
> One way to do this could be to store images in a separate extension 
> and then define  a way to reference that image from the logotype 
> extension through an internal reference.
>
> My proposed resolution is to exclude local storage from the current draft.
> Defining local embedding is adding unnecessary complexity to the draft.
>
> If a strong reason emerges to allow local storage, then this can be 
> defined in a separate draft.
>
> /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 n6KLhQhN069257 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Jul 2009 14:43:26 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6KLhQN6069256; Mon, 20 Jul 2009 14:43: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 n6KLhDAF069239 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 20 Jul 2009 14:43:24 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 18887 invoked from network); 20 Jul 2009 21:43:20 -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]>; 20 Jul 2009 21:43:20 -0000
Received: (qmail 92977 invoked from network); 20 Jul 2009 21:43:11 -0000
Received: from 213-64-142-97-no153.business.telia.com (HELO [192.168.1.5]) ([e-mail]@[213.64.142.97]) (envelope-sender <[e-mail]>) by s128.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <[e-mail]>; 20 Jul 2009 21:43:11 -0000
User-Agent: Microsoft-Entourage/12.19.0.090515
Date: Mon, 20 Jul 2009 23:43:10 +0200
Subject: Re: Embedded certificate image
From: Stefan Santesson <[e-mail]>
To: Thomas Hardjono <[e-mail]>, "'ietf-pkix'" <[e-mail]>
Message-ID: <[e-mail]>
Thread-Topic: Embedded certificate image
Thread-Index: AcoJYnIl4eQPCg2qAEyVQipx4ozd7AAF+ohgAAItt8E=
In-Reply-To: <007501ca097a$d72162f0$856428d0$@net>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3330978192_3700881"
Sender: [e-mail]
Precedence: 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_3330978192_3700881
Content-type: text/plain;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

Hi Thomas,

When discussing the particular issue at hand, it has just been considered i=
n
relation to certificate images.
However I agree that if we would create such extension, that we should make
it generic.

I think that is yet another good argument that such extension should be
separated from the certimage work.

What is your assessment on the actual need to store objects like an
information card inside a certificate?

/Stefan


On 09-07-20 10:44 PM, "Thomas Hardjono" <[e-mail]> wrote:

> Stefan,
> =20
> Has there been any thought about making such an extension =B3generic=B2 enoug=
h
> that it could reference other human-friendly objects (e.g. InfoCard, Open=
ID
> identity, etc. etc).
> =20
> /thomas/
> =20
> =20
> =20
>=20
> From: [e-mail] [mailto:[e-mail]] =
On
> Behalf Of Stefan Santesson
> Sent: Monday, July 20, 2009 1:50 PM
> To: ietf-pkix
> Subject: Embedded certificate image
> =20
> This is the first of two unresolved issues listed in the Certimage draft.
>=20
> Is there any reason to provide any means to embed certificate images in a
> certificate.
>=20
> The reason why this might be a valid option is because we often use
> certificates in environments that have sufficient bandwidth and memory
> capacity to allow certificate images to be stored in the certificate itse=
lf.
> By storing the image in the certificate, we could save a network retrieva=
l.
>=20
> The main counter argument is that it would be a serious disadvantage if a
> certificate occasionally needs to be used in a constrained environment an=
d the
> fact that the base standard that we are updating (RFC 3709) simply does n=
ot
> allow embedded images.
>=20
> One way to do this could be to store images in a separate extension and t=
hen
> define  a way to reference that image from the logotype extension through=
 an
> internal reference.
>=20
> My proposed resolution is to exclude local storage from the current draft=
.
> Defining local embedding is adding unnecessary complexity to the draft.
>=20
> If a strong reason emerges to allow local storage, then this can be defin=
ed in
> a separate draft.
>=20
> /Stefan=20
>=20


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

<HTML>
<HEAD>
<TITLE>Re: Embedded certificate image</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt=
'>Hi Thomas,<BR>
<BR>
When discussing the particular issue at hand, it has just been considered i=
n relation to certificate images.<BR>
However I agree that if we would create such extension, that we should make=
 it generic.<BR>
<BR>
I think that is yet another good argument that such extension should be sep=
arated from the certimage work.<BR>
<BR>
What is your assessment on the actual need to store objects like an informa=
tion card inside a certificate?<BR>
<BR>
/Stefan<BR>
<BR>
<BR>
On 09-07-20 10:44 PM, &quot;Thomas Hardjono&quot; &lt;<a href=3D"ietf@hardjon=
o.net">[e-mail]</a>&gt; wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><SPAN STYLE=3D'font-size:11pt'><FONT COLOR=3D"#1F497D=
"><FONT FACE=3D"Courier New">Stefan,<BR>
&nbsp;<BR>
Has there been any thought about making such an extension &#8220;generic&#8=
221; enough that it could reference other human-friendly objects (e.g. InfoC=
ard, OpenID identity, etc. etc).<BR>
&nbsp;<BR>
/thomas/<BR>
&nbsp;<BR>
&nbsp;<BR>
&nbsp;<BR>
</FONT></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><BR>
</FONT></SPAN><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, July 20, 2009 1:50 PM<BR>
<B>To:</B> ietf-pkix<BR>
<B>Subject:</B> Embedded certificate image<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'>This is the first of two unresolved issues listed in the Cer=
timage draft.<BR>
<BR>
Is there any reason to provide any means to embed certificate images in a c=
ertificate.<BR>
<BR>
The reason why this might be a valid option is because we often use certifi=
cates in environments that have sufficient bandwidth and memory capacity to =
allow certificate images to be stored in the certificate itself. By storing =
the image in the certificate, we could save a network retrieval.<BR>
<BR>
The main counter argument is that it would be a serious disadvantage if a c=
ertificate occasionally needs to be used in a constrained environment and th=
e fact that the base standard that we are updating (RFC 3709) simply does no=
t allow embedded images.<BR>
<BR>
One way to do this could be to store images in a separate extension and the=
n define &nbsp;a way to reference that image from the logotype extension thr=
ough an internal reference.<BR>
<BR>
My proposed resolution is to exclude local storage from the current draft.<=
BR>
Defining local embedding is adding unnecessary complexity to the draft.<BR>
<BR>
If a strong reason emerges to allow local storage, then this can be defined=
 in a separate draft.<BR>
<BR>
/Stefan <BR>
<BR>
</SPAN></FONT></BLOCKQUOTE>
</BODY>
</HTML>


--B_3330978192_3700881--




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6KKiR8o065922 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Jul 2009 13:44:27 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6KKiR74065921; Mon, 20 Jul 2009 13:44:27 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from outbound-mail-108.bluehost.com (outbound-mail-108.bluehost.com [69.89.22.8]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n6KKiEmT065905 for <[e-mail]>; Mon, 20 Jul 2009 13:44:24 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 26235 invoked by uid 0); 20 Jul 2009 20:44:13 -0000
Received: from unknown (HELO box251.bluehost.com) (69.89.31.51) by outboundproxy3.bluehost.com with SMTP; 20 Jul 2009 20:44:13 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=hardjono.net; h=Received:From:To:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=P5FIeSgQ5o8vQaBClLxuvXO88tnlsKjFq5KLCXuYak6y7B+OjIHa1NC/W0Ct2UgGJOuWhqWNEAY7f1VQbttgd/HR5hzS5k2C7Yn9PTS9w1cmRGgwuDV84n5dTVlk68ro;
Received: from dhcp-18-111-47-199.dyn.mit.edu ([18.111.47.199] helo=thomasvnf1ekrv) by box251.bluehost.com with esmtpa (Exim 4.69) (envelope-from <[e-mail]>) id 1MSziX-0003W8-1Q; Mon, 20 Jul 2009 14:44:13 -0600
From: "Thomas Hardjono" <[e-mail]>
To: "'Stefan Santesson'" <[e-mail]>, "'ietf-pkix'" <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: RE: Embedded certificate image
Date: Mon, 20 Jul 2009 16:44:04 -0400
Message-ID: <007501ca097a$d72162f0$856428d0$@net>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0076_01CA0959.500FC2F0"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcoJYnIl4eQPCg2qAEyVQipx4ozd7AAF+ohg
Content-Language: en-us
X-Identified-User: {727:box251.bluehost.com:hardjono:hardjono.net} {sentby:smtp auth 18.111.47.199 authed with ietf+hardjono.net}
Sender: [e-mail]
Precedence: 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_0076_01CA0959.500FC2F0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Stefan,
 
Has there been any thought about making such an extension "generic" enough
that it could reference other human-friendly objects (e.g. InfoCard, OpenID
identity, etc. etc).
 
/thomas/
 
 
 
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Stefan Santesson
Sent: Monday, July 20, 2009 1:50 PM
To: ietf-pkix
Subject: Embedded certificate image
 
This is the first of two unresolved issues listed in the Certimage draft.

Is there any reason to provide any means to embed certificate images in a
certificate.

The reason why this might be a valid option is because we often use
certificates in environments that have sufficient bandwidth and memory
capacity to allow certificate images to be stored in the certificate itself.
By storing the image in the certificate, we could save a network retrieval.

The main counter argument is that it would be a serious disadvantage if a
certificate occasionally needs to be used in a constrained environment and
the fact that the base standard that we are updating (RFC 3709) simply does
not allow embedded images.

One way to do this could be to store images in a separate extension and then
define  a way to reference that image from the logotype extension through an
internal reference.

My proposed resolution is to exclude local storage from the current draft.
Defining local embedding is adding unnecessary complexity to the draft.

If a strong reason emerges to allow local storage, then this can be defined
in a separate draft.

/Stefan 

------=_NextPart_000_0076_01CA0959.500FC2F0
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=3DProgId content=3DWord.Document>
<meta name=3DGenerator content=3D"Microsoft Word 12">
<meta name=3DOriginator content=3D"Microsoft Word 12">
<link rel=3DFile-List href=3D"cid:filelist.xml@01CA0959.4A8C52D0">
<title>Embedded certificate image</title>
<!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:AllowPNG/>
  <o:DoNotRelyOnCSS/>
  <o:TargetScreenSize>1024x768</o:TargetScreenSize>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:SpellingState>Clean</w:SpellingState>
  <w:TrackMoves/>
  <w:TrackFormatting/>
  <w:EnvelopeVis/>
  <w:ValidateAgainstSchemas/>
  <w:SaveIfXMLInvalid>false</w:SaveIfXMLInvalid>
  <w:IgnoreMixedContent>false</w:IgnoreMixedContent>
  <w:AlwaysShowPlaceholderText>false</w:AlwaysShowPlaceholderText>
  <w:DoNotPromoteQF/>
  <w:LidThemeOther>EN-US</w:LidThemeOther>
  <w:LidThemeAsian>X-NONE</w:LidThemeAsian>
  <w:LidThemeComplexScript>X-NONE</w:LidThemeComplexScript>
  <w:Compatibility>
   <w:DoNotExpandShiftReturn/>
   <w:BreakWrappedTables/>
   <w:SplitPgBreakAndParaMark/>
   <w:DontVertAlignCellWithSp/>
   <w:DontBreakConstrainedForcedTables/>
   <w:DontVertAlignInTxbx/>
   <w:Word11KerningPairs/>
   <w:CachedColBalance/>
  </w:Compatibility>
  <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
  <m:mathPr>
   <m:mathFont m:val=3D"Cambria Math"/>
   <m:brkBin m:val=3D"before"/>
   <m:brkBinSub m:val=3D"--"/>
   <m:smallFrac m:val=3D"off"/>
   <m:dispDef/>
   <m:lMargin m:val=3D"0"/>
   <m:rMargin m:val=3D"0"/>
   <m:defJc m:val=3D"centerGroup"/>
   <m:wrapIndent m:val=3D"1440"/>
   <m:intLim m:val=3D"subSup"/>
   <m:naryLim m:val=3D"undOvr"/>
  </m:mathPr></w:WordDocument>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:LatentStyles DefLockedState=3D"false" DefUnhideWhenUsed=3D"true"=20
  DefSemiHidden=3D"true" DefQFormat=3D"false" DefPriority=3D"99"=20
  LatentStyleCount=3D"267">
  <w:LsdException Locked=3D"false" Priority=3D"0" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Normal"/>
  <w:LsdException Locked=3D"false" Priority=3D"9" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"heading 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"9" QFormat=3D"true" =
Name=3D"heading 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"9" QFormat=3D"true" =
Name=3D"heading 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"9" QFormat=3D"true" =
Name=3D"heading 4"/>
  <w:LsdException Locked=3D"false" Priority=3D"9" QFormat=3D"true" =
Name=3D"heading 5"/>
  <w:LsdException Locked=3D"false" Priority=3D"9" QFormat=3D"true" =
Name=3D"heading 6"/>
  <w:LsdException Locked=3D"false" Priority=3D"9" QFormat=3D"true" =
Name=3D"heading 7"/>
  <w:LsdException Locked=3D"false" Priority=3D"9" QFormat=3D"true" =
Name=3D"heading 8"/>
  <w:LsdException Locked=3D"false" Priority=3D"9" QFormat=3D"true" =
Name=3D"heading 9"/>
  <w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 4"/>
  <w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 5"/>
  <w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 6"/>
  <w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 7"/>
  <w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 8"/>
  <w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 9"/>
  <w:LsdException Locked=3D"false" Priority=3D"35" QFormat=3D"true" =
Name=3D"caption"/>
  <w:LsdException Locked=3D"false" Priority=3D"10" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Title"/>
  <w:LsdException Locked=3D"false" Priority=3D"1" Name=3D"Default =
Paragraph Font"/>
  <w:LsdException Locked=3D"false" Priority=3D"11" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Subtitle"/>
  <w:LsdException Locked=3D"false" Priority=3D"22" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Strong"/>
  <w:LsdException Locked=3D"false" Priority=3D"20" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Emphasis"/>
  <w:LsdException Locked=3D"false" Priority=3D"59" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Table Grid"/>
  <w:LsdException Locked=3D"false" UnhideWhenUsed=3D"false" =
Name=3D"Placeholder Text"/>
  <w:LsdException Locked=3D"false" Priority=3D"1" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"No Spacing"/>
  <w:LsdException Locked=3D"false" Priority=3D"60" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Light Shading"/>
  <w:LsdException Locked=3D"false" Priority=3D"61" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Light List"/>
  <w:LsdException Locked=3D"false" Priority=3D"62" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Light Grid"/>
  <w:LsdException Locked=3D"false" Priority=3D"63" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Shading 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"64" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Shading 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"65" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium List 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"66" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium List 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"67" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"68" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"69" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"70" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Dark List"/>
  <w:LsdException Locked=3D"false" Priority=3D"71" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Colorful Shading"/>
  <w:LsdException Locked=3D"false" Priority=3D"72" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Colorful List"/>
  <w:LsdException Locked=3D"false" Priority=3D"73" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Colorful Grid"/>
  <w:LsdException Locked=3D"false" Priority=3D"60" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Light Shading Accent 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"61" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Light List Accent 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"62" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Light Grid Accent 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"63" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Shading 1 Accent 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"64" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Shading 2 Accent 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"65" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium List 1 Accent 1"/>
  <w:LsdException Locked=3D"false" UnhideWhenUsed=3D"false" =
Name=3D"Revision"/>
  <w:LsdException Locked=3D"false" Priority=3D"34" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"List Paragraph"/>
  <w:LsdException Locked=3D"false" Priority=3D"29" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Quote"/>
  <w:LsdException Locked=3D"false" Priority=3D"30" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Intense Quote"/>
  <w:LsdException Locked=3D"false" Priority=3D"66" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium List 2 Accent 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"67" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 1 Accent 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"68" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 2 Accent 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"69" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 3 Accent 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"70" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Dark List Accent 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"71" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Colorful Shading Accent 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"72" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Colorful List Accent 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"73" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Colorful Grid Accent 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"60" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Light Shading Accent 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"61" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Light List Accent 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"62" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Light Grid Accent 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"63" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Shading 1 Accent 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"64" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Shading 2 Accent 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"65" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium List 1 Accent 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"66" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium List 2 Accent 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"67" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 1 Accent 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"68" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 2 Accent 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"69" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 3 Accent 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"70" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Dark List Accent 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"71" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Colorful Shading Accent 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"72" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Colorful List Accent 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"73" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Colorful Grid Accent 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"60" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Light Shading Accent 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"61" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Light List Accent 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"62" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Light Grid Accent 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"63" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Shading 1 Accent 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"64" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Shading 2 Accent 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"65" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium List 1 Accent 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"66" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium List 2 Accent 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"67" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 1 Accent 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"68" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 2 Accent 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"69" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 3 Accent 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"70" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Dark List Accent 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"71" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Colorful Shading Accent 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"72" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Colorful List Accent 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"73" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Colorful Grid Accent 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"60" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Light Shading Accent 4"/>
  <w:LsdException Locked=3D"false" Priority=3D"61" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Light List Accent 4"/>
  <w:LsdException Locked=3D"false" Priority=3D"62" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Light Grid Accent 4"/>
  <w:LsdException Locked=3D"false" Priority=3D"63" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Shading 1 Accent 4"/>
  <w:LsdException Locked=3D"false" Priority=3D"64" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Shading 2 Accent 4"/>
  <w:LsdException Locked=3D"false" Priority=3D"65" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium List 1 Accent 4"/>
  <w:LsdException Locked=3D"false" Priority=3D"66" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium List 2 Accent 4"/>
  <w:LsdException Locked=3D"false" Priority=3D"67" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 1 Accent 4"/>
  <w:LsdException Locked=3D"false" Priority=3D"68" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 2 Accent 4"/>
  <w:LsdException Locked=3D"false" Priority=3D"69" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 3 Accent 4"/>
  <w:LsdException Locked=3D"false" Priority=3D"70" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Dark List Accent 4"/>
  <w:LsdException Locked=3D"false" Priority=3D"71" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Colorful Shading Accent 4"/>
  <w:LsdException Locked=3D"false" Priority=3D"72" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Colorful List Accent 4"/>
  <w:LsdException Locked=3D"false" Priority=3D"73" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Colorful Grid Accent 4"/>
  <w:LsdException Locked=3D"false" Priority=3D"60" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Light Shading Accent 5"/>
  <w:LsdException Locked=3D"false" Priority=3D"61" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Light List Accent 5"/>
  <w:LsdException Locked=3D"false" Priority=3D"62" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Light Grid Accent 5"/>
  <w:LsdException Locked=3D"false" Priority=3D"63" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Shading 1 Accent 5"/>
  <w:LsdException Locked=3D"false" Priority=3D"64" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Shading 2 Accent 5"/>
  <w:LsdException Locked=3D"false" Priority=3D"65" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium List 1 Accent 5"/>
  <w:LsdException Locked=3D"false" Priority=3D"66" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium List 2 Accent 5"/>
  <w:LsdException Locked=3D"false" Priority=3D"67" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 1 Accent 5"/>
  <w:LsdException Locked=3D"false" Priority=3D"68" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 2 Accent 5"/>
  <w:LsdException Locked=3D"false" Priority=3D"69" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 3 Accent 5"/>
  <w:LsdException Locked=3D"false" Priority=3D"70" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Dark List Accent 5"/>
  <w:LsdException Locked=3D"false" Priority=3D"71" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Colorful Shading Accent 5"/>
  <w:LsdException Locked=3D"false" Priority=3D"72" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Colorful List Accent 5"/>
  <w:LsdException Locked=3D"false" Priority=3D"73" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Colorful Grid Accent 5"/>
  <w:LsdException Locked=3D"false" Priority=3D"60" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Light Shading Accent 6"/>
  <w:LsdException Locked=3D"false" Priority=3D"61" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Light List Accent 6"/>
  <w:LsdException Locked=3D"false" Priority=3D"62" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Light Grid Accent 6"/>
  <w:LsdException Locked=3D"false" Priority=3D"63" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Shading 1 Accent 6"/>
  <w:LsdException Locked=3D"false" Priority=3D"64" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Shading 2 Accent 6"/>
  <w:LsdException Locked=3D"false" Priority=3D"65" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium List 1 Accent 6"/>
  <w:LsdException Locked=3D"false" Priority=3D"66" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium List 2 Accent 6"/>
  <w:LsdException Locked=3D"false" Priority=3D"67" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 1 Accent 6"/>
  <w:LsdException Locked=3D"false" Priority=3D"68" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 2 Accent 6"/>
  <w:LsdException Locked=3D"false" Priority=3D"69" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 3 Accent 6"/>
  <w:LsdException Locked=3D"false" Priority=3D"70" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Dark List Accent 6"/>
  <w:LsdException Locked=3D"false" Priority=3D"71" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Colorful Shading Accent 6"/>
  <w:LsdException Locked=3D"false" Priority=3D"72" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Colorful List Accent 6"/>
  <w:LsdException Locked=3D"false" Priority=3D"73" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Colorful Grid Accent 6"/>
  <w:LsdException Locked=3D"false" Priority=3D"19" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Subtle Emphasis"/>
  <w:LsdException Locked=3D"false" Priority=3D"21" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Intense Emphasis"/>
  <w:LsdException Locked=3D"false" Priority=3D"31" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Subtle Reference"/>
  <w:LsdException Locked=3D"false" Priority=3D"32" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Intense =
Reference"/>
  <w:LsdException Locked=3D"false" Priority=3D"33" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Book Title"/>
  <w:LsdException Locked=3D"false" Priority=3D"37" =
Name=3D"Bibliography"/>
  <w:LsdException Locked=3D"false" Priority=3D"39" QFormat=3D"true" =
Name=3D"TOC Heading"/>
 </w:LatentStyles>
</xml><![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;
	mso-font-charset:0;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:-1610611985 1073750139 0 0 159 0;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;
	mso-font-charset:0;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:1627400839 -2147483648 8 0 66047 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-unhide:no;
	mso-style-qformat:yes;
	mso-style-parent:"";
	margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";
	mso-fareast-font-family:Calibri;}
a:link, span.MsoHyperlink
	{mso-style-noshow:yes;
	mso-style-priority:99;
	color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-noshow:yes;
	mso-style-priority:99;
	color:purple;
	text-decoration:underline;
	text-underline:single;}
span.EmailStyle17
	{mso-style-type:personal-reply;
	mso-style-noshow:yes;
	mso-style-unhide:no;
	mso-ansi-font-size:11.0pt;
	mso-bidi-font-size:11.0pt;
	font-family:"Courier New";
	mso-ascii-font-family:"Courier New";
	mso-hansi-font-family:"Courier New";
	mso-bidi-font-family:"Times New Roman";
	color:#1F497D;}
span.SpellE
	{mso-style-name:"";
	mso-spl-e:yes;}
.MsoChpDefault
	{mso-style-type:export-only;
	mso-default-props:yes;
	font-size:10.0pt;
	mso-ansi-font-size:10.0pt;
	mso-bidi-font-size:10.0pt;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;
	mso-header-margin:.5in;
	mso-footer-margin:.5in;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 10]>
<style>
 /* Style Definitions */=20
 table.MsoNormalTable
	{mso-style-name:"Table Normal";
	mso-tstyle-rowband-size:0;
	mso-tstyle-colband-size:0;
	mso-style-noshow:yes;
	mso-style-priority:99;
	mso-style-qformat:yes;
	mso-style-parent:"";
	mso-padding-alt:0in 5.4pt 0in 5.4pt;
	mso-para-margin:0in;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Times New Roman","serif";}
</style>
<![endif]--><!--[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 =
style=3D'tab-interval:.5in'>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3D"Courier =
New"><span
style=3D'font-size:11.0pt;font-family:"Courier =
New";mso-bidi-font-family:"Times New Roman";
color:#1F497D'>Stefan,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3D"Courier =
New"><span
style=3D'font-size:11.0pt;font-family:"Courier =
New";mso-bidi-font-family:"Times New Roman";
color:#1F497D'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3D"Courier =
New"><span
style=3D'font-size:11.0pt;font-family:"Courier =
New";mso-bidi-font-family:"Times New Roman";
color:#1F497D'>Has there been any thought about making such an extension =
&#8220;generic&#8221;
enough that it could reference other human-friendly objects (e.g. <span
class=3DSpellE>InfoCard</span>, <span class=3DSpellE>OpenID</span> =
identity, etc.
etc).<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3D"Courier =
New"><span
style=3D'font-size:11.0pt;font-family:"Courier =
New";mso-bidi-font-family:"Times New Roman";
color:#1F497D'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3D"Courier =
New"><span
style=3D'font-size:11.0pt;font-family:"Courier =
New";mso-bidi-font-family:"Times New Roman";
color:#1F497D'>/thomas/<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3D"Courier =
New"><span
style=3D'font-size:11.0pt;font-family:"Courier =
New";mso-bidi-font-family:"Times New Roman";
color:#1F497D'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3D"Courier =
New"><span
style=3D'font-size:11.0pt;font-family:"Courier =
New";mso-bidi-font-family:"Times New Roman";
color:#1F497D'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3D"Courier =
New"><span
style=3D'font-size:11.0pt;font-family:"Courier =
New";mso-bidi-font-family:"Times New Roman";
color:#1F497D'><o:p>&nbsp;</o:p></span></font></p>

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

<div>

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

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:"Tahoma","sans-serif";mso-fareast-font-family:"Times New =
Roman";
font-weight:bold'>From:</span></font></b><font size=3D2 =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif";mso-fareast-f=
ont-family:
"Times New Roman"'> [e-mail]
[mailto:[e-mail]] <b><span =
style=3D'font-weight:bold'>On
Behalf Of </span></b>Stefan Santesson<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Monday, July 20, =
2009 1:50
PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> ietf-pkix<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> Embedded =
certificate
image<o:p></o:p></span></font></p>

</div>

</div>

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

<p class=3DMsoNormal><font size=3D2 face=3DCalibri><span =
style=3D'font-size:11.0pt;
font-family:"Calibri","sans-serif";mso-fareast-font-family:"Times New =
Roman"'>This
is the first of two unresolved issues listed in the Certimage draft.<br>
<br>
Is there any reason to provide any means to embed certificate images in =
a
certificate.<br>
<br>
The reason why this might be a valid option is because we often use
certificates in environments that have sufficient bandwidth and memory =
capacity
to allow certificate images to be stored in the certificate itself. By =
storing
the image in the certificate, we could save a network retrieval.<br>
<br>
The main counter argument is that it would be a serious disadvantage if =
a
certificate occasionally needs to be used in a constrained environment =
and the
fact that the base standard that we are updating (RFC 3709) simply does =
not
allow embedded images.<br>
<br>
One way to do this could be to store images in a separate extension and =
then
define &nbsp;a way to reference that image from the logotype extension =
through
an internal reference.<br>
<br>
My proposed resolution is to exclude local storage from the current =
draft.<br>
Defining local embedding is adding unnecessary complexity to the =
draft.<br>
<br>
If a strong reason emerges to allow local storage, then this can be =
defined in
a separate draft.<br>
<br>
/Stefan </span></font><span style=3D'mso-fareast-font-family:"Times New =
Roman"'><o:p></o:p></span></p>

</div>

</div>

</body>

</html>

------=_NextPart_000_0076_01CA0959.500FC2F0--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6KHnsOW055277 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Jul 2009 10:49:54 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6KHns5m055276; Mon, 20 Jul 2009 10:49:54 -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 n6KHnfhq055239 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 20 Jul 2009 10:49:53 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 12672 invoked from network); 20 Jul 2009 17:49:47 -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 Jul 2009 17:49:47 -0000
Received: (qmail 85274 invoked from network); 20 Jul 2009 17:49:40 -0000
Received: from 213-64-142-97-no153.business.telia.com (HELO [192.168.1.3]) ([e-mail]@[213.64.142.97]) (envelope-sender <[e-mail]>) by s24.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <[e-mail]>; 20 Jul 2009 17:49:40 -0000
User-Agent: Microsoft-Entourage/12.19.0.090515
Date: Mon, 20 Jul 2009 19:49:36 +0200
Subject: Embedded certificate image
From: Stefan Santesson <[e-mail]>
To: ietf-pkix <[e-mail]>
Message-ID: <[e-mail]>
Thread-Topic: Embedded certificate image
Thread-Index: AcoJYnIl4eQPCg2qAEyVQipx4ozd7A==
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3330964180_2850767"
Sender: [e-mail]
Precedence: 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_3330964180_2850767
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit

This is the first of two unresolved issues listed in the Certimage draft.

Is there any reason to provide any means to embed certificate images in a
certificate.

The reason why this might be a valid option is because we often use
certificates in environments that have sufficient bandwidth and memory
capacity to allow certificate images to be stored in the certificate itself.
By storing the image in the certificate, we could save a network retrieval.

The main counter argument is that it would be a serious disadvantage if a
certificate occasionally needs to be used in a constrained environment and
the fact that the base standard that we are updating (RFC 3709) simply does
not allow embedded images.

One way to do this could be to store images in a separate extension and then
define  a way to reference that image from the logotype extension through an
internal reference.

My proposed resolution is to exclude local storage from the current draft.
Defining local embedding is adding unnecessary complexity to the draft.

If a strong reason emerges to allow local storage, then this can be defined
in a separate draft.

/Stefan 

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

<HTML>
<HEAD>
<TITLE>Embedded certificate image</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt=
'>This is the first of two unresolved issues listed in the Certimage draft.<=
BR>
<BR>
Is there any reason to provide any means to embed certificate images in a c=
ertificate.<BR>
<BR>
The reason why this might be a valid option is because we often use certifi=
cates in environments that have sufficient bandwidth and memory capacity to =
allow certificate images to be stored in the certificate itself. By storing =
the image in the certificate, we could save a network retrieval.<BR>
<BR>
The main counter argument is that it would be a serious disadvantage if a c=
ertificate occasionally needs to be used in a constrained environment and th=
e fact that the base standard that we are updating (RFC 3709) simply does no=
t allow embedded images.<BR>
<BR>
One way to do this could be to store images in a separate extension and the=
n define &nbsp;a way to reference that image from the logotype extension thr=
ough an internal reference.<BR>
<BR>
My proposed resolution is to exclude local storage from the current draft.<=
BR>
Defining local embedding is adding unnecessary complexity to the draft.<BR>
<BR>
If a strong reason emerges to allow local storage, then this can be defined=
 in a separate draft.<BR>
<BR>
/Stefan </SPAN></FONT>
</BODY>
</HTML>


--B_3330964180_2850767--




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6KAudnU025303 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Jul 2009 03: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 n6KAudFN025302; Mon, 20 Jul 2009 03: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 mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.33]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6KAuSq2025287 for <[e-mail]>; Mon, 20 Jul 2009 03:56:38 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 9FAD766A928; Mon, 20 Jul 2009 22:56:27 +1200 (NZST)
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jG5jmsNmTAUi; Mon, 20 Jul 2009 22:56:27 +1200 (NZST)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id F227F66A925; Mon, 20 Jul 2009 22:56:25 +1200 (NZST)
Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id C99CE1DE4001; Mon, 20 Jul 2009 22:56:23 +1200 (NZST)
Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from <[e-mail]>) id 1MSqXf-00054o-MF; Mon, 20 Jul 2009 22:56:23 +1200
From: Peter Gutmann <[e-mail]>
To: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: Relieving CAs of 'ultimate responsibility' [was: Way forward - updating RFC 3161]
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
Date: Mon, 20 Jul 2009 22:56:23 +1200
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>Peter,
>
>Could you then give me the "sales pitch on a T-shirt" version of this.
>
>I'm reading the PK Superstructure document and can only find philosophical
>differences but no technical ones, except for a critical extension which
>meaning and purpose is unclear to me.

Uhh, I think that was meant for Stephen, not me...

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 n6KAtPHB025244 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Jul 2009 03:55:25 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6KAtPnV025243; Mon, 20 Jul 2009 03:55:25 -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 n6KAtMXK025234 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 20 Jul 2009 03:55:23 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 97552 invoked from network); 20 Jul 2009 10:55:24 -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 Jul 2009 10:55:24 -0000
Received: (qmail 92597 invoked from network); 20 Jul 2009 10:55:20 -0000
Received: from 213-64-142-97-no153.business.telia.com (HELO [192.168.1.6]) ([e-mail]@[213.64.142.97]) (envelope-sender <[e-mail]>) by s24.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <[e-mail]>; 20 Jul 2009 10:55:20 -0000
User-Agent: Microsoft-Entourage/12.19.0.090515
Date: Mon, 20 Jul 2009 12:55:18 +0200
Subject: Re: Relieving CAs of 'ultimate responsibility'
From: Stefan Santesson <[e-mail]>
To: Stephen Wilson <[e-mail]>, <[e-mail]>
Message-ID: <[e-mail]>
Thread-Topic: Relieving CAs of 'ultimate responsibility'
Thread-Index: AcoJKJGfBA7YQEy9G0yCKVLzJvWWkQ==
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>

Hi Stephen,


On 09-07-20 12:06 PM, "Stephen Wilson" <[e-mail]> wrote:

> 
> 
> Stefan Santesson wrote:
>> Stephen,
>> 
>> Sorry for bringing a negative touch, but I think your mails looks more like
>> sales pitch for your company's business agenda than creative proposal on PKI
>> protocol development.
> I don't mind criticism but that's unwarranted.  I have no commercial
> interest in any of this.  And I have no agenda other than to promote
> better, fresher applications of PKI.  We all know that PKI is
> misunderstood and feared for its complexity, but it's less appreciated
> that the complexity is mostly of our  making.

Your initial mail contained quite some advertising and made that impression
on me. I'll accept the assumption that you are acting for the good of man
kind. ;)

>> You may implement whatever model of administration around certificates and
>> their issuance as you like. They are still signed by the CA's key which
>> makes them a statement by the CA.
> You're reflecting the arbitrary constructs of orthodox PKI.  The
> metaphors of "signature" and "statement" and the like have landed us in
> a situation where people cannot conceieve of other ways to construe what
> it is that a CA does.  What if rather than 'signing a statement by the
> CA', we imagine the CA as putting its seal on a certificate in order to
> render that tamper resistant, and to bind other authority information?

I don't understand the practical implication of your argument, other than
that you like to use other words.

>> Unlike cheques, certificates can't have information added to the after
>> issuance/signing. That does not mean that the CA have to accept any liability
>> for their use.
> It's not the liability for (mis)use that concerns me here, it's the
> liability for registration errors.

The CA is not required by technology or protocols to accept any liability.
The certificate will still be issued by the CA and thus be a statement by
the CA.

>> 
>> Finally, I'm even more puzzled when a company claiming to be in the security
>> business, suggests other security expert to download their whitepapers, that
>> turns out to be an .exe file.
> It wasn't an .exe, it was just a link to a page.

Yeah, noticed, But it still downloads as an .exe on a Mac. I think that is
worth fixing :) It could be sorted by linking directly to the .pdf file.


> 
> BTW I am not trying to introduce any new "protocols" here and I haven't
> offered these thoughts for any technical consideration by the PKIX WG.
> Just trying to show that certain conventions of old PKI (like the idea
> that the CA "is ultimately the responsible party") might be arbitrary
> and useful to review.  These ideas were rather well received at the
> IDtrust conference in 2008.
> 
> Cheers,
> 
> Stephen.

Great. In the sense that this might effect how we develop protocols for PKI,
the discussion is valid. But I'm afraid that I just have a hard time to
understand the core of you ideas.

What I read in your paper is that you more or less want the RA to be the
issuer and the CA to be the facilitator for issuing certificate, but with no
liability for any faults committed by the RA, just for the operation of the
CA "factory".

Now, it is problematic in the sense that the RA, who in such case acts as
issuer, is not identified in the certificate. Unless the RA is identified as
issuer, the certificate is by definition a statement by the CA.

If you OTOH identify the RA as the issuer, then you have just made the RA a
CA and turned the CA into a facility operator, which is a model that has
been in existence for a long time.

If you try to do this by allowing the CA to use a common issuing key for
many RAs identified as issuers, then we have created a mess and violated a
whole bunch of standards..


Basically, I don't see the real difference from current PKI with limited
liability. Feel free to correct my misguided mind..

/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 n6KAHl4i022810 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Jul 2009 03:17:47 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6KAHl6F022809; Mon, 20 Jul 2009 03:17:47 -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 n6KAHYSx022701 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 20 Jul 2009 03:17:46 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 97784 invoked from network); 20 Jul 2009 10:17:36 -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]>; 20 Jul 2009 10:17:36 -0000
Received: (qmail 75815 invoked from network); 20 Jul 2009 10:17:33 -0000
Received: from 213-64-142-97-no153.business.telia.com (HELO [192.168.1.6]) ([e-mail]@[213.64.142.97]) (envelope-sender <[e-mail]>) by s57.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <[e-mail]>; 20 Jul 2009 10:17:33 -0000
User-Agent: Microsoft-Entourage/12.19.0.090515
Date: Mon, 20 Jul 2009 12:17:29 +0200
Subject: Re: RFC5280 : Applications and CRL DP extension support
From: Stefan Santesson <[e-mail]>
To: Jean-Marc Desperrier <[e-mail]>, <[e-mail]>
Message-ID: <[e-mail]>
Thread-Topic: RFC5280 : Applications and CRL DP extension support
Thread-Index: AcoJI0kyvigxkiMlqki6zUg2+CeJ8g==
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>

Jean,

CRLDP is not required in that meaning, but matching distribution points is
an extra feature to ensure that you are actually using the right CRL.

The basic assumption for PKI is that CA names are selected in a way that
you will not trust several CAs with identical names at the same time.
Following that assumption it is sufficient to match the name of the
certificate issuer in the certificate and the CRL.

In the absence of an IDP, the CRL must have a complete scope, and most CRLs
are issued with a complete scope.

However, It was once a disjoint in the way Microsoft issued its CRLs that
they allowed CRLs to cover "only" certificates issued under one CA key
without including IDP in the CRL, even if that CA under the same name had
issued certificates with another key. They had to add an IDP to the CRLs to
allow that limited scope. In this case the matching of distribution points
helps identifying the scope of the CRL by ensuring that you are looking at
the intended CRL for the certificate you are validating.

So it is logical to me that CDP is recommended to support CRL discovery, but
allowing IDP to be optional as long as the CRL has a complete scope.

/Stefan 


On 09-07-20 11:54 AM, "Jean-Marc Desperrier" <[e-mail]> wrote:

> 
> Stefan Santesson wrote:
>> When a CRLDP is present in a certificate and an Issuing Distribution point
>> extension is present in the CRL, them the distribution points of these
>> extensions MUST match as defined in section 5.2.5 of RFC 5280.
> 
> Yes, of course, but if support of CRLDP is only really required in that
> meaning, then there's a mismatch between the fact that application
> support of CRLDP is recommended, but support of IDP is optional (given
> that IDP  MUST be critical):
> 
>     4.2.1.13.  CRL Distribution Points
>     [...] this profile
>     RECOMMENDS support for this extension by CAs and applications.
> 
>     5.2.5.  Issuing Distribution Point
>     [...] conforming implementations are not required to support
>     this extension
> 
> Maybe the RECOMMENDS for CRL DP should best be read as meaning that the
> application SHOULD be able to parse and make the info available to the
> user ?
> 




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6KA7S88021358 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Jul 2009 03:07:28 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6KA7RiZ021357; Mon, 20 Jul 2009 03:07:27 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp162.iad.emailsrvr.com (smtp162.iad.emailsrvr.com [207.97.245.162]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6KA7FAW021283 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 20 Jul 2009 03:07:26 -0700 (MST) (envelope-from [e-mail])
Received: from relay6.relay.iad.emailsrvr.com (localhost [127.0.0.1]) by relay6.relay.iad.emailsrvr.com (SMTP Server) with ESMTP id 50F9E7B72F8 for <[e-mail]>; Mon, 20 Jul 2009 06:07:15 -0400 (EDT)
Received: by relay6.relay.iad.emailsrvr.com (Authenticated sender: swilson-AT-lockstep.com.au) with ESMTPA id AEC5F7B9090 for <[e-mail]>; Mon, 20 Jul 2009 06:07:06 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Mon, 20 Jul 2009 20:06:50 +1000
From: Stephen Wilson <[e-mail]>
User-Agent: Thunderbird 2.0.0.22 (Windows/20090605)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Relieving CAs of 'ultimate responsibility'
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:
> Stephen,
>
> Sorry for bringing a negative touch, but I think your mails looks more like sales pitch for your company's business agenda than creative proposal on PKI protocol development.
I don't mind criticism but that's unwarranted.  I have no commercial 
interest in any of this.  And I have no agenda other than to promote 
better, fresher applications of PKI.  We all know that PKI is 
misunderstood and feared for its complexity, but it's less appreciated 
that the complexity is mostly of our  making. 
> You may implement whatever model of administration around certificates and
> their issuance as you like. They are still signed by the CA's key which
> makes them a statement by the CA. 
You're reflecting the arbitrary constructs of orthodox PKI.  The 
metaphors of "signature" and "statement" and the like have landed us in 
a situation where people cannot conceieve of other ways to construe what 
it is that a CA does.  What if rather than 'signing a statement by the 
CA', we imagine the CA as putting its seal on a certificate in order to 
render that tamper resistant, and to bind other authority information? 
> Unlike cheques, certificates can't have information added to the after issuance/signing. That does not mean that the CA have to accept any liability for their use.
It's not the liability for (mis)use that concerns me here, it's the 
liability for registration errors.
>
> Finally, I'm even more puzzled when a company claiming to be in the security business, suggests other security expert to download their whitepapers, that turns out to be an .exe file.
It wasn't an .exe, it was just a link to a page. 

BTW I am not trying to introduce any new "protocols" here and I haven't 
offered these thoughts for any technical consideration by the PKIX WG.  
Just trying to show that certain conventions of old PKI (like the idea 
that the CA "is ultimately the responsible party") might be arbitrary 
and useful to review.  These ideas were rather well received at the 
IDtrust conference in 2008.

Cheers,

Stephen.

Stephen Wilson
Lockstep
www.lockstep.com.au


>
> Peter Gutmann wrote:
>>> Stephen Wilson <[e-mail]> writes:
>>>> But there is a way to relieve CAs of many risks, and at the same time
>>>> simplify the legal principles, the user agreements and the PKI business
>>>> model: treat the CA like a Security Printer. Like a cheque printer, a CA
>>>> should only be responsible for the quality of the certificates (cheques) but
>>>> not their content.
>>>>
>>>> http://www.lockstep.com.au/library/pki/the_security_printer_model_fo.
>>> Hmm, interesting perspective.  However, if this is implemented, can I put
>>> down my name to be the certificate vending machine?  Someone else (handwave)
>>> can be the RA.
>>>
>>> Peter.
>> I think the sarcasm is misplaced.
>>
>> Running a CA or a cheque printer is tougher than running a vending
>> machine.  The Security Printer model still requires a multi million
>> dollar investment in facilities security, Commion Criteria certified
>> systems, trusted personnel and so on.  And it's not a licence to print
>> money -- these should be high volume, low margin businesses.  I was
>> asked a question from the audience at an Asia PKI Forum conference once
>> how many CAs I thought were needed in the world, and I said "about three
>> or four".
>>
>> Picking RAs is not a hand waving exercise.  In most cases, the choice of
>> RA is logical and transparent: medical registration boards, licensing
>> bodies, employers, professional associations etc.
>>
>> This view of PKI holds that digital cerificates are best used to
>> automate transactions between parties that already recognise one
>> anothers' qualifications (and who therefore already have risk mitigation
>> arrangements in place, like professional indemnity schemes).  Therefore
>> certificates should be issued by existing credentialling authorities
>> (the RAs), and minted by specialist wholesale CAs.  There are other
>> precedents for this type of model, like bank card production.  We have
>> many many banks, issuing many many card products, but only a few large
>> scale card personalisation bureaus.
>>
>> In this way, the meaningfulness of certificates vests in existing
>> recognised bodies.  All the traditionally intractable problems of PKI
>> disappear (like certificate cross-recognition, because in commerce and
>> the professions we have ways of recognising credentials issued by
>> cross-border RAs).
>>
>> See also http://www.lockstep.com.au/library/pki/public_key_superstructure
>>
>> To move to the Security Printer paradigm requires we give up a few of
>> the long standing PKI ambitions, like the dream of stranger-to-stranger
>> e-commerce, and the dream of a one-size-fits-all multipurpose digital
>> certificate. 
>>
>> Cheers,
>>
>> Stephen Wilson
>> Lockstep
>> www.lockstep.com.au
>>
>
>
>
>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6K9sldd020018 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Jul 2009 02:54:47 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6K9slX2020017; Mon, 20 Jul 2009 02:54:47 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-ft3.fr.colt.net (smtp-ft3.fr.colt.net [213.41.78.205]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6K9sZ0V020000 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 20 Jul 2009 02:54:46 -0700 (MST) (envelope-from [e-mail])
Received: from smtp-ex5.fr.colt.net (smtp-ex5.fr.colt.net [213.41.78.121]) by smtp-ft3.fr.colt.net (8.13.8/8.13.8/Debian-3) with ESMTP id n6K9sW0p002301 for <[e-mail]>; Mon, 20 Jul 2009 11:54:38 +0200
Received: from host.104.92.68.195.rev.coltfrance.com ([195.68.92.104] helo=[172.30.24.37]) by smtp-ex5.fr.colt.net with esmtp (Exim) (envelope-from <[e-mail]>) id 1MSpZk-00043B-0h for <[e-mail]>; Mon, 20 Jul 2009 11:54:28 +0200
Message-ID: <[e-mail]>
Date: Mon, 20 Jul 2009 11:54:27 +0200
From: Jean-Marc Desperrier <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.1pre) Gecko/20090717 SeaMonkey/2.0b1pre
MIME-Version: 1.0
To: [e-mail]
Subject: Re: RFC5280 : Applications and CRL DP extension support
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ACL-Warn: 1/1 recipients OK.
Sender: [e-mail]
Precedence: 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:
> When a CRLDP is present in a certificate and an Issuing Distribution point
> extension is present in the CRL, them the distribution points of these
> extensions MUST match as defined in section 5.2.5 of RFC 5280.

Yes, of course, but if support of CRLDP is only really required in that 
meaning, then there's a mismatch between the fact that application 
support of CRLDP is recommended, but support of IDP is optional (given 
that IDP  MUST be critical):

    4.2.1.13.  CRL Distribution Points
    [...] this profile
    RECOMMENDS support for this extension by CAs and applications.

    5.2.5.  Issuing Distribution Point
    [...] conforming implementations are not required to support
    this extension

Maybe the RECOMMENDS for CRL DP should best be read as meaning that the 
application SHOULD be able to parse and make the info available to the 
user ?



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6K97KFp016603 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Jul 2009 02:07:20 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6K97JAF016601; Mon, 20 Jul 2009 02:07: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 n6K97HFT016581 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 20 Jul 2009 02:07:18 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 75660 invoked from network); 20 Jul 2009 09:07:18 -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]>; 20 Jul 2009 09:07:18 -0000
Received: (qmail 66780 invoked from network); 20 Jul 2009 09:07:15 -0000
Received: from 213-64-142-97-no153.business.telia.com (HELO [192.168.1.6]) ([e-mail]@[213.64.142.97]) (envelope-sender <[e-mail]>) by s19.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <[e-mail]>; 20 Jul 2009 09:07:15 -0000
User-Agent: Microsoft-Entourage/12.19.0.090515
Date: Mon, 20 Jul 2009 11:07:10 +0200
Subject: Re: Relieving CAs of 'ultimate responsibility' [was: Way forward - updating RFC 3161]
From: Stefan Santesson <[e-mail]>
To: Peter Gutmann <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Message-ID: <[e-mail]>
Thread-Topic: Relieving CAs of 'ultimate responsibility' [was: Way forward - updating RFC 3161]
Thread-Index: AcoJGXZ5unOtMj/hdEiyCunU9zF6ag==
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,

Could you then give me the "sales pitch on a T-shirt" version of this.

I'm reading the PK Superstructure document and can only find philosophical
differences but no technical ones, except for a critical extension which
meaning and purpose is unclear to me.

/Stefan

On 09-07-20 10:54 AM, "Peter Gutmann" <[e-mail]> wrote:

> 
> Yoav Nir <[e-mail]> writes:
> 
>> Stephen is right, it really is much like passports or cheques. There's all
>> sorts of security considerations about printing them, but the hard part is
>> the government or banks deciding to actually take the responsibility for the
>> issuing process.
> 
> Yup, that's what I was trying to point out, everyone wants to be the CA and
> collect the money, no-one wants to take responsibility (except in closed
> communities where you internalise the risk, and then have the luxury of being
> able to run things any way you like because of it).
> 
> 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 n6K8shAx015715 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Jul 2009 01:54:44 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6K8shgq015714; Mon, 20 Jul 2009 01:54:43 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mailhost.auckland.ac.nz (larry.its.auckland.ac.nz [130.216.12.34]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6K8sWOF015698 for <[e-mail]>; Mon, 20 Jul 2009 01:54:43 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id D5A9B41431E; Mon, 20 Jul 2009 20:54:30 +1200 (NZST)
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (larry.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fGYrLTpzAtzW; Mon, 20 Jul 2009 20:54:30 +1200 (NZST)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 925BB4142C7; Mon, 20 Jul 2009 20:54:30 +1200 (NZST)
Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 8320719F4003; Mon, 20 Jul 2009 20:54:29 +1200 (NZST)
Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from <[e-mail]>) id 1MSodh-0007MV-CS; Mon, 20 Jul 2009 20:54:29 +1200
From: Peter Gutmann <[e-mail]>
To: [e-mail], [e-mail], [e-mail], [e-mail]
Subject: RE: Relieving CAs of 'ultimate responsibility' [was: Way forward - updating RFC 3161]
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
Date: Mon, 20 Jul 2009 20:54:29 +1200
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Yoav Nir <[e-mail]> writes:

>Stephen is right, it really is much like passports or cheques. There's all
>sorts of security considerations about printing them, but the hard part is
>the government or banks deciding to actually take the responsibility for the
>issuing process.

Yup, that's what I was trying to point out, everyone wants to be the CA and
collect the money, no-one wants to take responsibility (except in closed
communities where you internalise the risk, and then have the luxury of being
able to run things any way you like because of it).

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 n6K8Qg06014270 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Jul 2009 01:26:42 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6K8Qgx9014269; Mon, 20 Jul 2009 01:26:42 -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 n6K8QdTw014261 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 20 Jul 2009 01:26:41 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 21775 invoked from network); 20 Jul 2009 08:26:41 -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 Jul 2009 08:26:41 -0000
Received: (qmail 92928 invoked from network); 20 Jul 2009 08:26:38 -0000
Received: from 213-64-142-97-no153.business.telia.com (HELO [192.168.1.6]) ([e-mail]@[213.64.142.97]) (envelope-sender <[e-mail]>) by s24.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <[e-mail]>; 20 Jul 2009 08:26:38 -0000
User-Agent: Microsoft-Entourage/12.19.0.090515
Date: Mon, 20 Jul 2009 10:26:37 +0200
Subject: Re: Relieving CAs of 'ultimate responsibility' 
From: Stefan Santesson <[e-mail]>
To: Stefan Santesson <[e-mail]>, Stephen Wilson <[e-mail]>, <[e-mail]>
Message-ID: <[e-mail]>
Thread-Topic: Relieving CAs of 'ultimate responsibility' 
Thread-Index: AcoJCbBC4bFJdk/+CUyf5DDm4FX/KwAChwJm
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>

My apologies for the .exe file comment.
At a closer look it appears to be a legal pdf, but the way you link to your
documents seems a bit odd as the link doesn't reveal the file type at all.

When clicking the link from a Mac OS using safari, it downloads as an .exe
file which isn't very nice. You should look into that.

/Stefan


On 09-07-20 9:14 AM, "Stefan Santesson" <[e-mail]> wrote:

> 
> Stephen,
> 
> Sorry for bringing a negative touch, but I think your mails looks more like
> sales pitch for your company's business agenda than creative proposal on PKI
> protocol development.
> 
> You may implement whatever model of administration around certificates and
> their issuance as you like. They are still signed by the CA's key which
> makes them a statement by the CA. Unlike cheques, certificates can't have
> information added to the after issuance/signing.That does not mean that the
> CA have to accept any liability for their use.
> 
> Finally, I'm even more puzzled when a company claiming to be in the security
> business, suggests other security expert to download their whitepapers, that
> turns out to be an .exe file.
> 
> Whatever it is, it will not execute on my computer.
> 
> /Stefan
> 
> 
> On 09-07-20 4:45 AM, "Stephen Wilson" <[e-mail]> wrote:
> 
>> 
>> 
>> 
>> Peter Gutmann wrote:
>>> Stephen Wilson <[e-mail]> writes:
>>>> But there is a way to relieve CAs of many risks, and at the same time
>>>> simplify the legal principles, the user agreements and the PKI business
>>>> model: treat the CA like a Security Printer. Like a cheque printer, a CA
>>>> should only be responsible for the quality of the certificates (cheques)
>>>> but
>>>> not their content.
>>>> 
>>>> http://www.lockstep.com.au/library/pki/the_security_printer_model_fo.
>>> 
>>> Hmm, interesting perspective.  However, if this is implemented, can I put
>>> down my name to be the certificate vending machine?  Someone else (handwave)
>>> can be the RA.
>>> 
>>> Peter.
>> I think the sarcasm is misplaced.
>> 
>> Running a CA or a cheque printer is tougher than running a vending
>> machine.  The Security Printer model still requires a multi million
>> dollar investment in facilities security, Commion Criteria certified
>> systems, trusted personnel and so on.  And it's not a licence to print
>> money -- these should be high volume, low margin businesses.  I was
>> asked a question from the audience at an Asia PKI Forum conference once
>> how many CAs I thought were needed in the world, and I said "about three
>> or four".
>> 
>> Picking RAs is not a hand waving exercise.  In most cases, the choice of
>> RA is logical and transparent: medical registration boards, licensing
>> bodies, employers, professional associations etc.
>> 
>> This view of PKI holds that digital cerificates are best used to
>> automate transactions between parties that already recognise one
>> anothers' qualifications (and who therefore already have risk mitigation
>> arrangements in place, like professional indemnity schemes).  Therefore
>> certificates should be issued by existing credentialling authorities
>> (the RAs), and minted by specialist wholesale CAs.  There are other
>> precedents for this type of model, like bank card production.  We have
>> many many banks, issuing many many card products, but only a few large
>> scale card personalisation bureaus.
>> 
>> In this way, the meaningfulness of certificates vests in existing
>> recognised bodies.  All the traditionally intractable problems of PKI
>> disappear (like certificate cross-recognition, because in commerce and
>> the professions we have ways of recognising credentials issued by
>> cross-border RAs).
>> 
>> See also http://www.lockstep.com.au/library/pki/public_key_superstructure
>> 
>> To move to the Security Printer paradigm requires we give up a few of
>> the long standing PKI ambitions, like the dream of stranger-to-stranger
>> e-commerce, and the dream of a one-size-fits-all multipurpose digital
>> certificate. 
>> 
>> Cheers,
>> 
>> Stephen Wilson
>> Lockstep
>> www.lockstep.com.au
>> 
> 
> 




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6K7Ebi1009676 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Jul 2009 00:14:37 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6K7Ebjb009675; Mon, 20 Jul 2009 00:14:37 -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 n6K7ELN2009638 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 20 Jul 2009 00:14:34 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 40579 invoked from network); 20 Jul 2009 07:14:23 -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 Jul 2009 07:14:23 -0000
Received: (qmail 24237 invoked from network); 20 Jul 2009 07:14:20 -0000
Received: from 213-64-142-97-no153.business.telia.com (HELO [192.168.1.6]) ([e-mail]@[213.64.142.97]) (envelope-sender <[e-mail]>) by s24.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <[e-mail]>; 20 Jul 2009 07:14:20 -0000
User-Agent: Microsoft-Entourage/12.19.0.090515
Date: Mon, 20 Jul 2009 09:14:15 +0200
Subject: Re: Relieving CAs of 'ultimate responsibility' 
From: Stefan Santesson <[e-mail]>
To: Stephen Wilson <[e-mail]>, <[e-mail]>
Message-ID: <[e-mail]>
Thread-Topic: Relieving CAs of 'ultimate responsibility' 
Thread-Index: AcoJCbBC4bFJdk/+CUyf5DDm4FX/Kw==
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>

Stephen,

Sorry for bringing a negative touch, but I think your mails looks more like
sales pitch for your company's business agenda than creative proposal on PKI
protocol development.

You may implement whatever model of administration around certificates and
their issuance as you like. They are still signed by the CA's key which
makes them a statement by the CA. Unlike cheques, certificates can't have
information added to the after issuance/signing.That does not mean that the
CA have to accept any liability for their use.

Finally, I'm even more puzzled when a company claiming to be in the security
business, suggests other security expert to download their whitepapers, that
turns out to be an .exe file.

Whatever it is, it will not execute on my computer.

/Stefan


On 09-07-20 4:45 AM, "Stephen Wilson" <[e-mail]> wrote:

> 
> 
> 
> Peter Gutmann wrote:
>> Stephen Wilson <[e-mail]> writes:
>>> But there is a way to relieve CAs of many risks, and at the same time
>>> simplify the legal principles, the user agreements and the PKI business
>>> model: treat the CA like a Security Printer. Like a cheque printer, a CA
>>> should only be responsible for the quality of the certificates (cheques) but
>>> not their content.
>>> 
>>> http://www.lockstep.com.au/library/pki/the_security_printer_model_fo.
>> 
>> Hmm, interesting perspective.  However, if this is implemented, can I put
>> down my name to be the certificate vending machine?  Someone else (handwave)
>> can be the RA.
>> 
>> Peter.
> I think the sarcasm is misplaced.
> 
> Running a CA or a cheque printer is tougher than running a vending
> machine.  The Security Printer model still requires a multi million
> dollar investment in facilities security, Commion Criteria certified
> systems, trusted personnel and so on.  And it's not a licence to print
> money -- these should be high volume, low margin businesses.  I was
> asked a question from the audience at an Asia PKI Forum conference once
> how many CAs I thought were needed in the world, and I said "about three
> or four".
> 
> Picking RAs is not a hand waving exercise.  In most cases, the choice of
> RA is logical and transparent: medical registration boards, licensing
> bodies, employers, professional associations etc.
> 
> This view of PKI holds that digital cerificates are best used to
> automate transactions between parties that already recognise one
> anothers' qualifications (and who therefore already have risk mitigation
> arrangements in place, like professional indemnity schemes).  Therefore
> certificates should be issued by existing credentialling authorities
> (the RAs), and minted by specialist wholesale CAs.  There are other
> precedents for this type of model, like bank card production.  We have
> many many banks, issuing many many card products, but only a few large
> scale card personalisation bureaus.
> 
> In this way, the meaningfulness of certificates vests in existing
> recognised bodies.  All the traditionally intractable problems of PKI
> disappear (like certificate cross-recognition, because in commerce and
> the professions we have ways of recognising credentials issued by
> cross-border RAs).
> 
> See also http://www.lockstep.com.au/library/pki/public_key_superstructure
> 
> To move to the Security Printer paradigm requires we give up a few of
> the long standing PKI ambitions, like the dream of stranger-to-stranger
> e-commerce, and the dream of a one-size-fits-all multipurpose digital
> certificate. 
> 
> Cheers,
> 
> Stephen Wilson
> Lockstep
> www.lockstep.com.au
> 




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6K4Yjow001025 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 19 Jul 2009 21:34:45 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6K4YjY2001024; Sun, 19 Jul 2009 21:34:45 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6K4YWa8001013 for <[e-mail]>; Sun, 19 Jul 2009 21:34:43 -0700 (MST) (envelope-from [e-mail])
Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 1F5F8200E06; Mon, 20 Jul 2009 07:34:47 +0300 (IDT)
Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id DB87820041C; Mon, 20 Jul 2009 07:34:46 +0300 (IDT)
X-CheckPoint: {4A63F2EC-0-14201DC2-1FFFF}
Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n6K4YU3d001665; Mon, 20 Jul 2009 07:34:31 +0300 (IDT)
Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Mon, 20 Jul 2009 07:34:30 +0300
From: Yoav Nir <[e-mail]>
To: "'Peter Gutmann'" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Date: Mon, 20 Jul 2009 07:34:28 +0300
Subject: RE: Relieving CAs of 'ultimate responsibility' [was: Way forward - updating RFC 3161]
Thread-Topic: Relieving CAs of 'ultimate responsibility' [was: Way forward - updating RFC 3161]
Thread-Index: AcoI37ZzgAcigqFNT7OOwSGBOOObrAAEDiLQ
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter Gutmann wrote:

>Stephen Wilson <[e-mail]> writes:
>
>>But there is a way to relieve CAs of many risks, and at the same time
>>simplify the legal principles, the user agreements and the PKI business
>>model: treat the CA like a Security Printer. Like a cheque printer, a CA
>>should only be responsible for the quality of the certificates (cheques) =
>but
>>not their content.
>>
>>See http://www.lockstep.com.au/library/pki/the_security_printer_model_fo.
>
>Hmm, interesting perspective.  However, if this is implemented, can I put =
>down my name to be the certificate vending machine?  Someone else=20
>(handwave) can be
>the RA.
>

I think under that model, you end up with some kind of statutory authority =
to be the RA, so I guess those commercial certificates would come from some=
 ministry of industry, trade and silly walks, with the CA just providing a =
service under contract to the government.

This sounds great, but so far no government that I know of has taken it upo=
n itself to issue certificates to businesses, and few have done so for the =
citizens. If they had wanted to, then setting up a CA to actually sign blob=
s is cheap enough that it wouldn't be an issue.

Stephen is right, it really is much like passports or cheques. There's all =
sorts of security considerations about printing them, but the hard part is =
the government or banks deciding to actually take the responsibility for th=
e issuing process. I don't see that happening in the contexts discussed on =
PKIX.


Email secured by Check Point



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6K2kMrk095405 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 19 Jul 2009 19:46:22 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6K2kMRE095404; Sun, 19 Jul 2009 19:46:22 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp222.iad.emailsrvr.com (smtp222.iad.emailsrvr.com [207.97.245.222]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6K2kBU7095388 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Sun, 19 Jul 2009 19:46:22 -0700 (MST) (envelope-from [e-mail])
Received: from relay12.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay12.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id 1A0DF2030DC for <[e-mail]>; Sun, 19 Jul 2009 22:46:11 -0400 (EDT)
Received: by relay12.relay.iad.mlsrvr.com (Authenticated sender: swilson-AT-lockstep.com.au) with ESMTPA id 01FEA202DD2 for <[e-mail]>; Sun, 19 Jul 2009 22:46:08 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Mon, 20 Jul 2009 12:45:56 +1000
From: Stephen Wilson <[e-mail]>
User-Agent: Thunderbird 2.0.0.22 (Windows/20090605)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Relieving CAs of 'ultimate responsibility' 
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>

Peter Gutmann wrote:
> Stephen Wilson <[e-mail]> writes:
>> But there is a way to relieve CAs of many risks, and at the same time
>> simplify the legal principles, the user agreements and the PKI business model: treat the CA like a Security Printer. Like a cheque printer, a CA should only be responsible for the quality of the certificates (cheques) but not their content.
>>
>> http://www.lockstep.com.au/library/pki/the_security_printer_model_fo.
>
> Hmm, interesting perspective.  However, if this is implemented, can I put down my name to be the certificate vending machine?  Someone else (handwave) can be the RA.
>
> Peter.
I think the sarcasm is misplaced.

Running a CA or a cheque printer is tougher than running a vending 
machine.  The Security Printer model still requires a multi million 
dollar investment in facilities security, Commion Criteria certified 
systems, trusted personnel and so on.  And it's not a licence to print 
money -- these should be high volume, low margin businesses.  I was 
asked a question from the audience at an Asia PKI Forum conference once 
how many CAs I thought were needed in the world, and I said "about three 
or four".

Picking RAs is not a hand waving exercise.  In most cases, the choice of 
RA is logical and transparent: medical registration boards, licensing 
bodies, employers, professional associations etc.  

This view of PKI holds that digital cerificates are best used to 
automate transactions between parties that already recognise one 
anothers' qualifications (and who therefore already have risk mitigation 
arrangements in place, like professional indemnity schemes).  Therefore 
certificates should be issued by existing credentialling authorities 
(the RAs), and minted by specialist wholesale CAs.  There are other 
precedents for this type of model, like bank card production.  We have 
many many banks, issuing many many card products, but only a few large 
scale card personalisation bureaus.

In this way, the meaningfulness of certificates vests in existing 
recognised bodies.  All the traditionally intractable problems of PKI 
disappear (like certificate cross-recognition, because in commerce and 
the professions we have ways of recognising credentials issued by 
cross-border RAs).

See also http://www.lockstep.com.au/library/pki/public_key_superstructure

To move to the Security Printer paradigm requires we give up a few of 
the long standing PKI ambitions, like the dream of stranger-to-stranger 
e-commerce, and the dream of a one-size-fits-all multipurpose digital 
certificate. 

Cheers,

Stephen Wilson
Lockstep
www.lockstep.com.au



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6K22V2i092549 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 19 Jul 2009 19: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 n6K22VTC092548; Sun, 19 Jul 2009 19: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 mailhost.auckland.ac.nz (moe.its.auckland.ac.nz [130.216.12.35]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6K22IeR092538 for <[e-mail]>; Sun, 19 Jul 2009 19:02:30 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id D3B2A1892A4; Mon, 20 Jul 2009 14:02:17 +1200 (NZST)
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (moe.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hJ6OyGmyHn2K; Mon, 20 Jul 2009 14:02:17 +1200 (NZST)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 6F2B0172B52; Mon, 20 Jul 2009 14:02:15 +1200 (NZST)
Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 470351DE4001; Mon, 20 Jul 2009 14:02:14 +1200 (NZST)
Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from <[e-mail]>) id 1MSiCk-0003g0-4g; Mon, 20 Jul 2009 14:02:14 +1200
From: Peter Gutmann <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Relieving CAs of 'ultimate responsibility' [was: Way forward - updating RFC 3161]
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
Date: Mon, 20 Jul 2009 14:02:14 +1200
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stephen Wilson <[e-mail]> writes:

>But there is a way to relieve CAs of many risks, and at the same time
>simplify the legal principles, the user agreements and the PKI business
>model: treat the CA like a Security Printer. Like a cheque printer, a CA
>should only be responsible for the quality of the certificates (cheques) but
>not their content.
>
>See http://www.lockstep.com.au/library/pki/the_security_printer_model_fo.

Hmm, interesting perspective.  However, if this is implemented, can I put down
my name to be the certificate vending machine?  Someone else (handwave) can be
the RA.

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 n6JNKb51084927 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 19 Jul 2009 16:20:37 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6JNKb8s084926; Sun, 19 Jul 2009 16:20:37 -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 n6JNKN7V084907 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Sun, 19 Jul 2009 16:20:35 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 13776 invoked from network); 19 Jul 2009 23:20:31 -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]>; 19 Jul 2009 23:20:31 -0000
Received: (qmail 49389 invoked from network); 19 Jul 2009 23:20:22 -0000
Received: from 213-64-142-97-no153.business.telia.com (HELO [192.168.1.6]) ([e-mail]@[213.64.142.97]) (envelope-sender <[e-mail]>) by s24.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <[e-mail]>; 19 Jul 2009 23:20:22 -0000
User-Agent: Microsoft-Entourage/12.19.0.090515
Date: Mon, 20 Jul 2009 01:20:16 +0200
Subject: Re: RFC5280 : Applications and CRL DP extension support
From: Stefan Santesson <[e-mail]>
To: Santosh Chokhani <[e-mail]>, Jean-Marc Desperrier <[e-mail]>, <[e-mail]>
Message-ID: <[e-mail]>
Thread-Topic: RFC5280 : Applications and CRL DP extension support
Thread-Index: AcoIfIL7ycjqV27dEEm7UtMVJllHhwACC5qgABCx+nc=
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>

Santosh,

Agreeing and I don't think our observations are in conflict.
You need to make sure both that you cover all relevant scopes as well as the
CRLs you are using matches the certificate you validate. I was only
addressing the latter.

/Stefan

On 09-07-19 5:24 PM, "Santosh Chokhani" <[e-mail]> wrote:

> Stefan,
> 
> The imprecision in the statement below can lead to security problem.  If
> IDP is present in a CRL with DP in the IDP, even if there is no CRL DP
> in the certificate, that CRL with DP in IDP can not be used by relying
> parties since whether the CRL covers the scope of the certificate or
> not, is unknown.
> 
>> -----Original Message-----
>> From: [e-mail]
>> [mailto:[e-mail]] On Behalf Of Stefan Santesson
>> Sent: Sunday, July 19, 2009 10:24 AM
>> To: Jean-Marc Desperrier; [e-mail]
>> Subject: Re: RFC5280 : Applications and CRL DP extension support
>> 
>> 
>> Jean,
>> 
>> An aspect of this often forgotten is that a major practical
>> function of the CRLDP is to act as an identifier used to
>> match the certificate and the CRL.
>> 
>> When a CRLDP is present in a certificate and an Issuing
>> Distribution point extension is present in the CRL, them the
>> distribution points of these extensions MUST match as defined
>> in section 5.2.5 of RFC 5280.
>> 
>> As far as I recall, there are no requirements that the
>> location stated in the CRLDP need to be used to obtain the CRL.
>> 
>> The URL stated in CDP may further be relative (and refer the
>> relying party to the resource on the local network).
>> 
>> /Stefan.
>> 
>> 
>> On 09-07-15 4:02 PM, "Jean-Marc Desperrier" <[e-mail]> wrote:
>> 
>>> 
>>> The text of RFC5280 says :
>>> 4.2.1.14 CRL Distribution Points
>>>      [...] this profile
>>>      recommends support for this extension by CAs and applications.
>>> 
>>> Whilst I 100% approve the recommendation for CAs (No CA
>> should issue 
>>> certificates without CRLDP when they do provide CRL), what
>> does it in 
>>> practice mean for applications ?
>>> 
>>> They are cases where dynamically  downloading the CRL by
>> interpreting 
>>> the CRL DP extension is inappropriate for some
>> applications, and where
>>> the needs and context of the application make it much more
>> adequate to 
>>> instead to configure in advance the location where the CRL of the
>>> supported CAs can be found.
>>> 
>>> Some examples  :
>>> - Closed networks : Network access to the open internet and
>> the CRL DP 
>>> might be simply unavailable, and the application should get
>> CRLs from 
>>> copies made at alternative locations on the local network.
>>> - Controled network : Even if no alternative local location is
>>> provided, network rules may forbid network  access that has
>> not been 
>>> vetted beforehand, so make it inappropriate if the
>> application tries
>>> to download data from a location based on the information
>> contained in 
>>> any the certificate it just received
>>> - Performance : When the application has to validate a hich
>> volume of 
>>> certificates, dynamic loading of the CRL is simply
>> inappropriate. This
>>> can be worked around by using caching mechanisms, but it
>> will be more 
>>> adequate to use configuration particularly if the
>> application already
>>> configures rules about how often to download new CRLs (CRLS quite
>>> often are renewed more frequently than their nextUpdate
>> field signals, 
>>> some CA renew their CRL every day, but have a nextUpdate
>> filed valid for one week).
>>> 
>>> So whilst it's very useful to have the CA include the information
>>> inside the certificate, I think the standard should not try to
>>> constrain the methods by which the application will get it's up to
>>> date revocation info, or make it clearer that the use of
>> alternates is 
>>> appropriate when they will give the same result.
>>> 
>>> Can I have confirmation from the group that the text in RFC5280 is
>>> *not* intended to discourage applications under such circumstances
>>> from using configuration settings instead of dynamically
>> reading the 
>>> CRL DP extension content  ?
>>> 
>>> 
>> 
>> 
>> 




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6JKePNN077123 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 19 Jul 2009 13:40:25 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6JKePAH077122; Sun, 19 Jul 2009 13:40:25 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp232.iad.emailsrvr.com (smtp232.iad.emailsrvr.com [207.97.245.232]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6JKeEwT077109 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Sun, 19 Jul 2009 13:40:24 -0700 (MST) (envelope-from [e-mail])
Received: from relay13.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay13.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id CB0911CC8EE for <[e-mail]>; Sun, 19 Jul 2009 16:40:13 -0400 (EDT)
Received: by relay13.relay.iad.mlsrvr.com (Authenticated sender: swilson-AT-lockstep.com.au) with ESMTPA id 175141CC946 for <[e-mail]>; Sun, 19 Jul 2009 16:40:12 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Mon, 20 Jul 2009 06:40:03 +1000
From: Stephen Wilson <[e-mail]>
User-Agent: Thunderbird 2.0.0.22 (Windows/20090605)
MIME-Version: 1.0
To: ietf-pkix <[e-mail]>
Subject: Relieving CAs of 'ultimate responsibility' [was: Way forward - updating RFC 3161] 
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=windows-1252; 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>

Stefan Santesson wrote:
>
> Note that we have a very similar [role separation] situation with PKI. 
> The CA issues certificates, but in practice the CA will delegate the 
> signing to a “unit” and may delegate authorization of attributes to 
> “Registration Authority”. Still, the CA is ultimately the responsible 
> party and not any “unit” or other subordinate entity or process.
Ultimately, the CA is responsible for what exactly? In orthodox PKI, the 
CA is responsible for everything, and hence we got ourselves into a 
quagmire of unwieldy thick CPs, legal agreements and untold risks. This 
despite the fact that most liabilities arise in mis-registration.

But there is a way to relieve CAs of many risks, and at the same time 
simplify the legal principles, the user agreements and the PKI business 
model: treat the CA like a Security Printer. Like a cheque printer, a CA 
should only be responsible for the quality of the certificates (cheques) 
but not their content.

See http://www.lockstep.com.au/library/pki/the_security_printer_model_fo.

Cheers,

Stephen Wilson
Managing Director
Lockstep Group

Phone [phone]

www.lockstep.com.au <http://www.lockstep.com.au>
-------------------
Lockstep Consulting provides independent specialist advice and analysis
on digital identity and privacy. Lockstep Technologies develops unique
new smart ID solutions that enhance privacy and prevent identity theft.
-----------------------------------------------------------------------
* Finextra Innovation Showcase 2009
* ABC TV 'The New Inventors' Nov 2008
* Global Security Challenge Asia Top Five 2008
* Australian Technology Showcase 2008
* AusIndustry COMET Grant 2007





Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6JHQgll065858 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 19 Jul 2009 10:26:42 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6JHQgda065857; Sun, 19 Jul 2009 10:26:42 -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 n6JHQfRo065850 for <[e-mail]>; Sun, 19 Jul 2009 10:26:41 -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 CDA8177; Sun, 19 Jul 2009 19:26:20 +0200 (CEST)
Received: from smtps.on-x.com (mintaka.puteaux.on-x [192.168.14.11]) by varuna.puteaux.on-x (Postfix) with ESMTP id 8B02417048; Sun, 19 Jul 2009 19:26:20 +0200 (CEST)
Received: from [192.168.0.12] (gut75-3-82-227-163-182.fbx.proxad.net [82.227.163.182]) by smtps.on-x.com (Postfix) with ESMTP id 711827877; Sun, 19 Jul 2009 19:26:20 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Sun, 19 Jul 2009 19:26:18 +0200
From: Peter Sylvester <[e-mail]>
User-Agent: Thunderbird 2.0.0.22 (X11/20090608)
MIME-Version: 1.0
To: Russ Housley <[e-mail]>
Cc: ietf-pkix <[e-mail]>
Subject: Re: Way forward - updating RFC 3161
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>

Russ Housley wrote:
>
>
>>     No doubt that everybody agrees that RFC 3161 should be updated to
>>     allow the use of RFC 5035 [ESSV2].
>
> I agree that this change is desirable to support the smooth transition 
> to bigger hash values than SHA-1.
>
> Russ
>
To be sure: You didn't say whether you think it would be necessary
or useful to have bigger hash values thta sha-1, i.e.
to implement  "the smooth transition" in this case.

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 n6JHMJti065529 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 19 Jul 2009 10:22:19 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6JHMJQ4065528; Sun, 19 Jul 2009 10:22:19 -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 n6JHM7Xn065497 for <[e-mail]>; Sun, 19 Jul 2009 10:22:18 -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 DD6A877; Sun, 19 Jul 2009 19:21:46 +0200 (CEST)
Received: from smtps.on-x.com (mintaka.puteaux.on-x [192.168.14.11]) by varuna.puteaux.on-x (Postfix) with ESMTP id 9CA0617048; Sun, 19 Jul 2009 19:21:46 +0200 (CEST)
Received: from [192.168.0.12] (gut75-3-82-227-163-182.fbx.proxad.net [82.227.163.182]) by smtps.on-x.com (Postfix) with ESMTP id 0B7407877; Sun, 19 Jul 2009 19:21:45 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Sun, 19 Jul 2009 19:21:45 +0200
From: Peter Sylvester <[e-mail]>
User-Agent: Thunderbird 2.0.0.22 (X11/20090608)
MIME-Version: 1.0
To: Stefan Santesson <[e-mail]>
Cc: [e-mail], ietf-pkix <[e-mail]>
Subject: Re: Way forward - updating RFC 3161
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/alternative; boundary="------------060806020509080603090304"
Sender: [e-mail]
Precedence: 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.
--------------060806020509080603090304
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


>
>     No doubt that everybody agrees that RFC 3161 should be updated to
>     allow the use of RFC 5035 [ESSV2].
>
It doesn't harm to optionally allow essv2.
That doesn't mean that one should remove the existing signed attribute.
>
>     The question is whether other changes should also be made.
>
>     The major differences from RFC 3161 [RFC3161] are summarized on
>     page 3 of the draft and are listed below:
>
>          1 - the document has been aligned with RFC 3628 to make the
>              difference between a time-stamping unit (TSU) and a TSA.
>
rfc 3628 is an informational rfc. It may be useful to consider a TSU, but
this is not required. although 3161 may be confusing for some, but
not more than those that use the term "CA" for many different things,
in all cases, the 3161 text doesn't seem to require any change imo.
It is sufficiently clear imo whether one talks about a technical entity,
a signing device, or some organisational entity.
>
>
>          2 - the document makes the difference between a time-stamping
>              service and a time-stamping unit and allows a time-stamping
>              service to support more than one time-stamping unit.
>
as an organisation or a operator, a "CA" may operate several HSMs etc etc,
there is no difference. It is even an unnecessary overspecification.
>
>
>          3 - the format of the subject field of a TSU certificate is now
>              defined.
>
And confusion with the "tsa" field in tstinfo added.
>
>
>     and also some minor updates :
>
>          4 - informative references to ISO 18014-1 [ISO18014-1],
>              ISO 18014-2 [ISO18014-2] and ISO 18014-3 [ISO18014-3]
>     have been
>              added.
>
>          5 - a new normative ASN1 module to refer to the ASN.1 modules
>              from the latest RFCs.
>
Whow, that indeed very important.
>
>
>     At the moment, RFC 3161 makes confusion between three different
>     concepts:
>     a TSA, a TSS and a TSU, respectively a Time-Stamping Authority,
>     a Time-Stamping Service and a Time-Stamping Unit.
>
No, it doesn't.
>
>
>     IMO, the document should be cleaned to call a spade a spade.
>
others don't seem to share this.
>
>
>     Historically, the notions applicable to TSAs have been copied and
>     pasted
>     from the documents related to CAs. Since a CA had one private key,
>     a TSA
>     had one private key as well, but this was short looking.
>
a ca had only one key? since when? what you describe for a tsa, can as 
well apply
to a CA, using several HSMs in parallel which are clones and maybe operated
in different places.
>
>
>     The CA advertises one public key, or more exactly one trust
>     anchor, usually
>     by issuing a self-signed certificate. This private key, when in use,
>     is supported by one HSH (Hardware Security Module). This private
>     key needs
>     to be saved in order to be restored in case of a problem. The time
>     for restoration
>     is usually not critical (this may take a few minutes or even a few
>     hours).
>     The life time of a CA certificate (or CA public key) is usually
>     between one and
>     15 years and should not be changed earlier, unless strictly needed.
>
I am not sure what you mean by CA here.
>
>
>     In order to provide time-stamp tokens (TSTs) with high
>     availability, more than
>     one TSU is usually needed. These units altogether provide a TSS
>     (Time-Stamping Service)
>     that is managed by an Authority called a TSA (Time-Stamping
>     Authority).
>
That' a possible way to describe or organise these things, but not the 
only one.
Ambiguous or slightly misused wording is well known in this field,
the major example being 'certificate'.

>
>     The key used to sign TSTs is not the key from a TSA, but the key
>     from a TSU.
>
IMO  'the key from a TSA/U' is not a sufficiently well defined
definition to make a distinction.

>
>     In order to a high level of security, the key used to sign to TSTs
>     should NOT be saved
>     and restored. It should be generated by the TSU itself and should
>     NOT be exported
>     outside the TSU. If the key of the TSU is erased purposely or by
>     accident, a new key pair
>     and certificate should be generated. 
>
Whether done or not, none of this has an impact to the protocol.
(To be clear, I do not comment on what you wrote).
 
>
>     Since TSU certificates are provided by a CA,
>     TST verification systems do not need to change any trust anchor.
>     Some TSUs may even
>     use short-lived TSU certificates, e.g. a TSU certificate valid for
>     one week or even one day.
>
and, where is the beef?
>
>
>     However, it is necessary to be able to know the name of the TSA
>     when looking at the
>     subject DN from the TSU certificate.
>
for what purpose, and, in fact, that's the point which is bad in the 
draft, what is the
name of (your definition of) the tsa when you look at the subject dn?
>
>
>     Along these lines, several changes should be made to RFC 3161. To
>     mention a few of them:
>
>     RFC 3161:
>       If the TSA does not recognize the hash
>       algorithm or knows that the hash algorithm is weak (a decision left
>       to the discretion of each individual TSA), then the TSA SHOULD
>     refuse
>       to provide the time-stamp token by returning a pkiStatusInfo of
>       'bad_alg'.
>
>     Proposed change :
>       If the TSS does not recognize the hash
>       algorithm or knows that the hash algorithm is weak (a decision left
>         to the discretion of each individual TSA), then the TSS SHOULD
>     refuse
>       to provide the time-stamp token by returning a pkiStatusInfo of
>       'bad_alg'.
>
any of your three meanings of tsu, tss, tsa applies to the text. The tsa 
takes the
resonsibility, the tss as a global service deliveres what one of the 
tsus create.
>
>
>     RFC3161:
>       The certificate identifier (ESSCertID) of the
>        TSA certificate MUST be included as a signerInfo attribute
>     inside a
>       SigningCertificate attribute.
>
>     Proposed change:
>       The certificate identifier (either ESSCertID  or ESSCertIDv2) of
>     the TSU certificate
>       MUST be included as a signerInfo attribute inside a
>     SigningCertificate attribute.
>
Rejected. The ESSCertId MUST be provided. An ESSCertIDV2 MAY be 
optionally added.
>
>
>     RFC 3161:
>       The serialNumber field is an integer assigned by the TSA to each
>     TimeStampToken.
>
>     Proposed change:
>       The serialNumber field is an integer assigned by the TSU to each
>      TimeStampToken.
>
This seems an overspecification. nothing is wrong, if a global TSA 
concentrator
allocates unique serialnumbers for its backend signing machines.
>
>
>     RFC 3161:
>       genTime is the time at which the time-stamp token has been
>     created by
>      
>       the TSA.
>
>     Proposed change:
>       genTime is the time at which the time-stamp token has been
>     created by
>        the TSU.
>
Idem. In fact, the text could say: Indicates the time that a TSA is 
willing to
assert.
>
>
>     RF3161:
>       The purpose of the tsa field is to give a hint in identifying the
>        name of the TSA.
>
>     Proposed change:
>       The purpose of the tsu field is to give a hint in identifying the
>       name of the TSU.
>
it is unacceptable to change the "name" of a field. although it may be
considered as irrelevant, it makes a difference when you use XER to
display things.

I also recommend Lewis Carroll:  "A hint in identifying a name".

Is this te name, or how you call the name, you a hint for that?

http://www.edelweb.fr/EdelStuff/Prospectus/ibmmail.txt

>
>     Note that the difference between a TSU and a TSA that is already
>     present
>     in RFC 3628 (Informational) is also present in ISO 18014 and in
>     ETSI TS 102 023.
>     All these documents have been issued after RFC 3161.
>
This is not an argument to copy them. There may also be
a reason for RFC 3628 being informational and not standards track.
the "dad, mon has already agreed" argument is more than weak here
>
>
>     Even, if the bits on the wire are the same, the meaning of these bits
>     would not necessarily be the same. For example, the ESSCertID
>     refers to
>     a  certificate from a TSU, not from a TSA.
>
And what does this mean in practice? What is a relying party supposed to do?
where would it get the name of a tsa? Is there a need to change something
at the relying party?

>
>     Since the changes to be done are scattered around the document, a
>     new draft
>     would seem more appropriate, hence why a new draft has been proposed.
>
This we have understood, but none of the changes seem useful or 
necessary, some
even are restrictive  and introduce unnecessary  modification.
>
>
>     From another angle, should we have an update to RFC 3161 or a new
>     draft?
>     An update would have to advantage to keep the magic number 3161
>     that everybody
>     identifies with TSP.
>
I think that was already discussed. no replacement.
>
>
>     In any case, I believe that both the ESSCertIDv2 and the
>     terminology aspects
>     should be addressed to align RFC 3161 with the documents issued
>     after it.
>
I'd recommend to do this in two different texts. ESSCertID2 as the one 
sentence
above.


"ESSCertID2 for RFC 3161".

Abstract

RFC 3161 use esssSigningCert to reference a signing certificat. This
document proposes a potentially cryptographically stronger reference by
using essv2. backward compatibility is ensured.

After the sentence of RFC3161:
  "The certificate identifier (ESSCertID) of the
   TSA certificate MUST be included as a signerInfo attribute inside a
  SigningCertificate attribute."

insert:

"An ESSCertIDV2 MAY be added in order to allow a smooth transition
stronger hash functions."

To be discussed what has to be done by an RP in case of no essv2
(basically no change), or one with an unknown algorithm:
MUST NOT reject a timestamp solely on the base that there is either
no essv2 or the essv2contains an unsupported algorithm.
I hate that phrase. :-)

and :

 "Clarifications on the meaning of the TSA tla"

abstract: RFC 3161 used the tla TSA for different purposes. This text
clarifiesthe different usages and redefines the tla, and introduces
two new tlas in alignment with 3628 etc. No technical change occurs
at the protocol level.

Peter







--------------060806020509080603090304
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
<blockquote cite="mid:[e-mail]" type="cite">
  <blockquote><span><br>
    </span> <span>No doubt that everybody agrees that RFC 3161 should
be updated to allow the use of RFC 5035 [ESSV2]. <br>
    </span></blockquote>
</blockquote>
It doesn't harm to optionally allow essv2. <br>
That doesn't mean that one should remove the existing signed attribute.<br>
<blockquote cite="mid:[e-mail]" type="cite">
  <blockquote><span>The question is whether other changes should also
be made.<br>
    <br>
The major differences from RFC 3161 [RFC3161] are summarized on page 3
of the draft and are listed below:<br>
    <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;1 - the document has been aligned with RFC 3628 to make the <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;difference between a time-stamping unit (TSU) and a TSA.<br>
    </span></blockquote>
</blockquote>
rfc 3628 is an informational rfc. It may be useful to consider a TSU,
but<br>
this is not required. although 3161 may be confusing for some, but<br>
not more than those that use the term "CA" for many different things,<br>
in all cases, the 3161 text doesn't seem to require any change imo.<br>
It is sufficiently clear imo whether one talks about a technical entity,<br>
a signing device, or some organisational entity.<br>
<blockquote cite="mid:[e-mail]" type="cite">
  <blockquote><span><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2 - the document makes the difference between a time-stamping <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;service and a time-stamping unit and allows a time-stamping <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;service to support more than one time-stamping unit.<br>
    </span></blockquote>
</blockquote>
as an organisation or a operator, a "CA" may operate several HSMs etc
etc,<br>
there is no difference. It is even an unnecessary overspecification.<br>
<blockquote cite="mid:[e-mail]" type="cite">
  <blockquote><span><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3 - the format of the subject field of a TSU certificate is now <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;defined.<br>
    </span></blockquote>
</blockquote>
And confusion with the "tsa" field in tstinfo added.<br>
<blockquote cite="mid:[e-mail]" type="cite">
  <blockquote><span><br>
and also some minor updates :<br>
    <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;4 - informative references to ISO 18014-1 [ISO18014-1], <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ISO 18014-2 [ISO18014-2] and ISO 18014-3 [ISO18014-3] have
been <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;added.<br>
    <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;5 - a new normative ASN1 module to refer to the ASN.1 modules <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;from the latest RFCs. <br>
    </span></blockquote>
</blockquote>
Whow, that indeed very important. <br>
<blockquote cite="mid:[e-mail]" type="cite">
  <blockquote><span></span> <span><br>
    </span> <span>At the moment, RFC 3161 makes confusion between
three different concepts: <br>
a TSA, a TSS and a TSU, respectively a Time-Stamping Authority, <br>
a Time-Stamping Service and a Time-Stamping Unit. <br>
    </span></blockquote>
</blockquote>
No, it doesn't. <br>
<blockquote cite="mid:[e-mail]" type="cite">
  <blockquote><span></span> <span> <br>
    </span> <span> IMO, the document should be cleaned to call a spade
a spade.<br>
    </span></blockquote>
</blockquote>
others don't seem to share this.<br>
<blockquote cite="mid:[e-mail]" type="cite">
  <blockquote><span><br>
Historically, the notions applicable to TSAs have been copied and
pasted <br>
from the documents related to CAs. Since a CA had one private key, a
TSA <br>
had one private key as well, but this was short looking.<br>
    </span></blockquote>
</blockquote>
a ca had only one key? since when? what you describe for a tsa, can as
well apply<br>
to a CA, using several HSMs in parallel which are clones and maybe
operated<br>
in different places. <br>
<blockquote cite="mid:[e-mail]" type="cite">
  <blockquote><span><br>
The CA advertises one public key, or more exactly one trust anchor,
usually <br>
by issuing a self-signed certificate. This private key, when in use, <br>
is supported by one HSH (Hardware Security Module). This private key
needs <br>
to be saved in order to be restored in case of a problem. The time for
restoration <br>
is usually not critical (this may take a few minutes or even a few
hours). <br>
The life time of a CA certificate (or CA public key) is usually between
one and <br>
15 years and should not be changed earlier, unless strictly needed.<br>
    </span></blockquote>
</blockquote>
I am not sure what you mean by CA here. <br>
<blockquote cite="mid:[e-mail]" type="cite">
  <blockquote><span><br>
In order to provide time-stamp tokens (TSTs) with high availability,
more than <br>
one TSU is usually needed. These units altogether provide a TSS
(Time-Stamping Service) <br>
that is managed by an Authority called a TSA (Time-Stamping Authority).<br>
    </span></blockquote>
</blockquote>
That' a possible way to describe or organise these things, but not the
only one.<br>
Ambiguous or slightly misused wording is well known in this field,<br>
the major example being 'certificate'.<br>
<br>
<blockquote cite="mid:[e-mail]" type="cite">
  <blockquote><span><br>
The key used to sign TSTs is not the key from a TSA, but the key from a
TSU.<br>
    </span></blockquote>
</blockquote>
IMO&nbsp; 'the key from a TSA/U' is not a sufficiently well defined <br>
definition to make a distinction.<br>
<br>
<blockquote cite="mid:[e-mail]" type="cite">
  <blockquote><span><br>
In order to a high level of security, the key used to sign to TSTs
should NOT be saved <br>
and restored. It should be generated by the TSU itself and should NOT
be exported <br>
outside the TSU. If the key of the TSU is erased purposely or by
accident, a new key pair <br>
and certificate should be generated. </span></blockquote>
</blockquote>
Whether done or not, none of this has an impact to the protocol. <br>
(To be clear, I do not comment on what you wrote).<br>
&nbsp;<br>
<blockquote cite="mid:[e-mail]" type="cite">
  <blockquote><span>Since TSU certificates are provided by a CA, <br>
TST verification systems do not need to change any trust anchor. Some
TSUs may even <br>
use short-lived TSU certificates, e.g. a TSU certificate valid for one
week or even one day.</span></blockquote>
</blockquote>
and, where is the beef?<br>
<blockquote cite="mid:[e-mail]" type="cite">
  <blockquote><span> <br>
However, it is necessary to be able to know the name of the TSA when
looking at the <br>
subject DN from the TSU certificate.<br>
    </span></blockquote>
</blockquote>
for what purpose, and, in fact, that's the point which is bad in the
draft, what is the<br>
name of (your definition of) the tsa when you look at the subject dn? <br>
<blockquote cite="mid:[e-mail]" type="cite">
  <blockquote><span><br>
Along these lines, several changes should be made to RFC 3161. To
mention a few of them:<br>
    <br>
RFC 3161:<br>
    </span> <span> &nbsp;&nbsp;If the TSA does not recognize the hash</span> <span>
    <br>
    </span> <span> &nbsp;&nbsp;algorithm or knows that the hash algorithm is
weak (a decision left</span> <span> <br>
    </span> <span> &nbsp;&nbsp;to the discretion of each individual TSA), then
the TSA SHOULD refuse</span> <span> <br>
    </span> <span> &nbsp;&nbsp;to provide the time-stamp token by returning a
pkiStatusInfo of</span> <span> <br>
    </span> <span> &nbsp;&nbsp;'bad_alg'.<br>
    </span> <span><br>
    </span> <span>Proposed change :<br>
    </span> <span> &nbsp;&nbsp;If the TSS does not recognize the hash</span> <span>
    <br>
    </span> <span> &nbsp;&nbsp;algorithm or knows that the hash algorithm is
weak (a decision left</span> <span> <br>
&nbsp;</span> <span> &nbsp;&nbsp;to the discretion of each individual TSA), then the
TSS SHOULD refuse</span> <span> <br>
    </span> <span> </span> <span> &nbsp;&nbsp;to provide the time-stamp token
by returning a pkiStatusInfo of</span> <span> <br>
    </span> <span> </span> <span> &nbsp;&nbsp;'bad_alg'.<br>
    </span></blockquote>
</blockquote>
any of your three meanings of tsu, tss, tsa applies to the text. The
tsa takes the<br>
resonsibility, the tss as a global service deliveres what one of the
tsus create.<br>
<blockquote cite="mid:[e-mail]" type="cite">
  <blockquote><span></span> <span><br>
    </span> <span>RFC3161:<br>
    </span> <span> &nbsp;&nbsp;The certificate identifier (ESSCertID) of the</span>
    <span> <br>
&nbsp;</span> <span> &nbsp;TSA certificate MUST be included as a signerInfo
attribute inside a</span> <span> <br>
    </span> <span> &nbsp;</span> <span>SigningCertificate attribute.<br>
    <br>
Proposed change:<br>
    </span> <span> &nbsp;&nbsp;The certificate identifier (either ESSCertID &nbsp;or
ESSCertIDv2) of the TSU certificate <br>
&nbsp;&nbsp;MUST be included as a </span> <span>signerInfo attribute inside a
SigningCertificate attribute.<br>
    </span></blockquote>
</blockquote>
Rejected. The ESSCertId MUST be provided. An ESSCertIDV2 MAY be
optionally added.<br>
<blockquote cite="mid:[e-mail]" type="cite">
  <blockquote><span><br>
RFC 3161:<br>
    </span> <span> &nbsp;&nbsp;The serialNumber field is an integer assigned by
the TSA to each</span> <span> <br>
    </span> <span> </span> <span> TimeStampToken.<br>
    <br>
Proposed change: <br>
    </span> <span> &nbsp;&nbsp;The serialNumber field is an integer assigned by
the TSU to each</span> <span> <br>
    </span> <span> </span> <span> &nbsp;TimeStampToken.<br>
    </span></blockquote>
</blockquote>
This seems an overspecification. nothing is wrong, if a global TSA
concentrator<br>
allocates unique serialnumbers for its backend signing machines.<br>
<blockquote cite="mid:[e-mail]" type="cite">
  <blockquote><span></span> <span><br>
    </span> <span>RFC 3161:<br>
    </span> <span> &nbsp;&nbsp;genTime is the time at which the time-stamp token
has been created by</span> <span> <br>
&nbsp;<br>
    </span> <span> &nbsp;&nbsp;the TSA.<br>
    </span> <span><br>
    </span> <span>Proposed change:<br>
    </span> <span> &nbsp;&nbsp;genTime is the time at which the time-stamp token
has been created by</span> <span> <br>
&nbsp;</span> <span> &nbsp;the TSU.<br>
    </span></blockquote>
</blockquote>
Idem. In fact, the text could say: Indicates the time that a TSA is
willing to<br>
assert. <br>
<blockquote cite="mid:[e-mail]" type="cite">
  <blockquote><span></span> <span><br>
    </span> <span>RF3161:<br>
    </span> <span> &nbsp;&nbsp;The purpose of the tsa field is to give a hint in
identifying the</span> <span> <br>
&nbsp;</span> <span> &nbsp;name of the TSA.<br>
    </span> <span><br>
    </span> <span>Proposed change:<br>
    </span> <span> &nbsp;&nbsp;The purpose of the tsu field is to give a hint in
identifying the</span> <span> <br>
    </span> <span> &nbsp;&nbsp;name of the TSU.<br>
    </span></blockquote>
</blockquote>
it is unacceptable to change the "name" of a field. although it may be<br>
considered as irrelevant, it makes a difference when you use XER to<br>
display things. <br>
<br>
I also recommend Lewis Carroll:&nbsp; "A hint in identifying a name".<br>
<br>
Is this te name, or how you call the name, you a hint for that?<br>
<br>
<a class="moz-txt-link-freetext" href="http://www.edelweb.fr/EdelStuff/Prospectus/ibmmail.txt">http://www.edelweb.fr/EdelStuff/Prospectus/ibmmail.txt</a><br>
<br>
<blockquote cite="mid:[e-mail]" type="cite">
  <blockquote><span></span> <span><br>
    </span> <span>Note that the difference between a TSU and a TSA
that is already present <br>
in RFC 3628 (Informational) is also present in ISO 18014 and in ETSI TS
102 023.<br>
All these documents have been issued after RFC 3161.<br>
    </span></blockquote>
</blockquote>
This is not an argument to copy them. There may also be <br>
a reason for RFC 3628 being informational and not standards track.<br>
the "dad, mon has already agreed" argument is more than weak here<br>
<blockquote cite="mid:[e-mail]" type="cite">
  <blockquote><span><br>
Even, if the bits on the wire are the same, the meaning of these bits <br>
would not necessarily be the same. For example, the ESSCertID refers to
    <br>
a &nbsp;certificate from a TSU, not from a TSA.<br>
    </span></blockquote>
</blockquote>
And what does this mean in practice? What is a relying party supposed
to do?<br>
where would it get the name of a tsa? Is there a need to change
something<br>
at the relying party?<br>
<br>
<blockquote cite="mid:[e-mail]" type="cite">
  <blockquote><span><br>
Since the changes to be done are scattered around the document, a new
draft <br>
would seem more appropriate, hence why a new draft has been proposed.<br>
    </span></blockquote>
</blockquote>
This we have understood, but none of the changes seem useful or
necessary, some <br>
even are restrictive&nbsp; and introduce unnecessary&nbsp; modification. <br>
<blockquote cite="mid:[e-mail]" type="cite">
  <blockquote><span><br>
>From another angle, should we have an update to RFC 3161 or a new
draft? <br>
An update would have to advantage to keep the magic number 3161 that
everybody <br>
identifies with TSP.<br>
    </span></blockquote>
</blockquote>
I think that was already discussed. no replacement.<br>
<blockquote cite="mid:[e-mail]" type="cite">
  <blockquote><span><br>
In any case, I believe that both the ESSCertIDv2 and the terminology
aspects <br>
should be addressed to align RFC 3161 with the documents issued after
it. <br>
    </span></blockquote>
</blockquote>
I'd recommend to do this in two different texts. ESSCertID2 as the one
sentence<br>
above.<br>
<br>
<br>
"ESSCertID2 for RFC 3161".<br>
<br>
Abstract <br>
<br>
RFC 3161 use esssSigningCert to reference a signing certificat. This<br>
document proposes a potentially cryptographically stronger reference by<br>
using essv2. backward compatibility is ensured.<br>
<br>
<span>After the sentence of RFC3161:<br>
</span> <span> &nbsp; "The certificate identifier (ESSCertID) of the</span>
<span> <br>
&nbsp;</span> <span> &nbsp;TSA certificate MUST be included as a signerInfo
attribute inside a</span> <span> <br>
</span> <span> &nbsp;</span> <span>SigningCertificate attribute."<br>
<br>
insert:<br>
<br>
</span> "An ESSCertIDV2 MAY be added in order to allow a smooth
transition<br>
stronger hash functions."<br>
<br>
To be discussed what has to be done by an RP in case of no essv2<br>
(basically no change), or one with an unknown algorithm: <br>
MUST NOT reject a timestamp solely on the base that there is either<br>
no essv2 or the essv2contains an unsupported algorithm.<br>
I hate that phrase. :-)<br>
<span></span><br>
and :<br>
<br>
&nbsp;"Clarifications on the meaning of the TSA tla" <br>
<br>
abstract: RFC 3161 used the tla TSA for different purposes. This text<br>
clarifiesthe different usages and redefines the tla, and introduces<br>
two new tlas in alignment with 3628 etc. No technical change occurs<br>
at the protocol level.<br>
<br>
Peter<br>
<br>
<br>
<br>
<br>
<br>
<br>
</body>
</html>

--------------060806020509080603090304--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6JFoT6O060743 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 19 Jul 2009 08:50:29 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6JFoTuS060742; Sun, 19 Jul 2009 08:50: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 n6JFoIHi060719 for <[e-mail]>; Sun, 19 Jul 2009 08:50:28 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 366999A473C for <[e-mail]>; Sun, 19 Jul 2009 11:50:34 -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 HnqnibzCC5k6 for <[e-mail]>; Sun, 19 Jul 2009 11:50:15 -0400 (EDT)
Received: from THINKPADR52.vigilsec.com (pool-96-241-154-102.washdc.fios.verizon.net [96.241.154.102]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 83902F24004 for <[e-mail]>; Sun, 19 Jul 2009 11:50:32 -0400 (EDT)
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Sun, 19 Jul 2009 11:38:03 -0400
To: ietf-pkix <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: Way forward - updating RFC 3161
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>

>     No doubt that everybody agrees that RFC 3161 should be updated to
>     allow the use of RFC 5035 [ESSV2].

I agree that this change is desirable to support the smooth 
transition to bigger hash values than SHA-1.

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 n6JFONLF059445 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 19 Jul 2009 08:24:24 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6JFONJ1059444; Sun, 19 Jul 2009 08:24:23 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from p03c11o141.symantecmail.net (p03c11o141.symantecmail.net [208.65.144.84]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6JFOB0O059421 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Sun, 19 Jul 2009 08:24:22 -0700 (MST) (envelope-from [e-mail])
Received: from unknown [65.242.48.5] (EHLO scygexch1.cygnacom.com) by p03c11o141.symantecmail.net (mxl_mta-5.7.0-7) with ESMTP id 6aa336a4.2590694320.87373.00-002.p03c11o141.symantecmail.net (envelope-from <[e-mail]>); Sun, 19 Jul 2009 09:24:22 -0600 (MDT)
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: RFC5280 : Applications and CRL DP extension support
Date: Sun, 19 Jul 2009 11:24:10 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: RFC5280 : Applications and CRL DP extension support
thread-index: AcoIfIL7ycjqV27dEEm7UtMVJllHhwACC5qg
References: <[e-mail]> <[e-mail]>
From: "Santosh Chokhani" <[e-mail]>
To: "Stefan Santesson" <[e-mail]>, "Jean-Marc Desperrier" <[e-mail]>, <[e-mail]>
X-Spam: [F=0.2000000000; S=0.200(2009071501)]
X-MAIL-FROM: <[e-mail]>
X-SOURCE-IP: [65.242.48.5]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stefan,

The imprecision in the statement below can lead to security problem.  If
IDP is present in a CRL with DP in the IDP, even if there is no CRL DP
in the certificate, that CRL with DP in IDP can not be used by relying
parties since whether the CRL covers the scope of the certificate or
not, is unknown.

> -----Original Message-----
> From: [e-mail]=20
> [mailto:[e-mail]] On Behalf Of Stefan Santesson
> Sent: Sunday, July 19, 2009 10:24 AM
> To: Jean-Marc Desperrier; [e-mail]
> Subject: Re: RFC5280 : Applications and CRL DP extension support
>=20
>=20
> Jean,
>=20
> An aspect of this often forgotten is that a major practical=20
> function of the CRLDP is to act as an identifier used to=20
> match the certificate and the CRL.
>=20
> When a CRLDP is present in a certificate and an Issuing=20
> Distribution point extension is present in the CRL, them the=20
> distribution points of these extensions MUST match as defined=20
> in section 5.2.5 of RFC 5280.
>=20
> As far as I recall, there are no requirements that the=20
> location stated in the CRLDP need to be used to obtain the CRL.
>=20
> The URL stated in CDP may further be relative (and refer the=20
> relying party to the resource on the local network).
>=20
> /Stefan.
>=20
>=20
> On 09-07-15 4:02 PM, "Jean-Marc Desperrier" <[e-mail]> wrote:
>=20
> >=20
> > The text of RFC5280 says :
> > 4.2.1.14 CRL Distribution Points
> >      [...] this profile
> >      recommends support for this extension by CAs and applications.
> >=20
> > Whilst I 100% approve the recommendation for CAs (No CA=20
> should issue=20
> > certificates without CRLDP when they do provide CRL), what=20
> does it in=20
> > practice mean for applications ?
> >=20
> > They are cases where dynamically  downloading the CRL by=20
> interpreting=20
> > the CRL DP extension is inappropriate for some=20
> applications, and where=20
> > the needs and context of the application make it much more=20
> adequate to=20
> > instead to configure in advance the location where the CRL of the=20
> > supported CAs can be found.
> >=20
> > Some examples  :
> > - Closed networks : Network access to the open internet and=20
> the CRL DP=20
> > might be simply unavailable, and the application should get=20
> CRLs from=20
> > copies made at alternative locations on the local network.
> > - Controled network : Even if no alternative local location is=20
> > provided, network rules may forbid network  access that has=20
> not been=20
> > vetted beforehand, so make it inappropriate if the=20
> application tries=20
> > to download data from a location based on the information=20
> contained in=20
> > any the certificate it just received
> > - Performance : When the application has to validate a hich=20
> volume of=20
> > certificates, dynamic loading of the CRL is simply=20
> inappropriate. This=20
> > can be worked around by using caching mechanisms, but it=20
> will be more=20
> > adequate to use configuration particularly if the=20
> application already=20
> > configures rules about how often to download new CRLs (CRLS quite=20
> > often are renewed more frequently than their nextUpdate=20
> field signals,=20
> > some CA renew their CRL every day, but have a nextUpdate=20
> filed valid for one week).
> >=20
> > So whilst it's very useful to have the CA include the information=20
> > inside the certificate, I think the standard should not try to=20
> > constrain the methods by which the application will get it's up to=20
> > date revocation info, or make it clearer that the use of=20
> alternates is=20
> > appropriate when they will give the same result.
> >=20
> > Can I have confirmation from the group that the text in RFC5280 is=20
> > *not* intended to discourage applications under such circumstances=20
> > from using configuration settings instead of dynamically=20
> reading the=20
> > CRL DP extension content  ?
> >=20
> >=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 n6JENlxC055924 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 19 Jul 2009 07:23:47 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6JENlkl055923; Sun, 19 Jul 2009 07:23:47 -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 n6JENiHf055915 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Sun, 19 Jul 2009 07:23:46 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 6243 invoked from network); 19 Jul 2009 14:23:49 -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]>; 19 Jul 2009 14:23:49 -0000
Received: (qmail 18289 invoked from network); 19 Jul 2009 14:23:41 -0000
Received: from 213-64-142-97-no153.business.telia.com (HELO [192.168.1.9]) ([e-mail]@[213.64.142.97]) (envelope-sender <[e-mail]>) by s128.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <[e-mail]>; 19 Jul 2009 14:23:41 -0000
User-Agent: Microsoft-Entourage/12.19.0.090515
Date: Sun, 19 Jul 2009 16:23:40 +0200
Subject: Re: RFC5280 : Applications and CRL DP extension support
From: Stefan Santesson <[e-mail]>
To: Jean-Marc Desperrier <[e-mail]>, <[e-mail]>
Message-ID: <[e-mail]>
Thread-Topic: RFC5280 : Applications and CRL DP extension support
Thread-Index: AcoIfIL7ycjqV27dEEm7UtMVJllHhw==
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>

Jean,

An aspect of this often forgotten is that a major practical function of the
CRLDP is to act as an identifier used to match the certificate and the CRL.

When a CRLDP is present in a certificate and an Issuing Distribution point
extension is present in the CRL, them the distribution points of these
extensions MUST match as defined in section 5.2.5 of RFC 5280.

As far as I recall, there are no requirements that the location stated in
the CRLDP need to be used to obtain the CRL.

The URL stated in CDP may further be relative (and refer the relying party
to the resource on the local network).

/Stefan.


On 09-07-15 4:02 PM, "Jean-Marc Desperrier" <[e-mail]> wrote:

> 
> The text of RFC5280 says :
> 4.2.1.14 CRL Distribution Points
>      [...] this profile
>      recommends support for this extension by CAs and applications.
> 
> Whilst I 100% approve the recommendation for CAs (No CA should issue
> certificates without CRLDP when they do provide CRL), what does it in
> practice mean for applications ?
> 
> They are cases where dynamically  downloading the CRL by interpreting
> the CRL DP extension is inappropriate for some applications, and where
> the needs and context of the application make it much more adequate to
> instead to configure in advance the location where the CRL of the
> supported CAs can be found.
> 
> Some examples  :
> - Closed networks : Network access to the open internet and the CRL DP
> might be simply unavailable, and the application should get CRLs from
> copies made at alternative locations on the local network.
> - Controled network : Even if no alternative local location is provided,
> network rules may forbid network  access that has not been vetted
> beforehand, so make it inappropriate if the application tries to
> download data from a location based on the information contained in any
> the certificate it just received
> - Performance : When the application has to validate a hich volume of
> certificates, dynamic loading of the CRL is simply inappropriate. This
> can be worked around by using caching mechanisms, but it will be more
> adequate to use configuration particularly if the application already
> configures rules about how often to download new CRLs (CRLS quite often
> are renewed more frequently than their nextUpdate field signals, some CA
> renew their CRL every day, but have a nextUpdate filed valid for one week).
> 
> So whilst it's very useful to have the CA include the information inside
> the certificate, I think the standard should not try to constrain the
> methods by which the application will get it's up to date revocation
> info, or make it clearer that the use of alternates is appropriate when
> they will give the same result.
> 
> Can I have confirmation from the group that the text in RFC5280 is *not*
> intended to discourage applications under such circumstances from using
> configuration settings instead of dynamically reading the CRL DP
> extension content  ?
> 
> 




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6JEEnSE055587 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 19 Jul 2009 07:14:49 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6JEEnNa055586; Sun, 19 Jul 2009 07:14:49 -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 n6JEEkNG055579 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Sun, 19 Jul 2009 07:14:47 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 53038 invoked from network); 19 Jul 2009 14:14:49 -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]>; 19 Jul 2009 14:14:49 -0000
Received: (qmail 56956 invoked from network); 19 Jul 2009 14:14:44 -0000
Received: from 213-64-142-97-no153.business.telia.com (HELO [192.168.1.9]) ([e-mail]@[213.64.142.97]) (envelope-sender <[e-mail]>) by s60.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <[e-mail]>; 19 Jul 2009 14:14:44 -0000
User-Agent: Microsoft-Entourage/12.19.0.090515
Date: Sun, 19 Jul 2009 16:14:41 +0200
Subject: Re: Way forward - updating RFC 3161
From: Stefan Santesson <[e-mail]>
To: Peter Sylvester <[e-mail]>
CC: <[e-mail]>, ietf-pkix <[e-mail]>
Message-ID: <[e-mail]>
Thread-Topic: Way forward - updating RFC 3161
Thread-Index: AcoIe0G30WfnZvqrW0eYAnDH3s7j6g==
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,

I have argued in support of your position and lost.
This work group has already decided to optionally allow a stronger hash than
SHA-1 to bind the signing certificate.

I would agree that no one has identified any realistic attack that would
require this response, but there is a point to do this anyway just to be
technically in line with other standards bodies and current deployment.

/Stefan


On 09-07-19 3:50 PM, "Peter Sylvester" <[e-mail]> wrote:

> 
> 
>> 
>> 
>>     No doubt that everybody agrees that RFC 3161 should be updated to
>>     allow the use of RFC 5035 [ESSV2].
>>     The question is whether other changes should also be made.
>> 
> I do not agree with that at all. I'd not even think thae the
> essSigningCert serves
> anything.
> 
> A requirement of the EU Electronic Signature Directive is that a signature
> must identify the signer. The tsa field in the tstinfo is imo sufficient and
> has the advantage being explicit.
> 
> 
> 




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6JDoxvB054413 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 19 Jul 2009 06:50:59 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6JDoxZS054412; Sun, 19 Jul 2009 06:50:59 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ganymede.on-x.com (ganymede.on-x.com [194.51.68.3]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6JDomr9054399 for <[e-mail]>; Sun, 19 Jul 2009 06:50:58 -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 0BB1477; Sun, 19 Jul 2009 15:50:26 +0200 (CEST)
Received: from smtps.on-x.com (mintaka.puteaux.on-x [192.168.14.11]) by varuna.puteaux.on-x (Postfix) with ESMTP id B692D17048; Sun, 19 Jul 2009 15:50:26 +0200 (CEST)
Received: from [192.168.0.12] (gut75-3-82-227-163-182.fbx.proxad.net [82.227.163.182]) by smtps.on-x.com (Postfix) with ESMTP id 688767877; Sun, 19 Jul 2009 15:50:26 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Sun, 19 Jul 2009 15:50:24 +0200
From: Peter Sylvester <[e-mail]>
User-Agent: Thunderbird 2.0.0.22 (X11/20090608)
MIME-Version: 1.0
To: Stefan Santesson <[e-mail]>
Cc: [e-mail], ietf-pkix <[e-mail]>
Subject: Re: Way forward - updating RFC 3161
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>

>
>
>     No doubt that everybody agrees that RFC 3161 should be updated to
>     allow the use of RFC 5035 [ESSV2].
>     The question is whether other changes should also be made.
>
I do not agree with that at all. I'd not even think thae the 
essSigningCert serves
anything.

A requirement of the EU Electronic Signature Directive is that a signature
must identify the signer. The tsa field in the tstinfo is imo sufficient and
has the advantage being explicit.





Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6JCii22051296 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 19 Jul 2009 05:44:44 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6JCiimo051295; Sun, 19 Jul 2009 05:44: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 n6JCig7o051288 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Sun, 19 Jul 2009 05:44:43 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 13766 invoked from network); 19 Jul 2009 12:44:46 -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]>; 19 Jul 2009 12:44:46 -0000
Received: (qmail 99619 invoked from network); 19 Jul 2009 12:44:41 -0000
Received: from 213-64-142-97-no153.business.telia.com (HELO [192.168.1.9]) ([e-mail]@[213.64.142.97]) (envelope-sender <[e-mail]>) by s57.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <[e-mail]>; 19 Jul 2009 12:44:41 -0000
User-Agent: Microsoft-Entourage/12.19.0.090515
Date: Sun, 19 Jul 2009 14:44:40 +0200
Subject: Re: Request for PKIX agenda items - IETF 75
From: Stefan Santesson <[e-mail]>
To: Stefan Santesson <[e-mail]>, "[e-mail]" <[e-mail]>
Message-ID: <[e-mail]>
Thread-Topic: Request for PKIX agenda items - IETF 75
Thread-Index: Acn48NXT7IibfD+IcUC82hGkpsHCGwPfdinR
In-Reply-To: <[e-mail]>
X-Priority: 1
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3330859481_13131838"
Sender: [e-mail]
Precedence: 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_3330859481_13131838
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit

All,

The response to this has been very thin. Hopefully because of vacations and
stuff. But I really need to know if you need a slot at the meeting or not.
I will post a preliminary agenda in a few days, but right now it looks quite
thin.

So unless you want really long presentations by me, please send in your
requests ASAP :)

/Stefan



On 09-06-29 9:36 PM, "Stefan Santesson" <[e-mail]> wrote:

> PKIX is currently scheduled to meet on Wednesday July 29, 1300-1500
> 
> Please send me any request for agenda items for the IETF in Stockholm.
> 
> As usual I need at least one author of each active draft to send me an e-mail
> stating if you need a slot or not.
> 
> I myself will request (and grant unless I hear loud objections) a time slot to
> talk about solutions for expanded attribute semantics expression. This is an
> issue that sorts under liaison with ETSI ESI activities as well as European ID
> management projects.
> 
> /Stefan


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

<HTML>
<HEAD>
<TITLE>Re: Request for PKIX agenda items - IETF 75</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt=
'>All,<BR>
<BR>
The response to this has been very thin. Hopefully because of vacations and=
 stuff. But I really need to know if you need a slot at the meeting or not.<=
BR>
I will post a preliminary agenda in a few days, but right now it looks quit=
e thin.<BR>
<BR>
So unless you want really long presentations by me, please send in your req=
uests ASAP :)<BR>
<BR>
/Stefan<BR>
<BR>
<BR>
<BR>
On 09-06-29 9:36 PM, &quot;Stefan Santesson&quot; &lt;<a href=3D"stefan@aaa-s=
ec.com">[e-mail]</a>&gt; wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><=
SPAN STYLE=3D'font-size:11pt'>PKIX is currently scheduled to meet on Wednesday=
 July 29, 1300-1500<BR>
<BR>
Please send me any request for agenda items for the IETF in Stockholm.<BR>
<BR>
As usual I need at least one author of each active draft to send me an e-ma=
il stating if you need a slot or not.<BR>
<BR>
I myself will request (and grant unless I hear loud objections) a time slot=
 to talk about solutions for expanded attribute semantics expression. This i=
s an issue that sorts under liaison with ETSI ESI activities as well as Euro=
pean ID management projects.<BR>
<BR>
/Stefan<BR>
</SPAN></FONT></BLOCKQUOTE>
</BODY>
</HTML>


--B_3330859481_13131838--




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6JCdf8O051100 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 19 Jul 2009 05:39:41 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6JCdfvD051099; Sun, 19 Jul 2009 05:39:41 -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 n6JCdQHp051086 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Sun, 19 Jul 2009 05:39:38 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 82291 invoked from network); 19 Jul 2009 12:39:29 -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]>; 19 Jul 2009 12:39:29 -0000
Received: (qmail 60160 invoked from network); 19 Jul 2009 12:39:24 -0000
Received: from 213-64-142-97-no153.business.telia.com (HELO [192.168.1.9]) ([e-mail]@[213.64.142.97]) (envelope-sender <[e-mail]>) by s19.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <[e-mail]>; 19 Jul 2009 12:39:24 -0000
User-Agent: Microsoft-Entourage/12.19.0.090515
Date: Sun, 19 Jul 2009 14:39:23 +0200
Subject: Re: Way forward - updating RFC 3161
From: Stefan Santesson <[e-mail]>
To: <[e-mail]>, ietf-pkix <[e-mail]>
Message-ID: <[e-mail]>
Thread-Topic: Way forward - updating RFC 3161
Thread-Index: AcoIbfGFNOFAdMjQAUOgoO4oOjSxNg==
In-Reply-To: <[e-mail]>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3330859164_13106136"
Sender: [e-mail]
Precedence: 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_3330859164_13106136
Content-type: text/plain;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

Denis,

I have seen your response and waited to see if someone is stepping up to
support you, but it seems that you are quite alone in your urge to update
the terminology and role separation of the time stamping protocol.

My primary issue is not whether the role separation is accurate and well
motivated. The central issue for me is why it need to be included in the
protocol specification.
Note that we have a very similar situation with PKI. The CA issues
certificates, but in practice the CA will delegate the signing to a =B3unit=B2
and may delegate authorization of attributes to  =B3Registration Authority=B2.
Still, the CA is ultimately the responsible party and not any =B3unit=B2 or
other subordinate entity or process. The same is true for a TSA. The TSA is
the responsible entity and as such the entity that is represented by the
certificate of the service, even if that certificate indicates which unit
under the TSA control that actually signed the Time-stamp.

As long as this does not reflect any bits on the wire, it would just be
confusing to define the role separation structure behind the service as par=
t
of the protocol.

This is where I think you have failed to convince us.

Unless I hear new convincing arguments, I will treat the answers on this
list as a rough consensus decision to NOT make a full replacement of RFC
3161, but merely provide an update document with ESSCertIDv2 and possibly
similar minor updates, but to drop alignment with RFC 3628 terminology.

/Stefan



On 09-07-10 3:55 PM, "Denis Pinkas" <[e-mail]> wrote:

> =20
> No doubt that everybody agrees that RFC 3161 should be updated to allow t=
he
> use of RFC 5035 [ESSV2].
> The question is whether other changes should also be made.
>=20
> The major differences from RFC 3161 [RFC3161] are summarized on page 3 of=
 the
> draft and are listed below:
>=20
>      1 - the document has been aligned with RFC 3628 to make the
>          difference between a time-stamping unit (TSU) and a TSA.
>=20
>      2 - the document makes the difference between a time-stamping
>          service and a time-stamping unit and allows a time-stamping
>          service to support more than one time-stamping unit.
>=20
>      3 - the format of the subject field of a TSU certificate is now
>          defined.
>=20
> and also some minor updates :
>=20
>      4 - informative references to ISO 18014-1 [ISO18014-1],
>          ISO 18014-2 [ISO18014-2] and ISO 18014-3 [ISO18014-3] have been
>          added.
>=20
>      5 - a new normative ASN1 module to refer to the ASN.1 modules
>          from the latest RFCs.
>=20
> At the moment, RFC 3161 makes confusion between three different concepts:
> a TSA, a TSS and a TSU, respectively a Time-Stamping Authority,
> a Time-Stamping Service and a Time-Stamping Unit.
> =20
> IMO, the document should be cleaned to call a spade a spade.
>=20
> Historically, the notions applicable to TSAs have been copied and pasted
> from the documents related to CAs. Since a CA had one private key, a TSA
> had one private key as well, but this was short looking.
>=20
> The CA advertises one public key, or more exactly one trust anchor, usual=
ly
> by issuing a self-signed certificate. This private key, when in use,
> is supported by one HSH (Hardware Security Module). This private key need=
s
> to be saved in order to be restored in case of a problem. The time for
> restoration=20
> is usually not critical (this may take a few minutes or even a few hours)=
.
> The life time of a CA certificate (or CA public key) is usually between o=
ne
> and=20
> 15 years and should not be changed earlier, unless strictly needed.
>=20
> In order to provide time-stamp tokens (TSTs) with high availability, more=
 than
> one TSU is usually needed. These units altogether provide a TSS (Time-Sta=
mping
> Service)=20
> that is managed by an Authority called a TSA (Time-Stamping Authority).
>=20
> The key used to sign TSTs is not the key from a TSA, but the key from a T=
SU.
>=20
> In order to a high level of security, the key used to sign to TSTs should=
 NOT
> be saved=20
> and restored. It should be generated by the TSU itself and should NOT be
> exported=20
> outside the TSU. If the key of the TSU is erased purposely or by accident=
, a
> new key pair=20
> and certificate should be generated. Since TSU certificates are provided =
by a
> CA,=20
> TST verification systems do not need to change any trust anchor. Some TSU=
s may
> even=20
> use short-lived TSU certificates, e.g. a TSU certificate valid for one we=
ek or
> even one day.=20
> However, it is necessary to be able to know the name of the TSA when look=
ing
> at the=20
> subject DN from the TSU certificate.
>=20
> Along these lines, several changes should be made to RFC 3161. To mention=
 a
> few of them:
>=20
> RFC 3161:
>    If the TSA does not recognize the hash
>    algorithm or knows that the hash algorithm is weak (a decision left
>    to the discretion of each individual TSA), then the TSA SHOULD refuse
>    to provide the time-stamp token by returning a pkiStatusInfo of
>    'bad_alg'.
>=20
> Proposed change :
>    If the TSS does not recognize the hash
>    algorithm or knows that the hash algorithm is weak (a decision left
>     to the discretion of each individual TSA), then the TSS SHOULD refuse
>     to provide the time-stamp token by returning a pkiStatusInfo of
>     'bad_alg'.
>=20
> RFC3161:
>    The certificate identifier (ESSCertID) of the
>    TSA certificate MUST be included as a signerInfo attribute inside a
>   SigningCertificate attribute.
>=20
> Proposed change:
>    The certificate identifier (either ESSCertID  or ESSCertIDv2) of the T=
SU
> certificate=20
>   MUST be included as a signerInfo attribute inside a SigningCertificate
> attribute.
>=20
> RFC 3161:
>    The serialNumber field is an integer assigned by the TSA to each
>   TimeStampToken.
>=20
> Proposed change:=20
>    The serialNumber field is an integer assigned by the TSU to each
>    TimeStampToken.
>=20
> RFC 3161:
>    genTime is the time at which the time-stamp token has been created by
> =20
>    the TSA.
>=20
> Proposed change:
>    genTime is the time at which the time-stamp token has been created by
>    the TSU.
>=20
> RF3161:
>    The purpose of the tsa field is to give a hint in identifying the
>    name of the TSA.
>=20
> Proposed change:
>    The purpose of the tsu field is to give a hint in identifying the
>    name of the TSU.
>=20
> Note that the difference between a TSU and a TSA that is already present
> in RFC 3628 (Informational) is also present in ISO 18014 and in ETSI TS 1=
02
> 023.
> All these documents have been issued after RFC 3161.
>=20
> Even, if the bits on the wire are the same, the meaning of these bits
> would not necessarily be the same. For example, the ESSCertID refers to
> a  certificate from a TSU, not from a TSA.
>=20
> Since the changes to be done are scattered around the document, a new dra=
ft
> would seem more appropriate, hence why a new draft has been proposed.
>=20
> From another angle, should we have an update to RFC 3161 or a new draft?
> An update would have to advantage to keep the magic number 3161 that ever=
ybody
> identifies with TSP.
>=20
> In any case, I believe that both the ESSCertIDv2 and the terminology aspe=
cts
> should be addressed to align RFC 3161 with the documents issued after it.
>=20
> Denis
>> =20
>> -----  Message re=E7u -----
>> =20
>> De  : Stefan Santesson <mailto :[e-mail]>
>> =20
>> =C0  : Pope,Nick,ietf-pkix <mailto
>> :[e-mail],[e-mail]>
>> =20
>> Date  : 2009-07-09, 13:13:15
>> =20
>> Sujet  : Re: Way forward - updating RFC 3161
>> =20
>>=20
>> =20
>> =20
>> =20
>> I conclude that the list so far is unanimous in its  view of not accepti=
ng
>> the approach of draft-ietf-pkix-rfc3161bis-01.
>> Even  though we have not heard the opinion of the draft author, It feels=
 that
>> we  will have a strong consensus for just making a short update  documen=
t.
>>=20
>> /Stefan
>>=20
>>=20
>> On 09-07-01 12:47 PM, "Pope, Nick" <[e-mail]>  wro=
te:
>>=20
>> =20
>>> Stefan,
>>> =20
>>> I also agree with the approach  of updating RFC 3161.  Changing the mod=
el of
>>> RFC 3161 is only going to  cause confusion.
>>> =20
>>> The implementation architecture concepts used  in the earlier proposal =
are
>>> already described in RFC 3628  and so I see  no need for further steps =
on
>>> that  aspect.
>>> =20
>>> Nick
>>> =20
>>>=20
>>> -----Original Message-----
>>> From: Stefan  Santesson [mailto:[e-mail]]
>>> Sent: 01 July 2009 02:00
>>> To: [e-mail]
>>> Cc: Denis Pinkas;  Pope, Nick
>>> Subject: Way forward - updating RFC  3161
>>>=20
>>> We  need to resolve how to update RFC 3161 with respect to allowing sup=
port
>>> of  RFC 5035 (ESSV2)
>>> One particular reason is because ETSI ESI is dependent  on progression =
of
>>> this issue in PKIX.
>>>=20
>>> I would like to open this issue  up for debate and then hopefully concl=
ude
>>> this issue, possibly after a straw  poll.
>>>=20
>>> My personal opinion, and what I interpret as the general  opinion of th=
is
>>> working group is that we should reject  draft-ietf-pkix-rfc3161bis-01 a=
s
>>> basis for updating rfc 3161. This draft  intends to obsolete RFC 3161 a=
nd
>>> introduces major changes to terminology and  role description to align =
RFC
>>> 3161 with the informational document RFC  3628.
>>>=20
>>> It is problematic to introduce such major changes to a standard  that i=
s
>>> widely deployed. It is neither required from a protocol  implementation
>>> perspective as these changes are not intended to change any  bits on th=
e
>>> wire. The optional usage of ESSV2 does not motivate a total  rewrite of=
 the
>>> current standard, but is better handled in an update  RFC.
>>>=20
>>> If description of roles and responsibilities that so not change  any bi=
ts on
>>> the wire need to be clarified in relation to RFC 3628 and RFC  3161, th=
en
>>> this should be handled either as an update to RFC 3628 or as a  separat=
e
>>> informational document.
>>>=20
>>> /Stefan =20
>>>=20
>=20


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

<HTML>
<HEAD>
<TITLE>Re: Way forward - updating RFC 3161</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt=
'>Denis,<BR>
<BR>
I have seen your response and waited to see if someone is stepping up to su=
pport you, but it seems that you are quite alone in your urge to update the =
terminology and role separation of the time stamping protocol.<BR>
<BR>
My primary issue is not whether the role separation is accurate and well mo=
tivated. The central issue for me is why it need to be included in the proto=
col specification.<BR>
Note that we have a very similar situation with PKI. The CA issues certific=
ates, but in practice the CA will delegate the signing to a &#8220;unit&#822=
1; and may delegate authorization of attributes to &nbsp;&#8220;Registration=
 Authority&#8221;. Still, the CA is ultimately the responsible party and not=
 any &#8220;unit&#8221; or other subordinate entity or process. The same is =
true for a TSA. The TSA is the responsible entity and as such the entity tha=
t is represented by the certificate of the service, even if that certificate=
 indicates which unit under the TSA control that actually signed the Time-st=
amp.<BR>
<BR>
As long as this does not reflect any bits on the wire, it would just be con=
fusing to define the role separation structure behind the service as part of=
 the protocol.<BR>
<BR>
This is where I think you have failed to convince us.<BR>
<BR>
Unless I hear new convincing arguments, I will treat the answers on this li=
st as a rough consensus decision to NOT make a full replacement of RFC 3161,=
 but merely provide an update document with ESSCertIDv2 and possibly similar=
 minor updates, but to drop alignment with RFC 3628 terminology.<BR>
<BR>
/Stefan<BR>
<BR>
<BR>
<BR>
On 09-07-10 3:55 PM, &quot;Denis Pinkas&quot; &lt;<a href=3D"denis.pinkas@bul=
l.net">[e-mail]</a>&gt; wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT SIZE=3D"2"><FONT FACE=3D"Tahoma, Verdana, Helve=
tica, Arial"><SPAN STYLE=3D'font-size:10pt'> <BR>
</SPAN></FONT></FONT><FONT FACE=3D"Times New Roman"><SPAN STYLE=3D'font-size:12=
pt'>No doubt that everybody agrees that RFC 3161 should be updated to allow =
the use of RFC 5035 [ESSV2]. <BR>
The question is whether other changes should also be made.<BR>
<BR>
The major differences from RFC 3161 [RFC3161] are summarized on page 3 of t=
he draft and are listed below:<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;1 - the document has been aligned with RFC 36=
28 to make the <BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;difference between a =
time-stamping unit (TSU) and a TSA.<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2 - the document makes the difference between=
 a time-stamping <BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;service and a time-st=
amping unit and allows a time-stamping <BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;service to support mo=
re than one time-stamping unit.<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3 - the format of the subject field of a TSU =
certificate is now <BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;defined.<BR>
<BR>
and also some minor updates :<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;4 - informative references to ISO 18014-1 [IS=
O18014-1], <BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ISO 18014-2 [ISO18014=
-2] and ISO 18014-3 [ISO18014-3] have been <BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;added.<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;5 - a new normative ASN1 module to refer to t=
he ASN.1 modules <BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;from the latest RFCs.=
 <BR>
</SPAN></FONT><FONT SIZE=3D"2"><FONT FACE=3D"Courier New"><SPAN STYLE=3D'font-siz=
e:10pt'><BR>
</SPAN></FONT></FONT><FONT SIZE=3D"4"><FONT FACE=3D"Times New Roman"><SPAN STYL=
E=3D'font-size:14pt'>At the moment, RFC 3161 makes confusion between three dif=
ferent concepts: <BR>
a TSA, a TSS and a TSU, respectively a Time-Stamping Authority, <BR>
a Time-Stamping Service and a Time-Stamping Unit. <BR>
</SPAN></FONT></FONT><FONT SIZE=3D"2"><FONT FACE=3D"Tahoma, Verdana, Helvetica,=
 Arial"><SPAN STYLE=3D'font-size:10pt'> <BR>
</SPAN></FONT><SPAN STYLE=3D'font-size:10pt'><FONT FACE=3D"Courier New">IMO, th=
e document should be cleaned to call a spade a spade.<BR>
<BR>
Historically, the notions applicable to TSAs have been copied and pasted <B=
R>
from the documents related to CAs. Since a CA had one private key, a TSA <B=
R>
had one private key as well, but this was short looking.<BR>
<BR>
The CA advertises one public key, or more exactly one trust anchor, usually=
 <BR>
by issuing a self-signed certificate. This private key, when in use, <BR>
is supported by one HSH (Hardware Security Module). This private key needs =
<BR>
to be saved in order to be restored in case of a problem. The time for rest=
oration <BR>
is usually not critical (this may take a few minutes or even a few hours). =
<BR>
The life time of a CA certificate (or CA public key) is usually between one=
 and <BR>
15 years and should not be changed earlier, unless strictly needed.<BR>
<BR>
In order to provide time-stamp tokens (TSTs) with high availability, more t=
han <BR>
one TSU is usually needed. These units altogether provide a TSS (Time-Stamp=
ing Service) <BR>
that is managed by an Authority called a TSA (Time-Stamping Authority).<BR>
<BR>
The key used to sign TSTs is not the key from a TSA, but the key from a TSU=
.<BR>
<BR>
In order to a high level of security, the key used to sign to TSTs should N=
OT be saved <BR>
and restored. It should be generated by the TSU itself and should NOT be ex=
ported <BR>
outside the TSU. If the key of the TSU is erased purposely or by accident, =
a new key pair <BR>
and certificate should be generated. Since TSU certificates are provided by=
 a CA, <BR>
TST verification systems do not need to change any trust anchor. Some TSUs =
may even <BR>
use short-lived TSU certificates, e.g. a TSU certificate valid for one week=
 or even one day. <BR>
However, it is necessary to be able to know the name of the TSA when lookin=
g at the <BR>
subject DN from the TSU certificate.<BR>
<BR>
Along these lines, several changes should be made to RFC 3161. To mention a=
 few of them:<BR>
<BR>
RFC 3161:<BR>
</FONT></SPAN></FONT><FONT FACE=3D"Times New Roman"><SPAN STYLE=3D'font-size:12=
pt'> &nbsp;&nbsp;If the TSA does not recognize the hash</SPAN><FONT SIZE=3D"2"=
><SPAN STYLE=3D'font-size:10pt'> <BR>
</SPAN></FONT><SPAN STYLE=3D'font-size:12pt'> &nbsp;&nbsp;algorithm or knows =
that the hash algorithm is weak (a decision left</SPAN><FONT SIZE=3D"4"><SPAN =
STYLE=3D'font-size:14pt'> <BR>
</SPAN></FONT><SPAN STYLE=3D'font-size:12pt'> &nbsp;&nbsp;to the discretion o=
f each individual TSA), then the TSA SHOULD refuse</SPAN><FONT SIZE=3D"4"><SPA=
N STYLE=3D'font-size:14pt'> <BR>
</SPAN></FONT><SPAN STYLE=3D'font-size:12pt'> &nbsp;&nbsp;to provide the time=
-stamp token by returning a pkiStatusInfo of</SPAN><FONT SIZE=3D"4"><SPAN STYL=
E=3D'font-size:14pt'> <BR>
</SPAN></FONT><SPAN STYLE=3D'font-size:12pt'> &nbsp;&nbsp;'bad_alg'.<BR>
</SPAN></FONT><FONT SIZE=3D"2"><FONT FACE=3D"Courier New"><SPAN STYLE=3D'font-siz=
e:10pt'><BR>
</SPAN></FONT></FONT><FONT SIZE=3D"4"><FONT FACE=3D"Times New Roman"><SPAN STYL=
E=3D'font-size:14pt'>Proposed change :<BR>
</SPAN></FONT></FONT><FONT FACE=3D"Times New Roman"><SPAN STYLE=3D'font-size:12=
pt'> &nbsp;&nbsp;If the TSS does not recognize the hash</SPAN><FONT SIZE=3D"4"=
><SPAN STYLE=3D'font-size:14pt'> <BR>
</SPAN></FONT><SPAN STYLE=3D'font-size:12pt'> &nbsp;&nbsp;algorithm or knows =
that the hash algorithm is weak (a decision left</SPAN><FONT SIZE=3D"4"><SPAN =
STYLE=3D'font-size:14pt'> <BR>
&nbsp;</SPAN></FONT><SPAN STYLE=3D'font-size:12pt'> &nbsp;&nbsp;to the discre=
tion of each individual TSA), then the TSS SHOULD refuse</SPAN><FONT SIZE=3D"2=
"><SPAN STYLE=3D'font-size:10pt'> <BR>
</SPAN></FONT><FONT SIZE=3D"4"><SPAN STYLE=3D'font-size:14pt'> </SPAN></FONT><S=
PAN STYLE=3D'font-size:12pt'> &nbsp;&nbsp;to provide the time-stamp token by r=
eturning a pkiStatusInfo of</SPAN><FONT SIZE=3D"2"><SPAN STYLE=3D'font-size:10pt=
'> <BR>
</SPAN></FONT><FONT SIZE=3D"4"><SPAN STYLE=3D'font-size:14pt'> </SPAN></FONT><S=
PAN STYLE=3D'font-size:12pt'> &nbsp;&nbsp;'bad_alg'.<BR>
</SPAN></FONT><FONT SIZE=3D"2"><FONT FACE=3D"Courier New"><SPAN STYLE=3D'font-siz=
e:10pt'><BR>
</SPAN></FONT></FONT><FONT SIZE=3D"4"><FONT FACE=3D"Times New Roman"><SPAN STYL=
E=3D'font-size:14pt'>RFC3161:<BR>
</SPAN></FONT></FONT><FONT FACE=3D"Times New Roman"><SPAN STYLE=3D'font-size:12=
pt'> &nbsp;&nbsp;The certificate identifier (ESSCertID) of the</SPAN><FONT S=
IZE=3D"4"><SPAN STYLE=3D'font-size:14pt'> <BR>
&nbsp;</SPAN></FONT><SPAN STYLE=3D'font-size:12pt'> &nbsp;TSA certificate MUS=
T be included as a signerInfo attribute inside a</SPAN><FONT SIZE=3D"2"><SPAN =
STYLE=3D'font-size:10pt'> <BR>
</SPAN></FONT><FONT SIZE=3D"4"><SPAN STYLE=3D'font-size:14pt'> &nbsp;</SPAN></F=
ONT><FONT SIZE=3D"2"><SPAN STYLE=3D'font-size:10pt'>SigningCertificate attribute=
.<BR>
<BR>
Proposed change:<BR>
</SPAN></FONT><SPAN STYLE=3D'font-size:12pt'> &nbsp;&nbsp;The certificate ide=
ntifier (either ESSCertID &nbsp;or ESSCertIDv2) of the TSU certificate <BR>
&nbsp;&nbsp;MUST be included as a </SPAN></FONT><FONT SIZE=3D"2"><FONT FACE=3D"=
Courier New"><SPAN STYLE=3D'font-size:10pt'>signerInfo attribute inside a Sign=
ingCertificate attribute.<BR>
<BR>
RFC 3161:<BR>
</SPAN></FONT></FONT><FONT FACE=3D"Times New Roman"><SPAN STYLE=3D'font-size:12=
pt'> &nbsp;&nbsp;The serialNumber field is an integer assigned by the TSA to=
 each</SPAN><FONT SIZE=3D"2"><SPAN STYLE=3D'font-size:10pt'> <BR>
</SPAN></FONT><FONT SIZE=3D"4"><SPAN STYLE=3D'font-size:14pt'> </SPAN></FONT></=
FONT><FONT SIZE=3D"2"><FONT FACE=3D"Courier New"><SPAN STYLE=3D'font-size:10pt'> T=
imeStampToken.<BR>
<BR>
Proposed change: <BR>
</SPAN></FONT></FONT><FONT FACE=3D"Times New Roman"><SPAN STYLE=3D'font-size:12=
pt'> &nbsp;&nbsp;The serialNumber field is an integer assigned by the TSU to=
 each</SPAN><FONT SIZE=3D"2"><SPAN STYLE=3D'font-size:10pt'> <BR>
</SPAN></FONT><FONT SIZE=3D"4"><SPAN STYLE=3D'font-size:14pt'> </SPAN></FONT><S=
PAN STYLE=3D'font-size:12pt'> &nbsp;TimeStampToken.<BR>
</SPAN></FONT><FONT SIZE=3D"2"><FONT FACE=3D"Courier New"><SPAN STYLE=3D'font-siz=
e:10pt'><BR>
</SPAN></FONT></FONT><FONT SIZE=3D"4"><FONT FACE=3D"Times New Roman"><SPAN STYL=
E=3D'font-size:14pt'>RFC 3161:<BR>
</SPAN></FONT></FONT><FONT FACE=3D"Times New Roman"><SPAN STYLE=3D'font-size:12=
pt'> &nbsp;&nbsp;genTime is the time at which the time-stamp token has been =
created by</SPAN><FONT SIZE=3D"4"><SPAN STYLE=3D'font-size:14pt'> <BR>
&nbsp;<BR>
</SPAN></FONT><SPAN STYLE=3D'font-size:12pt'> &nbsp;&nbsp;the TSA.<BR>
</SPAN></FONT><FONT SIZE=3D"2"><FONT FACE=3D"Courier New"><SPAN STYLE=3D'font-siz=
e:10pt'><BR>
</SPAN></FONT></FONT><FONT SIZE=3D"4"><FONT FACE=3D"Times New Roman"><SPAN STYL=
E=3D'font-size:14pt'>Proposed change:<BR>
</SPAN></FONT></FONT><FONT FACE=3D"Times New Roman"><SPAN STYLE=3D'font-size:12=
pt'> &nbsp;&nbsp;genTime is the time at which the time-stamp token has been =
created by</SPAN><FONT SIZE=3D"4"><SPAN STYLE=3D'font-size:14pt'> <BR>
&nbsp;</SPAN></FONT><SPAN STYLE=3D'font-size:12pt'> &nbsp;the TSU.<BR>
</SPAN></FONT><FONT SIZE=3D"2"><FONT FACE=3D"Courier New"><SPAN STYLE=3D'font-siz=
e:10pt'><BR>
</SPAN></FONT></FONT><FONT SIZE=3D"4"><FONT FACE=3D"Times New Roman"><SPAN STYL=
E=3D'font-size:14pt'>RF3161:<BR>
</SPAN></FONT></FONT><FONT FACE=3D"Times New Roman"><SPAN STYLE=3D'font-size:12=
pt'> &nbsp;&nbsp;The purpose of the tsa field is to give a hint in identifyi=
ng the</SPAN><FONT SIZE=3D"4"><SPAN STYLE=3D'font-size:14pt'> <BR>
&nbsp;</SPAN></FONT><SPAN STYLE=3D'font-size:12pt'> &nbsp;name of the TSA.<BR=
>
</SPAN></FONT><FONT SIZE=3D"2"><FONT FACE=3D"Courier New"><SPAN STYLE=3D'font-siz=
e:10pt'><BR>
</SPAN></FONT></FONT><FONT SIZE=3D"4"><FONT FACE=3D"Times New Roman"><SPAN STYL=
E=3D'font-size:14pt'>Proposed change:<BR>
</SPAN></FONT></FONT><FONT FACE=3D"Times New Roman"><SPAN STYLE=3D'font-size:12=
pt'> &nbsp;&nbsp;The purpose of the tsu field is to give a hint in identifyi=
ng the</SPAN><FONT SIZE=3D"4"><SPAN STYLE=3D'font-size:14pt'> <BR>
</SPAN></FONT><SPAN STYLE=3D'font-size:12pt'> &nbsp;&nbsp;name of the TSU.<BR=
>
</SPAN></FONT><FONT SIZE=3D"2"><FONT FACE=3D"Courier New"><SPAN STYLE=3D'font-siz=
e:10pt'><BR>
</SPAN></FONT></FONT><FONT SIZE=3D"4"><FONT FACE=3D"Times New Roman"><SPAN STYL=
E=3D'font-size:14pt'>Note that the difference between a TSU and a TSA that is =
already present <BR>
in RFC 3628 (Informational) is also present in ISO 18014 and in ETSI TS 102=
 023.<BR>
All these documents have been issued after RFC 3161.<BR>
<BR>
Even, if the bits on the wire are the same, the meaning of these bits <BR>
would not necessarily be the same. For example, the ESSCertID refers to <BR=
>
a &nbsp;certificate from a TSU, not from a TSA.<BR>
<BR>
Since the changes to be done are scattered around the document, a new draft=
 <BR>
would seem more appropriate, hence why a new draft has been proposed.<BR>
<BR>
>From another angle, should we have an update to RFC 3161 or a new draft? <B=
R>
An update would have to advantage to keep the magic number 3161 that everyb=
ody <BR>
identifies with TSP.<BR>
<BR>
In any case, I believe that both the ESSCertIDv2 and the terminology aspect=
s <BR>
should be addressed to align RFC 3161 with the documents issued after it. <=
BR>
</SPAN></FONT></FONT><FONT SIZE=3D"2"><FONT FACE=3D"Courier New"><SPAN STYLE=3D'f=
ont-size:10pt'><BR>
</SPAN></FONT></FONT><FONT SIZE=3D"4"><FONT FACE=3D"Times New Roman"><SPAN STYL=
E=3D'font-size:14pt'>Denis<BR>
</SPAN></FONT></FONT><BLOCKQUOTE><FONT SIZE=3D"2"><FONT FACE=3D"Tahoma, Verdana=
, Helvetica, Arial"><SPAN STYLE=3D'font-size:10pt'> <BR>
</SPAN></FONT></FONT><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial"><FONT S=
IZE=3D"1"><SPAN STYLE=3D'font-size:9pt'>----- &nbsp;Message re&ccedil;u ----- <B=
R>
</SPAN></FONT><FONT SIZE=3D"2"><SPAN STYLE=3D'font-size:10pt'> <BR>
</SPAN></FONT><FONT SIZE=3D"1"><SPAN STYLE=3D'font-size:9pt'><B>De &nbsp;:</B> =
Stefan Santesson &lt;mailto :<a href=3D"[e-mail]">[e-mail]=
</a>&gt; &nbsp;<BR>
</SPAN></FONT><FONT SIZE=3D"2"><SPAN STYLE=3D'font-size:10pt'> <BR>
</SPAN></FONT><FONT SIZE=3D"1"><SPAN STYLE=3D'font-size:9pt'><B>&Agrave; &nbsp;=
:</B> Pope,Nick,ietf-pkix &lt;mailto :<a href=3D"[e-mail]=
m">[e-mail]</a>,<a href=3D"[e-mail]">ietf-pkix@=
imc.org</a>&gt; &nbsp;&nbsp;<BR>
</SPAN></FONT><FONT SIZE=3D"2"><SPAN STYLE=3D'font-size:10pt'> <BR>
</SPAN></FONT><FONT SIZE=3D"1"><SPAN STYLE=3D'font-size:9pt'><B>Date &nbsp;:</B=
> 2009-07-09, 13:13:15<BR>
</SPAN></FONT><FONT SIZE=3D"2"><SPAN STYLE=3D'font-size:10pt'> <BR>
</SPAN></FONT><FONT SIZE=3D"1"><SPAN STYLE=3D'font-size:9pt'><B>Sujet &nbsp;:</=
B> Re: Way forward - updating RFC 3161<BR>
</SPAN></FONT><FONT SIZE=3D"2"><SPAN STYLE=3D'font-size:10pt'> <BR>
<BR>
&nbsp;<BR>
&nbsp;<BR>
&nbsp;<BR>
</SPAN></FONT></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN =
STYLE=3D'font-size:11pt'>I conclude that the list so far is unanimous in its &=
nbsp;view of not accepting the approach of draft-ietf-pkix-rfc3161bis-01.<BR=
>
Even &nbsp;though we have not heard the opinion of the draft author, It fee=
ls that we &nbsp;will have a strong consensus for just making a short update=
 &nbsp;document.<BR>
<BR>
/Stefan<BR>
<BR>
<BR>
On 09-07-01 12:47 PM, &quot;Pope, Nick&quot; &lt;<a href=3D"Nick.Pope@thales-=
esecurity.com">[e-mail]</a>&gt; &nbsp;wrote:<BR>
<BR>
</SPAN></FONT><FONT SIZE=3D"2"><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:10pt'> <BR>
</SPAN></FONT></FONT><BLOCKQUOTE><FONT SIZE=3D"2"><SPAN STYLE=3D'font-size:10pt=
'><FONT COLOR=3D"#000080"><FONT FACE=3D"Arial">Stefan,<BR>
&nbsp;<BR>
I also agree with the approach &nbsp;of updating RFC 3161. &nbsp;Changing t=
he model of RFC 3161 is only going to &nbsp;cause confusion.<BR>
&nbsp;<BR>
The implementation architecture concepts used &nbsp;in the earlier proposal=
 are already described in RFC 3628 &nbsp;and so I see &nbsp;no need for furt=
her steps on that &nbsp;aspect.<BR>
&nbsp;<BR>
Nick<BR>
&nbsp;<BR>
</FONT></FONT></SPAN></FONT><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'>-----Original Message-----<BR>
<B>From:</B> Stefan &nbsp;Santesson [<a href=3D"mailto:[e-mail]">ma=
ilto:[e-mail]</a>] &nbsp;<BR>
<B>Sent:</B> 01 July 2009 02:00<BR>
<B>To:</B> <a href=3D"[e-mail]">[e-mail]</a><BR>
<B>Cc:</B> Denis Pinkas; &nbsp;Pope, Nick<BR>
<B>Subject:</B> Way forward - updating RFC &nbsp;3161<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'>We &nbsp;need to resolve how to update RFC 3161 with respect=
 to allowing support of &nbsp;RFC 5035 (ESSV2)<BR>
One particular reason is because ETSI ESI is dependent &nbsp;on progression=
 of this issue in PKIX.<BR>
<BR>
I would like to open this issue &nbsp;up for debate and then hopefully conc=
lude this issue, possibly after a straw &nbsp;poll.<BR>
<BR>
My personal opinion, and what I interpret as the general &nbsp;opinion of t=
his working group is that we should reject &nbsp;draft-ietf-pkix-rfc3161bis-=
01 as basis for updating rfc 3161. This draft &nbsp;intends to obsolete RFC =
3161 and introduces major changes to terminology and &nbsp;role description =
to align RFC 3161 with the informational document RFC &nbsp;3628.<BR>
<BR>
It is problematic to introduce such major changes to a standard &nbsp;that =
is widely deployed. It is neither required from a protocol &nbsp;implementat=
ion perspective as these changes are not intended to change any &nbsp;bits o=
n the wire. The optional usage of ESSV2 does not motivate a total &nbsp;rewr=
ite of the current standard, but is better handled in an update &nbsp;RFC.<B=
R>
<BR>
If description of roles and responsibilities that so not change &nbsp;any b=
its on the wire need to be clarified in relation to RFC 3628 and RFC &nbsp;3=
161, then this should be handled either as an update to RFC 3628 or as a &nb=
sp;separate informational document.<BR>
<BR>
/Stefan</SPAN></FONT><FONT FACE=3D"Times New Roman"><SPAN STYLE=3D'font-size:12=
pt'> &nbsp;<BR>
</SPAN></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'=
font-size:11pt'><BR>
</SPAN></FONT></BLOCKQUOTE></BLOCKQUOTE><FONT SIZE=3D"2"><FONT FACE=3D"Tahoma, =
Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:10pt'><BR>
</SPAN></FONT></FONT></BLOCKQUOTE>
</BODY>
</HTML>


--B_3330859164_13106136--




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6FFqfw1009106 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Jul 2009 08:52:41 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6FFqfKl009104; Wed, 15 Jul 2009 08:52:41 -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 n6FFqT5v009081 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 15 Jul 2009 08:52:40 -0700 (MST) (envelope-from [e-mail])
Received: from newblitzen.Dartmouth.EDU (newblitzen.dartmouth.edu [129.170.208.36]) by mailhub1.dartmouth.edu (8.13.5/DND2.0/8.13.5) with ESMTP id n6FFIXHW019713 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Jul 2009 11:51:20 -0400
X-Disclaimer: This message was received from outside Dartmouth's BlitzMail system.
Received: from dhcp-212-191.cs.dartmouth.edu [129.170.212.191] by newblitzen.Dartmouth.EDU (Mac) via SMTP  for  id <152242281>; 15 Jul 2009 11:51:19 -0400
Message-ID: <[e-mail]>
Date: Wed, 15 Jul 2009 11:56:16 -0400
From: Massimiliano Pala <[e-mail]>
Organization: Dartmouth College - Computer Science Department
User-Agent: Thunderbird 2.0.0.22 (X11/20090605)
MIME-Version: 1.0
To: Jean-Marc Desperrier <[e-mail]>
CC: pkix <[e-mail]>
Subject: Re: RFC5280 : Applications and CRL DP extension support
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030509070506050206060504"
X-Dartmouth.EDU-MailScanner-Information: Please contact the ISP for more information
X-Dartmouth.EDU-MailScanner-ID: n6FFIXHW019713
X-MailScanner: Found to be clean by mailhub21.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.

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

Hi Jean,

your pledge for more dynamic approach to CRLs (but this could be applied
to any URLs embedded into certificates) is well known. Take a look at PRQP
(PKI Resource Query Protocol), currently a draft (you can download it
from the PKIX WG page): this should provide a solution to that by having
an authoritative source of information (instead of having just a
"configuration" file).

Hope this will help,

Best,
Max


Jean-Marc Desperrier wrote:
> 
> The text of RFC5280 says :
> 4.2.1.14 CRL Distribution Points
>     [...] this profile
>     recommends support for this extension by CAs and applications.
> 
> Whilst I 100% approve the recommendation for CAs (No CA should issue 
> certificates without CRLDP when they do provide CRL), what does it in 
> practice mean for applications ?
> 
> They are cases where dynamically  downloading the CRL by interpreting 
> the CRL DP extension is inappropriate for some applications, and where 
> the needs and context of the application make it much more adequate to 
> instead to configure in advance the location where the CRL of the 
> supported CAs can be found.
> 
> Some examples  :
> - Closed networks : Network access to the open internet and the CRL DP 
> might be simply unavailable, and the application should get CRLs from 
> copies made at alternative locations on the local network.
> - Controled network : Even if no alternative local location is provided, 
> network rules may forbid network  access that has not been vetted 
> beforehand, so make it inappropriate if the application tries to 
> download data from a location based on the information contained in any 
> the certificate it just received
> - Performance : When the application has to validate a hich volume of 
> certificates, dynamic loading of the CRL is simply inappropriate. This 
> can be worked around by using caching mechanisms, but it will be more 
> adequate to use configuration particularly if the application already 
> configures rules about how often to download new CRLs (CRLS quite often 
> are renewed more frequently than their nextUpdate field signals, some CA 
> renew their CRL every day, but have a nextUpdate filed valid for one week).
> 
> So whilst it's very useful to have the CA include the information inside 
> the certificate, I think the standard should not try to constrain the 
> methods by which the application will get it's up to date revocation 
> info, or make it clearer that the use of alternates is appropriate when 
> they will give the same result.
> 
> Can I have confirmation from the group that the text in RFC5280 is *not* 
> intended to discourage applications under such circumstances from using 
> configuration settings instead of dynamically reading the CRL DP 
> extension content  ?
> 
> 
> 


-- 

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

--------------ms030509070506050206060504
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
AKCCAdEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwNzE1
MTU1NjE2WjAjBgkqhkiG9w0BCQQxFgQUo6K7t8Envtqea7C2N+SxuNSPCScwUgYJKoZIhvcN
AQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYF
Kw4DAgcwDQYIKoZIhvcNAwICASgwgYwGCSsGAQQBgjcQBDF/MH0wdzETMBEGCgmSJomT8ixk
ARkWA2VkdTEZMBcGCgmSJomT8ixkARkWCWRhcnRtb3V0aDELMAkGA1UEBhMCVVMxGjAYBgNV
BAoTEURhcnRtb3V0aCBDb2xsZWdlMRwwGgYDVQQDExNEYXJ0bW91dGggQ2VydEF1dGgxAgIa
UzCBjgYLKoZIhvcNAQkQAgsxf6B9MHcxEzARBgoJkiaJk/IsZAEZFgNlZHUxGTAXBgoJkiaJ
k/IsZAEZFglkYXJ0bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91dGggQ29s
bGVnZTEcMBoGA1UEAxMTRGFydG1vdXRoIENlcnRBdXRoMQICGlMwDQYJKoZIhvcNAQEBBQAE
gYCrA40wHl9zopCfqNbaF3eabgpH48zfo20cAsaNDDbsNHLjMbfB0u0TRX1ey7BOp0KEht9X
NQKE+ELqY8JDV//2zqKxxJUDADUQ6fRbrUHhbXrEe9cdGX0MoQE+t8QpO0UdFURrkkd3+Few
Xpilr2GGql18KBsmASeLKddJ0fqztQAAAAAAAA==
--------------ms030509070506050206060504--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6FFppAA009031 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Jul 2009 08:51:51 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6FFppI8009030; Wed, 15 Jul 2009 08:51: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 n6FFpdA6009000 for <[e-mail]>; Wed, 15 Jul 2009 08:51:50 -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 6824578; Wed, 15 Jul 2009 17:51:15 +0200 (CEST)
Received: from smtps.on-x.com (mintaka.puteaux.on-x [192.168.14.11]) by varuna.puteaux.on-x (Postfix) with ESMTP id 1485317048; Wed, 15 Jul 2009 17:51:15 +0200 (CEST)
Received: from [192.168.0.12] (gut75-3-82-227-163-182.fbx.proxad.net [82.227.163.182]) by smtps.on-x.com (Postfix) with ESMTP id AD9677877; Wed, 15 Jul 2009 17:51:13 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Wed, 15 Jul 2009 17:51:14 +0200
From: Peter Sylvester <[e-mail]>
User-Agent: Thunderbird 2.0.0.22 (X11/20090608)
MIME-Version: 1.0
To: Jean-Marc Desperrier <[e-mail]>
Cc: [e-mail]
Subject: Re: RFC5280 : Applications and CRL DP extension support
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>

Jean-Marc Desperrier wrote:
>
> The text of RFC5280 says :
> 4.2.1.14 CRL Distribution Points
>     [...] this profile
>     recommends support for this extension by CAs and applications.
the full text is:

 The CRL distribution points extension identifies how CRL information
   is obtained.  The extension SHOULD be non-critical, but this profile
   RECOMMENDS support for this extension by CAs and applications.

>
> Whilst I 100% approve the recommendation for CAs (No CA should issue 
> certificates without CRLDP when they do provide CRL),
It is a recommandation, but not a requirement. Why do you approve the 
recommandation?

> what does it in practice mean for applications ?
>
>
> They are cases where dynamically  downloading the CRL by interpreting 
> the CRL DP extension is inappropriate for some applications, and where 
> the needs and context of the application make it much more adequate to 
> instead to configure in advance the location where the CRL of the 
> supported CAs can be found.
it depends what you mean by "dynamically". If you say: immediately, 
instantaneously, or during path
validation, then I agree with you. a relying party should  not be 
required to have a working
network connection to an uncontrollable environment.

The first sentence coul  probably be enhanced to read:
 "can be obtained", or "where the CA publishes a CRL for this cert"
>
> Some examples  :
> - Closed networks : Network access to the open internet and the CRL DP 
> might be simply unavailable, and the application should get CRLs from 
> copies made at alternative locations on the local network.
> - Controled network : Even if no alternative local location is 
> provided, network rules may forbid network  access that has not been 
> vetted beforehand, so make it inappropriate if the application tries 
> to download data from a location based on the information contained in 
> any the certificate it just received
> - Performance : When the application has to validate a hich volume of 
> certificates, dynamic loading of the CRL is simply inappropriate. This 
> can be worked around by using caching mechanisms, but it will be more 
> adequate to use configuration particularly if the application already 
> configures rules about how often to download new CRLs (CRLS quite 
> often are renewed more frequently than their nextUpdate field signals, 
> some CA renew their CRL every day, but have a nextUpdate filed valid 
> for one week).
The CA defines in its policy the source of CRLs. It also defines what 
kind of relying parties are possible.
If the a relying party is not able to use a "correct" crldp pointer due 
the first two cases, then one of the
parties hasn't done its job. resolving the url may also lead to 
different physical servers

performance: a local OCSP validation server (one of the first kind) can 
be regarded as just such a cache.
Unfortunately, the server cannot really "learn", because it never 
actually sees a certificate.

>
>
> So whilst it's very useful to have the CA include the information 
> inside the certificate, I think the standard should not try to 
> constrain the methods by which the application will get it's up to 
> date revocation info, or make it clearer that the use of alternates is 
> appropriate when they will give the same result.
The standard doesn't constrain this IMO. A recommandation is not a MUST.

>
>
> Can I have confirmation from the group that the text in RFC5280 is 
> *not* intended to discourage applications under such circumstances 
> from using configuration settings instead of dynamically reading the 
> CRL DP extension content  ?
>
>
The standard doesn't say that you have to get the information in a 
"dynamic" way IMO. loading crls
from a file which is updated in intervals is an implementation detail 
for a relying party.
I would thus vote: 'confirmed'.









Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6FE39Xd098402 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Jul 2009 07:03:09 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6FE39Jd098400; Wed, 15 Jul 2009 07:03: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-ft6.fr.colt.net (smtp-ft6.fr.colt.net [213.41.78.198]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6FE2uQP098380 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 15 Jul 2009 07:03:08 -0700 (MST) (envelope-from [e-mail])
Received: from smtp-ex2.fr.colt.net (smtp-ex2.fr.colt.net [213.41.78.195]) by smtp-ft6.fr.colt.net (8.13.8/8.13.8/Debian-3) with ESMTP id n6FE2qXi027229 for <[e-mail]>; Wed, 15 Jul 2009 16:02:52 +0200
Received: from host.104.92.68.195.rev.coltfrance.com ([195.68.92.104] helo=[172.30.24.37]) by smtp-ex2.fr.colt.net with esmtp (Exim) (envelope-from <[e-mail]>) id 1MR54Q-0000Di-1l for <[e-mail]>; Wed, 15 Jul 2009 16:02:54 +0200
Message-ID: <[e-mail]>
Date: Wed, 15 Jul 2009 16:02:53 +0200
From: Jean-Marc Desperrier <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.1pre) Gecko/20090703 SeaMonkey/2.0b1pre
MIME-Version: 1.0
To: [e-mail]
Subject: RFC5280 : Applications and CRL DP extension support
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ACL-Warn: 1/1 recipients OK.
Sender: [e-mail]
Precedence: 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 text of RFC5280 says :
4.2.1.14 CRL Distribution Points
     [...] this profile
     recommends support for this extension by CAs and applications.

Whilst I 100% approve the recommendation for CAs (No CA should issue 
certificates without CRLDP when they do provide CRL), what does it in 
practice mean for applications ?

They are cases where dynamically  downloading the CRL by interpreting 
the CRL DP extension is inappropriate for some applications, and where 
the needs and context of the application make it much more adequate to 
instead to configure in advance the location where the CRL of the 
supported CAs can be found.

Some examples  :
- Closed networks : Network access to the open internet and the CRL DP 
might be simply unavailable, and the application should get CRLs from 
copies made at alternative locations on the local network.
- Controled network : Even if no alternative local location is provided, 
network rules may forbid network  access that has not been vetted 
beforehand, so make it inappropriate if the application tries to 
download data from a location based on the information contained in any 
the certificate it just received
- Performance : When the application has to validate a hich volume of 
certificates, dynamic loading of the CRL is simply inappropriate. This 
can be worked around by using caching mechanisms, but it will be more 
adequate to use configuration particularly if the application already 
configures rules about how often to download new CRLs (CRLS quite often 
are renewed more frequently than their nextUpdate field signals, some CA 
renew their CRL every day, but have a nextUpdate filed valid for one week).

So whilst it's very useful to have the CA include the information inside 
the certificate, I think the standard should not try to constrain the 
methods by which the application will get it's up to date revocation 
info, or make it clearer that the use of alternates is appropriate when 
they will give the same result.

Can I have confirmation from the group that the text in RFC5280 is *not* 
intended to discourage applications under such circumstances from using 
configuration settings instead of dynamically reading the CRL DP 
extension content  ?




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6F9OvQs070975 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Jul 2009 02:24:57 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6F9Ov2R070974; Wed, 15 Jul 2009 02:24:57 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from UKCRN08.crn.thales-esecurity.com (mail.thales-esecurity.com [193.112.44.3]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6F9Ok2P070956 for <[e-mail]>; Wed, 15 Jul 2009 02:24:56 -0700 (MST) (envelope-from [e-mail])
Received: by ukcrn08.crn.thales-esecurity.com with Internet Mail Service (5.5.2653.19) id <343LVDR1>; Wed, 15 Jul 2009 10:24:42 +0100
Message-ID: <[e-mail]>
From: "Pope, Nick" <[e-mail]>
To: "'Stefan Santesson'" <[e-mail]>, Carl Wallace <[e-mail]>, [e-mail], [e-mail]
Subject: RE: Last Call: draft-ietf-pkix-ta-format (Trust Anchor Format) to Proposed Standard
Date: Wed, 15 Jul 2009 10:24:39 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

All,

I accept that we may not be able to change at this stage the TAF but we both
should bear in mind the existence the two solutions which need exist
together.

Nick


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> On Behalf Of Stefan Santesson
> Sent: 15 July 2009 02:16
> To: Carl Wallace; Pope, Nick; [e-mail]; [e-mail]
> Subject: Re: Last Call: draft-ietf-pkix-ta-format (Trust Anchor Format) to
> Proposed Standard
> 
> 
> Carl,
> 
> I agree with most of your assessment.
> 
> But Yes, there are interoperability issues on the larger scale.
> One current example is for example that the European and American Bridging
> CA models are incompatible from a technical perspective as the American
> model builds on cross certification while the European model builds on
> availability of TSLs.
> 
> A potential real impact scenario is that products may have to incorporate
> both architectures in order to function in both worlds. That is something
> I
> as standards guy would be pleased to avoid.
> 
> However, I don't think there is much we neither can or should do to change
> this.
> 
> 
> On 09-07-15 2:46 AM, "Carl Wallace" <[e-mail]> wrote:
> 
> >
> > TAF works with existing systems that use certificates as trust anchors
> > (a certificate is a TrustAnchorChoice object), offers a minor change to
> > that practice to allow relying parties to associate constraints with
> > certificates using syntax that is widely available (TBSCertificate) and
> > offers a minimal representation of trust anchor information for folks
> > who require such (TrustAnchorInfo).  I don't see an interoperability
> > issue with TAF.  Applications will use the appropriate format that meets
> > its needs.  Certificates are not suitable as trust anchors in all cases.
> > TAF is a relatively minimal, natural solution to this problem.
> >
> >
> >> -----Original Message-----
> >> From: Stefan Santesson [mailto:[e-mail]]
> >> Sent: Tuesday, July 14, 2009 6:42 PM
> >> To: Carl Wallace; Pope, Nick; [e-mail]; [e-mail]
> >> Subject: Re: Last Call: draft-ietf-pkix-ta-format (Trust Anchor
> > Format)
> >> to Proposed Standard
> >>
> >> Carl,
> >>
> >> I think the critique of the TSL work is well founded from the
> >> perspective of
> >> TAM, but there is nevertheless an important point here.
> >>
> >> While TSL might not be an ideal standard for automated trust anchor
> >> management, very much caused by its mixed scope of fields for both
> >> human and
> >> machine consumption, it has despite this become a central component
> > for
> >> efforts in Europe, supported by the EU commission, to provide a common
> >> framework for trust in CAs in Europe.
> >>
> >> There is a substantial risk that we will see two very different
> >> approaches
> >> that at least overlap in scope, which may harm interoperability.
> >>
> >> /Stefan
> >>
> >>
> >>
> >> On 09-07-10 1:50 PM, "Carl Wallace" <[e-mail]> wrote:
> >>
> >>> This document has been discussed previously relative to TAF.  A
> >> portion
> >>> of that discussion is here:
> >>> http://www.imc.org/ietf-pkix/mail-archive/msg05573.html.
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: [e-mail] [mailto:owner-ietf-
> >>>> [e-mail]] On Behalf Of Pope, Nick
> >>>> Sent: Friday, July 10, 2009 4:02 AM
> >>>> To: '[e-mail]'; [e-mail]
> >>>> Subject: RE: Last Call: draft-ietf-pkix-ta-format (Trust Anchor
> >>> Format)
> >>>> to Proposed Standard
> >>>>
> >>>>
> >>>> Perhaps the authors should be aware of the existing European
> >> Technical
> >>>> Specification for trust status lists (TS 102 231), which have some
> >>>> overlap
> >>>> in function with the Trust anchor list in this internet draft.
> >>>>
> >>>> This is being adopted by all EU member states as a means of
> >> publishing
> >>>> information on CA recognised as trustworthy under the national
> >>>> accreditation
> >>>> or supervisory schemes.
> >>>>
> >>>> To obtain a copy go to:
> >>>>
> >>>> http://pda.etsi.org/pda/queryform.asp
> >>>>
> >>>> and enter TS 102 231 in the search box.
> >>>>
> >>>> Nick Pope
> >>>> Thales e-Security Ltd
> >>>>
> >>>>
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: [e-mail] [mailto:owner-ietf-
> >>>> [e-mail]]
> >>>>> On Behalf Of The IESG
> >>>>> Sent: 10 July 2009 01:14
> >>>>> To: IETF-Announce
> >>>>> Cc: [e-mail]
> >>>>> Subject: Last Call: draft-ietf-pkix-ta-format (Trust Anchor
> > Format)
> >>>> to
> >>>>> Proposed Standard
> >>>>>
> >>>>>
> >>>>> The IESG has received a request from the Public-Key Infrastructure
> >>>>> (X.509) WG (pkix) to consider the following document:
> >>>>>
> >>>>> - 'Trust Anchor Format '
> >>>>>    <draft-ietf-pkix-ta-format-03.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-07-23. 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-ta-format-
> >> 03.txt
> >>>>>
> >>>>>
> >>>>> IESG discussion can be tracked via
> >>>>>
> >>>>
> >>>
> >>
> > https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag
> >>>> =17
> >>>>> 759&rfc_flag=0
> >>>> Consider the environment before printing this mail.
> >>>> "Thales e-Security Limited is incorporated in England and Wales
> > with
> >>>> company
> >>>> registration number 2518805. Its registered office is located at 2
> >>>> Dashwood
> >>>> Lang Road, The Bourne Business Park, Addlestone, Nr. Weybridge,
> >> Surrey
> >>>> KT15
> >>>> 2NX.
> >>>> The information contained in this e-mail is confidential. It may
> >> also
> >>>> be
> >>>> privileged. It is only intended for the stated addressee(s) and
> >> access
> >>>> to it
> >>>> by any other person is unauthorised. If you are not an addressee or
> >>> the
> >>>> intended addressee, you must not disclose, copy, circulate or in
> > any
> >>>> other
> >>>> way use or rely on the information contained in this e-mail. Such
> >>>> unauthorised use may be unlawful. If you have received this e-mail
> >> in
> >>>> error
> >>>> please delete it (and all copies) from your system, please also
> >> inform
> >>>> us
> >>>> immediately on [phone] or email postmaster@thales-
> >>>> esecurity.com.
> >>>> Commercial matters detailed or referred to in this e-mail are
> >> subject
> >>>> to a
> >>>> written contract signed for and on behalf of Thales e-Security
> >>>> Limited".
> >>>
> >>> _______________________________________________
> >>> Ietf mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/ietf
> >>
> >

Consider the environment before printing this mail.
"Thales e-Security Limited is incorporated in England and Wales with company
registration number 2518805. Its registered office is located at 2 Dashwood
Lang Road, The Bourne Business Park, Addlestone, Nr. Weybridge, Surrey KT15
2NX.
The information contained in this e-mail is confidential. It may also be
privileged. It is only intended for the stated addressee(s) and access to it
by any other person is unauthorised. If you are not an addressee or the
intended addressee, you must not disclose, copy, circulate or in any other
way use or rely on the information contained in this e-mail. Such
unauthorised use may be unlawful. If you have received this e-mail in error
please delete it (and all copies) from your system, please also inform us
immediately on [phone] or email [e-mail].
Commercial matters detailed or referred to in this e-mail are subject to a
written contract signed for and on behalf of Thales e-Security Limited". 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6F7ScgB060805 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Jul 2009 00:28:38 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6F7ScX1060804; Wed, 15 Jul 2009 00:28: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 n6F7SOKY060789 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 15 Jul 2009 00:28:36 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 59404 invoked from network); 15 Jul 2009 07:28:25 -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]>; 15 Jul 2009 07:28:25 -0000
Received: (qmail 30409 invoked from network); 15 Jul 2009 07:28:19 -0000
Received: from 213-64-142-21-no153.business.telia.com (HELO [192.168.0.17]) ([e-mail]@[213.64.142.21]) (envelope-sender <[e-mail]>) by s60.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <[e-mail]>; 15 Jul 2009 07:28:19 -0000
User-Agent: Microsoft-Entourage/12.19.0.090515
Date: Wed, 15 Jul 2009 03:15:30 +0200
Subject: Re: Last Call: draft-ietf-pkix-ta-format (Trust Anchor Format) to Proposed Standard
From: Stefan Santesson <[e-mail]>
To: Carl Wallace <[e-mail]>, "Pope, Nick" <[e-mail]>, <[e-mail]>, <[e-mail]>
Message-ID: <[e-mail]>
Thread-Topic: Last Call: draft-ietf-pkix-ta-format (Trust Anchor Format) to Proposed Standard
Thread-Index: AcoBORruS4wDApn5ScKB4kt3ZO5y1gAG0+fwAN/8tn0AA5c4wAABwQKZ
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>

Carl,

I agree with most of your assessment.

But Yes, there are interoperability issues on the larger scale.
One current example is for example that the European and American Bridging
CA models are incompatible from a technical perspective as the American
model builds on cross certification while the European model builds on
availability of TSLs.

A potential real impact scenario is that products may have to incorporate
both architectures in order to function in both worlds. That is something I
as standards guy would be pleased to avoid.

However, I don't think there is much we neither can or should do to change
this.


On 09-07-15 2:46 AM, "Carl Wallace" <[e-mail]> wrote:

> 
> TAF works with existing systems that use certificates as trust anchors
> (a certificate is a TrustAnchorChoice object), offers a minor change to
> that practice to allow relying parties to associate constraints with
> certificates using syntax that is widely available (TBSCertificate) and
> offers a minimal representation of trust anchor information for folks
> who require such (TrustAnchorInfo).  I don't see an interoperability
> issue with TAF.  Applications will use the appropriate format that meets
> its needs.  Certificates are not suitable as trust anchors in all cases.
> TAF is a relatively minimal, natural solution to this problem.
> 
> 
>> -----Original Message-----
>> From: Stefan Santesson [mailto:[e-mail]]
>> Sent: Tuesday, July 14, 2009 6:42 PM
>> To: Carl Wallace; Pope, Nick; [e-mail]; [e-mail]
>> Subject: Re: Last Call: draft-ietf-pkix-ta-format (Trust Anchor
> Format)
>> to Proposed Standard
>> 
>> Carl,
>> 
>> I think the critique of the TSL work is well founded from the
>> perspective of
>> TAM, but there is nevertheless an important point here.
>> 
>> While TSL might not be an ideal standard for automated trust anchor
>> management, very much caused by its mixed scope of fields for both
>> human and
>> machine consumption, it has despite this become a central component
> for
>> efforts in Europe, supported by the EU commission, to provide a common
>> framework for trust in CAs in Europe.
>> 
>> There is a substantial risk that we will see two very different
>> approaches
>> that at least overlap in scope, which may harm interoperability.
>> 
>> /Stefan
>> 
>> 
>> 
>> On 09-07-10 1:50 PM, "Carl Wallace" <[e-mail]> wrote:
>> 
>>> This document has been discussed previously relative to TAF.  A
>> portion
>>> of that discussion is here:
>>> http://www.imc.org/ietf-pkix/mail-archive/msg05573.html.
>>> 
>>> 
>>>> -----Original Message-----
>>>> From: [e-mail] [mailto:owner-ietf-
>>>> [e-mail]] On Behalf Of Pope, Nick
>>>> Sent: Friday, July 10, 2009 4:02 AM
>>>> To: '[e-mail]'; [e-mail]
>>>> Subject: RE: Last Call: draft-ietf-pkix-ta-format (Trust Anchor
>>> Format)
>>>> to Proposed Standard
>>>> 
>>>> 
>>>> Perhaps the authors should be aware of the existing European
>> Technical
>>>> Specification for trust status lists (TS 102 231), which have some
>>>> overlap
>>>> in function with the Trust anchor list in this internet draft.
>>>> 
>>>> This is being adopted by all EU member states as a means of
>> publishing
>>>> information on CA recognised as trustworthy under the national
>>>> accreditation
>>>> or supervisory schemes.
>>>> 
>>>> To obtain a copy go to:
>>>> 
>>>> http://pda.etsi.org/pda/queryform.asp
>>>> 
>>>> and enter TS 102 231 in the search box.
>>>> 
>>>> Nick Pope
>>>> Thales e-Security Ltd
>>>> 
>>>> 
>>>> 
>>>>> -----Original Message-----
>>>>> From: [e-mail] [mailto:owner-ietf-
>>>> [e-mail]]
>>>>> On Behalf Of The IESG
>>>>> Sent: 10 July 2009 01:14
>>>>> To: IETF-Announce
>>>>> Cc: [e-mail]
>>>>> Subject: Last Call: draft-ietf-pkix-ta-format (Trust Anchor
> Format)
>>>> to
>>>>> Proposed Standard
>>>>> 
>>>>> 
>>>>> The IESG has received a request from the Public-Key Infrastructure
>>>>> (X.509) WG (pkix) to consider the following document:
>>>>> 
>>>>> - 'Trust Anchor Format '
>>>>>    <draft-ietf-pkix-ta-format-03.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-07-23. 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-ta-format-
>> 03.txt
>>>>> 
>>>>> 
>>>>> IESG discussion can be tracked via
>>>>> 
>>>> 
>>> 
>> 
> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag
>>>> =17
>>>>> 759&rfc_flag=0
>>>> Consider the environment before printing this mail.
>>>> "Thales e-Security Limited is incorporated in England and Wales
> with
>>>> company
>>>> registration number 2518805. Its registered office is located at 2
>>>> Dashwood
>>>> Lang Road, The Bourne Business Park, Addlestone, Nr. Weybridge,
>> Surrey
>>>> KT15
>>>> 2NX.
>>>> The information contained in this e-mail is confidential. It may
>> also
>>>> be
>>>> privileged. It is only intended for the stated addressee(s) and
>> access
>>>> to it
>>>> by any other person is unauthorised. If you are not an addressee or
>>> the
>>>> intended addressee, you must not disclose, copy, circulate or in
> any
>>>> other
>>>> way use or rely on the information contained in this e-mail. Such
>>>> unauthorised use may be unlawful. If you have received this e-mail
>> in
>>>> error
>>>> please delete it (and all copies) from your system, please also
>> inform
>>>> us
>>>> immediately on [phone] or email postmaster@thales-
>>>> esecurity.com.
>>>> Commercial matters detailed or referred to in this e-mail are
>> subject
>>>> to a
>>>> written contract signed for and on behalf of Thales e-Security
>>>> Limited".
>>> 
>>> _______________________________________________
>>> Ietf mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/ietf
>> 
> 




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6F0kp51033036 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Jul 2009 17:46:51 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6F0kpbJ033034; Tue, 14 Jul 2009 17:46:51 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from p03c11o143.symantecmail.net (p03c11o143.symantecmail.net [208.65.144.86]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6F0kdVG033025 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 14 Jul 2009 17:46:50 -0700 (MST) (envelope-from [e-mail])
Received: from unknown [65.242.48.5] (EHLO scygexch1.cygnacom.com) by p03c11o143.symantecmail.net (mxl_mta-5.7.0-7) with ESMTP id bf62d5a4.3030494128.335633.00-005.p03c11o143.symantecmail.net (envelope-from <[e-mail]>); Tue, 14 Jul 2009 18:46:51 -0600 (MDT)
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: Last Call: draft-ietf-pkix-ta-format (Trust Anchor Format) to Proposed Standard
Date: Tue, 14 Jul 2009 20:46:38 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Last Call: draft-ietf-pkix-ta-format (Trust Anchor Format) to Proposed Standard
thread-index: AcoBORruS4wDApn5ScKB4kt3ZO5y1gAG0+fwAN/8tn0AA5c4wA==
References: <[e-mail]> <[e-mail]>
From: "Carl Wallace" <[e-mail]>
To: "Stefan Santesson" <[e-mail]>, "Pope, Nick" <[e-mail]>, <[e-mail]>, <[e-mail]>
X-Spam: [F=0.2000000000; S=0.200(2009070901)]
X-MAIL-FROM: <[e-mail]>
X-SOURCE-IP: [65.242.48.5]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

TAF works with existing systems that use certificates as trust anchors
(a certificate is a TrustAnchorChoice object), offers a minor change to
that practice to allow relying parties to associate constraints with
certificates using syntax that is widely available (TBSCertificate) and
offers a minimal representation of trust anchor information for folks
who require such (TrustAnchorInfo).  I don't see an interoperability
issue with TAF.  Applications will use the appropriate format that meets
its needs.  Certificates are not suitable as trust anchors in all cases.
TAF is a relatively minimal, natural solution to this problem.   =20


> -----Original Message-----
> From: Stefan Santesson [mailto:[e-mail]]
> Sent: Tuesday, July 14, 2009 6:42 PM
> To: Carl Wallace; Pope, Nick; [e-mail]; [e-mail]
> Subject: Re: Last Call: draft-ietf-pkix-ta-format (Trust Anchor
Format)
> to Proposed Standard
>=20
> Carl,
>=20
> I think the critique of the TSL work is well founded from the
> perspective of
> TAM, but there is nevertheless an important point here.
>=20
> While TSL might not be an ideal standard for automated trust anchor
> management, very much caused by its mixed scope of fields for both
> human and
> machine consumption, it has despite this become a central component
for
> efforts in Europe, supported by the EU commission, to provide a common
> framework for trust in CAs in Europe.
>=20
> There is a substantial risk that we will see two very different
> approaches
> that at least overlap in scope, which may harm interoperability.
>=20
> /Stefan
>=20
>=20
>=20
> On 09-07-10 1:50 PM, "Carl Wallace" <[e-mail]> wrote:
>=20
> > This document has been discussed previously relative to TAF.  A
> portion
> > of that discussion is here:
> > http://www.imc.org/ietf-pkix/mail-archive/msg05573.html.
> >
> >
> >> -----Original Message-----
> >> From: [e-mail] [mailto:owner-ietf-
> >> [e-mail]] On Behalf Of Pope, Nick
> >> Sent: Friday, July 10, 2009 4:02 AM
> >> To: '[e-mail]'; [e-mail]
> >> Subject: RE: Last Call: draft-ietf-pkix-ta-format (Trust Anchor
> > Format)
> >> to Proposed Standard
> >>
> >>
> >> Perhaps the authors should be aware of the existing European
> Technical
> >> Specification for trust status lists (TS 102 231), which have some
> >> overlap
> >> in function with the Trust anchor list in this internet draft.
> >>
> >> This is being adopted by all EU member states as a means of
> publishing
> >> information on CA recognised as trustworthy under the national
> >> accreditation
> >> or supervisory schemes.
> >>
> >> To obtain a copy go to:
> >>
> >> http://pda.etsi.org/pda/queryform.asp
> >>
> >> and enter TS 102 231 in the search box.
> >>
> >> Nick Pope
> >> Thales e-Security Ltd
> >>
> >>
> >>
> >>> -----Original Message-----
> >>> From: [e-mail] [mailto:owner-ietf-
> >> [e-mail]]
> >>> On Behalf Of The IESG
> >>> Sent: 10 July 2009 01:14
> >>> To: IETF-Announce
> >>> Cc: [e-mail]
> >>> Subject: Last Call: draft-ietf-pkix-ta-format (Trust Anchor
Format)
> >> to
> >>> Proposed Standard
> >>>
> >>>
> >>> The IESG has received a request from the Public-Key Infrastructure
> >>> (X.509) WG (pkix) to consider the following document:
> >>>
> >>> - 'Trust Anchor Format '
> >>>    <draft-ietf-pkix-ta-format-03.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-07-23. 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-ta-format-
> 03.txt
> >>>
> >>>
> >>> IESG discussion can be tracked via
> >>>
> >>
> >
>
https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dview_id&dTag=

> >> =3D17
> >>> 759&rfc_flag=3D0
> >> Consider the environment before printing this mail.
> >> "Thales e-Security Limited is incorporated in England and Wales
with
> >> company
> >> registration number 2518805. Its registered office is located at 2
> >> Dashwood
> >> Lang Road, The Bourne Business Park, Addlestone, Nr. Weybridge,
> Surrey
> >> KT15
> >> 2NX.
> >> The information contained in this e-mail is confidential. It may
> also
> >> be
> >> privileged. It is only intended for the stated addressee(s) and
> access
> >> to it
> >> by any other person is unauthorised. If you are not an addressee or
> > the
> >> intended addressee, you must not disclose, copy, circulate or in
any
> >> other
> >> way use or rely on the information contained in this e-mail. Such
> >> unauthorised use may be unlawful. If you have received this e-mail
> in
> >> error
> >> please delete it (and all copies) from your system, please also
> inform
> >> us
> >> immediately on [phone] or email postmaster@thales-
> >> esecurity.com.
> >> Commercial matters detailed or referred to in this e-mail are
> subject
> >> to a
> >> written contract signed for and on behalf of Thales e-Security
> >> Limited".
> >
> > _______________________________________________
> > Ietf mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/ietf
>=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 n6F0RCGS031872 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Jul 2009 17:27:12 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6F0RC1Z031870; Tue, 14 Jul 2009 17:27:12 -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 n6F0RA1r031858 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 14 Jul 2009 17:27:11 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 3936 invoked from network); 15 Jul 2009 00:27:18 -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 Jul 2009 00:27:18 -0000
Received: (qmail 30684 invoked from network); 15 Jul 2009 00:27:07 -0000
Received: from 213-64-142-21-no153.business.telia.com (HELO [192.168.0.17]) ([e-mail]@[213.64.142.21]) (envelope-sender <[e-mail]>) by s42.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <[e-mail]>; 15 Jul 2009 00:27:07 -0000
User-Agent: Microsoft-Entourage/12.19.0.090515
Date: Wed, 15 Jul 2009 02:16:29 +0200
Subject: Re: Last Call: draft-ietf-pkix-ta-format (Trust Anchor Format) to Proposed Standard
From: Stefan Santesson <[e-mail]>
To: Paul Hoffman <[e-mail]>
CC: <[e-mail]>, <[e-mail]>
Message-ID: <[e-mail]>
Thread-Topic: Last Call: draft-ietf-pkix-ta-format (Trust Anchor Format) to Proposed Standard
Thread-Index: AcoE4X+x+stJISnw7kO6vAAe5IJf9Q==
In-Reply-To: <p06240873c682c96aaacf@[10.20.30.158]>
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>

Paul,

I just provided information.

I don't think we can do anything. It is not reasonable for IETF to accept
TSL as bases for our work and it is not possible to turn EU around and
abandon TSL.

However, it has a value to be aware of the situation.

/Stefan



On 09-07-15 1:49 AM, "Paul Hoffman" <[e-mail]> wrote:

> 
> At 12:42 AM +0200 7/15/09, Stefan Santesson wrote:
>> There is a substantial risk that we will see two very different approaches
>> that at least overlap in scope, which may harm interoperability.
> 
> And....?
> 
> Are you proposing that the IETF abandon its efforts because of the EU's? Or
> that the EU abandon its work because of the IETF's? Or that the two dissimilar
> protocols somehow be merged (in a way that would cause less, not greater,
> confusion)? Or something else?
> 
> This is IETF Last Call. Please say what you think should happen in the IETF
> context with respect to this document.
> 
> --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 n6ENntFx029402 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Jul 2009 16:49:55 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6ENntwB029401; Tue, 14 Jul 2009 16:49:55 -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] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6ENnird029386 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Jul 2009 16:49:45 -0700 (MST) (envelope-from [e-mail])
Mime-Version: 1.0
Message-Id: <p06240873c682c96aaacf@[10.20.30.158]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Tue, 14 Jul 2009 16:49:43 -0700
To: Stefan Santesson <[e-mail]>
From: Paul Hoffman <[e-mail]>
Subject: Re: Last Call: draft-ietf-pkix-ta-format (Trust Anchor Format) to Proposed Standard
Cc: <[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 12:42 AM +0200 7/15/09, Stefan Santesson wrote:
>There is a substantial risk that we will see two very different approaches
>that at least overlap in scope, which may harm interoperability.

And....?

Are you proposing that the IETF abandon its efforts because of the EU's? Or that the EU abandon its work because of the IETF's? Or that the two dissimilar protocols somehow be merged (in a way that would cause less, not greater, confusion)? Or something else?

This is IETF Last Call. Please say what you think should happen in the IETF context with respect to this document.

--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 n6EMgmR7025474 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Jul 2009 15:42:48 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6EMgmrs025473; Tue, 14 Jul 2009 15:42:48 -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 n6EMgYid025461 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 14 Jul 2009 15:42:46 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 74203 invoked from network); 14 Jul 2009 22:42:41 -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]>; 14 Jul 2009 22:42:41 -0000
Received: (qmail 68004 invoked from network); 14 Jul 2009 22:42:31 -0000
Received: from 213-64-142-21-no153.business.telia.com (HELO [192.168.0.17]) ([e-mail]@[213.64.142.21]) (envelope-sender <[e-mail]>) by s42.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <[e-mail]>; 14 Jul 2009 22:42:31 -0000
User-Agent: Microsoft-Entourage/12.19.0.090515
Date: Wed, 15 Jul 2009 00:42:28 +0200
Subject: Re: Last Call: draft-ietf-pkix-ta-format (Trust Anchor Format) to Proposed Standard
From: Stefan Santesson <[e-mail]>
To: Carl Wallace <[e-mail]>, "Pope, Nick" <[e-mail]>, <[e-mail]>, <[e-mail]>
Message-ID: <[e-mail]>
Thread-Topic: Last Call: draft-ietf-pkix-ta-format (Trust Anchor Format) to Proposed Standard
Thread-Index: AcoBORruS4wDApn5ScKB4kt3ZO5y1gAG0+fwAN/8tn0=
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>

Carl,

I think the critique of the TSL work is well founded from the perspective of
TAM, but there is nevertheless an important point here.

While TSL might not be an ideal standard for automated trust anchor
management, very much caused by its mixed scope of fields for both human and
machine consumption, it has despite this become a central component for
efforts in Europe, supported by the EU commission, to provide a common
framework for trust in CAs in Europe.

There is a substantial risk that we will see two very different approaches
that at least overlap in scope, which may harm interoperability.

/Stefan



On 09-07-10 1:50 PM, "Carl Wallace" <[e-mail]> wrote:

> This document has been discussed previously relative to TAF.  A portion
> of that discussion is here:
> http://www.imc.org/ietf-pkix/mail-archive/msg05573.html.
> 
> 
>> -----Original Message-----
>> From: [e-mail] [mailto:owner-ietf-
>> [e-mail]] On Behalf Of Pope, Nick
>> Sent: Friday, July 10, 2009 4:02 AM
>> To: '[e-mail]'; [e-mail]
>> Subject: RE: Last Call: draft-ietf-pkix-ta-format (Trust Anchor
> Format)
>> to Proposed Standard
>> 
>> 
>> Perhaps the authors should be aware of the existing European Technical
>> Specification for trust status lists (TS 102 231), which have some
>> overlap
>> in function with the Trust anchor list in this internet draft.
>> 
>> This is being adopted by all EU member states as a means of publishing
>> information on CA recognised as trustworthy under the national
>> accreditation
>> or supervisory schemes.
>> 
>> To obtain a copy go to:
>> 
>> http://pda.etsi.org/pda/queryform.asp
>> 
>> and enter TS 102 231 in the search box.
>> 
>> Nick Pope
>> Thales e-Security Ltd
>> 
>> 
>> 
>>> -----Original Message-----
>>> From: [e-mail] [mailto:owner-ietf-
>> [e-mail]]
>>> On Behalf Of The IESG
>>> Sent: 10 July 2009 01:14
>>> To: IETF-Announce
>>> Cc: [e-mail]
>>> Subject: Last Call: draft-ietf-pkix-ta-format (Trust Anchor Format)
>> to
>>> Proposed Standard
>>> 
>>> 
>>> The IESG has received a request from the Public-Key Infrastructure
>>> (X.509) WG (pkix) to consider the following document:
>>> 
>>> - 'Trust Anchor Format '
>>>    <draft-ietf-pkix-ta-format-03.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-07-23. 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-ta-format-03.txt
>>> 
>>> 
>>> IESG discussion can be tracked via
>>> 
>> 
> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag
>> =17
>>> 759&rfc_flag=0
>> Consider the environment before printing this mail.
>> "Thales e-Security Limited is incorporated in England and Wales with
>> company
>> registration number 2518805. Its registered office is located at 2
>> Dashwood
>> Lang Road, The Bourne Business Park, Addlestone, Nr. Weybridge, Surrey
>> KT15
>> 2NX.
>> The information contained in this e-mail is confidential. It may also
>> be
>> privileged. It is only intended for the stated addressee(s) and access
>> to it
>> by any other person is unauthorised. If you are not an addressee or
> the
>> intended addressee, you must not disclose, copy, circulate or in any
>> other
>> way use or rely on the information contained in this e-mail. Such
>> unauthorised use may be unlawful. If you have received this e-mail in
>> error
>> please delete it (and all copies) from your system, please also inform
>> us
>> immediately on [phone] or email postmaster@thales-
>> esecurity.com.
>> Commercial matters detailed or referred to in this e-mail are subject
>> to a
>> written contract signed for and on behalf of Thales e-Security
>> Limited".
> 
> _______________________________________________
> Ietf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ietf




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6EDbnXW081350 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Jul 2009 06: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 n6EDbnLT081349; Tue, 14 Jul 2009 06: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 smtp100.biz.mail.re2.yahoo.com (smtp100.biz.mail.re2.yahoo.com [206.190.52.46]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n6EDbbZN081331 for <[e-mail]>; Tue, 14 Jul 2009 06:37:48 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 88710 invoked from network); 14 Jul 2009 13:37:37 -0000
Received: from unknown (HELO thunderfish.local) (turners@96.231.117.100 with plain) by smtp100.biz.mail.re2.yahoo.com with SMTP; 14 Jul 2009 13:37:37 -0000
X-Yahoo-SMTP: qPTWNAeswBAtDTSn9GKlmmL3C90ke7grn_5n9To-
X-YMail-OSG: 7ZrLJeEVM1kSGWQPcP249eCO.Di3SWifd6ukljbYf2LoCCi.ShqWS9b1Q.dpx0JNDSX60OmuWLV7c4gcoeWwavR3YZc_3JbzqHd9AThyhrcboGLW8q5WvMC36mQ17DeanW7B5pXv1qk_O5CltEQtQiu2xcH.EwZkUa7V4AVt2h62N86UhSMzi7bzXe9rEDScrWikoiii.U4kKXBJ2WkME5NhUwMdJVTTvEJui4tg1kpW60Cob5zgS8h5.GacdsixO8HhWe1t4ay2A8tlvKVFYceRFlsG2y5y_PvqGPeL1tqmjzOo2C3ZZPX1RTfvbppHT8fm_.8-
X-Yahoo-Newman-Property: ymail-3
Message-ID: <[e-mail]>
Date: Tue, 14 Jul 2009 09:37:37 -0400
From: Sean Turner <[e-mail]>
User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605)
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>
Subject: Re: WGLC on draft-ietf-pkix-new-asn1-05.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>

We need to align ECParameters with RFC 5480.  PKIX agreed to comment out 
  the specifiedCurve and namedCurve choices.  I leave the choice to you 
as to which way you'd like to fix it (though I tend to lean towards the 
1st):

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

or

ECParameters ::= CHOICE {
  namedCurve      CURVE.&id({NamedCurve}),
  implicitCurve   NULL,
  specifiedCurve  SpecifiedECDomain
  -- specifiedCurve MUST NOT be used in PKIX.
  -- Details for SpecifiedECDomain can be found in [X9.62].
  -- Any future additions to this CHOICE should be coordinated
  -- with ANSI X.9.
}
WITH COMPONENTS {namedCurve PRESENT}

spt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6CCcphI083607 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 12 Jul 2009 05:38:51 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6CCcpXt083606; Sun, 12 Jul 2009 05:38:51 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6CCcdWP083587 for <[e-mail]>; Sun, 12 Jul 2009 05:38:50 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.102] ((unknown) [75.141.233.128])  by rufus.isode.com (submission channel) via TCP with ESMTPSA  id <[e-mail]>; Sun, 12 Jul 2009 13:38:38 +0100
X-SMTP-Protocol-Errors: NORDNS
Cc: "'Charles W. Gardiner'" <[e-mail]>, "'Stefan Santesson'" <[e-mail]>, <[e-mail]>
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Jim Schaad <[e-mail]>
In-Reply-To: <13da01ca02ac$1520ebf0$3f62c3d0$@com>
Subject: Re: WGLC on draft-ietf-pkix-new-asn1-05.txt
Date: Sun, 12 Jul 2009 05:38:34 -0700
References: <[e-mail]> <6.2.1.2.2.20090710104636.02899208@127.0.0.1> <13da01ca02ac$1520ebf0$3f62c3d0$@com>
X-Mailer: Apple Mail (2.935.3)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
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 Jul 11, 2009, at 9:49 PM, Jim Schaad wrote:
>>
>> 4. PKIXExplicit88 has the statement "AttributeType ::=  
>> ATTRIBUTE.&id".
>> Why
>> not simply say AttributeType ::= OBJECT IDENTIFIER"?  This is a minor
>> point, but it seems to me that the present wording requires extra  
>> work
>> by a
>> computer or by a person trying to understand what is meant.  The
>> simpler
>> description is used in many other places, so why not this one?
>
> I might be willing to think about this type of change for the  
> benefit of a
> person, but not for the compiler. Taking your logic one step farther  
> it
> would make sense to eliminate the use of AttributeType and just use  
> OBJECT
> IDENTIFIER wherever AttributeType is used.  This would make it even  
> easier
> for the person reading the module.  This is one change that could be  
> made,
> however I don't know that I see a real benefit to making the change.

X.501(2008) uses:
   AttributeType  ::=  ATTRIBUTE.&id

Using
   AttributeType ::= OBJECT IDENTIFIER

in the PKIX module would, I think, would be confusing to readers of  
both specifications.  Consistency is a good thing.

Regarding other issues raised, I generally agree with Jim's response.   
In summary, I oppose making changes in response to Charlie's comment.

-- Kurt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6C4ra8C059329 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 11 Jul 2009 21:53:36 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6C4raSs059328; Sat, 11 Jul 2009 21:53:36 -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 n6C4rNkO059316 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <[e-mail]>; Sat, 11 Jul 2009 21:53:34 -0700 (MST) (envelope-from [e-mail])
Received: from GALATIONS (unknown [88.228.49.252]) by smtp3.pacifier.net (Postfix) with ESMTP id 4B9808CC4; Sat, 11 Jul 2009 21:49:38 -0700 (PDT)
From: "Jim Schaad" <[e-mail]>
To: "'Charles W. Gardiner'" <[e-mail]>, "'Stefan Santesson'" <[e-mail]>, <[e-mail]>
References: <[e-mail]> <6.2.1.2.2.20090710104636.02899208@127.0.0.1>
In-Reply-To: <6.2.1.2.2.20090710104636.02899208@127.0.0.1>
Subject: RE: WGLC on draft-ietf-pkix-new-asn1-05.txt
Date: Sun, 12 Jul 2009 07:49:00 +0300
Message-ID: <13da01ca02ac$1520ebf0$3f62c3d0$@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: AcoBd7yTsYOEx0G2Q0K7b+gNx22sWQBMSCfg
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>

Please see the comments embedded in the message.

> -----Original Message-----
> From: [e-mail] [mailto:owner-ietf-
> [e-mail]] On Behalf Of Charles W. Gardiner
> Sent: Friday, July 10, 2009 6:57 PM
> To: Stefan Santesson; [e-mail]
> Subject: Re: WGLC on draft-ietf-pkix-new-asn1-05.txt
> 
> 
>      My apologies for responding so late about this draft, but I have
> only
> recently had enough time to study carefully its implications for
> updating
> our ASN.1 "compiler" to accept the new notation.  So far I have several
> concerns:
> 
> 1. The files PKIXExplicit88 and PKIXImplicit88 import things from each
> other, creating an importing "loop".  This upsets the creation of ".h"
> files for C or C++ programs.  The looping can be prevented in the ".h"
> files with "#ifndef" statements, but the precedence of definitions will
> not
> always be correct.  This problem could be solved quite easily by taking
> some things out of either or both files and putting them in one or more
> other files which the PKIX*plicit88 files could import.

We have not introduced any new looping in the PKIX 5280 ASN.1 modules.
These modules have long had such loops in them.  If you go to a larger set
of modules to compile you will find even worse looping may occur.  Any ASN.1
compiler must be able to deal with this looping when doing emissions to .h
files.

> 
> 2. The ParamOptions described in AlgorithmInformation is not much use
> to a
> computer.  Translating the shades of necessity to numbers does not help
> either, particularly as the numbers are not in order of necessity.
> (What
> percentage of messages having parameters should be rejected if the
> preferredAbsent option is specified?)  Most of the options offered,
> namely
> required, absent and optional, can be achieved by choosing an
> appropriate
> form of the PARAM statement: for required, just give the TYPE; for
> absent,
> omit the PARAM statement completely; and for optional, use ARE OPTIONAL
> in
> the PARAM statement.  Perhaps inheritable could be dealt with by a
> variant
> of the ARE statement, or maybe that condition is implied by OPTION

We could order the values of ParamOptions if desired, however I do not
actually see any benefit to doing so.  No message should be rejected on
decoding when preferredAbsent is the value (the parameters should be decoded
and used), however when messages are encoded then the parameters should be
omitted.  The presence if this value in the object definition is to deal
with the text which says "the parameters for an algorithm have the type
NULL, the parameters SHOULD be omitted, but you MUST accept the parameters
if they are present."  This is, unfortunately a very common construction and
we need to represent this so that code can be written by the user (not the
compiler) that can correctly deal with it.  Having it emitted from the ASN.1
module rather than hand extracted from the text makes this more consistent.

> 
> 3. The disambiguation of SignatureAlgs and PublicKeys by the use of the
> file names, e.g PKIXAlgs-2008.SignatureAlgs, seems like a significant
> extension of the language.  Other cases use the name of a construct, as
> in
> the definition of SingleAttribute where it says ATTRIBUTE.&Type, but
> file
> names only appear in IMPORT statements.  Is this use of the language
> allowed in those difficult X68* documents? It might be simpler to
> change
> the names of the ambiguous terms in one case, e.g. SignatureAlgsOAEP
> (assuming that PKIXAlgs-2008 came first).  Or maybe both should be
> changed.

We looked at doing this both ways, that is using a single common name and
requiring the prefix of a module, and using distinguished names for each
module.  I finally decided that the use of a single common name makes it
clearer what the Object Set is used for and that clarity was worth requiring
that the module name (as defined in the import statement) be prefixed on the
single common name.

Please note that the reference to a variable as module.name was defined as
an acceptable part of the language in the 1988 ASN.1 syntax, while it was
not frequently used, it has always been in the language definition.

> 
> 4. PKIXExplicit88 has the statement "AttributeType ::= ATTRIBUTE.&id".
> Why
> not simply say AttributeType ::= OBJECT IDENTIFIER"?  This is a minor
> point, but it seems to me that the present wording requires extra work
> by a
> computer or by a person trying to understand what is meant.  The
> simpler
> description is used in many other places, so why not this one?

I might be willing to think about this type of change for the benefit of a
person, but not for the compiler. Taking your logic one step farther it
would make sense to eliminate the use of AttributeType and just use OBJECT
IDENTIFIER wherever AttributeType is used.  This would make it even easier
for the person reading the module.  This is one change that could be made,
however I don't know that I see a real benefit to making the change.

> 
>      The draft document certainly takes advantage of the abstractions
> allowed by the 2002 notation, and in some ways makes things more
> comprehensible -- once one masters the lingo.  I think attention to the
> points noted above would make the document easier to use by machine.
> 
> Charlie Gardiner
> 

Jim Schaad




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6AFuYC0039327 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Jul 2009 08:56:34 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6AFuYbU039326; Fri, 10 Jul 2009 08:56:34 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6AFuM49039308 for <[e-mail]>; Fri, 10 Jul 2009 08:56:33 -0700 (MST) (envelope-from [e-mail])
Received: from dommiel.bbn.com ([192.1.122.15] helo=gardiner-xp.bbn.com) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from <[e-mail]>) id 1MPHWO-0003Ky-FP; Fri, 10 Jul 2009 10:56:20 -0400
Message-Id: <6.2.1.2.2.20090710104636.02899208@127.0.0.1>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2
Date: Fri, 10 Jul 2009 11:57:11 -0400
To: Stefan Santesson <[e-mail]>, "[e-mail]" <[e-mail]>
From: "Charles W. Gardiner" <[e-mail]>
Subject: Re: WGLC on draft-ietf-pkix-new-asn1-05.txt
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

     My apologies for responding so late about this draft, but I have only 
recently had enough time to study carefully its implications for updating 
our ASN.1 "compiler" to accept the new notation.  So far I have several 
concerns:

1. The files PKIXExplicit88 and PKIXImplicit88 import things from each 
other, creating an importing "loop".  This upsets the creation of ".h" 
files for C or C++ programs.  The looping can be prevented in the ".h" 
files with "#ifndef" statements, but the precedence of definitions will not 
always be correct.  This problem could be solved quite easily by taking 
some things out of either or both files and putting them in one or more 
other files which the PKIX*plicit88 files could import.

2. The ParamOptions described in AlgorithmInformation is not much use to a 
computer.  Translating the shades of necessity to numbers does not help 
either, particularly as the numbers are not in order of necessity.  (What 
percentage of messages having parameters should be rejected if the 
preferredAbsent option is specified?)  Most of the options offered, namely 
required, absent and optional, can be achieved by choosing an appropriate 
form of the PARAM statement: for required, just give the TYPE; for absent, 
omit the PARAM statement completely; and for optional, use ARE OPTIONAL in 
the PARAM statement.  Perhaps inheritable could be dealt with by a variant 
of the ARE statement, or maybe that condition is implied by OPTIONAL.

3. The disambiguation of SignatureAlgs and PublicKeys by the use of the 
file names, e.g PKIXAlgs-2008.SignatureAlgs, seems like a significant 
extension of the language.  Other cases use the name of a construct, as in 
the definition of SingleAttribute where it says ATTRIBUTE.&Type, but file 
names only appear in IMPORT statements.  Is this use of the language 
allowed in those difficult X68* documents? It might be simpler to change 
the names of the ambiguous terms in one case, e.g. SignatureAlgsOAEP 
(assuming that PKIXAlgs-2008 came first).  Or maybe both should be changed.

4. PKIXExplicit88 has the statement "AttributeType ::= ATTRIBUTE.&id".  Why 
not simply say AttributeType ::= OBJECT IDENTIFIER"?  This is a minor 
point, but it seems to me that the present wording requires extra work by a 
computer or by a person trying to understand what is meant.  The simpler 
description is used in many other places, so why not this one?

     The draft document certainly takes advantage of the abstractions 
allowed by the 2002 notation, and in some ways makes things more 
comprehensible -- once one masters the lingo.  I think attention to the 
points noted above would make the document easier to use by machine.

Charlie Gardiner




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6ADtrCT029383 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Jul 2009 06:55:53 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6ADtr6U029382; Fri, 10 Jul 2009 06:55:53 -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 n6ADteBE029314 for <[e-mail]>; Fri, 10 Jul 2009 06:55:51 -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 D267518034; Fri, 10 Jul 2009 15:55:51 +0200 (CEST)
Received: from FRCLS4013 ([129.182.108.120]) by MSGA-001.frcl.bull.fr (Lotus Domino Release 5.0.11) with SMTP id 2009071015553891:56605 ; Fri, 10 Jul 2009 15:55:38 +0200 
Reply-To: [e-mail]
From: "Denis Pinkas"<[e-mail]>
To: "ietf-pkix"<[e-mail]>
CC: "Stefan Santesson"<[e-mail]>
Subject: Re: Way forward - updating RFC 3161
Date: Fri, 10 Jul 2009 15:55:38 +0200
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 10/07/2009 15:55:38, Serialize by Router on MSGA-001/FR/BULL(Release 5.0.11  |July 24, 2002) at 10/07/2009 15:55:40, Serialize complete at 10/07/2009 15:55:40
Content-Type: multipart/alternative;  boundary="----=_NextPart_09071015553780877458541_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_09071015553780877458541_002
Content-Type: text/plain; 
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable


No doubt that everybody agrees that RFC 3161 should be updated to allow t=
he use of RFC 5035 [ESSV2].=20
The question is whether other changes should also be made.

The major differences from RFC 3161 [RFC3161] are summarized on page 3 of=
 the draft and are listed below:

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

     2 - the document makes the difference between a time-stamping=20
         service and a time-stamping unit and allows a time-stamping=20
         service to support more than one time-stamping unit.

     3 - the format of the subject field of a TSU certificate is now=20
         defined.

and also some minor updates :

     4 - informative references to ISO 18014-1 [ISO18014-1],=20
         ISO 18014-2 [ISO18014-2] and ISO 18014-3 [ISO18014-3] have been=20
         added.

     5 - a new normative ASN1 module to refer to the ASN.1 modules=20
         from the latest RFCs.=20

At the moment, RFC 3161 makes confusion between three different concepts:=
=20
a TSA, a TSS and a TSU, respectively a Time-Stamping Authority,=20
a Time-Stamping Service and a Time-Stamping Unit.=20

IMO, the document should be cleaned to call a spade a spade.

Historically, the notions applicable to TSAs have been copied and pasted=20
from the documents related to CAs. Since a CA had one private key, a TSA=20
had one private key as well, but this was short looking.

The CA advertises one public key, or more exactly one trust anchor, usual=
ly=20
by issuing a self-signed certificate. This private key, when in use,=20
is supported by one HSH (Hardware Security Module). This private key need=
s=20
to be saved in order to be restored in case of a problem. The time for re=
storation=20
is usually not critical (this may take a few minutes or even a few hours)=
.=20
The life time of a CA certificate (or CA public key) is usually between o=
ne and=20
15 years and should not be changed earlier, unless strictly needed.

In order to provide time-stamp tokens (TSTs) with high availability, more=
 than=20
one TSU is usually needed. These units altogether provide a TSS (Time-Sta=
mping Service)=20
that is managed by an Authority called a TSA (Time-Stamping Authority).

The key used to sign TSTs is not the key from a TSA, but the key from a T=
SU.

In order to a high level of security, the key used to sign to TSTs should=
 NOT be saved=20
and restored. It should be generated by the TSU itself and should NOT be =
exported=20
outside the TSU. If the key of the TSU is erased purposely or by accident=
, a new key pair=20
and certificate should be generated. Since TSU certificates are provided =
by a CA,=20
TST verification systems do not need to change any trust anchor. Some TSU=
s may even=20
use short-lived TSU certificates, e.g. a TSU certificate valid for one we=
ek or even one day.=20
However, it is necessary to be able to know the name of the TSA when look=
ing at the=20
subject DN from the TSU certificate.

Along these lines, several changes should be made to RFC 3161. To mention=
 a few of them:

RFC 3161:
   If the TSA does not recognize the hash=20
   algorithm or knows that the hash algorithm is weak (a decision left=20
   to the discretion of each individual TSA), then the TSA SHOULD refuse=20
   to provide the time-stamp token by returning a pkiStatusInfo of=20
   'bad_alg'.

Proposed change :
   If the TSS does not recognize the hash=20
   algorithm or knows that the hash algorithm is weak (a decision left=20
    to the discretion of each individual TSA), then the TSS SHOULD refuse=
=20
    to provide the time-stamp token by returning a pkiStatusInfo of=20
    'bad_alg'.

RFC3161:
   The certificate identifier (ESSCertID) of the=20
   TSA certificate MUST be included as a signerInfo attribute inside a=20
  SigningCertificate attribute.

Proposed change:
   The certificate identifier (either ESSCertID  or ESSCertIDv2) of the T=
SU certificate=20
  MUST be included as a signerInfo attribute inside a SigningCertificate =
attribute.

RFC 3161:
   The serialNumber field is an integer assigned by the TSA to each=20
  TimeStampToken.

Proposed change:=20
   The serialNumber field is an integer assigned by the TSU to each=20
   TimeStampToken.

RFC 3161:
   genTime is the time at which the time-stamp token has been created by=20
=20
   the TSA.

Proposed change:
   genTime is the time at which the time-stamp token has been created by=20
   the TSU.

RF3161:
   The purpose of the tsa field is to give a hint in identifying the=20
   name of the TSA.

Proposed change:
   The purpose of the tsu field is to give a hint in identifying the=20
   name of the TSU.

Note that the difference between a TSU and a TSA that is already present=20
in RFC 3628 (Informational) is also present in ISO 18014 and in ETSI TS 1=
02 023.
All these documents have been issued after RFC 3161.

Even, if the bits on the wire are the same, the meaning of these bits=20
would not necessarily be the same. For example, the ESSCertID refers to=20
a  certificate from a TSU, not from a TSA.

Since the changes to be done are scattered around the document, a new dra=
ft=20
would seem more appropriate, hence why a new draft has been proposed.

>From another angle, should we have an update to RFC 3161 or a new draft?=20
An update would have to advantage to keep the magic number 3161 that ever=
ybody=20
identifies with TSP.

In any case, I believe that both the ESSCertIDv2 and the terminology aspe=
cts=20
should be addressed to align RFC 3161 with the documents issued after it.=
=20

Denis
----- Message re=E7u -----=20
De : Stefan Santesson=20
=C0 : Pope,Nick,ietf-pkix=20
Date : 2009-07-09, 13:13:15
Sujet : Re: Way forward - updating RFC 3161


I conclude that the list so far is unanimous in its view of not accepting=
 the approach of draft-ietf-pkix-rfc3161bis-01.
Even though we have not heard the opinion of the draft author, It feels t=
hat we will have a strong consensus for just making a short update docume=
nt.

/Stefan


On 09-07-01 12:47 PM, "Pope, Nick" <[e-mail]> wrote=
:


Stefan,
=20
I also agree with the approach of updating RFC 3161.  Changing the model =
of RFC 3161 is only going to cause confusion.
=20
The implementation architecture concepts used in the earlier proposal are=
 already described in RFC 3628  and so I see no need for further steps on=
 that aspect.
=20
Nick
=20

-----Original Message-----
From: Stefan Santesson [mailto:[e-mail]]=20
Sent: 01 July 2009 02:00
To: [e-mail]
Cc: Denis Pinkas; Pope, Nick
Subject: Way forward - updating RFC 3161

We need to resolve how to update RFC 3161 with respect to allowing suppor=
t of RFC 5035 (ESSV2)
One particular reason is because ETSI ESI is dependent on progression of =
this issue in PKIX.

I would like to open this issue up for debate and then hopefully conclude=
 this issue, possibly after a straw poll.

My personal opinion, and what I interpret as the general opinion of this =
working group is that we should reject draft-ietf-pkix-rfc3161bis-01 as b=
asis for updating rfc 3161. This draft intends to obsolete RFC 3161 and i=
ntroduces major changes to terminology and role description to align RFC =
3161 with the informational document RFC 3628.

It is problematic to introduce such major changes to a standard that is w=
idely deployed. It is neither required from a protocol implementation per=
spective as these changes are not intended to change any bits on the wire=
. The optional usage of ESSV2 does not motivate a total rewrite of the cu=
rrent standard, but is better handled in an update RFC.

If description of roles and responsibilities that so not change any bits =
on the wire need to be clarified in relation to RFC 3628 and RFC 3161, th=
en this should be handled either as an update to RFC 3628 or as a separat=
e informational document.

/Stefan=20

------=_NextPart_09071015553780877458541_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><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-fon=
t-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-langua=
ge: FR; mso-bidi-language: AR-SA"></SPAN>&nbsp;</DIV>
<DIV><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-fon=
t-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-langua=
ge: FR; mso-bidi-language: AR-SA">No=20
doubt that everybody agrees that RFC 3161 should be updated to allow the =
use of=20
RFC 5035 [ESSV2]. <BR>The question is whether other changes should also b=
e=20
made.<BR><BR>The major differences from RFC 3161 [RFC3161] are summarized=
 on=20
page 3 of the draft and are listed below:<BR><BR><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>1 - the docum=
ent has=20
been aligned with RFC 3628 to make the <BR><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;=20
</SPAN>difference between a time-stamping unit (TSU) and a TSA.<BR><BR><S=
PAN=20
style=3D"mso-spacerun: yes">&nbsp;</SPAN><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp; </SPAN>2 - the document ma=
kes the=20
difference between a time-stamping <BR><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;=20
</SPAN>service and a time-stamping unit and allows a time-stamping <BR><S=
PAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;=20
</SPAN>service to support more than one time-stamping unit.<BR><BR><SPAN=20
style=3D"mso-spacerun: yes">&nbsp; </SPAN><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;</SPAN>3 - the format of th=
e subject=20
field of a TSU certificate is now <BR><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;=20
</SPAN>defined.<BR><BR>and also some minor updates :<BR><BR><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;</SPAN>4 - informative references=
 to ISO=20
18014-1 [ISO18014-1], <BR><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;=20
</SPAN>ISO 18014-2 [ISO18014-2] and ISO 18014-3 [ISO18014-3] have been <B=
R><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;=20
</SPAN>added.<BR><BR><SPAN style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;=
=20
</SPAN><SPAN style=3D"mso-spacerun: yes">&nbsp;</SPAN>5 - a new normative=
 ASN1=20
module to refer to the ASN.1 modules <BR><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;=20
</SPAN>from the latest RFCs. <BR></SPAN><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'; mso-fareast-font-fa=
mily: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: =
FR; mso-bidi-language: AR-SA"><BR><FONT=20
face=3D"Times New Roman" size=3D3>At the moment, RFC 3161 makes confusion=
 between=20
three different concepts: <BR>a TSA, a TSS and a TSU, respectively a=20
Time-Stamping Authority, <BR>a Time-Stamping Service and a Time-Stamping =
Unit.=20
</FONT></SPAN></DIV>
<DIV><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'; mso-fareast-font-fa=
mily: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: =
FR; mso-bidi-language: AR-SA"><FONT=20
face=3D"Times New Roman" size=3D3></FONT></SPAN>&nbsp;</DIV>
<DIV><FONT face=3D"Times New Roman"><FONT size=3D3><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'; mso-fareast-font-fa=
mily: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: =
FR; mso-bidi-language: AR-SA">IMO,=20
the document should be cleaned to call a spade a spade.<BR><BR>Historical=
ly, the=20
notions applicable to TSAs have been copied and pasted <BR>from the docum=
ents=20
related to CAs. Since a CA had one private key, a TSA <BR>had one private=
 key as=20
well, but this was short looking.<BR><BR>The CA advertises one public key=
, or=20
more exactly one trust anchor, usually <BR>by issuing a self-signed certi=
ficate.=20
This private key, when in use, <BR>is supported by one HSH (Hardware Secu=
rity=20
Module). This private key needs <BR>to be saved in order to be restored i=
n case=20
of a problem. The time for restoration <BR>is usually not critical (this =
may=20
take a few minutes or even a few hours). <BR>The life time of a CA certif=
icate=20
(or CA public key) is usually between&nbsp;one and <BR>15 years and shoul=
d not=20
be changed earlier, unless strictly needed.<BR><BR>In order to provide=20
time-stamp tokens (TSTs) with high availability, more than <BR>one TSU is=
=20
usually needed. These units altogether provide a TSS (Time-Stamping Servi=
ce)=20
<BR>that is managed by an Authority called a TSA (Time-Stamping=20
Authority).<BR><BR>The key used to sign TSTs is not the key from a TSA, b=
ut the=20
key from a TSU.<BR><BR>In order to a high level of security, the key used=
 to=20
sign to TSTs should NOT be saved <BR>and restored. It should be generated=
 by the=20
TSU itself and should NOT be exported <BR>outside the TSU. If the key of =
the TSU=20
is erased purposely or by accident, a new key pair <BR>and certificate sh=
ould be=20
generated. Since TSU certificates are provided by a CA, <BR>TST verificat=
ion=20
systems do not need to change any trust anchor. Some TSUs may even <BR>us=
e=20
short-lived TSU certificates, e.g. a TSU certificate valid for one week o=
r even=20
one day. <BR>However, it is necessary to be able to know the name of the =
TSA=20
when looking at the <BR>subject DN from the TSU certificate.<BR><BR>Along=
 these=20
lines, several changes should be made to RFC 3161. To mention a few of=20
them:<BR><BR>RFC 3161:<BR></SPAN><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-fon=
t-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-langua=
ge: FR; mso-bidi-language: AR-SA"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>If the TSA does not recog=
nize the=20
hash</SPAN> </FONT></FONT></DIV>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><?xml:namespace prefix =3D o ns =3D=20
"urn:schemas-microsoft-com:office:office" /><o:p><FONT face=3D"Times New =
Roman"=20
size=3D3></FONT></o:p></SPAN></P>
<DIV><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-fon=
t-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-langua=
ge: FR; mso-bidi-language: AR-SA"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>algorithm or knows that t=
he hash=20
algorithm is weak (a decision left</SPAN><FONT face=3D"Times New Roman" s=
ize=3D3>=20
</FONT></DIV>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><o:p><FONT face=3D"Times New Roman"=20
size=3D3></FONT></o:p></SPAN></P>
<DIV><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-fon=
t-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-langua=
ge: FR; mso-bidi-language: AR-SA"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>to the discretion of each=
=20
individual TSA), then the TSA SHOULD refuse</SPAN><FONT face=3D"Times New=
 Roman"=20
size=3D3> </FONT></DIV>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><o:p><FONT face=3D"Times New Roman"=20
size=3D3></FONT></o:p></SPAN></P>
<DIV><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-fon=
t-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-langua=
ge: FR; mso-bidi-language: AR-SA"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>to provide the time-stamp=
 token by=20
returning a pkiStatusInfo of</SPAN><FONT face=3D"Times New Roman" size=3D=
3>=20
</FONT></DIV>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><o:p><FONT face=3D"Times New Roman"=20
size=3D3></FONT></o:p></SPAN></P>
<DIV><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-fon=
t-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-langua=
ge: FR; mso-bidi-language: AR-SA"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>'bad_alg'.<BR></SPAN><SPA=
N=20
lang=3DEN-US=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'; mso-fareast-font-fa=
mily: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: =
FR; mso-bidi-language: AR-SA"><BR><FONT=20
face=3D"Times New Roman" size=3D3>Proposed change&nbsp;:<BR></FONT></SPAN=
><SPAN=20
lang=3DEN-US=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-fon=
t-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-langua=
ge: FR; mso-bidi-language: AR-SA"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>If the TSS does not recog=
nize the=20
hash</SPAN><FONT face=3D"Times New Roman" size=3D3> </FONT></DIV>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><o:p><FONT face=3D"Times New Roman"=20
size=3D3></FONT></o:p></SPAN></P>
<DIV><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-fon=
t-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-langua=
ge: FR; mso-bidi-language: AR-SA"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>algorithm or knows that t=
he hash=20
algorithm is weak (a decision left</SPAN><FONT face=3D"Times New Roman" s=
ize=3D3>=20
</FONT></DIV>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><FONT=20
face=3D"Times New Roman"><FONT size=3D3><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><o:p>&nbsp;</o:p></SPAN><SPAN lang=3DE=
N-US=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-fon=
t-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-langua=
ge: FR; mso-bidi-language: AR-SA"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>to the discretion of each=
=20
individual TSA), then the TSS SHOULD refuse</SPAN> </FONT></FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><FONT=20
face=3D"Times New Roman"><FONT size=3D3><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><o:p>&nbsp;</o:p></SPAN><SPAN lang=3DE=
N-US=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-fon=
t-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-langua=
ge: FR; mso-bidi-language: AR-SA"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>to provide the time-stamp=
 token by=20
returning a pkiStatusInfo of</SPAN> </FONT></FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><o:p><FONT face=3D"Times New Roman"=20
size=3D3>&nbsp;</FONT></o:p></SPAN><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-fon=
t-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-langua=
ge: FR; mso-bidi-language: AR-SA"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>'bad_alg'.<BR></SPAN><SPA=
N=20
lang=3DEN-US=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'; mso-fareast-font-fa=
mily: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: =
FR; mso-bidi-language: AR-SA"><BR><FONT=20
face=3D"Times New Roman" size=3D3>RFC3161:<BR></FONT></SPAN><SPAN lang=3D=
EN-US=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-fon=
t-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-langua=
ge: FR; mso-bidi-language: AR-SA"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>The certificate identifie=
r=20
(ESSCertID) of the</SPAN><FONT face=3D"Times New Roman" size=3D3> </FONT>=
</P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><FONT=20
face=3D"Times New Roman"><FONT size=3D3><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><o:p>&nbsp;</o:p></SPAN><SPAN lang=3DE=
N-US=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-fon=
t-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-langua=
ge: FR; mso-bidi-language: AR-SA"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;</SPAN>TSA certificate MUST be in=
cluded as=20
a signerInfo attribute inside a</SPAN> </FONT></FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><o:p><FONT face=3D"Times New Roman"=20
size=3D3>&nbsp;</FONT></o:p></SPAN><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'; mso-fareast-font-fa=
mily: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: =
FR; mso-bidi-language: AR-SA"><FONT=20
face=3D"Times New Roman"><FONT size=3D3><SPAN style=3D"mso-spacerun: yes"=
>=20
</SPAN>SigningCertificate attribute.<BR><BR>Proposed=20
change:<BR></FONT></FONT></SPAN><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-fon=
t-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-langua=
ge: FR; mso-bidi-language: AR-SA"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>The certificate identifie=
r (either=20
ESSCertID&nbsp;<SPAN style=3D"mso-spacerun: yes"> </SPAN>or ESSCertIDv2) =
of the=20
TSU certificate <BR>&nbsp; MUST be included as a&nbsp;</SPAN><FONT=20
face=3D"Times New Roman"><FONT size=3D3><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'; mso-fareast-font-fa=
mily: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: =
FR; mso-bidi-language: AR-SA">signerInfo=20
attribute inside a SigningCertificate attribute.<BR><BR>RFC=20
3161:<BR></SPAN><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-fon=
t-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-langua=
ge: FR; mso-bidi-language: AR-SA"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>The serialNumber field is=
 an=20
integer assigned by the TSA to each</SPAN> </FONT></FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><o:p><FONT face=3D"Times New Roman"=20
size=3D3>&nbsp;</FONT></o:p></SPAN><FONT face=3D"Times New Roman"><FONT s=
ize=3D3><SPAN=20
lang=3DEN-US=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'; mso-fareast-font-fa=
mily: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: =
FR; mso-bidi-language: AR-SA"><SPAN=20
style=3D"mso-spacerun: yes"> </SPAN>TimeStampToken.<BR><BR>Proposed chang=
e:=20
<BR></SPAN><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-fon=
t-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-langua=
ge: FR; mso-bidi-language: AR-SA"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>The serialNumber field is=
 an=20
integer assigned by the TSU to each</SPAN> </FONT></FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><o:p><FONT face=3D"Times New Roman"=20
size=3D3>&nbsp;</FONT></o:p></SPAN><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-fon=
t-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-langua=
ge: FR; mso-bidi-language: AR-SA"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp; </SPAN>TimeStampToken.<BR></SPAN><SPAN=
=20
lang=3DEN-US=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'; mso-fareast-font-fa=
mily: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: =
FR; mso-bidi-language: AR-SA"><BR><FONT=20
face=3D"Times New Roman" size=3D3>RFC 3161:<BR></FONT></SPAN><SPAN lang=3D=
EN-US=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-fon=
t-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-langua=
ge: FR; mso-bidi-language: AR-SA"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>genTime is the time at wh=
ich the=20
time-stamp token has been created by</SPAN><FONT face=3D"Times New Roman"=
 size=3D3>=20
</FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><o:p><FONT face=3D"Times New Roman"=20
size=3D3>&nbsp;</FONT></o:p></SPAN></P>
<DIV><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-fon=
t-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-langua=
ge: FR; mso-bidi-language: AR-SA"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>the TSA.<BR></SPAN><SPAN=20
lang=3DEN-US=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'; mso-fareast-font-fa=
mily: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: =
FR; mso-bidi-language: AR-SA"><BR><FONT=20
face=3D"Times New Roman" size=3D3>Proposed change:<BR></FONT></SPAN><SPAN=
 lang=3DEN-US=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-fon=
t-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-langua=
ge: FR; mso-bidi-language: AR-SA"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>genTime is the time at wh=
ich the=20
time-stamp token has been created by</SPAN><FONT face=3D"Times New Roman"=
 size=3D3>=20
</FONT></DIV>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><o:p><FONT face=3D"Times New Roman"=20
size=3D3>&nbsp;</FONT></o:p></SPAN><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-fon=
t-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-langua=
ge: FR; mso-bidi-language: AR-SA"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp; </SPAN>the TSU.<BR></SPAN><SPAN lang=3D=
EN-US=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'; mso-fareast-font-fa=
mily: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: =
FR; mso-bidi-language: AR-SA"><BR><FONT=20
face=3D"Times New Roman" size=3D3>RF3161:<BR></FONT></SPAN><SPAN lang=3DE=
N-US=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-fon=
t-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-langua=
ge: FR; mso-bidi-language: AR-SA"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>The purpose of the tsa fi=
eld is to=20
give a hint in identifying the</SPAN><FONT face=3D"Times New Roman" size=3D=
3>=20
</FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><o:p><FONT face=3D"Times New Roman"=20
size=3D3>&nbsp;</FONT></o:p></SPAN><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-fon=
t-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-langua=
ge: FR; mso-bidi-language: AR-SA"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp; </SPAN>name of the TSA.<BR></SPAN><SPA=
N=20
lang=3DEN-US=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'; mso-fareast-font-fa=
mily: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: =
FR; mso-bidi-language: AR-SA"><BR><FONT=20
face=3D"Times New Roman" size=3D3>Proposed change:<BR></FONT></SPAN><SPAN=
 lang=3DEN-US=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-fon=
t-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-langua=
ge: FR; mso-bidi-language: AR-SA"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>The purpose of the tsu fi=
eld is to=20
give a hint in identifying the</SPAN><FONT face=3D"Times New Roman" size=3D=
3>=20
</FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><o:p><FONT face=3D"Times New Roman"=20
size=3D3></FONT></o:p></SPAN></P>
<DIV><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-fon=
t-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-langua=
ge: FR; mso-bidi-language: AR-SA"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>name of the TSU.<BR></SPA=
N><SPAN=20
lang=3DEN-US=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'; mso-fareast-font-fa=
mily: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: =
FR; mso-bidi-language: AR-SA"><BR><FONT=20
face=3D"Times New Roman" size=3D3>Note that the difference between a TSU =
and a TSA=20
that is already present <BR>in RFC 3628 (Informational) is also present i=
n ISO=20
18014 and in ETSI </FONT></SPAN><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'; mso-fareast-font-fa=
mily: 'Times New Roman'; mso-ansi-language: FR; mso-fareast-language: FR;=
 mso-bidi-language: AR-SA"><FONT=20
face=3D"Times New Roman" size=3D3>TS 102 023</FONT></SPAN><SPAN lang=3DEN=
-US=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'; mso-fareast-font-fa=
mily: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: =
FR; mso-bidi-language: AR-SA"><FONT=20
face=3D"Times New Roman" size=3D3>.</FONT></SPAN></DIV>
<DIV><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'; mso-fareast-font-fa=
mily: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: =
FR; mso-bidi-language: AR-SA"><FONT=20
face=3D"Times New Roman" size=3D3>All these documents have been issued af=
ter RFC=20
3161.<BR><BR>Even, if the bits on the wire are the same, the meaning of t=
hese=20
bits <BR>would not necessarily be the same. For example, the ESSCertID re=
fers=20
to&nbsp;<BR>a &nbsp;certificate from a TSU, not from a TSA.<BR><BR>Since =
the=20
changes to be done are scattered around the document, a new draft <BR>wou=
ld seem=20
more appropriate, hence why a new draft has been proposed.<BR><BR>From an=
other=20
angle, should we have an update to RFC 3161 or a new draft? <BR>An update=
 would=20
have to advantage to keep the magic number 3161 that everybody <BR>identi=
fies=20
with TSP.<BR><BR>In any case, I believe that both the ESSCertIDv2 and the=
=20
terminology aspects <BR>should be addressed to align RFC 3161 with the do=
cuments=20
issued after it. <BR></FONT></SPAN><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'; mso-fareast-font-fa=
mily: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: =
FR; mso-bidi-language: AR-SA"><BR><FONT=20
face=3D"Times New Roman" size=3D3>Denis</FONT></SPAN><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'; mso-fareast-font-fa=
mily: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: =
FR; mso-bidi-language: AR-SA"></DIV></SPAN>
<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]">Stefan Santesson</A> </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=20
  href=3D"mailto :[e-mail],[e-mail]">Pope,=
Nick,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>Date=20
  :</B> 2009-07-09, 13:13:15</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: Way forward - updating RFC 3161</DIV>
  <DIV><BR></DIV>
  <DIV></DIV>
  <DIV></DIV>
  <DIV><FONT face=3D"Calibri, Verdana, Helvetica, Arial"><SPAN=20
  style=3D"FONT-SIZE: 11pt">I conclude that the list so far is unanimous =
in its=20
  view of not accepting the approach of draft-ietf-pkix-rfc3161bis-01.<BR=
>Even=20
  though we have not heard the opinion of the draft author, It feels that=
 we=20
  will have a strong consensus for just making a short update=20
  document.<BR><BR>/Stefan<BR><BR><BR>On 09-07-01 12:47 PM, "Pope, Nick" =
&lt;<A=20
  href=3D"[e-mail]">[e-mail]<=
/A>&gt;=20
  wrote:<BR><BR></SPAN></FONT>
  <BLOCKQUOTE><FONT color=3D#000080><FONT size=3D2><FONT face=3DArial><SP=
AN=20
    style=3D"FONT-SIZE: 10pt">Stefan,<BR>&nbsp;<BR>I also agree with the =
approach=20
    of updating RFC 3161. &nbsp;Changing the model of RFC 3161 is only go=
ing to=20
    cause confusion.<BR>&nbsp;<BR>The implementation architecture concept=
s used=20
    in the earlier proposal are already described in RFC 3628 &nbsp;and s=
o I see=20
    no need for further steps on that=20
    aspect.<BR>&nbsp;<BR>Nick<BR>&nbsp;<BR></SPAN></FONT></FONT></FONT><F=
ONT=20
    face=3D"Calibri, Verdana, Helvetica, Arial"><SPAN=20
    style=3D"FONT-SIZE: 11pt"><BR></SPAN></FONT><FONT size=3D2><FONT=20
    face=3D"Tahoma, Verdana, Helvetica, Arial"><SPAN=20
    style=3D"FONT-SIZE: 10pt">-----Original Message-----<BR><B>From:</B> =
Stefan=20
    Santesson [<A=20
    href=3D"mailto:[e-mail]">mailto:[e-mail]</A>]=20
    <BR><B>Sent:</B> 01 July 2009 02:00<BR><B>To:</B> <A=20
    href=3D"[e-mail]">[e-mail]</A><BR><B>Cc:</B> Denis =
Pinkas;=20
    Pope, Nick<BR><B>Subject:</B> Way forward - updating RFC=20
    3161<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">We=20
    need to resolve how to update RFC 3161 with respect to allowing suppo=
rt of=20
    RFC 5035 (ESSV2)<BR>One particular reason is because ETSI ESI is depe=
ndent=20
    on progression of this issue in PKIX.<BR><BR>I would like to open thi=
s issue=20
    up for debate and then hopefully conclude this issue, possibly after =
a straw=20
    poll.<BR><BR>My personal opinion, and what I interpret as the general=
=20
    opinion of this working group is that we should reject=20
    draft-ietf-pkix-rfc3161bis-01 as basis for updating rfc 3161. This dr=
aft=20
    intends to obsolete RFC 3161 and introduces major changes to terminol=
ogy and=20
    role description to align RFC 3161 with the informational document RF=
C=20
    3628.<BR><BR>It is problematic to introduce such major changes to a s=
tandard=20
    that is widely deployed. It is neither required from a protocol=20
    implementation perspective as these changes are not intended to chang=
e any=20
    bits on the wire. The optional usage of ESSV2 does not motivate a tot=
al=20
    rewrite of the current standard, but is better handled in an update=20
    RFC.<BR><BR>If description of roles and responsibilities that so not =
change=20
    any bits on the wire need to be clarified in relation to RFC 3628 and=
 RFC=20
    3161, then this should be handled either as an update to RFC 3628 or =
as a=20
    separate informational document.<BR><BR>/Stefan</SPAN></FONT><FONT=20
    face=3D"Times New Roman"><SPAN style=3D"FONT-SIZE: 12pt">=20
    <BR></SPAN></FONT><FONT face=3D"Calibri, Verdana, Helvetica, Arial"><=
SPAN=20
    style=3D"FONT-SIZE: 11pt"><BR></SPAN></FONT></BLOCKQUOTE></DIV></BLOC=
KQUOTE></BODY></HTML>

------=_NextPart_09071015553780877458541_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 n6ABp9Kd017926 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Jul 2009 04:51:09 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6ABp9si017925; Fri, 10 Jul 2009 04:51:09 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from p03c11o142.symantecmail.net (p03c11o142.symantecmail.net [208.65.144.85]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6ABovD7017878 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Fri, 10 Jul 2009 04:51:08 -0700 (MST) (envelope-from [e-mail])
Received: from unknown [65.242.48.5] (EHLO scygexch1.cygnacom.com) by p03c11o142.symantecmail.net (mxl_mta-5.7.0-7) with ESMTP id c2b275a4.2050743216.72532.00-007.p03c11o142.symantecmail.net (envelope-from <[e-mail]>); Fri, 10 Jul 2009 05:51:08 -0600 (MDT)
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: Last Call: draft-ietf-pkix-ta-format (Trust Anchor Format) to Proposed Standard
Date: Fri, 10 Jul 2009 07:50:56 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Last Call: draft-ietf-pkix-ta-format (Trust Anchor Format) to Proposed Standard
thread-index: AcoBORruS4wDApn5ScKB4kt3ZO5y1gAG0+fw
References: <[e-mail]>
From: "Carl Wallace" <[e-mail]>
To: "Pope, Nick" <[e-mail]>, <[e-mail]>, <[e-mail]>
X-Spam: [F=0.2000000000; S=0.200(2009070901)]
X-MAIL-FROM: <[e-mail]>
X-SOURCE-IP: [65.242.48.5]
Sender: [e-mail]
Precedence: 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 document has been discussed previously relative to TAF.  A portion
of that discussion is here:
http://www.imc.org/ietf-pkix/mail-archive/msg05573.html.=20


> -----Original Message-----
> From: [e-mail] [mailto:owner-ietf-
> [e-mail]] On Behalf Of Pope, Nick
> Sent: Friday, July 10, 2009 4:02 AM
> To: '[e-mail]'; [e-mail]
> Subject: RE: Last Call: draft-ietf-pkix-ta-format (Trust Anchor
Format)
> to Proposed Standard
>=20
>=20
> Perhaps the authors should be aware of the existing European Technical
> Specification for trust status lists (TS 102 231), which have some
> overlap
> in function with the Trust anchor list in this internet draft.
>=20
> This is being adopted by all EU member states as a means of publishing
> information on CA recognised as trustworthy under the national
> accreditation
> or supervisory schemes.
>=20
> To obtain a copy go to:
>=20
> http://pda.etsi.org/pda/queryform.asp
>=20
> and enter TS 102 231 in the search box.
>=20
> Nick Pope
> Thales e-Security Ltd
>=20
>=20
>=20
> > -----Original Message-----
> > From: [e-mail] [mailto:owner-ietf-
> [e-mail]]
> > On Behalf Of The IESG
> > Sent: 10 July 2009 01:14
> > To: IETF-Announce
> > Cc: [e-mail]
> > Subject: Last Call: draft-ietf-pkix-ta-format (Trust Anchor Format)
> to
> > Proposed Standard
> >
> >
> > The IESG has received a request from the Public-Key Infrastructure
> > (X.509) WG (pkix) to consider the following document:
> >
> > - 'Trust Anchor Format '
> >    <draft-ietf-pkix-ta-format-03.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-07-23. 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-ta-format-03.txt
> >
> >
> > IESG discussion can be tracked via
> >
>
https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dview_id&dTag=

> =3D17
> > 759&rfc_flag=3D0
> Consider the environment before printing this mail.
> "Thales e-Security Limited is incorporated in England and Wales with
> company
> registration number 2518805. Its registered office is located at 2
> Dashwood
> Lang Road, The Bourne Business Park, Addlestone, Nr. Weybridge, Surrey
> KT15
> 2NX.
> The information contained in this e-mail is confidential. It may also
> be
> privileged. It is only intended for the stated addressee(s) and access
> to it
> by any other person is unauthorised. If you are not an addressee or
the
> intended addressee, you must not disclose, copy, circulate or in any
> other
> way use or rely on the information contained in this e-mail. Such
> unauthorised use may be unlawful. If you have received this e-mail in
> error
> please delete it (and all copies) from your system, please also inform
> us
> immediately on [phone] or email postmaster@thales-
> esecurity.com.
> Commercial matters detailed or referred to in this e-mail are subject
> to a
> written contract signed for and on behalf of Thales e-Security
> Limited".



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6A82I7F000161 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Jul 2009 01:02:18 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6A82ILU000160; Fri, 10 Jul 2009 01:02:18 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from UKCRN08.crn.thales-esecurity.com (mail.thales-esecurity.com [193.112.44.3]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6A826qp000145 for <[e-mail]>; Fri, 10 Jul 2009 01:02:17 -0700 (MST) (envelope-from [e-mail])
Received: by ukcrn08.crn.thales-esecurity.com with Internet Mail Service (5.5.2653.19) id <N9JNGQ4A>; Fri, 10 Jul 2009 09:02:03 +0100
Message-ID: <[e-mail]>
From: "Pope, Nick" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, [e-mail]
Subject: RE: Last Call: draft-ietf-pkix-ta-format (Trust Anchor Format) to Proposed Standard
Date: Fri, 10 Jul 2009 09:02:01 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Perhaps the authors should be aware of the existing European Technical
Specification for trust status lists (TS 102 231), which have some overlap
in function with the Trust anchor list in this internet draft.

This is being adopted by all EU member states as a means of publishing
information on CA recognised as trustworthy under the national accreditation
or supervisory schemes.

To obtain a copy go to:

http://pda.etsi.org/pda/queryform.asp

and enter TS 102 231 in the search box.

Nick Pope
Thales e-Security Ltd



> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> On Behalf Of The IESG
> Sent: 10 July 2009 01:14
> To: IETF-Announce
> Cc: [e-mail]
> Subject: Last Call: draft-ietf-pkix-ta-format (Trust Anchor Format) to
> Proposed Standard
> 
> 
> The IESG has received a request from the Public-Key Infrastructure
> (X.509) WG (pkix) to consider the following document:
> 
> - 'Trust Anchor Format '
>    <draft-ietf-pkix-ta-format-03.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-07-23. 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-ta-format-03.txt
> 
> 
> IESG discussion can be tracked via
> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=17
> 759&rfc_flag=0
Consider the environment before printing this mail.
"Thales e-Security Limited is incorporated in England and Wales with company
registration number 2518805. Its registered office is located at 2 Dashwood
Lang Road, The Bourne Business Park, Addlestone, Nr. Weybridge, Surrey KT15
2NX.
The information contained in this e-mail is confidential. It may also be
privileged. It is only intended for the stated addressee(s) and access to it
by any other person is unauthorised. If you are not an addressee or the
intended addressee, you must not disclose, copy, circulate or in any other
way use or rely on the information contained in this e-mail. Such
unauthorised use may be unlawful. If you have received this e-mail in error
please delete it (and all copies) from your system, please also inform us
immediately on [phone] or email [e-mail].
Commercial matters detailed or referred to in this e-mail are subject to a
written contract signed for and on behalf of Thales e-Security Limited". 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6A0EA99074932 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Jul 2009 17:14:10 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6A0EA13074931; Thu, 9 Jul 2009 17:14:10 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6A0E9W4074924 for <[e-mail]>; Thu, 9 Jul 2009 17:14:10 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 30) id 20CC83A6D3F; Thu,  9 Jul 2009 17:13:41 -0700 (PDT)
X-idtracker: yes
To: IETF-Announce <[e-mail]>
From: The IESG <[e-mail]>
Reply-to: [e-mail]
CC: <[e-mail]>
Subject: Last Call: draft-ietf-pkix-ta-format (Trust Anchor Format) to Proposed Standard
Message-Id: <[e-mail]>
Date: Thu,  9 Jul 2009 17:13:41 -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:

- 'Trust Anchor Format '
   <draft-ietf-pkix-ta-format-03.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-07-23. 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-ta-format-03.txt


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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n69LWLdk066329 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Jul 2009 14:32:22 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n69LWLaC066328; Thu, 9 Jul 2009 14:32:21 -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 n69LWAVV066319 for <[e-mail]>; Thu, 9 Jul 2009 14:32:21 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 30) id 42CC03A68A5; Thu,  9 Jul 2009 14:31:41 -0700 (PDT)
X-idtracker: yes
To: IETF-Announce <[e-mail]>
From: The IESG <[e-mail]>
Reply-to: [e-mail]
CC: <[e-mail]>
Subject: Last Call: draft-ietf-pkix-ta-format (Trust Anchor Format) to
Message-Id: <[e-mail]>
Date: Thu,  9 Jul 2009 14:31:42 -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>

Proposed Standard

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

- 'Trust Anchor Format '
   <draft-ietf-pkix-ta-format-03.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-07-23. 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-ta-format-03.txt


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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n69BDW5n027544 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Jul 2009 04:13:32 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n69BDWOt027543; Thu, 9 Jul 2009 04:13:32 -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 n69BDIWB027520 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 9 Jul 2009 04:13:30 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 65237 invoked from network); 9 Jul 2009 11:13:20 -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]>; 9 Jul 2009 11:13:20 -0000
Received: (qmail 51353 invoked from network); 9 Jul 2009 11:13:16 -0000
Received: from 213-64-142-21-no153.business.telia.com (HELO [192.168.0.17]) ([e-mail]@[213.64.142.21]) (envelope-sender <[e-mail]>) by s19.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <[e-mail]>; 9 Jul 2009 11:13:16 -0000
User-Agent: Microsoft-Entourage/12.19.0.090515
Date: Thu, 09 Jul 2009 13:13:15 +0200
Subject: Re: Way forward - updating RFC 3161
From: Stefan Santesson <[e-mail]>
To: "Pope, Nick" <[e-mail]>, <[e-mail]>
CC: Denis Pinkas <[e-mail]>
Message-ID: <[e-mail]>
Thread-Topic: Way forward - updating RFC 3161
Thread-Index: AcoAhkEF0bEPkm92pkiISr34/HqhxA==
In-Reply-To: <[e-mail]>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3329989996_27827715"
Sender: [e-mail]
Precedence: 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_3329989996_27827715
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit

I conclude that the list so far is unanimous in its view of not accepting
the approach of draft-ietf-pkix-rfc3161bis-01.
Even though we have not heard the opinion of the draft author, It feels that
we will have a strong consensus for just making a short update document.

/Stefan


On 09-07-01 12:47 PM, "Pope, Nick" <[e-mail]> wrote:

> Stefan,
>  
> I also agree with the approach of updating RFC 3161.  Changing the model of
> RFC 3161 is only going to cause confusion.
>  
> The implementation architecture concepts used in the earlier proposal are
> already described in RFC 3628  and so I see no need for further steps on that
> aspect.
>  
> Nick
>  
> 
> -----Original Message-----
> From: Stefan Santesson [mailto:[e-mail]]
> Sent: 01 July 2009 02:00
> To: [e-mail]
> Cc: Denis Pinkas; Pope, Nick
> Subject: Way forward - updating RFC 3161
>  
> We need to resolve how to update RFC 3161 with respect to allowing support of
> RFC 5035 (ESSV2)
> One particular reason is because ETSI ESI is dependent on progression of this
> issue in PKIX.
> 
> I would like to open this issue up for debate and then hopefully conclude this
> issue, possibly after a straw poll.
> 
> My personal opinion, and what I interpret as the general opinion of this
> working group is that we should reject draft-ietf-pkix-rfc3161bis-01 as basis
> for updating rfc 3161. This draft intends to obsolete RFC 3161 and introduces
> major changes to terminology and role description to align RFC 3161 with the
> informational document RFC 3628.
> 
> It is problematic to introduce such major changes to a standard that is widely
> deployed. It is neither required from a protocol implementation perspective as
> these changes are not intended to change any bits on the wire. The optional
> usage of ESSV2 does not motivate a total rewrite of the current standard, but
> is better handled in an update RFC.
> 
> If description of roles and responsibilities that so not change any bits on
> the wire need to be clarified in relation to RFC 3628 and RFC 3161, then this
> should be handled either as an update to RFC 3628 or as a separate
> informational document.
> 
> /Stefan 
> 


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

<HTML>
<HEAD>
<TITLE>Re: Way forward - updating RFC 3161</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt=
'>I conclude that the list so far is unanimous in its view of not accepting =
the approach of draft-ietf-pkix-rfc3161bis-01.<BR>
Even though we have not heard the opinion of the draft author, It feels tha=
t we will have a strong consensus for just making a short update document.<B=
R>
<BR>
/Stefan<BR>
<BR>
<BR>
On 09-07-01 12:47 PM, &quot;Pope, Nick&quot; &lt;<a href=3D"Nick.Pope@thales-=
esecurity.com">[e-mail]</a>&gt; wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT COLOR=3D"#000080"><FONT SIZE=3D"2"><FONT FACE=3D"=
Arial"><SPAN STYLE=3D'font-size:10pt'>Stefan,<BR>
&nbsp;<BR>
I also agree with the approach of updating RFC 3161. &nbsp;Changing the mod=
el of RFC 3161 is only going to cause confusion.<BR>
&nbsp;<BR>
The implementation architecture concepts used in the earlier proposal are a=
lready described in RFC 3628 &nbsp;and so I see no need for further steps on=
 that aspect.<BR>
&nbsp;<BR>
Nick<BR>
&nbsp;<BR>
</SPAN></FONT></FONT></FONT><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'>-----Original Message-----<BR>
<B>From:</B> Stefan Santesson [<a href=3D"mailto:[e-mail]">mailto:s=
[e-mail]</a>] <BR>
<B>Sent:</B> 01 July 2009 02:00<BR>
<B>To:</B> <a href=3D"[e-mail]">[e-mail]</a><BR>
<B>Cc:</B> Denis Pinkas; Pope, Nick<BR>
<B>Subject:</B> Way forward - updating RFC 3161<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'>We need to resolve how to update RFC 3161 with respect to al=
lowing support of RFC 5035 (ESSV2)<BR>
One particular reason is because ETSI ESI is dependent on progression of th=
is issue in PKIX.<BR>
<BR>
I would like to open this issue up for debate and then hopefully conclude t=
his issue, possibly after a straw poll.<BR>
<BR>
My personal opinion, and what I interpret as the general opinion of this wo=
rking group is that we should reject draft-ietf-pkix-rfc3161bis-01 as basis =
for updating rfc 3161. This draft intends to obsolete RFC 3161 and introduce=
s major changes to terminology and role description to align RFC 3161 with t=
he informational document RFC 3628.<BR>
<BR>
It is problematic to introduce such major changes to a standard that is wid=
ely deployed. It is neither required from a protocol implementation perspect=
ive as these changes are not intended to change any bits on the wire. The op=
tional usage of ESSV2 does not motivate a total rewrite of the current stand=
ard, but is better handled in an update RFC.<BR>
<BR>
If description of roles and responsibilities that so not change any bits on=
 the wire need to be clarified in relation to RFC 3628 and RFC 3161, then th=
is should be handled either as an update to RFC 3628 or as a separate inform=
ational document.<BR>
<BR>
/Stefan</SPAN></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'><BR>
</SPAN></FONT></BLOCKQUOTE>
</BODY>
</HTML>


--B_3329989996_27827715--




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6916hUE086390 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Jul 2009 18:06:43 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6916hll086389; Wed, 8 Jul 2009 18:06:43 -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 n6916f0Y086383 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 8 Jul 2009 18:06:42 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 85532 invoked from network); 9 Jul 2009 01:06:50 -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]>; 9 Jul 2009 01:06:50 -0000
Received: (qmail 39581 invoked from network); 9 Jul 2009 01:06:39 -0000
Received: from 213-64-142-21-no153.business.telia.com (HELO [192.168.0.17]) ([e-mail]@[213.64.142.21]) (envelope-sender <[e-mail]>) by s60.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <[e-mail]>; 9 Jul 2009 01:06:39 -0000
User-Agent: Microsoft-Entourage/12.19.0.090515
Date: Thu, 09 Jul 2009 03:06:41 +0200
Subject: WGLC on draft-ietf-pkix-new-asn1-05.txt
From: Stefan Santesson <[e-mail]>
To: "[e-mail]" <[e-mail]>
Message-ID: <[e-mail]>
Thread-Topic: WGLC on draft-ietf-pkix-new-asn1-05.txt
Thread-Index: AcoAMYSCTdtsO7y6eEuE+5lrugQPGg==
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3329953602_25631355"
Sender: [e-mail]
Precedence: 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_3329953602_25631355
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit


Initiating WG last call on draft-ietf-pkix-new-asn1-05.txt
Last call ends on Friday July 24.

/Stefan

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

<HTML>
<HEAD>
<TITLE>WGLC on draft-ietf-pkix-new-asn1-05.txt</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt=
'><BR>
Initiating WG last call on </SPAN></FONT><FONT SIZE=3D"1"><FONT FACE=3D"Geneva,=
 Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:12px'>draft-ietf-pkix-new=
-asn1-05.txt<BR>
Last call ends on Friday July 24.<BR>
<BR>
/Stefan</SPAN></FONT></FONT>
</BODY>
</HTML>


--B_3329953602_25631355--




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n66HkG4P072761 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Jul 2009 10:46:16 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n66HkG0F072760; Mon, 6 Jul 2009 10:46:16 -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 n66HkFNm072753 for <[e-mail]>; Mon, 6 Jul 2009 10:46:15 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 30) id BF86C28C3BE; Mon,  6 Jul 2009 10:45:48 -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: Document Action: 'Traceable Anonymous Certificate' to Experimental RFC
Message-Id: <[e-mail]>
Date: Mon,  6 Jul 2009 10:45:48 -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:

- 'Traceable Anonymous Certificate '
   <draft-ietf-pkix-tac-04.txt> as an Experimental RFC

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

The IESG contact persons are Tim Polk and Pasi Eronen.

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

Technical Summary

   This document describes a model for issuing X.509 certificates in
which the certificates do not contain the "true" name of the user, and
thus provide some level of anonymity. Traceable Anonymous Certificates
(TACs) are issued by a CA that is divided into two parts. One part
verifies and records the identity of the user to whom the certificate is
issued, and the other issues the certificate to the user but does not know
the user's identity.  The certificates issued under the TAC model are
intended primary for use in web access (and not in applications such as
e-mail). The model allows an aggrieved party to request that a TAC CA
divulge the identity of a user who has abused the anonymity offered by the
certificate. (Details of what constitutes abuse by a user are outside the
scope of the document and are established by TAC CA via a Certification
Policy.) To void the anonymity offered by the two-arty issuance procedure,
both parts of the CA collaborate using a protocol defined in the document.



  The current version of the model supports only RSA-based security
protocols between the two parts of the TAC CA, although the user's
certificate may contain a public key for any algorithm.


Working Group Summary


This document has reached rough WG consensus after considerable debate
over the last 18 months. It is targeted at Experimental status. This work
did not attract much interest from most WG members initially. It addresses
a PKI niche, which some WG members didn't think would ever be of
commercial interest. The document authors were Korean and they had
considerable trouble expressing their ideas in writing, and in a suitable
style for an IETF standard. Steve Kent, my co-chair, agreed to become a
co-author and he re-wrote the document and has coordinated subsequent
revisions. Two WG members provided extensive reviews of the I-D, which
resulted in a number of changes to address technical details. The version
that entered WGLC triggered comments from a few WG members. Changes were
made to address several of these comments, but a suggestion to make a
substantial design change was rejected. Two WG members raised concerns
whether the split-signature technology employed here adds enough security
to merit the increased complexity. However, the principle authors work for
KISA, the Korean Information Security Agency that accredits CAs in that
country. Their judgment that this is a reasonable tradeoff is enough to
merit progression as experimental document. The real proof of the
document's value will be decided based on adoption by CAs, something the
KISA authors say will happen (at least in their country).

Document Quality

There are no know implementations at this time, which is not surprising
for a document targeted at Experimental status. However, the KISA staff
who are the principle authors have indicated that they anticipate at least
one commercial TAC CA (in South Korea) will be forthcoming after an RFC is
published. An organization that chooses to implement the model described
here will be a CA service provider, not a product vendor per se.

RFC Editor Note

This document is being forwarded for publication assuming that the
proposed update to the TLP will be completed by the IETF Trust prior
to completion of the RFC publication process.  If that process does not
terminate successfully, please make the following substitution in 
Appendix A, replacing RFC XXXX with the number assigned to this RFC:

OLD

   DEFINITIONS IMPLICIT TAGS ::=

NEW

   DEFINITIONS IMPLICIT TAGS ::=

--
--   Copyright (c) 2009 IETF Trust and the persons identified as
--   authors of the code.  All rights reserved.
--
--   Redistribution and use in source and binary forms, with or without
--   modification, are permitted provided that the following conditions
--   are met:
--
--   - Redistributions of source code must retain the above copyright
--     notice, this list of conditions and the following disclaimer.
--
--   - Redistributions in binary form must reproduce the above copyright
--     notice, this list of conditions and the following disclaimer in
--     the documentation and/or other materials provided with the
--     distribution.
--
--   - Neither the name of Internet Society, IETF or IETF Trust, nor the
--     names of specific contributors, may be used to endorse or promote
--     products derived from this software without specific prior
--     written permission.
--
--
--
--   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
--   'AS IS' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
--   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
--   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
--   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
--   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
--   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
--   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
--   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
--   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
--   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
--
--   This version of the ASN.1 module is part of RFC XXXX;
--   see the RFC itself for full legal notices.
--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n61Alfv3086969 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Jul 2009 03:47:41 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n61AlfHn086968; Wed, 1 Jul 2009 03:47:41 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from UKCRN08.crn.thales-esecurity.com (mail.thales-esecurity.com [193.112.44.3]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n61AlTSQ086948 for <[e-mail]>; Wed, 1 Jul 2009 03:47:40 -0700 (MST) (envelope-from [e-mail])
Received: by ukcrn08.crn.thales-esecurity.com with Internet Mail Service (5.5.2653.19) id <N9JN192T>; Wed, 1 Jul 2009 11:47:24 +0100
Message-ID: <[e-mail]>
From: "Pope, Nick" <[e-mail]>
To: "'Stefan Santesson'" <[e-mail]>, [e-mail]
Cc: Denis Pinkas <[e-mail]>, "Pope, Nick" <[e-mail]>
Subject: RE: Way forward - updating RFC 3161
Date: Wed, 1 Jul 2009 11:47:20 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9FA39.4F01D0EE"
Sender: [e-mail]
Precedence: 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.

------_=_NextPart_001_01C9FA39.4F01D0EE
Content-Type: text/plain

Stefan,

 

I also agree with the approach of updating RFC 3161.  Changing the model of
RFC 3161 is only going to cause confusion.

 

The implementation architecture concepts used in the earlier proposal are
already described in RFC 3628  and so I see no need for further steps on
that aspect.

 

Nick

 

-----Original Message-----
From: Stefan Santesson [mailto:[e-mail]] 
Sent: 01 July 2009 02:00
To: [e-mail]
Cc: Denis Pinkas; Pope, Nick
Subject: Way forward - updating RFC 3161

 

We need to resolve how to update RFC 3161 with respect to allowing support
of RFC 5035 (ESSV2)
One particular reason is because ETSI ESI is dependent on progression of
this issue in PKIX.

I would like to open this issue up for debate and then hopefully conclude
this issue, possibly after a straw poll.

My personal opinion, and what I interpret as the general opinion of this
working group is that we should reject draft-ietf-pkix-rfc3161bis-01 as
basis for updating rfc 3161. This draft intends to obsolete RFC 3161 and
introduces major changes to terminology and role description to align RFC
3161 with the informational document RFC 3628.

It is problematic to introduce such major changes to a standard that is
widely deployed. It is neither required from a protocol implementation
perspective as these changes are not intended to change any bits on the
wire. The optional usage of ESSV2 does not motivate a total rewrite of the
current standard, but is better handled in an update RFC.

If description of roles and responsibilities that so not change any bits on
the wire need to be clarified in relation to RFC 3628 and RFC 3161, then
this should be handled either as an update to RFC 3628 or as a separate
informational document.

/Stefan 


------_=_NextPart_001_01C9FA39.4F01D0EE
Content-Type: text/html

<html>

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


<meta name=Generator content="Microsoft Word 10 (filtered)">
<title>Way forward - updating RFC 3161</title>

<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size: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;}
span.EmailStyle17
	{font-family:Arial;
	color:navy;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=EN-GB link=blue vlink=purple>

<div class=Section1>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>Stefan,</span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;</span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>I also agree with the approach of updating
RFC 3161.&nbsp; Changing the model of RFC 3161 is only going to cause confusion.</span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;</span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>The implementation architecture concepts
used in the earlier proposal are already described in RFC 3628 &nbsp;and so I
see no need for further steps on that aspect.</span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;</span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>Nick</span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;</span></font></p>

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

<p class=MsoNormal><font size=2 face=Tahoma><span lang=EN-US style='font-size:
10.0pt;font-family:Tahoma'>-----Original Message-----<br>
<b><span style='font-weight:bold'>From:</span></b> Stefan Santesson
[mailto:[e-mail]] <br>
<b><span style='font-weight:bold'>Sent:</span></b> 01 July 2009 02:00<br>
<b><span style='font-weight:bold'>To:</span></b> [e-mail]<br>
<b><span style='font-weight:bold'>Cc:</span></b> Denis Pinkas; Pope, Nick<br>
<b><span style='font-weight:bold'>Subject:</span></b> Way forward - updating
RFC 3161</span></font></p>

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

<p class=MsoNormal><font size=2 face=Calibri><span style='font-size:11.0pt;
font-family:Calibri'>We need to resolve how to update RFC 3161 with respect to
allowing support of RFC 5035 (ESSV2)<br>
One particular reason is because ETSI ESI is dependent on progression of this
issue in PKIX.<br>
<br>
I would like to open this issue up for debate and then hopefully conclude this
issue, possibly after a straw poll.<br>
<br>
My personal opinion, and what I interpret as the general opinion of this
working group is that we should reject draft-ietf-pkix-rfc3161bis-01 as basis
for updating rfc 3161. This draft intends to obsolete RFC 3161 and introduces
major changes to terminology and role description to align RFC 3161 with the
informational document RFC 3628.<br>
<br>
It is problematic to introduce such major changes to a standard that is widely
deployed. It is neither required from a protocol implementation perspective as
these changes are not intended to change any bits on the wire. The optional
usage of ESSV2 does not motivate a total rewrite of the current standard, but
is better handled in an update RFC.<br>
<br>
If description of roles and responsibilities that so not change any bits on the
wire need to be clarified in relation to RFC 3628 and RFC 3161, then this
should be handled either as an update to RFC 3628 or as a separate
informational document.<br>
<br>
/Stefan</span></font> </p>

</div>

</div>

</body>

</html>

------_=_NextPart_001_01C9FA39.4F01D0EE--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n619rKbD081457 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Jul 2009 02:53:21 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n619rK5J081456; Wed, 1 Jul 2009 02:53:20 -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 n619r89I081436 for <[e-mail]>; Wed, 1 Jul 2009 02:53:19 -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 921138D; Wed,  1 Jul 2009 11:53:06 +0200 (CEST)
Received: from [193.51.14.5] ([212.234.46.65]) by vinea.on-x.com (Lotus Domino Release 5.0.11) with ESMTP id 2009070111530478:54510 ; Wed, 1 Jul 2009 11:53:04 +0200 
Message-ID: <[e-mail]>
Date: Wed, 01 Jul 2009 11:53:05 +0200
From: Peter Sylvester <[e-mail]>
User-Agent: Thunderbird 1.5.0.9 (X11/20061206)
MIME-Version: 1.0
To: Stefan Santesson <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, Denis Pinkas <[e-mail]>, "Pope, Nick" <[e-mail]>
Subject: Re: Way forward - updating RFC 3161
References: <[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 07/01/2009 11:53:04 AM, Serialize by Router on vinea/ON-X(Release 5.0.11  |July 24, 2002) at 07/01/2009 11:53:05 AM, Serialize complete at 07/01/2009 11:53:05 AM
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>

Treating Stefan's request as a straw poll: I agree to reject the draft.
No comment about what should be done as updates to other texts.